From nobody Sun Apr 1 00:59:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B22124B0A; Sun, 1 Apr 2018 00:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIo8m4JMXirG; Sun, 1 Apr 2018 00:58:51 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B645E120724; Sun, 1 Apr 2018 00:58:50 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann , Eric Rescorla CC: IETF discussion list , General Area Review Team , "draft-ietf-tls-tls13.all@ietf.org" , "Dale R. Worley" , "" Thread-Topic: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] Thread-Index: AQHTyPZh/Bj0e6slEEedOHrlGtKOJKPrUiUAgAA5pSA= Date: Sun, 1 Apr 2018 07:58:47 +0000 Message-ID: <1522569526813.65723@s21sec.com> References: , <1522560535687.32559@cs.auckland.ac.nz> In-Reply-To: <1522560535687.32559@cs.auckland.ac.nz> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 07:58:55 -0000 > Note that temporarily enabling debug on a live endpoint isn't a big issue= ,=0A= > everything will continue to operate as before except for the one client t= hat=0A= > requests debug-level alerts, and that knows what it's up for because it= =0A= > explicitly asked for it.=0A= =0A= And for the malicious user that, knowing the server is currently in debug m= ode and returning extended errors, can more easily perform attacks on it...= =0A= =0A= ________________________________________=0A= De: TLS en nombre de Peter Gutmann =0A= Enviado: domingo, 1 de abril de 2018 7:29=0A= Para: Eric Rescorla=0A= Cc: IETF discussion list; General Area Review Team; draft-ietf-tls-tls13.al= l@ietf.org; Dale R. Worley; =0A= Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of= draft-ietf-tls-tls13-24]=0A= =0A= Eric Rescorla writes:=0A= =0A= >In my experience, there are four major scenarios for diagnosing this kind = of=0A= >failure. Under the assumption that you control one end, the other end can = be:=0A= >=0A= >1. A live endpoint.=0A= >2. A testing endpoint someone has put up.=0A= >3. An endpoint that someone is actively working on with you.=0A= >4. An endpoint you control (e.g., you're running it on your own machine).= =0A= >=0A= >If this is a debug-only feature, then it won't be available in case #1,=0A= =0A= I have the feeling the people who have commented on this were talking from= =0A= real-world experience, and in the example I gave it was exactly case #1. T= his=0A= was a live, large-scale production environment by a major ecommerce=0A= organisation (details fudged somewhat to avoid identifying anyone, but=0A= everyone here would know the name), and the only way to get things working = was=0A= to spend several weeks randomly tweaking every conceivable option on the=0A= client until things started working, because the only thing the server woul= d=0A= say was "Handshake failure". The client-side organisation still has no ide= a=0A= what made things work, they've narrowed it down by trial and error to about= =0A= half a dozen things they had to change, but that's it.=0A= =0A= If they'd been able to get the server operators to turn on extended-alert f= or=0A= even just a single handshake it would have avoided several weeks' effort an= d a=0A= fix that even now is pure guesswork.=0A= =0A= >For the same reason, it's not really that helpful in case #3, because you = can=0A= >just ask the person you're working with to read the logs,=0A= =0A= Except that these people are EDI companies, not TLS experts. They have=0A= neither the expertise nor the inclination to help debug TLS issues. What t= hey=0A= will do is enable debug on the server so the client can sort things out, bu= t=0A= they're not going to devote any effort to sorting out the problem at their= =0A= end.=0A= =0A= Note that temporarily enabling debug on a live endpoint isn't a big issue,= =0A= everything will continue to operate as before except for the one client tha= t=0A= requests debug-level alerts, and that knows what it's up for because it=0A= explicitly asked for it.=0A= =0A= >so this leaves case #2,=0A= =0A= Actually it leaves 1, 2, and 3. 4 is kinda pathological, so really the=0A= problem is "all of the cases".=0A= =0A= Peter.=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tls=0A= =0A= From nobody Sun Apr 1 01:14:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C8124B18; Sun, 1 Apr 2018 01:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 j7ckbBqd0aYh; Sun, 1 Apr 2018 01:14:18 -0700 (PDT) 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 B12A8120724; Sun, 1 Apr 2018 01:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1522570458; x=1554106458; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CM3dkwjKLE4Ajh+X2H54G2vlALVQKSSTJemhe9Q+mJY=; b=ZSzB8d04hz7FRGvani1hMPf0aqndcyRXHLYZwuBcONvxM/nrEMAWCQTV z4hsLi53tNcBvDwL7126A1tc6YKU6237923pQxLWmjzXnL77xOhsAj1/x T5DMqXkWbB0a9T6FE6GsnH0HW+Xod6fe0xbJ9oHI1ePtZVkSRo7oDiteX OVj9AN8HkIUwngBQnoyPb7DUya0+vfhRLgDso8knn2cAgaoycKj6jO8Mi 5mcufv+Aryjj5yfsqinURsBPH3hFRQxIogpRAGHrPtGY3mzM+yc7McqMq hFwiuLfY52RUdNpqy0EidqC4VTpE9qy2yNwDxvra2LFGOjnGcLUQLojxM g==; X-IronPort-AV: E=Sophos;i="5.48,391,1517828400"; d="scan'208";a="6070140" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Apr 2018 20:14:14 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 1 Apr 2018 20:14:14 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sun, 1 Apr 2018 20:14:13 +1200 From: Peter Gutmann To: Ion Larranaga Azcue , Eric Rescorla CC: IETF discussion list , General Area Review Team , "draft-ietf-tls-tls13.all@ietf.org" , "Dale R. Worley" , "" Thread-Topic: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] Thread-Index: AQHTyY9MxUl9Rw0+eUijRSwSGSYB/qPrj6CD Date: Sun, 1 Apr 2018 08:14:12 +0000 Message-ID: <1522570413761.44728@cs.auckland.ac.nz> References: , <1522560535687.32559@cs.auckland.ac.nz>, <1522569526813.65723@s21sec.com> In-Reply-To: <1522569526813.65723@s21sec.com> 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] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 08:14:20 -0000 Ion Larranaga Azcue writes:=0A= =0A= >And for the malicious user that, knowing the server is currently in debug= =0A= >mode and returning extended errors, can more easily perform attacks on it.= ..=0A= =0A= If there's someone on the Internet who can scan every TLS server on the pla= net=0A= once a minute to see a brief debug window open up, and then perform somethi= ng=0A= like a million-message-attack using a single debug message, then they're ki= nda=0A= wasting their abilities in attacking TLS servers...=0A= =0A= Peter.=0A= From nobody Sun Apr 1 02:55:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34450120727; Sun, 1 Apr 2018 02:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnjLKPzpsEx5; Sun, 1 Apr 2018 02:55:35 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67E01205D3; Sun, 1 Apr 2018 02:55:34 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann , Eric Rescorla CC: IETF discussion list , General Area Review Team , "draft-ietf-tls-tls13.all@ietf.org" , "Dale R. Worley" , "" Thread-Topic: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] Thread-Index: AQHTyPZh/Bj0e6slEEedOHrlGtKOJKPrUiUAgAA5pSD///RaAIAALNwQ Date: Sun, 1 Apr 2018 09:55:31 +0000 Message-ID: <1522576530994.95464@s21sec.com> References: , <1522560535687.32559@cs.auckland.ac.nz>, <1522569526813.65723@s21sec.com>, <1522570413761.44728@cs.auckland.ac.nz> In-Reply-To: <1522570413761.44728@cs.auckland.ac.nz> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 09:55:37 -0000 Of course not. I mean an attacker who is specially interested in this serve= r and knows that someone has requested a debug window on it.=0A= =0A= ________________________________________=0A= De: Peter Gutmann =0A= Enviado: domingo, 1 de abril de 2018 10:14=0A= Para: Ion Larranaga Azcue; Eric Rescorla=0A= Cc: IETF discussion list; General Area Review Team; draft-ietf-tls-tls13.al= l@ietf.org; Dale R. Worley; =0A= Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of= draft-ietf-tls-tls13-24]=0A= =0A= Ion Larranaga Azcue writes:=0A= =0A= >And for the malicious user that, knowing the server is currently in debug= =0A= >mode and returning extended errors, can more easily perform attacks on it.= ..=0A= =0A= If there's someone on the Internet who can scan every TLS server on the pla= net=0A= once a minute to see a brief debug window open up, and then perform somethi= ng=0A= like a million-message-attack using a single debug message, then they're ki= nda=0A= wasting their abilities in attacking TLS servers...=0A= =0A= Peter.=0A= =0A= From nobody Sun Apr 1 03:01:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04AA120727; Sun, 1 Apr 2018 03:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlPuCncBHsPI; Sun, 1 Apr 2018 03:00:56 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F2C1205D3; Sun, 1 Apr 2018 03:00:55 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann , Eric Rescorla CC: General Area Review Team , "Dale R. Worley" , IETF discussion list , "draft-ietf-tls-tls13.all@ietf.org" , "" Thread-Topic: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] Thread-Index: AQHTyPZh/Bj0e6slEEedOHrlGtKOJKPrUiUAgAA5pSD///RaAIAALNwQgAABZWY= Date: Sun, 1 Apr 2018 10:00:53 +0000 Message-ID: <1522576853459.77882@s21sec.com> References: , <1522560535687.32559@cs.auckland.ac.nz>, <1522569526813.65723@s21sec.com>, <1522570413761.44728@cs.auckland.ac.nz>,<1522576530994.95464@s21sec.com> In-Reply-To: <1522576530994.95464@s21sec.com> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 10:00:58 -0000 Anyway, I don't mean I'm against the idea of the extended errors extensions= ... Only that let's not take it lightly. It can be a good debugging tool bu= t also a risky one.=0A= =0A= ________________________________________=0A= De: TLS en nombre de Ion Larranaga Azcue =0A= Enviado: domingo, 1 de abril de 2018 11:55=0A= Para: Peter Gutmann; Eric Rescorla=0A= Cc: General Area Review Team; Dale R. Worley; IETF discussion list; draft-i= etf-tls-tls13.all@ietf.org; =0A= Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of= draft-ietf-tls-tls13-24]=0A= =0A= Of course not. I mean an attacker who is specially interested in this serve= r and knows that someone has requested a debug window on it.=0A= =0A= ________________________________________=0A= De: Peter Gutmann =0A= Enviado: domingo, 1 de abril de 2018 10:14=0A= Para: Ion Larranaga Azcue; Eric Rescorla=0A= Cc: IETF discussion list; General Area Review Team; draft-ietf-tls-tls13.al= l@ietf.org; Dale R. Worley; =0A= Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of= draft-ietf-tls-tls13-24]=0A= =0A= Ion Larranaga Azcue writes:=0A= =0A= >And for the malicious user that, knowing the server is currently in debug= =0A= >mode and returning extended errors, can more easily perform attacks on it.= ..=0A= =0A= If there's someone on the Internet who can scan every TLS server on the pla= net=0A= once a minute to see a brief debug window open up, and then perform somethi= ng=0A= like a million-message-attack using a single debug message, then they're ki= nda=0A= wasting their abilities in attacking TLS servers...=0A= =0A= Peter.=0A= =0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tls=0A= =0A= From nobody Sun Apr 1 06:53:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2273124C27 for ; Sun, 1 Apr 2018 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh73MFxfvlSl for ; Sun, 1 Apr 2018 06:53:48 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EE4124207 for ; Sun, 1 Apr 2018 06:53:48 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id q71-v6so11056173oic.6 for ; Sun, 01 Apr 2018 06:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SdRDHe6J3qwifUZVLUzDYJqgfTsjzW3vdpXHFHebr6w=; b=e1uiM3Y9XBGb7UID0NbZgN1iguuI3QRcC5+Ff2Y6mNrbSTSwpHEuInhuIiXvEEIwYD s1uQAv+kog5EOfZ/2/y1HEEv0cTP2GQSYrixqIYo591wB5o1Rx5zwaMnF5Kw7/3n2hR1 L8dQoV6U1aFzun7935MjEBBa7/f+W7EjGFt6cWA8CwxjOWRDA6n+q8K68oxlcOCg4zp5 +cMS+9jD6w+k2TlFZOwHzk9o7Oa8n0XbAD1FeDR7LDK9tOrH5rq/BEbUnROtpfTi59gG ChN7qgwo6H7OfXHmyDMP/X/I3GNKdDRM5g0+R9Mqnw3NSF5WHSIPeiYsO4ls2cQnT2jM LblQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SdRDHe6J3qwifUZVLUzDYJqgfTsjzW3vdpXHFHebr6w=; b=tO5ZBdOEQQSidFP0K4wP655UNkOMQ+asR5rOr9Lly2cGeNyTp0VGGcR/n5x+0lwj7b ArvSUihMfYdE5fLcNlTUDi66MP5ujb+DKbSAEWt47D48z/05+buDR5jVMLjn5YJnzews /CBTqNz1sWU6iW2rTy9//o2HQZymxwFmo5X/TArJ1n1TBNgHucz/zuRHw4M4GHI7Qdvc W0UNf1RLp1gJxBws+kD2DuEqbdASSCWr8QuAhlC/doLaL/76p3eBfPapX7e+Sc5xmGJH uVsQ7Zinpr+31eOCjHoNyrD7y2ULiaqeRDVr7DXzJkyjG370LEwvGokiIAsFXs+4g6uX YwOQ== X-Gm-Message-State: ALQs6tD44fvPIWMrQkoeTfoFeIXsLkWbXHZzuAnrdRBFDgYL9Ld/OvpO N+aMStPK8ZRPswZq3uPJhkYRhePjfrtCXfqJHZT2QQ== X-Google-Smtp-Source: AIpwx4+A+TzXM6IRd36PrVErKk/OGHFI4uyXUyHVtrlphAS7j9HHmd0Ty1fvYLsRi3NoYISD+iKeQfsrSvW4dHD6MAo= X-Received: by 2002:aca:3114:: with SMTP id x20-v6mr3458693oix.108.1522590827839; Sun, 01 Apr 2018 06:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Sun, 1 Apr 2018 06:53:07 -0700 (PDT) In-Reply-To: <1522560535687.32559@cs.auckland.ac.nz> References: <1522560535687.32559@cs.auckland.ac.nz> From: Eric Rescorla Date: Sun, 1 Apr 2018 06:53:07 -0700 Message-ID: To: Peter Gutmann Cc: Kathleen Moriarty , Bill Frantz , Steve Fenter , "Dale R. Worley" , General Area Review Team , IETF discussion list , "draft-ietf-tls-tls13.all@ietf.org" , "" Content-Type: multipart/alternative; boundary="0000000000006e97b00568c9cd3a" Archived-At: Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 13:53:51 -0000 --0000000000006e97b00568c9cd3a Content-Type: text/plain; charset="UTF-8" On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann wrote: > Eric Rescorla writes: > > >In my experience, there are four major scenarios for diagnosing this kind > of > >failure. Under the assumption that you control one end, the other end can > be: > > > >1. A live endpoint. > >2. A testing endpoint someone has put up. > >3. An endpoint that someone is actively working on with you. > >4. An endpoint you control (e.g., you're running it on your own machine). > > > >If this is a debug-only feature, then it won't be available in case #1, > > I have the feeling the people who have commented on this were talking from > real-world experience, Sure. I am also talking from real world experience. > and in the example I gave it was exactly case #1. This > was a live, large-scale production environment by a major ecommerce > organisation (details fudged somewhat to avoid identifying anyone, but > everyone here would know the name), and the only way to get things working > was > to spend several weeks randomly tweaking every conceivable option on the > client until things started working, because the only thing the server > would > say was "Handshake failure". The client-side organisation still has no > idea > what made things work, they've narrowed it down by trial and error to about > half a dozen things they had to change, but that's it. > > If they'd been able to get the server operators to turn on extended-alert > for > even just a single handshake it would have avoided several weeks' effort > and a > fix that even now is pure guesswork. Maybe. I've spent a fair amount of time trying to diagnose failures where I know precisely the line of code that generated the failure, and it can still be quite difficult. > >For the same reason, it's not really that helpful in case #3, because you > can > >just ask the person you're working with to read the logs, > > Except that these people are EDI companies, not TLS experts. They have > neither the expertise nor the inclination to help debug TLS issues. What > they > will do is enable debug on the server so the client can sort things out, > but > they're not going to devote any effort to sorting out the problem at their > end. > I'm not suggesting that they ask the counterparty to diagnose the problem, just send the relevant logs. It seems like the ask of "turn on logging and give me the results" and "turn on extended debugging" are fairly similar. -Ekr --0000000000006e97b00568c9cd3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann <<= a href=3D"mailto:pgut001@cs.auckland.ac.nz" target=3D"_blank">pgut001@cs.au= ckland.ac.nz> wrote:
Eric Rescorla <ekr@rtfm.com> writes:

>In my experience, there are four major scenarios for diagnosing this ki= nd of
>failure. Under the assumption that you control one end, the other end c= an be:
>
>1. A live endpoint.
>2. A testing endpoint someone has put up.
>3. An endpoint that someone is actively working on with you.
>4. An endpoint you control (e.g., you're running it on your own mac= hine).
>
>If this is a debug-only feature, then it won't be available in case= #1,

I have the feeling the people who have commented on this were talkin= g from
real-world experience,


and in the example I gave it was exactly case #1.= =C2=A0 This
was a live, large-scale production environment by a major ecommerce
organisation (details fudged somewhat to avoid identifying anyone, but
everyone here would know the name), and the only way to get things working = was
to spend several weeks randomly tweaking every conceivable option on the client until things started working, because the only thing the server woul= d
say was "Handshake failure".=C2=A0 The client-side organisation s= till has no idea
what made things work, they've narrowed it down by trial and error to a= bout
half a dozen things they had to change, but that's it.

If they'd been able to get the server operators to turn on extended-ale= rt for
even just a single handshake it would have avoided several weeks' effor= t and a
fix that even now is pure guesswork.

Maybe.= I've spent a fair amount of time trying to diagnose failures where
I know precisely the line of code that generated the failure, and it= can still
be quite difficult.

=C2=A0
>For the same reason, it's not really that helpful in case #3, becau= se you can
>just ask the person you're working with to read the logs,

Except that these people are EDI companies, not TLS experts.=C2=A0 T= hey have
neither the expertise nor the inclination to help debug TLS issues.=C2=A0 W= hat they
will do is enable debug on the server so the client can sort things out, bu= t
they're not going to devote any effort to sorting out the problem at th= eir
end.

I'm not suggesting that they a= sk the counterparty to diagnose the problem,
just send the releva= nt logs. It seems like the ask of "turn on logging and give
= me the results" and "turn on extended debugging" are fairly = similar.

-Ekr


--0000000000006e97b00568c9cd3a-- From nobody Sun Apr 1 07:38:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C6C124C27 for ; Sun, 1 Apr 2018 07:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cpDoipqB-ym for ; Sun, 1 Apr 2018 07:38:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24033124207 for ; Sun, 1 Apr 2018 07:38:02 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w31EbNRH013122; Sun, 1 Apr 2018 15:37:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Kn4MrnBJIQ6/gIXc6EBnLRsnOkzZt7eNnHYeWwtILPg=; b=QTI+ommGNxvD5ZJDEWZYf3O0mPorFQ+RlS9XfuJWh0c3LGJIsUy179R0SyDK5LWrzEPZ fs6Ju18P3GbJCNyKM5tntxrOk9fk/yl1296NCt903j+HCEy+X65sbV8dc6SGoZjPYZ8K EtGjvUCVmoxIMipuq2rb3UwBOrvA+LjczRdFfpGOrZ5E5cPwOUuE+4hFMwC+mFbApfQW WQgLnDXrg35BDI3FxQVg9nquBI/bxfmEKgFE6RPVeMsKduKh8/sScZg3DE/ZLEr/A0IN kw+vY2GRBykBwump+7VzcrWmZ6EdY15qxwre1S/yjxJPcW/hJ0YPjDrMBOVcW3jZA8+D nQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2h1ydc3as4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 Apr 2018 15:37:51 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w31EaXkb009281; Sun, 1 Apr 2018 10:37:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvbn3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 01 Apr 2018 10:37:50 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 1 Apr 2018 10:37:49 -0400 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.1263.000; Sun, 1 Apr 2018 10:37:49 -0400 From: "Salz, Rich" To: Peter Gutmann , Kathleen Moriarty , Eric Rescorla CC: "" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTx7wtXVSppbP1QU+ckO7A4mMz76PoUyqAgAEzRACAAAciAIAATT6AgAAFYoCAAHj/gIABS4aAgABZ1QA= Date: Sun, 1 Apr 2018 14:37:48 +0000 Message-ID: <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> In-Reply-To: <1522559738688.99197@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.62] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=799 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804010161 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=727 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804010161 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 14:38:04 -0000 PiAgICBQb3NzaWJseSwgaWYgeW91IGNvbnNpZGVyIGJlaW5nIGFibGUgdG8gc2F5ICJJbnZhbGlk IGxlbmd0aCBlbmNvZGluZyBpbg0KICAgIHByZWZlcnJlZC1FQ0MtY3VydmVzIGV4dGVuc2lvbiIg aW4gVHN3YW5hIGlzIG1pc3Npb24tY3JpdGljYWwgdG8gZGVidWdnaW5nIGENCiAgICBUTFMgaGFu ZHNoYWtlIGZhaWx1cmUuDQogIA0KSSBzbyBsb3ZlIHlvdXIgbWVzc2FnZXMsIFBldGVyLiAgSG9u ZXN0bHkgSSBkby4NCg0KUGVyaGFwcyBub3QgVHN3YW5hLCBidXQgcGVyaGFwcyBDaGluYSBtYXkg Y2FyZSB0byBwaWNrIGEgY291bnRlci1leGFtcGxlLg0KDQoNCg== From nobody Mon Apr 2 13:20:02 2018 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 7342612D93E; Mon, 2 Apr 2018 13:20:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152270040046.28413.18197119614911305289.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2018 13:20:00 -0700 Archived-At: Subject: [TLS] Warren Kumari's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 20:20:00 -0000 Warren Kumari has entered the following ballot position for draft-ietf-tls-iana-registry-updates-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-iana-registry-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'd suggest that the authors review the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-tls-iana-registry-updates-04-opsdir-lc-romascanu-2018-02-20/ I especially agree with #1 ("It would be useful from an operator perspective to add to the registries where the Recommended column is added a text similar to the one in Section 6,...") I'm guessing it is not needed, but should there be a note to the RFC editor to fix the "IANA [SHALL prepend/has prepended]..." bit to "IANA has prepended..." throughout? 'tis probably obvious enough, but I figured worth asking. The Nits Checker grumps about missing Updates in the Abstract -- I was getting ready to fuss about this, and then found "This document updates many (D)TLS RFCs (see updates header)." - this seems like a fine hack to me. From nobody Mon Apr 2 18:22:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFC126CBF; Mon, 2 Apr 2018 18:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nVjwBIqIQy5; Mon, 2 Apr 2018 18:21:57 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 4EE8A12DA13; Mon, 2 Apr 2018 18:21:54 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id 23-v6so17644014otj.0; Mon, 02 Apr 2018 18:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T4UNgQf6oh/SRfHTQDUSKMOlUTn8zYg4hI8lx6L32E0=; b=Y08earhkYuDgx73J5NQ6Mgdxfrvsk58aWd56JJkkBJeGx25vx0JztHzYA0IDM0nzBD accO/3aQr2FGc6QywAoopRh7vW6O53z6r51pGClsKPTVhD1SfMlilVGs1X4S2aaJ8ane i2WIb4eiQwzYTL6RFIRJIXQ8mUpYH7Vefk20RIXfBLe5NVVqmn4POaNCBYaiabgAK0qp smjnVj7hed9BemScKbf/WPsxowcFty6oMwyhkqkS9k/F53I85gX0Kabwuc/IVhvl56Pw 0T4eXdtAd61gNnN8u8ke9HPjxl6FqfiY1/xam0YnX3IAWohjamefO3g4QMTG7P5XXxvT QqnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T4UNgQf6oh/SRfHTQDUSKMOlUTn8zYg4hI8lx6L32E0=; b=QL6f1+CrG+C/7+1K/mdWJdXAL/1rLs2N+3/Nhz0YAusble2EdPduY/Lom3J+2jKLB/ nlmum5e+NjavG/hHgNWhNm42K1x7K48MahbkcxfMVNkdBdt5sfGB9SxMs/6rjpn8z4qC K32Y3XPG6dY5L14vmkfNVdybKAsJjn71lPNsmn4cDJLezlv7HSll6s90/n7xZZxuU7K1 Plm/FAAKU9NuGQaMtRaXkc91TQNulPThJMkQQOcFgmMY+6gzjiVo1vQ9ea4QRZ+olc2k S8GYyVmbT90SIfi/1QQgNIhqqg+MinfqOCbDsu2wp+hj9hhLkJJmnjrtrNbstxZxlM20 o8Dw== X-Gm-Message-State: ALQs6tBWirLzLiDFq5cs3kMMe2Fnj7mQ3CLh2Jg1/Mbn0TGio5plXOSQ QfTBCM722gqTWYL6N6FGjEx4IUkCUtNl6SacuQPY5n+M X-Google-Smtp-Source: AIpwx4+Wund/6qZZuw1jqwqFd/px3GpHiAL4UmmYuxqRvvXXisPfSXRN3MFlETHha41oNUFX57AjvevdL3PhNmM5d3M= X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr908613otd.394.1522718513506; Mon, 02 Apr 2018 18:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 2 Apr 2018 18:21:52 -0700 (PDT) In-Reply-To: <152252471645.19695.5060454044516666979.idtracker@ietfa.amsl.com> References: <152252471645.19695.5060454044516666979.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 3 Apr 2018 11:21:52 +1000 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Eric Rescorla's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 01:21:59 -0000 Nits are on the editor's copy. https://github.com/tlswg/tls-record-limit/commit/8c6307f63d5c3e34d3da1747fcdfbcc54aa290f6 On Sun, Apr 1, 2018 at 5:31 AM, Eric Rescorla wrote: > This text is a bit confusing. Consider a case where a server recognizes the > extension and has no limit, but the client offers one. > > In that case, the server can either: > > Return an extension with a max-size limit > Not return the extension > I think we want the server to conform to the client's limit in any case, but > "negotiated" is unclear. I think that I was operating on the assumption that both endpoints need to signal that they support the extension, but you are right that the server could omit the extension, but comply anyway. That doesn't seem properly transparent, so, at the cost of 6 octets, I think that we want everything to be clear. I've changed later text as follows: -Clients SHOULD advertise the `record_size_limit` extension, even if they have no -need to limit the size of records. This allows servers to advertise a limit at -their discretion. If this extension is not negotiated, endpoints can send -records of any size permitted by the protocol or other negotiated extensions. +Endpoints SHOULD advertise the `record_size_limit` extension, even if they have +no need to limit the size of records. For clients, this allows servers to +advertise a limit at their discretion. For servers, this allows clients to know +that their limit will be respected. If this extension is not negotiated, +endpoints can send records of any size permitted by the protocol or other +negotiated extensions. Note that while a client that sets a limit might be pleasantly surprised when a server respects its limit, having the extension "negotiated" means that it can treat overlarge records with an error. From nobody Mon Apr 2 18:56:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A912DA45 for ; Mon, 2 Apr 2018 18:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=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 TQojOvxvIjyf for ; Mon, 2 Apr 2018 18:56:05 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859D212DA41 for ; Mon, 2 Apr 2018 18:56:04 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id h26-v6so17661368otj.12 for ; Mon, 02 Apr 2018 18:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AddBOfSsXqVnJvTbh0M+KtrzOnz+68hf7yh4q45pL6k=; b=LCYQdv7e5x51HCuGshqSWhTzyQHJq3XmC3Yqt+YywOKNIMqKO7zQlr34yopscIwrqj SF269a7Zj3g3688INmlvXzmzEVP5njRl+pzxfbmgq1GT5qwZhZpER4RgvvJNmTR6hvHC 01d3bpojmOysmhzAz/jLl2Ch02PYZ5w5z5gzVwz1rFgjvsdOi282QszLbMD05EdCBsT+ dhJ/frgPurxN0T7Q0N8acvYO5Gu0CLG6Qq1gCtwcVIfjr9f/Gd8fnGM/lW5e00S+TCNp xwHbkYawRdN5x6UZIRaC2lIIO5vMWfBYCO3wEZFHWDIQXFcRZftwTdTFIcWSfKqEC/lf M2AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AddBOfSsXqVnJvTbh0M+KtrzOnz+68hf7yh4q45pL6k=; b=k1/ngXWD4zxRyNb3NHTllYl7KDLHQWXcye2R6NTebHBA7HVopJpF/kpURihOxjO7Gg mbR2tY5YhYXmatj/MOvr4XY2CigCE/aFsvKcN5/7PyQbg9qXmoXEtnJnAkOQdrOeN8be YdaxF3SRTL9dM1XqEeMqVQZBt2/32V930o/DlBbzSvEu08QkEXJZKReBWd3uCOzkMi5F n1abhm0gFJ8d0O5zy8DY7BKvLeA3YWUbn2QbzSkBvK2txSZ6rje5HyuXH3+CSgwZPloD Vk0/mfUcWCUbfGOQA6nJ31dtgYNTHyFut5FzWpVu+H9ljmCppMFeOAWZ8T5mbGKA2rl1 vPOA== X-Gm-Message-State: ALQs6tD1bJg9OeeSSwLzCFC7b4/K/poS4rk0tLt1qEiMdCH1KPxd4OMn HZH63+Z2XF+mA89d/Kx3QFD7INjH80w47uDYEN9T5Q== X-Google-Smtp-Source: AIpwx48AAmSzJbsTbK8fMh7k3UUGHv44GRXPIyofJUgJz4fJ+CPLaclWg3Og/j4Y/KQ0/WW4+I64+zMcAihSPSBGBWA= X-Received: by 2002:a9d:5192:: with SMTP id y18-v6mr7310251otg.176.1522720563980; Mon, 02 Apr 2018 18:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 2 Apr 2018 18:55:23 -0700 (PDT) In-Reply-To: References: <152252471645.19695.5060454044516666979.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 2 Apr 2018 18:55:23 -0700 Message-ID: To: Martin Thomson Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: multipart/alternative; boundary="0000000000004f017d0568e802ea" Archived-At: Subject: Re: [TLS] Eric Rescorla's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 01:56:07 -0000 --0000000000004f017d0568e802ea Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 6:21 PM, Martin Thomson wrote: > Nits are on the editor's copy. > > https://github.com/tlswg/tls-record-limit/commit/ > 8c6307f63d5c3e34d3da1747fcdfbcc54aa290f6 > > On Sun, Apr 1, 2018 at 5:31 AM, Eric Rescorla wrote: > > This text is a bit confusing. Consider a case where a server recognizes > the > > extension and has no limit, but the client offers one. > > > > In that case, the server can either: > > > > Return an extension with a max-size limit > > Not return the extension > > I think we want the server to conform to the client's limit in any case, > but > > "negotiated" is unclear. > > I think that I was operating on the assumption that both endpoints > need to signal that they support the extension, but you are right that > the server could omit the extension, but comply anyway. That doesn't > seem properly transparent, so, at the cost of 6 octets, I think that > we want everything to be clear. I've changed later text as follows: > > -Clients SHOULD advertise the `record_size_limit` extension, even if > they have no > -need to limit the size of records. This allows servers to advertise a > limit at > -their discretion. If this extension is not negotiated, endpoints can send > -records of any size permitted by the protocol or other negotiated > extensions. > +Endpoints SHOULD advertise the `record_size_limit` extension, even if > they have > +no need to limit the size of records. For clients, this allows servers to > +advertise a limit at their discretion. For servers, this allows > clients to know > +that their limit will be respected. If this extension is not negotiated, > +endpoints can send records of any size permitted by the protocol or other > +negotiated extensions. > > Note that while a client that sets a limit might be pleasantly > surprised when a server respects its limit, having the extension > "negotiated" means that it can treat overlarge records with an error. > This seems like a fine resolution. -Ekr --0000000000004f017d0568e802ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 2, 2018 at 6:21 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
Nits are= on the editor's copy.

https://git= hub.com/tlswg/tls-record-limit/commit/8c6307f63d5c3e34d3da1747fcd= fbcc54aa290f6

On Sun, Apr 1, 2018 at 5:31 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> This text is a bit confusing. Consider a case where a server recognize= s the
> extension and has no limit, but the client offers one.
>
> In that case, the server can either:
>
> Return an extension with a max-size limit
> Not return the extension
> I think we want the server to conform to the client's limit in any= case, but
> "negotiated" is unclear.

I think that I was operating on the assumption that both endpoints need to signal that they support the extension, but you are right that
the server could omit the extension, but comply anyway.=C2=A0 That doesn= 9;t
seem properly transparent, so, at the cost of 6 octets, I think that
we want everything to be clear.=C2=A0 I've changed later text as follow= s:

-Clients SHOULD advertise the `record_size_limit` extension, even if
they have no
-need to limit the size of records.=C2=A0 This allows servers to advertise = a limit at
-their discretion.=C2=A0 If this extension is not negotiated, endpoints can= send
-records of any size permitted by the protocol or other negotiated extensio= ns.
+Endpoints SHOULD advertise the `record_size_limit` extension, even if they= have
+no need to limit the size of records.=C2=A0 For clients, this allows serve= rs to
+advertise a limit at their discretion.=C2=A0 For servers, this allows
clients to know
+that their limit will be respected.=C2=A0 If this extension is not negotia= ted,
+endpoints can send records of any size permitted by the protocol or other<= br> +negotiated extensions.

Note that while a client that sets a limit might be pleasantly
surprised when a server respects its limit, having the extension
"negotiated" means that it can treat overlarge records with an er= ror.

This seems like a fine resolution.=

-Ekr


--0000000000004f017d0568e802ea-- From nobody Mon Apr 2 19:52:04 2018 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 736B31270A3; Mon, 2 Apr 2018 19:52:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152272392244.13963.7326437515101111372.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2018 19:52:02 -0700 Archived-At: Subject: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 02:52:02 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-tls-record-limit-02: 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-record-limit/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a nit, but just to make sure … The "record_size_limit" extension replaces the "max_fragment_length" extension [RFC6066]. A server that supports the "record_size_limit" extension MUST ignore and "max_fragment_length" that appears in a ^^^ the "and" should be "any", shouldn't it? ClientHello if both extensions appear. A client MUST treat receipt of both "max_fragment_length" and "record_size_limit" as a fatal error, and SHOULD generate an "illegal_parameter" alert. From nobody Mon Apr 2 21:47:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A06512D86D; Mon, 2 Apr 2018 21:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np0dXUQq9c2Q; Mon, 2 Apr 2018 21:47:53 -0700 (PDT) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E573124B17; Mon, 2 Apr 2018 21:47:53 -0700 (PDT) Received: by mail-ot0-x243.google.com with SMTP id h55-v6so16482448ote.9; Mon, 02 Apr 2018 21:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3hjDaWJfBV8ZklZYlF4hs4VSN00PcKZgh6fRdpAlOpg=; b=qfo1smT1CVE42NCcTXDnso28OzMUha1CuKRDKvi7ay51b8X3SbsDapsuuEeUfdvMID hxyuqqmE8lrNHC2+ga7TqV4fh4RbJyqaQ6X4C3j+vw68GnmtoK9mhTqEov+Nx29RrkaJ rfdXqhgh/IM58/cKL9bB1FhCfxP0p7WzbRpdBvk7gXi9nsWCDShofIWYXGQHMHOn1AIi lm1R5yv2DPUOM3lgeYk2KAuZ5juzbYL4CZg1TMW3yWLVnyBf/y6m/xI8LjNNMiUUZ6+i 5xrsE/V4oSleK1cHKFjpmMg0Py6zYkqcrbxGdpkDyKftuCyt41ArR08G1HpjpXUIsyb8 Nx/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3hjDaWJfBV8ZklZYlF4hs4VSN00PcKZgh6fRdpAlOpg=; b=ReiE+GtoeIgP4g+K5XQrspNvSyg0CUZHyaSRDu3h5yBoGKzoyBMOuXVuyx0tOHu4+b ipFpX694Jx8zjVXBtguSumsBoNjRhrp3U2CsYfDLUq+/iSoZJxJd1PxQZJdn9Yc85fR+ cge321M6vyO/TmWSrdeQUdEN3SnC3vNCzNDnCF6O8r4sI6KYYWVKSylz+rqAxMarjqXn R1eEJv4ZUQD+gNS73McVuRXqvnyfQ5SPHGXTtEQTH1wTg4YVRgeMbwlHcRbiNg/zhgR2 wioN18NARczffYmUpLGfxgxv5+xu7I2NURekxLfXRcn6IwiUr3q3g+o7kV6OF5TeA66D cSjQ== X-Gm-Message-State: ALQs6tBTLZKf/8ijZ7m6FWGRmHgC4NeutdyuWOlNwJE7W7wGSUrjkCjw zSq8l/RWyrU9hcgucL98IZnsCv+Z58O0m7QINwW1+ftQ X-Google-Smtp-Source: AIpwx4/7jQLvsEPF2fXK0M2sa+N/MSKnDFdyHmyoYpY4xnGebjXwunDHiVzPS/JC1zJtI44yX84Rf2Z5xc20qwvUk+4= X-Received: by 2002:a9d:454c:: with SMTP id p12-v6mr7613930oti.352.1522730872784; Mon, 02 Apr 2018 21:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 2 Apr 2018 21:47:52 -0700 (PDT) In-Reply-To: <152272392244.13963.7326437515101111372.idtracker@ietfa.amsl.com> References: <152272392244.13963.7326437515101111372.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 3 Apr 2018 14:47:52 +1000 Message-ID: To: Spencer Dawkins Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:47:55 -0000 For the transport ADs, who both noticed the same typo: https://github.com/tlswg/tls-record-limit/commit/e36a69777ee5661c33a421d64b= b48bb68c7680b9 (I think that it might have been "any", but "a" is equally good and also fewer characters) On Tue, Apr 3, 2018 at 12:52 PM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-tls-record-limit-02: 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-record-limit/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This is a nit, but just to make sure =E2=80=A6 > > The "record_size_limit" extension replaces the "max_fragment_length" > extension [RFC6066]. A server that supports the "record_size_limit" > extension MUST ignore and "max_fragment_length" that appears in a > ^^^ > the "and" should be "any", shouldn't it? > > ClientHello if both extensions appear. A client MUST treat receipt > of both "max_fragment_length" and "record_size_limit" as a fatal > error, and SHOULD generate an "illegal_parameter" alert. > > From nobody Mon Apr 2 21:49:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547C612D86D; Mon, 2 Apr 2018 21:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azdHrFVYx4Yw; Mon, 2 Apr 2018 21:49:25 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042BE126CB6; Mon, 2 Apr 2018 21:49:25 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id v64-v6so17986135otb.13; Mon, 02 Apr 2018 21:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qaQI499BZYoh8Zw827rdmbYfxbSYr6bGMplxtIqmiP8=; b=Y+QOTKsU0yOD2HjbsAkPsIbL2nx5KI0RoREb5DJeVGm8gxDvmTmgO+MfQph0FOX8XU Ju3aa8yp1WeNvkxNmMMa77cI9uY6OnGEUD/IHE/u7SJJPmB4QQKvVw1UrvTEj+fFHMFm eTI4rfF2PCyQlu/AC5lbX0HN1MllWJhukpsnDQkrVVAa5sswJ7wf4OrPDVqfEKUN1Df2 4u54ok5WMJjkLrIheDHSxpx5zXAnSs6XQkEccaE0/CH1aMBfdz9Pm8u9WDtHfk3j/0qe ff1ae/03ahr8rjmBvaBQBpJPKPAab4URr40eNy0qLLlMsfs6OU+mBM9lb515XcfGJPsP QeUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qaQI499BZYoh8Zw827rdmbYfxbSYr6bGMplxtIqmiP8=; b=bfBFVb3DLOcf8zi9G0/5xy0QL9oNayM817PPfLLh79nwP4iGJ+wDnfqqgPw7DD4FQ5 qMCrpJ0Lq2sx0/finRKsKB+QIXSkQIBvHCJCf0pn5OEvTuBdv3PUJ6uksWAs4NUGSdtU 3XzuC2QK7OxLcK2JuHExSXujii8bVJCId+m7EoFjE9NKmW6JwuiAaAIKWSoLiwys9NHZ KjaWhS7hx554+8gmP6KgX2ilgcUa581r3kBLpu10q94Wyt/w1taw2xtxOc0KF2ptKIdU alXs61PYzeSPzC74ejDnF+W0ccnxvGJmJvxoIGtmiyIVNV789Ztur1bH7Cd0uuxIc+RE uNmQ== X-Gm-Message-State: ALQs6tA4FpNIZCj8y4lBPdruiCzOw1KCgrkenbUtRXO4Yr/kU4LZwx3K cKAaSxz3sLDkVksEh5sfPeqDQ7Kdls8nQLW6ytY= X-Google-Smtp-Source: AIpwx4+Ov+NDkEnFFz3kyUU3iNX1RRM2ZkI6A6xazet04RcddlKDj8q/UGAopCWdasyYQSQ4LmBOdRpe1AP1nygzXPk= X-Received: by 2002:a9d:29ea:: with SMTP id g39-v6mr7483648otd.241.1522730964400; Mon, 02 Apr 2018 21:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 2 Apr 2018 21:49:23 -0700 (PDT) In-Reply-To: <152234574960.9148.17418629394530547618.idtracker@ietfa.amsl.com> References: <152234574960.9148.17418629394530547618.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 3 Apr 2018 14:49:23 +1000 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-record-limit-02=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:49:26 -0000 I responded to Spencer regarding the nit. On Fri, Mar 30, 2018 at 4:49 AM, Mirja K=C3=BChlewind = wrote: > One minor comment the title of sec 5: not sure if "deprecating" is the be= st > word as that maybe be read as "moved to historic" in IETF world... For this, until we move all of RFC 6066 to historic/historical, I think that deprecating is clear enough. From nobody Mon Apr 2 21:55:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108B912D890 for ; Mon, 2 Apr 2018 21:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CO_NU8ZRPran for ; Mon, 2 Apr 2018 21:54:57 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83EF12D86D for ; Mon, 2 Apr 2018 21:54:54 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id s24-v6so7308148plq.6 for ; Mon, 02 Apr 2018 21:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1YPSJObEW1jSFrcksDW7iPm/Gcjvz8loD/awnl5r6h0=; b=IE0M08QBescXjBeH7AcSdVLNKY3Jw06h3tsli5Ox5w+HYEfp0fAemZdtkvlAiz1WBO teWTJa7gUXt+zWr6EW8AYSucXmKpxXHQxcp1Ijfz787dcFvSEQm7iC3Cr3D9bhv08H+e FOhbTygD/Fz7inhz18la2lns7vtQfCEeH1Sf4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1YPSJObEW1jSFrcksDW7iPm/Gcjvz8loD/awnl5r6h0=; b=GxtH99JnNgLPbyqQETbonNH9aNyAeAfGdQpr4kuKwWXqCrUzXt9pDh5DFefW7lcWHP XC6qTKzHtnxBHy90G3P6y0tJjvnz0DKT/45EsI/OBGnvht6oQM5nnA6NSRPb9e+0H6qi aRhyeL/MpuyM9x9/HSgLk/3UqkGg+ZcSuym/tmS86LfuIfuhPo4qnezFNVI+cogKodNQ 2PtoR8SjpPuwpSZjtAfM+D9O9HbjBLsrrx1+bXPbp1l9G+voRYJ1ddxs+mW/Tta8js8V yFiSXiAqnaaMFOUjPwMZ5fBU/J5NsX82Vx1ZDb7WWdlIBF5PEnaCambyeCWhl82/yV1a mirw== X-Gm-Message-State: AElRT7F2zT9UefQTOZLiDhSZMz1ydpVOtusWnEjcSOYF+/wzir+njWE4 fy12L1K7NkGmNJ7T/GTC4xZHmA== X-Google-Smtp-Source: AIpwx4/nuIeDD037wwOxlQAbgmibIr/SzDHZPWfm8kYovpBJJxk/nx/MXCLJNFhlVTPvh3aHRf6xcA== X-Received: by 2002:a17:902:b60c:: with SMTP id b12-v6mr12647167pls.203.1522731294557; Mon, 02 Apr 2018 21:54:54 -0700 (PDT) Received: from [5.5.33.142] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id l80sm3353115pfk.73.2018.04.02.21.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 21:54:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <152270040046.28413.18197119614911305289.idtracker@ietfa.amsl.com> Date: Mon, 2 Apr 2018 23:54:45 -0500 Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152270040046.28413.18197119614911305289.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Warren Kumari's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:54:59 -0000 > On Apr 2, 2018, at 15:20, Warren Kumari wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-04: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'd suggest that the authors review the OpsDir review: > = https://datatracker.ietf.org/doc/review-ietf-tls-iana-registry-updates-04-= opsdir-lc-romascanu-2018-02-20/ >=20 > I especially agree with #1 ("It would be useful from an operator = perspective to > add to the registries where the Recommended column is added a text = similar to > the one in Section 6,=E2=80=A6") I submitted a PR to address this: = https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62/file= s I=E2=80=99ll merge in a bit. > I'm guessing it is not needed, but should there be a note to the RFC = editor to > fix the "IANA [SHALL prepend/has prepended]..." bit to "IANA has = prepended..." > throughout? 'tis probably obvious enough, but I figured worth asking. Yeah I figure we can do this during the AUTH48 stage ;) > The Nits Checker grumps about missing Updates in the Abstract -- I was = getting > ready to fuss about this, and then found "This document updates many = (D)TLS > RFCs (see updates header)." - this seems like a fine hack to me. Glad you liked the hack! spt= From nobody Tue Apr 3 07:31:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2A128954; Tue, 3 Apr 2018 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=GkD+bmvP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nL2eJQxy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMs_b_xkohs7; Tue, 3 Apr 2018 07:30:57 -0700 (PDT) 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 668BD1271DF; Tue, 3 Apr 2018 07:30:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9F492215F7; Tue, 3 Apr 2018 10:30:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 03 Apr 2018 10:30:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=oNjBAuxrXk29AO2XcXZe9gV9xKEFM a8iMrax1S3J5R8=; b=GkD+bmvPC53C5vFSQn5ZvRNDhopOd7EzDUm5MM2Tw1ZGH rB5jSYMiAX6pp+MGrD9bBLvAbkUzoEmHoHlt6H4BEjbWoMzmG8aac5663N2WUj8z 4t4frpTvTq2b4usuwGeF4Zmq7cqtTOV9yFjpRK5PuQtCxVymUJhb+Vd8x2VtVwn5 pYTU4LRUGvcXWYQu2Ml/D2IroYIP4G38K4/dSjXqWcqxyrz8tIqtPq8qOAy2YpKM mBjPAACad2xdAZ5HHXCmp1USymJtVffy1nGylNK0QD6G74//CrsicranZVvXh8Hf 8EWEeNadqKOOpqHBDRQQr62QQ/v0xJwo9HIWA6f8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=oNjBAu xrXk29AO2XcXZe9gV9xKEFMa8iMrax1S3J5R8=; b=nL2eJQxyu8P2gZimi46Dh3 thf4ZoWC10QOEJ+9gEwwNPrU1j25pmDVGy0sPtT0Rlz6IF/HVeka8QgmNinRxqzE 6xRkBf/rh6b8Mw9+uFVz6xySPSd09mfBF/rUU4L+8q4gy3Tc5/jr9USslMSar3XL czEh5KdSmQTgWEOxcwHs7gcY1k8COEv69x+dkAdoFHquKAr+OOA0WoIhnEvTQ7uo aZ/CkqbP6IF28YDicBx7FgzWb4AWKyIWSQBIZr346kz90WaX6nLeNv9baUiROcPT /yUd2w+3LIwsR2HJ1I7GQVDiBlDfz5Fp9GtbwNGtd9QWF061ja0YFWPidnst4rvw == X-ME-Sender: Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FF84E4437; Tue, 3 Apr 2018 10:30:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <0EF565D9-C1F4-480A-9D01-8BAEB616736E@sn3rd.com> Date: Tue, 3 Apr 2018 10:30:55 -0400 Cc: Russ Housley , IETF Gen-ART , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <0AF5DCA7-7DD2-4B10-BB3D-05AA0276A2C5@cooperw.in> References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <0EF565D9-C1F4-480A-9D01-8BAEB616736E@sn3rd.com> To: Sean Turner , Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 14:31:04 -0000 Stewart, thanks for your review. Sean, thanks for the updates. I have = entered a No Objection ballot. Alissa > On Feb 27, 2018, at 2:22 PM, Sean Turner wrote: >=20 >=20 >=20 >> On Feb 27, 2018, at 11:21, Russ Housley wrote: >>=20 >>=20 >>>> Minor issues: >>>>=20 >>>> I think convention is to list the documents being updated in the = Abstract, but >>>> cannot find any formal guidance. >>>=20 >>> You=E2=80=99re right that is the convention, but it=E2=80=99s not = required. draft-flanagan-7322bis is attempting to make including = updates in the abstract a must, but it=E2=80=99s not been through any = kind of LC yet. There is a sentence there saying that a lot of RFCs are = updated and to see the updates header so I think under the 7322 to = balance concise and to not include references I=E2=80=99m thinking this = is okay. >>>=20 >>=20 >> If another update top the document is needed, then it does not seem = hard to comply with the coming convention. >=20 > Just an FYI I plan to object to the coming convention :) >=20 >> =3D=3D=3D=3D=3D=3D >>>>=20 >>>> If an item is marked as not recommended it does not necessarily = mean >>>> SB> Do you mean "marked as not recommended" or "not marked as = recommended=E2=80=9D. >>>=20 >>> There are two states for the Recommended column: YES and NO. I can = go either way on whether >>> marked as not recommended =3D NO >>> not marked as recommended =3D NO >>>=20 >>> WG - thoughts? >>=20 >> I think the second wording is more clear. >=20 > fixed >=20 >>>> =3D=3D=3D=3D=3D=3D=3D >>>> SB> I am worried about the semantics of Recommended =3D no. >>>> SB> Presumably there are three states: recommended, not = recommended, >>>> SB> and silent/don't know/don't care/not yet. Which of these >>>> SB> states does Recommended =3D no represent? >>>=20 >>> There are two states and a draft that specifies a value in a = registry that has a Recommended column needs to state which it is. = I=E2=80=99m not too concerned because we can change the column value = later if it turns out a NO should have been a YES. >>=20 >> It would be more clear is Section 6 said that each parameter will = have either "yes" or "no" in the new recommended column. >=20 > Can do: >=20 > OLD: >=20 > The instructions in this document add a Recommended column to many of = the > TLS registries >=20 > NEW: >=20 > The instructions in this document add a Recommended column with a = value > of YES or NO to many of the (D)TLS registries >=20 > PR: = https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Apr 3 09:56:23 2018 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 75D63126BFD; Tue, 3 Apr 2018 09:56:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152277457647.22702.669514304265362603.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 09:56:16 -0700 Archived-At: Subject: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 16:56:17 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tls-iana-registry-updates-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-iana-registry-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the idea behind this document. I have a few minor issues which I would like to discuss before recommending its approval: 1) In several places: "IESG action is REQUIRED for a Yes->No transition." Firstly, this should be "IESG Approval", not "IESG action" (according to RFC 8126). Secondly, are you saying that this is the ONLY way to transition from Yes to No? Surely, Standards Action should also be allowed in case there is no rush? Besides IESG is likely to prefer a document explaining the transition anyway. 2) In Section 15: 15. TLS Certificate Types Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict. Based on WG consensus, the decision was taken to change registration policy to Specification Required [RFC8126] while reserving a small part of the code space for experimental and private use. Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry. X.509 and Raw Public Key are "Yes". All others are "No". In order to register an extension with the value "Yes", a Standards Track document [RFC8126] is REQUIRED. The above sentence. Future Certificate Types MUST define the value of this column. A Standards Track document [RFC8126] is REQUIRED to register an entry with the value "Yes". And this is just repeating the above sentence in a different way. IESG action is REQUIRED for a Yes->No transition. 3) In Section 17: Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still import to warn implementers of import --> important pre-TLS1.3 implementations about the dangers of blinding implementing blinding --> blindly cryptographic algorithms. And later in the same section: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed cipher suites --> hash functions/signatures? here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. From nobody Tue Apr 3 14:50:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB7C12D87B; Tue, 3 Apr 2018 14:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shbho3B7iLWz; Tue, 3 Apr 2018 14:50:31 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 B5B31126C2F; Tue, 3 Apr 2018 14:50:30 -0700 (PDT) X-AuditID: 1209190e-8c7ff700000025c5-aa-5ac3f725f1d8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 74.14.09669.527F3CA5; Tue, 3 Apr 2018 17:50:29 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w33LoS62020661; Tue, 3 Apr 2018 17:50:28 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w33LoNgw023129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Apr 2018 17:50:26 -0400 Date: Tue, 3 Apr 2018 16:50:24 -0500 From: Benjamin Kaduk To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, tls@ietf.org, tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie Message-ID: <20180403215023.GP80088@mit.edu> References: <152277457647.22702.669514304265362603.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152277457647.22702.669514304265362603.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hTV1lX9fjjK4N5NPYv97w8xWdw9u4jV YsaficwW0/deY7eYc+IGi8Wn812MDmwea7uvsnnsPHWAzWPJkp9MAcxRXDYpqTmZZalF+nYJ XBnd75azF7wUrGjqvM3UwLifr4uRk0NCwETi/bK/bF2MXBxCAouZJNbtvcgE4WxglDjzeD2U c4ZJ4vLWRSwgLSwCKhI31y5nB7HZgOyG7svMILaIgI7EscMvwRqYBSYxSpy7/p0JJCEskCGx cOZ5sCJeoKIrB3pZQWwhAR+Jg1+eQMUFJU7OfAK2gFlAS+LGP5BBHEC2tMTyfxwgYU4BX4mj Zx6CjRQVUJbY23eIfQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gv N7NELzWldBMjOLQl+XYwTmrwPsQowMGoxMO7YtHhKCHWxLLiytxDjJIcTEqivLovgEJ8Sfkp lRmJxRnxRaU5qcWHGCU4mJVEeBU2A+V4UxIrq1KL8mFS0hwsSuK8i/bvjRISSE8sSc1OTS1I LYLJynBwKEnwSn4DahQsSk1PrUjLzClBSDNxcIIM5wEaLgVSw1tckJhbnJkOkT/FqCglzuv0 FSghAJLIKM2D6wWlHons/TWvGMWBXhHmjQBp5wGmLbjuV0CDmYAG2+cdABlckoiQkmpgtGcP 005+vD06R0ntYNeFYIs2xyId4S8zM92yAzwPtzgJ8b+3bZyzuP/1pq8nZxUEqq28M2fv8Rkn J4osF0q6Vnxu2VYDoamay79G/7v06GR9XXDMb7FI3xW8S+pShIOU+KpezPx1+XXg/eSf5w60 JU75ffDtJ975lX7aGrnv9BY/01mxXG3KEiWW4oxEQy3mouJEAON/0HgYAwAA Archived-At: Subject: Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:50:37 -0000 I will trim the purely editorial stuff, as the authors should be able to handle that (and have already started, since the cipher suite/hash+signature algorithm thing was already noted). On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-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-iana-registry-updates/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support the idea behind this document. I have a few minor issues which I > would like to discuss before recommending its approval: > > 1) In several places: > > "IESG action is REQUIRED for a Yes->No transition." > > Firstly, this should be "IESG Approval", not "IESG action" (according to RFC > 8126). Sure, let's use the right term. > Secondly, are you saying that this is the ONLY way to transition from Yes to > No? Surely, Standards Action should also be allowed in case there is no rush? > Besides IESG is likely to prefer a document explaining the transition anyway. Is IESG Approval mutaully exclusive with Standards-Action? My reading of 8126's: New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has the discretion to request documents or other supporting materials on a case-by-case basis. is that a standards-track document could include an "IESG Considerations" section that requests the IESG to effect the transition. That is to say, while I have no objection to your proposed (idea for) text, I also am not sure that it is qualitatively different from the current text. -Benjamin From nobody Tue Apr 3 21:09:29 2018 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 2311712DA18; Tue, 3 Apr 2018 21:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 21:09:21 -0700 Archived-At: Subject: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:09:24 -0000 Adam Roach has entered the following ballot position for draft-ietf-tls-iana-registry-updates-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone put in on this document. I have a handful of comments, ranging from nits to minor issues. They appear in document order. --------------------------------------------------------------------------- Title: Please expand "TLS" and "DTLS" in the title. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. --------------------------------------------------------------------------- Abstract: Please include the list of updated RFCs in the abstract. See §3.1.D. The current formulation of "This document updates many (D)TLS RFCs (see updates header)" is problematic due to the factors described in the final paragraph of RFC 7322 §4.3. --------------------------------------------------------------------------- §2: > Instead of listing the changes and their rationale in this, > the introductory, section each section provides rationale for the > proposed change(s). There's something awkward with the commas here. Perhaps you mean: > Instead of listing the changes and their rationale in this, > the introductory section, each section provides rationale for the > proposed change(s). --------------------------------------------------------------------------- §8: This section doesn't indicate anything about the disposition of "token_binding," which is due to (potentially) expire in 11 months. Given that the temporary property of this registration is due only to the previous policy that this document is obsoleting, it seems that this document should instruct IANA to remove the temporary status from the "token_binding" TLS ExtensionType. --------------------------------------------------------------------------- §8: The table that adds a "Recommended" column to the TLS ExtensionType does not indicate values for "token_binding" or "cached_info." I suggest either adding them, or adding text to explain their omission. --------------------------------------------------------------------------- §9: > assigned via Specification Required {{RFC8126}}. Values with the > first byte 255 (decimal) are reserved for Private Use {{RFC8126}}. Nit: the "{{...}}" citation style is probably not what you intended. --------------------------------------------------------------------------- §13: > o A "Recommended" column to the TLS Exporter Label registry. The > table that follows has been generated by marking Standards Track > RFCs as "Yes" and all others as "No". No rows are marked "No." Presumably, the text above should instead say "any values not indicated in the table below [will be/have been] marked 'No'" --------------------------------------------------------------------------- §14: > 120 no_application_protocol Y [RFC7301] Every other updated table is amended to also point to this document. I presume that omitting it from this entry is an oversight, and that it should instead be: > 120 no_application_protocol Y [RFC7301] [RFCthis] --------------------------------------------------------------------------- §17: > o [SHALL update/has updated] the TLS HashAlgorithm Registry to list > values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry > to list values 4-223 as "Reserved". HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8. Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223", respectively. --------------------------------------------------------------------------- §17: > Despite the fact that the HashAlgorithm and SignatureAlgorithm > registries are orphaned, it is still import to warn implementers of nit: "important" > pre-TLS1.3 implementations about the dangers of blinding implementing nit: "blindly" From nobody Tue Apr 3 22:58:43 2018 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 CF707124D6C; Tue, 3 Apr 2018 22:58:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152282152084.23972.5999986320638189748.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 22:58:40 -0700 Archived-At: Subject: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 05:58:41 -0000 Adam Roach has entered the following ballot position for draft-ietf-tls-record-limit-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who contributed work towards this document. --------------------------------------------------------------------------- §4: > MUST NOT send a value higher than the protocol-defined maximum record > size unless explicitly allowed by such a future version or extension. Presumably, recipients MUST gracefully accept values higher than the maximum record size? That is implied by this text (and the text that follows), but given how TLS frequently aborts connections at the first sign of any irregularity, it's probably worth saying explicitly. --------------------------------------------------------------------------- §4: > a DTLS endpoint that > receives a record larger than its advertised limit MAY either > generate a fatal "record_overflow" alert or discard the record. I'm concerned about the interaction between the option to discard the record and protocols that perform retransmission of lost packets over DTLS (e.g., proposals such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is simply discarded, retransmissions of that (presumably still oversized) packet will take a while to time out (I'm not particularly well-versed in QUIC, but assume it has characteristics similar to TCP's ~nine-minute timeout), which would result in really bad user experiences. Is there rationale for this optionality? It would seem to be cleaner if the response were simply to always send a fatal error. If this optionality is retained, please at least consider adding text describing the impact of discarding oversized packets when used with a reliable protocol. --------------------------------------------------------------------------- §4.1: > In TLS 1.2, block ciphers allow between 1 and 256 octets of padding. nit: The formulation "between X and Y" is ambiguous as to whether X and Y are included in the range. Consider rephrasing as "...from 1 to 256...". From nobody Tue Apr 3 23:44:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A7F126CC4; Tue, 3 Apr 2018 23:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR9G9MoeDILx; Tue, 3 Apr 2018 23:44:37 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A4124B17; Tue, 3 Apr 2018 23:44:37 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id o9-v6so22188299otj.5; Tue, 03 Apr 2018 23:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1zyJRX6sGnf29H5aZ8sjtf2n4tbW766VKCvoS0rBBFo=; b=e1UjWNtR/rN+DV5yW47err3YwCgG619GdgTeI5RDQiEV7OR4NwUcv0tJmTHnyJygpt Ebd9GcsuDKN2EfbQX/n4cZt7x11goDQmjTGTLMdFF+1Cd4LbynhNuaqvGz62svjJAmxN S8u+5H59J8sq5BoNYbBF3DWTU6FPWDj945oAIFynwxYzvKoXKUeS/D+o3zchR1qINO7U Aj8kH2xpw2ejcwO6nd+JlZ0z5KGc0gr90xk7lLTk4TcrofuinnAQBYaXp4ZUGykn5Ykx dqF903TMzzRfYvsV5K3an3PJCCPAq2LlsCC80xWJ2bD3935NGQcio1tDSCK6yg5Ddw1W s5Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1zyJRX6sGnf29H5aZ8sjtf2n4tbW766VKCvoS0rBBFo=; b=fy6lJoIMpYgEXBrOAuSSg+UfBYNopG5Yh0bFQnw1aPmh+UMhu+ss7LtOr4ljevAy9i LJZ14zoYXU2cRMXZ4O5LagX2pFp9t/8rutnwqJ38/nv83gen21zW8WDPbSfAoov6EZy9 u86ti4QMBEUr/+6TKXAjKfmsBe2lA4gUW1x5FzgtSedVtbP0v9sDvIVuIA8hzX6z6U3K eRC7QCkeW/rBkOBqIWrLLi5IXNGTGrs99f9SwbQRe38PV0tKwMT+mT0doy+v8QslBk+C XYrNeHUV727ntmVrE5LX/k1TQV75Ui8C/ffF1l7ipUmSt0gjMdGBhCRMRZRpPlhvOPfW g1xw== X-Gm-Message-State: ALQs6tBU+kXMhlZFmFpVIX7e0HxGbPDTfcMgAMkFXJYTFz7wSqOx3OW5 NHffmbGeZFfU9rJr77PyT+x59RT3QNTMKx0y4u0iLv0g X-Google-Smtp-Source: AIpwx4856qpO9jrhQ0lEUjLsC/S5Dn3mvyhL55w05cJmj8Wmls/KVi4ffZ+GMkQFCRSL/Tj0p/pRuOkL2vklLHbuIgc= X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr1638754ota.392.1522824276882; Tue, 03 Apr 2018 23:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 23:44:36 -0700 (PDT) In-Reply-To: <152282152084.23972.5999986320638189748.idtracker@ietfa.amsl.com> References: <152282152084.23972.5999986320638189748.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 4 Apr 2018 16:44:36 +1000 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 06:44:40 -0000 Hi Adam, Thanks for the review. You picked up on something that was a little sloppy there. PR: https://github.com/tlswg/tls-record-limit/pull/19 On Wed, Apr 4, 2018 at 3:58 PM, Adam Roach wrote:> Adam Roach has entered the following ballot position for > =C2=A74: > >> MUST NOT send a value higher than the protocol-defined maximum record >> size unless explicitly allowed by such a future version or extension. > > Presumably, recipients MUST gracefully accept values higher than the maxi= mum > record size? That is implied by this text (and the text that follows), b= ut > given how TLS frequently aborts connections at the first sign of any > irregularity, it's probably worth saying explicitly. I thought that the following text was doing precisely that: > A server MUST NOT enforce this restriction; a client might advertise a hi= gher limit that is enabled by an extension or version the server does not u= nderstand. A client can enforce the restriction, because it knows the entire set of possible extensions that determine the maximum size. I'll concede that it's a little sloppy in that it doesn't explicitly say whether a client is expected to police the value. Is that a change you would like to see? As in: > A client MAY abort the handshake with an illegal_parameter alert if the r= ecord_size_limit extension includes a value greater than the maximum record= size permitted by the negotiated protocol version and extensions. Note that this wasn't made a MUST because if there is an extension that raises the limit, the client has to do a second pass over the extensions and that's awkward. > =C2=A74: > >> a DTLS endpoint that >> receives a record larger than its advertised limit MAY either >> generate a fatal "record_overflow" alert or discard the record. > > I'm concerned about the interaction between the option to discard the rec= ord and > protocols that perform retransmission of lost packets over DTLS (e.g., pr= oposals > such as draft-rescorla-quic-over-dtls). In the case that an oversized pac= ket is > simply discarded, retransmissions of that (presumably still oversized) pa= cket > will take a while to time out (I'm not particularly well-versed in QUIC, = but > assume it has characteristics similar to TCP's ~nine-minute timeout), whi= ch > would result in really bad user experiences. Is there rationale for this= optionality? > It would seem to be cleaner if the response were simply to always send a = fatal > error. The problem is that you only want to abort if you decrypt the record. DTLS doesn't kill connections if it receives junk. In this case, you would only want to kill the connection if the record is authentic. But if you have a record size limit, it's usually because you don't want to decrypt big records. So you probably won't bother even trying to decrypt the big packet, even if you could. So yes, discard ends up looking like packet loss, akin to the loss you get when a path doesn't support the MTU. Except that you don't have any hope of receiving feedback (inasmuch as ICMP is available to DTLS anyway...). Given that it's a protocol error, I'm not all that enthusiastic about fixing the problem. Even writing it down seems wrong. "If an endpoint violates its negotiated constraints, then it can induce denial of service on itself." There's only so much defensive design we can build in. FWIW, QUIC has the exact same mechanism built in, but you don't retransmit packets verbatim, so it could rectify itself if it was a one-off. More likely, it would compound when more outstanding data is available to send in every subsequent packet, perpetuating the use of over-large packets. From nobody Wed Apr 4 00:44:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9C1270AC; Wed, 4 Apr 2018 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMPBMnhaLR07; Wed, 4 Apr 2018 00:44:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 6E342126BF3; Wed, 4 Apr 2018 00:44:26 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w347iMap026033 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 02:44:23 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Martin Thomson Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" References: <152282152084.23972.5999986320638189748.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <5005fa90-021c-f947-baac-27b86a1acba4@nostrum.com> Date: Wed, 4 Apr 2018 02:44:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 07:44:32 -0000 On 4/4/18 1:44 AM, Martin Thomson wrote: > Hi Adam, > > Thanks for the review. You picked up on something that was a little > sloppy there. > > PR: https://github.com/tlswg/tls-record-limit/pull/19 > > On Wed, Apr 4, 2018 at 3:58 PM, Adam Roach wrote:> > Adam Roach has entered the following ballot position for >> §4: >> >>> MUST NOT send a value higher than the protocol-defined maximum record >>> size unless explicitly allowed by such a future version or extension. >> Presumably, recipients MUST gracefully accept values higher than the maximum >> record size? That is implied by this text (and the text that follows), but >> given how TLS frequently aborts connections at the first sign of any >> irregularity, it's probably worth saying explicitly. > I thought that the following text was doing precisely that: > >> A server MUST NOT enforce this restriction; a client might advertise a higher limit that is enabled by an extension or version the server does not understand. It would, if it were present. The IESG is reviewing version -02 of the document, in which that text does not appear. (I see it's in your repo, so presumably the -03 version will address the issue I highlight). > A client can enforce the restriction, because it knows the entire set > of possible extensions that determine the maximum size. I'll concede > that it's a little sloppy in that it doesn't explicitly say whether a > client is expected to police the value. Is that a change you would > like to see? As in: > >> A client MAY abort the handshake with an illegal_parameter alert if the record_size_limit extension includes a value greater than the maximum record size permitted by the negotiated protocol version and extensions. > Note that this wasn't made a MUST because if there is an extension > that raises the limit, the client has to do a second pass over the > extensions and that's awkward. I'm okay both with and without the change. What I really wanted was text equivalent to what you quote above. > >> §4: >> >>> a DTLS endpoint that >>> receives a record larger than its advertised limit MAY either >>> generate a fatal "record_overflow" alert or discard the record. >> I'm concerned about the interaction between the option to discard the record and >> protocols that perform retransmission of lost packets over DTLS (e.g., proposals >> such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is >> simply discarded, retransmissions of that (presumably still oversized) packet >> will take a while to time out (I'm not particularly well-versed in QUIC, but >> assume it has characteristics similar to TCP's ~nine-minute timeout), which >> would result in really bad user experiences. Is there rationale for this optionality? >> It would seem to be cleaner if the response were simply to always send a fatal >> error. > The problem is that you only want to abort if you decrypt the record. > DTLS doesn't kill connections if it receives junk. Ah, okay. That makes perfect sense. Under such circumstances, I agree that dropping such packets seems to be the least bad path. No document change is necessary, although I wouldn't object if you added an explanation to the document that says exactly what you say above. /a From nobody Wed Apr 4 01:19:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04902124205; Wed, 4 Apr 2018 01:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OebyQA_wvUPO; Wed, 4 Apr 2018 01:19:28 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471B21201FA; Wed, 4 Apr 2018 01:19:28 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id e123-v6so18453134oih.13; Wed, 04 Apr 2018 01:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LPmLZPQ1a7wvybIRWQGqFzYjhKg2b5vjrD+eEJwEo5U=; b=cGxQkZsok5QbveTltKtM9DEvCZ09ac2LGcNKHoOAkSmSzryDbq6qwpLw3TyC0W4pU3 2Jtrs37/Ehhax45oPmwQUeRtSotg+Qc2GR6PwT/87phB/CrrTYjrVBSuHJoPz2FBjDND wmk9iR1UOf8/UHeUTPCBcvl/c6Kg2VL4nRs+9wiGe3qmHlhRxU/070bqTKUgyNoyWQ7W ssnPzHuOo9CHfIMd/ymlMSTPcStDkMN5zgiBgD4cCjY/jL9r8IeYAizmOstxVj6HxqK3 A+g7ZxQ1CalUDM035cdf0Be45KsLXjvfm66dmQpSV44PpfhtwHK0T5aU9yT4y8SZLqdM 4vSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LPmLZPQ1a7wvybIRWQGqFzYjhKg2b5vjrD+eEJwEo5U=; b=AjHdQpFAwDSD8pp/bisWqtINfcu6dVQW9zzmUZDrd5V2uYLQQp5AJcHzzh9hqx4mFr NnHCNDwb2izieM4CnCkgZKMCWi5IVBX3rtyrWJTDjRqKJOukzlYeyBvFgKldSN8SY9lv e6vYTK7H7LOR4D9Dp3y77v7gZ/sSDMj2Qt8tmHk3VtECtEzUOLlb5unevzURTyFyNIGd IxJzgQJhuiqdY+vOPlNfINN62jQb9fmMO67Qf+w/BfL+X5vjPgahAFHB8EmiBCjbi3UC cQnB1u2uUoAboYqF9twU7U2icbosO9w75wvxbZhhCACQXs1eD3Fqta5hA7AVpczuf2Tu n1QA== X-Gm-Message-State: ALQs6tAyLMysuWils3yB7co0yrpomPUPb7z7GCCRChAmWR7sJjpIFIYW MHdwnsgYeOzanO1bMq7Z3NmJG3GbdY8natvhCpqrlA== X-Google-Smtp-Source: AIpwx49r7RkAAhZxMj5ryi2N5AkpegsIjplnDEcM80QK5CHA5u0+vHrrKNWZf7q59qeGUNd50Z9cudSPvjE9j9sEoZM= X-Received: by 2002:aca:4ac2:: with SMTP id x185-v6mr8809658oia.295.1522829967563; Wed, 04 Apr 2018 01:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 01:19:27 -0700 (PDT) In-Reply-To: <5005fa90-021c-f947-baac-27b86a1acba4@nostrum.com> References: <152282152084.23972.5999986320638189748.idtracker@ietfa.amsl.com> <5005fa90-021c-f947-baac-27b86a1acba4@nostrum.com> From: Martin Thomson Date: Wed, 4 Apr 2018 18:19:27 +1000 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 08:19:30 -0000 On Wed, Apr 4, 2018 at 5:44 PM, Adam Roach wrote: >>> A server MUST NOT enforce this restriction; a client might advertise a >>> higher limit that is enabled by an extension or version the server does not >>> understand. > > It would, if it were present. The IESG is reviewing version -02 of the > document, in which that text does not appear. (I see it's in your repo, so > presumably the -03 version will address the issue I highlight). My fault. Sean prompted me to push out a new version, then IESG reviews started coming in, so I held back. That was the result of a secdir review. From nobody Wed Apr 4 01:59:56 2018 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 4EEA2126BF3; Wed, 4 Apr 2018 01:59:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152283239031.23912.11881905598705882976.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 01:59:50 -0700 Archived-At: Subject: [TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-record-limit-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 08:59:50 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-tls-record-limit-02: 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-record-limit/ There are no remarks associated with this position. From nobody Wed Apr 4 04:21:45 2018 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 2AE791270B4; Wed, 4 Apr 2018 04:21:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152284090016.23908.302744975919228304.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 04:21:40 -0700 Archived-At: Subject: [TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 11:21:40 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-tls-iana-registry-updates-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-iana-registry-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- s/aligment/alignment s/prviate/private From nobody Wed Apr 4 05:43:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1790812741D for ; Wed, 4 Apr 2018 05:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qsO9SpuHEuI for ; Wed, 4 Apr 2018 05:43:34 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC79C120726 for ; Wed, 4 Apr 2018 05:43:33 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 093D5EBFFC; Wed, 4 Apr 2018 12:43:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3708F84424; Wed, 4 Apr 2018 12:43:31 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Apr 2018 14:43:23 +0200 Message-ID: <1727401.ncI4dqslgy@pintsize.usersys.redhat.com> In-Reply-To: References: <1521920255951.94271@s21sec.com> <20180328231713.6B3D9409B@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1651044.NGUcdvbub2"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Apr 2018 12:43:33 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Apr 2018 12:43:33 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 12:43:37 -0000 --nextPart1651044.NGUcdvbub2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote: > Hi Martin >=20 > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex > > Sent: Thursday, March 29, 2018 4:47 AM > > To: Steve Fenter > > Cc: tls@ietf.org > > Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't= do > > it)>=20 > > Steve Fenter wrote: > > > To clarify for anyone who has confusion on the enterprise TLS > > > visibility use case, I think enterprises need to be able to do > > > out-of-band decryption anywhere in the network that they own. > >=20 > > This is argument is so lame. > >=20 > > In Germany, monitoring communications between individuals or between > > individuals and legal entities, including communications over corporate > > networks, was made a serious crime in 2004 (TKG 2004) with a penalty of= up > > to 5 years in prison for listening into such communication. > >=20 > > The world didn't end. Really, consider it proven that there is no need. >=20 > Could monitoring could be legally done if user provided his consent at the > time of login into enterprise managed terminal? > I guess that's the case in enterprise managed networks. No, even then the employer needs to establish a concrete case for inspectio= n=20 of the communications of an employee. Employer also must not continue inspection of an email as soon as it has=20 noticed that it is part of a private message. https://www.lexology.com/library/detail.aspx?g=3Df946064a-05d0-4603-ace9-38= 46b1c7536d and this is true, to a large degree, for the whole of EU: https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-= employer-had-privacy-breached-court-rules =46rom the ECHR ruling: "An employer[...] cannot reduce private social life in the workplace to zer= o.=20 Respect for private life and for the privacy of correspondence continues to= =20 exist, even if these may be restricted in so far as necessary." > > There may be _desires_. For me, those desires are no less unethical as > > data collections by apple, camebridge analytica, facebook, google, > > microsoft, whathaveyou... > >=20 > > .... and fortunately, for corporations in germany, such data gathering = is > > not just unethical, but truely criminal by law. > >=20 > >=20 > > -Martin > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > > w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7Cvakul.garg%40n > > xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9 > > 2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=3Dsa3hcM4C94 > > %2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=3D0 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1651044.NGUcdvbub2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlrEyGsACgkQkqjRuAHS 9fUejg//SWxt6w3Z2y0jXJFSd/OFgI8FI84aAr31LOJxR4IxNedg4s0WJJinrpu3 30hGrchEQXEh3USvjOiNG1rbR9rtYViPb2/ma3+WCfEatdQx8EFsPuvJcAuyVRUC /qVNgiw1ewkYmD5LLyfWaBTApf+14xKX27hOZYmnLOW0eDxIbObWbCc6OBAtfOXV Q5GSjV08y4L/vErI9OKOrcZjhq6DOhSBedfQXdQjqPc44hDNIlaBnnIZFDQ4ENQT yWxDiTGzTwYP1mIJkPrxFv9vA4X7DZqF852wczwS9FP/K2Ry+T2N8WViriyTGCeZ 0P931ekvJ0BvNQjsuncO9+LvjIDHhU/aT5k2eCNhaMeBTdG1Tkx4yCvAh3gtANX5 9pRR6czuxmpDLk3mmr8PWrhL7vP2Ec9tC83yXE4lrDT5XRpN4nogBsZkfEvHHDeH bFmPka5yl1gA/RTaFrNHIujVy7sNsUM7fv7ojiM7d99gaW/oHjDa2TnLB4mmvXfA JrAP+iE2oNwagAM9lG1e1Yu8xyBZy1rntMNr+IMD9EDGTilN9pC59cUU65Xy378i hhH3RLE0aUJzFP/j4KFFJ5NmFTEieqw+z5acDLMtnf/Cak72vzrUAprqAX+rPLrY WWxQSCuoWTtC8xdKJOfTmMAZcaGdPPAizFJT9y4dwVR9o3IAFgA= =T6RM -----END PGP SIGNATURE----- --nextPart1651044.NGUcdvbub2-- From nobody Wed Apr 4 07:46:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F265112D94F for ; Wed, 4 Apr 2018 07:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0dZiv0sWhcR for ; Wed, 4 Apr 2018 07:46:40 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::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 F1E22124D37 for ; Wed, 4 Apr 2018 07:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1522853196; s=strato-dkim-0002; d=zinks.de; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=joOJkRWlzOzKqmjVY4A4oTuYmOr/1JzTSxDdveW+Y9c=; b=FkTp1AhhnaoHZR5W1iwFt7GBvslWhSE48fxqTboT4EC6X8gHevyQDCpvv516jnAIqP i4fLHsob2Y9dn1A61YpVemPrXcn6Y0DvjH0d/BL1fvR14/q9E2lbuzB5jRrCwa13nbFQ C+U2hWFMzmfJG8ft4UpW/FKvCkg6TqrrdFZr+fy+4RJdd74YYEt8S/8mhUpLLAnc+1tZ ZOqgWNgiA5aD0IQQ2v6AM09qYUWLPlYP36pKowXZ8xsOPH7kYaZ4mcPl0AqUwOdNVwjQ 6mi08gHuVbwLfBNVD4TSWy2xrfHUyZ6fMJzASmtUOYb48tRIhW3GBcK9aAU8Mi69NcgI sAeA== X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQIHae3Fs8= X-RZG-CLASS-ID: mo00 Received: from [10.33.22.7] (p54A6DFE8.dip0.t-ipconnect.de [84.166.223.232]) by smtp.strato.de (RZmta 43.1 DYNA|AUTH) with ESMTPSA id k07273u34EkaHle (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 4 Apr 2018 16:46:36 +0200 (CEST) To: tls@ietf.org References: <1521920255951.94271@s21sec.com> <20180328231713.6B3D9409B@ld9781.wdf.sap.corp> <1727401.ncI4dqslgy@pintsize.usersys.redhat.com> From: Roland Zink Message-ID: Date: Wed, 4 Apr 2018 16:46:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1727401.ncI4dqslgy@pintsize.usersys.redhat.com> Content-Type: multipart/alternative; boundary="------------9D717DE960A2E621CB64F131" Archived-At: Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 14:46:44 -0000 This is a multi-part message in MIME format. --------------9D717DE960A2E621CB64F131 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Am 04.04.2018 um 14:43 schrieb Hubert Kario: > On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote: >> Hi Martin >> >>> -----Original Message----- >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex >>> Sent: Thursday, March 29, 2018 4:47 AM >>> To: Steve Fenter >>> Cc: tls@ietf.org >>> Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do >>> it)> >>> Steve Fenter wrote: >>>> To clarify for anyone who has confusion on the enterprise TLS >>>> visibility use case, I think enterprises need to be able to do >>>> out-of-band decryption anywhere in the network that they own. >>> This is argument is so lame. >>> >>> In Germany, monitoring communications between individuals or between >>> individuals and legal entities, including communications over corporate >>> networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up >>> to 5 years in prison for listening into such communication. >>> >>> The world didn't end. Really, consider it proven that there is no need. >> Could monitoring could be legally done if user provided his consent at the >> time of login into enterprise managed terminal? >> I guess that's the case in enterprise managed networks. > No, even then the employer needs to establish a concrete case for inspection > of the communications of an employee. > Employer also must not continue inspection of an email as soon as it has > noticed that it is part of a private message. > > https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-3846b1c7536d > > and this is true, to a large degree, for the whole of EU: > https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-employer-had-privacy-breached-court-rules > > From the ECHR ruling: > "An employer[...] cannot reduce private social life in the workplace to zero. > Respect for private life and for the privacy of correspondence continues to > exist, even if these may be restricted in so far as necessary." This is true, but at the same time the employer is required in many countries including Germany to archive many emails and other relevant messages. See for example https://en.wikipedia.org/wiki/Email_archiving or https://www.intradyn.com/email-retention-laws/. This is often in conflict with the above mentioned laws, for an example see https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissions-documents-investigations. I don't think breaking TLS is the way to fulfill such requirements but I also think TLS connection to a company shouldn't end up at a third party providing hosting or CDN services. Regards, Roland > >>> There may be _desires_. For me, those desires are no less unethical as >>> data collections by apple, camebridge analytica, facebook, google, >>> microsoft, whathaveyou... >>> >>> .... and fortunately, for corporations in germany, such data gathering is >>> not just unethical, but truely criminal by law. >>> >>> >>> -Martin >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cvakul.garg%40n >>> xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9 >>> 2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=sa3hcM4C94 >>> %2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=0 >> _______________________________________________ >> 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 --------------9D717DE960A2E621CB64F131 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Am 04.04.2018 um 14:43 schrieb Hubert Kario:
On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:

Hi Martin


-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, March 29, 2018 4:47 AM
To: Steve Fenter <steven.fenter58@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do
it)> 
Steve Fenter <steven.fenter58@gmail.com> wrote:

To clarify for anyone who has confusion on the enterprise TLS
visibility use case, I think enterprises need to be able to do
out-of-band decryption anywhere in the network that they own.

This is argument is so lame.

In Germany, monitoring communications between individuals or between
individuals and legal entities, including communications over corporate
networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up
to 5 years in prison for listening into such communication.

The world didn't end.  Really, consider it proven that there is no need.

Could monitoring could be legally done if user provided his consent at the
time of login into enterprise managed terminal?
I guess that's the case in enterprise managed networks.

No, even then the employer needs to establish a concrete case for inspection 
of the communications of an employee.
Employer also must not continue inspection of an email as soon as it has 
noticed that it is part of a private message.

https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-3846b1c7536d

and this is true, to a large degree, for the whole of EU:
https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-employer-had-privacy-breached-court-rules

>From the ECHR ruling:
"An employer[...] cannot reduce private social life in the workplace to zero. 
Respect for private life and for the privacy of correspondence continues to 
exist, even if these may be restricted in so far as necessary."

This is true, but at the same time the employer is required in many countries including Germany to archive many emails and other relevant messages. See for example https://en.wikipedia.org/wiki/Email_archiving or https://www.intradyn.com/email-retention-laws/. This is often in conflict with the above mentioned laws, for an example see https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissions-documents-investigations.


I don't think breaking TLS is the way to fulfill such requirements but I also think TLS connection to a company shouldn't end up at a third party providing hosting or CDN services.


Regards,
Roland





There may be _desires_.  For me, those desires are no less unethical as
data collections by apple, camebridge analytica, facebook, google,
microsoft, whathaveyou...

.... and fortunately, for corporations in germany, such data gathering is
not just unethical, but truely criminal by law.


-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cvakul.garg%40n
xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9
2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=sa3hcM4C94
%2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=0

_______________________________________________
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

--------------9D717DE960A2E621CB64F131-- From nobody Wed Apr 4 08:36:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6812DA43; Wed, 4 Apr 2018 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3JAipu7c7YJ; Wed, 4 Apr 2018 08:36:04 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 D6AAA12DA2C; Wed, 4 Apr 2018 08:36:03 -0700 (PDT) X-AuditID: 12074423-e71ff70000002881-ff-5ac4f0e0330e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 13.36.10369.1E0F4CA5; Wed, 4 Apr 2018 11:36:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w34FZtLq020773; Wed, 4 Apr 2018 11:35:57 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w34FZoHC027342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Apr 2018 11:35:53 -0400 Date: Wed, 4 Apr 2018 10:35:50 -0500 From: Benjamin Kaduk To: Adam Roach Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, tls@ietf.org, tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie Message-ID: <20180404153547.GZ80088@mit.edu> References: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6novvow5Eogxt7+Sz2/F3EbnH37CJW ixl/JjJbTN97jd1izokbLBafzncxOrB5rO2+yuaxZMlPJo9ZO5+wBDBHcdmkpOZklqUW6dsl cGWsvNDNXnBGuOLOpI8sDYxzBLoYOTkkBEwkPvTfZ+xi5OIQEljMJPFo6gQWCGcDo8SjtRPZ IJwzTBKXr/xhB2lhEVCRmLr0IAuIzQZkN3RfZgaxRQQUJdoO32QGaWAWmMQoce76dyaQhLBA lMT3WdfYQGxeAR2JpkPtYM1CAj4Sk7oWsEDEBSVOznwCZjMD1ezcegeongPIlpZY/o8DIiwv 0bx1NtguTgFfiRUNV8DGiwooS+ztO8Q+gVFwFpJJs5BMmoUwaRaSSQsYWVYxyqbkVunmJmbm FKcm6xYnJ+blpRbpmunlZpbopaaUbmIEx4KL8g7Gl33ehxgFOBiVeHhXLjocJcSaWFZcmXuI UZKDSUmU98n9I1FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgfHAPK8aYkVlalFuXDpKQ5WJTE eRfv3xslJJCeWJKanZpakFoEk5Xh4FCS4FUFxryQYFFqempFWmZOCUKaiYMTZDgP0PAj70GG Fxck5hZnpkPkTzHqchy7PK2HWYglLz8vVUqc9xFIkQBIUUZpHtwcUAqTyN5f84pRHOgtYd6N IFU8wPQHN+kV0BImoCUTEsGWlCQipKQaGOVfif9b7dpgK/MuV3deqcSnX38KfexcTjHPDKxd I84rFOO81v+AieF3u1/y1m02TbU3pMw6zrRPTox8ss3922a3ntCDPzhmGD/VFJ313ymx/dxP gU26H6ft8M8wtpbY8PzbLut35wrYOWbcPTNtzqOZBVdCf2xX6HQS2uboNnuDYsFXzQl+05VY ijMSDbWYi4oTAXpj2Xs8AwAA Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 15:36:06 -0000 On Tue, Apr 03, 2018 at 09:09:21PM -0700, Adam Roach wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > --------------------------------------------------------------------------- > > Abstract: > > Please include the list of updated RFCs in the abstract. See > §3.1.D. The current formulation > of "This document updates many (D)TLS RFCs (see updates header)" is problematic > due to the factors described in the final paragraph of RFC 7322 §4.3. Would you be happy with just removing the "see updates header" bit? Because I do not see much wrong with the use of "updates many (D)TLS RFCs" in this case, which effects broad sweeping changes and for which listing the individually affected documents is not very helpful. > --------------------------------------------------------------------------- > > §8: > > This section doesn't indicate anything about the disposition of > "token_binding," which is due to (potentially) expire in 11 months. Given that > the temporary property of this registration is due only to the previous policy > that this document is obsoleting, it seems that this document should instruct > IANA to remove the temporary status from the "token_binding" TLS ExtensionType. good catch > --------------------------------------------------------------------------- > > §8: > > The table that adds a "Recommended" column to the TLS ExtensionType does not > indicate values for "token_binding" or "cached_info." I suggest either adding > them, or adding text to explain their omission. Yeah, trying to keep a document like this up-to-date is always exciting. I have confidence that the interaction between IANA and the authors will sort things out properly, though. > --------------------------------------------------------------------------- > > §17: > > > o [SHALL update/has updated] the TLS HashAlgorithm Registry to list > > values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry > > to list values 4-223 as "Reserved". > > HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8. > Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223", > respectively. This is already addressed in a pull request against the github repo. [some other uncontroversial nits trimmed] -Benjamin From nobody Wed Apr 4 09:37:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230F120724 for ; Wed, 4 Apr 2018 09:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyh5fFJ_tqL6 for ; Wed, 4 Apr 2018 09:37:12 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94312126D3F for ; Wed, 4 Apr 2018 09:37:12 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F3934023112; Wed, 4 Apr 2018 16:37:11 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.34.247.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 844CA10B2B51; Wed, 4 Apr 2018 16:37:10 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Apr 2018 18:37:03 +0200 Message-ID: <1715803.mF2QBD68G2@pintsize.usersys.redhat.com> In-Reply-To: References: <1521920255951.94271@s21sec.com> <1727401.ncI4dqslgy@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1934838.pBjHOxOYCL"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Apr 2018 16:37:11 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Apr 2018 16:37:11 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 16:37:15 -0000 --nextPart1934838.pBjHOxOYCL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 April 2018 16:46:36 CEST Roland Zink wrote: > Am 04.04.2018 um 14:43 schrieb Hubert Kario: > > On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote: > >> Hi Martin > >>=20 > >>> -----Original Message----- > >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex > >>> Sent: Thursday, March 29, 2018 4:47 AM > >>> To: Steve Fenter > >>> Cc: tls@ietf.org > >>> Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don= 't > >>> do > >>> it)> > >>>=20 > >>> Steve Fenter wrote: > >>>> To clarify for anyone who has confusion on the enterprise TLS > >>>> visibility use case, I think enterprises need to be able to do > >>>> out-of-band decryption anywhere in the network that they own. > >>>=20 > >>> This is argument is so lame. > >>>=20 > >>> In Germany, monitoring communications between individuals or between > >>> individuals and legal entities, including communications over corpora= te > >>> networks, was made a serious crime in 2004 (TKG 2004) with a penalty = of > >>> up > >>> to 5 years in prison for listening into such communication. > >>>=20 > >>> The world didn't end. Really, consider it proven that there is no ne= ed. > >>=20 > >> Could monitoring could be legally done if user provided his consent at > >> the > >> time of login into enterprise managed terminal? > >> I guess that's the case in enterprise managed networks. > >=20 > > No, even then the employer needs to establish a concrete case for > > inspection of the communications of an employee. > > Employer also must not continue inspection of an email as soon as it has > > noticed that it is part of a private message. > >=20 > > https://www.lexology.com/library/detail.aspx?g=3Df946064a-05d0-4603-ace= 9-384 > > 6b1c7536d > >=20 > > and this is true, to a large degree, for the whole of EU: > > https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read= =2Dby > > -employer-had-privacy-breached-court-rules>=20 > > From the ECHR ruling: > > "An employer[...] cannot reduce private social life in the workplace to > > zero. Respect for private life and for the privacy of correspondence > > continues to exist, even if these may be restricted in so far as > > necessary." >=20 > This is true, but at the same time the employer is required in many > countries including Germany to archive many emails and other relevant > messages. See for example https://en.wikipedia.org/wiki/Email_archiving > or https://www.intradyn.com/email-retention-laws/. This is often in > conflict with the above mentioned laws, for an example see > https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emis= sio > ns-documents-investigations. >=20 >=20 > I don't think breaking TLS is the way to fulfill such requirements but I > also think TLS connection to a company shouldn't end up at a third party > providing hosting or CDN services. it's not in conflict, just because you control of have the data doesn't mea= n=20 you are allowed to access it - think phone companies listening on customer= =20 conversations What it does mean, is that realtime access to TLS connections is definitely= =20 not necessary to retain messages for criminal investigations, that can and= =20 should be done at the endpoint in control of the company, not in transit at= =20 network boundary. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1934838.pBjHOxOYCL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlrE/y8ACgkQkqjRuAHS 9fVrxQ//Y1i9df1uHO4Nk+o0Sa3WR1AMNrD31BnTHmIZwx1N5LDZ3J5DXVqXj2rE pe9dUr9nWfZiaB+bSpRqqNB39+7DQvHz2chZK9CuvrWsT5N7AnoDflRHLqsSX3MX oZ3jhQ2qlN7l6ixmABroULGsl1AH3TPJ80eZcCdbbVCNznsatPtk5beG9WfuBwAv IQDjEDUKItIjY0ZD1IcdwKV9HCXfQTxrgSOjr2l0nA6biE78jAHKNxOcuScbN1hl dplMvA6NhHVXYwVYL28fsf4u4E0DBT++iS3qIGMUO2bzaxWMQAluhISTpetjSFfS bseJe8hwosgJAZUKmO/TNzjxkUdV6eI+zevK0cKR0x4Vq7E8+hKz1hGDibKZbSst ARvY6XaM2JDvxa1hwpxEG9oDx1aCbmfeWPiMq95zRwBa889JEPjav+5xHnpIAqRM XwpUzjbDMbzN05l12s5wZRou8cb7a5yixewL2Z44WdZj85TfEvowoX6nZjsUbD+c uwp+7udGOUKicqD5Ro0ChV+fQwiY1yoEPtkfWiWbLmeMttmAVbhtEixCrCAqUuq8 nr0XOtIhcFcXKLpBk+2Xp/9AETpFxHrZN673O1qcXSpptq2Lb6UnZh9G5dxR7HEr Nt9fMm+sB8tHuGpIgu2OaK7F3FEpc2WQI3GCK0Jbfjpsfy8DIdk= =7EXF -----END PGP SIGNATURE----- --nextPart1934838.pBjHOxOYCL-- From nobody Wed Apr 4 10:48:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC493124C27; Wed, 4 Apr 2018 10:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=2EEp8gIW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RnnyG3lM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frl-fXde6fUO; Wed, 4 Apr 2018 10:48:27 -0700 (PDT) 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 7480812DA6C; Wed, 4 Apr 2018 10:48:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D5032216BF; Wed, 4 Apr 2018 13:48:26 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 04 Apr 2018 13:48:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=vNLvNX+BqKBGiPSCZYh0Wy0rLWIv4 udJk6U1CA8qWG8=; b=2EEp8gIWYHu8R0v9t9yed4/sOcsQZLiBCCT9TASqYo4GW /2E2/YTmSswGGrD9Vuhb28eu4ZcW+LBwGvp21LMC6NHczr7Ira68mR39UaMvVG4s qrSZt2WM/X6maS9OWySOfVoRIKo7Z+IOKvW9rfdfQWGcyxrUjcuAm37mU7BqBD2K qX8E5H9C/0kpKPdbRfimXx9uBVSnFAx2yX4kIUdrfYP17Fb5i971wb/RRft0zmmg DwpZokgSY+ozYvhdHX/pCzpQDGAngmMGTsspAYPTgVr2tck4+s8iAJ5NCN3EvT6e JusvjmzVrQdPcdcxevKmpd59c4h9LC/HgILswRx6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=vNLvNX +BqKBGiPSCZYh0Wy0rLWIv4udJk6U1CA8qWG8=; b=RnnyG3lMnGb0AZYje+CSwp Xe9+T29e8z5Q5G1I0+l0E1XiBVp3uXQbNFUWXqrFD6BNMBmK1+XqxcC33Ibqh+Jh zefWzA00tDwNj47iT087yRXpmmvNpqncT9/T9nQZAqkJDwOVmcAc0r8RGCrpATa4 bL44joBenDGntm/8twlNs9GIinC2tgXpXbd3ievwluJu3y62yx3WrSJpKJKqC5o0 kPrH5Zte4EUlQ2BVl626STTjrCooslkjo64GelTx4FT+Z4G/P/ZKleutn4N7I5Vi sEbYntTrdTWl+83lxYD0BCqTAVjaKw874MVe3hUQ8hEBUvNYj0GzvIhd5olG1Brw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B356A9E092; Wed, 4 Apr 2018 13:48:26 -0400 (EDT) Message-Id: <1522864106.3946680.1326596904.38827BCA@webmail.messagingengine.com> From: Alexey Melnikov To: Benjamin Kaduk Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, tls@ietf.org, tls-chairs@ietf.org, stephen.farrell@cs.tcd.ie MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 Date: Wed, 04 Apr 2018 18:48:26 +0100 References: <152277457647.22702.669514304265362603.idtracker@ietfa.amsl.com> <20180403215023.GP80088@mit.edu> In-Reply-To: <20180403215023.GP80088@mit.edu> Archived-At: Subject: Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 17:48:30 -0000 Hi Benjamin, On Tue, Apr 3, 2018, at 10:50 PM, Benjamin Kaduk wrote: > I will trim the purely editorial stuff, as the authors should be > able to handle that (and have already started, since the cipher > suite/hash+signature algorithm thing was already noted). > > On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote: > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-tls-iana-registry-updates-04: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I support the idea behind this document. I have a few minor issues which I > > would like to discuss before recommending its approval: > > > > 1) In several places: > > > > "IESG action is REQUIRED for a Yes->No transition." > > > > Firstly, this should be "IESG Approval", not "IESG action" (according to RFC > > 8126). > > Sure, let's use the right term. > > > Secondly, are you saying that this is the ONLY way to transition from Yes to > > No? Surely, Standards Action should also be allowed in case there is no rush? > > Besides IESG is likely to prefer a document explaining the transition anyway. > > Is IESG Approval mutaully exclusive with Standards-Action? > My reading of 8126's: > > New assignments may be approved by the IESG. Although there is no > requirement that the request be documented in an RFC, the IESG has > the discretion to request documents or other supporting materials on > a case-by-case basis. > > is that a standards-track document could include an "IESG > Considerations" section that requests the IESG to effect the > transition. I suppose this can work, but typically "IESG Approval" is used for exception cases, where here it is always used. I think "IETF Consensus or IESG Approval" is more natural way of phrasing the intent. > That is to say, while I have no objection to your proposed (idea > for) text, I also am not sure that it is qualitatively different > from the current text. Best Regards, Alexey From nobody Wed Apr 4 10:50:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B163126CD6 for ; Wed, 4 Apr 2018 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qEs_1pIRzYDM for ; Wed, 4 Apr 2018 10:50:37 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0597124C27 for ; Wed, 4 Apr 2018 10:50:36 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id g20-v6so15067130plo.9 for ; Wed, 04 Apr 2018 10:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JSKKK/6uuyvg7O8aG4kyWGdqPNFdK6Ad/mH4qcGGA64=; b=g4YP3f8r/sfnC1BNX2L9JBpj5vxc4FwCK8k82SbeJX6XGfaxb5numa+Aby5LFYIrOR zhXfJGO1Vkx1tkzBm/mZuEJ4b2pruzE3XHjspAG5e2e8ReZqCnktCHKs+1pRUdk7fFbk lxuc3+Cs+pqgSbQGF+WF1saYNpkT0FNkD96/qru+HG8XImuCf36ytiVIIRcPvOvKbZBr h3+iU6FOEvIXXqwwiFfHGyE/Rzv+r4kxKGIbG+t5B+WcrHm9LkekriN9AftPFW92ZO2G O1UBZpcYzFIFxtn5D6SErQWWYOD0UnIR2iXFXkP/LecwlfSnlCaZ3WFivfuiemIRgtKO sjsQ== 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=JSKKK/6uuyvg7O8aG4kyWGdqPNFdK6Ad/mH4qcGGA64=; b=JYX8/+wrzxL2s5JRcKrz3995xo8bbfEhX8SSgDAWJGPpqvKAofcNf4+kpZ+wJ2OF7c 5mi2sQsfYjAtfBZEUkNKfHOtQseNDMbpeVZjtOmA0vDG2YxIEUMKOS/kgOuZtMHvtHqq DOfnlrfBrymHQKT/9jwqknR7Df2cBHWTkXc3Ytln4LI9YW9YTMwxGA+CLj2ujmtKFCeh 6MpZgALxjHNbH+8qGW3iMWHGp2blmYMsMrS2XIIcUHJu2rh0NXUIu39zdVPFjGuO374K xmZlcYaOMgCnl2mehUL+83KsQS2YjWQFdj9w7JbEo+GIXr3OIWk0u3IsOfzZx1ia6OAB tbtw== X-Gm-Message-State: ALQs6tC0LMFq457v77mKyew5OZ+RHVYM3B0ELua6NCVVVSjG+CkW96hO VcwapEdc1lQ7EMbbyFQA2JfI6o1ZTTIk4bFQX0/9so+S X-Google-Smtp-Source: AIpwx49TZ+O3ZTZSOtbacwBHGW1WgQiW3QoynvRNcxpHFRay27CSzJIKSvLm87zJfEBt2k+xaP+YADuDL4NgnmU1fsA= X-Received: by 10.101.101.152 with SMTP id u24mr4328076pgv.226.1522864236002; Wed, 04 Apr 2018 10:50:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.172.24 with HTTP; Wed, 4 Apr 2018 10:50:15 -0700 (PDT) From: Joseph Salowey Date: Wed, 4 Apr 2018 10:50:15 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="089e08251ce8d4177405690975a8" Archived-At: Subject: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 17:50:40 -0000 --089e08251ce8d4177405690975a8 Content-Type: text/plain; charset="UTF-8" Hi Folks, Some objections were raised late during the review of the draft-ietf-tls-dnssec-chain-extension. The question before the working group is either to publish the document as is or to bring the document back into the working group to address the following issues: - Recommendation of adding denial of existence proofs in the chain provided by the extension - Adding signaling to require the use of this extension for a period of time (Pinning with TTL) This is a consensus call on how to progress this document. Please answer the following questions: 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work? If the answer to 1) is no then please indicate if you think the working group should work on the document to include A) Recommendation of adding denial of existence proofs in the chain provided by the extension B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL) C) Both This call will be open until April 18, 2018. Thanks, Joe --089e08251ce8d4177405690975a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fol= ks,

Some objections were raised late during the revie= w of the=C2=A0draft-ietf-tls-dnssec-chain-extension. The question befo= re the working group is either to publish the document as is or to bring th= e document back into the working group to address the following issues:

-=C2=A0Recommendation of adding deni= al of existence proofs in the chain provided by the extension
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial"><= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12= .8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb= (255,255,255);text-decoration-style:initial;text-decoration-color:initial;f= loat:none;display:inline">- Adding signaling to require the use of this ext= ension for a period of time (Pinning with TTL)

This is a consensus = call on how to progress this document.=C2=A0 Please answer the following qu= estions:

1) Do you support publication of the document as is= ,=C2=A0leaving these two issues to = potentially be addressed in=C2=A0follow-u= p work?
If the answer to 1) is no t= hen please indicate if you think the working group should work on the docum= ent to include=C2=A0

A)=C2=A0Recommendation of adding de= nial of existence proofs in the chain provided by the extension
B) Addi= ng signaling to require the use of this extension for a period of time (Pin= ning with TTL)
C) Both

This call will be op= en until April 18, 2018.

<= /span>
Thanks,

Jo= e


--089e08251ce8d4177405690975a8-- From nobody Wed Apr 4 14:04:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F038F12D967 for ; Wed, 4 Apr 2018 14:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx5I0KTW2TEG for ; Wed, 4 Apr 2018 14:04:56 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::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 16F6E127AD4 for ; Wed, 4 Apr 2018 14:04:56 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id k6-v6so10769308pls.5 for ; Wed, 04 Apr 2018 14:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k7c9HjqjjFb35Wt02ZYTEiHO2FouwGhacajUpx/mVmI=; b=f5ZPo/sbE6HUNHiOZUp8NEU22j4XJ5gLulz7mLJIVNYo+emPrV8P/rNGZHwLv2G0cw sJfbSfQH+GyxbJ3T3ernXjupcyzB+NFmY8lBtgkfuBclbdkQ16mZdt15WS8/14WG33NE vIJ/qt3yS5W7oW7p5hWxWjVoUBW8mHNrbLMJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k7c9HjqjjFb35Wt02ZYTEiHO2FouwGhacajUpx/mVmI=; b=h/u2b/RdPkFQF5PQjkV5VlLWW1MI2U/oXgm7ml33UWFogizyiGDf5SvoyN04sXdeUp 58ugp/cbs0riD/PTIEUJXN0836I4lJIsNAnk+0H+aOA+u3opJoF/8XWJo/+NsS9G+BXQ Rw5P/qMRMIRhS8Tq+3YxowPIm0CC195v0WWuBCsPt7oaNRVkkI7nT78SMweVvhyjKk4i OBw5dyzvjgT9SaXRjoFwqSydum/I8IFDupxNV8jhvDSdUVp9jqwGxtP+E36SZlyVvYk6 ug9ztey7mn3ckMrWXCyb2U3SYhJDyd9mRegLKnjd1G5krzWe6mWZwFkm5wVl7TnZxZt+ ry+w== X-Gm-Message-State: AElRT7F/yyMhzifbDgmZp4xpaAhYOgkJnM1IYPKXNAIGQhjjAnFg4nff oE5EYlXsFck+9B9LIKSZs6K2Gw== X-Google-Smtp-Source: AIpwx48PyNJdoSpny9fWa0GY7wq8Z5uqov4Mx0L3c/fLNZNOkw9xllfjGfkISh0vzszIHpPa15KWLQ== X-Received: by 2002:a17:902:525:: with SMTP id 34-v6mr19951920plf.267.1522875895674; Wed, 04 Apr 2018 14:04:55 -0700 (PDT) Received: from [5.5.33.147] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id t68sm10818673pfk.9.2018.04.04.14.04.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 14:04:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <1522864106.3946680.1326596904.38827BCA@webmail.messagingengine.com> Date: Wed, 4 Apr 2018 16:04:45 -0500 Cc: Benjamin Kaduk , The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, tls@ietf.org, tls-chairs@ietf.org, Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: References: <152277457647.22702.669514304265362603.idtracker@ietfa.amsl.com> <20180403215023.GP80088@mit.edu> <1522864106.3946680.1326596904.38827BCA@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:04:58 -0000 > On Apr 4, 2018, at 12:48, Alexey Melnikov = wrote: >=20 > Hi Benjamin, >=20 > On Tue, Apr 3, 2018, at 10:50 PM, Benjamin Kaduk wrote: >> I will trim the purely editorial stuff, as the authors should be >> able to handle that (and have already started, since the cipher >> suite/hash+signature algorithm thing was already noted). >>=20 >> On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote: >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-tls-iana-registry-updates-04: No Objection >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> I support the idea behind this document. I have a few minor issues = which I >>> would like to discuss before recommending its approval: >>>=20 >>> 1) In several places: >>>=20 >>> "IESG action is REQUIRED for a Yes->No transition." >>>=20 >>> Firstly, this should be "IESG Approval", not "IESG action" = (according to RFC >>> 8126). >>=20 >> Sure, let's use the right term. Yep my bad - fixing this. >>> Secondly, are you saying that this is the ONLY way to transition = from Yes to >>> No? Surely, Standards Action should also be allowed in case there is = no rush? >>> Besides IESG is likely to prefer a document explaining the = transition anyway. >>=20 >> Is IESG Approval mutaully exclusive with Standards-Action? >> My reading of 8126's: >>=20 >> New assignments may be approved by the IESG. Although there is no >> requirement that the request be documented in an RFC, the IESG has >> the discretion to request documents or other supporting materials = on >> a case-by-case basis. >>=20 >> is that a standards-track document could include an "IESG >> Considerations" section that requests the IESG to effect the >> transition. >=20 > I suppose this can work, but typically "IESG Approval" is used for = exception cases, where here it is always used. I think "IETF Consensus = or IESG Approval" is more natural way of phrasing the intent. We wanted a bar that implied some adult supervision hence the IESG = Approval :). I=E2=80=99d prefer to leave it at the lower because = technically IETF Consensus also includes IESG Approval right? I mean if = somebody gets their draft through the process doesn=E2=80=99t it end = with IESG approval? >> That is to say, while I have no objection to your proposed (idea >> for) text, I also am not sure that it is qualitatively different >> from the current text. Here=E2=80=99s a link to the PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70 spt= From nobody Wed Apr 4 14:33:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2A1267BB for ; Wed, 4 Apr 2018 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epTHCRJqCNXf for ; Wed, 4 Apr 2018 14:33:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF8B120454 for ; Wed, 4 Apr 2018 14:33:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40GfMt2wBHz37L; Wed, 4 Apr 2018 23:33:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522877610; bh=r7Fg91OUxV1lHA508BJt2QF1+LJ5Pqueqbm2DDMQs9w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=X91im+pPXxbSIjdwdfMUNvm8dd1T5w60lDUzHA/e+M6yDGntkgQaleM3M3y2zlzvi 6CVQBnTIoFWJE39usoKpqK6cJURJsBP+wvTfznvJKBZY9kPtxHMWvqbbS1zWOGTJKo isYf/+DvEFHvhic059WaYfo5WAb8fnmPz3dcEAFo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ee3hKwDwnY4D; Wed, 4 Apr 2018 23:33:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 4 Apr 2018 23:33:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 61BEEC9A; Wed, 4 Apr 2018 17:33:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 61BEEC9A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5984C4095AB0; Wed, 4 Apr 2018 17:33:27 -0400 (EDT) Date: Wed, 4 Apr 2018 17:33:27 -0400 (EDT) From: Paul Wouters To: Joseph Salowey cc: "" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:33:36 -0000 On Wed, 4 Apr 2018, Joseph Salowey wrote: > This is a consensus call on how to progress this document.  Please answer the following questions: > > 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed > in follow-up work? I do NOT support publication of the document as-is. > If the answer to 1) is no then please indicate if you think the working group should work on the document to > include  > > A) Recommendation of adding denial of existence proofs in the chain provided by the extension > B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL) > C) Both These options need a bit of clarification. If you do A) then by publishing the proof of non-existance records, you can cancel any outstanding kind of pin done. And you would not need B) But that requires the server farm consistently send the TLS extension at all times. If they stop doing this, you have to somehow determine if this is an attack or an administrative discontinuation. Doing a pin as per B) would help identify if this is an attack or not. And a pin whose value meants "no commitment" would allow for a farm of TLS servers where not all servers have the extension (obviously at a price of reduced security) So to support all cases, I would say C) but I think B) would get us pretty far on a lot of deployments. The document's intension is clearly to staple DNSSEC answers for the TLSA query on the TLS handshake. Omiting proof of non-existence means it fails to achieve its specified goal and makes this TLS extension completely useless[*] Paul [*] The only use case would to accept WebPKI _or_ DNSSEC, which only reduces the currently available security levels instead of increasing it. From nobody Wed Apr 4 14:53:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9898126BF0 for ; Wed, 4 Apr 2018 14:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 xkPWqm_37EmH for ; Wed, 4 Apr 2018 14:53:14 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DAB120454 for ; Wed, 4 Apr 2018 14:53:14 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i28-v6so25062870otf.8 for ; Wed, 04 Apr 2018 14:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RHpsc7DSbmwN3riHyirZYjSlZmgkf8Lq+RanKkGCupA=; b=frTd/hjyqGYdsvzvJiF47nzbistZvWc1xXqsZnMf58Y1UZrPfMR+C7PD3B0lsEW+jx a/QR/hAdW01zvNR0D2dvpzaCQHzoyEhD3eF7bKXJAR4AMYTnBS+XgLOZESohQBiib4qs XaHWMldFaiu0dHaysH8RclEVewMqa6JbLqU3adTihAWrqQlbJPwML8DjyaP5PDtAvMZr ivkbICNpr8rXdIDWkTifit1jOghIDxSsK+VHljXy3is0P3jmEMTYqgX7jDifoDpmjW50 17Yaf5oAHIp90MXCBaLgec2sI9PXfDfu4idNyFXLPHwGoGT7ndVxvzu1ZZ1+HsUH2goe Py9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RHpsc7DSbmwN3riHyirZYjSlZmgkf8Lq+RanKkGCupA=; b=ocLa93W9Pe+nqpdOUNznoVaNCkZ2IekZG8nDvuGmSCp0Nrax9Swvs3jYK+fAgSf0m9 pIxS0Rs2ySX51PdaRMVhiE7sLuP7QFdVLMULOSvyUypN6yfksPmDlf5gIQZzrcaEv9U9 ZZpqQzAgOaxwADyoG+xSJM7enz3mm26XEW2T1FWEY3fiKxK35jQZMmI4C6fz5QKuCIca +ez8kRfS7B5cWOFCMcMQ3tX4ZphKmhFFn9FiX/l9/zHsukVawN6q9sU9PnB5BTq0V6ze m/095JpY2ETY7OAfz3oL9ZUDYB4+TpzOHgZyvgEJU3mlLk+p0wjUP+JA3veYDpAvWDxI grEA== X-Gm-Message-State: ALQs6tC4wOj/ZzGp9qICxzzwi+IGi9ErHH9tOYsg90gdBX7Lwikm2SFQ EFHfA2+iZNAbBpSr97JBdAz6f80aAbEMKK5tIJjInA== X-Google-Smtp-Source: AIpwx48ceuNprkUisStfruCqW/BK5Vr8VQOIeIcpcrRPXUhuiSWwGKvvTeSjPJ6EdEU0oES3PhgiacJju4q3mGD7Ot4= X-Received: by 2002:a9d:1920:: with SMTP id j32-v6mr12541957ota.383.1522878793531; Wed, 04 Apr 2018 14:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Wed, 4 Apr 2018 14:53:13 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 4 Apr 2018 17:53:13 -0400 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="0000000000008658ad05690cd9c2" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:53:18 -0000 --0000000000008658ad05690cd9c2 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > I support publication of the document as is. I would also be comfortable with a minor modification to say that TLSA certificate usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism. Even if this document is restricted to the assertive use cases, it can still be used in cases where clients and servers have agreed to forego the "normal" PKI and rely on DANE, or in cases where servers are able to switch between DANE and non-DANE authentication depending on the client's capabilities. The former pattern could be made to work in the web if there were interest; I believe DKG has indicated that DPRIVE might fall in the former category. While there may be utility in the restrictive use cases, the discussion to date indicates that there is sufficient complexity and controversy involved in making that work that we should not block this document from enabling assertive use cases while that is in progress. --Richard > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both > > This call will be open until April 18, 2018. > > Thanks, > > Joe > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0000000000008658ad05690cd9c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <joe@salowey.net><= /span> wrote:
Hi Folks,

Some objections were raised late during the review of = the=C2=A0draft-ietf-tls-dnssec-chain-extension. The question before th= e working group is either to publish the document as is or to bring the doc= ument back into the working group to address the following issues:
-=C2=A0Recommendation of adding denial of= existence proofs in the chain provided by the extension
= - Adding signaling to require the use of this extension for a period of tim= e (Pinning with TTL)

This is a consensus call on how to progress th= is document.=C2=A0 Please answer the following questions:

1)= Do you support publication of the document as is,=C2=A0leaving these two issues to potentially be addressed i= n=C2=A0follow-up work?

I support publication of the docume= nt as is.=C2=A0 I would also be comfortable with a minor modification to sa= y that TLSA certificate usages 0 and 1 (the restrictive ones) MUST NOT be u= sed with this mechanism.

Even if this document is = restricted to the assertive use cases, it can still be used in cases where = clients and servers have agreed to forego the "normal" PKI and re= ly on DANE, or in cases where servers are able to switch between DANE and n= on-DANE authentication depending on the client's capabilities.=C2=A0 Th= e former pattern could be made to work in the web if there were interest; I= believe DKG has indicated that DPRIVE might fall in the former category.

While there may be utility in the restrictive u= se cases, the discussion to date indicates that there is sufficient complex= ity and controversy involved in making that work that we should not block t= his document from enabling assertive use cases while that is in progress.

--Richard

=C2=A0
If the answer to 1) is n= o then please indicate if you think the working group should work on the do= cument to include=C2=A0

A)=C2=A0Recommendation of adding= denial of existence proofs in the chain provided by the extension
B) A= dding signaling to require the use of this extension for a period of time (= Pinning with TTL)
C) Both

This call will be= open until April 18, 2018.
Thanks,

Joe



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


--0000000000008658ad05690cd9c2-- From nobody Wed Apr 4 15:05:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9602E12D86C for ; Wed, 4 Apr 2018 15:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 uWDTkSW0KVVM for ; Wed, 4 Apr 2018 15:05:20 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63B512D877 for ; Wed, 4 Apr 2018 15:05:18 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id v5-v6so14129916plo.4 for ; Wed, 04 Apr 2018 15:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTqSIB/QnpLls6cFT7Xa1xq+/9SNyZTWNtAQcpZzUOU=; b=FYWb03BFGQSQo+uMuHpXUmYMaXycs8hmUgHTxlQQb54eqkh5AmiFcoZnqP6LbuJYgi 3ADHmeecpIhNCkOoPeOGiViuaVJVZk7csiu8sORBNpe9bW9u3EH8m/WG8ff2wZJfvwuV RZrAebv3LNK6IZXWIln4qh6qBrY3g62tFo9Co= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTqSIB/QnpLls6cFT7Xa1xq+/9SNyZTWNtAQcpZzUOU=; b=EeQqwub7CP476xuEg/KEoOHdmW7iGTVZQp8wofjbhtm0d3a5xcGZ/O08WrNy53XxgI jxeUJmFgKT3MSk1hFW3zWM3o+7OGnLkRq8HLJ33Tir83o9nMG/BFfazqoxgHKi373LhJ ASOhbtnDoJosfdp81lGAl8awqxKOWKpBnEtTNRklf9cpjwvovIkj1YbSJjgvTG2Ki7IE GAIU0lQ5kEsMHnSPNOYoyJrECSkO7PcGCk1vRkoYi1DIZflP3nHVEu8q11B6I91Z7wp/ mBEkklJIGZkGTqtI1kEa6TDVonnK88/Hh7S3pX/fHBpjQQ53LM5Hf7VEAq9TLgEZXMjT cL+g== X-Gm-Message-State: AElRT7G622J+SNSvWsyll6IC7LbScdwqavGHyHfz60jcNQOQLdpxSW8j 74VmNsRUWV5HJWQths2R8kxmzA== X-Google-Smtp-Source: AIpwx48gDikQTqF4CtmRDhJHrK/fVce/qFHPdunZasrMC782QXDPDKwR+W1N2QxjmKnowkMnZzN1bw== X-Received: by 10.99.141.200 with SMTP id z191mr13011092pgd.418.1522879518290; Wed, 04 Apr 2018 15:05:18 -0700 (PDT) Received: from [5.5.33.147] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id r14sm11945321pfa.163.2018.04.04.15.05.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 15:05:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 17:05:08 -0500 Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:05:21 -0000 On Apr 3, 2018, at 23:09, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-04: Yes >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for the work everyone put in on this document. I have a handful = of > comments, ranging from nits to minor issues. They appear in document = order. >=20 > = --------------------------------------------------------------------------= - >=20 > Title: >=20 > Please expand "TLS" and "DTLS" in the title. See > https://www.rfc-editor.org/materials/abbrev.expansion.txt for = guidance. Sure, but I have also just sent a request off to get TLS and DTLS added = as well-known abbreviations so I=E2=80=99m hoping to change it back = during AUTH48 ;) > = --------------------------------------------------------------------------= - >=20 > Abstract: >=20 > Please include the list of updated RFCs in the abstract. See > =C2=A73.1.D. The = current formulation > of "This document updates many (D)TLS RFCs (see updates header)" is = problematic > due to the factors described in the final paragraph of RFC 7322 =C2=A74.= 3. See Ben=E2=80=99s response. > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 >> Instead of listing the changes and their rationale in this, >> the introductory, section each section provides rationale for the >> proposed change(s). >=20 > There's something awkward with the commas here. Perhaps you mean: >=20 >> Instead of listing the changes and their rationale in this, >> the introductory section, each section provides rationale for the >> proposed change(s). Yep that does read better. > = --------------------------------------------------------------------------= - >=20 > =C2=A78: >=20 > This section doesn't indicate anything about the disposition of > "token_binding," which is due to (potentially) expire in 11 months. = Given that > the temporary property of this registration is due only to the = previous policy > that this document is obsoleting, it seems that this document should = instruct > IANA to remove the temporary status from the "token_binding" TLS = ExtensionType. I think that would be terribly unfair especially since the draft = defining the token_binding extension is on the 5/10 telechat ;) https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ How about I just get them to add a Recommended =3D Yes column. > = --------------------------------------------------------------------------= - >=20 > =C2=A78: >=20 > The table that adds a "Recommended" column to the TLS ExtensionType = does not > indicate values for "token_binding" or "cached_info." I suggest either = adding > them, or adding text to explain their omission. Can=E2=80=99t believe I forgot cached_info. I=E2=80=99ll add a note = about token_binding. I also just sent the WG a note about needing to = add the Recommended =E2=80=9CYes=E2=80=9D value to their IANA = considerations. > = --------------------------------------------------------------------------= - >=20 > =C2=A79: >=20 >> assigned via Specification Required {{RFC8126}}. Values with the >> first byte 255 (decimal) are reserved for Private Use {{RFC8126}}. >=20 > Nit: the "{{...}}" citation style is probably not what you intended. Ah it did that because it=E2=80=99s a code snipet :(. Fixed the multiple = occurrences. > = --------------------------------------------------------------------------= - >=20 > =C2=A713: >=20 >> o A "Recommended" column to the TLS Exporter Label registry. The >> table that follows has been generated by marking Standards Track >> RFCs as "Yes" and all others as "No". >=20 > No rows are marked "No." Presumably, the text above should instead say = "any > values not indicated in the table below [will be/have been] marked = 'No=E2=80=99" yeah I think it=E2=80=99s that the others are "to be marked=E2=80=9D = (same for the cipher suites). > = --------------------------------------------------------------------------= - >=20 > =C2=A714: >=20 >> 120 no_application_protocol Y [RFC7301] >=20 > Every other updated table is amended to also point to this document. I = presume > that omitting it from this entry is an oversight, and that it should = instead be: >=20 >> 120 no_application_protocol Y [RFC7301] [RFCthis] Yep. See the following PR to address the above changes: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/71 > = --------------------------------------------------------------------------= - >=20 > =C2=A717: >=20 >> o [SHALL update/has updated] the TLS HashAlgorithm Registry to list >> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry >> to list values 4-223 as "Reserved". >=20 > HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and = 8. > Presumably the reserved ranges should be "7 and 9-223" and "4-6 and = 9-223", > respectively. https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65 > = --------------------------------------------------------------------------= - >=20 > =C2=A717: >=20 >> Despite the fact that the HashAlgorithm and SignatureAlgorithm >> registries are orphaned, it is still import to warn implementers of >=20 > nit: "important" >=20 >> pre-TLS1.3 implementations about the dangers of blinding implementing >=20 > nit: =E2=80=9Cblindly" https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70 From nobody Wed Apr 4 15:12:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7503F12D86C for ; Wed, 4 Apr 2018 15:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80F4RFvBIoun for ; Wed, 4 Apr 2018 15:12:04 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D62812D876 for ; Wed, 4 Apr 2018 15:12:04 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id bj1-v6so13702057plb.8 for ; Wed, 04 Apr 2018 15:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gk16SifS4vMQ1HFlhRKCaCyVgixeFS6hwBRaE0FqH/Q=; b=1/zN2YOm2Smq7Dw5cvKBqnyaUFWeT48FkyO12SqApjfIgzgRYbed9I/6/IqQNyaorm /XypJ/gA2t1r1QYYZJBIlM4cCvykFfEhl1oANhI3NqIn3OlxeGuVOgIhU8zhSc/kKIqJ F4CmFwKw7K5V/rUO2UEouR2oZ+TbcFvQ5zQ+z2r3bUpaLLNidEfgjY3lpq7IMIXzPKlz +9tbuh3FqmrpIgkh2vRdq4QewxPtznfOvtC3ptfpCZjmQ+GY3JLpmbagCbAoHAZkWcab Y/W6cD5YWTcOcNRRvuB5nloI27HWVEdpkc0DVV/Sn3l1kHp/83NtFjJgBz+ezbybEhbG CRBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Gk16SifS4vMQ1HFlhRKCaCyVgixeFS6hwBRaE0FqH/Q=; b=hRHtG0ORoKmyapqSFrBUBGG8gPz+CDtW0IIn1X+Z32LlWxP7jDczqyZOlg7qrfDqBo lTdwcAP9fbVaDj10pKWzq+V6ennOVDqqrIR8cwA3WonDgdCMPNSfrKiu8Jx74EU/xaVv LnSR9HgyaQE7DnWcpZtHaQTBnsEanuF2hWCTEi+IZthrwJq8oGC72cRoWzW8wWCMAYkl nhgFMOYWrAxDDqejWtFrKaIXNPXilwDJiXoEZSooMslPZjdo6B9aKqEYyoUwpYLVLvHr Vd/eNhpUsl7BGKDehYf8FET5e3PyHmX9kR2eO/7z5MGbols7z+AxYppm658x5dWx4UtG ECKw== X-Gm-Message-State: AElRT7HEb+R2GUzCWvbGIqGh94GRsPWr88NM9dcklk7Hbns8eUxt58RB XmhCFarCWEVOzvXSaykfByHV5qmABA== X-Google-Smtp-Source: AIpwx49LtS8Dz8BphBVXlVsf3QHhj6aIRW1OroNbdKqOyPhGVk9YuED/UsTkKGwPsZhNntxvGwQpPw== X-Received: by 10.99.54.75 with SMTP id d72mr12991176pga.96.1522879923858; Wed, 04 Apr 2018 15:12:03 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([2620:11a:c081:20:f12c:1dde:a8f2:78f4]) by smtp.gmail.com with ESMTPSA id s78sm12304573pfa.161.2018.04.04.15.12.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 15:12:03 -0700 (PDT) To: tls@ietf.org References: From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSdNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbT7CwZcEEwEKAEECGwMFCQlnUwAFCwkIBwMF FQoJCAsFFgIDAQACHgECF4AWIQRPaC2TKheW+CDyNMDfuJFymnbbjwUCWml0ZAIZAQAKCRDf uJFymnbbjwiCEACjyYe2HGofiuEla4aI3CvIEzEpn2HsMWXrrqqybtPwIMv3aQ0XrxFPkeWk JN9CYwG23IZIE9h7gB2PMIEtzOswzEUGioryHjqZ6NWbX9yjoyIPkVKAAGcn66shF/8ZPhxu cG2dLNY0UxrbF6NmWlGLGSHkd2wTYCQUVNKq7gWrHIYzSXBwKL+zlOhw9JqPk8a/+JeSFLE/ dZBlKJLpllELGSGtvpOuCJz/ICK/jXiEKDFaiMveResRNIP7SsLcoxwcIdVra5q0oQbE/zlD tlq6yPR8aO3cYm6MTkFcZW0pPQiFqXXOpZJGCxJMjd10qKBAr3uJ+czomFp0kVkosckSau5Q +h66MY73PDQnfmjDCzgN4w+TU5dv5wM6Zq9nutFuBtf0EELN0tKuSakI2mlpvIjPzSHh0Xmi mBhjWurmWXyHAV3PDbEMwEePJKAOeP8xx/qalmD8f424TA897nVqZ/oKtrVeIua+P6v87z5+ 9EFvrAX3ZDb9YOk+HvnNLBpDl3Vk7aZzNTjsNZcVbYTGZBOOtjMw5dOz/5xDv8kpaf4ORxEL Nf5BZaSEWZLW+pRtNE3fWJ5uuJvqDitwnI6WLS7Q5MkuHRz0/nVMqT0JRuFOChGQrY6/kmbH JK82xf1Xy2y7UFADuhlx6iOCaG08BFEDVmsGDna0SF3nNq//gc7BTQRaaWdIARAAoGbjNfII c0robr/p9JFslgnhFq8fRMtNxIBY+WpQbeefji793TrHcgRycY7XdHGUtV2imZYK9WGdDqUD b/1ssvLkltgWeochtUijff9TJnySzZ448WgUD+MmjMA3Ut8F+4aFmNfSKVT2R2A0d+RQIEpx v7OsHviDiEzNUyaDibOPsoHiuXQuy30aI/pZBB2K03IJWFbsLMithTc/7BfJCVtXxGRzOuqY Um4Qr8GxAlm2+Hgxl2ymWPdltUU0OVObXfAzC18mIqUKYa3KHkV6W9fA2zpxNFsCEFdMgYHP 604lLf8FY2rHdUa7AjwUAv7ifmR5J769jKMSFgQbEbSmBxuumji/pw1fF9Zorheo+HM7b4Jn aq8Dx6QClcYX8HfxuLLjQbp2MOP5AFfW9vnonV+XptzbTzzZf6jY7JhB0Bp/+SSkR0b0LNMr ooFw4TdjdJHqB62xghPJMgP3fNy+xPXfeYbH9ycaUc5nmk83vjaXCGl+bl3SjmggYy7cdbTq wwOF1+2N52PsGimWGt0bwu8rpRSYin2Fg0q4lnkF3F49OqfB+rxerMvS3l/cUUY0yO6gxxcc LjECChqoLn17cbtKccXDKl0xFD2Z8VFlL7hY42LxJrTvdvjrfzbqLVfCb0T8INjp2IzCaHVN V+4cxLPHY7YGRvrdxRBit4tRCVEAEQEAAcLBfAQYAQoAJhYhBE9oLZMqF5b4IPI0wN+4kXKa dtuPBQJaaWdIAhsMBQkJZ1MAAAoJEN+4kXKadtuPJK4P/R/PeirQEAgFdEXFd0Kme+YmOaQs aUcsQGkdD4xOY4mFeYFBzwira/VD2beAYvm8zS0NiiSukceFzX+ZUFqKRKNSMbTohT45K0CK TZGJhVsjhqSqUiA4YLCabMGasTwy6aPufRjZUlBur97DAJ8fhr7b6nM5L4OlDwzfyWCu+QSB qAhmTMqK9QdBJkWI/fC3cI0/eXUGV42b1gQ3iMfjcVGSqAOwJUf8YLDdzxxquEgKTCy9Ef6m 4iyM1D50z7ebAbNKXn5VbzK7YCDImfRXWDxPlVsufl9gJnhYOmZeVu+h0FD+nmGUFeWm2foo lvZWNU5qrKqUyA7v2TMu6S5J8VeRNb0MvsLIoZbg2MnWkOB1qDWmO0BW/se07L4yUYvnB+wc uI8aIU1lLmrpLjJk9HhGnrFiUq2gJsbH36icA6bItHIWbJLl4xJvYF+q2OzIczmZe1c/Rfuj GE7U5k9ZqZCwDFn9fybilAn50gB0ZQ8VDgBukEiaB1gBqmMt14hfWzet8kOsZZZaEm2zLz/V VtHv4hSjChCL3yLwINCK5T3HygBrrk9WscCFO3WvzeyznF8gw0hFLks71y/wZFso8bi83S2O nk7wumU/3wOYkvzwFI9Fm61jax0LUOTmNvmpdr+iXS7v8OiGSQgaU6LDgDs85q3vt9X5NRys KnfcUcQv Message-ID: Date: Wed, 4 Apr 2018 15:12:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:12:06 -0000 On 4/4/18 2:53 PM, Richard Barnes wrote: > I support publication of the document as is.  I would also be > comfortable with a minor modification to say that TLSA certificate > usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism. The addition of text that clarifies that seems absolutely reasonable to me. I do think there would be a problem with adding additional complexity to the extension to support functionality that nobody has said that they intend to use (including the proponents of the changes), given that the changes would not be introduced to correct an error in the existing spec. Melinda -- Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Wed Apr 4 15:13:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35BD12D86C for ; Wed, 4 Apr 2018 15:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 4CtTIfCTHngd for ; Wed, 4 Apr 2018 15:12:57 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8610412D879 for ; Wed, 4 Apr 2018 15:12:55 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id s24-v6so16139763plq.6 for ; Wed, 04 Apr 2018 15:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1fo+/A2jr4M0VYQ7aCAShOzc85EK/34H8ZHqM5B7XpU=; b=dU5aRYCNeiYlLIaAy7tWkDFtdyrSa96VxbaKMKJ29Q1Jx8Kdb6uEM3Je0s/GY/m323 0Tddau/EqsRcj/RFIU5Wh4PFrIw+rde+pNt02FSMy5LvJjOajfzJq30y0A98NYFRgBYm 9AeTPMXHQSVxS4wKzoQT1fZ60B1UmDMLGRn5E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1fo+/A2jr4M0VYQ7aCAShOzc85EK/34H8ZHqM5B7XpU=; b=USIvX5nF6NOKP+0P3eNMM9Riy2yypumgoIQrRp8Ow9pXCDaOXf9qQH5FueBuawUK8R MgOWEfgZggYCUNnFoAix9xiXk/Rfuy5azoBjFLvaUWIIZoHL+2WHynL+Ochxb9b8cjbo XTW6ptc5RuXRobf7+ITnwLbyjpjMbOW7OwwqyLf1dIGxF+k3uHwLl+VTIGntazGED0YA cwozktJ+j0aXkqyLOzc800zsoSHHOrmAIlHAebkPK5cujbVK8C8jmnNbN6tJeENvSqa9 8oJIQAo18EV8WVOetj4G3hu0GKpjx5yKLdskW5QQIGWnv6NSZtaBGlZO8L5V+YkF7R8i zWVg== X-Gm-Message-State: AElRT7Grk1jsq6LIt4jnRY1U5zcbJQVtC27eIw4BdMeu91aS37pRRgkg AF4VwctE0Oi7WDtrK67os14oMg0p+ME= X-Google-Smtp-Source: AIpwx49APZ3HWyIc9ejwtaugI6eyDTUw1Qv5B95cpXEl4UHBrgAZtRdtt2Brkw40es9IXejXRcxoaQ== X-Received: by 10.101.86.141 with SMTP id v13mr13066663pgs.353.1522879975170; Wed, 04 Apr 2018 15:12:55 -0700 (PDT) Received: from [5.5.33.147] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id o88sm12381505pfk.91.2018.04.04.15.12.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 15:12:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Wed, 4 Apr 2018 17:12:46 -0500 Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152281496113.23972.392506465427726208.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:12:59 -0000 > On Apr 4, 2018, at 17:05, Sean Turner wrote: >=20 >>=20 >> Abstract: >>=20 >> Please include the list of updated RFCs in the abstract. See >> =C2=A73.1.D. The = current formulation >> of "This document updates many (D)TLS RFCs (see updates header)" is = problematic >> due to the factors described in the final paragraph of RFC 7322 = =C2=A74.3. >=20 > See Ben=E2=80=99s response. Here we are again. This time I updated the abstract to include the 8 = RFCs this draft =E2=80=9Cupdates=E2=80=9D.* spt * I still think this policy is silly.= From nobody Wed Apr 4 16:27:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1912DA27 for ; Wed, 4 Apr 2018 16:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aTHpdrfkIwm7 for ; Wed, 4 Apr 2018 16:27:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA49F12D954 for ; Wed, 4 Apr 2018 16:27:38 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 800457A330D for ; Wed, 4 Apr 2018 23:27:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 4 Apr 2018 19:27:36 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:27:50 -0000 > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: >=20 > - Recommendation of adding denial of existence proofs in the chain = provided by the extension > - Adding signaling to require the use of this extension for a period = of time (Pinning with TTL) These are indeed the immediate proposed fixes, and ultimately the = consensus call will be about whether the fixes should be formalized and integrated or the document = advanced as-is, but before we consider them in a vacuum, I'd like to explain in some detail *why* = they are needed. This requires firstly an examination of why the extension is needed in the = first place, and what use-cases it should address. This will be detailed below, but first: > This is a consensus call on how to progress this document. Please = answer the following questions: >=20 > 1) Do you support publication of the document as is, leaving these two = issues to potentially be addressed in follow-up work? >=20 > If the answer to 1) is no then please indicate if you think the = working group should work on the document to include=20 >=20 > A) Recommendation of adding denial of existence proofs in the chain = provided by the extension > B) Adding signaling to require the use of this extension for a period = of time (Pinning with TTL) > C) Both For the record, (C) both. And now to explain why: The first thing to understand is why this extension is needed in the = first place. A partial answer can bee seen in the introduction to the draft. Please pardon = burying the lede, below I quote from the text of the introduction in order of presentation, but = the main point is closer to the end: ----------------- This draft describes a new TLS [RFC5246] [TLS13] extension for transport of a DNS record set serialized with the DNSSEC signatures [RFC4034] needed to authenticate that record set. ----------------- We should note that an empty record set (NXDOMAIN or NODATA) is still a record set, and DNSSEC *authenticates* denial of existence, and it is necessary to also support denial of existence, in order to support downgrade-resistance against "TLSA-stripping". The reason is that this extension is not being introduced into brand new internet in which the CA/B forum WebPKI does not exist and DANE will be the *only* way for TLS clients to authenticate servers. For this extension to coexist with the WebPKI clients will need to be able to *some* servers via DANE and others (those that don't have DANE TLSA records) via the existing WebPKI. Suppose that, in the absence of authenticated denial of existence, and clients being able to rely on continued support for the extension: * As will be the cast for most existing applications, the client is willing to use the WebPKI when DANE TLSA records don't appear to be availble. * An attacker is able to obtain a fraudulent WebPKI certificate. Then the attacker can impersonate the target server by leaving out the extension and presenting just the fraudulent WebPKI certificate, and the client will have to accept this even when the real server previously employed the extension and provided TLSA records. What the above establishes is that in mixed environments, i.e. almost all use-cases for this specification, TLSA records provide no additional protection, if WebPKI fails, security is compromised even with DANE. Some have argued that this is OK, that even though the above "restrictive" use-case is unavailable we still get an "additive" use case, where servers can be authenticated with DANE when that happens to be present and otherwise WebPKI. Sadly, that use-case is largely a mirage. Firstly, given the existing dominant client base that only supports WebPKI, any server would in any case still need WebPKI certificates (say from Let's Encrypt), and that will suffice for all clients both those that support DANE and those that don't. Thus enabling DANE on the server, only makes it possible to impersonate the server if DANE is compromised, but does not defend against WebPKI compromise. So the server gets more complexity, and reduced security, and maybe even increased risk of failure if the TLSA records are managed carelessly and fail to match. No rational server operator will employ the "additive" mode. Some DANE idealists might do it to signal their support for the technology, but this will be futile, they'll get no real benefit from doing so. Continuing on with the introduction: ----------------- The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without performing additional DNS record lookups and incurring the associated latency penalty. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. ----------------- Here we see the promise of being able to get by without having access to a validating resolver, but validating resolvers deliver both signed data when present and signed proof of non-existence when the requested records are absent. But most importantly: ----------------- This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. ----------------- This plainly shows that browser HTTPS was a motivating use-case for the extension. Indeed earlier mention of latency concerts is also based on the reasons why browsers don't (want to) do DANE even when direct DNSSEC lookups are possible. Not just browsers, no existing application can adopt specification incrementally. Even if the extension is required in the application, it is unrealistic to expect that all server domains will rapidly adopt DNSSEC. At the moment there are ~6 million DNSSEC-signed domains, substantially concentrated in northern Europe, with fairly thin adoption generally (only ~800K domains out of ~120 million in .com). An application that expects the extension should expect to not find TLSA records for many servers it connects to, indeed many server domains will be unsigned, and the server would only be able to present denial of existence for the DS records of a parent domain, proving its domain "insecure" (in DNSSEC terms). The modifications in (A) and (B) are most similar to STS (not HPKP) and harden DANE-authenticated HTTPS against downgrade to just DV, and make going to all the trouble of supporting the extension at the server a tangible security benefit. Absent such a benefit, no reasonable server operator will implement the extension. Just deploying a WebPKI certificate, which is necessary in any case, provides the same protection with less effort. The pin-time in (B) also allows servers to signal a zero pin time, and thus indicate an incomplete deployment, reducing breakage when clients find the extension partially deployed, but decide to expect it anyway for security reasons. The pin (pinning just the boolean presence of the extension, like STS pins availability of TLS) would not pin any of the TLSA data, that's subject to the normal, and typically short, DNS TTLs should the client choose to cache the presented DNS records. Its lifetime would be measured in hours (not seconds) and I'd go with a 16-bit value that represent any time from 0 hours (partial deployment) to 65535 hours which is close to 7.5 years. The pin is set (or reset to a new value) when the server performs a handshake in which the extension is present with a non-zero TTL, and either provides matching TLSA records or a valid denial of existence (and is authenticated via WebPKI). For browser HTTPS, (in a separate specification) in might make sense to limit DANE support to just the "restrictive" case, PKIX-TA(0) and PKIX-EE(1). There are many in the TLS and browser communities who don't trust the security of DNSSEC, and would be reluctant to authenticate sensitive browser connections based on DANE alone. That's fine. Just as DANE for SMTP limits the scope to DANE-TA(2) and DANE-EE(3) for reasons explained in section 1.3 of RFC7672, the converse can reasonably be argued for browsers. This suggests even more strongly that DANE stripping matters (if "restrictive" turns out to be the main purpose of DANE in that space) and that this specification needs to harden DANE against downgrades. I should also mention that there is a user community that expects the IETF to make DANE support work in browsers and which would be once again left frustrated with the specification failing to meet their expectations. For a published example: = https://service.networking4all.com/hc/en-us/articles/115001319589-Wat-is-D= ANE-en-DNSSEC- but I've certainly been party to various conversations with users where want DANE to work for their Web servers and browsers, the finer points to be worked out by this WG and browser/web server developers. And yet, as it stands, the deployment cost-benefit analysis for this extension in existing applications plays out as follows: COSTS: * You still manage WebPKI certificates to support the majority of = existing clients. * If the WebPKI is compromised, you're compromised. * If DNSSEC is compromised, you're compromised * You pay the complexity cost of also supporting the extension * You might present incorrect TLSA records and the connection might = fail even when it would otherwise succeed with WebPKI BENEFITS: * Nothing other than bragging rights that you're cool enough to deploy = a shiny new technology I think that users deserve better than that, and that the extension = should have tangible security benefits not only in greenfield applications where DANE is the = mandatory authentication mechanism, but also in legacy applications where deployment would = necessarily be incremental and initially slow. Yes, there is not today an immediate backlog of implementations waiting = to adopt the specification into legacy spaces. The same was true for DANE in RFC6698 = when the specification was completed in Aug 2012. The first substantive = implementation work did not begin until Feb/Mar of 2013 and its later adoption was = substantially driven by the unanticipated news in June of that year. We don't know what the future will bring, the WebPKI is certainly = looking much more fragile lately than it did in the past with multiple failures at various = CAs, and the health of the ecosystem threatened by a new economic reality. It is = prudent to have alternatives "in the wings", even if there is not an immediate = rush to adopt. This specification should be sufficiently robust to support not only the = immediate narrow DPRIV use-case, but also other use-cases. What's more adding = support for (A) and (B) in no way burdens the immediate adopters, all they suffer is = a short delay in the publication of the final document. They can ignore the pin = TTL, and given mandatory TLSA records are certainly not compelled to generate = denial of existence given that they're planning to have TLSA records. It may = however turn out that even there a capability to vend denial of existence could = prove useful. In summary, the present specification fails to address its motivating = use-cases, provides no incremental adoption path, and is only narrowly fit for = purpose with some new applications, but provides no alternative security mechanisms = in the existing application spaces where direct use DNSSEC by the client = (bypassing this extension) is not an option. This is why my "hum" is for both (A) and (B), i.e. (C). --=20 Viktor. From nobody Wed Apr 4 16:38:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6E126FB3 for ; Wed, 4 Apr 2018 16:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xYgMvQ8O9fl0 for ; Wed, 4 Apr 2018 16:38:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F7D126C2F for ; Wed, 4 Apr 2018 16:38:10 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 031107A330D for ; Wed, 4 Apr 2018 23:38:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 4 Apr 2018 19:38:09 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:38:13 -0000 > On Apr 4, 2018, at 6:12 PM, Melinda Shore = wrote: >=20 >> I support publication of the document as is. I would also be >> comfortable with a minor modification to say that TLSA certificate >> usages 0 and 1 (the restrictive ones) MUST NOT be used with this = mechanism. >=20 > The addition of text that clarifies that seems absolutely reasonable > to me. That addition is fundamentally flawed. THere is no realistic scalable adoption model in which a server publishes DANE-only certificates to and expects thereby to support a meaningful set of clients that would don't trust Let's Encrypt (for example). Nor do I see the browser community accepting DANE alone as a sufficient security mechanism. > I do think there would be a problem with adding additional complexity Ignoring a 16-bit field in the extension adds ZERO complexity. Not sending a denial of existence response and not accepting one if given (in applications that don't need this feature) likewise adds ZERO complexity. The complexity argument is a mirage. > to the extension to support functionality that nobody has said that > they intend to use (including the proponents of the changes), given > that the changes would not be introduced to correct an error in > the existing spec. The changes are needed to support the extension in any application where adoption is necessarily incremental (i.e. all existing WebPKI applications). To refute that, one would need to refute the security and cost-benefit analyses in my post and somehow demonstrate "alternative facts" that establish the viability of an additive model, and some other way to compensate for the fact the present extension has a major downgrade hole. It is precisely the "restrictive" use-case that Richard says can be left out that users expect from DANE, that is tangible benefit over and above just using WebPKI, from say Let's Encrypt. --=20 Viktor. From nobody Wed Apr 4 18:54:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B63126B72 for ; Wed, 4 Apr 2018 18:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5W02ohXGMsJi for ; Wed, 4 Apr 2018 18:54:48 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980E112D7ED for ; Wed, 4 Apr 2018 18:54:48 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id s10-v6so14937472plp.0 for ; Wed, 04 Apr 2018 18:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8uvGVKDEPgW3tSztk2WYdBnBwDnBZiXj4vLo6g72Pj0=; b=VkVOHl8UU+OY46AtKWEADHDZ4w5sY5R7F8R1WPLFLwwaJ7p3ZaeoNKcHSMAGrUFy1G AgEkfCqeY31Dt2OBfmNhLIoElkR8Virr4qp9atQBotgj5TL+d+v3uD1NHbzGv/I7MJnM myT7FwE6EHxBHrwu+Wa7uKhW4fRKVMya+nYVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8uvGVKDEPgW3tSztk2WYdBnBwDnBZiXj4vLo6g72Pj0=; b=QNJttF3tHDEGCO+uzQkE0zCPWz0OLPs2btwLp4XQv0VwFLPNlqFEbDqVbQAcK54dH5 hjbMr1ZNCmbtxcNgCvOTvERKz3uRj0mgRUogDgDzOA2epbf8R4MajwtY43wdxW7Ll6XX 7lRAkD36TYjfc3xR/hh0PGK2qEK8nNgAtEN7cWT/6a24IZm3bRcdbyXvZx5dKsKn2vkn JwrVATWUb56irrifJBgi5dOyZg9XfVaNGCX5Yqww6x6ZqHexXweeTNIEh6yv3BS8F10s uvjHnhpKCBjXKnZ+jUm5EspquUvZCWjpLjRPmCxAEG0wKChPq7qT6tmJnr74i2Z/f37Z Qncg== X-Gm-Message-State: AElRT7GQ12yxqQwtGhPfEGPZjeQRyR0+HdCjqHTH2lB00CcxIo79uN8C H1As7OM/bOPls5Mi/+fqW/YNKw== X-Google-Smtp-Source: AIpwx49yiEqNIrqwtxOUK0gxJ/qDPPueRc8DSh5lhAAB0beeGpTETyM65bk9Rj45LJF8JAKVvmG9Cw== X-Received: by 10.98.234.13 with SMTP id t13mr9183616pfh.56.1522893288006; Wed, 04 Apr 2018 18:54:48 -0700 (PDT) Received: from [5.5.33.150] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m23sm13745794pfg.75.2018.04.04.18.54.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 18:54:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <152251888958.19839.2574354810199784685.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 20:54:39 -0500 Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152251888958.19839.2574354810199784685.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Eric Rescorla's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 01:54:51 -0000 > On Mar 31, 2018, at 12:54, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-04: Yes >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > requires standards action. Not all parameters defined in standards > track documents need to be marked as recommended. > It might be useful to capitalize Recommended here. Here and a couple of other places I capitalized recommended. > been through the IETF consensus process, has limited applicability, > or is intended only for specific use cases. > I think technically it has "Recommended =3D No=E2=80=9D yeah the OPSDIR review noted this as well so I changed the sentence to = be: If an item is not marked as recommended it does =E2=80=A6 = https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62/file= s > Note: Supported Groups marked as "Yes" are those allocated via > Standards Track RFCs. Supported Groups marked as "No" are not; > supported groups marked "No" range from "good" to "bad" from a > This may need a revision because some have not been allocated that = way. Supported Groups is the one real odd-ball here because they were = originally not on standards track, but 4492bis is going to move them = there. Would this work: These =E2=80=9CYes=E2=80=9D groups are taken from Standards Track RFCs; = {{?I-D.ietf-tls-rfc4492bis}} elevates secp256r1 and secp384r1 to = Standards Track. > thus requiring a new construction. The exporter interface = remains > the same, however the value is computed different. > differently. PR for the three changes: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/72 From nobody Wed Apr 4 18:57:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F34412785F for ; Wed, 4 Apr 2018 18:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 189RJ_tIAADO for ; Wed, 4 Apr 2018 18:57:21 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7D7126C19 for ; Wed, 4 Apr 2018 18:57:20 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id 61-v6so14941353plb.2 for ; Wed, 04 Apr 2018 18:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gVkUvg92dBdgjF487YxS2llgIGZLqJWTEtZcatovODk=; b=GRSdI27Q1m1C3Bh/JrAJuelB8KP0Zgu6H+Q4G0BUeOXxqzufgl4XdOq9z8isS182mR Fj2wBXayGY91HoioLOIvWYP2fcWYgzrXAsLR+Dz/Gn7zn3LVO+M0xA1cIxB+q8R8aoOK svD2j423lKzPkIiBkERhtK9TxBzXdBxU7SvPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gVkUvg92dBdgjF487YxS2llgIGZLqJWTEtZcatovODk=; b=KNQbxnUmPDUV0ukm7o3ZwvaASa8ql+olyoU5zjYc5xnD02tZwOYDyAemr/KK1HdJ1f ZkXzSHayOn7T0kD7Kg/f95DNE56gRssSK1G5L8YJQDkK2uqGHs0aia5xQKOAkyiVY+4F ipfzB+qgLGGavSnFSBvxUXWe+CqzbTi0FcwW6k5SOpjUOilV75T+EQg+WHC2GX9zXY6I bWLZ1KLflbLEwBWmb4qRPbuFwxHCjUq16deo6oDa0EkjvNnWXrsfkIFbxY1trOtROu6/ 4M4JDHiUefFcAigjU5EXkx59vAXwcywrkMCfqFmLlGMWDmn0mIKxdtOxVONMKREn3EsC L1uw== X-Gm-Message-State: AElRT7Evj4OYZyeWPV8S+43oOy5Cm+663C9EITU5Do/OwfXE6vhIJ2I4 /TVRn5juJvfbAVnRHSG4GtnwOg== X-Google-Smtp-Source: AIpwx4/4pl2i7IoiReo0dGBhrJvkoszUOUOJnZtxrSgJVSYbTJrnScM9roc46UiA26E3e5BOtHD2LA== X-Received: by 10.99.119.195 with SMTP id s186mr13738961pgc.453.1522893440576; Wed, 04 Apr 2018 18:57:20 -0700 (PDT) Received: from [5.5.33.150] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g23sm11408100pfi.171.2018.04.04.18.57.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 18:57:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <152284090016.23908.302744975919228304.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 20:57:12 -0500 Cc: The IESG , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7CA1C369-14A1-4782-930E-D3A0CF9E0E3A@sn3rd.com> References: <152284090016.23908.302744975919228304.idtracker@ietfa.amsl.com> To: Ignas Bagdonas X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 01:57:23 -0000 > On Apr 4, 2018, at 06:21, Ignas Bagdonas wrote: > > Ignas Bagdonas has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-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-iana-registry-updates/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > s/aligment/alignment > s/prviate/private I think this ought to fix it up: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/73 From nobody Wed Apr 4 19:08:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC92A127076 for ; Wed, 4 Apr 2018 19:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yQB3ZhmEA5j for ; Wed, 4 Apr 2018 19:07:58 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B85126B72 for ; Wed, 4 Apr 2018 19:07:58 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id i28-v6so25581753otf.8 for ; Wed, 04 Apr 2018 19:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nSha1E6bphe0AnjFR4dApS/xI/WbSOdqlWCOz1E2XME=; b=bRSyiSuN8fUEOA30XjCFcbDhDv2qBvvT1a0dJ/D4nC6J0pbdHLp6VquUdBB833iVCl ed8dq3tkkGHQ3cCYUCpWh2LoVx19vXXV0ce0n3y0dNmXjBViPZNNpdbWQjh42W8QlCx9 j9iDB4hr3zUcc4ZpNAv4pKXm0+yEF1h9ziJ2apobjYTPBOwGOWyDfvXImWa4OYnKuzvC k3R3jcrmtdYdqcBOcXYmd7UPXhlJVxuRzyvOQXtapUJINw4U7J2uEfwWvyLAsgXX44cs 2UIcM/sfiIIaWrMCK1gwoPPrdyHJPWtFwbQGi2SFUiy0N1P20eEupezrxSkO1IDkoTjz DpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nSha1E6bphe0AnjFR4dApS/xI/WbSOdqlWCOz1E2XME=; b=dYdLiBVGtS1D0gXOMhDJ4X+mVaSibXdsisYv3hFY/JuP3vnVjDNxYf/eeOeG+iwEoP XfFuvoY4tMyI9C7PBPBfH7tDO2Nq2IAcjRR38Z24/bIJkEPcQSVtnjtrUchzVpmO6GwD ZIP/jeSlxwjACR6AnLBk4E21mO20jpkkrHsuBdjtJZ1E2wrQLpE+zBbhFv+KeMl/bARG 1Od/uU4gi+93y9GR2S9x2JSKz70ZJN+8weNb5vaRjbLRCyuPmaEHNdvC+G7TBcN61Jfn WupGlIdGEDso7pLx/WIf1vVFeCm61op3wPVtQqCgrpyqy2xPDYU7ELBPAx6EnUq00QzQ k3jg== X-Gm-Message-State: ALQs6tAElkjua6NQ3WpNkHjlZLHEsLOtR50tyOCHDcE+nKEk8xJzMFzS TWFRe4rW/m5yv17iJnMTYvJvAwD1TUrPEh4dVxfWqA== X-Google-Smtp-Source: AIpwx4/bIZNGCSTU484DkqRR/No0OgFQAnmHx6y1WjJcZP83ZcU38Ce4ptxRhJx5MCb6B03sPu9HR/A+D5YMCZBr66E= X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr5994278otd.394.1522894077562; Wed, 04 Apr 2018 19:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 19:07:57 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 5 Apr 2018 12:07:57 +1000 Message-ID: To: TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:08:02 -0000 Given what we've learned about pinning (it is being removed from browsers), this seems like a bad plan to me. Your cost benefit analysis seems about right though. On Thu, Apr 5, 2018 at 9:27 AM, Viktor Dukhovni wrote: > > >> On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: >> >> - Recommendation of adding denial of existence proofs in the chain provided by the extension >> - Adding signaling to require the use of this extension for a period of time (Pinning with TTL) > > These are indeed the immediate proposed fixes, and ultimately the consensus call will be about > whether the fixes should be formalized and integrated or the document advanced as-is, but before > we consider them in a vacuum, I'd like to explain in some detail *why* they are needed. This > requires firstly an examination of why the extension is needed in the first place, and what > use-cases it should address. This will be detailed below, but first: > >> This is a consensus call on how to progress this document. Please answer the following questions: >> >> 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work? >> >> If the answer to 1) is no then please indicate if you think the working group should work on the document to include >> >> A) Recommendation of adding denial of existence proofs in the chain provided by the extension >> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL) >> C) Both > > For the record, (C) both. And now to explain why: > > The first thing to understand is why this extension is needed in the first place. A partial > answer can bee seen in the introduction to the draft. Please pardon burying the lede, below > I quote from the text of the introduction in order of presentation, but the main point is closer > to the end: > > ----------------- > This draft describes a new TLS [RFC5246] [TLS13] extension for > transport of a DNS record set serialized with the DNSSEC signatures > [RFC4034] needed to authenticate that record set. > ----------------- > > We should note that an empty record set (NXDOMAIN or NODATA) is still > a record set, and DNSSEC *authenticates* denial of existence, and it > is necessary to also support denial of existence, in order to support > downgrade-resistance against "TLSA-stripping". The reason is that this > extension is not being introduced into brand new internet in which the > CA/B forum WebPKI does not exist and DANE will be the *only* way for > TLS clients to authenticate servers. For this extension to coexist > with the WebPKI clients will need to be able to *some* servers via > DANE and others (those that don't have DANE TLSA records) via the > existing WebPKI. > > Suppose that, in the absence of authenticated denial of existence, > and clients being able to rely on continued support for the extension: > > * As will be the cast for most existing applications, the client > is willing to use the WebPKI when DANE TLSA records don't appear > to be availble. > > * An attacker is able to obtain a fraudulent WebPKI certificate. > > Then the attacker can impersonate the target server by leaving out > the extension and presenting just the fraudulent WebPKI certificate, > and the client will have to accept this even when the real server > previously employed the extension and provided TLSA records. > > What the above establishes is that in mixed environments, i.e. > almost all use-cases for this specification, TLSA records provide > no additional protection, if WebPKI fails, security is compromised > even with DANE. > > Some have argued that this is OK, that even though the above > "restrictive" use-case is unavailable we still get an "additive" > use case, where servers can be authenticated with DANE when > that happens to be present and otherwise WebPKI. Sadly, that > use-case is largely a mirage. Firstly, given the existing > dominant client base that only supports WebPKI, any server > would in any case still need WebPKI certificates (say from > Let's Encrypt), and that will suffice for all clients both > those that support DANE and those that don't. Thus enabling > DANE on the server, only makes it possible to impersonate > the server if DANE is compromised, but does not defend against > WebPKI compromise. So the server gets more complexity, and > reduced security, and maybe even increased risk of failure > if the TLSA records are managed carelessly and fail to match. > > No rational server operator will employ the "additive" mode. > Some DANE idealists might do it to signal their support for > the technology, but this will be futile, they'll get no real > benefit from doing so. > > Continuing on with the introduction: > > ----------------- > The intent of this > proposal is to allow TLS clients to perform DANE Authentication > [RFC6698] [RFC7671] of a TLS server without performing additional DNS > record lookups and incurring the associated latency penalty. It also > provides the ability to avoid potential problems with TLS clients > being unable to look up DANE records because of an interfering or > broken middlebox on the path between the client and a DNS server > [HAMPERING]. And lastly, it allows a TLS client to validate the > server's DANE (TLSA) records itself without needing access to a > validating DNS resolver to which it has a secure connection. > ----------------- > > Here we see the promise of being able to get by without having > access to a validating resolver, but validating resolvers deliver > both signed data when present and signed proof of non-existence when > the requested records are absent. But most importantly: > > ----------------- > This mechanism is useful for TLS applications that need to address > the problems described above, typically web browsers or SIP/VoIP > [RFC3261] and XMPP [RFC7590]. > ----------------- > > This plainly shows that browser HTTPS was a motivating use-case > for the extension. Indeed earlier mention of latency concerts is > also based on the reasons why browsers don't (want to) do DANE even > when direct DNSSEC lookups are possible. > > Not just browsers, no existing application can adopt specification > incrementally. Even if the extension is required in the application, > it is unrealistic to expect that all server domains will rapidly > adopt DNSSEC. At the moment there are ~6 million DNSSEC-signed > domains, substantially concentrated in northern Europe, with > fairly thin adoption generally (only ~800K domains out of ~120 > million in .com). An application that expects the extension > should expect to not find TLSA records for many servers it > connects to, indeed many server domains will be unsigned, and > the server would only be able to present denial of existence > for the DS records of a parent domain, proving its domain > "insecure" (in DNSSEC terms). > > The modifications in (A) and (B) are most similar to STS (not HPKP) > and harden DANE-authenticated HTTPS against downgrade to just DV, > and make going to all the trouble of supporting the extension at > the server a tangible security benefit. Absent such a benefit, > no reasonable server operator will implement the extension. Just > deploying a WebPKI certificate, which is necessary in any case, > provides the same protection with less effort. > > The pin-time in (B) also allows servers to signal a zero pin time, > and thus indicate an incomplete deployment, reducing breakage when > clients find the extension partially deployed, but decide to expect > it anyway for security reasons. > > The pin (pinning just the boolean presence of the extension, like > STS pins availability of TLS) would not pin any of the TLSA data, > that's subject to the normal, and typically short, DNS TTLs should > the client choose to cache the presented DNS records. Its lifetime > would be measured in hours (not seconds) and I'd go with a 16-bit > value that represent any time from 0 hours (partial deployment) > to 65535 hours which is close to 7.5 years. > > The pin is set (or reset to a new value) when the server performs > a handshake in which the extension is present with a non-zero TTL, > and either provides matching TLSA records or a valid denial of > existence (and is authenticated via WebPKI). > > For browser HTTPS, (in a separate specification) in might make > sense to limit DANE support to just the "restrictive" case, > PKIX-TA(0) and PKIX-EE(1). There are many in the TLS and > browser communities who don't trust the security of DNSSEC, > and would be reluctant to authenticate sensitive browser > connections based on DANE alone. That's fine. Just as > DANE for SMTP limits the scope to DANE-TA(2) and DANE-EE(3) > for reasons explained in section 1.3 of RFC7672, the converse > can reasonably be argued for browsers. This suggests even > more strongly that DANE stripping matters (if "restrictive" > turns out to be the main purpose of DANE in that space) and > that this specification needs to harden DANE against downgrades. > > I should also mention that there is a user community that expects > the IETF to make DANE support work in browsers and which would be > once again left frustrated with the specification failing to meet > their expectations. For a published example: > > https://service.networking4all.com/hc/en-us/articles/115001319589-Wat-is-DANE-en-DNSSEC- > > but I've certainly been party to various conversations with users > where want DANE to work for their Web servers and browsers, the > finer points to be worked out by this WG and browser/web server > developers. > > And yet, as it stands, the deployment cost-benefit analysis for this > extension in existing applications plays out as follows: > > COSTS: > > * You still manage WebPKI certificates to support the majority of existing clients. > * If the WebPKI is compromised, you're compromised. > * If DNSSEC is compromised, you're compromised > * You pay the complexity cost of also supporting the extension > * You might present incorrect TLSA records and the connection might fail even when > it would otherwise succeed with WebPKI > > BENEFITS: > > * Nothing other than bragging rights that you're cool enough to deploy a shiny new technology > > I think that users deserve better than that, and that the extension should have tangible > security benefits not only in greenfield applications where DANE is the mandatory authentication > mechanism, but also in legacy applications where deployment would necessarily be incremental and > initially slow. > > Yes, there is not today an immediate backlog of implementations waiting to adopt the > specification into legacy spaces. The same was true for DANE in RFC6698 when the > specification was completed in Aug 2012. The first substantive implementation work > did not begin until Feb/Mar of 2013 and its later adoption was substantially driven > by the unanticipated news in June of that year. > > We don't know what the future will bring, the WebPKI is certainly looking much more > fragile lately than it did in the past with multiple failures at various CAs, and > the health of the ecosystem threatened by a new economic reality. It is prudent > to have alternatives "in the wings", even if there is not an immediate rush to > adopt. > > This specification should be sufficiently robust to support not only the immediate > narrow DPRIV use-case, but also other use-cases. What's more adding support for > (A) and (B) in no way burdens the immediate adopters, all they suffer is a short > delay in the publication of the final document. They can ignore the pin TTL, > and given mandatory TLSA records are certainly not compelled to generate denial > of existence given that they're planning to have TLSA records. It may however > turn out that even there a capability to vend denial of existence could prove > useful. > > In summary, the present specification fails to address its motivating use-cases, > provides no incremental adoption path, and is only narrowly fit for purpose with > some new applications, but provides no alternative security mechanisms in the > existing application spaces where direct use DNSSEC by the client (bypassing > this extension) is not an option. > > This is why my "hum" is for both (A) and (B), i.e. (C). > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 4 19:15:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5012D7F0 for ; Wed, 4 Apr 2018 19:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ce8-1vfNgiye for ; Wed, 4 Apr 2018 19:15:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B81127775 for ; Wed, 4 Apr 2018 19:15:27 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4E1FC7A330D for ; Thu, 5 Apr 2018 02:15:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 4 Apr 2018 22:15:25 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:15:30 -0000 > On Apr 4, 2018, at 10:07 PM, Martin Thomson = wrote: >=20 > Given what we've learned about pinning (it is being removed from > browsers), this seems like a bad plan to me. Question, are you thinking of HPKP or STS? HPKP pins rather volatile data, and is too fragile to be used (something I would have predicted without even running the experiment). STS and this proposal pin a capability: * STS: I can be relied on to support TLS * option (B): I can be relied on to support the TLS extension for the specified itme (or not when the TTL is 0). So I rather that the unsurprising failure of HPKP is the wrong lesson to apply. STS seems successful enough, indeed in the UTA working group Google, Microsoft, Yahoo et. al. are standardizing an STS for SMTP (as a work-around for lack of DNSSEC in their domains) and this pins an STS policy for timescales comparable to the proposal here. The UTA STS draft has just cleared WG last call, Should I expect that = the folks in this WG opposing the pin for the DANE chain extension are = strongly opposed to SMTP STS and will argue against it in IETF last call and if IESG members in IESG review? --=20 Viktor. From nobody Wed Apr 4 19:23:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935B712D7ED for ; Wed, 4 Apr 2018 19:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkERjR_LXwqi for ; Wed, 4 Apr 2018 19:23:19 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67561127775 for ; Wed, 4 Apr 2018 19:23:19 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id h26-v6so25574072otj.12 for ; Wed, 04 Apr 2018 19:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xGE3kHEWvT75xJk8U2m0Or/y2n6p8hjFjwfhZQBK2o4=; b=JBao0MIPcVT24X1QcB6VmGBrG5tyLZp33skX8+A3B0t7nfXf9PAobJGV5QV5vwY49M gryXHl8oCI8j+PmVNHiUEKHFczIBLglkZSTjFmbcqRFNUWeuYxr6YIXCC5CqgKTh05VV /tximh8OgJwUSWwF2cJwAPY7JiOwMoSBQxTV4kqk1Wb5R9YiYpvrYnWB5lOEHIbjEJvm ojfcT7QhdlvmPRJJKaFydGqKPkhG8kr4WXhjZljvIeQfQ5eXUJwu90O7wqTJo+ThzeXv lrtljwcXXwTa3fyPDriKy1NhigFr5eAtuaEwTwzqvNEGqFYTenMcYL+JnnZ3WrqJhl9U PXow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xGE3kHEWvT75xJk8U2m0Or/y2n6p8hjFjwfhZQBK2o4=; b=l+28hU9T/h35IpvE3Zs3RX7qBGo2qYC+0vvTI3GD3vPYGvoPJi9femo6WutTTy0C0z Ty4+6MpaKN7NcOwWQQyEerMKfryvfeMwY4tlfuO6REwilsvAXBqdozKeVFCJtswyfvt+ Y1D4wIOfcF/Ww3jcyX/RzHRU+06OcipARp92LxaE3zeFGpBbXtcyNE7KoqjqvvvIQWWd fuME5qLAg8ZFljhJ6AzN5zzQGG1eqY+nHIRxsG8OPcWTTYW8BOwvZq62TRAGHT7VeQC2 YGgcUp9UTU5ZB1xCDUbQMKVLzGVsLzWorDMvmzolzuXpOi5YbhCpEomGdnaAOhkDP6tJ lAXw== X-Gm-Message-State: ALQs6tBDvKB4IdrWvZHvPSr72K0sXLGCDtG3UC909jgozmOfXqWnr1yQ CLiMnHhpTnIXEoAuZID0IEUk0wwpjNHUrZhxMWtTeg4t X-Google-Smtp-Source: AIpwx48dKCiW6krXcOZ4Phl0qTkPmdIcXlsF/vprLcERO2p/V9dPUvRyItF6lruldVk+Uocedm81gf50xVPo8mscOmI= X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr9368139oth.217.1522894998718; Wed, 04 Apr 2018 19:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Wed, 4 Apr 2018 19:22:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 4 Apr 2018 19:22:38 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000006de0580569109f67" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:23:21 -0000 --0000000000006de0580569109f67 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 7:15 PM, Viktor Dukhovni wrote: > > > > On Apr 4, 2018, at 10:07 PM, Martin Thomson > wrote: > > > > Given what we've learned about pinning (it is being removed from > > browsers), this seems like a bad plan to me. > > Question, are you thinking of HPKP or STS? HPKP pins rather volatile > data, and is too fragile to be used (something I would have predicted > without even running the experiment). STS and this proposal pin a > capability: > > * STS: I can be relied on to support TLS > * option (B): I can be relied on to support the TLS extension > for the specified itme (or not when the TTL is 0). > I don't think that this comparison is particularly apt.The representation in HSTS is simply "I support HSTS". The representation in HPKP is "I will use either consistent keying material *or* a consistent set of CAs". The representation here is "I will continue to have DNSSEC-signed DANE records". That is a significantly more risky proposition than continuing to support TLS (and I'm ignoring the risk of hijacking attacks that people were concerned with with HPKP), and so this seems rather more like HPKP to me. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006de0580569109f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 7:15 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:


> On Apr 4, 2018, at 10:07 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> Given what we've learned about pinning (it is being removed from > browsers), this seems like a bad plan to me.

Question, are you thinking of HPKP or STS?=C2=A0 HPKP pins rather vo= latile
data, and is too fragile to be used (something I would have predicted
without even running the experiment).=C2=A0 STS and this proposal pin a
capability:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * STS:=C2=A0 I can be relied on to support TLS<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 * option (B): I can be relied on to support the= TLS extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the specified itme (or not when the = TTL is 0).

I don't think that this = comparison is particularly apt.The representation in HSTS
is simp= ly "I support HSTS". The representation in HPKP is "I will u= se either consistent
keying material *or* a consistent set of CAs= ". The representation here is "I will
continue to have = DNSSEC-signed DANE records". That is a significantly more risky
<= div>proposition than continuing to support TLS (and I'm ignoring the ri= sk of hijacking
attacks that people were concerned with with HPKP= ), and so this seems rather
more like HPKP to me.

<= /div>
-Ekr




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

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

--0000000000006de0580569109f67-- From nobody Wed Apr 4 19:30:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB8D12785F for ; Wed, 4 Apr 2018 19:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjZtymJBkeM4 for ; Wed, 4 Apr 2018 19:30:21 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30975126B6D for ; Wed, 4 Apr 2018 19:30:21 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E22F9A00400F; Wed, 4 Apr 2018 19:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pwT0FK5dPcseKh ReX4oPivXS1Bg=; b=VGiNpgUcZS7kope689PlZOK0JWfr8LHbHtbOuO9fAyX71R xNX4kWTL23eoUhUCMrd1i0ViHhMQU97NItX29mJFgBRG1C215Ngbe0KBHL7428IN YOy/6aZdAnXAXoc5hIxhl8Ezf12+Q+U4/6qjaxoPce393v7bx8XYSZVl1+xtY= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 8EEE8A000B3C; Wed, 4 Apr 2018 19:30:20 -0700 (PDT) Date: Wed, 4 Apr 2018 21:16:25 -0500 From: Nico Williams To: Joseph Salowey Cc: "" Message-ID: <20180405021624.GF25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:30:23 -0000 On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote: > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the working > group is either to publish the document as is or to bring the document back > into the working group to address the following issues: For the record, I've had a document need changes after IESG publication approval that were then made with a WG LC for those changes rather than a repeat of WG LC, IETF LC, and IESG review. I'm surprised that this changes should require "bring[ing] the document back into the working group" if by that you mean going through the full process all over. Though, to be sure, I don't object if that's the required path now, but I don't want people to feel compelled to be against this LC on account of the delay in publication being much bigger, not if there's a shorter method. (Also, I don't mind a delay all that much: it's hardly that big a deal; RFCs often end up stuck in AUTH48 for much much longer!) > - Recommendation of adding denial of existence proofs in the chain provided > by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? I do not. > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both At least (B), and preferably (C). My rationale for (B) is that this is the sort of thing where adding it from the get-go will yield deployment where DANE is not mandatory for the application whereas not adding it now will yield non-deployment of DANE in such applications for a very long time. My rationale for (C) is that (A) is trivial, so might as well throw it in. Mind you, (B) is also trivial (two bytes! to be conveyed however you want, with 0 -> clear the pin to DANE). Thanks, Nico -- From nobody Wed Apr 4 19:34:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACDD12D947 for ; Wed, 4 Apr 2018 19:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 qz1Eh0mt2H4l for ; Wed, 4 Apr 2018 19:34:29 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CC812DA29 for ; Wed, 4 Apr 2018 19:34:29 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 161E3A00400F; Wed, 4 Apr 2018 19:34:29 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 442D2A000B3C; Wed, 4 Apr 2018 19:34:28 -0700 (PDT) Date: Wed, 4 Apr 2018 21:20:07 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180405022007.GG25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:34:33 -0000 On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > I don't think that this comparison is particularly apt.The > representation in HSTS is simply "I support HSTS". The representation > in HPKP is "I will use either consistent keying material *or* a > consistent set of CAs". The representation here is "I will continue to > have DNSSEC-signed DANE records". That is a significantly more risky > proposition than continuing to support TLS (and I'm ignoring the risk > of hijacking attacks that people were concerned with with HPKP), and > so this seems rather more like HPKP to me. Without a TTL (with zero meaning "clear the pin to DANE") this extension can only really be used with mandatory-to-use-with-DANE protocols, where the commitment to "continue to have DNSSEC-signed DANE records" is implied. The TTL allows one to put a bound on that commitment, thus alleviating the risk. That's the whole point: to alleviate the risk of commitment to DANE in order to not discourage opportunistic deployment. Nico -- From nobody Wed Apr 4 19:37:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1853812D7F0 for ; Wed, 4 Apr 2018 19:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 6zS39QmL9sIg for ; Wed, 4 Apr 2018 19:37:05 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D849512785F for ; Wed, 4 Apr 2018 19:37:05 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 1F769A004012; Wed, 4 Apr 2018 19:37:05 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id C198AA00400F; Wed, 4 Apr 2018 19:37:04 -0700 (PDT) Date: Wed, 4 Apr 2018 21:22:29 -0500 From: Nico Williams To: Martin Thomson Cc: TLS WG Message-ID: <20180405022228.GH25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:37:07 -0000 On Thu, Apr 05, 2018 at 12:07:57PM +1000, Martin Thomson wrote: > Given what we've learned about pinning (it is being removed from > browsers), this seems like a bad plan to me. You can use this TTL, or not. You're not required to set it to any value other than the max ("infinity") or min (zero) if you don't want to. You can pin or not pin. You can make DNAE mandatory (TTL set to infinity) or not. Adding this TTL cannot have a negative impact on the initial application of this extension. Nico -- From nobody Wed Apr 4 19:39:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6E129BBF for ; Wed, 4 Apr 2018 19:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIOluuCiSO41 for ; Wed, 4 Apr 2018 19:39:54 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 BFDE212426E for ; Wed, 4 Apr 2018 19:39:54 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id m22-v6so25605920otf.10 for ; Wed, 04 Apr 2018 19:39:54 -0700 (PDT) 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; bh=CYoGMMAx0rvc440oph2krUZCYwKrMFtWwLJtIta/AUs=; b=xcK2EJXbSzhQvGBucNiCAzZAxJCCOTC3NqEfQHakYiIrlBoAjHHzF24dxwidPrNs7J X+xlQPx4vECGCwM3L/oOxs5aKZr0/VF7ORFwJSEuA0Q+214wHRPz+K5oVdcFcFOkBUQe /oidzihQ5yyu5Cse+mnD7PetqIzEuaeG3SYtGps83EpHqUeZ0GaZt9/Yxc1cIKL44Hy6 ShqpDJ71+7rbwCRSJKmx2PmSl/KlTvChSIlBI4XgkLTZwmJb9wq3fH7YOIR6V7J+V4EI 7UBEcrF74tbD06h9sHEGKhD3Il773+w3niLgirydHeu+WitlCwLMUCe2MLzM9phmXO8B PFUw== 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=CYoGMMAx0rvc440oph2krUZCYwKrMFtWwLJtIta/AUs=; b=hry+5YH+JgLY/+Tdtmxf2+QHTqlprJFaGUqHUtqAaJbETgpdO72rXlIF1idFFr7cIl lD3wV/ogduifGm5CW3zrFm3fldykMXM+LBVD84BYPz24xAp5tbS1RmHqf/z/lzzWzhTX i5mqVp3K/8vS9Lrz5iBFDyLU1tLd/+0VsbC6mEz+7I45wGD+2FJkTcSd6iJXcGPry2xo 6LzfDC1/Au3RDVHpCBlojYDW6IqOy7O1NljpHk705hPW03vz5FjgBW7y4Hlcd+Wty/zw mb1+X9qfbmLnsdzPOZhAzJ6KM6EoVr6BFPDR9npTjXiTGLqxCFUOGc8KIxuTtz46HW9Z E/MA== X-Gm-Message-State: ALQs6tDhoINwAWzn2psHRKKwwga4i6n84kYQejuI0gCpNBZXGGZrqWxV lZcp1hoB74yh44e7NRRNzoz2HgW5YEgfA0Cy+mAQeg== X-Google-Smtp-Source: AIpwx4/zcanwMGfIj/Q0PJp6xCMLMNGHFxbaf1K5oPRfrR3+N8V5LfK1j9EOMpNWCHlH2/0wLRyGe5awmnsBcJ+mPmk= X-Received: by 2002:a9d:305a:: with SMTP id w26-v6mr11798211otd.292.1522895994129; Wed, 04 Apr 2018 19:39:54 -0700 (PDT) MIME-Version: 1.0 References: <20180405022007.GG25259@localhost> In-Reply-To: From: Richard Barnes Date: Thu, 05 Apr 2018 02:39:43 +0000 Message-ID: To: Nico Williams , "" Content-Type: multipart/alternative; boundary="000000000000c2a7fa056910dac1" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:39:57 -0000 --000000000000c2a7fa056910dac1 Content-Type: text/plain; charset="UTF-8" Re-adding the list. On Wed, Apr 4, 2018, 22:39 Richard Barnes wrote: > > > On Wed, Apr 4, 2018, 22:34 Nico Williams wrote: > >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> > I don't think that this comparison is particularly apt.The >> > representation in HSTS is simply "I support HSTS". The representation >> > in HPKP is "I will use either consistent keying material *or* a >> > consistent set of CAs". The representation here is "I will continue to >> > have DNSSEC-signed DANE records". That is a significantly more risky >> > proposition than continuing to support TLS (and I'm ignoring the risk >> > of hijacking attacks that people were concerned with with HPKP), and >> > so this seems rather more like HPKP to me. >> >> Without a TTL (with zero meaning "clear the pin to DANE") this extension >> can only really be used with mandatory-to-use-with-DANE protocols, where >> the commitment to "continue to have DNSSEC-signed DANE records" is >> implied. >> > > This is just not true. As I said in my earlier message, servers can > switch based on the ClientHello. > > Clients advertise which methods they support, servers switch, and they > both see how often DANE gets used. When it gets high enough, they turn off > the fallback. Just like every other TLS feature we've ever done. > > --Richard > > > >> The TTL allows one to put a bound on that commitment, thus alleviating >> the risk. >> >> That's the whole point: to alleviate the risk of commitment to DANE in >> order to not discourage opportunistic deployment. >> >> Nico >> -- >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000c2a7fa056910dac1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-adding the list.=C2=A0

On Wed, Apr 4, 2018, 22:39 Richard Barnes <rlb@ipv= .sx> wrote:


On Wed, Apr 4, 2018,= 22:34 Nico Williams <nico@cryptonector.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eri= c Rescorla wrote:
> I don't think that this comparison is particularly apt.The
> representation in HSTS is simply "I support HSTS". The repre= sentation
> in HPKP is "I will use either consistent keying material *or* a > consistent set of CAs". The representation here is "I will c= ontinue to
> have DNSSEC-signed DANE records". That is a significantly more ri= sky
> proposition than continuing to support TLS (and I'm ignoring the r= isk
> of hijacking attacks that people were concerned with with HPKP), and > so this seems rather more like HPKP to me.

Without a TTL (with zero meaning "clear the pin to DANE") this ex= tension
can only really be used with mandatory-to-use-with-DANE protocols, where the commitment to "continue to have DNSSEC-signed DANE records" i= s
implied.

This is just not true.=C2=A0 As I said in my earlier message, ser= vers can switch based on the ClientHello.

=
Clients advertise which methods they support, servers swi= tch, and they both see how often DANE gets used.=C2=A0 When it gets high en= ough, they turn off the fallback.=C2=A0 Just like every other TLS feature w= e've ever done.=C2=A0

--Richard



The TTL allows one to put a bound on that commitment, thus alleviating
the risk.

That's the whole point: to alleviate the risk of commitment to DANE in<= br> order to not discourage opportunistic deployment.

Nico
--

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo= /tls
--000000000000c2a7fa056910dac1-- From nobody Wed Apr 4 19:40:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136A812D7F0 for ; Wed, 4 Apr 2018 19:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw0XFg3reJam for ; Wed, 4 Apr 2018 19:40:28 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF93112426E for ; Wed, 4 Apr 2018 19:40:28 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2A439A004012; Wed, 4 Apr 2018 19:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=O5PePXAZEWLH5Z ZnOuC2hBa3oNc=; b=entGX4PrL9or6EehYBpAq4dqgAzs3RrsKFPizKj0WwGm0i VTp4TFSkP2TOnDFoxCSvFdxpo8ep43+yJi405KMLogPEHwZ0ITeoMiOzlwmg1nxL rUoiiV+vFy2wV0LHxW+fkGtZ0MktDcoAKo1RCgbCqZ2jKQ5p9wl6aKByDLd9s= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id A3B12A004017; Wed, 4 Apr 2018 19:40:27 -0700 (PDT) Date: Wed, 4 Apr 2018 21:25:32 -0500 From: Nico Williams To: Paul Wouters Cc: Joseph Salowey , "" Message-ID: <20180405022531.GI25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:40:30 -0000 On Wed, Apr 04, 2018 at 05:33:27PM -0400, Paul Wouters wrote: > On Wed, 4 Apr 2018, Joseph Salowey wrote: > >A) Recommendation of adding denial of existence proofs in the chain provided by the extension > >B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL) > >C) Both > > These options need a bit of clarification. > > If you do A) then by publishing the proof of non-existance records, you > can cancel any outstanding kind of pin done. And you would not need B) Hmm, not quite. You might want to publish the "clear the pin" (TTL == zero) without having to first stop publishing TLSA RRs. The idea is to first ramp up the TTL, and if there's any problems / change of mind, ramp it down and remove the TLSA RRs when the last possible extant pin must have expired. Therefore I think (B) is more urgent. (A) is even more trivial than (B), so there's no reason not to do both ((C)). > [..] > > So to support all cases, I would say C) but I think B) would get us > pretty far on a lot of deployments. +1 > The document's intension is clearly to staple DNSSEC answers for the > TLSA query on the TLS handshake. Omiting proof of non-existence means > it fails to achieve its specified goal and makes this TLS extension > completely useless[*] +1 Thanks, Nico -- From nobody Wed Apr 4 19:45:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32690124BFA for ; Wed, 4 Apr 2018 19:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U2hdxoOMQkZ for ; Wed, 4 Apr 2018 19:45:34 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7276312426E for ; Wed, 4 Apr 2018 19:45:34 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id u141-v6so21203606oif.1 for ; Wed, 04 Apr 2018 19:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yQ/Kkn0EfLXH+dyiS/p9zZF3jjrt9/ONEvDDM8RuV+o=; b=XKTo7lllnbYUXe4a/oSK3l+VkvJi3hxtMApAIGg3m6nMSvYCz2ITEx7ShLjbEyCNFX wwaB3U4Dq6v3VxCBCVw8UhmFdOD7b+KASs4gH2Q5I1XbrVLEZCyTIb4h5yTO5YX5my+e EeLKbi7D5GPKq7IuBZ7HPGqzKO4EF0sDG2qhsXjwXY1Z3pO7gt1JTxBnUAlzVQulSPQ4 GGv+s+rOQ74UJiKW1+x5StgQMg2wIRmhzIGH7r5qT0inM8Ij3scba70qzCJJxsnKPkwz 16DXG2Lny1Z1pQcD6EUND1PoO+RrWwkd7YOr+KNbNUvGuR93NPcIg7AHQljJ38uYgk0D Midg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yQ/Kkn0EfLXH+dyiS/p9zZF3jjrt9/ONEvDDM8RuV+o=; b=RDbI5TL09X6w4ccAPuindC5bYmIgUEse/U+KcirmHyeKccqm9nNS11Fj0Q+4bg9AxK IFgxYlyhOnFDnSDBDJnc/flgyRiQEon8PagZQyfyoStdn5LrSpZ6cB6II7WtITel1ROb aenDbJBMTjgi7opwwRdvjojkSI7esDd1Gmb+jX9cGMZDBxG6KMOEjYvwvCpoBc/VxraR FReUiMLky0nwCeWMzCBePfQOQjBKzGOETuXiFbfQOE4qoFxXuPeu8rH3MmpbsvKCIeId jBhn4Sl9rJnruBPhzRreiqdYxW95HMVgdYaft8Jkx+f8MJK/0ThHFEX1G8MbhX915x4N F7nQ== X-Gm-Message-State: ALQs6tBkeLm2qqecl5bVKQA0Ng8FIKwGWYRL3qZ3q063GNGtV1cDQxbK HnWkTvPZPcqDi2QJbVDbyLBjcEf0Suc7ZpD2C6j1Myz8 X-Google-Smtp-Source: AIpwx4+RxGeWwxndAOJOi5xoccuW4HNNvvrIixN4HxDsNojkxDxYmySZUZcQ5ongFryVpGXCG3ZiHpnyUoLEXp2hbh0= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr11014807oib.138.1522896333699; Wed, 04 Apr 2018 19:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Wed, 4 Apr 2018 19:44:53 -0700 (PDT) In-Reply-To: <20180405022007.GG25259@localhost> References: <20180405022007.GG25259@localhost> From: Eric Rescorla Date: Wed, 4 Apr 2018 19:44:53 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000000014f6056910ef5f" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:45:36 -0000 --0000000000000014f6056910ef5f Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams wrote: > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > > I don't think that this comparison is particularly apt.The > > representation in HSTS is simply "I support HSTS". The representation > > in HPKP is "I will use either consistent keying material *or* a > > consistent set of CAs". The representation here is "I will continue to > > have DNSSEC-signed DANE records". That is a significantly more risky > > proposition than continuing to support TLS (and I'm ignoring the risk > > of hijacking attacks that people were concerned with with HPKP), and > > so this seems rather more like HPKP to me. > > Without a TTL (with zero meaning "clear the pin to DANE") this extension > can only really be used with mandatory-to-use-with-DANE protocols, where > the commitment to "continue to have DNSSEC-signed DANE records" is > implied. > This simply isn't true, for the reasons Richard Barnes indicated in his response to you. > The TTL allows one to put a bound on that commitment, thus alleviating > the risk. > > That's the whole point: to alleviate the risk of commitment to DANE in > order to not discourage opportunistic deployment. > HPKP had a TTL and yet as a practical matter, people found it very problematic. And, of course, if you're concerned with hijacking attacks, the hijacker will just advertise a very long TTL. -Ekr Nico > -- > --0000000000000014f6056910ef5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> I don't think that this comparison is particularly apt.The
> representation in HSTS is simply "I support HSTS". The repre= sentation
> in HPKP is "I will use either consistent keying material *or* a > consistent set of CAs". The representation here is "I will c= ontinue to
> have DNSSEC-signed DANE records". That is a significantly more ri= sky
> proposition than continuing to support TLS (and I'm ignoring the r= isk
> of hijacking attacks that people were concerned with with HPKP), and > so this seems rather more like HPKP to me.

Without a TTL (with zero meaning "clear the pin to DANE") = this extension
can only really be used with mandatory-to-use-with-DANE protocols, where the commitment to "continue to have DNSSEC-signed DANE records" i= s
implied.

This simply isn't true, fo= r the reasons Richard Barnes indicated in his response
to you.


The TTL allows one to put a bound on that commitment, thus alleviating
the risk.

That's the whole point: to alleviate the risk of commitment to DANE in<= br> order to not discourage opportunistic deployment.

HPKP had a TTL and yet as a practi= cal matter, people found it very problematic.
And, of course, if = you're concerned with hijacking attacks, the hijacker will
ju= st advertise a very long TTL.

-Ekr

<= /div>
Nico
--

--0000000000000014f6056910ef5f-- From nobody Wed Apr 4 19:46:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A566124BFA for ; Wed, 4 Apr 2018 19:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5K402GOKplQ for ; Wed, 4 Apr 2018 19:46:42 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F1412426E for ; Wed, 4 Apr 2018 19:46:42 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 47033A00400F; Wed, 4 Apr 2018 19:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Ou8lxpBHJhHH2L LYgVIsijPfE2Q=; b=RtoJfReNFTSTi4ThERQltvcFtoFOlVLUcqGVwuRilEed1U zwthfw60v5Zu7k4Hmoo/qw5M4QLYrCdQnnK0FatE0vwxSWI2sm6lr/g/BJG4Jr82 qpaAQsgL58dBYMWFncH24ksuj4CLYjahcE0XaaE8ycFuhUxMcu2BSqNbJVPD0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id DBBCBA000B3C; Wed, 4 Apr 2018 19:46:41 -0700 (PDT) Date: Wed, 4 Apr 2018 21:31:07 -0500 From: Nico Williams To: Richard Barnes Cc: "" Message-ID: <20180405023106.GJ25259@localhost> References: <20180405022007.GG25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:46:44 -0000 On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote: > Re-adding the list. Removing one level of quotes. > On Wed, Apr 4, 2018, 22:34 Nico Williams wrote: >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> > I don't think that this comparison is particularly apt.The >> > representation in HSTS is simply "I support HSTS". The representation >> > in HPKP is "I will use either consistent keying material *or* a >> > consistent set of CAs". The representation here is "I will continue to >> > have DNSSEC-signed DANE records". That is a significantly more risky >> > proposition than continuing to support TLS (and I'm ignoring the risk >> > of hijacking attacks that people were concerned with with HPKP), and >> > so this seems rather more like HPKP to me. >> >> Without a TTL (with zero meaning "clear the pin to DANE") this extension >> can only really be used with mandatory-to-use-with-DANE protocols, where >> the commitment to "continue to have DNSSEC-signed DANE records" is >> implied. > > This is just not true. As I said in my earlier message, servers can > switch based on the ClientHello. > > Clients advertise which methods they support, servers switch, and they > both see how often DANE gets used. When it gets high enough, they turn off > the fallback. Just like every other TLS feature we've ever done. If clients and servers just negotiate the use of DANE, then there's a downgrade attack when DANE is the only outcome desired by the server operator but some WebPKI CA is willing to issue a rogue certificate for it. That downgrade is a fatal flaw for any protocols where this extension isn't mandatory. QED. We cannot be serious about security while promoting a protocol with a glaring downgrade attack. The TTL with pin-to-DANE semantics alleviates this by allowing the use of DANE to become mandatory-like for some time after first-use. It's TOFU-ish (Trust On First Use). TOFU has worked rather well for some protocols, and it will probably work well in the future. This mechanism to make this extension mandatory-for-some-time negates the downgrade attack *and* simultaneously provides a path to undo the use of DANE -- something that operators can reasonably be expected to demand for any protocol where this extension is not mandatory. Nico -- From nobody Wed Apr 4 19:50:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A45124319 for ; Wed, 4 Apr 2018 19:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf8XYv2Tw68Q for ; Wed, 4 Apr 2018 19:50:53 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21FE127077 for ; Wed, 4 Apr 2018 19:50:53 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 45884A00400F; Wed, 4 Apr 2018 19:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=T/gd0+IfuecuNb qRN+8uUECGZBc=; b=Au4NthIbpr+s2vqzKW43/kTeuLLHDszxYwQI7c/95zfaGA KUNd5q5IRzBXrfPTvE8P8U5g9qI2wRgBZA7JyFu4Uf3IYZP4BPmEkRWBt8ExyI/p oR1w0yZxCEkZFgJBw/5153esC7A/rm6D+kPGeE3vlSrseZDqZb3zdEqHs4JKg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id E2FC9A000B3C; Wed, 4 Apr 2018 19:50:52 -0700 (PDT) Date: Wed, 4 Apr 2018 21:34:57 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180405023456.GK25259@localhost> References: <20180405022007.GG25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:50:56 -0000 On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams wrote: > > > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > > > I don't think that this comparison is particularly apt.The > > > representation in HSTS is simply "I support HSTS". The representation > > > in HPKP is "I will use either consistent keying material *or* a > > > consistent set of CAs". The representation here is "I will continue to > > > have DNSSEC-signed DANE records". That is a significantly more risky > > > proposition than continuing to support TLS (and I'm ignoring the risk > > > of hijacking attacks that people were concerned with with HPKP), and > > > so this seems rather more like HPKP to me. > > > > Without a TTL (with zero meaning "clear the pin to DANE") this extension > > can only really be used with mandatory-to-use-with-DANE protocols, where > > the commitment to "continue to have DNSSEC-signed DANE records" is > > implied. > > > > This simply isn't true, for the reasons Richard Barnes indicated in his > response > to you. See my response to him. For any non-mandatory use of this extension, without the pinning semantics there is a glaring downgrade attack. > HPKP had a TTL and yet as a practical matter, people found it very > problematic. I can see why: you have to commit to one certificate in the chain not changing. Whereas here you only have to commit to continue to publish TLSA RRs (and signing them and your zone). This is a big difference. > And, of course, if you're concerned with hijacking attacks, the > hijacker will just advertise a very long TTL. But it's a TOFU-ish thing. The server impersonator has to have the right timing or else be detected -- that's very risky for them, and a deterrent to even trying. It's not fool-proof, but it's not nothing either. Nico -- From nobody Wed Apr 4 19:57:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624C7127077 for ; Wed, 4 Apr 2018 19:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GQOA_1XYFRl for ; Wed, 4 Apr 2018 19:57:18 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F58124319 for ; Wed, 4 Apr 2018 19:57:18 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id u84-v6so21205084oie.10 for ; Wed, 04 Apr 2018 19:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KH1NctZQ3rPGVXmJrnx4dWVi7s81hRYyJpuNAmk51gI=; b=itNiI6dAzBO2xBCKH7t6UlPcJqUn2avGNsCHcrCdrcy665T7VJL9S+4iM3FHo8/xHo YfVXGvnJais9qSjLBYIvH/0IPLal+lT3Wke3tujzhrsmhS0CKfCgBGXFQAR30b1BJrRn XCO2+47VPLY7t+tgOJOAUadF7c7jDROmT/IhZfJ0pchKLtaY2WGvs8xctwdtqWiW1gDv 3+zOH9d7UxOBgg4TkOQvB6OgAktoB2NNUmhzaphKxIYRX6eDT13efeNyio1wEkYzieeb /n+THoph3ojNHq34k+KgyFp90eHhx6W/kA6+HH1uWdScUtSPeeElVMbdf08uF6Vmqy+b FQ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KH1NctZQ3rPGVXmJrnx4dWVi7s81hRYyJpuNAmk51gI=; b=dAbxY0X37X7XMnt3SZtk/QsLz9PesRvrX/wFN0qXR80hpthn0mVgBd+FGCQVo5LbMG bvnjIptcTVEYK7X66lMzUpk8Ax6D9txz/NiEQNlT0RkuFKtBzHI2yxkiW9HRBm/lh4BH cv2IQIfz+HmvYLOopCB7Re/pFqsSi9kQcu1HwXPLFmzEwpZ1VK+8UracuWmByAEE9OVW ghkH3l+lZbwWv9MM/D6mi9De6l6moXDytwS+rKAln0vmF/nxxdfk5QoWEPmpG+DdRC4j Osft9qcwJWDGORNqNfMe47Q0kNrnEWKQRO6XWYkZFAJVvG5U/9U1lOaMSpjJGFVbeOPu V43A== X-Gm-Message-State: ALQs6tBmoSs2OQOjog9o0qLnd63M0IULvo6jyVm4mK3F8Yb+x1CkmG6H 8Y7snD+ZVMUTpVk4GZPI93EL3HHQ/WMYyFL6AW9kNA== X-Google-Smtp-Source: AIpwx49qpCyixwmP39UQQ7CorYzn1ex3lmRyLW7Sk8kkTNE3L40uT6s6x2UScchMGUEBG7Wr4EFlhmyGnRbPCNJ9ARc= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr11028512oib.138.1522897037742; Wed, 04 Apr 2018 19:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Wed, 4 Apr 2018 19:56:37 -0700 (PDT) In-Reply-To: <20180405023106.GJ25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> From: Eric Rescorla Date: Wed, 4 Apr 2018 19:56:37 -0700 Message-ID: To: Nico Williams Cc: Richard Barnes , "" Content-Type: multipart/alternative; boundary="000000000000f6def1056911188c" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 02:57:20 -0000 --000000000000f6def1056911188c Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams wrote: > On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote: > > Re-adding the list. > > Removing one level of quotes. > > > On Wed, Apr 4, 2018, 22:34 Nico Williams wrote: > >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > >> > I don't think that this comparison is particularly apt.The > >> > representation in HSTS is simply "I support HSTS". The representation > >> > in HPKP is "I will use either consistent keying material *or* a > >> > consistent set of CAs". The representation here is "I will continue to > >> > have DNSSEC-signed DANE records". That is a significantly more risky > >> > proposition than continuing to support TLS (and I'm ignoring the risk > >> > of hijacking attacks that people were concerned with with HPKP), and > >> > so this seems rather more like HPKP to me. > >> > >> Without a TTL (with zero meaning "clear the pin to DANE") this extension > >> can only really be used with mandatory-to-use-with-DANE protocols, where > >> the commitment to "continue to have DNSSEC-signed DANE records" is > >> implied. > > > > This is just not true. As I said in my earlier message, servers can > > switch based on the ClientHello. > > > > Clients advertise which methods they support, servers switch, and they > > both see how often DANE gets used. When it gets high enough, they turn > off > > the fallback. Just like every other TLS feature we've ever done. > > If clients and servers just negotiate the use of DANE, then there's a > downgrade attack when DANE is the only outcome desired by the server > operator but some WebPKI CA is willing to issue a rogue certificate for > it. > > That downgrade is a fatal flaw for any protocols where this extension > isn't mandatory. > > QED. > > We cannot be serious about security while promoting a protocol with a > glaring downgrade attack. > Unfortunately, you are conflating the assertive and restrictive use cases. To recap, there are two potential reasons why one might want thi technology: 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's a pain). This rationale was stronger back before Let's Encrypt, but I suppose some people may still feel that way. 2. Restrictive: To protect yourself from compromise of the WebPKI. Yes, if your motivation is #2, then the flow you suggest is a real problem, but it's not a problem for #1. While not an author of this document, I'd understood it's primary motivation to be #1, and that's what Richard's earlier notes have said as well. -Ekr --000000000000f6def1056911188c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Thu, Apr 05, = 2018 at 02:39:43AM +0000, Richard Barnes wrote:
> Re-adding the list.

Removing one level of quotes.

> On Wed, Apr 4, 2018, 22:34 Nico Williams <nico@cryptonector.com> wrote:
>> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> > I don't think that this comparison is particularly apt.Th= e
>> > representation in HSTS is simply "I support HSTS". = The representation
>> > in HPKP is "I will use either consistent keying material= *or* a
>> > consistent set of CAs". The representation here is "= ;I will continue to
>> > have DNSSEC-signed DANE records". That is a significantl= y more risky
>> > proposition than continuing to support TLS (and I'm ignor= ing the risk
>> > of hijacking attacks that people were concerned with with HPK= P), and
>> > so this seems rather more like HPKP to me.
>>
>> Without a TTL (with zero meaning "clear the pin to DANE"= ) this extension
>> can only really be used with mandatory-to-use-with-DANE protocols,= where
>> the commitment to "continue to have DNSSEC-signed DANE record= s" is
>> implied.
>
> This is just not true.=C2=A0 As I said in my earlier message, servers = can
> switch based on the ClientHello.
>
> Clients advertise which methods they support, servers switch, and they=
> both see how often DANE gets used.=C2=A0 When it gets high enough, the= y turn off
> the fallback.=C2=A0 Just like every other TLS feature we've ever d= one.

If clients and servers just negotiate the use of DANE, then there= 9;s a
downgrade attack when DANE is the only outcome desired by the server
operator but some WebPKI CA is willing to issue a rogue certificate for
it.

That downgrade is a fatal flaw for any protocols where this extension
isn't mandatory.

QED.

We cannot be serious about security while promoting a protocol with a
glaring downgrade attack.

Unfortunately= , you are conflating the assertive and restrictive use cases.
To recap, there are two potential reasons why one might want th= i
technology:

1. Assertive: To avoid hav= ing to engage with the WebPKI (e.g., because it's
a pain). Th= is rationale was stronger back before Let's Encrypt, but
I su= ppose some people may still feel that way.

2. = Restrictive: To protect yourself from compromise of the WebPKI.
<= br>
Yes, if your motivation is #2, then the flow you suggest is a= real problem,
but it's not a problem for #1. While not an au= thor of this document, I'd
understood it's primary motiva= tion to be #1, and that's what Richard's
earlier notes ha= ve said as well.

-Ekr


--000000000000f6def1056911188c-- From nobody Wed Apr 4 20:04:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C24127735 for ; Wed, 4 Apr 2018 20:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH79fTFDaYkG for ; Wed, 4 Apr 2018 20:04:14 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D99127369 for ; Wed, 4 Apr 2018 20:04:14 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id j8-v6so18133867ota.7 for ; Wed, 04 Apr 2018 20:04:14 -0700 (PDT) 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=TGcHwgk8aDw5JoUjtyvdZyGmVvD5Leyfa3EvB1mno5E=; b=LV865ioVpwa4WIBVTMyo0PoFc9jdqbKVzOZF1k0GmXBOjqqqjfuZB5IPjqgorWVLBb xNqheddG8ePDCdAGNUlknokxShH3RseIsUL/ckORazpnIPluLwgB0Te+UGRxRVBd2E8e 5x8LbBMg4Gh55dB6RmSd1k70huJeR8PcG4mV/kLLZ6+Uxkti+Wa9KOHss0BMqDMwFxpa 1vXYCaXZdlEfpaHamPfIR7kactPunYEsLOtLuuVCLPld6mrgAK2vxltAgSnBb5dJhx29 Ebu3x23fevjsoAIayXB6xfaG73ti6vm9SAyrqRjVIX/SvBbCQe57AM4RCMdk9YNdXYEs abMA== 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=TGcHwgk8aDw5JoUjtyvdZyGmVvD5Leyfa3EvB1mno5E=; b=iP0MDv7NwduTwyPgDKP6U54CFPqufETEPQHrRORBn1McRzJN75vBa7VrlRmJ8SU3mh kh09JlUVKTGDLfGoCWXS1n9ZvnhE8yscQdXHOWIGXF7pHXm/SSjJfqo+akg/Ku0k6J/Y counGFo9hlWkzbv4zGKLPgtvuoCAoT9C3NUD1Loo+3e3vnN6v+eIU2wu188tiGnNRbX7 4ZxF3JTLXfjAt2DmNE6VkkUkPf3p4ImnsRnO6VBnTHOYKR8eagFdNldKalTZnKwXMVwF Q+fykG7zahky69JgqoyiH+2IaEU+r1OHTRlDK4mrRWbpdcGaLo3uRTyF1xGKdmtsgEmU lnLw== X-Gm-Message-State: ALQs6tBVRQeffOLXfj10ezvxIKc+S3sn/LAWXPjFamBS0hIv8u7b9dT9 wTLIK9sBPNDbPiJ3NrjbV6g6MGg82CGnl40IoGOVww== X-Google-Smtp-Source: AIpwx4+7zidy23sCnh3ZG871JgUYRMtGBZzaTisixmLbPgolBZIQEuFW373BY1zkEjs8YpHesr3AkmuIuuEDlI/Juec= X-Received: by 2002:a9d:5403:: with SMTP id j3-v6mr12980621oth.52.1522897453940; Wed, 04 Apr 2018 20:04:13 -0700 (PDT) MIME-Version: 1.0 References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> In-Reply-To: From: Richard Barnes Date: Thu, 05 Apr 2018 03:04:03 +0000 Message-ID: To: Eric Rescorla Cc: Nico Williams , "" Content-Type: multipart/alternative; boundary="000000000000c58db2056911310a" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:04:17 -0000 --000000000000c58db2056911310a Content-Type: text/plain; charset="UTF-8" And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today". There's nothing in here that degrades security (except maybe the legacy crypto in the DNS); it's just not meeting the bar that you are setting. That doesn't mean there's not still some utility to be had. --Richard On Wed, Apr 4, 2018, 22:57 Eric Rescorla wrote: > > > On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams > wrote: > >> On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote: >> > Re-adding the list. >> >> Removing one level of quotes. >> >> > On Wed, Apr 4, 2018, 22:34 Nico Williams wrote: >> >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> >> > I don't think that this comparison is particularly apt.The >> >> > representation in HSTS is simply "I support HSTS". The representation >> >> > in HPKP is "I will use either consistent keying material *or* a >> >> > consistent set of CAs". The representation here is "I will continue >> to >> >> > have DNSSEC-signed DANE records". That is a significantly more risky >> >> > proposition than continuing to support TLS (and I'm ignoring the risk >> >> > of hijacking attacks that people were concerned with with HPKP), and >> >> > so this seems rather more like HPKP to me. >> >> >> >> Without a TTL (with zero meaning "clear the pin to DANE") this >> extension >> >> can only really be used with mandatory-to-use-with-DANE protocols, >> where >> >> the commitment to "continue to have DNSSEC-signed DANE records" is >> >> implied. >> > >> > This is just not true. As I said in my earlier message, servers can >> > switch based on the ClientHello. >> > >> > Clients advertise which methods they support, servers switch, and they >> > both see how often DANE gets used. When it gets high enough, they turn >> off >> > the fallback. Just like every other TLS feature we've ever done. >> >> If clients and servers just negotiate the use of DANE, then there's a >> downgrade attack when DANE is the only outcome desired by the server >> operator but some WebPKI CA is willing to issue a rogue certificate for >> it. >> >> That downgrade is a fatal flaw for any protocols where this extension >> isn't mandatory. >> >> QED. >> >> We cannot be serious about security while promoting a protocol with a >> glaring downgrade attack. >> > > Unfortunately, you are conflating the assertive and restrictive use cases. > > To recap, there are two potential reasons why one might want thi > technology: > > 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's > a pain). This rationale was stronger back before Let's Encrypt, but > I suppose some people may still feel that way. > > 2. Restrictive: To protect yourself from compromise of the WebPKI. > > Yes, if your motivation is #2, then the flow you suggest is a real problem, > but it's not a problem for #1. While not an author of this document, I'd > understood it's primary motivation to be #1, and that's what Richard's > earlier notes have said as well. > > -Ekr > > > --000000000000c58db2056911310a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And just to be clear, by "downgrade attack", yo= u mean "normal PKI authentication that we rely on today".=C2=A0 T= here's nothing in here that degrades security (except maybe the legacy = crypto in the DNS); it's just not meeting the bar that you are setting.= =C2=A0 =C2=A0That doesn't mean there's not still some utility to be= had.=C2=A0

--Richard=C2=A0


On Wed, Apr 4, 2018, 22:57 Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams <nico@cryptonector.com> wrote:
On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrot= e:
> Re-adding the list.

Removing one level of quotes.

> On Wed, Apr 4, 2018, 22:34 Nico Williams <nico@cryptonector.com<= /a>> wrote:
>> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> > I don't think that this comparison is particularly apt.Th= e
>> > representation in HSTS is simply "I support HSTS". = The representation
>> > in HPKP is "I will use either consistent keying material= *or* a
>> > consistent set of CAs". The representation here is "= ;I will continue to
>> > have DNSSEC-signed DANE records". That is a significantl= y more risky
>> > proposition than continuing to support TLS (and I'm ignor= ing the risk
>> > of hijacking attacks that people were concerned with with HPK= P), and
>> > so this seems rather more like HPKP to me.
>>
>> Without a TTL (with zero meaning "clear the pin to DANE"= ) this extension
>> can only really be used with mandatory-to-use-with-DANE protocols,= where
>> the commitment to "continue to have DNSSEC-signed DANE record= s" is
>> implied.
>
> This is just not true.=C2=A0 As I said in my earlier message, servers = can
> switch based on the ClientHello.
>
> Clients advertise which methods they support, servers switch, and they=
> both see how often DANE gets used.=C2=A0 When it gets high enough, the= y turn off
> the fallback.=C2=A0 Just like every other TLS feature we've ever d= one.

If clients and servers just negotiate the use of DANE, then there= 9;s a
downgrade attack when DANE is the only outcome desired by the server
operator but some WebPKI CA is willing to issue a rogue certificate for
it.

That downgrade is a fatal flaw for any protocols where this extension
isn't mandatory.

QED.

We cannot be serious about security while promoting a protocol with a
glaring downgrade attack.






--000000000000c58db2056911310a-- From nobody Wed Apr 4 20:07:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4DF127369 for ; Wed, 4 Apr 2018 20:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoekJIWeihtS for ; Wed, 4 Apr 2018 20:07:24 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BB3127077 for ; Wed, 4 Apr 2018 20:07:23 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id e123-v6so21217599oih.13 for ; Wed, 04 Apr 2018 20:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lf3QGATpPHMGrRBKAelGgPJt/rsnEkeWVz10Sz5qMWw=; b=Zxh9XxVcDxDYzZHAtQQaURYRhaHUqB8xeRrQWplNHPka9FJSFYmP2PiE7HzGcJCO94 RTf7mSHXEru6ohpWrsyE9GWz/IwmZNeS6ZN3s6tA/OWn2SHb/b87ceY/3diXV35mQKf+ 2GL/uHHBTVxWiMklO6IwlQViojfv82MXus1QeSd0rhokpE+bvkslrDAw6CUq6H75QIcP 8tMdUrxfR+Izd9B+2qSop9kpXSIZAgFPcqYeYIS2zwa7xZo4lmfxgJzyGnxq70/GwJGx ZZ+QHCR7NE+8yIQtbopuD9yzGBs05OyZZTsOblZQgHHDJxIYE4gGoSAwroPnSWotAK/x kH/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lf3QGATpPHMGrRBKAelGgPJt/rsnEkeWVz10Sz5qMWw=; b=LP3fICcX8xOsxaXHs0ErinYRPyxjDzqWeJIsMxqoFCmJ5JfBhJBzsjGuH/0tUPvWgF 7uIeoRqq+xb4MTkC7Og0N1Dk31F3ZTjHk7YLi/uybSVoqkiqCZCW/ShXFuUG/Jo8AGm9 PdFdTwkB+OTjow7+hoApivS0A/81RhgSLXrfD/XEPGTnWd89lO7Wr+4mw2c7OhacDjQj cmNl8+aXbbFYHqnn74D80KaBEUnB/wxcuwh0R2/rR7/dhBfNSH+fFxh6wqDyqfBUo7oO 44+4cbgMRUH3f4FRyqAta9ug7/70wfVkOBtboN8+d+3dxsyMoopvPifQwiFh8rPuFE7n i65Q== X-Gm-Message-State: ALQs6tBdUDIt5lGd5i4MfFSqNU0KrWo4lBHYRvFJB/VOLvzSveM/a1J2 FMdKboD0+qTj5X7Ghx9lr4bmcTvs/u1gMucybiAcXRqTHXc= X-Google-Smtp-Source: AIpwx4+Z5DDsb1kaEx28feMi/VOGcQM84lpju0EfpCb2WNlT5H2PNOc2yzuTWutezvbywaYrWKSZ3PdQQXi5+Q1lmHk= X-Received: by 2002:aca:3114:: with SMTP id x20-v6mr12029440oix.108.1522897643200; Wed, 04 Apr 2018 20:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Wed, 4 Apr 2018 20:06:42 -0700 (PDT) In-Reply-To: <20180405023456.GK25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> From: Eric Rescorla Date: Wed, 4 Apr 2018 20:06:42 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000000d8b340569113dec" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:07:25 -0000 --0000000000000d8b340569113dec Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote: > On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote: > > On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams > wrote: > > > > > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > > > > I don't think that this comparison is particularly apt.The > > > > representation in HSTS is simply "I support HSTS". The representation > > > > in HPKP is "I will use either consistent keying material *or* a > > > > consistent set of CAs". The representation here is "I will continue > to > > > > have DNSSEC-signed DANE records". That is a significantly more risky > > > > proposition than continuing to support TLS (and I'm ignoring the risk > > > > of hijacking attacks that people were concerned with with HPKP), and > > > > so this seems rather more like HPKP to me. > > > > > > Without a TTL (with zero meaning "clear the pin to DANE") this > extension > > > can only really be used with mandatory-to-use-with-DANE protocols, > where > > > the commitment to "continue to have DNSSEC-signed DANE records" is > > > implied. > > > > > > > This simply isn't true, for the reasons Richard Barnes indicated in his > > response > > to you. > > See my response to him. For any non-mandatory use of this extension, > without the pinning semantics there is a glaring downgrade attack. > I've responded to this separately. > > HPKP had a TTL and yet as a practical matter, people found it very > > problematic. > > I can see why: you have to commit to one certificate in the chain not > changing. No, this isn't correct, in two respects. 1. HPKP pins the SPKI, not the certificate, it's about the *key* not changing, and intermediates and roots change quite infrequently. (https://tools.ietf.org/html/rfc7469#section-2.1.1) 2. It's not one key. HPKP allowed you to pin multiple keys and in fact *required* you to set a backup pin (https://tools.ietf.org/html/rfc7469#section-2.5) Whereas here you only have to commit to continue to publish > TLSA RRs (and signing them and your zone). This is a big difference. > I don't think that's it all obvious that this is going to be easier to guarantee, especially given the rather high DNSSEC misconfiguration rate (https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf, https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf). > And, of course, if you're concerned with hijacking attacks, the > > hijacker will just advertise a very long TTL. > > But it's a TOFU-ish thing. The server impersonator has to have the > right timing or else be detected -- that's very risky for them, and a > deterrent to even trying. It's not fool-proof, but it's not nothing > either. > Given that the motivation for this kind of hijacking was generally expected to be vandalism or ransom, this doesn't seem very comforting. -Ekr > Nico > -- > --0000000000000d8b340569113dec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Re= scorla wrote:
> On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams <nico@cryptonector.com> wrote:
>
> > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > > > I don't think that this comparison is particularly apt.T= he
> > > representation in HSTS is simply "I support HSTS".= The representation
> > > in HPKP is "I will use either consistent keying materia= l *or* a
> > > consistent set of CAs". The representation here is &quo= t;I will continue to
> > > have DNSSEC-signed DANE records". That is a significant= ly more risky
> > > proposition than continuing to support TLS (and I'm igno= ring the risk
> > > of hijacking attacks that people were concerned with with HP= KP), and
> > > so this seems rather more like HPKP to me.
> >
> > Without a TTL (with zero meaning "clear the pin to DANE"= ;) this extension
> > can only really be used with mandatory-to-use-with-DANE protocols= , where
> > the commitment to "continue to have DNSSEC-signed DANE recor= ds" is
> > implied.
> >
>
> This simply isn't true, for the reasons Richard Barnes indicated i= n his
> response
> to you.

See my response to him.=C2=A0 For any non-mandatory use of this exte= nsion,
without the pinning semantics there is a glaring downgrade attack.

I've responded to this separately.


> HPKP had a TTL and yet as a practical matter, people found it very
> problematic.

I can see why: you have to commit to one certificate in the chain no= t
changing.=C2=A0

No, this isn't correct,= in two respects.

1. HPKP pins the SPKI, not the c= ertificate, it's about the *key* not changing,
and inter= mediates and roots change quite infrequently.

2. It's not one key. H= PKP allowed you to pin multiple keys and in fact
*required* you t= o set a backup pin


Whereas here you only have to commit to continue to publish
TLSA RRs (and signing them and your zone).=C2=A0 This is a big difference.<= br>

I don't think that's it all obv= ious that this is going to be easier to guarantee,
especially giv= en the rather high DNSSEC misconfiguration rate
=

> And, of course, if you're concerned with hijacking attacks, the > hijacker will just advertise a very long TTL.

But it's a TOFU-ish thing.=C2=A0 The server impersonator has to = have the
right timing or else be detected -- that's very risky for them, and a deterrent to even trying.=C2=A0 It's not fool-proof, but it's not n= othing
either.

Given that the motivation for t= his kind of hijacking was generally
expected to be vandalism or r= ansom, this doesn't seem very comforting.

= -Ekr


Nico
--

--0000000000000d8b340569113dec-- From nobody Wed Apr 4 20:18:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03876127076 for ; Wed, 4 Apr 2018 20:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 NkVJu9a1WYbZ for ; Wed, 4 Apr 2018 20:18:29 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5944126B6D for ; Wed, 4 Apr 2018 20:18:29 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id DE8E2A00400F; Wed, 4 Apr 2018 20:18:28 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 8031CA000B3C; Wed, 4 Apr 2018 20:18:28 -0700 (PDT) Date: Wed, 4 Apr 2018 21:59:18 -0500 From: Nico Williams To: Eric Rescorla Cc: Richard Barnes , "" Message-ID: <20180405025917.GL25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:18:31 -0000 On Wed, Apr 04, 2018 at 07:56:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams wrote: > > We cannot be serious about security while promoting a protocol with a > > glaring downgrade attack. > > Unfortunately, you are conflating the assertive and restrictive use cases. I'm conflating nothing. I want to be able to use this HTTPS with DANE, but this extension as-is cannot be used in any protocol where it isn't mandatory. (Richard B. proposes that one can use this with HTTPS when using a CA that is not likely to be trusted by some clients. But that's hardly the enticing use of this extension for HTTPS. The interesting use-case is DANE for HTTPS, with or without WebPKI, and having a method of possibly deploying this. By "possibly" I mean "incremental".) > To recap, there are two potential reasons why one might want thi > technology: > > [...] You're not being serious. You're rationalizing the document as-is. Nico -- From nobody Wed Apr 4 20:23:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40A8127077 for ; Wed, 4 Apr 2018 20:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPq8Kwcr-Fud for ; Wed, 4 Apr 2018 20:22:58 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E881126B6D for ; Wed, 4 Apr 2018 20:22:58 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E2775A004012; Wed, 4 Apr 2018 20:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=K/sH8qed+cl5hf LAKjeMU9tRE3E=; b=s+jFhhySSAPMn9/spbFaSr/gJCI0BkaWRPLfjRcQrstu3e J+64f4ZOOAnrngVuBupEc/fHj5+ZuaKMEETb6bpLoVPAejUvno/YGTN1YBOW1P8n PdAlVTM6ZMW+PyT5pfXInC5v31NQR8o0KKs1Vc035mYwsO6/qIM653f27tl8w= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 86449A00400F; Wed, 4 Apr 2018 20:22:57 -0700 (PDT) Date: Wed, 4 Apr 2018 22:03:20 -0500 From: Nico Williams To: Richard Barnes Cc: Eric Rescorla , "" Message-ID: <20180405030320.GM25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:23:00 -0000 On Thu, Apr 05, 2018 at 03:04:03AM +0000, Richard Barnes wrote: > And just to be clear, by "downgrade attack", you mean "normal PKI > authentication that we rely on today". There's nothing in here that It's NOT that using WebOKI is a downgrade. It's that if an operator wants to use DANE (with any usage), then they want to use DANE. If an impersonator can make that not happen, it's a downgrade from the operator's perspective (because they then don't get what they wanted). > degrades security (except maybe the legacy crypto in the DNS); it's > just not meeting the bar that you are setting. That doesn't mean > there's not still some utility to be had. Nonsense. The operator wants DANE? They should be able to get it. If an active attacker can make that not happen at will, then that is and can only be called a downgrade attack. Waving your hands doesn't make this go away. The WebPKI's security is irrelevant to this discussion. Only the server operator's desired outcome is relevant. If they can't get it, then this protocol is not useful to them. And this protocol is all about using DANE in TLS applications!!! Nico -- From nobody Wed Apr 4 20:30:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D8E127076 for ; Wed, 4 Apr 2018 20:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 v9D6NS3RF6Mq for ; Wed, 4 Apr 2018 20:30:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1EF126B6D for ; Wed, 4 Apr 2018 20:30:03 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1C5EB7A330D for ; Thu, 5 Apr 2018 03:30:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <20180405023456.GK25259@localhost> Date: Wed, 4 Apr 2018 23:30:01 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <068F471B-790C-4F8A-BCCB-150BCF8B2E6F@dukhovni.org> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:30:05 -0000 > On Apr 4, 2018, at 10:34 PM, Nico Williams wrote: > > I can see why: you have to commit to one certificate in the chain not > changing. Whereas here you only have to commit to continue to publish > TLSA RRs (and signing them and your zone). This is a big difference. Even more strongly NOT ONLY do you not actually commit to publishing TLSA records going forward since with (A) (denial of existence) you can just prove they don't exist. You can even stop using DNSSEC for your domain entirely. And yet still support the extension and just furnish proof (again denial of existence) that your domain is no longer signed (i.e. no DS records in the parent or ancestor thereof as signed by that parent or ancestor). THEREFORE, the pin is *precisely* just a capability pin (like STS), saying I can present the extension, there is NO obligation to provide any specific content in that extension. -- Viktor. From nobody Wed Apr 4 20:30:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFCF129BBF for ; Wed, 4 Apr 2018 20:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 qU2lLRi8_TVU for ; Wed, 4 Apr 2018 20:30:06 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C68A126B6D for ; Wed, 4 Apr 2018 20:30:06 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C3D68A00400F; Wed, 4 Apr 2018 20:30:05 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 6EA41A000B3C; Wed, 4 Apr 2018 20:30:05 -0700 (PDT) Date: Wed, 4 Apr 2018 22:09:46 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180405030945.GN25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:30:10 -0000 On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote: > > > > HPKP had a TTL and yet as a practical matter, people found it very > > > problematic. > > > > I can see why: you have to commit to one certificate in the chain not > > changing. > > No, this isn't correct, in two respects. > > 1. HPKP pins the SPKI, not the certificate, it's about the *key* not > changing, and intermediates and roots change quite infrequently. > (https://tools.ietf.org/html/rfc7469#section-2.1.1) Either way it's the same impact: you cannot roll that key over. Whereas with pin-to-DANE there's no such problem. I thought I made that clear. > 2. It's not one key. HPKP allowed you to pin multiple keys and in fact > *required* you to set a backup pin > (https://tools.ietf.org/html/rfc7469#section-2.5) The problem remains: you're pinning to key material, which complicates key management. > Whereas here you only have to commit to continue to publish > > TLSA RRs (and signing them and your zone). This is a big difference. > > > > I don't think that's it all obvious that this is going to be easier to > guarantee, especially given the rather high DNSSEC misconfiguration > rate > (https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf, > https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf). I flubbed that up a bit. With the pin you commit to continue to using this extension for as long as the clients have pinned it (which you control via the TTL). You can actually stop signing your zone provided that you continue to use the extension. > > And, of course, if you're concerned with hijacking attacks, the > > > hijacker will just advertise a very long TTL. > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > right timing or else be detected -- that's very risky for them, and a > > deterrent to even trying. It's not fool-proof, but it's not nothing > > either. > > Given that the motivation for this kind of hijacking was generally > expected to be vandalism or ransom, this doesn't seem very comforting. The motivation for opportunistically using this is to be able to incrementally deploy DANE for HTTPS (and browsers). Without that it won't get deployed at all for HTTPS. Nico -- From nobody Wed Apr 4 20:40:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A412785F for ; Wed, 4 Apr 2018 20:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaiP9635h1ZK for ; Wed, 4 Apr 2018 20:40:18 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B038A127369 for ; Wed, 4 Apr 2018 20:40:18 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l190-v6so21277422oig.9 for ; Wed, 04 Apr 2018 20:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cczk1tecwH10LG5UktJf0g9Xj37Mrt7l0wZh9QIQuWo=; b=vWQI921Lk/LQ3JbBNvfmh12UyQxQpYGkrMvt+KvAWnYSXidhUUQlJA7Xqyogi96znS kKRnSPOvIO6mswPKB87l4eCh5ydoWclLedH2BzoWPUSTjI8KbsecgNc7akbf7mh4O8Bd oLtbgKXLk1Qes+HgdIpMy1QfNaS9jl7cHt7dX294loEyIuYOq3HgL30iZT42HxYIn8nD Umo2QHl6wZYC3I9KfWBoypOpsf26xdRVEMxRXpA5wM7DgwXDobEqcJDrJuLzUtrgtInh 2SKJlOhT7xQOMSThuWBwP3mNR7E7D6Amg0+dqHX0FsuoZBZWBY0nUUK0Cbi96kBq5zs6 W2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cczk1tecwH10LG5UktJf0g9Xj37Mrt7l0wZh9QIQuWo=; b=qqHx5MPG05N9qQxwfXhoAmRVqKqvqX95u5QnpZmjbKjTD+veRc4l/HFvNDK5xRbPkz eVYmtZIoQJ5AqfAOeQ4ZcD7/Hvxg2fcUbTafmjjTLYqerQ7qRgOL0zScKNpBswXIOp3T ikhjtX9FJvQpE0Aff/InaLg9+233iUjrkxsrvPP76RrSLOW2RQFrWlATOULHETJNCiNf sYjdTWNJUMqJZhkJq8hMX27YKR3LwT+HyxVRDVMVGU6xPXHNCPYbQ6SHExPefaqAYVy0 BbUgTCFaKm2tCQx/wDGgE3NWfdHbJ4jvw8lrVJ48upueGhnMVmsA8tc4j4nA7gux+1ka FugQ== X-Gm-Message-State: ALQs6tCs+vkJfkiHWB0ZkK/bCZ07JrUJm26/aimgYQlxnesgQGGF66/m 1laXE7qplnUx3s0V9wDKvq7MHfSKBWwPmemTS59QXw== X-Google-Smtp-Source: AIpwx4+xlbUm2ioVI8sHuH6iLRj/UrNrx0C0f/qrWfYT2/OklzQhd34JhtGcyETaxtVIDLvnQSGNoyMFUew2hs82MSY= X-Received: by 2002:aca:544b:: with SMTP id i72-v6mr12365471oib.262.1522899617977; Wed, 04 Apr 2018 20:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Wed, 4 Apr 2018 20:39:37 -0700 (PDT) In-Reply-To: <20180405030945.GN25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> <20180405030945.GN25259@localhost> From: Eric Rescorla Date: Wed, 4 Apr 2018 20:39:37 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary="000000000000c22d0e056911b2f9" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:40:21 -0000 --000000000000c22d0e056911b2f9 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote: > On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote: > > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams > wrote: > > > > > > HPKP had a TTL and yet as a practical matter, people found it very > > > > problematic. > > > > > > I can see why: you have to commit to one certificate in the chain not > > > changing. > > > > No, this isn't correct, in two respects. > > > > 1. HPKP pins the SPKI, not the certificate, it's about the *key* not > > changing, and intermediates and roots change quite infrequently. > > (https://tools.ietf.org/html/rfc7469#section-2.1.1) > > Either way it's the same impact: you cannot roll that key over. > > Whereas with pin-to-DANE there's no such problem. I thought I made that > clear. > Yes, I agree that you're relying on a different guarantee from your parent zone, I just don't think it's particularly obvious that that guarantee is easier to ensure, for the reasons I indicated previously. > > And, of course, if you're concerned with hijacking attacks, the > > > > hijacker will just advertise a very long TTL. > > > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > > right timing or else be detected -- that's very risky for them, and a > > > deterrent to even trying. It's not fool-proof, but it's not nothing > > > either. > > > > Given that the motivation for this kind of hijacking was generally > > expected to be vandalism or ransom, this doesn't seem very comforting. > > The motivation for opportunistically using this is to be able to > incrementally deploy DANE for HTTPS (and browsers). Without that it > won't get deployed at all for HTTPS. > I don't see how this is responsive to the concern that this technique will be used for hijacking. -Ekr > Nico > -- > --000000000000c22d0e056911b2f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams <nico@cryptonector.com> wrote:
>
> > > HPKP had a TTL and yet as a practica= l matter, people found it very
> > > problematic.
> >
> > I can see why: you have to commit to one certificate in the chain= not
> > changing.
>
> No, this isn't correct, in two respects.
>
> 1. HPKP pins the SPKI, not the certificate, it's about the *key* n= ot
> changing, and intermediates and roots change quite infrequently.
> (https://tools.ietf.org/html/rfc7469#sect= ion-2.1.1)

Either way it's the same impact: you cannot roll that key over.<= br>
Whereas with pin-to-DANE there's no such problem.=C2=A0 I thought I mad= e that
clear.

Yes, I agree that you're rel= ying on a different guarantee from your parent
zone, I just don&#= 39;t think it's particularly obvious that that guarantee is easier
to ensure, for the reasons I indicated previously.


> > And, of course, if you're concerned with hijacking attacks, t= he
> > > hijacker will just advertise a very long TTL.
> >
> > But it's a TOFU-ish thing.=C2=A0 The server impersonator has = to have the
> > right timing or else be detected -- that's very risky for the= m, and a
> > deterrent to even trying.=C2=A0 It's not fool-proof, but it&#= 39;s not nothing
> > either.
>
> Given that the motivation for this kind of hijacking was generally
> expected to be vandalism or ransom, this doesn't seem very comfort= ing.

The motivation for opportunistically using this is to be able to
incrementally deploy DANE for HTTPS (and browsers).=C2=A0 Without that it won't get deployed at all for HTTPS.

I don't see how this is responsive to the concern that this technique= will
be used for hijacking.

-Ekr
<= div>

Nico
--

--000000000000c22d0e056911b2f9-- From nobody Wed Apr 4 21:20:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E402127369 for ; Wed, 4 Apr 2018 21:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJSqueXZKRoB for ; Wed, 4 Apr 2018 21:19:59 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 F37AC128954 for ; Wed, 4 Apr 2018 21:19:58 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id h26-v6so25780946otj.12 for ; Wed, 04 Apr 2018 21:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wjYhtIOqoF/BQnOBPScgmCpkMf6/Ld2xmpPVhxLGN9Y=; b=QljIoxbIR8Whk51WyLqj62gxTivveEHslez2qq+1XTEZXvaGcfg+MeQrVsZx+EepXx Kcv0/3cBR71BOQtRo+IZ7SfSTovE54S138r5OeUIgrZHl+fhOnswsAPb5EAg4B+rqeRu iAmN6GQ0xuYhhXbTJ9Z/ArWXPi3ybDB/sRn3wgVDypiyWy33LL7AwhmvhNQV635JSAK7 RQGxJ8lQ4vpX2BsLjkb1odw2ljFKknSkHDi++/9dyWYxxKH73NkzAj9IZq6RqEr2HnRJ z2zPI/gPjVvBHf7+6HLpD3oF3QpqLiT8og0JSv4ajVPFoaNTcFtX6sdN1rP/F4OBXKE8 FSzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wjYhtIOqoF/BQnOBPScgmCpkMf6/Ld2xmpPVhxLGN9Y=; b=e65nFZJoIuFp0+aYxJwA4cO53hpAdb5nJr5pDSytnsEsBwhxIZBy5sx9Dcyx7jCrT6 npVqK01oZAz9XVCYRw2WshIN6wJEX3Hq8Faeyz3yBRj4t7eIeWlN/ZdGBHtpx5QGo7jn 3yOnmUI7xhYXKj2XVAqQC+JjLWV0aODk3caQk+Gsax0jloJubiYJon+yyAAZS5wRanZr SFlKC9l8HR+373/7pg5rRfKJVcRFdI4/ggaFWW7PG39GJC9OPmCyI2K7NCF1mg7D68RR GbvptOdOwHcx+VT6Ad3wF9ncfQKlGYJQHsp3rCFbGq+yyYepXHlsQYN0M/ntKvByIdwm 3i9g== X-Gm-Message-State: ALQs6tC9VVMvH5GLnwF1CyvtI5NxYkk7ljGvsgHIh6d7HK25oMy9FJbc bxIxX1VVPZm6EzYkO9wsoLqS951RBIMTtqyRU44= X-Google-Smtp-Source: AIpwx49591VPz/9hdfR23rJtezQ24dZYRWTEgg0j9YjziA9aCPtASXOpLpKHa9nhXWol6YtAvkQ/KpF5CCZOCb25Ehs= X-Received: by 2002:a9d:1311:: with SMTP id f17-v6mr96172ote.15.1522901998296; Wed, 04 Apr 2018 21:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 21:19:57 -0700 (PDT) In-Reply-To: <20180405030945.GN25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> <20180405030945.GN25259@localhost> From: Martin Thomson Date: Thu, 5 Apr 2018 14:19:57 +1000 Message-ID: To: Nico Williams Cc: Eric Rescorla , TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 04:20:00 -0000 On Thu, Apr 5, 2018 at 1:09 PM, Nico Williams wrote: > The motivation for opportunistically using this is to be able to > incrementally deploy DANE for HTTPS (and browsers). Without that it > won't get deployed at all for HTTPS. Do you have both clients and servers that are interested in this particular approach? From nobody Wed Apr 4 23:46:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C853126D73 for ; Wed, 4 Apr 2018 23:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 geLjU9xo_Gy9 for ; Wed, 4 Apr 2018 23:46:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C9E120725 for ; Wed, 4 Apr 2018 23:46:14 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 80FED7A330D for ; Thu, 5 Apr 2018 06:46:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 5 Apr 2018 02:46:12 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 06:46:16 -0000 > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: >=20 > A) Recommendation of adding denial of existence proofs in the chain = provided by the extension > B) Adding signaling to require the use of this extension for a period = of time (Pinning with TTL) > C) Both The discussion so far has demonstrated the need for an important = clarification about the nature of the pinning in B): * The pin would not require *anything* more than continuing support = for the extension. * In particular, it would not require continued presence of TLSA = records, nor even continued DNSSEC support by the server's domain. * This is because the server can respond with denial of existence of = either its TLSA records, or even of the the DS records for its domain or some parent = domain. This is why my claim that this is essentially like STS, and nothing like = HPKP is valid. A corollary of the above is that (B) requires (A). Just (B) alone is = not sufficient, it is too limited a mechanism without denial of existence. If support for the extension itself is mandatory in some application = context (implicit unbounded pin), then of course (A) alone is enough, but we should note = that such implicit indefinite pinning is fragile during partial deployment and does not = protect applications where the implicit requirement is not an option (incremental = deployment). Therefore, the real choice before us is (C) or not (C), the choices of = (A) alone or (B) alone are unsound half-measures. (C) is essentially STS for dane chains over TLS with downgrade = protection after first contact, and imposes no burden on the present implementors. If they = were willing to implement without a pin or denial of existence, they can ignore the pin = TTL and never transmit denial of existence (which their clients would not expect to = process). On the other hand, they may find after some experience that the proposed = features are actually useful, and might add them to their application logic. I = don't know whether DANE is mandatory with DPRIV or is just an "additive" = alternative to WebPKI. If the latter, with the present draft it is trivially stripped, and = again there is little incentive to not just use WebPKI, especially if DANE support is = not required from all clients (thus servers need at least WebPKI). Looking at RFC8310, I see hints of support for both WebPKI and DANE, = with no guidance as to how a client is to choose between them, accept either both, avoid = downgrades to one when the other is preferred, ... So I rather suspect that even the DPRIV use-case, which supposedly does = not need the proposed changes, actually does need them for meaningful security = from using DANE, and we've not just not looked at the details closely enough yet. = It may well turn out not substantially different from the browser use-case that = is not adequately met by the current draft. Can someone explain briefly how DPRIV avoids the same downgrade issues, = and negative adoption incentives (cost-benfit comparison)? If it turns out = that no adequate explanation is possible, and indeed the same issues are = present, then the proposed changes (which are still needed elsewhere) are all the more pressing. --=20 Viktor. From nobody Thu Apr 5 02:03:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C965D1201FA for ; Thu, 5 Apr 2018 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PsFgZ_q4qxf for ; Thu, 5 Apr 2018 02:03:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA992126DED for ; Thu, 5 Apr 2018 02:03:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40GxgW0XbRz2C0 for ; Thu, 5 Apr 2018 11:03:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522918983; bh=9fR20tSJzqbB2c4wvBY28/lD4R63X4FuKbdi+vHSlXc=; h=Date:From:To:Subject:In-Reply-To:References; b=niGy2ZUABRNm6ZHnaBbY4rxVtqeGsO/96BUdQKiMTVsVZQ21/Pbvw/ZhOfzpk8kQY ew9F9Tzb/4OLqr7dt9lqwcYBzql84FIMqtOyNxy0NDU3X3e5EI38Ysu4NEUq+iYQ2e jnNZGglRLNgyI8R6G/mZ3bxfotcNqdhQgyIHQ3oA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tuQSz1Su94xS for ; Thu, 5 Apr 2018 11:03:00 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 5 Apr 2018 11:03:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E5C853531DD; Thu, 5 Apr 2018 05:02:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E5C853531DD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D76094095AB2 for ; Thu, 5 Apr 2018 05:02:59 -0400 (EDT) Date: Thu, 5 Apr 2018 05:02:59 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: <20180405022007.GG25259@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 09:03:24 -0000 On Wed, 4 Apr 2018, Eric Rescorla wrote: > HPKP had a TTL and yet as a practical matter, people found it very problematic. > And, of course, if you're concerned with hijacking attacks, the hijacker will > just advertise a very long TTL. By publising DANE records with either a TLSA record or a denial of existence proof, you can override any longterm TTL. If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension containing a valid NSEC proof of non-existence overrides the previous TTL/PIN. In fact, this is one of the reasons the WG should decide to fix the current draft to include proofs of denial of existence. Paul From nobody Thu Apr 5 02:06:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205EA126D0C for ; Thu, 5 Apr 2018 02:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEStb73-upYL for ; Thu, 5 Apr 2018 02:06:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8D21201FA for ; Thu, 5 Apr 2018 02:06:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Gxly2cd0z2C0 for ; Thu, 5 Apr 2018 11:06:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522919214; bh=TxEewVdRxnpan4Qg2zdiXE3q02eQZg0TbDv7IuhCsxg=; h=Date:From:To:Subject:In-Reply-To:References; b=WEf+DjOVWZbhPMnEE6J1/EdsIho3J/aWXya78G/AK5A25Bo9M3Y2Fuh9Apw1BHXx7 uwhhCJ5XDLs0xZ/MnYUllT93wjXH2Btp6c69sc7EK2qYFLIcelha0t+emnO69liLV1 u4mqYR63SNZCp613zri79Ruf+zK4Gbh5uyDrpKis= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sjkwCxuJJK4v for ; Thu, 5 Apr 2018 11:06:48 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 5 Apr 2018 11:06:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2687B3531DD; Thu, 5 Apr 2018 05:06:47 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2687B3531DD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 193404095AB2 for ; Thu, 5 Apr 2018 05:06:47 -0400 (EDT) Date: Thu, 5 Apr 2018 05:06:47 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 09:06:57 -0000 On Wed, 4 Apr 2018, Eric Rescorla wrote: > 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's > a pain). This rationale was stronger back before Let's Encrypt, but > I suppose some people may still feel that way. > > 2. Restrictive: To protect yourself from compromise of the WebPKI. > > Yes, if your motivation is #2, then the flow you suggest is a real problem, > but it's not a problem for #1. While not an author of this document, I'd > understood it's primary motivation to be #1, and that's what Richard's > earlier notes have said as well. The primary use case of the author's is not relevant. The document is a working group document, and people who have contributed to this document from the start also have valid use cases. For example, I proposed to use the DNS wire format early on and the WG made that change. My use case was never to create a "DANE or WebPKI is enough" security model, as I do not think that model helps anyone. Paul From nobody Thu Apr 5 02:13:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4551201FA for ; Thu, 5 Apr 2018 02:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kSqLcMi-kM3 for ; Thu, 5 Apr 2018 02:13:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A300F1270AC for ; Thu, 5 Apr 2018 02:13:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Gxvs3rhCz2C0 for ; Thu, 5 Apr 2018 11:13:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522919625; bh=gcZyHMPyR4Zv97gzgIF32AIxI1icf1n7vWSSTrXi9Ig=; h=Date:From:To:Subject:In-Reply-To:References; b=E0LgrO0FXEk5ngij0FiwwXpuQSYo2upcywBII4Z/KiO5WZ1Xv+CFuT2jID/gb84v7 AN24eqeHixwO2W6srqsXupHy0DylrbKrc+bF762+0Adb8jcQmraQQtQNGd7zSUYXqx sDC0wo0HdcrCj97mYMsdxZqwW9kOb80yUPliwaHo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Zkc1_0KVXBd5 for ; Thu, 5 Apr 2018 11:13:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 5 Apr 2018 11:13:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4FFD93531DD; Thu, 5 Apr 2018 05:13:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4FFD93531DD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 46ED84095AB2 for ; Thu, 5 Apr 2018 05:13:42 -0400 (EDT) Date: Thu, 5 Apr 2018 05:13:42 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 09:13:53 -0000 On Thu, 5 Apr 2018, Richard Barnes wrote: > And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today".  There's nothing in here that degrades security You mean other then LetsEncrypt destroying the ecosystem and leading to a "one key to rule them all" situation? The webpki is changing dramatically. The amount of CAB/forum violations seems to be increasing, partially as a result of these violations getting exposed by certificate transparancy and perhaps partially because of the financial strain caused by the free LetsEncrypt. Allowing people to deploy another PKI is not harmful - forcing people to stick with the webpki could prove harmful. > That doesn't mean there's not still some utility to be had.  Your tls-extension use case can be supported regardless of the outcome of this consensus call. That is not at stake today. Other people's valid use cases are the ones that are at stake now. Paul From nobody Thu Apr 5 02:22:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119012702E for ; Thu, 5 Apr 2018 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKQ4j_JVMB5g for ; Thu, 5 Apr 2018 02:22:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEDF126579 for ; Thu, 5 Apr 2018 02:22:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Gy6F0ZlLz2C0 for ; Thu, 5 Apr 2018 11:22:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522920165; bh=IeN56b98DNPhyRFiEUY/iPj+r/j7YUYkS77hp43vxdg=; h=Date:From:To:Subject:In-Reply-To:References; b=C8mNmCgpdBC15NhYSo1CSSNoVrOykfYVpyuMeWyHy7JKtzdYiTe6yPsiNPu31JvW8 j98s3b6XtqzxXKvECdVxfJxLxRAwdr4IsTxRT65+LBS2BNu1zB7q6onExT5WmsKGf4 vwWiJ0cD0kKDjG0sKWWm4gj1Yk6BBvWr+2/W9PoA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7QMm9I1UDpVR for ; Thu, 5 Apr 2018 11:22:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 5 Apr 2018 11:22:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5B0693531DD; Thu, 5 Apr 2018 05:22:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5B0693531DD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5420F4095AB2 for ; Thu, 5 Apr 2018 05:22:42 -0400 (EDT) Date: Thu, 5 Apr 2018 05:22:42 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> <20180405030945.GN25259@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 09:22:49 -0000 On Wed, 4 Apr 2018, Eric Rescorla wrote: > The motivation for opportunistically using this is to be able to > incrementally deploy DANE for HTTPS (and browsers).  Without that it > won't get deployed at all for HTTPS. > > I don't see how this is responsive to the concern that this technique will > be used for hijacking. To hijack a DANE TLSA record, an attacker has to take over the DNS domain. Controlling the DNS is equally fatal for the webpki, as you can just ACME a new certificate at that point. So the hijacking case is not made worse at all. But the compromise/coercion of only 1 of 600+ (sub)CA's is actually protected against, making DANE a stronger authentication alternative. Additionally, in the case of forced domain transfer in relation to an ownership dispute being litigated, the DANE based pinning is actually superior to any other kind of pinning, because it gives the (new) domain owner full control to cancel any outstanding long term pins distributed by the old/previous/malicious owner. Paul From nobody Thu Apr 5 02:31:18 2018 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 B396D126579; Thu, 5 Apr 2018 02:31:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux To: "The IESG" Cc: draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152292067172.25904.6713770378882293720.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2018 02:31:11 -0700 Archived-At: Subject: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 09:31:12 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-tls-record-limit-02: 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-record-limit/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, I'm not a TLS expert so please disregard if this is irrelevant. Document says: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length". Do you mean: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length" *only*. If so, what would be the behaviour of a server that supports both "max_fragment_length" and "record_size_limit" in that situation? From nobody Thu Apr 5 02:35:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098501270A7 for ; Thu, 5 Apr 2018 02:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38lPoRlUWVbO for ; Thu, 5 Apr 2018 02:35:41 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF11812702E for ; Thu, 5 Apr 2018 02:35:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 453B546F98 for ; Thu, 5 Apr 2018 12:35:39 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id JL79wsnr8G4w for ; Thu, 5 Apr 2018 12:35:38 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (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 8915D73 for ; Thu, 5 Apr 2018 12:35:37 +0300 (EEST) Date: Thu, 5 Apr 2018 12:35:37 +0300 From: Ilari Liusvaara To: TLS WG Message-ID: <20180405093537.GA22690@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 09:35:44 -0000 On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote: > > > > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: > > > > A) Recommendation of adding denial of existence proofs in the chain provided by the extension > > B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL) > > C) Both > > Therefore, the real choice before us is (C) or not (C), the choices of (A) alone or (B) > alone are unsound half-measures. I agree that both (A) and (B) are bad idea, while (C) is sound idea. > (C) is essentially STS for dane chains over TLS with downgrade protection after first > contact, and imposes no burden on the present implementors. If they were willing to > implement without a pin or denial of existence, they can ignore the pin TTL and never > transmit denial of existence (which their clients would not expect to process). If one wants to save bandwidth in "cancel pin" case, one could add a flag into request that tells the server if it should transmit DoE or not (if it has actual chain, that should be transmitted anyway). That way, the cancel would only need to be transmitted once to each client, instead of potentially multiple times, and clients that do not support pinning would not waste downstream bandwidth downloading cancels they would ignore anyway. -Ilari From nobody Thu Apr 5 03:28:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07281270FC; Thu, 5 Apr 2018 03:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4QycnnJbquH; Thu, 5 Apr 2018 03:28:55 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22331201FA; Thu, 5 Apr 2018 03:28:55 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m7-v6so26667361otd.1; Thu, 05 Apr 2018 03:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XEKLl3J2hXs+tGBUZdsy5+jTgZo4MFtQJ1OjqtP5ck8=; b=Ho0w7N0Qtp4Me1VEk8FgSb6Ow7Jm2IeHrchK9DO6f0nL/M9EtdaBSf2fJFUA4pCy7T VENJEoClYXgI7WjgzjzOssfjeYeZ2Gjfr+SQlzEJCYxI8hlUSCPQy0z0r1GcwDnpkopw W/SgiW9aNQajix1oYd/8uKLrRMRPx5TptGF1ADlzIMC1LvdyVUBOMOU9av4B4SRZ/ROc wli0Sy5kC8PHHVXHA8hRH4d6t/X9xQ9Hdfp5NmhD9zzk2gtlsvnKHdxFYjm0PsHqghe8 Wmfvoh4dhSSTt/+2/cK3GlPvZuef62ds4BX1hgQT9Ka8+8QW7uSP3mShSBybUocFPIIB gUVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XEKLl3J2hXs+tGBUZdsy5+jTgZo4MFtQJ1OjqtP5ck8=; b=BZjAD1Km4zp3P8JWS8ArUDQr1Ij23AfmtC+1BaCpHE2cyTVCHOGIWaGq8Db+23ErDN 1RA+9L2s/mxhHsDn+bNb+FOKd3oaSUKct58OSlqBlfVCmm5wa9Zgrj6TVEP4f9Rv+DJm crM6DMloP+iLO1uLbqpfNWYML/sp25ubjeD78GmOuBuaqrwHvvQsC5zKDfNyYF3kT2YK Jy4zxpU+WU1EFW9uqzVq/U+LMifn102Rt2Y6ul4clB5ZWI4vkL4Nv6QL/tm9hWJ9tObB n+56EMmsxheVh/u1LfvS/UoZtVGl1wjoXTxoF8UcFz7Fez7MGl0kBP+V69lwXCKUuKRh ihCw== X-Gm-Message-State: ALQs6tCkVTqsXbLb+EgCVu18ev9tgPTpOgkW94NqKvM9c+9smuGNx+xV Qu6AEka37LvfjULQV4fTl+SI7svkQLxJ5SoseRU= X-Google-Smtp-Source: AIpwx489OpUKlQPOnMNYBjP7pdj1RG1sNLiexEciIMW+lnt1jhFXSZRLX38U65Karj1/bbS8w6RShM1XCGp4kv6Ostc= X-Received: by 2002:a9d:1311:: with SMTP id f17-v6mr689610ote.15.1522924135114; Thu, 05 Apr 2018 03:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 03:28:54 -0700 (PDT) In-Reply-To: <152292067172.25904.6713770378882293720.idtracker@ietfa.amsl.com> References: <152292067172.25904.6713770378882293720.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 5 Apr 2018 20:28:54 +1000 Message-ID: To: Martin Vigoureux Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 10:28:57 -0000 On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux wrote: > Hello, I'm not a TLS expert so please disregard if this is irrelevant. > Document says: > Clients that depend on having a small record size MAY continue to > advertise the "max_fragment_length". > > Do you mean: > Clients that depend on having a small record size MAY continue to > advertise the "max_fragment_length" *only*. It's "also". The idea being that if you aren't sure if the server supports the new thing, you might offer the old thing in addition to the new thing in the hopes that if the new thing isn't supported, the old thing might be. > If so, what would be the behaviour of a server that supports both > "max_fragment_length" and "record_size_limit" in that situation? If you don't include record_size_limit, you can't use it. If the client includes both, then the text from the preceding paragraph applies: "A server that supports the record_size_limit extension MUST ignore a max_fragment_length that appears in a ClientHello if both extensions appear." From nobody Thu Apr 5 06:33:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C124E12D88F for ; Thu, 5 Apr 2018 06:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDN8s3hPHRJ3 for ; Thu, 5 Apr 2018 06:33:51 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3163E12D887 for ; Thu, 5 Apr 2018 06:33:51 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id f47-v6so18252633oth.2 for ; Thu, 05 Apr 2018 06:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m3cJkC5gaMnkFQx3RHiSoL51BNR75kUBV8t+EQ0u/Gc=; b=dAD3XN0EVEpOA+s0iMSKq7ge1tW7gEQnqQ9NchjNB9wSza/iFsk2ZcRl0BGZaUF/U/ sUQUsZkR3efuU+L/fWuD1N3gx6UUDRQOUkp6soLzDB0lq110MUtzSykH7JCYJVyyRgD+ EgXor0gQLcMj1wQadzEnQf9mpUFc/7MTvkSo+GnEWMODDmfa6oKgPlnIZV84bBjK1pJ2 wq3H1WeQtwTdVBgth6pXgalJcX2KhvN1ji/Jb/5MFFHFUms/ht3O3v35kflBK8zVY2Td u1mLhfVulnYA+4VehYihCBNZ+FZHFew5mjtMkRF+yMluh740S14Acp53Z3uve9T54cUw PHew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m3cJkC5gaMnkFQx3RHiSoL51BNR75kUBV8t+EQ0u/Gc=; b=ZRLmfavx4Xo+xLDElhpb7cdcJ1Kv2VDsS25xBYLwykKBlb9mAoTezUgLUIRyj6LhYN Y7wPrQ1WhzCUxGzONmiLFSrWkkiFhcCBTvaBztjFZAJpI9iGIpqtAf72QeubnEGA5J84 egTAhIUVsmqeL+kfoQ9m/b+xfAPqsxGCc/16A8iV3sMtR1NBqnuQBsF5alAfdAh0dlcA 9rFZPD53alOf1fyzrMzH1wObfm4273UOOjivmDttUWqbmeRMU6eXcRx6XUxTztgwUJAG rj64lbmVfFmpcEKbkPKmvu71jYd7KN+d+MPHYnQbmCvfWVgBnVUPo+vIvN1tNhmaFt+s cPvQ== X-Gm-Message-State: ALQs6tBH9W/g7ZMgA0O4catUdyXKh0cH5CWnpd8ezgc+CzjM6INl4cr7 ZLOW/FHP9P4lkT9shVWfQ4YT1VgnNbdk0spl9Uz0+EJB X-Google-Smtp-Source: AIpwx4/JIRu9l7B5ed6DtfKGYQgr/Fn1XlqB+wHs65HjpnK3aPjJ7PG5OvrKts4X5LGuOM/xsbV9A7kNyHeEjhTYbsk= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr13236327otb.101.1522935230561; Thu, 05 Apr 2018 06:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 5 Apr 2018 06:33:10 -0700 (PDT) In-Reply-To: References: <20180405022007.GG25259@localhost> From: Eric Rescorla Date: Thu, 5 Apr 2018 06:33:10 -0700 Message-ID: To: Paul Wouters Cc: "" Content-Type: multipart/alternative; boundary="0000000000006f15ad056919fd7f" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:33:53 -0000 --0000000000006f15ad056919fd7f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote: > On Wed, 4 Apr 2018, Eric Rescorla wrote: > > HPKP had a TTL and yet as a practical matter, people found it very >> problematic. >> And, of course, if you're concerned with hijacking attacks, the hijacker >> will >> just advertise a very long TTL. >> > > By publising DANE records with either a TLSA record or a denial of > existence proof, you can override any longterm TTL. > > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension > containing a valid NSEC proof of non-existence overrides the previous > TTL/PIN.' Thanks. This is a good point that I agree does not apply to HPKP. However, that doesn't mean that hijacking isn't a problem (though I agree a less serious one). If I have no provisions for DNSSEC at all and the attacker does pin hijacking I could be offline for hours to days while I figure out how to get and serve them. -Ekr > In fact, this is one of the reasons the WG should decide to fix the > current draft to include proofs of denial of existence. > > Paul > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006f15ad056919fd7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 4 Apr = 2018, Eric Rescorla wrote:

HPKP had a TTL and yet as a practical matter, people found it very problema= tic.
And, of course, if you're concerned with hijacking attacks, the hijacke= r will
just advertise a very long TTL.

 By publising DANE records with either a TLSA record or a denial of
existence proof, you can override any longterm TTL.

If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
containing a valid NSEC proof of non-existence overrides the previous
TTL/PIN.'

Thanks. This is a good point = that I agree does not apply to HPKP.

However, that= doesn't mean that hijacking isn't a problem (though I agree a less=
serious one). If I have no provisions for DNSSEC at all and the = attacker does
pin hijacking I could be offline for hours to days = while I figure out how to get
and serve them.

-Ekr


=C2=A0
In fact, this is one of the reasons the WG should decide to fix the
current draft to include proofs of denial of existence.

Paul


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

--0000000000006f15ad056919fd7f-- From nobody Thu Apr 5 06:34:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B933112D887 for ; Thu, 5 Apr 2018 06:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87_iK1QuPgV8 for ; Thu, 5 Apr 2018 06:34:47 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47AC127444 for ; Thu, 5 Apr 2018 06:34:47 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id u141-v6so22557348oif.1 for ; Thu, 05 Apr 2018 06:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GcO0Ip2gOC+tfBQkvpSIMlc2KwwquOQfaHjFh6eVET4=; b=sFnOV0A9DV30yVmK4xxDEQ8u/X1NZZEaIAgIf90zfk71SgXKUNwSB1TzOMp5Oclfy0 UNw8z+ANikWCj5ynEtQpv6vICrlp/qw5B+6eXnELdjdxR3bV7HT/hfFtTaxjpb0/s97X oUImvZul8ut9T1bMUKvI3c84c7+bfNDvXGXgOKjEBHIKscj9x9Iq+gCKydHp9kdf7m+Y BlrqViMpbZCg25KU7esJlZJRxOf3R/ELcXhQk+Ktxj9t8Iru/6PcPnVZF00apTwfjahL gyG9dOVnsjLSgCGefa8KkfvZ5l27LqLRI5qzeXHQ20+AYgsHBVEWsCgsCKJ0FU9lS5WH MrNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GcO0Ip2gOC+tfBQkvpSIMlc2KwwquOQfaHjFh6eVET4=; b=l/jnW1ZD/YKPfJaJ74eqw4Z2rxrW2nOo/wpjLrbBgtJOIJE7buV7g5Zm0Bz0ollAg9 ZPCqCDVGP16Mbcc/bbkXVUmTyp7oh3Gtv8+dGiyoeu6KyT2z+WjUTXYd+/z8HX9K8fds jjQoyN2sIPXf99yGBDV2tsxP66FojsCxmBBZO2/qON6twBGxkMFuDwpTNqq4ozK5CCJm Dw+cbiMFEexhaxUR8IxY0kC4wyGJmg8n9IDM3vZNVE+vNXmb6ipg+bhzs5UmTDVTrcfd rx845XPykhPBkwq+/CEW2ZPfEV0RFhi2m3YEQW2Lyugb3g2wIzkeBpxokS0cKj1+cdpb 9ahQ== X-Gm-Message-State: ALQs6tAJ+cczSc60ILKMCzv8n3ak8+DGkDRawxhbkZa6iEd+pmvUxmH0 i748X550pQ81yEFC/GsS4rRHn3XPZA62fsV1AZyYaA== X-Google-Smtp-Source: AIpwx49PHMuf0GD71ZpzIENoqxkNypO0vpAPxdxWT5fEvKpzwhSieDSwrto0bdLC1V9OBSE81DCMsx28UbTi0exuKJ0= X-Received: by 2002:aca:544b:: with SMTP id i72-v6mr13458167oib.262.1522935287210; Thu, 05 Apr 2018 06:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 5 Apr 2018 06:34:06 -0700 (PDT) In-Reply-To: References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> From: Eric Rescorla Date: Thu, 5 Apr 2018 06:34:06 -0700 Message-ID: To: Paul Wouters Cc: "" Content-Type: multipart/alternative; boundary="000000000000cf8a1105691a0095" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:34:50 -0000 --000000000000cf8a1105691a0095 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 5, 2018 at 2:06 AM, Paul Wouters wrote: > On Wed, 4 Apr 2018, Eric Rescorla wrote: > > 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's >> a pain). This rationale was stronger back before Let's Encrypt, but >> I suppose some people may still feel that way. >> >> 2. Restrictive: To protect yourself from compromise of the WebPKI. >> >> Yes, if your motivation is #2, then the flow you suggest is a real >> problem, >> but it's not a problem for #1. While not an author of this document, I'd >> understood it's primary motivation to be #1, and that's what Richard's >> earlier notes have said as well. >> > > The primary use case of the author's is not relevant. The document is a > working group document, and people who have contributed to this document > from the start also have valid use cases. > Of course. I'm merely responding here to the claim that the document is useless as-is. -Ekr > For example, I proposed to use the DNS wire format early on and the WG > made that change. My use case was never to create a "DANE or WebPKI is > enough" security model, as I do not think that model helps anyone. > > Paul > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000cf8a1105691a0095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 5, 2018 at 2:06 AM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 4 Apr = 2018, Eric Rescorla wrote:

1. Assertive: To avoid having to engage with the WebPKI (e.g., because it&#= 39;s
a pain). This rationale was stronger back before Let's Encrypt, but
I suppose some people may still feel that way.

2. Restrictive: To protect yourself from compromise of the WebPKI.

Yes, if your motivation is #2, then the flow you suggest is a real problem,=
but it's not a problem for #1. While not an author of this document, I&= #39;d
understood it's primary motivation to be #1, and that's what Richar= d's
earlier notes have said as well.

 The primary use case of the author's is not relevant. The document is a=
working group document, and people who have contributed to this document from the start also have valid use cases.

Of course. I'm merely responding here to the claim that the document= is useless
as-is.

-Ekr

For example, I proposed to use the DNS wire format early on and the WG
made that change. My use case was never to create a "DANE or WebPKI is=
enough" security model, as I do not think that model helps anyone.

Paul


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

--000000000000cf8a1105691a0095-- From nobody Thu Apr 5 06:35:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789661275FD; Thu, 5 Apr 2018 06:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzorXqymLceU; Thu, 5 Apr 2018 06:35:49 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0096.outbound.protection.outlook.com [104.47.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B25012D887; Thu, 5 Apr 2018 06:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjsudhQeJNnsIFoaKYMXfHWkIe/eyo8B5Sm5XSIUS9k=; b=OaN/wdaXy9H/TOw+9yIcMcOgyPS8NZ83l70gC9A8g5g1kpt4OouvZiw3XE0BD+QODlkv/Y+zhL6DoogOEAgvCo0i5ZmCIS+ph1bsmZk5Ww9mmtcOac/1Ha0i8KDSAYQ6OASmbRqEVSt5a4553tkjA/6zT/yeugBiIahHDNOQgJ0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [135.244.230.53] (135.245.212.53) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Thu, 5 Apr 2018 13:35:45 +0000 To: Martin Thomson Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, Sean Turner , tls-chairs , "" References: <152292067172.25904.6713770378882293720.idtracker@ietfa.amsl.com> From: Martin Vigoureux Message-ID: <237e9364-6b9a-28eb-da0d-5e032cae86eb@nokia.com> Date: Thu, 5 Apr 2018 15:35:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.212.53] X-ClientProxiedBy: VI1PR0501CA0003.eurprd05.prod.outlook.com (2603:10a6:800:92::13) To HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:2b::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 852e844b-2083-4333-b8ca-08d59afa231d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:HE1PR0701MB2139; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 3:cX/QTmXnzwBOMwD+cV1DYdRTGk7DwcJKUoXhuziHgWr7dZX3yXZ01nRKC+8eeBg0/EUssUaNQ+kgX8VoXJOyrYdUQSCr7f/hHffAHKJMEEe2iuYc/x0NVxgGkITpDXDHU+WrGy37hYx0N86Bqg5j+BJ8fhGSTtp3i+5GIxlMS/tkWhRGS5x0asQHFpufG+nTnKakW8kYD6ydMDwJDfEXM14I3bGEdvdvX47dmN/rlts/oCiZxTpZrkBugpHDQj6Q; 25:dFRF2XXJzYAei+BX8MzAM8W2iukMAivCxzIWQ23PjpP8F1PgKpYs4/uronPcmw24bQPjq8c2EJbh98tlZOgl/NsSplIkeuuwzoTCnUvKr0CoXDz5vlJgvqcYa2zoHZbgOFkITTVaOjqt985S9Hj4QvrSgN3ZTygNRCtfHqeDNzQJV+H5AFbsObVqTH55nQFNeMT4wl8eHAQPBClMObMILGER/1zvFxcG8DJ1GsHF5TW+XV+F0LJxctqa+KrD5JYX8wePSYRVYA1yWBadWAHYwypY089UE6QrfdFmiwWNiaG2Rj5enz8wjCOmeAm5XBi4KUvVWNFEJovsBv3djOXOgg==; 31:nTrnyDsQyzjDyV9aDk8aZw/sBefTMNmS7OmDoJSTp67HMu5fyxWdOTv8wxKJmZs6f2+CWnYk/w0M9mAtq8ZIMlHDZAlIDkrmV6bJRopW5uZxP69E6BF8HnY5OU1z4Wdc3xte4Ccrg2FzVUbZqLdpZVrF/TBw8B5kaCUvmBhVmCNvZheL0kuFpzb5mGS0xHdM4+ns65vWY1Vky9NXVQNxB9UPZKuqrdbWAcrFi+Dh32I= X-MS-TrafficTypeDiagnostic: HE1PR0701MB2139: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 20:FPybOz5Puy5xMIFZ+jqYqZxtzWwUjwmLE0tblGJMA2m0p2R+dA/HPlrWDKsMSek/SybliqJRC2G8prGgf6lYnzrbxxRlt3pYWQmZVHxVu+ewLlsYRlJuPnsEP7NBu4fbvc0EysGhiRCJAbZM4qD21JJUrWjKA60EUBGqxDDlJCMd0/Pp6kS0GSjZCV6htyLTaElcolKpl43O95D2FjEysqNuuaw4YG7KG73CgGbGIMz57T/DmvAsWFLaVz10wnlqd2YjLEkZC9zRMRqMgwV7bQAwSp0UBJ11e6ycsOwKgFLxC8nEEAp8KqVh1oVjRkrjVOFwFKX/M/9/MJqBkrQoSCNKMksssMRstoJnyUyo0wFkYWIJbuiVx0XGSKNXyZ8Ztabd9xnFQKJOuYI0gObVT0l0TpHxAb3Cl6wCybBd7XfIZvchPA4E62HRMIk33s8trLuv3lcvdeopV1Dh0Yi2WKep4Xkxcyzhj2NANc+hNlkJ2x09tOZ9h2mcTnOZxbKy; 4:YCF3rdeefk1HkG/g9zXNgNnsWwEURXOcGYHpfTPrEohbEGqiEltHdFBPW/fmsZG7nEl+tfqMeKUaZ10vFbn2Nkd0j4tfLUdoxSOwlWoeBazm+jd100yD6ASMoHCTg0c3+1T91W0/KMsXt3c6cKn+UV0IoZpEyyTenWukLFcLqPy4KV3crSHjmjEY3OJgBaL2tzUGzAnu5r1jaIFvnti5gIx4kGiT3llViznY7V0dj9iHXqrNagqrGn6QKERleb0qz76P+rus9f4IgDsFjdJIQvyGTxCdw5y7qp/WTKxacx7+6AaoYOpSXOK6RInJllMmXAdTtiwYpJVPUdQmG9latOK8K0cBFRjh2Kc9+o36rdQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR0701MB2139; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2139; X-Forefront-PRVS: 06339BAE63 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(39380400002)(366004)(346002)(396003)(39860400002)(51914003)(189003)(199004)(377424004)(26005)(31696002)(6486002)(68736007)(305945005)(97736004)(50466002)(53546011)(386003)(36756003)(59450400001)(5660300001)(76176011)(64126003)(58126008)(65806001)(11346002)(8676002)(66066001)(316002)(86362001)(446003)(16576012)(81156014)(81166006)(31686004)(7736002)(65956001)(106356001)(16526019)(956004)(8936002)(229853002)(6916009)(49976009)(39060400002)(2616005)(186003)(67846002)(25786009)(3260700006)(65826007)(53936002)(4326008)(52146003)(2486003)(6666003)(47776003)(52116002)(54906003)(476003)(3846002)(486006)(6116002)(2906002)(6246003)(2870700001)(105586002)(23676004)(478600001)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2139; H:[135.244.230.53]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjIxMzk7MjM6T0dqR0E4amJtVlh6STAySVJvQUc5WUhi?= =?utf-8?B?U2xON1IyZWMxdENwZi9QQ3E2N1liUDBzUVJWN0ppNmpWZlhqQ3B3d3BDbHZx?= =?utf-8?B?Z3ZySjFBdEVFaVU5aC93NU1Ib05sQTIveFRoNzZSM3dGeWoxMnRhbFhCUFNT?= =?utf-8?B?ZlQreWlRUTUxUWhVQThTMkZUS00zQ3JoVDVLTUZLWVJRTlRoKzVTRSsrM3V4?= =?utf-8?B?WGpTVkl0OEZ3TUJVcmJpZUhXTzBtU3pUbHBSL054a2RXTjBhM3NZUEdPdVV4?= =?utf-8?B?TzNNNDhyTEpTdFRuVjFRZUZVUloxTUFxY2xXNEtEMkt3R1ZQWTNheUZGcHg2?= =?utf-8?B?MVEwNm91UVVNLzZ4WE1VUk9KQ0dwUkN1TExUOHl1NHkySmloM3lWMDRoZmd6?= =?utf-8?B?UWVNei9GamxZZ3VnQWxDMDdZWHVzYytlVktUODB6N1N2ZW1FUUljUWNKZk84?= =?utf-8?B?cHM2YTlidUgrakt2TU9jRXdlcVlyenJqeEE0d0RwMUJ3d2tvN2V5bm1xUm5l?= =?utf-8?B?cXBudHFKQ1ZScld0dFBZL1hEWTkyaUo3OG42aTlJcm1JZE1wKzdGZlNvU2Z4?= =?utf-8?B?TzFuMi9UTHNKR0V4bGNxbXZ4WHhkUnBWR0dBVGNKeldWWmNHVDc4MTJwVVly?= =?utf-8?B?Qk5rK0tyWnIrd2tIdk9OcDdnNHRnVnFMTThzbWg2UitVNEloa240bU5pQWFD?= =?utf-8?B?bFZMZExCVDBLRmFLVzJ1R2ovUUdiNkVJSXNuV1NiaUQ3cTJpVzVUdVh6aUlW?= =?utf-8?B?U3pBWXkvMUhFSWZ5bmRlKzd5MkFNOTNKbGk3MlA2UjhGY2ZTV2o3WVJTUWxh?= =?utf-8?B?K0xRa0grNzl5MEphdkpqMDRuWjhBZHdYamVOUE9KOE5XZ1RPOS8yTGtpNkdU?= =?utf-8?B?ZXl4Q01yUVRrTkhwakVkaWVyLzNnU3dXdi9OaE0vVUlWQldhcDU2MkFIMHR0?= =?utf-8?B?cE43QythVElhdFJ2NjlVcnZjVldNZSs1dDF2MDJQQkV5VmNTMHlBbXl0RkJq?= =?utf-8?B?ZzBvYjE5TlFVL2NsbDJaYUpoaUFkYnhrVHNwcGN1S0J0YmM4TTFKbVk5Mnlw?= =?utf-8?B?TXUzWFE3Q3k1TEdBSlJ3dDhUczJWbDUzN3JzQUdqMnZzOUN1MjZQVUJoK08z?= =?utf-8?B?SHNCY081QmJSbUliejcyZkFiUnhBZm1tUERKNGYrcW1lQzk1d2JJMXhicG9M?= =?utf-8?B?UWFWUFozOHFDR0xsNzFESWNyQXpnbm9xZk16ZlFGSE42NlIwajVQT0UvYkpj?= =?utf-8?B?MWx3ZUpRTmdMdzMzVzJwdWs0SGQrVmQ2YzcvWmY0QWJ1WlFsNXNwUUJvTkNl?= =?utf-8?B?SGNVdkl4QjRmSzZ4UXUzQXo1Mm44UE01TWpOZms1UXhJdjA5REJZcjc2V1lL?= =?utf-8?B?YzR5VHYvM1B5MEZEVGxzOTRaVHloWjZGTWZ5aHJ3dmpJUW00OGdyMEIvd1B0?= =?utf-8?B?SXBrUm55WGFZZk04aUw2cGhmS3dRUEU1Z2ExSFJZdWtYK1VUdFozc0lHY2ZO?= =?utf-8?B?K25RYnlrMldSZXZFZWlKelBwUVVyVFZIYlZTWVdoZXhsOGR6Y0pTV1ErSTBZ?= =?utf-8?B?dmNDOWJkN2xXTUozS0ZmdGVYTlpOU1U4S3o3cG1PbEorUW1QelFKRzhNQU02?= =?utf-8?B?OGRTKy9LenlxU0V0d2ltNENjaXUzek5zSC9oMCs3Y0EzLzI3TkwvcHdtWmhC?= =?utf-8?B?am1xSytGbXU1aVlRdmh5SG5lTlhwL2FVU09FWTBwNmFNZTF0eEdCMThIY2Mx?= =?utf-8?B?RTF5VkVvbmpVbnllcDNGY1h1cjJrbkNIOVhZRjd0QjlXTHBlMGg2OVBBNjdF?= =?utf-8?B?THllNHFGZ0dVOGpXeFpxL3JPTmRxNnpZRVczNTlZUTNJdFEwN2JSc0J1RVhr?= =?utf-8?B?a1hsZm9NZkdMTGRMbjJqZ1FDdHpqQnVyZDZhVGZHR1l3MlNGOE8zZFlFRE5n?= =?utf-8?B?emR1dmFDUnBVU1RMRkoxczNBUzIvekFWbDNweVp4TXRSNEh4UW1PbC9ybE9Q?= =?utf-8?B?anhqVXlSd0dJTjV2dHRaaFltVzZOeWxpdEpMckM0blVPcU1GTnFSWWdZbUMz?= =?utf-8?B?ZDJvaGtaYkNQbkN6dkY1TG5MSVFmQ1JUZUIxc1BWYkw5YklDQlJTcENFTmxv?= =?utf-8?B?STF0bGQ1Umc3ZzVrSE1Td2kwSVlTOTVwR3MvOTNnRm5NMUVvQjRBZmdyNGYr?= =?utf-8?B?U1RBbnBFeG9LQzd2Z1dGN2UyZmZ4SXc9PQ==?= X-Microsoft-Antispam-Message-Info: Hdq8c4lTG3ICLKEJOVBX2TxAz8u5Tzk1+tMzk4H1UrVTPmDxZrKRIItfe5Im42TUJpHUe+VFe67wThMvzYF3EJg6eKpuxzKacdMJaFFdJI0CySLsiqUNBOnLp2SzF4lr3Cxh3Rvu18Skai6j2V1EAnqFMeyIO/GemdKVk15D5iWsRP7A9Oy7A7yP2IvO5nclcVunCKAVFgSR7XDQ86XP+qJBgBh8dfpcR+VzqxyNyjqTH2bU41Ulb7bbsyCUUGe0 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 6:3HnmpGeIw8Jsuk6pYguSAqed/naFwbVaAqSMbj/K1BJnk2Tp2qzTBJt71GF1SOz3HfrKC2pIcCOgELh43Z2uJO1USR2stHsAsRMbDybyQ5wcw0uPpPn+zntyxlVktW3KTPLNz7VrDRlbyvHAYmE1FWINLg0VlQVKCKEtAgvzbwSDzC5d/0Wl5JRi7fuuFp3iQBID+LqaDyai7eq24Dvnxb8JPruYEVjH9kFKgmZ/YVFCUyBQbJUJshWANEWdWFnN7twQNvvJPFpB4PyfffeVEdHx0qMywGSeC82niiD3q37KiXxgO0P44VFE/YjHMqEJED8M1/ylHTWVI5hafkkRTPzSyIP1rWNFlWumHzf8UEzceV4iU2ryhKj6VgTjfZJkkthEVE+8Ne0Mtio1uZJwEA9r48VBUBkp/CU16bburXOj0f/6kfmlYlyN4B0kTmXgfD/pP6yfdzUOoxo0Yz5Q2g==; 5:2gc625mSM82e0k87w3bdN3Go058Br6WXB8D1GsG17aSpMKqOUFHqhLr8rfR+oQTIGY/5dZQtr4T7OmJfxceREKkifu1J1AjWAkAhLMY+nZU96p2//AENDBueWk+t9ew4qjTz4M1LGWkDV0h4dKQ8Ke/i3skhPlxduYg3cq/EL4o=; 24:8iyCGkajKxDTB8+UJVyb5z/8pVU3xnjPsEj8ZWwOYrZ/x237v8sDzTP3HMEDp7f/4AMlGrhTFWUI8ivKrJggIUiPY5DqdRgWRmmv1DD/FSk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2139; 7:Wn880Tz+3KYvrKakTtxwm91CHpEjYST9HuZnW7mc2sSUIFtKqZR256+JJUVqKvN3J/OGrcrVmejFU3cJR4jlibQnbn8rLak0nM4ekNj6B4aQd8qP3JVWhIladyx99adrVrXpfU5Z7hnPORtrEXJUzX8hv3htyHbqoN/5eatjT6kdPjrClW0HGxG5p3oZNO2dEIpmCYVYe8K/7GgKHJUzhGUA5/HXb+0lzUE4aJusJN1rEg/VBYsuZ89aVcN6rGYG X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2018 13:35:45.8149 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 852e844b-2083-4333-b8ca-08d59afa231d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139 Archived-At: Subject: Re: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:35:51 -0000 Martin, thanks for the quick reply. That clarifies. I asked because the paragraph above that sentence somehow already implies that clients may continue advertise the "max_fragment_length" (at least that's ow I understand it), so I felt that this sentence must mean something different. -m Le 2018-04-05 à 12:28, Martin Thomson a écrit : > On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux > wrote: >> Hello, I'm not a TLS expert so please disregard if this is irrelevant. >> Document says: >> Clients that depend on having a small record size MAY continue to >> advertise the "max_fragment_length". >> >> Do you mean: >> Clients that depend on having a small record size MAY continue to >> advertise the "max_fragment_length" *only*. > > It's "also". The idea being that if you aren't sure if the server > supports the new thing, you might offer the old thing in addition to > the new thing in the hopes that if the new thing isn't supported, the > old thing might be. > >> If so, what would be the behaviour of a server that supports both >> "max_fragment_length" and "record_size_limit" in that situation? > > If you don't include record_size_limit, you can't use it. If the > client includes both, then the text from the preceding paragraph > applies: "A server that supports the record_size_limit extension MUST > ignore a max_fragment_length that appears in a ClientHello if both > extensions appear." > From nobody Thu Apr 5 07:08:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4508D127599 for ; Thu, 5 Apr 2018 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD1N7FPbc1mT for ; Thu, 5 Apr 2018 07:08:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500F012D890 for ; Thu, 5 Apr 2018 07:08:09 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2D2987A330D for ; Thu, 5 Apr 2018 14:08:08 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 5 Apr 2018 10:08:07 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <2931578B-8500-403C-9CAF-89FBADCB0B30@dukhovni.org> References: <20180405022007.GG25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 14:08:28 -0000 > On Apr 5, 2018, at 9:33 AM, Eric Rescorla wrote: >=20 > However, that doesn't mean that hijacking isn't a problem (though I = agree a less > serious one). If I have no provisions for DNSSEC at all and the = attacker does > pin hijacking I could be offline for hours to days while I figure out = how to get > and serve them. Perhaps you did not see my explanation of why the pin imposes no = obligation beyond supporting the extension in the server software. A server for an = unsigned domain can just serve denial of existence of the domain's (or a parent's) DS = record. So you don't need to "get and serve them", you just need to forward = whatever is the true data in DNS about the server's domain. Only the capability to = present the actual DNS chain is required. * If server's zone is not DNSSEC-signed, forward NSEC records = showing existence of NS and non-existence of DS at or above the = requested: _443._tcp.server-fqdn.example domain and the requisite signatures up to the root. * If server's zone is DNSSEC-signed, but no TLSA records are = present, serve NSEC records proving non-existence (or NODATA) of the = requested _443._tcp.server-fqdn.example IN TLSA ? records and the requisite signatures up to the root. * If the server's zone is DNSSEC-signed, and TLSA records are = present, serve the requested TLSA records along with the requisite signatures = up to the root. All three of these would be obtained and cached (up to most of the = advertised TTL) in the same way from a suitable resolver that supports chain queries, it is = up to that resolver to return the appropriate response each of the above cases, the = server can treat the data as opaque, modulo determining the time for which it may = cache the response so that the chain need not be re-fetched for each client = connection. If one is worried about hijack by someone who can cause the domain to be = signed with TLSA records published (so as to set a non-zero pin), then one = might be motivated to have server software that is capable of returning the = extension. Just as with STS one might need software that supports TLS if the = hijacker deployed STS. I don't think that such hijacking is a major risk, but if = that risks drives adoption of the extension (without any other changes in tbe domain's practices wrt. DNSSEC or DANE adoption) all the better. :-) The domain might need the extension some day for more than just hijack = recovery, and it will already be available. --=20 Viktor. From nobody Thu Apr 5 07:21:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4001205D3 for ; Thu, 5 Apr 2018 07:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T53EGsIz6EeL for ; Thu, 5 Apr 2018 07:21:17 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B9212D885 for ; Thu, 5 Apr 2018 07:21:16 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c3-v6so22722664oib.5 for ; Thu, 05 Apr 2018 07:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=b/Do9vdZfeywxgtc0PbcMBjDlHr6iFneTssnnCnQMyI=; b=Rz93a8JpZPcqcCE1xL/PwWtLQJv4ZHGwK3au6wTdbqJglpilcQlHy3iAlFKePtsdAn a7hN02l2rZE63JWh7hItyZ7w6d/YswnC6PQRhxALaKTPSbqrDXt/s6tHKUzSAf4kwgNK l2avGVFbeo/zoCjRLoWoaimJqL/NpFE4kwSrtbzReWFQdpHgk5erjZEZEjP9uu/LmvZj 3ElHnRkY53q5xRlISm90u7gFyhoxf2/EI/LRin99hyr0R34LNTn0jOegGVNeIruel62k U960mfaOL3k7el/4NYneRAI/gF+ELnJ3v8e6bDsNuZIPEN4C8g76LMNHZpZA9eDOEOtd qhkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=b/Do9vdZfeywxgtc0PbcMBjDlHr6iFneTssnnCnQMyI=; b=aJr7425PgFrfRGbr+JVnwNe0txAYOoRQbTvgixfYMRQo610ud1YOcRGb7DxI08wMmY 3Y5sn3OqA8AkgjXKFROCPrncEIFQR8G5d7WIQc7eFjKeVBOYrs0KRKjn080QoH5OrAov 1Kf0iDji3c5miWRbI/9i4jtCHtMBxo8sx7n2MWKREw9zWXrANMj3Fb4ZZwpZVsWLg0nt utvNsn4se6OIP0Of8LmQNPiTxbkIN/QrI+xd+1rOapeb6wa6n/Bvfzdf2zB6/YbEJ36c caCMN0D3gyX8RxErSz48bnfDxbyprnWDIWuaJf8CvENFDhvPilUYRSQzSghtXM30B0yp /qGw== X-Gm-Message-State: ALQs6tDU0r0XNj+okuSAF/7bgYS0cQ++c3CKtqaVVj1KShqLZR1juA0b uYxYdsvLxEDjoOSCh4gwDsz0PORSUDWDqoXnrkwPpmKJ X-Google-Smtp-Source: AIpwx49kovTmeqam1Ig8sfS2TErpCYd0RhnYe3puJiFZf98Lem9wU8lJ6/IZkf1IF0POXy00Zvno4oez4jnfY+OH80Y= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr12188659oib.138.1522938076144; Thu, 05 Apr 2018 07:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 5 Apr 2018 07:20:35 -0700 (PDT) In-Reply-To: <2931578B-8500-403C-9CAF-89FBADCB0B30@dukhovni.org> References: <20180405022007.GG25259@localhost> <2931578B-8500-403C-9CAF-89FBADCB0B30@dukhovni.org> From: Eric Rescorla Date: Thu, 5 Apr 2018 07:20:35 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000000b31b905691aa7ac" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 14:21:20 -0000 --0000000000000b31b905691aa7ac Content-Type: text/plain; charset="UTF-8" On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni wrote: > > > > On Apr 5, 2018, at 9:33 AM, Eric Rescorla wrote: > > > > However, that doesn't mean that hijacking isn't a problem (though I > agree a less > > serious one). If I have no provisions for DNSSEC at all and the attacker > does > > pin hijacking I could be offline for hours to days while I figure out > how to get > > and serve them. > > Perhaps you did not see my explanation of why the pin imposes no > obligation beyond > supporting the extension in the server software. A server for an unsigned > domain > can just serve denial of existence of the domain's (or a parent's) DS > record. > Yes, so quite possibly I need to upgrade my entire server farm, which might be running on some software which has no version which implements this extension. This could be an enormous effort. -Ekr - > > So you don't need to "get and serve them", you just need to forward > whatever is > the true data in DNS about the server's domain. Only the capability to > present > the actual DNS chain is required. > > * If server's zone is not DNSSEC-signed, forward NSEC records > showing > existence of NS and non-existence of DS at or above the > requested: > > _443._tcp.server-fqdn.example > > domain and the requisite signatures up to the root. > > * If server's zone is DNSSEC-signed, but no TLSA records are > present, serve > NSEC records proving non-existence (or NODATA) of the requested > > _443._tcp.server-fqdn.example IN TLSA ? > > records and the requisite signatures up to the root. > > * If the server's zone is DNSSEC-signed, and TLSA records are > present, serve > the requested TLSA records along with the requisite signatures > up to the root. > > All three of these would be obtained and cached (up to most of the > advertised TTL) in > the same way from a suitable resolver that supports chain queries, it is > up to that > resolver to return the appropriate response each of the above cases, the > server can > treat the data as opaque, modulo determining the time for which it may > cache the > response so that the chain need not be re-fetched for each client > connection. > > If one is worried about hijack by someone who can cause the domain to be > signed > with TLSA records published (so as to set a non-zero pin), then one might > be > motivated to have server software that is capable of returning the > extension. > Just as with STS one might need software that supports TLS if the hijacker > deployed STS. I don't think that such hijacking is a major risk, but if > that > risks drives adoption of the extension (without any other changes in tbe > domain's practices wrt. DNSSEC or DANE adoption) all the better. :-) > The domain might need the extension some day for more than just hijack > recovery, > and it will already be available. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000b31b905691aa7ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:


> On Apr 5, 2018, at 9:33 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> However, that doesn't mean that hijacking isn't a problem (tho= ugh I agree a less
> serious one). If I have no provisions for DNSSEC at all and the attack= er does
> pin hijacking I could be offline for hours to days while I figure out = how to get
> and serve them.

Perhaps you did not see my explanation of why the pin imposes no obl= igation beyond
supporting the extension in the server software.=C2=A0 A server for an unsi= gned domain
can just serve denial of existence of the domain's (or a parent's) = DS record.

Yes, so quite possibly I nee= d to upgrade my entire server farm, which might be running
on som= e software which has no version which implements this extension. This could=
be an enormous effort.

-Ekr


-

So you don't need to "get and serve them", you just need to f= orward whatever is
the true data in DNS about the server's domain.=C2=A0 Only the capabili= ty to present
the actual DNS chain is required.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * If server's zone is not DNSSEC-signed, fo= rward NSEC records showing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 existence of NS and non-existence of DS = at or above the requested:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_443._tcp.ser= ver-fqdn.example

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain and the requisite signatures up t= o the root.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * If server's zone is DNSSEC-signed, but no= TLSA records are present, serve
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NSEC records proving non-existence (or N= ODATA) of the requested

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _443._tcp.server-fq= dn.example IN TLSA ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 records and the requisite signatures up = to the root.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * If the server's zone is DNSSEC-signed, an= d TLSA records are present, serve
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the requested TLSA records along with th= e requisite signatures up to the root.

All three of these would be obtained and cached (up to most of the advertis= ed TTL) in
the same way from a suitable resolver that supports chain queries, it is up= to that
resolver to return the appropriate response each of the above cases, the se= rver can
treat the data as opaque, modulo determining the time for which it may cach= e the
response so that the chain need not be re-fetched for each client connectio= n.

If one is worried about hijack by someone who can cause the domain to be si= gned
with TLSA records published (so as to set a non-zero pin), then one might b= e
motivated to have server software that is capable of returning the extensio= n.
Just as with STS one might need software that supports TLS if the hijacker<= br> deployed STS.=C2=A0 I don't think that such hijacking is a major risk, = but if that
risks drives adoption of the extension (without any other changes in tbe domain's practices wrt. DNSSEC or DANE adoption) all the better. :-) The domain might need the extension some day for more than just hijack reco= very,
and it will already be available.

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

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

--0000000000000b31b905691aa7ac-- From nobody Thu Apr 5 07:36:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667F3126BF7 for ; Thu, 5 Apr 2018 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_PHISH=3.557] 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 xNnODBLZzK-I for ; Thu, 5 Apr 2018 07:36:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C508912D7F9 for ; Thu, 5 Apr 2018 07:36:35 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B8B857A330D for ; Thu, 5 Apr 2018 14:36:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 5 Apr 2018 10:36:33 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <256E9B57-2D8A-4B49-B293-42664F8367F3@dukhovni.org> References: <20180405022007.GG25259@localhost> <2931578B-8500-403C-9CAF-89FBADCB0B30@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 14:36:37 -0000 > On Apr 5, 2018, at 10:20 AM, Eric Rescorla wrote: >=20 >=20 > Yes, so quite possibly I need to upgrade my entire server farm, which = might be running > on some software which has no version which implements this extension. = This could > be an enormous effort. Yes, module hijack. The same applied with STS, if the server farm had = no TLS support, or insufficient capacity to handle the load with TLS. This is not = substantially different, other than that TLS support is fairly mainstream now. Note that the hijack would also need obtain WebPKI certificates (as I = would expect DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)). = So the that would be a full takeover of the domain, and the affected clients = would have to have visited the hijacked site during the time it was controlled by = the malicious party. Note also that clients that support the extension will also be rare for = some time, so the impact of any hijack that improbably pins the extension will be = modest. So, if some users running early adopter browsers that support the = extension have to manually clear the pin after a domain hijack, and visiting the = hijacked site, potentially disclosing sensitive information to the wrong party, etc. = then becoming aware of that when the browser warns them about missing extension = support seems like a feature and not a bug. They can and probably should contact the = legitimate site's help desk and figure out what to do to secure their account, change = passwords, ... This scenario is not impossible, but a rather low risk, and would = initially, as server support ramps up, affect few users. The pin can be cleared by = the user in such a situation, and having the user be aware of the fact that = he/she visited a hijacked site is not a bad thing. --=20 Viktor. From nobody Thu Apr 5 08:07:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36512DA15 for ; Thu, 5 Apr 2018 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7zI-vZPazZq for ; Thu, 5 Apr 2018 08:07:37 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E95812DA08 for ; Thu, 5 Apr 2018 08:07:37 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 659523C012B27; Thu, 5 Apr 2018 08:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Ol8waI7HylugG2 Lz0aXKZS0BKls=; b=SILA/q4AdoeOrIW6+3uBmVSgFD3e7vXCWieeoZ3GwFi6Re 5kdt8wqlzOHwiyUhdyEHsWYFT4FaNRr8s6tAHU1Rs/4QzCudBYqxZu5KAC49YcUx xViAHjMxC20Lw1R2MscuzVz52VgAu/KeAQAUIzixYeAKGPZUqjzaHCqXYDhVk= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 0E2183C012B1A; Thu, 5 Apr 2018 08:07:35 -0700 (PDT) Date: Thu, 5 Apr 2018 09:47:41 -0500 From: Nico Williams To: Eric Rescorla Cc: Paul Wouters , "" Message-ID: <20180405144740.GO25259@localhost> References: <20180405022007.GG25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 15:07:38 -0000 On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote: > On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote: > > On Wed, 4 Apr 2018, Eric Rescorla wrote: > >> HPKP had a TTL and yet as a practical matter, people found it very > >> problematic. > >> And, of course, if you're concerned with hijacking attacks, the > >> hijacker will just advertise a very long TTL. > > > > By publising DANE records with either a TLSA record or a denial of > > existence proof, you can override any longterm TTL. > > > > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension > > containing a valid NSEC proof of non-existence overrides the > > previous TTL/PIN.' > > Thanks. This is a good point that I agree does not apply to HPKP. > > However, that doesn't mean that hijacking isn't a problem (though I > agree a less serious one). If I have no provisions for DNSSEC at all > and the attacker does pin hijacking I could be offline for hours to > days while I figure out how to get and serve them. I've been calling this pin-to-DANE because it's short, but, really, it's pin-to-using-this-extension. You can use this extension even if your domain is not signed because the proof that it isn't signed would be delivered in this extension. I believe the only way pinning to this extension can cause the hijacking you propose is if the root zone stops being signed as then there would be no way to prove that you're no longer using DANE :) Nico -- From nobody Thu Apr 5 08:15:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28A129C70 for ; Thu, 5 Apr 2018 08:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8nWQmp8tSU6 for ; Thu, 5 Apr 2018 08:15:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC6312DA06 for ; Thu, 5 Apr 2018 08:15:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 647C93C012B31; Thu, 5 Apr 2018 08:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6iqXby5oQi8EFT wR9ZRYvLqD2bc=; b=KDzvyjIxFRbYXJmRKBBwIA8U/d4SBfh562OYp/bgYhiVKW IlD/fEEZvMdwN5eJs/co3Ev6MHvlfUURpx1RojhN5m/CFvln4Q981cYoANovoNcy 4jZmKwXiQMf8pPtzV92H7z4MwSf8S4sTPk7Sv52jn0WpX8uJC2A4tUuRrCCL8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 103673C012B27; Thu, 5 Apr 2018 08:15:36 -0700 (PDT) Date: Thu, 5 Apr 2018 09:54:55 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180405145454.GP25259@localhost> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> <20180405030945.GN25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 15:15:40 -0000 On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote: > > Either way it's the same impact: you cannot roll that key over. > > > > Whereas with pin-to-DANE there's no such problem. I thought I made that > > clear. > > Yes, I agree that you're relying on a different guarantee from your > parent zone, I just don't think it's particularly obvious that that > guarantee is easier to ensure, for the reasons I indicated previously. Sure it is. As long as the root zone is signed you can use this extension and prove that you are / are not using DANE. > > > And, of course, if you're concerned with hijacking attacks, the > > > > > hijacker will just advertise a very long TTL. > > > > > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > > > right timing or else be detected -- that's very risky for them, and a > > > > deterrent to even trying. It's not fool-proof, but it's not nothing > > > > either. > > > > > > Given that the motivation for this kind of hijacking was generally > > > expected to be vandalism or ransom, this doesn't seem very comforting. > > > > The motivation for opportunistically using this is to be able to > > incrementally deploy DANE for HTTPS (and browsers). Without that it > > won't get deployed at all for HTTPS. > > I don't see how this is responsive to the concern that this technique will > be used for hijacking. You're right. I believe this has been answered now separately by others, and also by me. This is not a pin-to-DANE feature we're asking for, but a pin-to-using-this-extension. I shouldn't have called it pin-to-DANE, but I did because it's short -- short, but not sufficiently pithy :( Now, it's true that an impersonator could force you to use this extension when you were not ready to, and that's a DoS, though an easy one to fix, relatively. I'll take that DoS over a downgrade attack. We could mitigate the DoS by saying that the pin TTL must be coerced to zero (or maybe 1) if the extension only bore an authenticated denial of existence. I would prefer to not have to do this, but I'd accept it. Nico -- From nobody Thu Apr 5 08:51:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD9F12D87D for ; Thu, 5 Apr 2018 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6AbXNo_VDeHt for ; Thu, 5 Apr 2018 08:51:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8141E12D88D for ; Thu, 5 Apr 2018 08:51:38 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2D3BB7A330D for ; Thu, 5 Apr 2018 15:51:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <20180405145454.GP25259@localhost> Date: Thu, 5 Apr 2018 11:51:17 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <04E74714-BAE2-4142-A03F-DD33B3B30782@dukhovni.org> References: <20180405022007.GG25259@localhost> <20180405023456.GK25259@localhost> <20180405030945.GN25259@localhost> <20180405145454.GP25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 15:51:40 -0000 > On Apr 5, 2018, at 10:54 AM, Nico Williams wrote: > > We could mitigate the DoS by saying that the pin TTL must be coerced to > zero (or maybe 1) if the extension only bore an authenticated denial of > existence. I would prefer to not have to do this, but I'd accept it. When we get past this consensus call, and get to craft the actual text describing the pin TTL, I would expect a non-zero PIN to only be possible when proving TLSA records. A denial of existence should not be able to set a new pin TTL, and should clear any previous pin TTL. If DANE is not actually deployed, there's little reason to pin the extension, and clearing the pin via denial of existence is a useful mechanism. A client might then lose access to continued denial of existence until it again sees actual TLSA records with a non-zero pin, but that seems OK to me. -- Viktor. From nobody Thu Apr 5 19:25:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9912D94B for ; Thu, 5 Apr 2018 19:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 tKO4cYVIgBKk for ; Thu, 5 Apr 2018 19:25:52 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0AA12E87C for ; Thu, 5 Apr 2018 19:25:50 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 4H4Gfss8soWpd4H4YfoXLA; Fri, 06 Apr 2018 02:25:50 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id 4H4VfRi688pS64H4WfTxD5; Fri, 06 Apr 2018 02:25:49 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w362PkjF026617; Thu, 5 Apr 2018 22:25:46 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w362PjQH026612; Thu, 5 Apr 2018 22:25:45 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Eric Rescorla Cc: pgut001@cs.auckland.ac.nz, kathleen.moriarty.ietf@gmail.com, frantz@pwpconsult.com, steven.fenter58@gmail.com, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org In-Reply-To: (ekr@rtfm.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Apr 2018 22:25:45 -0400 Message-ID: <877epl136e.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNkOzsOtIn1IziHA4X3nmRCTTTbBBXDZ7xakuaOYKekiuwXdDIWslQ3FXMvw/k665IQKBPobP9AiFiEwvKB5I0A5wbejLVzBexDOpiiDng/ZqAHY/nHr STmaUirBZ1wdpHwgKZy8PKuV6ZcIng10XscKrJFpZ07fPwnjKlCiM/X0by18HPe+9o5rJwtnnP6FNAoY78L/AOoPPl47BMdDC+CePonHySt8ewfiP0LCGpbQ FGnsuliET8HgnYEdQ1PH+z3ULu0i+wgN1udBrM1dsIUmeqF8+tlv8zerVFS0SosI5W3R2kEXol1Fk7vl9PTZGtz+6oMOhOcbl2fIIdzPeBq6hReV93sE06dY up47xuh1GzlAwXxNbHZnoUnRpJ6qGRrJmfKEc0HWVMnj0ftNjvS7AMu8Th0pb4VHVf6uA7JWCWom2FpiDlm83ON3KbY3dA== Archived-At: Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 02:25:53 -0000 Eric Rescorla writes: > I guess there might be some intermediate category 1.5 that's kind of in > production so you don't want to print out complete logs, but you'd like > more detail than you would probably want to expose in general, but my > experience is that that's not super-common. My expectation is that the useful case is when there *aren't* any logs, or what logging is done does not tell the specific reasons that particular interactions were rejected. That's pretty common in SIP systems. Of course, anything like this would be an extension. But would it be reasonable for one endpoint to present a "debug password" in its request which, if it matched the debug password set in the other endpoint, would cause the other endpoint to provide fuller error information? That would allow a "debug window" that could be exploited only between endpoints that had some sort of administrative coordination. Dale From nobody Thu Apr 5 19:33:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0AA1201F2 for ; Thu, 5 Apr 2018 19:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 wkAruG3cVf50 for ; Thu, 5 Apr 2018 19:33:08 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D14112946D for ; Thu, 5 Apr 2018 19:33:07 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id 4HBafUrnTrSBO4HBaff4yB; Fri, 06 Apr 2018 02:33:06 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with SMTP id 4HBYf8mO7fa8F4HBYfXeRD; Fri, 06 Apr 2018 02:33:05 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w362X3EO026994; Thu, 5 Apr 2018 22:33:03 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w362X3g5026991; Thu, 5 Apr 2018 22:33:03 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Bill Frantz Cc: pgut001@cs.auckland.ac.nz, steven.fenter58@gmail.com, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org In-Reply-To: (frantz@pwpconsult.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Apr 2018 22:33:02 -0400 Message-ID: <871sft12u9.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfM2Mi9ywbjZLJda4eyFMnRtLFV9gfic9x//UBxZLWtjJ4oqgx2AxmSB1w14oS31RNF+BJ8aFFlb+afycc1cOrfoct7gjadzLB/Gzv6SsLvtCENf0hMfL ZTC2xJeyj6YtPUCKSocczD32Yq19dvF31TJT8GL+9euBwDylSIpyTEC5Vczk5jQY1Ok0uH4klh14kXqJX9KExsHwHfITvCX2urn/yjQNA6b0fG0TZwIUewiv Dgyha3C4YYymwAV47Caf7/bcO1xYFWGj2A48iHxmR/74RPsjhx9tAVTGiJQf+MUtNZen9mb4NC3UEGFwu04D239jTXyuzahwXutbUYR7Nvg70q25sNNwUGGM N0KTJKK7 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 02:33:09 -0000 Bill Frantz writes: > We have always avoided the long form error messages in TLS > because they can be of great help to attackers as well as > debuggers. I think this objection is much weaker if we write the > long form error messages into a log that is kept with other > server logs. I'd not considered textual messages. What struck me is that the draft has dozens, maybe more than 100, conditions that must be satisfied, and only a few different error codes. It strikes me that each particular rule could be assigned an error number, so an implementation could point out which of the dozens of rules was violated in a particular handshake. Dale From nobody Thu Apr 5 20:20:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136A12E87D for ; Thu, 5 Apr 2018 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SkXToWZmrkgM for ; Thu, 5 Apr 2018 20:19:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1D412E87C for ; Thu, 5 Apr 2018 20:19:58 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D77417A330D for ; Fri, 6 Apr 2018 03:19:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> Date: Thu, 5 Apr 2018 23:19:55 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 03:20:00 -0000 > On Apr 1, 2018, at 10:37 AM, Salz, Rich wrote: >=20 >> Possibly, if you consider being able to say "Invalid length = encoding in > preferred-ECC-curves extension" in Tswana is mission-critical to = debugging a > TLS handshake failure. >=20 > I so love your messages, Peter. Honestly I do. >=20 > Perhaps not Tswana, but perhaps China may care to pick a = counter-example. For debugging messages, I'm with Peter, they'll only be implemented if = they're simple enough to support. I can't see having to have localization files = on the server for debug messages that might be requested by a client is some = other locale and only when debug is enabled, and the consumer is a developer and not = an end-user. --=20 Viktor. From nobody Fri Apr 6 05:10:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919FE126C25 for ; Fri, 6 Apr 2018 05:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxtr81kIzNCu for ; Fri, 6 Apr 2018 05:10:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51B91201FA for ; Fri, 6 Apr 2018 05:10:37 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w36C970Q031167 for ; Fri, 6 Apr 2018 13:10:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=VUluNkQeub3z3l8wriSWNClHnNCGbElSOZt4nwhvEuw=; b=ZbQlvppjqUUT0ySXrsonU7VSPjHZU70upxzYUeHTifKOnHg8H4l3463bGkQgASER9/8W fyzJ5haJn/mD5044oWf/Yo/A4dsXCCAM+zIY2QadYoMxCn0AQL1v8gic1scstLgMrh/D 8J3Ha/dZQGSQYvwCo6hVV0k6J8uLWj+mmkIqx3ouGeEgP2gzHwQlzrIlLRILVknF2wEU qnNKtcLuS4gBhcvaZYxCdRIdus7K99fvfl5zHJaMcJh0P8xInqVFMMtsM5T/yxV6oSea cBy6kDd3ACeQ2D+9OmEepeBgUx20afjxwb6dPt2DxR1BpwfRl9Tl/Q6NaYkyUySwWTsd Iw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv5sd7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 06 Apr 2018 13:10:37 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w36C5rmI010555 for ; Fri, 6 Apr 2018 08:10:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nvep9j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 06 Apr 2018 08:10:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 6 Apr 2018 08:10:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Fri, 6 Apr 2018 08:10:35 -0400 From: "Salz, Rich" To: TLS WG Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTx7wtXVSppbP1QU+ckO7A4mMz76PoUyqAgAEzRACAAAciAIAATT6AgAAFYoCAAHj/gIABS4aAgABZ1QCAB2FQgIAAUTUA Date: Fri, 6 Apr 2018 12:10:35 +0000 Message-ID: <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> In-Reply-To: <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.173] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-06_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=877 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804060128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804060128 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 12:10:39 -0000 PiAgICBGb3IgZGVidWdnaW5nIG1lc3NhZ2VzLCBJJ20gd2l0aCBQZXRlciwgdGhleSdsbCBvbmx5 IGJlIGltcGxlbWVudGVkIGlmIHRoZXkncmUNCiAgICBzaW1wbGUgZW5vdWdoIHRvIHN1cHBvcnQu ICBJIGNhbid0IHNlZSBoYXZpbmcgdG8gaGF2ZSBsb2NhbGl6YXRpb24gZmlsZXMgb24gdGhlDQog ICAgc2VydmVyIGZvciBkZWJ1ZyBtZXNzYWdlcyB0aGF0IG1pZ2h0IGJlIHJlcXVlc3RlZCBieSBh IGNsaWVudCBpcyBzb21lIG90aGVyIGxvY2FsZQ0KICAgIGFuZCBvbmx5IHdoZW4gZGVidWcgaXMg ZW5hYmxlZCwgYW5kIHRoZSBjb25zdW1lciBpcyBhIGRldmVsb3BlciBhbmQgbm90IGFuIGVuZC11 c2VyLg0KICAgDQpUaGUgdGFibGUgc3Rha2VzIGhhdmUgaW5jcmVhc2VkLCBhbmQgSSBkb24ndCB0 aGluayBpdCBpcyByZWFzb25hYmxlIGFueSBtb3JlIGZvciBhbnkgSUVURiBwcm90b2NvbCB0byBo YXZlICJqdXN0IHVzZSBBU0NJSSIgZm9yIHRleHQgbWVzc2FnZXMuICBJdCBjb3VsZCBiZSBVVEY4 LCBvciBpdCBjb3VsZCBiZSBjb2Rlc2V0L3RhZ2dlZC4gIFdoeSB0d28gZGV2ZWxvcGVycyBpbiwg c2F5LCBSdXNzaWEgbmVlZCB0byBzcGVhayBFbmdsaXNoIHRvIGRlYnVnIHRoZWlyIFRMUyBpbXBs ZW1lbnRhdGlvbnMuDQoNCg== From nobody Fri Apr 6 07:39:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3921270AC for ; Fri, 6 Apr 2018 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=v7igYC6d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FQmqxe7H Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTS23WMw2RNh for ; Fri, 6 Apr 2018 07:39:50 -0700 (PDT) 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 D9C53120726 for ; Fri, 6 Apr 2018 07:39:49 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4257520CAF for ; Fri, 6 Apr 2018 10:39:49 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute7.internal (MEProxy); Fri, 06 Apr 2018 10:39:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=1Mqnu9kxl+ZWhErvcvE4w0ecN+WXV 1W7fWRn3+6NISc=; b=v7igYC6dpi98Zpxtsl0jcGsWk7hZ3EmLXseIamGFsBPQq I7ChTo8tDJFo+3ESRQCVdtmfxjybxgYpocYZuggU+MyDjJYGbCdYKegTl1ZfYCa4 bjdEoMrGSiiJNOd99SRuZAfz2PX5vwmbWwX96yeERcY30Nh+16PTtoE1qa90sbaz 2V2MFkZdg6bTiYjzti0ylNBBZICGMMGYXlhopYY2HuwxeEEtS/bYLmrDz9DlObsE FZ/61j9e/kqjDIC8lhAfeRmPJSm4Rb9CBVLT4VyP3N68dDVo2LwXP7zMHgROZDBN eQS9ZCU7avVszwbNbxWo9aYoScU9vvAxpK6MwGD7g== 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1Mqnu9 kxl+ZWhErvcvE4w0ecN+WXV1W7fWRn3+6NISc=; b=FQmqxe7H3BBIjPp2+I8nYD Clz6Zo4wz0AZyM8MpCDmiCGdRZVfRbUNwF3whiSi/APi2kTQd7AA1uKb+Zw4T98s SH++7dcBTXJpczmzBYUFAfRXwmnu0fDrkS+t+C4yY6eYmOJA+Y23gRU1QfwYvvAl HMzBogDoDYKsPmhNvuHgIJmRoylPHHjkY26kgQmixpVpY6PeXDPMDM3zo/nzum2U raHkjDs0kkDqn3jHL0d2uk0iQEm2WFzm3SSPxNcj7dxLtz+ZJzMELzjpQ9OnBMhc B2oN75HzgsSM+bo6ElIB/pHfUfrBfnrusdsFx3pqnaWZn1A7ELvuiMHvZsp9DcpA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 20C7BBA43D; Fri, 6 Apr 2018 10:39:49 -0400 (EDT) Message-Id: <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> From: Stan Kalisch To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152302558926515302" X-Mailer: MessagingEngine.com Webmail Interface - ajax-61ab7380 References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> Date: Fri, 06 Apr 2018 10:39:49 -0400 In-Reply-To: <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 14:39:51 -0000 This is a multi-part message in MIME format. --_----------=_152302558926515302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote: > The table stakes have increased, Exactly. > and I don't think it is reasonable any more for any IETF protocol to > have "just use ASCII" for text messages. It could be UTF8, or it > could be codeset/tagged. Why two developers in, say, Russia need to > speak English to debug their TLS implementations. Viktor rightly points out that in this situation the developer is the consumer. As the Internet exponentially expands=E2=80=94often in ways we'r= e not always able to posit ahead of time=E2=80=94the base of developers exponenti= ally expands. The IETF shouldn't be sanguine about the possibility that at some point the number of those developers who do not speak English will reach a critical mass that is able to start eschewing protocols that it finds too mired in US-ASCII. I would ask anybody who would say it could never happen how sure they are of that assertion. Thanks, Stan --_----------=_152302558926515302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi,

On Fri, Apr 6, 2018, at 8:10 AM, Salz, Ri= ch wrote:
The table stakes have increased,

Exactly.

and I don't thi= nk it is reasonable any more for any IETF protocol to have "just use ASCII"= for text messages.  It could be UTF8, or it could be codeset/tagged.&= nbsp; Why two developers in, say, Russia need to speak English to debug the= ir TLS implementations.

Viktor rightly points out that in this si= tuation the developer is the consumer.  As the Internet exponentially = expands=E2=80=94often in ways we're not always able to posit ahead of time= =E2=80=94the base of developers exponentially expands.  The IETF shoul= dn't be sanguine about the possibility that at some point the number of tho= se developers who do not speak English will reach a critical mass that is a= ble to start eschewing protocols that it finds too mired in US-ASCII.

I would ask anybody who would say it coul= d never happen how sure they are of that assertion.


Thanks,
Stan

--_----------=_152302558926515302-- From nobody Fri Apr 6 10:16:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBD112025C for ; Fri, 6 Apr 2018 10:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9dx77KSi2WPN for ; Fri, 6 Apr 2018 10:16:33 -0700 (PDT) Received: from 8.mo2.mail-out.ovh.net (8.mo2.mail-out.ovh.net [188.165.52.147]) (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 D44C41200C5 for ; Fri, 6 Apr 2018 10:16:32 -0700 (PDT) Received: from player692.ha.ovh.net (unknown [10.109.122.73]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id BE80C12A8B4 for ; Fri, 6 Apr 2018 19:16:30 +0200 (CEST) Received: from [192.168.0.16] (rng31-1-88-168-248-146.fbx.proxad.net [88.168.248.146]) (Authenticated sender: contact@simonbernard.eu) by player692.ha.ovh.net (Postfix) with ESMTPSA id 0448460009D for ; Fri, 6 Apr 2018 19:16:29 +0200 (CEST) From: Simon Bernard To: "tls@ietf.org" Message-ID: Date: Fri, 6 Apr 2018 19:16:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 12352810830315141361 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrgeekgdduudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [TLS] [DTLS]: how to handle unknown identity and bad psk ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:16:35 -0000 Hi, We are implementing DTLS with PSK over UDP and I would like to know how "unknown identity" and "bad psk" should be handled Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says : (https://tools.ietf.org/html/rfc4279#section-2) >   If the server does not recognize the PSK identity, it MAY respond >   with an "unknown_psk_identity" alert message. Alternatively, if the >   server wishes to hide the fact that the PSK identity was not known, >   it MAY continue the protocol as if the PSK identity existed but the >   key was incorrect: that is, respond with a "decrypt_error" alert. In TLS the safer way seems to send a "decrypt_error" alert for both. But in DTLS : https://tools.ietf.org/html/rfc6347#section-4.1.2.7 >   In general, invalid records >   SHOULD be silently discarded, thus preserving the association; >   however, an error MAY be logged for diagnostic purposes. >   Implementations which choose to generate an alert instead, MUST >   generate fatal level alerts to avoid attacks where the attacker >   repeatedly probes the implementation to see how it responds to >   various types of error.  Note that if DTLS is run over UDP, then any >   implementation which does this will be extremely susceptible to >   denial-of-service (DoS) attacks because UDP forgery is so easy. >   Thus, this practice is NOT RECOMMENDED for such transports. Is this record layer recommendation for all type of record ? even HANDSHAKE(22) record (and so FINISHED message) or is it mainly for APPLICATION_DATA(23) record ? Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we just ignore bad credentials silently ? -- Simon From nobody Fri Apr 6 10:27:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C912025C for ; Fri, 6 Apr 2018 10:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiziuJZjNtEu for ; Fri, 6 Apr 2018 10:27:15 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33321200C5 for ; Fri, 6 Apr 2018 10:27:15 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 188-v6so1736855oih.8 for ; Fri, 06 Apr 2018 10:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9BOXTA4dcE043YPFpoBAmgHksHZzSmDmD0YOfx6jnQM=; b=Ir9XP8wRl/AywRa/cFyjhCHWGln0UnkmtKWRx1MrNIxNi5pLxSTIcCVs7P1cEkNVIM J5iKpL4nxg0FMHcmIolFENLzQN9w79CSCXcdlpAHCVAgKNVA5fN4Y5TjUhdZphmIgbcv BVYdc/yZLmQ8nS7NtBkggdsdAQWGCrUaGcQnhnnAnpJpdN2YvJHnjUlGqCGm98MJGCTs 4dZMkerIHw2aGLwYxutRd19U/2LvRC1+KQNhaRoaR8TIKQDBxkKiExC/LpBuOyBKC4st msaNE/by+rIZkv3SbcmGmsQR96AmkqOD9suodFxPwVa71qs1aZs9P++CIHvY/EGctYd5 hXDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9BOXTA4dcE043YPFpoBAmgHksHZzSmDmD0YOfx6jnQM=; b=Iop7JjNtJpBiBVc7EDftLAgZ7LKoNkC/REdGF3Tj9jOTYv4YvMHF9/bKrmJAJwYVs/ HxCtLn5xEByWptEPD8eXnTpn6xd+jMhi/0XwGMX6fglvWGX+TYU7jZH2HnDbBahkkkPw iGweez4+9s90GQh+JyKLRAEqJpTw/359rsd3+JDFPgMRLeSmcJCrAfKFSlt0QeJFP59n d8+ODdptztIS5X2Jjsy0/Cs7mWnJkheE5ZB/pTWpRj8vTiWDFmsbKyOLqNwEO5SxTnnd ZLKh5CuU/vQIZ9aPN+bqJRBkHFy1DuOSfVpqHf/rRkyIY8HdMaI8waxesLycrOGrL+7d Fljw== X-Gm-Message-State: ALQs6tCD+vBmi+0dtuf54iZZFIkqmSZPfW77JMFrnv3SKPLwFvDHnYdJ j0XstIlsAN7cLzhkRiqy4O6/3JBwMHx21NGGygCTkgnP X-Google-Smtp-Source: AIpwx49yZTq4SiiDAsVXDjh8/AIhdA5EnpwR69wK/xusCv/XYdmhJaNjpjDaUnnCafskrP84897FzguWVSwfpBAHfOc= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr15090002oib.138.1523035635022; Fri, 06 Apr 2018 10:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 6 Apr 2018 10:26:34 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 6 Apr 2018 10:26:34 -0700 Message-ID: To: Simon Bernard Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000001bd8e0569315e7a" Archived-At: Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:27:18 -0000 --00000000000001bd8e0569315e7a Content-Type: text/plain; charset="UTF-8" On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard wrote: > Hi, > > We are implementing DTLS with PSK over UDP and I would like to know how > "unknown identity" and "bad psk" should be handled > > Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says : > (https://tools.ietf.org/html/rfc4279#section-2) > > > If the server does not recognize the PSK identity, it MAY respond > > with an "unknown_psk_identity" alert message. Alternatively, if the > > server wishes to hide the fact that the PSK identity was not known, > > it MAY continue the protocol as if the PSK identity existed but the > > key was incorrect: that is, respond with a "decrypt_error" alert. > > In TLS the safer way seems to send a "decrypt_error" alert for both. > > But in DTLS : > https://tools.ietf.org/html/rfc6347#section-4.1.2.7 > > > In general, invalid records > > SHOULD be silently discarded, thus preserving the association; > > however, an error MAY be logged for diagnostic purposes. > > Implementations which choose to generate an alert instead, MUST > > generate fatal level alerts to avoid attacks where the attacker > > repeatedly probes the implementation to see how it responds to > > various types of error. Note that if DTLS is run over UDP, then any > > implementation which does this will be extremely susceptible to > > denial-of-service (DoS) attacks because UDP forgery is so easy. > > Thus, this practice is NOT RECOMMENDED for such transports. > > Is this record layer recommendation for all type of record ? even > HANDSHAKE(22) record (and so FINISHED message) or is it mainly for > APPLICATION_DATA(23) record ? > > Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we > just ignore bad credentials silently ? > Hi Simon, The advice in 4279 is basically "make an unknown identity look like a bad key". So the idea would be to just randomize the key and then get the TLS or DTLS-type behavior. I.e., with TLS you would send decrypt_error and in DTLS the handshake would just stall because you would drop packets. -Ekr -- > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000001bd8e0569315e7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <contact@simonber= nard.eu> wrote:
Hi,

We are implementing DTLS with PSK over UDP and I would like to know how &qu= ot;unknown identity" and "bad psk" should be handled

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2= )

>=C2=A0=C2=A0 If the server does not recognize the PSK identity, it MAY = respond
>=C2=A0=C2=A0 with an "unknown_psk_identity" alert message. Al= ternatively, if the
>=C2=A0=C2=A0 server wishes to hide the fact that the PSK identity was n= ot known,
>=C2=A0=C2=A0 it MAY continue the protocol as if the PSK identity existe= d but the
>=C2=A0=C2=A0 key was incorrect: that is, respond with a "decrypt_e= rror" alert.

In TLS the safer way seems to send a "decrypt_error" alert for bo= th.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-= 4.1.2.7

>=C2=A0=C2=A0 In general, invalid records
>=C2=A0=C2=A0 SHOULD be silently discarded, thus preserving the associat= ion;
>=C2=A0=C2=A0 however, an error MAY be logged for diagnostic purposes. >=C2=A0=C2=A0 Implementations which choose to generate an alert instead,= MUST
>=C2=A0=C2=A0 generate fatal level alerts to avoid attacks where the att= acker
>=C2=A0=C2=A0 repeatedly probes the implementation to see how it respond= s to
>=C2=A0=C2=A0 various types of error.=C2=A0 Note that if DTLS is run ove= r UDP, then any
>=C2=A0=C2=A0 implementation which does this will be extremely susceptib= le to
>=C2=A0=C2=A0 denial-of-service (DoS) attacks because UDP forgery is so = easy.
>=C2=A0=C2=A0 Thus, this practice is NOT RECOMMENDED for such transports= .

Is this record layer recommendation for all type of record ? even HANDSHAKE= (22) record (and so FINISHED message) or is it mainly for APPLICATION_DATA(= 23) record ?

Is it acceptable to send fatal alert "decrypt_error" in DTLS or s= hould we just ignore bad credentials silently ?

Hi=C2=A0 Simon,

The advice in 4279 is bas= ically "make an unknown identity look like a bad key". So the ide= a would be to just randomize the key and then get the TLS or DTLS-type beha= vior. I.e., with TLS you would send decrypt_error and in DTLS the handshake= would just stall because you would drop packets.

= -Ekr

--
Simon

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

--00000000000001bd8e0569315e7a-- From nobody Fri Apr 6 12:26:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250B126BF6 for ; Fri, 6 Apr 2018 12:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egOMOnbSMQYJ for ; Fri, 6 Apr 2018 12:26:27 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97552124D68 for ; Fri, 6 Apr 2018 12:26:27 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D4878A00C541; Fri, 6 Apr 2018 12:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=A8WPjD7Oj6scpQ6qUKxf8iU8Isk =; b=wcVjySKkoDTsHVKDsNiYgvzn5MiRFyauahAkH0w/IlUAGYR/G+kh4ZR4aM2 QLXyh7FQX3wLsKzm9u3RjtE1eGutReVdyUYHHHek0oXvn6v5DRqx0qWsUrNQ+0LQ MQeMcsvjycftFBAh3p6dZ3BJ3vWNskY5kZG+5fIMFSCzOGNs= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8D3ECA00C540; Fri, 6 Apr 2018 12:26:26 -0700 (PDT) Date: Fri, 6 Apr 2018 14:21:02 -0500 From: Nico Williams To: TLS WG Message-ID: <20180406192101.GQ25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [TLS] DPRIV has the downgrade too (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 19:26:29 -0000 On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote: > So I rather suspect that even the DPRIV use-case, which supposedly does not need > the proposed changes, actually does need them for meaningful security from using > DANE, and we've not just not looked at the details closely enough yet. It may > well turn out not substantially different from the browser use-case that is not > adequately met by the current draft. > > Can someone explain briefly how DPRIV avoids the same downgrade issues, and > negative adoption incentives (cost-benfit comparison)? If it turns out that > no adequate explanation is possible, and indeed the same issues are present, > then the proposed changes (which are still needed elsewhere) are all the > more pressing. Oh, right, DPRIV isn't a work-in-progress. It's already here. Thus it cannot be an application that makes draft-ietf-tls-dnssec-chain-extension mandatory. Therefore it's subject to the downgrade attack we want to address with (C). I think now the WG should really want this LC to succeed and get this change made. Nico -- From nobody Fri Apr 6 12:54:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A0127137 for ; Fri, 6 Apr 2018 12:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 eCUgZEPUrvf9 for ; Fri, 6 Apr 2018 12:54:41 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6BC126D85 for ; Fri, 6 Apr 2018 12:54:40 -0700 (PDT) From: Ion Larranaga Azcue To: Stan Kalisch , "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTtcVLUPhTERem+EGBXUIdhpIlGKPn+86AgAAneICAATNEAIAAByMAgABNPYCAAAVigIAAvEKAgAEIQ4CAAJzjAIAHHkKAgACURICAACmygIAAYlRR Date: Fri, 6 Apr 2018 19:54:36 +0000 Message-ID: <1523044476527.20197@s21sec.com> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com>, <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> In-Reply-To: <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: multipart/alternative; boundary="_000_152304447652720197s21seccom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 19:54:44 -0000 --_000_152304447652720197s21seccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My opinion is that if we are going to have extended error codes, it's bette= r to use numeric ones and not text based errors. Imagine a chinese client t= rying to troubleshoot a connection to a server using a TLS stack that repor= ts its errors in russian. That would be crazy! I'm not saying that forcing English is better. There are many people out th= ere who have problems with english as well, and I'm sure that they would ra= ther look a numeric code in a table with localized error messages than havi= ng to use google translate. That being said... If in the end a decission is made to have text based error messages, I thin= k that the messages should be (at least) UTF-8. If a developer wants to gen= erate an error message including information from the certificate (I can't = imagine a valid scenario but... why not?), there are many places where UTF-= 8 is allowed. Additionally, a server name can also contain non-ASCII charac= ters and so on... ________________________________ De: TLS en nombre de Stan Kalisch Enviado: viernes, 6 de abril de 2018 16:39 Para: tls@ietf.org Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Hi, On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote: The table stakes have increased, Exactly. and I don't think it is reasonable any more for any IETF protocol to have "= just use ASCII" for text messages. It could be UTF8, or it could be codese= t/tagged. Why two developers in, say, Russia need to speak English to debu= g their TLS implementations. Viktor rightly points out that in this situation the developer is the consu= mer. As the Internet exponentially expands-often in ways we're not always = able to posit ahead of time-the base of developers exponentially expands. = The IETF shouldn't be sanguine about the possibility that at some point the= number of those developers who do not speak English will reach a critical = mass that is able to start eschewing protocols that it finds too mired in U= S-ASCII. I would ask anybody who would say it could never happen how sure they are o= f that assertion. Thanks, Stan --_000_152304447652720197s21seccom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote:

My opinion is that if we are going to have extended error codes, it's better to use numeric ones and not text based errors.


That was my own gut feeling on the least painful way to go, but I'm open to the possibility that gut feeling was woefully naive.


Stan
--_----------=_152305719138447230-- From nobody Fri Apr 6 16:40:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494F1126BF0 for ; Fri, 6 Apr 2018 16:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bjQMRI6wRfm for ; Fri, 6 Apr 2018 16:40:35 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C3D120454 for ; Fri, 6 Apr 2018 16:40:35 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id y46-v6so2942489otd.4 for ; Fri, 06 Apr 2018 16:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GgtZlmt59u+UWVfCIkPvg1og+wBKemDzgwwT1i5lpeE=; b=aUkwKveqnOvv347OrDsy1PWH9fBY9nX0ESAhDT5rtlkP8nv3KaesU1pNJK3r7tR49H vQGLOovWyYg7309a3l2BnvoUhzXEmD9Rkv/T5Zun0yuVZOJ4QXnXewqxH3l1bv+JDKSN aFRuBi7sODX7GTHevESfngrT/tNqgsYiJBRyF2MFG0sc23ssTx86MMvf9uSu8oEnAbvA JFvoHMsmzW/z5uz4IvEaJkjk+egngzygiOzvaxXg/WLpKUo1TtDiIqgsuNUxoVed8sRl pFQcaget1QaMmjdExZYHk/3ejU96KrNnT/NTUVL0m3gxTZJBnNOe0ypPQEYAshNjXJ27 VV+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GgtZlmt59u+UWVfCIkPvg1og+wBKemDzgwwT1i5lpeE=; b=hG7Cl/M/QnoHGmS3v4dhPlmhPVpwhT4Y6bISpBYnmnA7F652Vijw7KAxrs+AdrQ5jr fk7UPUaVbfARWgtusES4xNCokY18Iupa5w+kSJRh1DpmBTC5f/MPVaA+6K8AscnanP4x ZW9hxAK2KbyKY9R2vuYTcKiNCvORU0AfusQAJ6DMuxhmWoxyKSLYWJqb6q7iCSC/ao9c fPEIfy9MJ35x7w27c5An+JdGBn1ugfTQobll+Fa4mOLCGkhTMIxwGze4ypUq1UYb7sB7 3VEaozJZXeY3zZbsJeYqMdlPuHZnN9ggVaPpKup+xe1imEW2VyWabfbwZDPnXRJr4BQp wBfg== X-Gm-Message-State: ALQs6tDos7cJH8IV/ObwIcMrQej10Vd7bY2aHawq16kHbAMzAjWHXWvL F5O5L7pe9kifUVz0ijwfa0vm2m0lluQUZwq/iDdHEqyI X-Google-Smtp-Source: AIpwx4/Q9hiiG3ADw3tDUt3aPvP1S5huuoHvMN30eyaeSnqdG55nR/n3SmRjwCwIfbTArdWgjb0u86SWuwhiij0SMvc= X-Received: by 2002:a9d:4c16:: with SMTP id l22-v6mr3835535otf.176.1523058034580; Fri, 06 Apr 2018 16:40:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 6 Apr 2018 16:39:54 -0700 (PDT) In-Reply-To: <20180406231127.GN3322@mournblade.imrryr.org> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <20180406231127.GN3322@mournblade.imrryr.org> From: Eric Rescorla Date: Fri, 6 Apr 2018 16:39:54 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000001fac11056936957b" Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 23:40:37 -0000 --0000000000001fac11056936957b Content-Type: text/plain; charset="UTF-8" On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni wrote: > On Fri, Apr 06, 2018 at 12:10:35PM +0000, Salz, Rich wrote: > > > > For debugging messages, I'm with Peter, they'll only be implemented > if they're > > > simple enough to support. I can't see having to have localization > files on the > > > server for debug messages that might be requested by a client is > some other locale > > > and only when debug is enabled, and the consumer is a developer and > not an end-user. > > > > The table stakes have increased, and I don't think it is reasonable any > > more for any IETF protocol to have "just use ASCII" for text messages. > > It could be UTF8, or it could be codeset/tagged. Why two developers in, > > say, Russia need to speak English to debug their TLS implementations. > > Because the server has no idea what locale the client is in. > Localization is not an option. That would depend on how you designed the feature. Because the client would have to opt-in in any case, it could provide its locale in that opt-in message. I'm not saying that this (or even the feature at all) is necessarily a good idea, but it's not like it's impossible. -Ekr The only option (which is essentially > "use-ascii") is to use UTF-8, and then the error messages are in > whatever language the developer of the server used. So the Russian > developer will be seeing Chinese debug messages from the server. > That's not progress. > > If you want localization, the messages need to be numeric codes, > with localized string tables on each client. But then older clients > might not understand some new server messages (perhaps OK if the > message list is sufficiently stable given a client protocol version > and set of client supported extensions). > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001fac11056936957b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:
On Fri, Apr 06, 2018 at 12:10:35PM +0000, Salz, Rich wrote:

> >=C2=A0 =C2=A0 For debugging messages, I'm with Peter, they'= ;ll only be implemented if they're
> >=C2=A0 =C2=A0simple enough to support.=C2=A0 I can't see havin= g to have localization files on the
> >=C2=A0 =C2=A0server for debug messages that might be requested by = a client is some other locale
> >=C2=A0 =C2=A0and only when debug is enabled, and the consumer is a= developer and not an end-user.
>
> The table stakes have increased, and I don't think it is reasonabl= e any
> more for any IETF protocol to have "just use ASCII" for text= messages.
> It could be UTF8, or it could be codeset/tagged.=C2=A0 Why two develop= ers in,
> say, Russia need to speak English to debug their TLS implementations.<= br>
Because the server has no idea what locale the client is in.
Localization is not an option.=C2=A0

That = would depend on how you designed the feature. Because the client would have=
to opt-in in any case, it could provide its locale in that opt-i= n message.

I'm not saying that this (or even t= he feature at all) is necessarily a good idea, but
it's not l= ike it's impossible.

-Ekr

=

The only option (which is ess= entially
"use-ascii") is to use UTF-8, and then the error messages are in<= br> whatever language the developer of the server used.=C2=A0 So the Russian developer will be seeing Chinese debug messages from the server.
That's not progress.

If you want localization, the messages need to be numeric codes,
with localized string tables on each client.=C2=A0 But then older clients might not understand some new server messages (perhaps OK if the
message list is sufficiently stable given a client protocol version
and set of client supported extensions).

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

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

--0000000000001fac11056936957b-- From nobody Fri Apr 6 21:49:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDBA126B6D for ; Fri, 6 Apr 2018 21:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PZyTyQ9lZ_It for ; Fri, 6 Apr 2018 21:49:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C13124319 for ; Fri, 6 Apr 2018 21:49:35 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0C70A7A330D for ; Sat, 7 Apr 2018 04:49:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 7 Apr 2018 00:49:32 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <0F36675A-206C-4B17-8E74-6B18C5F0D1EF@dukhovni.org> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <20180406231127.GN3322@mournblade.imrryr.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:49:37 -0000 > On Apr 6, 2018, at 7:39 PM, Eric Rescorla wrote: >=20 > That would depend on how you designed the feature. Because the client = would have > to opt-in in any case, it could provide its locale in that opt-in = message. >=20 > I'm not saying that this (or even the feature at all) is necessarily a = good idea, but > it's not like it's impossible. Yes, it is not impossible, but it is much too brittle. There's little = reason (in general) to expect the server to have support for the client's locale, let alone = have locale-specific translation tables for TLS errors. Numeric codes are much better if the = error reasons are easily to classify in advance. Otherwise, numeric codes + UTF8 text in = English. This works with enhanced status codes in SMTP, which some MUAs (Outlook) = render in local languages based on the status code, but the remote postmaster will want = the original text, so that's often more useful for debugging when there's a problem (and = not just a wrong email address). --=20 Viktor. From nobody Sat Apr 7 07:25:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E101270AB for ; Sat, 7 Apr 2018 07:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jufqg7ePYomr for ; Sat, 7 Apr 2018 07:25:45 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C94124217 for ; Sat, 7 Apr 2018 07:25:45 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w37EN4FV000413 for ; Sat, 7 Apr 2018 15:25:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=v64zzwBW3SckZd6mZAE2QdiG1ob7dXA7erSmFgMVwaQ=; b=nZ/cZg6T1o1pB5ElUvMjHr+5rG44g5gqBiA3BPRdPbvd8o1rMgbd/2EQ1qxUurCGAeAg fJQEx7kDCiBc37vORpidJoVX6mDbXO2GTrYTe/vzMBQviHqd7w1kk9cCVXxIQyz2AtEE qL6+tCrKOMIgnDNkfTbNquoH1zhC0/3dZ+YB32wDewrF5hbBb+LSgVlhm7hMJyH9QAkL dctSpsRsnZWwRMRc8IYExhdoTWgClFzVPbYS5GcASCqC6ZTFaw4YZFbTN1cjb+PfOOEh 2+o2/AXp3GaFKJe9e8+Wx5BX14ef/ql7zKqnNixS8m2k6zFezeW6dCiMlwYJqtCXkisj Ow== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2h6utt8d5a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 07 Apr 2018 15:25:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w37EPhWK011407 for ; Sat, 7 Apr 2018 10:25:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h6sav8tmu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 07 Apr 2018 10:25:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 7 Apr 2018 10:25:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Sat, 7 Apr 2018 10:25:30 -0400 From: "Salz, Rich" To: TLS WG Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTx7wtXVSppbP1QU+ckO7A4mMz76PoUyqAgAEzRACAAAciAIAATT6AgAAFYoCAAHj/gIABS4aAgABZ1QCAB2FQgIAAUTUAgAD7tQCAAAfyAIAAVoMAgABdEoA= Date: Sat, 7 Apr 2018 14:25:29 +0000 Message-ID: <0CF376BD-27E0-44D8-AB07-AE9D5CD27DA2@akamai.com> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <20180406231127.GN3322@mournblade.imrryr.org> <0F36675A-206C-4B17-8E74-6B18C5F0D1EF@dukhovni.org> In-Reply-To: <0F36675A-206C-4B17-8E74-6B18C5F0D1EF@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.76] Content-Type: text/plain; charset="utf-8" Content-ID: <5155739EE0E10546817C13643448670F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-07_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=624 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804070159 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=541 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804070158 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 14:25:47 -0000 SnVzdCBtYWtlIHRoZSB0ZXh0IG1lc3NhZ2UgVVRGOC4gIElzIHRoYXQgc28gaGFyZCwgc28gZGlz dGFzdGVmdWw/ICBUaGlzIGdldHMgYSB2ZXJ5IGNvbW1vbiB1c2UtY2FzZSBhbmQgaXMgdXNlZnVs IGZvciBkZWJ1Z2dpbmcuDQoNCkkgdXNlZCB0byBzYXkgImp1c3QgdGVhY2ggJ2VtIGFsbCBFbmds aXNoLCIgYnV0IHRoYXQgd2FzIDI1IHllYXJzIGFnbyBhbmQgSSB3YXMgbm90IHNlcmlvdXMuDQoN Cg0KDQo= From nobody Sat Apr 7 17:38:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DDA126D45 for ; Sat, 7 Apr 2018 17:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 t3PIW3HTuGrE for ; Sat, 7 Apr 2018 17:38:02 -0700 (PDT) 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 3F62F124D68 for ; Sat, 7 Apr 2018 17:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1523147882; x=1554683882; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bSDGId/Pl5StcKWDZ0T605abMfDt/SiqwOK+rH2OPZM=; b=D0eJ/WM/Ex7Z08qEQIyzC6OxSqZbTEjs04yoQNcpNsAXefOEImB+DRio huVMUTxpDlsVOv7PTp5d+vgdw3YFlmfzVg9mVtaxfhJiEIh1Jgxzc0fU9 ma72N4lZTAHo3cz/gIbRrWVHb1e5Uq5fRELGcJjLrQZq4/hpwxxkMqWPz EgKhy79tFDARFRcTGqbHFUvaRTuvYCjhUIUm2k218ZVuVwAd9KJ8BKzJc vgNqlY8YoNb4P/IMN+tkN4wtI3ggmRsbAPJRU6HQwg7tAkOVnfCYzMwAi dA8jqzhtXWIAbGGKd98oEyiifU0o/v2ZLN51/sPvKrc5MFUr0CesH1qwU g==; X-IronPort-AV: E=Sophos;i="5.48,421,1517828400"; d="scan'208";a="6670279" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2018 12:37:57 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 8 Apr 2018 12:37:57 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sun, 8 Apr 2018 12:37:57 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTyXh+/Lp+FYBJG0WUfSNMD3DC66PzGXCC///K/YCAALimAIACcIhU Date: Sun, 8 Apr 2018 00:37:56 +0000 Message-ID: <1523147824699.14023@cs.auckland.ac.nz> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com>, <20180406231127.GN3322@mournblade.imrryr.org> In-Reply-To: <20180406231127.GN3322@mournblade.imrryr.org> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 00:38:05 -0000 I can't believe the amount of pointless bikeshedding that's already been do= ne=0A= over something that's going to be a rarely-if-ever used mechanism for one s= et=0A= of hardcore technical developers to communicate to another set of hardcore= =0A= technical developers. This isn't a design for a multilingual IM system wit= h=0A= emojis and animated GIFs, it's a rarely-used debugging/diagnostic facility,= =0A= and yet we're arguing over whether a developer who can read a lengthy=0A= technical document specified entirely in US-ASCII (TLS RFC) and implement i= t=0A= in C or Java (US-ASCII, English keywords) will be unable to communicate an= =0A= error message in anything but Cantonese (or Mandarin, or Qiang, or Kam=96Su= i, or=0A= Kipchak, or whatever was meant by "Chinese").=0A= =0A= Even for the few steps in the process where there's i18n available like the= =0A= gcc compile stage, the Chinese-speaking devs I know use the English version= =0A= because they don't want an attempted guess in another language at what the= =0A= error is, they want the actual error message from the compiler authors (man= y=0A= gcc error messages are barely comprehensible in English, let alone in an=0A= Uighur translation. Or maybe there are in Uighur, which is why I have trou= ble=0A= figuring out what they're saying).=0A= =0A= In any case it's a rarely-used, optional, by-special-request debugging=0A= facility for technical developers, make it UTF-8 and the devs can decide wh= at=0A= they put in there.=0A= =0A= Peter.=0A= From nobody Sat Apr 7 17:40:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53973126C83 for ; Sat, 7 Apr 2018 17:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 jh8N4Y3axn3P for ; Sat, 7 Apr 2018 17:40:34 -0700 (PDT) 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 69452124D68 for ; Sat, 7 Apr 2018 17:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1523148034; x=1554684034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DDNQLFOn6ERG7qK8bGKEfOorjupgHQomi8Kn9WVH7Jg=; b=Yee3glARSvkDHP2faJWwweSaTLzlBBLJyYECiGm7wFIO1xB1pYC7BU5Y +GigAfIavdaRVkMVKGugGiOKhWVt9PVJuBqqjo/955bF/KO9jE7lpiJTb uThFM1ChEWhzCIM4g5oIehvyG9Yg2t8cLhRMSDP83wURG9vu4oj7H8DZI TSCgITKy6Usz7SOrWWo+bMHCh1jpnSG8ujNV7VH3HchBjAyM9CBpUGZBZ urk+Ejqjnp/l9HS+aqOM2P9zN5vrNbuxBjs6T4kIOH9Kj8sqJb9xDJtQA GaUzLULARvTmjhYEe1ArOGy/IoxbNi7HSj1maOO4fQD26jj57swFV+zZo w==; X-IronPort-AV: E=Sophos;i="5.48,421,1517828400"; d="scan'208";a="6670438" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2018 12:40:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 8 Apr 2018 12:40:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sun, 8 Apr 2018 12:40:32 +1200 From: Peter Gutmann To: Ion Larranaga Azcue CC: "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTyXh+/Lp+FYBJG0WUfSNMD3DC66PzGXCC///K/YCAACmygIAAV/MAgAA7NYCAAnAVGw== Date: Sun, 8 Apr 2018 00:40:31 +0000 Message-ID: <1523147980074.75304@cs.auckland.ac.nz> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> <1523044476527.20197@s21sec.com>, <1523057191.3844723.1329421696.7A2BAE27@webmail.messagingengine.com> In-Reply-To: <1523057191.3844723.1329421696.7A2BAE27@webmail.messagingengine.com> 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] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 00:40:36 -0000 Stan Kalisch writes:=0A= =0A= >On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote:=0A= >>=0A= >> My opinion is that if we are going to have extended error codes, it's=0A= >> better to use numeric ones and not text based errors.=0A= >=0A= >That was my own gut feeling on the least painful way to go, but I'm open t= o=0A= >the possibility that gut feeling was woefully naive.=0A= =0A= To see why this won't work, you just need to think one step further: Try=0A= sitting down and defining the numeric error codes you're proposing.=0A= =0A= If it's still not obvious: The reason why we need free-form strings is beca= use=0A= the numeric codes we already have provide insufficient detail. To provide = the=0A= required detail, you'd need to define numeric codes for every error conditi= on=0A= and failed check that every TLS and PKI library (because lots of handshake= =0A= failures are due to problems with certs) could wish to communicate. To tak= e a=0A= PKI example, there's "Certificate chain with length %d has a path constrain= t=0A= of length %d", which for reasonable values of the two %d leads to, say, aro= und=0A= a hundred error codes just for that one condition. Then take every single= =0A= type of error that would need to be communicated and you're into at least 1= 6-=0A= bit values, or 32- or 64-bit if you take cases like "Packet length of %d=0A= indicated but only %d bytes were sent".=0A= =0A= Even if someone came up with the massive codebook of thousands or tens of= =0A= thousands of error codes, which TLS author would want to spend hours paging= =0A= through them to find the right code for each situation?=0A= =0A= Conversely, if you limit the number of error codes to, say, 5,000, how are = you=0A= going to convince TLS library authors to check for and report only those=0A= errors? What happens if new error types are defined?=0A= =0A= Peter.= From nobody Mon Apr 9 01:09:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CC81200C5 for ; Mon, 9 Apr 2018 01:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 I6_XPmLfQbl9 for ; Mon, 9 Apr 2018 01:09:39 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB8712D96D for ; Mon, 9 Apr 2018 01:09:37 -0700 (PDT) Received: from fe0vm1649.rbesz01.com (unknown [139.15.230.188]) by fe0vms0187.rbdmz01.com (Postfix) with ESMTPS id 40KNHy4ZN4z1XLH0c; Mon, 9 Apr 2018 10:09:34 +0200 (CEST) Received: from fe0vm7918.rbesz01.com (unknown [10.58.172.176]) by fe0vm1649.rbesz01.com (Postfix) with ESMTPS id 40KNHy44SQz2B; Mon, 9 Apr 2018 10:09:34 +0200 (CEST) X-AuditID: 0a3aad10-40fff70000000ee7-f1-5acb1fc37445 Received: from si0vm1949.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm7918.rbesz01.com (SMG Outbound) with SMTP id 29.9D.03815.3CF1BCA5; Mon, 9 Apr 2018 10:09:39 +0200 (CEST) Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by si0vm1949.rbesz01.com (Postfix) with ESMTPS id 40KNHy2MBlz6D44M5; Mon, 9 Apr 2018 10:09:34 +0200 (CEST) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Mon, 9 Apr 2018 10:09:34 +0200 Received: from SI-MBX2033.de.bosch.com ([fe80::d477:ebbc:f463:4ce4]) by SI-MBX2033.de.bosch.com ([fe80::d477:ebbc:f463:4ce4%4]) with mapi id 15.01.1415.002; Mon, 9 Apr 2018 10:09:34 +0200 From: "Kraus Achim (INST/ECS4)" To: Eric Rescorla , Simon Bernard CC: "tls@ietf.org" Thread-Topic: [TLS] [DTLS]: how to handle unknown identity and bad psk ? Thread-Index: AQHTzcsKyL0esUkqYEKDgQM2tceocKPz27QAgAQ3urA= Date: Mon, 9 Apr 2018 08:09:33 +0000 Message-ID: <375313f185e74fcea7de3df1687e98fc@bosch-si.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.82.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22TfUwbdRjH+fWu9Nr14Hpd24dO1J0my6obMN0szCwLJsq2+PrHEvuPK3Kj zWhLeoXBoob4UhgvkeEGrG6ISkk3h2xsIs4Cs8SEAqOJZllhrrEDlb4gc2rC4gve7WDtH/5z ed4+z/f5Pb/fERj9OaEnrHYX67SbK5hMBa4o6svdMvbQpCm/aXCLsf+GT2b0JaZlxjuhRrQb K+npuSsp+WDOjZXU+za9hJkUT5exFdZq1pm364DCEro9j1f+8FjNzEhQWoemDI1ITgD1JPy4 PJjZiBQETXVK4EzjBC46IwgujbwjE50kgujQVYnojCKI+epxgc+kiqCte0wm2OupPRD7OYIE G6M2wtJ3Xfdq1NRzEJ+JScWaErhyws03Ini7CE4PVAsmTj0Kf7z7glBBUjsh4e3HRKmjCAZ7 FzEhIadehunWyXtSiMqF8+dDmCilg9n5jyTicSjo8YtxoDQQm/tXKtoPw6DvJC5oYdRm6L+c tzbl8aaoTNRVQfDkPN6KdJ60rp4U4UkjPGlEN8LPIs1BNr/a9lRhgXGrs5TljuQXbH3dYRtA 4qVRQ8gTLA0gikCMkizOnjTRUnM1V2sLoO2EhNGQexMTJjqr1FFWazFzltecVRUsx+hJlJGR Qavvh7mqUpuV46wOewABgTHrSeZjniPLzLVHWKdDxAJoA4EzOrK57A0TTZWbXewhlq1knWvZ nQTBANnyID+DysmWszUHrRWutTSTK2pq0zPpshJCHkBPEEpeOyS0ILlKs42zlq/iOSJOr0VT 6AR6kUi6m5sx4pZf+M5/396M0bjdYWf1OtLAv2maEihLlf3+NPoHyB3ngiZak5ZIdYyjGcTv U01eEgZR8v9Jag4gh9SnXqVVq8EUtM3LM1RMC6MtDRL4rSMpgUDvdRw6h9+TQvSaOxOal65n wqcBnwyGwmdlsBAJySGSiMrhQldYAf0rDetgofOfdXBrsU8JC1PjSli+NkHCTNcSCaMftmXB lV9msyHo76QgOjxLwd2W0yqYaq2j4WLkKzX87l1UQzg5poG/V25qwHvOp4Po13EdNHj8AG1H O3LgxIXpnDi/ZAm/5DsHxoUlu8yu/1nyajR1On0d8hna/zoW2xQedVwu3LyvI7lr/5+s4Qvt m3mt2eVfLu2mwfvr/reXZcRxGuL59Rnadiv3LINudt8+tKf72I6BbT8NH74610SyriwoevwM +YjbX/wZ+9Y3NcXh6o292oLD48aVZy4ayKx9377/CTe3N3pK3rd9wwoWKUw8f+MVVVuMwTmL ucCAOTnzf050JvrBBAAA Archived-At: Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 08:09:43 -0000 SGksDQoNCj4gUkZDNjM0NywgNC4xLjIuNy4gSGFuZGxpbmcgSW52YWxpZCBSZWNvcmRzDQo+IOKA pg0KPiBJbiBnZW5lcmFsLCBpbnZhbGlkIHJlY29yZHMgU0hPVUxEIGJlIHNpbGVudGx5IGRpc2Nh cmRlZCwgdGh1cyBwcmVzZXJ2aW5nIHRoZSBhc3NvY2lhdGlvbjsNCg0KRHVyaW5nIGEgaGFuZHNo YWtlIG9ubHkgdGhlIG5ldyBhc3NvY2lhdGlvbiB3aWxsIGJlIGFmZmVjdGVkIGFuZCB0aGVyZWZv cmUgbm8gKGN1cnJlbnQpIGFzc29jaWF0aW9uIGNvdWxkIGJlIHByZXNlcnZlZCB3aXRoIHNpbGVu dGx5IGRpc2NhcmRpbmcgcmVjb3Jkcy4gU28gSSBjYW4ndCBzZWUsIHdoYXQgYmVuZWZpdCB3b3Vs ZCBiZSBhY2hpZXZlZCBhcHBseWluZyB0aGUgZ2VuZXJhbCBydWxlIHRvIHRoZSBoYW5kc2hha2Vz IGFsc28uDQoNCj4gUkZDNjM0NywgNC4yLiBUaGUgRFRMUyBIYW5kc2hha2UgUHJvdG9jb2wNCj4g RFRMUyB1c2VzIGFsbCBvZiB0aGUgc2FtZSBoYW5kc2hha2UgbWVzc2FnZXMgYW5kIGZsb3dzIGFz IFRMUywgd2l0aA0KPiB0aHJlZSBwcmluY2lwYWwgY2hhbmdlczoNCj4gLi4uDQo+IFdpdGggdGhl c2UgZXhjZXB0aW9ucywgdGhlIERUTFMgbWVzc2FnZSBmb3JtYXRzLCBmbG93cywgYW5kIGxvZ2lj IGFyZQ0KPiB0aGUgc2FtZSBhcyB0aG9zZSBvZiBUTFMgMS4yLg0KDQo+IFJGQzUyNDYsIDcuMi4y LiBFcnJvciBBbGVydHMNCj4gRXJyb3IgaGFuZGxpbmcgaW4gdGhlIFRMUyBIYW5kc2hha2UgcHJv dG9jb2wgaXMgdmVyeSBzaW1wbGUuIFdoZW4gYW4NCj4gZXJyb3IgaXMgZGV0ZWN0ZWQsIHRoZSBk ZXRlY3RpbmcgcGFydHkgc2VuZHMgYSBtZXNzYWdlIHRvIHRoZSBvdGhlcg0KPiBwYXJ0eS4NCg0K U28sIGlmIG5vIGFsZXJ0cyBzaG91bGQgYmUgdXNlZCBkdXJpbmcgdGhlIGhhbmRzaGFrZSwgSSB3 b3VsZCBwcmVmZXIgdG8gaGF2ZSB0aGF0IG1lbnRpb25lZCBhcyAiZm9ydGggcHJpbmNpcGFsIGNo YW5nZSIgaW4gNC4yLg0KDQpGTVBPViwgdGhlIG1haW4gYWR2aWNlIGZvciB0aGUgaGFuZHNoYWtl LWFsZXJ0cyBzaG91bGQgYmUsIHRoYXQgdGhleSBNVVNUIGJlIHVzZWQgd2l0aCBjYXJlLCBub3Qg dG8gcHJvdmlkZSBkZXRhaWxzLCB3aGljaCBtYXkgYmUgdXNlZCBmb3IgYW4gYXR0YWNrLCBhbmQg dGhhdCBoYW5kc2hha2UtYWxlcnRzIE1BWSBub3QgYmUgdXNlZCBhdCBhbGwuDQoNCk1pdCBmcmV1 bmRsaWNoZW4gR3LDvMOfZW4gLyBCZXN0IHJlZ2FyZHMgDQoNCkFjaGltIEtyYXVzDQoNCihJTlNU L0VDUzQpIA0KQm9zY2jCoFNvZnR3YXJlIElubm92YXRpb25zwqBHbWJIIHwgU3R1dHRnYXJ0ZXIg U3RyYcOfZSAxMzAgfCA3MTMzMiBXYWlibGluZ2VuIHwgR0VSTUFOWSB8IGh0dHA6Ly93d3cuYm9z Y2gtc2kuY29tIA0KDQoNClNpdHo6IEJlcmxpbiwgUmVnaXN0ZXJnZXJpY2h0OiBBbXRzZ2VyaWNo dCBDaGFybG90dGVuYnVyZzsgSFJCIDE0ODQxMSBCDQpBdWZzaWNodHNyYXRzdm9yc2l0emVuZGVy OiBEci4tSW5nLiBUaG9yc3RlbiBMw7xja2U7IEdlc2Now6RmdHNmw7xocnVuZzogRHIuIFN0ZWZh biBGZXJiZXIsIE1pY2hhZWwgSGFobg0KDQoNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBGcmVpdGFnLCA2 LiBBcHJpbCAyMDE4IDE5OjI3DQpUbzogU2ltb24gQmVybmFyZCA8Y29udGFjdEBzaW1vbmJlcm5h cmQuZXU+DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gW0RUTFNdOiBob3cg dG8gaGFuZGxlIHVua25vd24gaWRlbnRpdHkgYW5kIGJhZCBwc2sgPw0KDQoNCg0KT24gRnJpLCBB cHIgNiwgMjAxOCBhdCAxMDoxNiBBTSwgU2ltb24gQmVybmFyZCA8bWFpbHRvOmNvbnRhY3RAc2lt b25iZXJuYXJkLmV1PiB3cm90ZToNCkhpLA0KDQpXZSBhcmUgaW1wbGVtZW50aW5nIERUTFMgd2l0 aCBQU0sgb3ZlciBVRFAgYW5kIEkgd291bGQgbGlrZSB0byBrbm93IGhvdyAidW5rbm93biBpZGVu dGl0eSIgYW5kICJiYWQgcHNrIiBzaG91bGQgYmUgaGFuZGxlZA0KDQpQcmUtU2hhcmVkIEtleSBD aXBoZXJzdWl0ZXMgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBzYXlzIDoNCiho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI3OSNzZWN0aW9uLTIpDQoNCj7CoMKgIElm IHRoZSBzZXJ2ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZSBQU0sgaWRlbnRpdHksIGl0IE1BWSBy ZXNwb25kDQo+wqDCoCB3aXRoIGFuICJ1bmtub3duX3Bza19pZGVudGl0eSIgYWxlcnQgbWVzc2Fn ZS4gQWx0ZXJuYXRpdmVseSwgaWYgdGhlDQo+wqDCoCBzZXJ2ZXIgd2lzaGVzIHRvIGhpZGUgdGhl IGZhY3QgdGhhdCB0aGUgUFNLIGlkZW50aXR5IHdhcyBub3Qga25vd24sDQo+wqDCoCBpdCBNQVkg Y29udGludWUgdGhlIHByb3RvY29sIGFzIGlmIHRoZSBQU0sgaWRlbnRpdHkgZXhpc3RlZCBidXQg dGhlDQo+wqDCoCBrZXkgd2FzIGluY29ycmVjdDogdGhhdCBpcywgcmVzcG9uZCB3aXRoIGEgImRl Y3J5cHRfZXJyb3IiIGFsZXJ0Lg0KDQpJbiBUTFMgdGhlIHNhZmVyIHdheSBzZWVtcyB0byBzZW5k IGEgImRlY3J5cHRfZXJyb3IiIGFsZXJ0IGZvciBib3RoLg0KDQpCdXQgaW4gRFRMUyA6DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM0NyNzZWN0aW9uLTQuMS4yLjcNCg0KPsKgwqAg SW4gZ2VuZXJhbCwgaW52YWxpZCByZWNvcmRzDQo+wqDCoCBTSE9VTEQgYmUgc2lsZW50bHkgZGlz Y2FyZGVkLCB0aHVzIHByZXNlcnZpbmcgdGhlIGFzc29jaWF0aW9uOw0KPsKgwqAgaG93ZXZlciwg YW4gZXJyb3IgTUFZIGJlIGxvZ2dlZCBmb3IgZGlhZ25vc3RpYyBwdXJwb3Nlcy4NCj7CoMKgIElt cGxlbWVudGF0aW9ucyB3aGljaCBjaG9vc2UgdG8gZ2VuZXJhdGUgYW4gYWxlcnQgaW5zdGVhZCwg TVVTVA0KPsKgwqAgZ2VuZXJhdGUgZmF0YWwgbGV2ZWwgYWxlcnRzIHRvIGF2b2lkIGF0dGFja3Mg d2hlcmUgdGhlIGF0dGFja2VyDQo+wqDCoCByZXBlYXRlZGx5IHByb2JlcyB0aGUgaW1wbGVtZW50 YXRpb24gdG8gc2VlIGhvdyBpdCByZXNwb25kcyB0bw0KPsKgwqAgdmFyaW91cyB0eXBlcyBvZiBl cnJvci7CoCBOb3RlIHRoYXQgaWYgRFRMUyBpcyBydW4gb3ZlciBVRFAsIHRoZW4gYW55DQo+wqDC oCBpbXBsZW1lbnRhdGlvbiB3aGljaCBkb2VzIHRoaXMgd2lsbCBiZSBleHRyZW1lbHkgc3VzY2Vw dGlibGUgdG8NCj7CoMKgIGRlbmlhbC1vZi1zZXJ2aWNlIChEb1MpIGF0dGFja3MgYmVjYXVzZSBV RFAgZm9yZ2VyeSBpcyBzbyBlYXN5Lg0KPsKgwqAgVGh1cywgdGhpcyBwcmFjdGljZSBpcyBOT1Qg UkVDT01NRU5ERUQgZm9yIHN1Y2ggdHJhbnNwb3J0cy4uDQoNCklzIHRoaXMgcmVjb3JkIGxheWVy IHJlY29tbWVuZGF0aW9uIGZvciBhbGwgdHlwZSBvZiByZWNvcmQgPyBldmVuIEhBTkRTSEFLRSgy MikgcmVjb3JkIChhbmQgc28gRklOSVNIRUQgbWVzc2FnZSkgb3IgaXMgaXQgbWFpbmx5IGZvciBB UFBMSUNBVElPTl9EQVRBKDIzKSByZWNvcmQgPw0KDQpJcyBpdCBhY2NlcHRhYmxlIHRvIHNlbmQg ZmF0YWwgYWxlcnQgImRlY3J5cHRfZXJyb3IiIGluIERUTFMgb3Igc2hvdWxkIHdlIGp1c3QgaWdu b3JlIGJhZCBjcmVkZW50aWFscyBzaWxlbnRseSA/DQoNCkhpwqAgU2ltb24sDQoNClRoZSBhZHZp Y2UgaW4gNDI3OSBpcyBiYXNpY2FsbHkgIm1ha2UgYW4gdW5rbm93biBpZGVudGl0eSBsb29rIGxp a2UgYSBiYWQga2V5Ii4gU28gdGhlIGlkZWEgd291bGQgYmUgdG8ganVzdCByYW5kb21pemUgdGhl IGtleSBhbmQgdGhlbiBnZXQgdGhlIFRMUyBvciBEVExTLXR5cGUgYmVoYXZpb3IuIEkuZS4sIHdp dGggVExTIHlvdSB3b3VsZCBzZW5kIGRlY3J5cHRfZXJyb3IgYW5kIGluIERUTFMgdGhlIGhhbmRz aGFrZSB3b3VsZCBqdXN0IHN0YWxsIGJlY2F1c2UgeW91IHdvdWxkIGRyb3AgcGFja2V0cy4NCg0K LUVrcg0KDQotLQ0KU2ltb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNCm1haWx0bzpUTFNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== From nobody Mon Apr 9 02:28:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F903127698 for ; Mon, 9 Apr 2018 02:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 YKiTM-lBuBTa for ; Mon, 9 Apr 2018 02:28:24 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5364A126C26 for ; Mon, 9 Apr 2018 02:28:24 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann CC: "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTtcVLUPhTERem+EGBXUIdhpIlGKPn+86AgAAneICAATNEAIAAByMAgABNPYCAAAVigIAAvEKAgAEIQ4CAAJzjAIAHHkKAgACURICAACmygIAAYlRRgAAw1YCAAacBgIACKyew Date: Mon, 9 Apr 2018 09:28:21 +0000 Message-ID: <9112d613326d4fe8b397fdd61580ea59@LXDOMEXC01.ssidom.com> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> <1523044476527.20197@s21sec.com>, <1523057191.3844723.1329421696.7A2BAE27@webmail.messagingengine.com> <1523147980074.75304@cs.auckland.ac.nz> In-Reply-To: <1523147980074.75304@cs.auckland.ac.nz> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 09:28:27 -0000 I don't think it's necessary going to that degree of detail. For your speci= fic first example, alert the alert "bad_certificate" is enough, or at the m= ost a "certificate_chain_length_error". Your second example is, for me, mor= e real, because it can be an extended error for a "decode_error" alert. As = "decode_error" is too broad, we could have a "length_mismatch" extended err= or. But not give the specific values, because once the user knows that ther= e is an error with the length of a packet, it can revise length fields in t= hat specific packet in order to identify the error. An additional intermedi= ate option is allowing specific parameters for each extended error, for ins= tance in this example it could be the location within the packet of the off= ending field.=20 Summarizing, including a text error message is going from black to white wi= thout passing through the greys. The problem I see with it is that it's har= d for applications to automatically parse it, should it become necessary. I= would first start trying to define an extended error reporting protocol us= ing only numeric codes, and after the first few attempts, if we see that th= e list is not manageable, we could start exploring other options. My preferences are (in descending order of preference): - leave it as it is now, no extended error codes - numeric extended error codes - numeric extended error codes with specific sub-parameters for each extend= ed error code (e.g. location within the packet of offending length field in= a "length_mismatch" extended error code) - numeric extended error codes with an arbitrary list of opaque parameters = each, to be filled by developer (implementations can't rely on the content = but can show them, on screen, so if you want it can be a text message) - a single opaque extended error code. It can be numeric, UTF8 string or wh= at the developer wants, but in my opinion this should be the last resort. I= have never liked "let me put whatever I want" solutions -----Mensaje original----- De: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Enviado el: domingo, 8 de abril de 2018 2:41 Para: Ion Larranaga Azcue CC: tls@ietf.org Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Stan Kalisch writes: >On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote: >> >> My opinion is that if we are going to have extended error codes, it's=20 >> better to use numeric ones and not text based errors. > >That was my own gut feeling on the least painful way to go, but I'm=20 >open to the possibility that gut feeling was woefully naive. To see why this won't work, you just need to think one step further: Try si= tting down and defining the numeric error codes you're proposing. If it's still not obvious: The reason why we need free-form strings is beca= use the numeric codes we already have provide insufficient detail. To prov= ide the required detail, you'd need to define numeric codes for every error= condition and failed check that every TLS and PKI library (because lots of= handshake failures are due to problems with certs) could wish to communica= te. To take a PKI example, there's "Certificate chain with length %d has a= path constraint of length %d", which for reasonable values of the two %d l= eads to, say, around a hundred error codes just for that one condition. Th= en take every single type of error that would need to be communicated and y= ou're into at least 16- bit values, or 32- or 64-bit if you take cases like= "Packet length of %d indicated but only %d bytes were sent". Even if someone came up with the massive codebook of thousands or tens of t= housands of error codes, which TLS author would want to spend hours paging = through them to find the right code for each situation? Conversely, if you limit the number of error codes to, say, 5,000, how are = you going to convince TLS library authors to check for and report only thos= e errors? What happens if new error types are defined? Peter. From nobody Mon Apr 9 02:50:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA912783A for ; Mon, 9 Apr 2018 02:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 Sypi0dMi2gLV for ; Mon, 9 Apr 2018 02:50:18 -0700 (PDT) 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 E732B124207 for ; Mon, 9 Apr 2018 02:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1523267418; x=1554803418; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VKAuNMD8HjKZsejHsGvRBeKsA0smRt793AonLSit33I=; b=lbuD2lQWIaX+S6GGpv8X6UMrYPqeKzdP9D1JqySA8/Ot+1JcTjyaJYJG 0c3SLzJuBwIZlcY1IZrzIEkjEtyoityEnB5+ttZBKSMuIXxHoNAyVBo8L s5bDD2O0pwm+SzlKb0zY7yp9Y6RtJwI0UbFlzX2fZeJUAbV4WJChRkPKE Wju4g5lqx4Sc7iA3PxolOZjVPyi256q5JAYCw82WFBm1nIWDcFNpD04th cYUl6jgMiICoKbiVrvQMuLOcC1OFOdhV/lJO5hIfuhtwmcNqnxeU/Tzpu pGYf9sMLqiHdrrIKYk4IVi6r59rnq4nNJETu44jBu5VdeX/jjMu0YQum/ Q==; X-IronPort-AV: E=Sophos;i="5.48,426,1517828400"; d="scan'208";a="6827670" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Apr 2018 21:50:13 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 9 Apr 2018 21:50:13 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 9 Apr 2018 21:50:12 +1200 From: Peter Gutmann To: Ion Larranaga Azcue CC: "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTyXh+/Lp+FYBJG0WUfSNMD3DC66PzGXCC///K/YCAACmygIAAV/MAgAA7NYCAAnAVG4ABXLyAgADNrH8= Date: Mon, 9 Apr 2018 09:50:11 +0000 Message-ID: <1523267357971.79887@cs.auckland.ac.nz> References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> <1523044476527.20197@s21sec.com>, <1523057191.3844723.1329421696.7A2BAE27@webmail.messagingengine.com> <1523147980074.75304@cs.auckland.ac.nz>, <9112d613326d4fe8b397fdd61580ea59@LXDOMEXC01.ssidom.com> In-Reply-To: <9112d613326d4fe8b397fdd61580ea59@LXDOMEXC01.ssidom.com> 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] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 09:50:21 -0000 Ion Larranaga Azcue writes:=0A= =0A= >I don't think it's necessary going to that degree of detail. For your=0A= >specific first example, alert the alert "bad_certificate" is enough=0A= =0A= We already have error codes at about that level. They're not enough to deb= ug=0A= any problems (I mean, "bad certificate" is only marginally better than the= =0A= canonical Ken Thompson Unix error message in which a giant "?" lights up in= =0A= front of you, "the experienced TLS developer will usually know what's wrong= "),=0A= thus the need for free-form text messages that tell you what the actual=0A= problem is.=0A= =0A= >The problem I see with it is that it's hard for applications to automatica= lly=0A= >parse it,=0A= =0A= Applications don't need to parse it, it's an optional, opt-in=0A= debugging/diagnostic facility to help developers sort out why a handshake i= s=0A= failing, not something that an application is meant to process.=0A= =0A= >I would first start trying to define an extended error reporting protocol= =0A= >using only numeric codes=0A= =0A= Please, go ahead and do so. For that we'll probably need to start a new li= st=0A= to allow everyone to debate at length which error codes are needed and what= =0A= they should represent. tls-error-bikeshedding@ietf.org seems to be a good= =0A= candidate name.=0A= =0A= Either that or say it's a UTF-8 string with free-form text, and we'll assum= e=0A= developers can somehow manage to figure the rest out themselves, as they ha= ve=0A= for pretty much every other situation in which free-form text error message= s=0A= are used.=0A= =0A= Peter.=0A= From nobody Mon Apr 9 04:20:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9058127867 for ; Mon, 9 Apr 2018 04:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 5HEHpITbtUN9 for ; Mon, 9 Apr 2018 04:20:49 -0700 (PDT) Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE72126BF6 for ; Mon, 9 Apr 2018 04:20:49 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann CC: "tls@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Thread-Index: AQHTtcVLUPhTERem+EGBXUIdhpIlGKPn+86AgAAneICAATNEAIAAByMAgABNPYCAAAVigIAAvEKAgAEIQ4CAAJzjAIAHHkKAgACURICAACmygIAAYlRRgAAw1YCAAacBgIACKyewgAAAwYCAACX0gA== Date: Mon, 9 Apr 2018 11:20:46 +0000 Message-ID: References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <1523025589.2651530.1328912616.6FC37C86@webmail.messagingengine.com> <1523044476527.20197@s21sec.com>, <1523057191.3844723.1329421696.7A2BAE27@webmail.messagingengine.com> <1523147980074.75304@cs.auckland.ac.nz>, <9112d613326d4fe8b397fdd61580ea59@LXDOMEXC01.ssidom.com> <1523267357971.79887@cs.auckland.ac.nz> In-Reply-To: <1523267357971.79887@cs.auckland.ac.nz> Accept-Language: es-ES, pt-PT, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.250.16] x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 11:20:52 -0000 I think you don't really get my position in this issue... No, I'm not going= to start a list of numeric codes because I don't believe in this functiona= lity. Not even numeric extended alert codes have any appeal to me, it's jus= t the least offending idea. In my opinion, someone wants this functionality because he doesn't want to = ask the server administrators to analyze or even send the debug logs in the= peer side, which already have the information he needs. He is trying to su= bstitute a person-to-person interaction he doesn't want to perform for a co= mputer-to-computer interaction he sees as more convenient. Maybe without re= alizing he still needs to ask peer administrators to enable this debug func= tionality on a (most likely) production server. So, I'm totally against this whole idea but if everybody else supports it, = I'm going to try to do damage control and suggest limiting the amount of in= formation that can (will) be leaked. -----Mensaje original----- De: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Enviado el: lunes, 9 de abril de 2018 11:50 Para: Ion Larranaga Azcue CC: tls@ietf.org Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 Ion Larranaga Azcue writes: >I don't think it's necessary going to that degree of detail. For your=20 >specific first example, alert the alert "bad_certificate" is enough We already have error codes at about that level. They're not enough to deb= ug any problems (I mean, "bad certificate" is only marginally better than t= he canonical Ken Thompson Unix error message in which a giant "?" lights up= in front of you, "the experienced TLS developer will usually know what's w= rong"), thus the need for free-form text messages that tell you what the ac= tual problem is. >The problem I see with it is that it's hard for applications to=20 >automatically parse it, Applications don't need to parse it, it's an optional, opt-in debugging/dia= gnostic facility to help developers sort out why a handshake is failing, no= t something that an application is meant to process. >I would first start trying to define an extended error reporting=20 >protocol using only numeric codes Please, go ahead and do so. For that we'll probably need to start a new li= st to allow everyone to debate at length which error codes are needed and w= hat they should represent. tls-error-bikeshedding@ietf.org seems to be a g= ood candidate name. Either that or say it's a UTF-8 string with free-form text, and we'll assum= e developers can somehow manage to figure the rest out themselves, as they = have for pretty much every other situation in which free-form text error me= ssages are used. Peter. From nobody Mon Apr 9 11:33:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94E4129C51 for ; Mon, 9 Apr 2018 11:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3awR4CdGXYQH for ; Mon, 9 Apr 2018 11:33:26 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.204]) (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 C29F61273B1 for ; Mon, 9 Apr 2018 11:33:25 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-12.bemta-8.messagelabs.com id A2/50-20771-4F1BBCA5; Mon, 09 Apr 2018 18:33:24 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTcRTH97t3m9fH5DpnnkYSrSFlbcw0NCy ooHwVRRCWBHXN27bcpu1OWf2jYUWpha9JjtRRRvgoNC2zkkoJc0rD9WTYw9QoJUszTcPqbnf2 +O9zzvf7O+f8DofAxY+FUoI2m2ijgdLJhH58h/JSimKquTdVdfwsiv3scmKxk44CtBFLqK2dx RJmqrGdWKpAa0jLNB8QaKpvVWFZQ0nm2bZnKA+1bC1AfgSf/IxByd1HmDsQk+UYNJ504lzwBk HPlx9s4EsISRU87+jG3CwhN0LXC5vAzcFkEgyOn0JcPhmenrvsw3EO2OcKPMwn5TBl7/fUEZH 74O3Lx94GAwLomyrxmHzJTVDdXu5hRC6CGXujpxlOhoJruMbDQEpgsL9XyHEIfBz6KeD8+6Dq a6c3vwwq7zm9/jBw1hQidzMgWzH4PvYB5wQFfLFYvLwdbMVNAs7kRFBc9tqHEyKgo6OLFQiWM +BenYxLx0H+kycY56/FoaKl2etfAkXnS7yF3gjgWvO4Zy9iMh3K6xfGc+Bwsz+Q250UXj09g4 rRSus/P7Wy73GyBkH+/TFk9ewsCHoqh/mcKQIsV0e9vBTaPl3AOY6D83MPhBwvg/LCQR+O18L YwwlkQ0Q9WsHQxhzaqIhcp0wzatUak57S6hSRqlilnmYYSk3rqDRGeTBTfx2xt5XL46FbqOJO fCdaTGCyENHNot5UcWBaZvpRDcVo9huzdTTTiZYQhAxEAewNioOMtJo2H9Lq2ANdkIEIkElE4 W5ZxGRRekar5iQ7UhADraVFuJhvyDTQ0lBRiNtEuk2abMOfEgtn7kRh0mAR4vF44oAs2qjXmv 7XR1EogWTBohtNbJUArcH0p9MoOwTGDjF54JF7CBP1V5LmoTNH2m+n/lrle3tLYtLyd2UN33P W+L/qPubTuDumfT7lhtx1omFPW4F1Q0zCZMuuwxmro0Z4J+WuXMsAYw61P7NO7CjdG93ltyE6 vHC7Mnv/vF2RPuKIqgvmJ8vlm9Xxtm/vd0w3Xdl2+qLFz9VNpjBhlzdNr090XPJXJX5U941I3 sv4jIaKjMCNDPUb4wUO5OEDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1523298803!200479645!1 X-Originating-IP: [207.46.163.87] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14663 invoked from network); 9 Apr 2018 18:33:23 -0000 Received: from mail-bl2nam02lp0087.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) (207.46.163.87) by server-9.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 9 Apr 2018 18:33:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ilh1sDrAcR2ibQ8f+mq0XKIPPcEDJOyke1DDc6uJ8dc=; b=oTdfzym0zMYzd/8AZFk7TebCdh096HV7w+QrEKUwewTiMdLO9RlOuQ/+776k5a9orfqnRgXttijPsDZmv7GmCGY0xbcPAmeTqK4n4I8NJtlbfmEzP1p+KVhu0bdOtK58E8xwHF9mZmGcF/y3MmEUd6TEWbApE0L2S34OUWm6GWM= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1744.namprd14.prod.outlook.com (10.171.147.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Mon, 9 Apr 2018 18:33:22 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd%17]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 18:33:22 +0000 From: Tim Hollebeek To: Paul Wouters , "tls@ietf.org" Thread-Topic: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension Thread-Index: AQHTzD153lXhdbKumEK21sHaP8VrkqPxQIwAgAAszYCAAAIWgIAAAgQA////TICAAAWaHv///XmAgAAHIICAAAITgIAAZ0gAgAbgLWA= Date: Mon, 9 Apr 2018 18:33:22 +0000 Message-ID: References: <20180405022007.GG25259@localhost> <20180405023106.GJ25259@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [12.153.98.139] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1744; 7:RurQboqCsZURsWlanCDAzNl3Xr6g7eTp+H60dMvffSLRyWxpweaLSda4bFXXiHKXjvJp8p4dD/ESh8xLckSq+yZHvsgg3q8DbqBoB+Z+v+7j0163EEWd5JyZPsNCu75Cb/HFEfWWXRFsIEW6pZ9V4bIS9FEnmqWrgZMJMw58FXoPzidxyVpomrfChnBGPdNPJBKKpCTC1LTKoLWlmNU8oZI+1f/MEjD41rfdy1jIH+YYWaBNqgoN8ldhEcPPcO63 x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 694bf85d-8c95-492a-2a42-08d59e485fe1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1744; x-ms-traffictypediagnostic: MWHPR14MB1744: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(3002001)(6041310)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR14MB1744; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1744; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(346002)(366004)(39380400002)(199004)(189003)(5660300001)(229853002)(53936002)(3280700002)(81156014)(6246003)(2906002)(2900100001)(8936002)(76176011)(446003)(59450400001)(476003)(6506007)(5250100002)(7696005)(486006)(11346002)(81166006)(8676002)(68736007)(110136005)(2501003)(6436002)(55016002)(9686003)(86362001)(99286004)(66066001)(93886005)(106356001)(102836004)(186003)(316002)(26005)(33656002)(478600001)(99936001)(7736002)(74316002)(97736004)(25786009)(14454004)(105586002)(305945005)(3660700001)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1744; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CuhJWpXsfJNOvUfPJyybxLZAXGV5PYo2VULPsXLrIWPnUmRisX0RxBX51DNTlimc0lCH6HAJRyS11JBJV+iXxN5NMpgbWM9e3lRkSSsgszBOxI/XMVdnPddXtf/Dp4hZSyIPoHH/Lf+7+AjMNwgpWbLEWWvIkOPiAFcAtJK1XVSTT3Dnlj/ZkUuQTbcysS7AsauVMZ5UvZjFuWEoKeMIFtHWclFs/x+MJcv4VZh0geFehR0NyiZ+P8EcdzH5ANMSrTXFlqwe5WuKOOik29nC7c56r1ScOaeY6Q6Vz93hGaWU0MG/Iif8hegaaWu0Li/FtF4waZpfsy9V5hhU3ZUVVuPJWpcBMuznCQqIWruDpigjFv85VMxugncIHrnRnkfFbCrhmaBj43prvrPCLPxyST7H85eQhP+u1WC73gYf2jE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0A2E_01D3D00F.B31E7180" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 694bf85d-8c95-492a-2a42-08d59e485fe1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 18:33:22.4656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1744 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:33:28 -0000 ------=_NextPart_000_0A2E_01D3D00F.B31E7180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > The webpki is changing dramatically. The amount of CAB/forum violations > seems to be increasing, partially as a result of these violations getting > exposed > by certificate transparancy and perhaps partially because of the financial > strain > caused by the free LetsEncrypt. Uniformed speculations that are just flat out wrong do not help anyone. LetsEncrypt, if anything, has been a big help to the CA industry. Both free and paid offerings are seeing significant growth. Let's not spread FUD about "financial strain" that does not actually exist. And furthermore, it's best not suggest hypothetical unproved ("seems to be") observations are caused by the previously mentioned cause that doesn't actually exist. That's irresponsible. Tools like cablint have actually contributed far more to improvements in the technical compliance of certificates from vendors who previously didn't adhere that closely to strict compliance with RFCs, CABF requirements, required certificate profiles, and so on. CT is less responsible, as it is only required for EV (though many large CAs have voluntarily started logging all certificates). Many bad certificates were still found the old fashioned way: by crawling for them. There's an old story about an intelligence analyst who found a handful of suspicious structures in a remote desert. More resources were assigned to figure out what they were. A few months later, the number of structures was observed to be increasing rapidly. More resources were assigned. Pretty soon, new ones were found every day. People started panicking, and someone was dispatched to investigate on the ground. It turned out to be a kind of water condenser common in the region, and the increase in numbers was only because people had started looking for them. They had always been there, just no one paid attention to them. The truth is that the increase in activity around problems with various certificates is because people are just paying far more attention to even the smallest, most obscure details of every issued web PKI certificate these days: far, far more than they did even just two or three years ago. And that's a good thing, not a bad thing. Progress is being made. The certificates being issued by almost every CA out there are much technically cleaner than they were when I first started doing CA things, maybe five years ago. The Symantec swamp cleanup effort is also responsible for a significant fraction (the majority?) of recent reports. -Tim ------=_NextPart_000_0A2E_01D3D00F.B31E7180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNDA5MTgzMzE3WjAvBgkqhkiG9w0BCQQxIgQgFixuuD5HlAny16Vqc4i1pJyCQlPZ tJRBn57ThWGgpW8wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBADUo6sPXgYAyRL5ulMraWkViC+jfhNm2u6FkiUYiZJP9qhg/9Omzag9+HzaTQKXx6QfvF6AN WGC/Mbro/auJz6Z8trOkF6McEc7HdLIIt8rW5sTMlWsJiejlXeEoas/j3Z8785tvQ5uDgLvR4RMg +sBtv75auoUqjoufZZ8FvzTKVVJ0AMY5duMnAhchEO2yvZFlku+b8GEH8lO8aIjt4cz6HcHVWKJL tFrmlXsEoeSglUCMy6VITfBmlfn8FJHGY9Lxs5YixHsfWi8i1zHncxdAMuwBW8zrmgxJgV5/nHfX 3Le66uWRkM3S1Ku5lS4YVrDV9esuqDG/gjBmT6fOv7cAAAAAAAA= ------=_NextPart_000_0A2E_01D3D00F.B31E7180-- From nobody Mon Apr 9 14:16:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2D312D944 for ; Mon, 9 Apr 2018 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRHNFRnul9ww for ; Mon, 9 Apr 2018 14:16:47 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7860C12D7EF for ; Mon, 9 Apr 2018 14:16:47 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id e123-v6so9077667oih.13 for ; Mon, 09 Apr 2018 14:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FymfYiIIz5iawKv99N5fj2kYt+yJXuDbR4JdJMHZygE=; b=U99FkW+kFoqEjaCNsuWlt1ifjgQTriWaTI4umUnIAhjZ1KKK8JFgXXc6RKKC4vvuCj Xvt3O9ctpYE33RtCZaTV2TJL5tCPynLaqtm4KYMBeik6kDeG+JkTNqYfytId38a+PYHl wSFMmSY7MzKnCB/zXLXko6QT8dpFMlLYUqsUF+SEVyyIYPnU1ycrbruT0tBMk1pcdkr0 GnIolOaGADKlYnbZ1hxH5+KFNdfOgh+pTQz9WlYRdeOIOzsOFSy3z6tLC8leOvd+qTUl KSbvcCyXbeGZ38x538VFGHfN0/0y1qn6viOgpiD4jSm5pHpZI9dFh668Z6nQsllaA6va orqg== 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=FymfYiIIz5iawKv99N5fj2kYt+yJXuDbR4JdJMHZygE=; b=cuizNwQDUq2FsTy1+bKdQKy+zrv5OeQs3T1yvhZe67EwtY3mKj29BOvAbDJMNoINWT cd7wEFHpXs2xjSLDOq19UmLUPpMzEr6RiCm/E/AZmcr7NWYZpnmwJlLmiY2oZ1h70lQ3 UFYXgMPiXxb541FYbNuhINsqKTlsWHcmS0GZu8nRa8vwGpK+6gqG0hZo6qRC3B5mFDrd 061PKbikUWEPaha3w3xvyAv24UnFDMdMyXCn2a7TRLSKF+dZX2YjWzNV74KayD9qpiu2 iB5Vu1I+eOD8vChTaAx7/MHKp6FOpv/B4NGMU48zRlvlzb4p6aCBZosePj0pb3Rls19e ODrA== X-Gm-Message-State: ALQs6tA8rre0wHwjbHZMqFhdm4mAK82s4KJgdABEedaBQMba7hQiZSr9 aud6B5LhgDYbWmtH2vZh1mr3uvOiJeJuMOH8QqwPDsI/ X-Google-Smtp-Source: AIpwx48DNERg+FJqT/HcDA9bkvQkou9gKN5Ap9a3W62bOmVV0g0dwMkdGVEk282Cs67FZuSNTLsuqhOtVgvxD1YRsmA= X-Received: by 2002:aca:7258:: with SMTP id p85-v6mr359749oic.349.1523308606579; Mon, 09 Apr 2018 14:16:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.113.145 with HTTP; Mon, 9 Apr 2018 14:16:06 -0700 (PDT) From: Joseph Birr-Pixton Date: Mon, 9 Apr 2018 22:16:06 +0100 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] New version intolerance caused by draft-26 supported_versions change? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:16:49 -0000 Hello, PR#1163 in draft-26 seems to have broken interop with previous drafts with a variety of deployed implementations. draft-26 and later clients fail with a protocol_version alert. Affected Internet servers include: cloudflare.com: offers draft-23, intolerant to draft-26 www.apple.com: seemingly unwilling to negotiate any draft, but intolerant anyway(?) www.microsoft.com: same google.com: same https://jbp.io/assets/tls13-logs/cloudflare.broken.txt https://jbp.io/assets/tls13-logs/apple.broken.txt https://jbp.io/assets/tls13-logs/microsoft.broken.txt https://jbp.io/assets/tls13-logs/google.broken.txt In all these cases, offering TLS1.2 in supported_versions (ie, the pre-draft-26 behaviour) works, and TLS1.2 is negotiated: https://jbp.io/assets/tls13-logs/cloudflare.works.txt https://jbp.io/assets/tls13-logs/apple.works.txt https://jbp.io/assets/tls13-logs/microsoft.works.txt https://jbp.io/assets/tls13-logs/google.works.txt Corroboration appreciated. It's totally possible I'm doing something stupid :) Thanks, Joe From nobody Mon Apr 9 14:29:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D51512D7EF for ; Mon, 9 Apr 2018 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 mdIFmmAQ8vhr for ; Mon, 9 Apr 2018 14:29:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D5A126CBF for ; Mon, 9 Apr 2018 14:29:16 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w39LCdWt017644; Mon, 9 Apr 2018 22:29:14 +0100 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=N91VMi+y8Ml+Ey0s1cMAgLn7ujgQNsGgbP9wiz67qlk=; b=BovCbthYhwKlO1eetMgNwmwQwTdPZQfRqWFiKomeuPm/m25bo8mtnLuOpCDSTUMtVJfE JMdVIT3Gxd4SGcPiI8U82A4JibhuBY2YZE9KCYZ2rV/gu8C+bXPleIZekol9cm/F4AlF GmFWmyXynpUz6k1bEkqwZTLoq4y/ij4ePFvkS3l4EIJDPV5tkVIjka2FpSNJNRNF8fz0 uSkvhtUWHa9gqnTYRinLJrh17u8mBUyT+CfHInmybFBmFIG7ktB42yoATogVkwUhTN3K k5pFleRGYnOc0GRzIbnwTUa5vH5IE+IWDb9ICO6s+8qHUWDGsz9aj1Gn4Ehj1FcB4dPi 0g== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2h6s90x9h5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Apr 2018 22:29:13 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w39LBB5K023135; Mon, 9 Apr 2018 17:29:13 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h6savgp60-1; Mon, 09 Apr 2018 17:29:13 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id EC0F082B69; Mon, 9 Apr 2018 21:29:12 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f5eLg-0006k2-7d; Mon, 09 Apr 2018 16:29:12 -0500 Date: Mon, 9 Apr 2018 16:29:12 -0500 From: Benjamin Kaduk To: Joseph Birr-Pixton Cc: tls@ietf.org Message-ID: <20180409212912.GJ17433@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=2018-04-09_09:, , 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-1711220000 definitions=main-1804090213 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090213 Archived-At: Subject: Re: [TLS] New version intolerance caused by draft-26 supported_versions change? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:29:18 -0000 On Mon, Apr 09, 2018 at 10:16:06PM +0100, Joseph Birr-Pixton wrote: > Hello, > > PR#1163 in draft-26 seems to have broken interop with previous drafts > with a variety of deployed implementations. draft-26 and later clients > fail with a protocol_version alert. > > Affected Internet servers include: > > cloudflare.com: offers draft-23, intolerant to draft-26 > www.apple.com: seemingly unwilling to negotiate any draft, but > intolerant anyway(?) > www.microsoft.com: same > google.com: same > > https://jbp.io/assets/tls13-logs/cloudflare.broken.txt > https://jbp.io/assets/tls13-logs/apple.broken.txt > https://jbp.io/assets/tls13-logs/microsoft.broken.txt > https://jbp.io/assets/tls13-logs/google.broken.txt > > In all these cases, offering TLS1.2 in supported_versions (ie, the > pre-draft-26 behaviour) works, and TLS1.2 is negotiated: > > https://jbp.io/assets/tls13-logs/cloudflare.works.txt > https://jbp.io/assets/tls13-logs/apple.works.txt > https://jbp.io/assets/tls13-logs/microsoft.works.txt > https://jbp.io/assets/tls13-logs/google.works.txt > > Corroboration appreciated. It's totally possible I'm doing something stupid :) It is not expected for draft-NN to interoperate with draft-YY, but implementations thereof that also support TLS 1.2 should be able to negotiate TLS 1.2. So depending on what you mean by "intolerant", there may be nothing to see here. -Ben From nobody Mon Apr 9 14:29:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65012D7F5 for ; Mon, 9 Apr 2018 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 hpnx2q9WcEnv for ; Mon, 9 Apr 2018 14:29:49 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAE4126CBF for ; Mon, 9 Apr 2018 14:29:48 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w39LD0M1021184; Mon, 9 Apr 2018 22:29:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ZarVvyERY0ubioaDwyiohIUKtELJEtILviEmg/yFJDE=; b=T2S//J4qcDk4JKIxre6V4sO0MWAnHbR9aXLzIlk/7M6gwphKG2HKikvz0ux3rCUShk0C uLMNaYoQPIfM+tWb692OLN4GeyZWOJ/8DMUNhFrWE8aVWYUJ4IbTC1/FeuBmM/3mZd0S AVcrwicV3gnli7MPwocZz66RsM4PqUIdLx8YqDOj4DBP+lyMoUZ5yD2b12gCbjlVywIR rvHVcIxwfyMNuPVgZSBmgcgiwKrdLr7SZVxnhKBuJbaVL5C78xi7bY/HXM+LiuIofGFO yVeEoLTLI0ReAnBLNqd9geoKlbNwwhgLCxPJEqJ1GaEXvVw5gpEjwROvGrRg/d3ZnT7d Fw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2h6ty672uv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Apr 2018 22:29:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w39LB7Qs020165; Mon, 9 Apr 2018 17:29:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h6saugu04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Apr 2018 17:29:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 9 Apr 2018 17:29:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Mon, 9 Apr 2018 17:29:45 -0400 From: "Salz, Rich" To: Joseph Birr-Pixton , "tls@ietf.org" Thread-Topic: [TLS] New version intolerance caused by draft-26 supported_versions change? Thread-Index: AQHT0EgY94nJJ9ZntEGnd3AZVR3YAqP48zGA Date: Mon, 9 Apr 2018 21:29:44 +0000 Message-ID: <10B52B6C-B75A-4219-B0C4-5646FE5EEB03@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.135] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_09:, , 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=714 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090213 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=658 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090213 Archived-At: Subject: Re: [TLS] New version intolerance caused by draft-26 supported_versions change? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:29:50 -0000 WW91ciByZXN1bHRzIGFyZSBub3QgcmVhbGx5IHZlcnkgc3VycHJpc2luZy4NCg0KRGlmZmVyZW50 IGZvbGtzIGFyZSBhdCBkaWZmZXJlbnQgZHJhZnRzLCBhbmQgImV2ZXJ5b25lIiBpcyB3YWl0aW5n IGZvciB0aGUgZmluYWwgUkZDIHRvIGJlIHB1Ymxpc2hlZCBhbmQgdXBncmFkZSB0aGVuLg0KIA0K DQo= From nobody Mon Apr 9 14:30:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0612D7F5 for ; Mon, 9 Apr 2018 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 Nw6w6nDmOzHR for ; Mon, 9 Apr 2018 14:30:19 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 51D1E12D7F4 for ; Mon, 9 Apr 2018 14:30:19 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id d9-v6so8140309oth.10 for ; Mon, 09 Apr 2018 14:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8uty4YSAO7gSd+eI2HiOL354E1E12Lc07sKB8t9cJdc=; b=Mvu1wbdvJv3eS+DE8DiqWPeka0OqnJhBlreBK5RcUBbvHX68ejMrokQmBWMsONKDYQ SQGjmQOMBkxCZtsabrcGO0imeHUn9YUytxLP7RJIkAGq66MiaijxGxzQXXdUbcCLOEoV z2PL/5kWHQgHwT2wSwCmulKUdckUFcuuGgLwzMD70lo8y/o721oq0rb/roppUm0mj13/ hlvicjwPx7FfZJQ5QRAuiiZRyBqC3lvzKfRsnOP3+tR+QICxdtuACaVizlnxcW8AQdjI 0r8IEmYhJ2z9d5zeYvlBRW1p7FDRMWEKGOISy2rjOWuF5TOYPQ5YsQNKa2MNg29QRfDB gQwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8uty4YSAO7gSd+eI2HiOL354E1E12Lc07sKB8t9cJdc=; b=PLraK7WEYw/zZlqP9ps/2iommGIyHzPzJEoVmPN6I/S0o+5z8YWgKUsG4ZZGv9bpft pZMoKdprQOK39yvPQaoUP+w/cK1GWdjfPpjFNa9CZtvQ0OULvXXP2A/I1Tdf0MpCHH3I i2D0Wi1DGXbUhuKN2BomFcyvAdTkhY0tqOMRKrjGFxGcQDxRZP6csFS4xomDf6QUiZRk UCAgzwFviWnd++uvgWn4VN/RXne7nCB9NEd+9wHWmnsEsPOzh1aNsPtR7Hr2TkLCih/o R/otf6vOE3EOIoxBHxdAOvxTrgfF/y6DzAJ8chUFNf131/ACFSFwxDUSCHbljrreirXi Brag== X-Gm-Message-State: ALQs6tCMoAZ4T0WWuPa87JVnBKsIxGV8zuT7agoXA04LSXTYuyHFCU1F 8YHrI1q6L3IrfpIChDrg7A2FdtkeqNxV9bw0v+3FDJIGXVU= X-Google-Smtp-Source: AIpwx4+NaBvHR5vlSviqTGLTEpYH/4vrqGI2kNOzHQpuMjykWbKGtykmqOkUxS8NAniFkGhM4X58R2B44iVd4Zl2Zyk= X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr14935587ota.392.1523309418493; Mon, 09 Apr 2018 14:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Mon, 9 Apr 2018 14:29:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 9 Apr 2018 14:29:38 -0700 Message-ID: To: Joseph Birr-Pixton Cc: "" Content-Type: multipart/alternative; boundary="000000000000c5d0480569711ccc" Archived-At: Subject: Re: [TLS] New version intolerance caused by draft-26 supported_versions change? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:30:22 -0000 --000000000000c5d0480569711ccc Content-Type: text/plain; charset="UTF-8" On Mon, Apr 9, 2018 at 2:16 PM, Joseph Birr-Pixton wrote: > Hello, > > PR#1163 in draft-26 seems to have broken interop with previous drafts > with a variety of deployed implementations. draft-26 and later clients > fail with a protocol_version alert. > > Affected Internet servers include: > > cloudflare.com: offers draft-23, intolerant to draft-26 > www.apple.com: seemingly unwilling to negotiate any draft, but > intolerant anyway(?) > www.microsoft.com: same > google.com: same > > https://jbp.io/assets/tls13-logs/cloudflare.broken.txt > https://jbp.io/assets/tls13-logs/apple.broken.txt > https://jbp.io/assets/tls13-logs/microsoft.broken.txt > https://jbp.io/assets/tls13-logs/google.broken.txt > > In all these cases, offering TLS1.2 in supported_versions (ie, the > pre-draft-26 behaviour) works, and TLS1.2 is negotiated: > You're just sending supported_versions = {0x7f1a}, but that's not correct. You need to send {0x7f1a, 0x0303}: " The "supported_versions" extension is used by the client to indicate which versions of TLS it supports and by the server to indicate which version it is using. The extension contains a list of supported versions in preference order, with the most preferred version first. Implementations of this specification MUST send this extension in the ClientHello containing all versions of TLS which they are prepared to negotiate (for this specification, that means minimally 0x0304, but if previous versions of TLS are allowed to be negotiated, they MUST be present as well). " So what's happening here is the any server which knows about TLS 1.3 (supported_versions) is getting a version mismatch. PR#1163 was just about what the server sends. -Ekr > https://jbp.io/assets/tls13-logs/cloudflare.works.txt > https://jbp.io/assets/tls13-logs/apple.works.txt > https://jbp.io/assets/tls13-logs/microsoft.works.txt > https://jbp.io/assets/tls13-logs/google.works.txt > > Corroboration appreciated. It's totally possible I'm doing something > stupid :) > > Thanks, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c5d0480569711ccc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 9, 2018 at 2:16 PM, Joseph Birr-Pixton &l= t;jpixton@gmail.com<= /a>> wrote:
Hello,

PR#1163 in draft-26 seems to have broken interop with previous drafts
with a variety of deployed implementations. draft-26 and later clients
fail with a protocol_version alert.

Affected Internet servers include:

clou= dflare.com: offers draft-23, intolerant to draft-26
www.a= pple.com: seemingly unwilling to negotiate any draft, but
intolerant anyway(?)
w= ww.microsoft.com: same
google.c= om: same

https://jbp.io/assets/tls13-logs/cloudfla= re.broken.txt
https://jbp.io/assets/tls13-logs/apple.broken.= txt
https://jbp.io/assets/tls13-logs/microsoft= .broken.txt
https://jbp.io/assets/tls13-logs/google.broke= n.txt

In all these cases, offering TLS1.2 in supported_versions (ie, the
pre-draft-26 behaviour) works, and TLS1.2 is negotiated:

You're just sending supported_versions =3D {0x7f1a}, but t= hat's not
correct. You need to send {0x= 7f1a, 0x0303}:

"
   The "supported_versions=
" extension is used by the client to indicate
   which versions of TLS it supports and by the server to indicate which
   version it is using.  The extension contains a list of supported
   versions in preference order, with the most preferred version first.
   Implementations of this specification MUST send this extension in the
   ClientHello containing all versions of TLS which they are prepared to
   negotiate (for this specification, that means minimally 0x0304, but
   if previous versions of TLS are allowed to be negotiated, they MUST
   be present as well).
"

So what's happening here is the any serve= r which knows about TLS 1.3 (supported_versions)
is getting a version mismatch.

PR#1163 was just about what the server sends= .

-Ekr



https://jbp.io/assets/tls13-logs/cloudflar= e.works.txt
https://jbp.io/assets/tls13-logs/apple.works.tx= t
https://jbp.io/assets/tls13-logs/microsoft.= works.txt
https://jbp.io/assets/tls13-logs/google.works.= txt

Corroboration appreciated.=C2=A0 It's totally possible I'm doing so= mething stupid :)

Thanks,
Joe

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

--000000000000c5d0480569711ccc-- From nobody Mon Apr 9 14:36:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1584312D95F for ; Mon, 9 Apr 2018 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldfibT8QktGr for ; Mon, 9 Apr 2018 14:36:38 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 68F6212D95C for ; Mon, 9 Apr 2018 14:36:38 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id m7-v6so10396412otd.1 for ; Mon, 09 Apr 2018 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TZC9yCOVEq79no0KGeH/uq0Ll+I/EBfpnpThpsj3vm8=; b=EMnlAvFYThxrYr5BWSHPu8jwSuizjdzuDAV0/+ks0a0WfRiirJYXSq1YySjUbNSPSl MgMN7GgpH51FUnTBzn1caUSsz5XOw2AXdOKRak+w+e+4z1THuysOLE/G6z7b0DUps4W9 JsUMWR84EO08rS8aeWruWJAgSWMWPn3YGF8acXeCW+o3l2eo8E+jqtVzAwGTgRL94Nwf 26seKrTGkV8U6KCGWlnG0K6wRt1nUwVb0eRYGQAXonkypHyXGf9KjQ8WxTiTOY+U3H33 QGd3ut7heevWVLfm7+IZ96GG09mckTDZufkdH3iig3smRR78WdGB8b4ZizAPZUVFW5zp yQLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TZC9yCOVEq79no0KGeH/uq0Ll+I/EBfpnpThpsj3vm8=; b=M/fADnkvMmTFaffx0/+UCWuhllcJ8hrGefE9llUOfTR/k9UHSpu7uXFphWo64aadOw AKnTFKVd0GoyrUJNio8icJnjlJ5BIMZZ3s6cbU9AM6lKSdKmeAl6UTcwRwVr579b2cBa VYsH4XZiVH0JWImQHg6UFTfFh8zb+DccJnyr5iZEDdAntmT0b8FsffARgUspA/dCNzC+ mzDr4bMtLfsKdRKd8XxDMRRU9rLfVBk90ejd3Fo1i8zCuYfjPS+LjixbJmsNQhbGwf8H kXV2rMoa9B5zXZID/BBVUbyVZHyDkILt4zFUC7WHM1s4wc/B+1jymT8vm2R58hW3r9eo 7nCg== X-Gm-Message-State: AElRT7FP4Dhl/CKVjMl/7vstmJgvXTAJfhQh5Ye9YyEZN3ykjPT97RM0 juaLTkKTmWEHUdATAsSI51ZLbWkxoUZx3jLYQNo= X-Google-Smtp-Source: AIpwx49NMCelXoT9Ai1qM4ZDVopUHLoycSqkfFl5eteW7glr2QJufKiU3FDC+vTKY2qNfQDRsI6Hk+A0BKG/HUCqkKA= X-Received: by 2002:a9d:4469:: with SMTP id f38-v6mr22345686otj.335.1523309797683; Mon, 09 Apr 2018 14:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.113.145 with HTTP; Mon, 9 Apr 2018 14:35:57 -0700 (PDT) In-Reply-To: References: From: Joseph Birr-Pixton Date: Mon, 9 Apr 2018 22:35:57 +0100 Message-ID: To: Eric Rescorla Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] New version intolerance caused by draft-26 supported_versions change? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:36:40 -0000 On 9 April 2018 at 22:29, Eric Rescorla wrote: > PR#1163 was just about what the server sends. Aha. This is the bit I missed. I had interpreted "you can't negotiate pre-TLS 1.3 with supported_versions" applied to both ends. Thanks! Joe From nobody Mon Apr 9 16:34:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8DF12D86E for ; Mon, 9 Apr 2018 16:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=uDIvzXqc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JV1pBm+w Received: 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-JrT9WiU8Iq for ; Mon, 9 Apr 2018 16:34:21 -0700 (PDT) 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 D91061243F6 for ; Mon, 9 Apr 2018 16:34:20 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2D1882133A for ; Mon, 9 Apr 2018 19:34:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 09 Apr 2018 19:34:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=3S4B3TH4XplBlvkdO6i32z2zsDU6A qFjtEta/ZWhEW0=; b=uDIvzXqcPVspPxYIbIaWhxogddqH5SKpDcYFolA671Sbc SdaM0YY6+3a60m7gXqeDtVX03sfoLW7RDPC7ga4sEtUjlDyPCDo5KU6gR0JgImZU n8KZBY6OHm0NgbxlJsd7M9ns/jwNEUgC/QjkRzZobtkCq6Hj9/YUVy6Equli4zNT +ezcJBqBk7pJ+4JQ+RrQA+SX/PZZQnYI6K25rYpnzFcUjy7yqlYiAVHu67ytcJYJ Sj2risI0uRvurGxD2a65fG9I/szns4NwPv3Op8whBwJH/FC1zdEKk/54H0cApDLp DTVydvMH8/3JFRBMblrsDLCZHgwFs/q4N8dXZvjLQ== 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3S4B3T H4XplBlvkdO6i32z2zsDU6AqFjtEta/ZWhEW0=; b=JV1pBm+wzVvr0OMvaSsfwh SSynrC2tpdP7rPVXF3FIzLsZgnSFySHC1zjG11WBz/KA69iNjC2Ks8dEEVOe5jQ9 sx5FrhnIZZg7vkgGlWA0MF18XOShTLja9+fHA7051u9i+8jniHp98gdRF3QVcU2f WW6L/7XX03qOQmTeEYdlC9RjO4ai+462euhBMNUAFI0p47LUp46BG+10JCmivpMr IQv7oBBE2C7zrCt5hpFxJQL12PeQnxS6q1Iax/pl0aWTMgG9jpXaZ5zAZNGxAX+l 2Y/YCWFwoNfr01UkB1CB+YLp+gsDwxfQVXkQGbnY/KyxftD3p3rTKXT2mNygBkTQ == X-ME-Sender: References: <1522377304060.20682@cs.auckland.ac.nz> <1522462562850.29528@cs.auckland.ac.nz> <2C1F7A14-45B0-49DE-98B1-897223F7A1B0@akamai.com> <1522559738688.99197@cs.auckland.ac.nz> <7EBF2F91-6FEA-4705-BB1A-3FB5D7E33949@akamai.com> <2DA08233-1EC4-4371-943B-E41BF5D8DA8C@dukhovni.org> <109337BE-3299-46B5-A2F8-9583107AB537@akamai.com> <20180406231127.GN3322@mournblade.imrryr.org> <1523147824699.14023@cs.auckland.ac.nz> From: Stan Kalisch Content-Type: text/plain; charset=utf-8 In-Reply-To: <1523147824699.14023@cs.auckland.ac.nz> Message-Id: <21245667-16C0-4814-AE02-2580D94B8056@glyphein.mailforce.net> Date: Mon, 9 Apr 2018 19:34:17 -0400 To: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 23:34:23 -0000 > On Apr 7, 2018, at 8:37 PM, Peter Gutmann wrot= e: >=20 > I can't believe the amount of pointless bikeshedding that's already been d= one over something that's going to be a rarely-if-ever used mechanism for on= e set > of hardcore technical developers to communicate to another set of hardcore= technical developers. Not to be too Steve Jobs about it, but I was simply trying to have a little i= magination and question assumptions (including my own) about how the size of= the developer base could grow, and what that could mean. So if being thoug= htful to the point where one has the occasional slight digression is bikeshe= dding, that's fine with me. > This isn't a design for a multilingual IM system with emojis and animated G= IFs, Thank you for clearing that up. > it's a rarely-used debugging/diagnostic facility, > and yet we're arguing over whether a developer who can read a lengthy > technical document specified entirely in US-ASCII (TLS RFC) and implement i= t in C or Java (US-ASCII, English keywords) will be unable to communicate an= error message in anything but Cantonese (or Mandarin, or Qiang, or Kam=E2=80= =93Sui, or > Kipchak, or whatever was meant by "Chinese"). Actually, no, we're not arguing over that. > Even for the few steps in the process where there's i18n available like th= e gcc compile stage, the Chinese-speaking devs I know use the English versio= n because they don't want an attempted guess in another language at what the= > error is, And because they also know English. Thanks, Stan= From nobody Tue Apr 10 02:17:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1D1273E2 for ; Tue, 10 Apr 2018 02:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tf1eeU3EtbHy for ; Tue, 10 Apr 2018 02:17:40 -0700 (PDT) Received: from esa3.dyson.c3s2.iphmx.com (esa3.dyson.c3s2.iphmx.com [68.232.139.42]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B481712420B for ; Tue, 10 Apr 2018 02:17:39 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8858"; a="30850055" X-IronPort-AV: E=Sophos; i="5.48,431,1517875200"; d="scan'208,217"; a="30850055" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa3.dyson.c3s2.iphmx.com with ESMTP; 10 Apr 2018 10:28:46 +0100 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 6FE48FA10; Tue, 10 Apr 2018 07:37:01 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 583B2FA02; Tue, 10 Apr 2018 07:37:01 +0000 (GMT) Received: from UK-MAL-CAS-04.dyson.global.corp (10.1.108.112) by UK-MAL-CAS-02.dyson.global.corp (10.1.108.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 10 Apr 2018 10:17:18 +0100 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-04.dyson.global.corp ([10.1.108.112]) with mapi id 14.03.0319.002; Tue, 10 Apr 2018 10:17:16 +0100 From: Tony Putman To: Eric Rescorla CC: "" Thread-Topic: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 Thread-Index: AQHTtMcJWeEnis9wG0CY/StJz+XTI6PD/QqAgAKL6FCAAHbSgIAy56sQ Date: Tue, 10 Apr 2018 09:17:16 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC1DBF4FA2@UK-MAL-MBOX-01.dyson.global.corp> References: <140080C241BAA1419B58F093108F9EDC1678CD1A@UK-MAL-MBOX-02.dyson.global.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1DBF4FA2UKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 09:17:43 -0000 --_000_140080C241BAA1419B58F093108F9EDC1DBF4FA2UKMALMBOX01dyso_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMgb24gYW5kIG9mZi4NCg0KRnJvbTogVExTIFtt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpT ZW50OiAwOCBNYXJjaCAyMDE4IDIzOjI1DQpJIHRoaW5rIHRoYXQgdGhpcyBhbmQgZHJhZnQtcHV0 bWFuIGFyZSBub3QgY29tcGV0aW5nLCBidXQgcmF0aGVyIHRoYXQgdGhleSBzZXJ2ZSBkaWZmZXJl bnQgdXNlIGNhc2VzDQpBZ3JlZWQuIEl0IHNvdW5kcyBsaWtlIHlvdSBoYXZlIGEgc2V0IG9mIHVz ZSBjYXNlcyB3aGVyZSB5b3Uga25vdyBob3cgdG8gcHJlZGlzdHJpYnV0ZSB0aGUgc2VydmVyIGtl eT8gVGhpcyBpcyB0aGUgcGFydCB3ZSBmb3VuZCBjaGFsbGVuZ2luZyBpbiB0aGUgd2ViIGNvbnRl eHQuDQoNClllcywgdGhlIHVzZSBjYXNlIEkgd2FzIGFkZHJlc3Npbmcgd2FzIGlkZW50aWNhbCB0 byBleHRlcm5hbCBQU0ssIHNvIHRoZSBzZXJ2ZXIga2V5IGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBz YW1lIHdheSBhcyB0aGUgZXh0ZXJuYWwgUFNLIGlzIGRpc3RyaWJ1dGVkIChmb3IgZXhhbXBsZSwg ZmFjdG9yeSBwcm92aXNpb25pbmcpLg0KDQpCdXQgaW4gdGhlIHdlYiBjb250ZXh0LCBpdCBvY2N1 cnMgdG8gbWUgdGhhdCB0aGUgc2VydmVyIGtleSBjb3VsZCBiZSBkaXN0cmlidXRlZCBpbiB0aGUg VVJMLiBBbiBtZXRob2Qgc2ltaWxhciB0byAob3IgZXZlbiBhIHJlcHVycG9zaW5nIG9mKSB0aGUg dXNlcm5hbWUvcGFzc3dvcmQgb3B0aW9uIGNvdWxkIGJlIHVzZWQgd2hlbiBjaGFpbmluZyBmcm9t IG9uZSB3ZWIgc2l0ZSB0byBhbm90aGVyLiBGb3IgZXhhbXBsZSwgb25lIHNpdGUgY291bGQgbGlu ayB0byBhbm90aGVyIHVzaW5nIHRoZSBVUkwgaHR0cHM6Ly88a2V5aWQ+OjxFQ0RIIHB1YmxpYyBr ZXk+QDxob3N0Pi4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG1ha2UgaXRzIGZpcnN0 IHJlcXVlc3QgdG8gdGhlIG5ldyBzaXRlIHVzaW5nIDAtUlRUIHRyYWZmaWMuDQoNCkEgbnVtYmVy IG9mIGlzc3VlczoNCjEpIFdoYXQgaWYgdGhlIHB1YmxpYyBrZXkgaGFzIGJlZW4gcmV0aXJlZD8g VGhlIGNsaWVudCBzaG91bGQgaW5jbHVkZSBhbHRlcm5hdGl2ZSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIHNvIHRoYXQgdGhlIGhhbmRzaGFrZSBjb3VsZCBwcm9jZWVkLCB0aG91Z2ggb2YgY291cnNl IHRoZSByZXF1ZXN0IHdvdWxkIGhhdmUgdG8gYmUgcmVwZWF0ZWQgb25jZSB0aGUgY29ubmVjdGlv biB3YXMgZXN0YWJsaXNoZWQuDQoNCjIpIFRoaXMgYWxsb3dzIGFuIGF0dGFja2VyIHRvIGxldmVy YWdlIGEgdnVsbmVyYWJpbGl0eSBpbiBvbmUgc2l0ZSB0byBpbXBlcnNvbmF0ZSBhbm90aGVyLiBU byBtaXRpZ2F0ZSB0aGlzLCB0aGUgaGFuZHNoYWtlIGNvdWxkIGluY2x1ZGUgQ2VydGlmaWNhdGUv Q2VydGlmaWNhdGVWZXJpZnkgbWVzc2FnZXMgaW4gc2VydmVyJ3MgcmVzcG9uc2UgdG8gcHJvdmlk ZSBpbmRlcGVuZGVudCBhdXRoZW50aWNhdGlvbi4NCg0KMykgRG9lcyB0aGlzIHdvcmsgYXQgd2Vi IHNjYWxlPyBJIGNhbid0IGFuc3dlcjogbm90IG15IGFyZWEgb2YgZXhwZXJ0aXNlLiBQcm94aWVz IHdvdWxkIGhhdmUgdG8gYmUgc21hcnRlciwgYnV0IHByb3ZpZGVkIHRoZSBjbGllbnQgaW5jbHVk ZXMgbm9uLTNESCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIHRoZSBDbGllbnRIZWxsbywgdGhl biB0aGUgZmFpbHVyZSBjYXNlcyB3aWxsIG5vdCBjYXVzZSBhbnkgYWRkaXRpb25hbCBSVFRzIGlu IHNldHRpbmcgdXAgdGhlIGNvbm5lY3Rpb24uDQoNCklzIGl0IHdvcnRoIHRhY2tsaW5nIHRoZXNl IGlzc3VlcyB0byBzYXZlIG9uZSBSVFQgd2hlbiBjb25uZWN0aW5nIHRvIGEgbmV3IGhvc3Q/IEFn YWluLCBJIGRvbid0IGtub3csIGJ1dCBJIHRoaW5rIGl0J3MgYSBxdWVzdGlvbiB3b3J0aCBhc2tp bmcuDQoNClRvbnkNCg0KCkR5c29uIFRlY2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBudW1iZXIg MDE5NTkwOTAsIFRldGJ1cnkgSGlsbCwgTWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLgpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVz c2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg aXQsIGFuZCBkbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtZXNzYWdlIG9yIGluIGFueSBhdHRhY2htZW50LgpEeXNvbiBtYXkgbW9u aXRvciBlbWFpbCB0cmFmZmljIGRhdGEgYW5kIGNvbnRlbnQgZm9yIHNlY3VyaXR5ICYgdHJhaW5p bmcuCg== --_000_140080C241BAA1419B58F093108F9EDC1DBF4FA2UKMALMBOX01dyso_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIG9uIGFuZCBvZmYuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxi cj4NCjxiPlNlbnQ6PC9iPiAwOCBNYXJjaCAyMDE4IDIzOjI1PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHRoaW5rIHRoYXQgdGhpcyBhbmQg ZHJhZnQtcHV0bWFuIGFyZSBub3QgY29tcGV0aW5nLCBidXQgcmF0aGVyIHRoYXQgdGhleSBzZXJ2 ZSBkaWZmZXJlbnQgdXNlIGNhc2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQuIEl0 IHNvdW5kcyBsaWtlIHlvdSBoYXZlIGEgc2V0IG9mIHVzZSBjYXNlcyB3aGVyZSB5b3Uga25vdyBo b3cgdG8gcHJlZGlzdHJpYnV0ZSB0aGUgc2VydmVyIGtleT8gVGhpcyBpcyB0aGUgcGFydCB3ZSBm b3VuZCBjaGFsbGVuZ2luZyBpbiB0aGUgd2ViIGNvbnRleHQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWVzLCB0aGUg dXNlIGNhc2UgSSB3YXMgYWRkcmVzc2luZyB3YXMgaWRlbnRpY2FsIHRvIGV4dGVybmFsIFBTSywg c28gdGhlIHNlcnZlciBrZXkgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBl eHRlcm5hbCBQU0sgaXMgZGlzdHJpYnV0ZWQgKGZvciBleGFtcGxlLCBmYWN0b3J5DQogcHJvdmlz aW9uaW5nKS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJ1dCBpbiB0 aGUgd2ViIGNvbnRleHQsIGl0IG9jY3VycyB0byBtZSB0aGF0IHRoZSBzZXJ2ZXIga2V5IGNvdWxk IGJlIGRpc3RyaWJ1dGVkIGluIHRoZSBVUkwuIEFuIG1ldGhvZCBzaW1pbGFyIHRvIChvciBldmVu IGEgcmVwdXJwb3Npbmcgb2YpIHRoZSB1c2VybmFtZS9wYXNzd29yZCBvcHRpb24NCiBjb3VsZCBi ZSB1c2VkIHdoZW4gY2hhaW5pbmcgZnJvbSBvbmUgd2ViIHNpdGUgdG8gYW5vdGhlci4gRm9yIGV4 YW1wbGUsIG9uZSBzaXRlIGNvdWxkIGxpbmsgdG8gYW5vdGhlciB1c2luZyB0aGUgVVJMIGh0dHBz Oi8vJmx0O2tleWlkJmd0OzombHQ7RUNESCBwdWJsaWMga2V5Jmd0O0AmbHQ7aG9zdCZndDsuIFRo aXMgd291bGQgYWxsb3cgdGhlIGNsaWVudCB0byBtYWtlIGl0cyBmaXJzdCByZXF1ZXN0IHRvIHRo ZSBuZXcgc2l0ZSB1c2luZyAwLVJUVCB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5BIG51bWJlciBvZiBpc3N1ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xKSBXaGF0 IGlmIHRoZSBwdWJsaWMga2V5IGhhcyBiZWVuIHJldGlyZWQ/IFRoZSBjbGllbnQgc2hvdWxkIGlu Y2x1ZGUgYWx0ZXJuYXRpdmUgYXV0aGVudGljYXRpb24gbWV0aG9kcyBzbyB0aGF0IHRoZSBoYW5k c2hha2UgY291bGQgcHJvY2VlZCwgdGhvdWdoIG9mIGNvdXJzZSB0aGUgcmVxdWVzdA0KIHdvdWxk IGhhdmUgdG8gYmUgcmVwZWF0ZWQgb25jZSB0aGUgY29ubmVjdGlvbiB3YXMgZXN0YWJsaXNoZWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIpIFRoaXMgYWxsb3dzIGFu IGF0dGFja2VyIHRvIGxldmVyYWdlIGEgdnVsbmVyYWJpbGl0eSBpbiBvbmUgc2l0ZSB0byBpbXBl cnNvbmF0ZSBhbm90aGVyLiBUbyBtaXRpZ2F0ZSB0aGlzLCB0aGUgaGFuZHNoYWtlIGNvdWxkIGlu Y2x1ZGUgQ2VydGlmaWNhdGUvQ2VydGlmaWNhdGVWZXJpZnkgbWVzc2FnZXMNCiBpbiBzZXJ2ZXIn cyByZXNwb25zZSB0byBwcm92aWRlIGluZGVwZW5kZW50IGF1dGhlbnRpY2F0aW9uLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MykgRG9lcyB0aGlzIHdvcmsgYXQgd2Vi IHNjYWxlPyBJIGNhbid0IGFuc3dlcjogbm90IG15IGFyZWEgb2YgZXhwZXJ0aXNlLiBQcm94aWVz IHdvdWxkIGhhdmUgdG8gYmUgc21hcnRlciwgYnV0IHByb3ZpZGVkIHRoZSBjbGllbnQgaW5jbHVk ZXMgbm9uLTNESCBhdXRoZW50aWNhdGlvbiBtZXRob2RzDQogaW4gdGhlIENsaWVudEhlbGxvLCB0 aGVuIHRoZSBmYWlsdXJlIGNhc2VzIHdpbGwgbm90IGNhdXNlIGFueSBhZGRpdGlvbmFsIFJUVHMg aW4gc2V0dGluZyB1cCB0aGUgY29ubmVjdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JcyBpdCB3b3J0aCB0YWNrbGluZyB0aGVzZSBpc3N1ZXMgdG8gc2F2ZSBv bmUgUlRUIHdoZW4gY29ubmVjdGluZyB0byBhIG5ldyBob3N0PyBBZ2FpbiwgSSBkb24ndCBrbm93 LCBidXQgSSB0aGluayBpdCdzIGEgcXVlc3Rpb24gd29ydGggYXNraW5nLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyI+DQpEeXNvbiBUZWNobm9s b2d5IExpbWl0ZWQsIGNvbXBhbnkgbnVtYmVyIDAxOTU5MDkwLCBUZXRidXJ5IEhpbGwsIE1hbG1l c2J1cnksIFNOMTYgMFJQLCBVSy4NCjxicj4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSBhZGRyZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBpdCwgYW5kIGRvIG5vdCB1c2UsIGNv cHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ug b3IgaW4gYW55IGF0dGFjaG1lbnQuDQo8YnI+DQpEeXNvbiBtYXkgbW9uaXRvciBlbWFpbCB0cmFm ZmljIGRhdGEgYW5kIGNvbnRlbnQgZm9yIHNlY3VyaXR5ICZhbXA7IHRyYWluaW5nLg0KPC9zcGFu PjwvYm9keT4NCjwvaHRtbD4NCg== --_000_140080C241BAA1419B58F093108F9EDC1DBF4FA2UKMALMBOX01dyso_-- From nobody Tue Apr 10 03:04:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0D124234 for ; Tue, 10 Apr 2018 03:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, 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=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4jw25TiopT2 for ; Tue, 10 Apr 2018 03:04:03 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 90942126D0C for ; Tue, 10 Apr 2018 03:04:03 -0700 (PDT) Received: from [IPv6:2a04:b900:0:1:8fd:440a:450b:c41e] (unknown [IPv6:2a04:b900:0:1:8fd:440a:450b:c41e]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A118A8F0E for ; Tue, 10 Apr 2018 12:04:01 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1523354641; bh=L+plF0ZfxX/Wf/OzhYNatT95V7bJ5WFGMlAdI2H1G4o=; h=Subject:To:References:From:Date:In-Reply-To; b=H7mpRCDWIqAQedPm7pYC93T6WVn+b/9FxMbf0gQqfhR7GmQE98Bw5Dgenoi2eU/bq qdFMYzmbg9jjt/8cscs1XXtX0ZTXGOHeU2DDhHLNw6VOW896wGUY/sXlqUDfvT3GuN sGtUewoMYM63yD6g7O69hKLh5sc+LKzB6+O5LNuM= To: "" References: From: Willem Toorop Message-ID: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> Date: Tue, 10 Apr 2018 12:04:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 10:04:06 -0000 I support separation of concerns: publish as is, and start new work to extend existing Strict Transport Security mechanisms to include DANE authenticated TLS. Currently the draft is describing only a single mechanism: Letting owners of a (DNSSEC signed) domain vouch for their own TLS services. Not needing a third party for this is IMHO already valuable. HTTP Strict Transport Security (HSTS) [RFC6797] is extensible with directives. A new document could provide a useDANE directive for HSTS. That document could furthermore make more explicit, that when the chain extension delivers a denial of existence proof or a proof of insecurity, that a fallback to non-DANE PKIX has to be done. The chain extension already contains verification of Denial Of Existence proofs, because that is needed for verifying wildcard expansions. It does not explicitly mention the fallback to non-PKIX with a Denial of Existence proof or insecurity proof for the TLSA record, because it is (currently) irrelevant when the extension could simply be left out too. However, it does implicitly by referring to the DANE RFCs in paragraph 2 of section 6. Verification: > If the authentication chain is correctly verified, the client then > performs DANE authentication of the server according to the DANE TLS > protocol [RFC6698] [RFC7671]. Because the current draft is describing only the embedding of DANE records to authenticate the TLS service, it is quite short and to the point. I am afraid that built-in STS would bloat it with a lot of concerns that are not specific for the simple mechanism of embedding DANE. The extension as currently is does not add security like DANE over DNS protocol would have. This is pointed out in in the draft in Section 8, in which a mechanism like STS is also already suggested. I have a few questions too. Currently the extension contains only DNSSEC data, which can be verified to be authentic and correct. Is this also true for an additional TTL value? Is it safe to do STS at TLS ClientHello time? Why is there not a STS specification at TLS level already (which would also cover imaps, pops etc.), but only for protocols one layer above TLS? -- Willem Op 04-04-18 om 19:50 schreef Joseph Salowey: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document.  Please > answer the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include  > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both > > This call will be open until April 18, 2018. > > Thanks, > > Joe > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 10 06:48:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B65127735 for ; Tue, 10 Apr 2018 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVfqdVj3pb-f for ; Tue, 10 Apr 2018 06:48:41 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62B212D7E2 for ; Tue, 10 Apr 2018 06:48:25 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q80so13707448ioi.13 for ; Tue, 10 Apr 2018 06:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RE5WFr7VeS3kNC0TC7uf3S2d/KKCK3Xu/xDtv8Z3B9Q=; b=dfYTy0lKRoSscOOkCaJG214GmoGJDtuKz8Opw4MLwaEDDbUvZ2JkDwkPFnNqEM2QX2 Ty2x4c3M6R/Pmp5McVD1En491iB6HPcS/X+7TJWIfIEfuWfjO5U1dCKAWkZNwtBIb5gE eRlEqXuebGM8HG/BDTiGa35otaQui7kRPpFCE+GZlMLXx7hLgA1HXjlgA75WLaG5kOKs kFFZtY8iniZWPiF3hZGTfYzxK+HSm/t8X/Mf3OSJ0hGu+YDTSCov/AEB01BpoeLtGbsk cHuj7cExrSe2deuACTzlWcrg8ruSLl4tzoFgatPIFLE/7Hmq9TdkrVGOwEvuEU2cn5dz SI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RE5WFr7VeS3kNC0TC7uf3S2d/KKCK3Xu/xDtv8Z3B9Q=; b=FZKnn+py+xlHhpr912oGKqFg2V5MjKuVBtBvme/zl3g3Pjn6nMA1+GxNjIucvq1sVv P14ufN4ncfotGHknofkxdm/+tl+Q2haHpVRYQQ4TcpGl4M8CFq2vSgyrtZm2eL4T/9hp IxpMxPTeFDEN0qQo1NNfKweMeFbGm5sebAlteBR1ard9BUzRchGPM7NIX0EWMJ9tSln3 M/m3LL8j7fhduV+5FlBjo1RsPekIhoZ3/9uokF2c209zcNr1uOmq0aW9JG6nS2SWXY/z FNxcHvMihZMyAVf8HyWOxbneqgXOmoVHVtU5plvuSOTA8F6Urh23ri0j++HPWorteXE5 /ViQ== X-Gm-Message-State: ALQs6tBtXwDwkqEAXrr4oFgcJGICwICbXCyvp1oDMUlGLUtm2NVokff+ FpdkbX6sfQg0JqXnw3LlRjLAxtFEv+ziF4obvwQ= X-Google-Smtp-Source: AIpwx49iWSPX+bsEhRZULD1JTPhv6rwWhKRmYKvqS/m5GwBVOK+3Jxq0XVU79PpI4b1rs3l79SQsx+ujcl/pdT1N6z0= X-Received: by 10.107.137.98 with SMTP id l95mr524733iod.179.1523368105031; Tue, 10 Apr 2018 06:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.213.131 with HTTP; Tue, 10 Apr 2018 06:48:24 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Tue, 10 Apr 2018 09:48:24 -0400 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="001a113f3a7ec344f105697ec688" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 13:48:47 -0000 --001a113f3a7ec344f105697ec688 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > Yes. I support the publication of the document as is. and would like to explain my position a bit. I'm very sympathetic to Viktor's desire to enhance this protocol to provide downgrade resistance against PKIX attacks, and I generally would share that desire too. But I would also like to publish a document that has the solid consensus of the community that is one of key potential target consumers of this draft (web browsers and servers). So I'm giving more weight to their views and preferences. To date, the only people from that community that have spoken up have expressed strong opposition to Viktor's proposed enhancement. I also feel that the amount of time it has taken to finish up this draft has significantly hurt its deployment chances. In the early days of this draft there was (in my view) a window of opportunity where some browsers had actual interest in implementing this spec. But in the intervening time, there have been enough bandaids (CT and strengthed CAB forum requirements) applied to the WebPKI that to many people in the web community, the risk of bad actors has been sufficiently mitigated. But to the extent that there are still some folks interested in this proposal, I see no benefit in proposing an additional feature that they've stated doesn't work for them, or that they will not use. Another important facet of this debate that so far has not surfaced on recent mailing list discussions is an assessment of the relative benefits of webpki versus dane, and the recognition that there are strongly divergent views on this topic. In the early days of this draft, a number of web folks made it quite clear to me that this protocol can't be used to compel the use of DANE, and that the browser gets to decide what to use (and so dane-to-pkix downgrade attacks were not a concern for them). The large majority of DNSSEC proponents I know (and I'll state upfront that I'm one of them) clearly feel that DANE is superior to webpki, and that it's logical that DANE should be used to address webpki security issues. But this view is not shared by many others, most particularly in the web community. I've been involved in many lengthy debates on this topic, and the arguments against DANE usually boil down to: (1) widespread use 1024-bit RSA as the weak link in the majority of DNSSEC chains, (2) mistrust of registrars and their potential security failings, (3) mistrust of registries and/or other ancestor zones that could mount targeted attacks that could only be detected by a DNSSEC key transparency system, ala CT. These are legitimate arguments, and until we have better answers to them, I'm not inclined to aggressively push DANE, and position it as unconditionally superior, on communities that have expressed these concerns. Viktor has asserted that no-one will be motivated to deploy DANE without protection against PKIX downgrade, because there is no compelling enough additional gain of security. He may be right or wrong, but I've already heard several web folks disagree with him. And furthermore, they've expressed what I think are legitimate concerns about the fragility of the pinning proposal. Yes, I agree that it's not as bad as HPKP, but I also agree that there are more risks and failure possibilities than HSTS. As for other applications, we've already heard from a number of folks in the DNS over TLS camp that the draft works for them in the current form. Most DNS over TLS clients are expected to have explicit configuration of their resolver addresses and DANE capabilities. Some possible ways forward I see for folks wanting to develop a version of this spec with PKIX downgrade resistant capabilities (I've already stated earlier, that I would be happy to participate in such efforts): * Develop a new spec, with a new codepoint, and let the specs compete for adoption. * Develop a -bis document - if we manage to get WG consensus on the approach at a later date. * Do something outside the protocol, and specific to applications that want to include mechanisms to mandate DANE usage (like a HTTP header). -- Shumon Huque --001a113f3a7ec344f105697ec688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 4, 2018 at 1:50 PM, Joseph Salowey <joe@salowey.net> w= rote:
Hi Folks,

Some objections were raised late duri= ng the review of the=C2=A0draft-ietf-tls-dnssec-chain-extension. The q= uestion before the working group is either to publish the document as is or= to bring the document back into the working group to address the following= issues:

-=C2=A0Recommendation of= adding denial of existence proofs in the chain provided by the extension
- Adding signaling to require the use of this extension fo= r a period of time (Pinning with TTL)
This is a consensus call on h= ow to progress this document.=C2=A0 Please answer the following questions:<= /span>

1) Do you support publication of the document as is,= =C2=A0leaving these two issues to potenti= ally be addressed in=C2=A0follow-up work<= /span>?

Yes. I support t= he publication of the document as is.

and wou= ld like to explain my position a bit.

I'm very= sympathetic to Viktor's desire to enhance this protocol
to p= rovide downgrade resistance against PKIX attacks, and I
generally= would share that desire too.

But I would also lik= e to publish a document that has the solid
consensus of the commu= nity that is one of key potential target
consumers of this draft = (web browsers and servers). So I'm giving
more weight to thei= r views and preferences. To date, the only
people from that commu= nity that have spoken up have expressed
strong opposition to Vikt= or's proposed enhancement.

I also feel that th= e amount of time it has taken to finish up
this draft has signifi= cantly hurt its deployment chances. In the
early days of this dra= ft there was (in my view) a window of opportunity
where some brow= sers had actual interest in implementing this spec.
But in the in= tervening time, there have been enough bandaids (CT
and strengthe= d CAB forum requirements) applied to the WebPKI that
to many peop= le in the web community, the risk of bad actors has been
sufficie= ntly mitigated. But to the extent that there are still some
folks= interested in this proposal, I see no benefit in proposing an
ad= ditional feature that they've stated doesn't work for them, or
that they will not use.

Another important fa= cet of this debate that so far has not surfaced
on recent mailing= list discussions is an assessment of the relative
benefits of we= bpki versus dane, and the recognition that there are
strongly div= ergent views on this topic. In the early days of this
draft, a nu= mber of web folks made it quite clear to me that this
protocol ca= n't be used to compel the use of DANE, and that the browser
g= ets to decide what to use (and so dane-to-pkix downgrade attacks were
=
not a concern for them). The large majority of DNSSEC proponents I
know (and I'll state upfront that I'm one of them) clearly f= eel that
DANE is superior to webpki, and that it's logical th= at DANE should be
used to address webpki security issues. But thi= s view is not shared by
many others, most particularly in the web= community. I've been
involved in many lengthy debates on thi= s topic, and the arguments
against DANE usually boil down to: (1)= widespread use 1024-bit RSA
as the weak link in the majority of = DNSSEC chains, (2) mistrust of
registrars and their potential sec= urity failings, (3) mistrust of
registries and/or other ancestor = zones that could mount targeted
attacks that could only be detect= ed by a DNSSEC key transparency
system, ala CT. These are legitim= ate arguments, and until we have
better answers to them, I'm = not inclined to aggressively push DANE,
and position it as uncond= itionally superior, on communities that have
expressed these conc= erns.

Viktor has asserted that no-one will be moti= vated to deploy DANE
without protection against PKIX downgrade, b= ecause there is no
compelling enough additional gain of security.= He may be right or
wrong, but I've already heard several web= folks disagree with him.
And furthermore, they've expressed = what I think are legitimate
concerns about the fragility of the p= inning proposal. Yes, I agree
that it's not as bad as HPKP, b= ut I also agree that there are more
risks and failure possibiliti= es than HSTS.

As for other applications, we've= already heard from a number of
folks in the DNS over TLS camp th= at the draft works for them in
the current form. Most DNS over TL= S clients are expected to have
explicit configuration of their re= solver addresses and DANE
capabilities.

= Some possible ways forward I see for folks wanting to develop a version
of this spec with PKIX downgrade resistant capabilities (I've al= ready=C2=A0
stated earlier, that I would be happy to participate = in such efforts):

* Develop a new spec, with a new= codepoint, and let the specs compete
=C2=A0 for adoption.
<= div>* Develop a -bis document - if we manage to get WG consensus on the
=C2=A0 approach at a later date.
* Do something outside th= e protocol, and specific to applications
=C2=A0 that want to incl= ude mechanisms to mandate DANE usage (like a HTTP
=C2=A0 header).=

--=C2=A0
Shumon Huque
<= br>
=C2=A0
--001a113f3a7ec344f105697ec688-- From nobody Tue Apr 10 07:20:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E39012DA51 for ; Tue, 10 Apr 2018 07:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6wpg7hcda_kv for ; Tue, 10 Apr 2018 07:20:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (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 271D4129BBF for ; Tue, 10 Apr 2018 07:20:04 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 16CAC7A3309 for ; Tue, 10 Apr 2018 14:20:02 +0000 (UTC) (envelope-from viktor@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 10 Apr 2018 10:20:01 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 14:20:08 -0000 > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > consumers of this draft (web browsers and servers). So I'm giving > more weight to their views and preferences. To date, the only > people from that community that have spoken up have expressed > strong opposition to Viktor's proposed enhancement. There'll be negligible adoption of this draft as-is by Web Server operators on the public Internet. It offers them all pain and no gain. ZERO additional security over and above what they get with Let's Encrypt, only additional operational complexity and a new way to fail when the client supports DANE and the TLSA records are stale. Outside a few bilateral or intramural arrangements for mandatory DANE by clients when accessing specific destination servers, anyone deploying the present specification for the Web, is a masochist, or simply ignorant of what they're getting. What your response omits is any sort of cost/benefit analysis of the applicability of the present proposal to the Web. To be a proponent of adoption, you need to propose a specification that delivers tangible benefits at [plausibly] acceptable cost. No amount of wishful thinking or expedited publication will lead to meaningful adoption of a technology that is all cost and no benefit. If there's a flaw in my cost/benefit analysis posted earlier in this thread, please post a correction. From: Martin Thomson Date: Thu, 5 Apr 2018 12:07:57 +1000 To: TLS WG Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [skepticism re pinning, addressed in follow-ups] Your cost benefit analysis seems about right though. To Willem's point, moving the TTL negotiation out of the TLS extension into HTTP STS metadata means that each application protocol (IMAP, JMAP, POP, SMTP submission, ...) that would employ this specification to address the "last mile" problems with DNSSEC at mobile client systems, would need to be extended with a similar protocol extension. That's rather a lot of duplicate work (and a lot more delay) for something that can be done just once and promptly in this specification. -- Viktor. From nobody Tue Apr 10 08:22:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF06D12D95D for ; Tue, 10 Apr 2018 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yldlaKnG8Jbh for ; Tue, 10 Apr 2018 08:22:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F058712D962 for ; Tue, 10 Apr 2018 08:22:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40L9s25hN9z36y; Tue, 10 Apr 2018 17:22:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523373750; bh=yAfPaQHCVF0+FvWEE4Efrw18oW2jsdwF/E9w88fjPIk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=I6ax6OwkgYLuE1ve24DgX6bU20boz0J6+A8f646/QX04izt0uw6oyMqOvdORHvUF9 0qbxqOEqHEakOGX6q6HFkO7erjpCMgpa7yaQx/j0bS081reWFHWwU7aPRHuBHjjX8S FcNV3NY5M/ehOP0U1gkFHSeIWLwRHYw61AUgFvUc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6hL-ZLdp1VLD; Tue, 10 Apr 2018 17:22:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Apr 2018 17:22:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1923E35363F; Tue, 10 Apr 2018 11:22:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1923E35363F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0F0BA40C9594; Tue, 10 Apr 2018 11:22:28 -0400 (EDT) Date: Tue, 10 Apr 2018 11:22:28 -0400 (EDT) From: Paul Wouters To: Willem Toorop cc: "" In-Reply-To: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> Message-ID: References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:22:36 -0000 On Tue, 10 Apr 2018, Willem Toorop wrote: I just want to clarify one misconception in Willem's statement. See my previous emails to thist list for my full arguments on this issue. > The chain extension already contains verification of Denial Of Existence > proofs, because that is needed for verifying wildcard expansions. This might confuse people. I am talking about denial of existence of any TLSA record. You are talking about proof of non-existance of other TLSA records besides the one you are returning. These are completely different issues. I just want to ensure people realise when I said we need proof of non-existence, that people do not read your line "already contains this" as me being wrong. > It does not explicitly mention the fallback to non-PKIX with a Denial of > Existence proof or insecurity proof for the TLSA record, because it is > (currently) irrelevant when the extension could simply be left out too. So that's not one bug, but two bugs. Defining them out of scope is not what we should do. For instance, the document could already assume that the proof of TLS extension (pinning) is going to be solved elsewhere, and therefor a full denial of existence proof in this document would be valuable. The document does not specify what to do when it does not find a TLSA record to include. It does state: If the server is configured for DANE authentication, then it performs the appropriate DNS queries, builds the authentication chain, and returns it to the client. So if the server is configured for DANE, and it only finds denial of existence proofs of its own TLSA record, what is the expected behaviour? This hints at returning the proof of non-existence, but clearly even the authors are now saying they did not mean this and a server is not required to do this. Clearly the text needs clarification, and if it then leaves out denial of existence, it needs a justification for that as well. Paul From nobody Tue Apr 10 08:32:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07CA124B0A for ; Tue, 10 Apr 2018 08:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8SaFtiWrAbPb for ; Tue, 10 Apr 2018 08:32:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318DE12DA06 for ; Tue, 10 Apr 2018 08:32:56 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 625C37A3309 for ; Tue, 10 Apr 2018 15:32:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 10 Apr 2018 11:32:54 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:32:58 -0000 > On Apr 10, 2018, at 11:22 AM, Paul Wouters wrote: > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. Paul makes a good point. If indeed at some later time (as Willem suggests) a commitment to deliver the extension is made at some application layer, then the underlying TLS extension code will need to be able to return denial of existence of TLSA records when these are deleted or not yet present. And yet there is nothing in the document that describes returning denial of existence for the requested TLSA records, except to validate a wildcard TLSA RRset (which is still a positive response). So indeed the present document does not support responses that are a denial of existence *of the requested TLSA RRset*. So at the very least this defect will need to be addressed, (option (A)). This in no way weakens the imperative for (C) (both denial of existence support and an extension support TTL). -- Viktor. From nobody Tue Apr 10 09:49:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70EB12D574 for ; Tue, 10 Apr 2018 09:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 nli1tn0j0Jrv for ; Tue, 10 Apr 2018 09:49:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AD7126C89 for ; Tue, 10 Apr 2018 09:49:02 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3AGmac0004890 for ; Tue, 10 Apr 2018 17:49:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=NZumUz45TgudO/81vdfBQNRG4xMvBAMqc1vmGhGmaTo=; b=FcQ+A4Rxr0MYgBzciXXtdN7L2WHJzA5S9R5qPV7ol6NMXeikc3+5Tl+RFHpKdASUmv2Y /m3j96U5Jgm0iirlbnG8flyhzkvXnpENZq0jhPvRLvJtNG67fJBD4T30+7AjDTvqyQKz 0svmFnzWxNB1WirDFksHAn/gXcbCtw0fZpLrg6nzVIvxugvVXUyCZ/B3Fec9Nt5Bj4h6 ZezgFKXRVFlLYp+vxCCcvY2J/vCRGvBO3LfSqlXUZ3HwXJ6F4+2B4rQYKUJUyIkw02dv WMdwaNNbSuEqZLgK/0UjfCaKiiXVvpIDE056YIvyG+TcgwsCFCKZ9Ef6IXO03hbG7ocN MA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2h6s6y9tax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Apr 2018 17:49:02 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3AGkbcV014322 for ; Tue, 10 Apr 2018 12:49:00 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h6saum3mq-1 for ; Tue, 10 Apr 2018 12:48:59 -0400 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 AB765287DF for ; Tue, 10 Apr 2018 16:48:59 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f5wS2-00029c-Ua for tls@ietf.org; Tue, 10 Apr 2018 11:48:58 -0500 Date: Tue, 10 Apr 2018 11:48:58 -0500 From: Benjamin Kaduk To: TLS WG Message-ID: <20180410164858.GK17433@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=2018-04-10_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804100160 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804100160 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:49:04 -0000 Hi Viktor, With no hats. On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > > > But I would also like to publish a document that has the solid > > consensus of the community that is one of key potential target > > consumers of this draft (web browsers and servers). So I'm giving > > more weight to their views and preferences. To date, the only > > people from that community that have spoken up have expressed > > strong opposition to Viktor's proposed enhancement. > > There'll be negligible adoption of this draft as-is by Web Server > operators on the public Internet. It offers them all pain and no > gain. ZERO additional security over and above what they get with > Let's Encrypt, only additional operational complexity and a new > way to fail when the client supports DANE and the TLSA records > are stale. I'd like to expand the discussion a little bit, on the question of what the goals of this document are, as well as that they should be. Your text above seems to imply that you see the goal of the document as being a security mechanism to DANE-authenticate TLS connections. But it's not clear to me that this is the best reading of the current document text. Re-quoting some text you had included in the thread previously: [...] The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without performing additional DNS record lookups and incurring the associated latency penalty. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. [...] I'd like to see if we can agree on what "the problems described above" are. I am reading the quoted text to say that the problems are: 1) needing to incur additional latency by doing DNS lookups 2) interfering/broken middleboxes that drop DANE records 3) needing a secure connection to a validating resolver While it is true that performing DANE Authentication generally does have a security role, the three items I list above are essentially matters of convenience, and not themselves relevant for security. In this sense, the immediate goal of the document is more to play a role as a transport than to provide security directly. I concede that it remains useful to consider what the client will do with the received DANE records or denial thereof, so as to not unduly block off future routes for development. But it seems at least possible to take a very broad view in this space, including even the possibility of additional TLS extensions that can modify the behavior of this one (such as a modification to provide pinning-like behavior). Such extensions could be introduced closer in time to when the desire to implement and use such behavior appears. So, can we ask ourselves what we intend to get from the document? I suspect that the vehemence of disagreement being presented stems from a disagreement in the goals we are seeking to achieve. -Ben From nobody Tue Apr 10 10:25:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41B12DA1D for ; Tue, 10 Apr 2018 10:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b-19nxES7hf for ; Tue, 10 Apr 2018 10:25:04 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DC61270A0 for ; Tue, 10 Apr 2018 10:25:04 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id t192-v6so15437237itc.1 for ; Tue, 10 Apr 2018 10:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EljZLxm+Rhiz3rXtGnGvef7VOPWhoeaZ+jfCJpoT+Ig=; b=X38GnnGYXorCmTJ3KUF5ZzPEoQdl1bYZTkcUqnFXEV7l+yle/xaP7yAVx9S/GbjSP1 ZRIwOUUrcc+Z7KxHibcqOt1dGTy0xw/q5rrbqn5wX3+lYIcquRYoVQyoLR0t7P+9Oqr1 7sSs7js8yb3oq08cwI8GABjZE1jwUXBjRozsSpyC57Db6oTS/W5WJhtZQVjd+m97A7Kl 8ZyL/1HjHBQ8AWZJK0kxFoyl+lANGJkv3jmz3UbZrRxPfARxvtc+iHomM3enRzruIA6x QEXFO0Fnlg7MmVW3gB/1yLAlSebS7qIU30boWX4fWnkAvhdVfj2CJEdEa8YqOtmOYEpC c6sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EljZLxm+Rhiz3rXtGnGvef7VOPWhoeaZ+jfCJpoT+Ig=; b=JZdk+HBYkWLG+vhK+zXVCQamO+WCLGCC7YrxOJ1yCf5cbI2/h9MBP/zHXzggZs14h8 Un4gdHJkh6x0TAZ94XMB8T44x5x4ueg/P+iLcWsHWKgqJX8OL8FWxO3z4532qYc/rim2 x+LioueM6dfPloew84zVml/GGrlfeswkZc8gELuIQNQejOA2BZlCKTkZVL5ud4xMIwsA KTr9wsp4zIPNWcaVkRu5spbh/vJr0b1Z+V44j6M3VEQsPwJl1V3370iaRaXmsbu9D9Gj ZxTNRIh3cIsEjH34bNnkaZqeNgpGAygD9ryqOCxROYjkh4+DIiRxhNwGgvm0vDFhb5l4 owvg== X-Gm-Message-State: ALQs6tALU6i7Wi4DdsKj6ozrzdanLWrScmF0SVmAV5/Tdq7r/TpHkn3g jN4N0gX8m6HH6nRjH19QlwcTcxwFb+ZCNG5Wu2Q= X-Google-Smtp-Source: AIpwx4+rnyoD1POwf5LukZBlAdFfMEYwurefbn62tPnBxTxDGgklHg7V/SmXSgkbxi6WzYcIjY2rzftggpVOl6cTMyE= X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr388248itg.61.1523381103555; Tue, 10 Apr 2018 10:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.213.131 with HTTP; Tue, 10 Apr 2018 10:25:02 -0700 (PDT) In-Reply-To: <20180410164858.GK17433@akamai.com> References: <20180410164858.GK17433@akamai.com> From: Shumon Huque Date: Tue, 10 Apr 2018 13:25:02 -0400 Message-ID: To: Benjamin Kaduk Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000008919e0056981cde8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:25:06 -0000 --0000000000008919e0056981cde8 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote: [...] > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least possible > to take > a very broad view in this space, including even the possibility of > additional > TLS extensions that can modify the behavior of this one (such as a > modification > to provide pinning-like behavior). Maybe that's the best option. Advance the current document as-is. And also develop a separate DANE pinning extension (now'ish ..) -- Shumon Huque --0000000000008919e0056981cde8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
[...]=C2=A0
I concede that it remains useful to consider what the client will do
with the received DANE records or denial thereof, so as to not unduly
block off future routes for development.=C2=A0 But it seems at least possib= le to take
a very broad view in this space, including even the possibility of addition= al
TLS extensions that can modify the behavior of this one (such as a modifica= tion
to provide pinning-like behavior).=C2=A0
=C2=A0
= Maybe that's the best option. Advance the current document as-is. And a= lso
develop a separate DANE pinning extension (now'ish ..)

--=C2=A0
Shumon Huque

--0000000000008919e0056981cde8-- From nobody Tue Apr 10 11:14:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697E1271FD for ; Tue, 10 Apr 2018 11:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GKDmW5B72u7N for ; Tue, 10 Apr 2018 11:14:16 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5143212702E for ; Tue, 10 Apr 2018 11:14:16 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3AIAEOr022362; Tue, 10 Apr 2018 19:14:14 +0100 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=Nc+IcZDw7DmejdIkbve3LVHbzGgs844XDgGhEiX4ayg=; b=QGdJW4cGge3dCxPsaHqCLszbnEJQ7qRYIuZBB+JKJXMJr979FsLwqT6LIVAZHpnwWdX1 mJwBdCdDLH4aZ1fxBmFVyJ6Sj4ERVvCEMHI7LHblKpi7isED1jA2Hyi/W9TY2cpMifwm z835hl9Bc8ZoInyVay+mjh2tRuvSU3tPE5oZZ1fR07CvLrYpsjHuYsOMIiXpfNVf2efu CU/v//T5EAJF9AI0ZWKr1fK0X5bkEGIncnLhhqdumQ+8cWZv/eBp1Hb/h5MBd4/N56FH 43IUUA2FffOPAQWfv3C5qBWOmuLsF/UgEqQArHyS+VfvsX3Aa/bNCgfK3aeUsoOCC0wc Eg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2h6uttgnu5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Apr 2018 19:14:14 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3AI7cks004394; Tue, 10 Apr 2018 14:14:13 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78phtk13-1; Tue, 10 Apr 2018 14:14:13 -0400 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 7971D20068; Tue, 10 Apr 2018 18:14:13 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f5xmW-0004h6-Hd; Tue, 10 Apr 2018 13:14:12 -0500 Date: Tue, 10 Apr 2018 13:14:12 -0500 From: Benjamin Kaduk To: Shumon Huque Cc: TLS WG Message-ID: <20180410181412.GO17433@akamai.com> References: <20180410164858.GK17433@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=2018-04-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804100172 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804100172 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:14:18 -0000 On Tue, Apr 10, 2018 at 01:25:02PM -0400, Shumon Huque wrote: > On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote: > [...] > > > I concede that it remains useful to consider what the client will do > > with the received DANE records or denial thereof, so as to not unduly > > block off future routes for development. But it seems at least possible > > to take > > a very broad view in this space, including even the possibility of > > additional > > TLS extensions that can modify the behavior of this one (such as a > > modification > > to provide pinning-like behavior). > > > Maybe that's the best option. Advance the current document as-is. And also > develop a separate DANE pinning extension (now'ish ..) Perhaps, but we should come to agreement on the actual goals before we get too far... -Ben From nobody Tue Apr 10 11:43:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A484F12D877 for ; Tue, 10 Apr 2018 11:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1symcUXNiAa for ; Tue, 10 Apr 2018 11:43:05 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4FF12D777 for ; Tue, 10 Apr 2018 11:43:05 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 142-v6so17255568itl.5 for ; Tue, 10 Apr 2018 11:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/IR7GBUV4UukmmycyCK8aD3RAxD4WtkeXNJkk65/7jA=; b=l/kiQaDcb7tcWMFDiUJIrr6kDcSbPvpHCnHqN3k1+ZgHAqU8AqOOl0WitG+W/Mih4n cEYQDgElL9e3FfM0aFzUedjyq5SMjy6VNCjAm/PSI+PAfv5mWXW2+weyYI9roh6jp0f3 jvTwYyoNXTKNhYZQFs+tqhDyN/mWOuZrdNcBl+ClOf81bO6Tsyp6IkrD9euSRXUX1Ger pKlpg92mTblVABNdiOAQMka46xonVlQVUB0n8pK94HeEEKE7Ln/j/dhF8sfe8YUpPyAo 1g6QfNKsjVuPyltIxZfPjN3MDb73o+foDGQIG6A2RFP90Ca35Rh+/x5sBmiAMwfFEq2z UrIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/IR7GBUV4UukmmycyCK8aD3RAxD4WtkeXNJkk65/7jA=; b=iJQ6EhB8+T+ls9q5hBttZAejLtxS8+EPqEE3MbhAtX00Df5/4NFt+dFuHRrPBDTAjH XvQpLyM0jPYATAfxzZTOzakAxgb2yQrU9INMoS/VXhVO6zPSFPw620wUmqU6z0Rkssrz bnm7aQbkzK7FfWRox85PuUnscirG3Tk0ahOr4TDj2Cp/VmNwoxPYZPoofc/JqqzBKF6A TVdK8Ncxl6+cl44HfJ/x0vf5cfOFzakenbIzdx/wHCNoBZI8rq0q1L0B5E47GqA5k8O0 zZfboTD6yzQZ6cKF/o/iCQQ5A69Z4UwZ0dfr4KyiGfb/G9gig9tzzb60KEUNpOtU6fNI sAig== X-Gm-Message-State: ALQs6tBcK45KlWkk34TwPV1nSC+fyiscSGOR/nNKgvG0HH+Jd2XGmJvq lXt+Uz8F4e0NvgeigiWxDo8PlC05JO9vo3GwChHDQA== X-Google-Smtp-Source: AIpwx4+nGu8r8XYDCoX5ziLz500I6ntApsqbFStSVmAhjKXAjj1aXxW1His/iPn0U9seZIpNXNslhNI0Y4WVN2NJLHM= X-Received: by 2002:a24:209:: with SMTP id 9-v6mr670730itu.93.1523385784615; Tue, 10 Apr 2018 11:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.213.131 with HTTP; Tue, 10 Apr 2018 11:43:03 -0700 (PDT) In-Reply-To: References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> From: Shumon Huque Date: Tue, 10 Apr 2018 14:43:03 -0400 Message-ID: To: Paul Wouters Cc: Willem Toorop , "" Content-Type: multipart/alternative; boundary="0000000000008c4833056982e41e" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:43:08 -0000 --0000000000008c4833056982e41e Content-Type: text/plain; charset="UTF-8" On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters wrote: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misconception in Willem's statement. See my > previous emails to thist list for my full arguments on this issue. > > The chain extension already contains verification of Denial Of Existence >> proofs, because that is needed for verifying wildcard expansions. >> > > This might confuse people. I am talking about denial of existence of any > TLSA record. You are talking about proof of non-existance of other TLSA > records besides the one you are returning. These are completely > different issues. I just want to ensure people realise when I said we > need proof of non-existence, that people do not read your line "already > contains this" as me being wrong. > > > It does not explicitly mention the fallback to non-PKIX with a Denial of >> Existence proof or insecurity proof for the TLSA record, because it is >> (currently) irrelevant when the extension could simply be left out too. >> > > So that's not one bug, but two bugs. Defining them out of scope is not > what we should do. For instance, the document could already assume that > the proof of TLS extension (pinning) is going to be solved elsewhere, > and therefor a full denial of existence proof in this document would be > valuable. > > The document does not specify what to do when it does not find a TLSA > record to include. It does state: > > If the server is configured for DANE > authentication, then it performs the appropriate DNS queries, builds > the authentication chain, and returns it to the client. > > So if the server is configured for DANE, and it only finds denial of > existence proofs of its own TLSA record, what is the expected behaviour? > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. Personally, I would be okay with relaxing/clarifying the language in the draft a bit so that it does not rule out the possibility that a DNSSEC (NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be returned. I wonder if that, together with a new extension that can convey DANE pinning information is a way forward .. -- Shumon Huque --0000000000008c4833056982e41e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 10, 2018 at 11:22 AM, Paul Wouters <paul@nohats.ca> wro= te:
On Tue, 10 Apr 2018, Willem Toorop wr= ote:

I just want to clarify one misconception in Willem's statement. See my<= br> previous emails to thist list for my full arguments on this issue.

The chain extension already contains verification of Denial Of Existence proofs, because that is needed for verifying wildcard expansions.

 This might confuse people. I am talking about denial of existence of any TLSA record. You are talking about proof of non-existance of other TLSA
records besides the one you are returning. These are completely
different issues. I just want to ensure people realise when I said we
need proof of non-existence, that people do not read your line "alread= y
contains this" as me being wrong.


It does not explicitly mention the fallback to non-PKIX with a Denial of Existence proof or insecurity proof for the TLSA record, because it is
(currently) irrelevant when the extension could simply be left out too.

 So that's not one bug, but two bugs. Defining them out of scope is not<= br> what we should do. For instance, the document could already assume that
the proof of TLS extension (pinning) is going to be solved elsewhere,
and therefor a full denial of existence proof in this document would be
valuable.

The document does not specify what to do when it does not find a TLSA
record to include. It does state:

=C2=A0 =C2=A0 If the server is configured for DANE
=C2=A0 =C2=A0authentication, then it performs the appropriate DNS queries, = builds
=C2=A0 =C2=A0the authentication chain, and returns it to the client.

So if the server is configured for DANE, and it only finds denial of
existence proofs of its own TLSA record, what is the expected behaviour?
This hints at returning the proof of non-existence, but clearly even the authors are now saying they did not mean this and a server is not
required to do this. Clearly the text needs clarification, and if it
then leaves out denial of existence, it needs a justification for that
as well.

Personally, I would be okay with r= elaxing/clarifying the language in the draft a bit so that it does not rule= out the possibility that a DNSSEC (NSEC/NSEC3) chain corresponding to an N= XDOMAIN or NODATA response can be returned.

I wond= er if that, together with a new extension that can convey DANE pinning info= rmation is a way forward ..

--=C2=A0
Shu= mon Huque

--0000000000008c4833056982e41e-- From nobody Tue Apr 10 14:36:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4060C12D7E6 for ; Tue, 10 Apr 2018 14:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKNAuvWLUmuT for ; Tue, 10 Apr 2018 14:35:59 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [192.40.56.151]) (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 77C791272E1 for ; Tue, 10 Apr 2018 14:35:59 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 54DFE1E22B; Tue, 10 Apr 2018 21:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1523396158; bh=dhQ550mTMHt8e5V3JgPF8Bnvzxqq2CWylnRiqfVZFLE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=0iUpW8At1RPZSlKmyNi57ps9jCLWm+Ji08YJBdWYQnc4M1UMsX8mxeYSOuVcKU+jt eIRDBdJnrIL/BCu4FFFsHCW9wNyecPMWfER5yoGnvDSYczYLAVUjbc+z8wr2Hqgjya nzUPJWf+VjyOo+4gekcXJxbU0aVA33NKSTYy1Rv3WQxAIwC6mZj/dDOQTIbtr0z5bB RRAjUlojJZ83ZaQ7CPYl4vQkcGuc5E6YA2ZBcouniDB2ZRllK1Jp29KbCJMI1kCDVC Zt738QXuDHogv9mj2O+Zcu8+2nulSqEDOLxCvNQc044vJ/X1EF0CfIaXC9vnUAFT3e 6JAd+s45AIKDQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id A697E10773E78; Tue, 10 Apr 2018 21:35:51 +0000 (UTC) From: James Cloos To: Benjamin Kaduk Cc: Shumon Huque , TLS WG In-Reply-To: <20180410181412.GO17433@akamai.com> (Benjamin Kaduk's message of "Tue, 10 Apr 2018 13:14:12 -0500") References: <20180410164858.GK17433@akamai.com> <20180410181412.GO17433@akamai.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2018 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 10 Apr 2018 17:35:51 -0400 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:36:01 -0000 [I only have part of the thread available, and so am replying to the last message I see.] I agree that the draft MUST explicitly support chains corresponding to a NXDOMAIN or NODATA responses to have sufficient value. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Apr 10 16:58:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1812D944 for ; Tue, 10 Apr 2018 16:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNhcjSFlhVnf for ; Tue, 10 Apr 2018 16:58:02 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B6812D876 for ; Tue, 10 Apr 2018 16:58:02 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 66519A004F2C; Tue, 10 Apr 2018 16:58:01 -0700 (PDT) Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 16CCCA004F2B; Tue, 10 Apr 2018 16:58:00 -0700 (PDT) Date: Tue, 10 Apr 2018 18:53:21 -0500 From: Nico Williams To: Shumon Huque Cc: Joseph Salowey , "" Message-ID: <20180410235321.GR25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 23:58:04 -0000 On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote: > Yes. I support the publication of the document as is. > > and would like to explain my position a bit. > > I'm very sympathetic to Viktor's desire to enhance this protocol > to provide downgrade resistance against PKIX attacks, and I > generally would share that desire too. > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > [...] Assertion of facts not in evidence. We're here because there is a question as to consensus (and/or process). We need to address that. The earlier consensus is not just applicable, as if it were, we would not be having this LC. Using the earlier consensus as justification is not responsive to the substantive issues, and is just not a good argument. A valid argument would be that this extension works for DPRIV, but you should consider that even for DPRIV there is a downgrade unless the client knows a priori that the server does (or does not) support this extension. > I also feel that the amount of time it has taken to finish up > this draft has significantly hurt its deployment chances. In the I'll be blunt: I do not care about how long it's taken and neither should anyone else (besides, it will take longer on the RFC-Editor queue anyways; as an RFC author myself, I know this all too well). I care about the quality of the end result, and so should you, and so should the WG, IETF, and IESG. There is bug in the spec. The bug affects DPRIV as well as other applications -- it affects any application where the client does not know a priori whether the server will or will not be using this extension. > early days of this draft there was (in my view) a window of opportunity > where some browsers had actual interest in implementing this spec. See the point that even DPRIV is affected. You might argue that your DPRIV clients will know a priori whether the server supports this extension, but that would have to be true of all DPRIV clients. > But in the intervening time, there have been enough bandaids (CT > and strengthed CAB forum requirements) applied to the WebPKI that > to many people in the web community, the risk of bad actors has been > sufficiently mitigated. But to the extent that there are still some > folks interested in this proposal, I see no benefit in proposing an > additional feature that they've stated doesn't work for them, or > that they will not use. Contradition. Then why bother with DANE and this extension? Your argument is to cancel the Internet-Draft, not to publish it as-is, yet you are also arguing to publish as-is. Pick one. > Another important facet of this debate that so far has not surfaced > on recent mailing list discussions is an assessment of the relative > benefits of webpki versus dane, and the recognition that there are > strongly divergent views on this topic. [...] This is not the subject matter of this LC. > Viktor has asserted that no-one will be motivated to deploy DANE > without protection against PKIX downgrade, because there is no > compelling enough additional gain of security. He may be right or > wrong, but I've already heard several web folks disagree with him. > [...] You're not addressing the glaring downgrade attack. > As for other applications, we've already heard from a number of > folks in the DNS over TLS camp that the draft works for them in > the current form. Most DNS over TLS clients are expected to have > explicit configuration of their resolver addresses and DANE > capabilities. "Most" != "all". To live with the downgrade you'd have to make that "all". You might want to think about all the deployment scenarios ruled out by having this bug. > Some possible ways forward I see for folks wanting to develop a version > of this spec with PKIX downgrade resistant capabilities (I've already > stated earlier, that I would be happy to participate in such efforts): > > * Develop a new spec, with a new codepoint, and let the specs compete > for adoption. > * Develop a -bis document - if we manage to get WG consensus on the > approach at a later date. > * Do something outside the protocol, and specific to applications > that want to include mechanisms to mandate DANE usage (like a HTTP > header). Needless to say, I oppose your proposal for reasons I've stated before. Two specs is not better than one, and we can count on implementors missing one. Nico -- From nobody Tue Apr 10 17:17:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498E012D959 for ; Tue, 10 Apr 2018 17:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s8gxjZE73YO for ; Tue, 10 Apr 2018 17:17:20 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C07912D944 for ; Tue, 10 Apr 2018 17:17:20 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id g14so76458pfh.3 for ; Tue, 10 Apr 2018 17:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=cbKhXfmszm8R/l446Vq+vaOrLwloSHlmkjDoQZ9HJk4=; b=jGM43UpuommDobWB2zaeZJjUrLqpd2KECVgOqFkBqinGCqUxp9FQ5FhtA4YiuhzJrQ IoOmqVwmgF+7mfvonHkBULX3kZ1isne372TJt3H8xncUm5ko3AJPlZalU07AHuXeLpRM wx+l/qu6KJ43O0u97+XzYXT//FCrvuG8VtWXu4GbLjhoPEBqIVcIniTxpGyQ34Hi76vh jKYoLcZsDYYc8SSDtJZb2Q7A3b6dnPX018jPJ8UvoU1/dIpnGE85dUeA0/F/ZyvD2UwV N//K3vEgDvidH9X3SK7MsjHrpwUr2QYGZl5zxZDnvPwVcM0w65/FoMv23aFBEM3O6jWr R01Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=cbKhXfmszm8R/l446Vq+vaOrLwloSHlmkjDoQZ9HJk4=; b=aawveQG6stO4aakeqD8VRBmvo9Vgb6kN62x8BQthybc27/W4OHMAI1KB86zIREvg35 c5s5PwiHJSwcDcvSx99leHhTZRDXwRrzjOr+ApeP/3nuZDkhv2+Q8+6NHu1BSbpVDKiN z7UebZA9xc1rWJQIwUBYR3P8zhHIhGFmVTwJpe80KlOtn7JY+M391yZTZJ4wYfrOBWkw CAxyTQU0NJRif2zeUeQBw9bBjpS9zJs3kurMPnL/etkt8ltASg57JCvQql2hXxWKtBAk rgdt3r2Drr05kbvhfNmX4uCiF90IK/IUIAR6d074FA4Hmn+NAesopdBVS0WN7xSVRwNI P/0A== X-Gm-Message-State: ALQs6tALk65EmFnvZn+u8Vv3iRzXpp2XAc4qatlLByx4TTeZhic3XOSy MLr5mJkBP006iZj42XFfVLI94hs= X-Google-Smtp-Source: AIpwx4+e8Pp2Skdjdamelfji4qzBeI/KLPN/DEiPV5EmkmhnrxkCT+i2DshO+sUI/PB99RHlqPPp+g== X-Received: by 10.101.71.194 with SMTP id f2mr1775175pgs.312.1523405839220; Tue, 10 Apr 2018 17:17:19 -0700 (PDT) Received: from aspen.local (216-67-115-161-radius.dynamic.acsalaska.net. [216.67.115.161]) by smtp.gmail.com with ESMTPSA id w26sm9886852pfi.17.2018.04.10.17.17.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 17:17:18 -0700 (PDT) To: tls@ietf.org References: <20180410235321.GR25259@localhost> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PsLBlwQTAQoAQQIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaWd0AhkB AAoJEN+4kXKadtuPmvIQAJvVNnT0qhltq35AQ9Z1Ipx1IkEcQ8+yyMNLgyV9ZYhn9wn9JS/C TSb7HDSyTRiIz8CnaiCIOn2ZpT3sgYFw3cijT6YfRiifCeu4z3ea+XXOA/VyqXo42ARWOvq3 XdY3uj/j1c39PvhbopUwhulHzFJL7cMJCLEws588HdLwT8GVe+aTFPP4buJRqpOM0kSr/gkN 1IYKI0x1w6NgsgrYjCnv/VUwThjcVWPwMvZStvBnGquE6tvEmlnY+5cRktKSFw4X1ijxKzJD m0iqg7P7gNjC0r5uR2fF6BC0OPo9txPnabYph1wZ7V/5gnDwtWimD0ER77EO5Mr3zZHzva5v EwDpEbKXI43XAfpbxz3uc2fmXE2cvOCFgY/fTpX4kjVaxyFvjf1zrsac/7qFzwvgotYrYSc+ E1Ts+n1hWwsDA+qw/9reE1z9w+sn7SKL7zlS9sV54rfcd1AT0aMwlhAkEOaXRutriQ9BWWOv TOZBtRuV5RO/ZieY7lLX2+na2LjxLyak9k6wYwQwKvzvovBrr8zwDfJQDQujdVhk/lrlngAw Qh/U9dOg2hTUNiFHbKe1N+4vNCW/aLqm33LEV/vK/KepGsTl1ezQotOr0d05h2QySsdAgLCX Gv7bb+wTl/8Yx8hZfZO68KoRk8Zy4Yz8kE5LWJir+QQC7m7oo/4wZZcIzsFNBFppZ0gBEACg ZuM18ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1 YZ0OpQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR3 5FAgSnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fE ZHM66phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQ V0yBgc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4 cztvgmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRH RvQs0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBj Ltx1tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI 7qDHFxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnY jMJodU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABwsF8BBgBCgAmFiEET2gtkyoXlvgg8jTA 37iRcpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ7 5iY5pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiF PjkrQIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/J YK75BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApM LL0R/qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV 5abZ+iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJR i+cH7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7 Vz9F+6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloS bbMvP9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjx uLzdLY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+3 1fk1HKwqd9xRxC8= Message-ID: Date: Tue, 10 Apr 2018 16:17:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180410235321.GR25259@localhost> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wlXQWwhmwdwu18DbqeAEx71VxzPvTBd2X" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 00:17:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wlXQWwhmwdwu18DbqeAEx71VxzPvTBd2X Content-Type: multipart/mixed; boundary="HWOalVxPDEmbXlUEie3K4Jj1XWsSsrUXo"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension References: <20180410235321.GR25259@localhost> In-Reply-To: <20180410235321.GR25259@localhost> --HWOalVxPDEmbXlUEie3K4Jj1XWsSsrUXo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/10/18 3:53 PM, Nico Williams wrote: > The earlier consensus is not just applicable, as if it were, we would > not be having this LC. I have no idea what that even means, to be honest. We're through last call, and it's not that the earlier wg consensus isn't "applicable," it's that you've raised new issues. So let's be clear about that. I've been watching this discussion and trying to get a handle on what's been going on (and how this fits into several other IETF issues more generally), and I think this discussion would be over if the people arguing in favor of changing the use of the extension had plans to implement it. But so far nobody has said that they do. It's been suggested that if we intend to stick with the original, intended use we can just ignore the extra bytes, which strikes me as an exceedingly odd argument for including new protocol features. It's unfortunate that over in DNS-land they're discussing how to get rid of unused features that increase complexity, while over here we're having a discussion of how to add unused features that increase complexity. I think those of us who care about the institutional effectiveness of the IETF and the value of the standardization process care quite a bit about the amount of time it takes to push a document through to publication. Aside from negatively affecting the chances of the success of a given protocol, it's harmful to the standards process more broadly and discourages participation from people who want to get work done. There's an unfortunate number of IETF protocols that people worked on for years and that never saw implementation, and it seems to me that we ought to be trying to minimize the chances of that happening with the protocols we're working on. I haven't seen anything in this discussion that leads me to believe that the extension as specified is fundamentally broken or insecure for its intended use. I'm good with adding clarifying text or scoping it more clearly, but beating this thing to death for a use case that nobody intends to implement seems a bit misguided to me. Melinda --=20 Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --HWOalVxPDEmbXlUEie3K4Jj1XWsSsrUXo-- --wlXQWwhmwdwu18DbqeAEx71VxzPvTBd2X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAlrNVAwACgkQ37iRcpp2 24+wSA//c2mjATt1JtcIra72W9T9FfkCvx2fa1jMBjgqJ0FgKpyMQ92wY6h++axI O9/BPwsuOuqUxJA+KnEv2nuXZll6cSH5COl1zIuQDGEfpvZ3IxpePU6lUpcWuV0J P14b4qw3Fsume4c6xJtiUVka864q8Bzx1RJJC2T1wZrOAzhxG8LN52MpLqNAqzvK 80Mzzfyt7SC18iEd3Uo53c4AUMpauxi/YtWgkkmoguG1IXKIlSjfgHsrujfqeTvC 9X3ZXmSe/IiqmCVQANBBW4EV++AOj3uFmG7toLwPf1lAnACqGI/HXDmjRP/r6Czc CmVQawrF2jlVCvuRfYNJmB2Wl7RDaAyPPto56Fj1e9xp8lpzVETjqyquQmr5jwku p04BnZIOeWh3x1Qt54+Vz/jQlBPUcORxDYgCh9vcpnAUOFOgQ9H6GXEtxtGW8KVb sAv/hAFiIZdxR2YI9Cu94BGZ9rUboVPOh73s3N2F7JT+AHTDFlGkx7pI2sNVwgBJ Q1HPie23+Bsys+V7d6OXJIWuC75Si0+y/FkXl378yRqa+wNnvg0JXqrMptP9e/Yj 3gskFMLCi6Q0s3DUQ/Uk2s4YA5qX5e3Y4mfZEFz7srOW83VvXdXxnrcWrLVEnV+M 9K0ezGHjHjlNc7DRCBI11qYE8KpgXt7NOWq/iA70DeMYQUh/2d4= =Ojyt -----END PGP SIGNATURE----- --wlXQWwhmwdwu18DbqeAEx71VxzPvTBd2X-- From nobody Tue Apr 10 17:24:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33724124205 for ; Tue, 10 Apr 2018 17:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY6LHrwquvCD for ; Tue, 10 Apr 2018 17:24:04 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8EE120713 for ; Tue, 10 Apr 2018 17:24:04 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 3B816A004F1C; Tue, 10 Apr 2018 17:24:03 -0700 (PDT) Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id C06A8A004F2D; Tue, 10 Apr 2018 17:24:02 -0700 (PDT) Date: Tue, 10 Apr 2018 19:15:09 -0500 From: Nico Williams To: Benjamin Kaduk Cc: TLS WG Message-ID: <20180411001508.GS25259@localhost> References: <20180410164858.GK17433@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410164858.GK17433@akamai.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 00:24:06 -0000 On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote: > On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > > But I would also like to publish a document that has the solid > > > consensus of the community that is one of key potential target > > > consumers of this draft (web browsers and servers). So I'm giving > > > more weight to their views and preferences. To date, the only > > > people from that community that have spoken up have expressed > > > strong opposition to Viktor's proposed enhancement. > > > > There'll be negligible adoption of this draft as-is by Web Server > > operators on the public Internet. It offers them all pain and no > > gain. ZERO additional security over and above what they get with > > Let's Encrypt, only additional operational complexity and a new > > way to fail when the client supports DANE and the TLSA records > > are stale. > > I'd like to expand the discussion a little bit, on the question of > what the goals of this document are, as well as that they should be. I don't think that's necessary for settling this LC, but let's follow this for now: > Your text above seems to imply that you see the goal of the document > as being a security mechanism to DANE-authenticate TLS connections. Without precluding DANE + WebPKI. > But it's not clear to me that this is the best reading of the current > document text. Re-quoting some text you had included in the thread > previously: > > [...] The intent of this > proposal is to allow TLS clients to perform DANE Authentication > [RFC6698] [RFC7671] of a TLS server without performing additional DNS > record lookups and incurring the associated latency penalty. It also > provides the ability to avoid potential problems with TLS clients > being unable to look up DANE records because of an interfering or > broken middlebox on the path between the client and a DNS server > [HAMPERING]. And lastly, it allows a TLS client to validate the > server's DANE (TLSA) records itself without needing access to a > validating DNS resolver to which it has a secure connection. The last-mile problem described in the last sentence in the above quote is the most important point. This extension is not merely an optimization so that the client need not perform those additional DNS queries: it is a workaround to the last-mile problem. Moreover, this isn't just a run-time optimization, but also a developer optimization. Lastly, sometimes run-time and/or developer optimizations are actually necessary to get traction. > This mechanism is useful for TLS applications that need to address > the problems described above, typically web browsers or SIP/VoIP > [RFC3261] and XMPP [RFC7590]. [...] > > I'd like to see if we can agree on what "the problems described above" are. > I am reading the quoted text to say that the problems are: > > 1) needing to incur additional latency by doing DNS lookups > 2) interfering/broken middleboxes that drop DANE records > 3) needing a secure connection to a validating resolver (2) -> this extension is for clients to be able to use DANE when they otherwise could not. In order to be able to mix WebPKI and/or DANE, it is necessary to have the proofs of non-existence in order to be able to decide to dispense with DANE. Therefore this isn't just an optimization for when you want to use DANE: it is for when you are willing to use DANE, and willing to not do DANE, but you need to know which to do. It is because the choice is WebPKI and/or DANE that the downgrade attack, and the pinning mitigation (with TOFU semantics) matter. For example, on the web, in IMAP, ..., the WebPKI *and* (not *or*) DANE usage (DANE usages PKIX-TA #0 and PKIX-EE #1) are likely to matter. > While it is true that performing DANE Authentication generally does have > a security role, the three items I list above are essentially matters of > convenience, and not themselves relevant for security. In this sense, the > immediate goal of the document is more to play a role as a transport than to > provide security directly. I don't follow. The security role for DANE here is the whole story, and it is essential. How can we say that this is just about latency or last-mile problems when what DANE is doing at the end of the day is... provide authentication (security). > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least > possible to take a very broad view in this space, including even the > possibility of additional TLS extensions that can modify the behavior > of this one (such as a modification to provide pinning-like behavior). > Such extensions could be introduced closer in time to when the desire > to implement and use such behavior appears. Again, my concern is that the follow-on will not happen. I don't believe the authors are interested in it. It is perfectly possible that without this "feature" in on day one it may never get added because people throw their hands up and move on. This happens in our industry. But what really bugs me is that the only reason anyone seems to want to avoid these minimal changes is "so we can be done already". After 16 years of participation at the IETF, I find that... a bit surprising. It's not that we never shoot-the-engineers-and-ship, but that we try not to have glaring problems in our specs. We're the sort of SDO that has enough review to find and fix such problems, and we're a large community, and we try to serve that community's needs, not just each draft's authors' immediate needs. > So, can we ask ourselves what we intend to get from the document? I > suspect that the vehemence of disagreement being presented stems from > a disagreement in the goals we are seeking to achieve. OK: We need a general-purpose extension for stapled-DANE in TLS. Because for many (all existing) TLS applications this is an upgrade, we also need downgrade protection. Full stop. To me this is self-evident, and I don't understand how it is not to anyone else, except because of an urge to "be done", and I don't see how that could possibly be justification. FYI, I've had to go back to a WG before to correct a problem post-IESG approval. It happens. It's not a big deal. We'll almost certainly spend more time and effort arguing about this than about actual proposed text. Nico -- From nobody Tue Apr 10 17:37:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25DA12D944 for ; Tue, 10 Apr 2018 17:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDqJTncNW0Xq for ; Tue, 10 Apr 2018 17:37:40 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5B6120713 for ; Tue, 10 Apr 2018 17:37:40 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 892BBA004F2D; Tue, 10 Apr 2018 17:37:32 -0700 (PDT) Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 980C1A004F1C; Tue, 10 Apr 2018 17:37:19 -0700 (PDT) Date: Tue, 10 Apr 2018 19:26:34 -0500 From: Nico Williams To: Melinda Shore Cc: tls@ietf.org Message-ID: <20180411002633.GT25259@localhost> References: <20180410235321.GR25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 00:37:42 -0000 On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote: > On 4/10/18 3:53 PM, Nico Williams wrote: > > The earlier consensus is not just applicable, as if it were, we would > > not be having this LC. > > I have no idea what that even means, to be honest. We're through > last call, and it's not that the earlier wg consensus isn't > "applicable," it's that you've raised new issues. So let's be > clear about that. It means that because we are having this LC, we cannot use the previous consensus as evidence for ending this LC with a "no". We might as well never have had the LC in that case, and it is not a substantive response to the LC anyways. It's a "please go away" response. > I've been watching this discussion and trying to get a handle > on what's been going on (and how this fits into several other > IETF issues more generally), and I think this discussion would > be over if the people arguing in favor of changing the use > of the extension had plans to implement it. But so far nobody [...] Viktor began implementing DANE 8 months after it was published. That spec was ready. This spec is not. > It's unfortunate that over in DNS-land they're discussing how > to get rid of unused features that increase complexity, while over > here we're having a discussion of how to add unused features that > increase complexity. Sure, this is true, but it doesn't mean that we should exclude features that are necessary to making the protocol work in the first place. This is a TLS extension for stapled DANE, not a DPRIV extension to TLS. > I think those of us who care about the institutional effectiveness > of the IETF and the value of the standardization process care > quite a bit about the amount of time it takes to push a document > through to publication. Aside from negatively affecting the chances > [...] What is it to "care about the institutional effectiveness of the IETF ..."? Is it to care only about speediness? Or only about correctness? How about a bit of both? Honestly, if all you want is speediness, why not go to OASIS? Register the extension codepoint with IANA and publish elsewhere, why not? Doing things in the IETF means... the peanut gallery are not just spectators. Bringing work to the IETF means incurring the risk that others may glom onto it. It happens *all the time*, it's happened to me, and it will happen to others. There is nothing special to this piece of work that should exempt it. Nico -- From nobody Tue Apr 10 18:29:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0691241F8 for ; Tue, 10 Apr 2018 18:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YuMXXEFFaGY1 for ; Tue, 10 Apr 2018 18:29:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CEB120227 for ; Tue, 10 Apr 2018 18:29:02 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id F08EB7A3309 for ; Wed, 11 Apr 2018 01:29:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 10 Apr 2018 21:28:59 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <4D3C1B15-4258-4E98-9D27-69F9CA7B5F67@dukhovni.org> References: <20180410235321.GR25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 01:29:04 -0000 > On Apr 10, 2018, at 8:17 PM, Melinda Shore = wrote: >=20 > There's an unfortunate number of IETF protocols that > people worked on for years and that never saw implementation, and > it seems to me that we ought to be trying to minimize the chances > of that happening with the protocols we're working on. Exactly, which is why we need to make sure that the protocol does not fail to address its natural use-cases. This is a protocol for stapled DANE in TLS, and many potential applications will run in mixed WebPKI + DANE environments and will need to be able to do DANE *when possible*, in a downgrade-resistant manner (in this case after first contact). > I haven't seen > anything in this discussion that leads me to believe that the > extension as specified is fundamentally broken or insecure for its > intended use. The intended use in the introduction does not preclude Web browser HTTPS, JMAP, IMAP, POP, NNTP, SMTP Submission, XMPP, ... with only statically configured DANE for DPRIV in scope. DPRIV may well be the application that's ready now, but closing the door on others is surely unwise. > I'm good with adding clarifying text or scoping it > more clearly, but beating this thing to death for a use case that > nobody intends to implement seems a bit misguided to me. It is a mistake to confuse lack of immediate adoption plans with evidence that no such implementations will ever happen, and should be precluded at the outset. I had no idea DANE existed (too busy implementing comprehensive TLS support in Postfix to follow IETF work) when the DANE WG concluded work on RFC6698. 8 months later Tony Finch brought DANE to my attention, and I began implementation at that time. My implementation was the first non-toy implementation of DANE that got used in real systems. Was I ready to implement in August of 2012? No. Did I then never implement? Of course not, indeed we'd not be talking about DANE at all (it would be dead) if it were not for that work, and subsequent work to eliminate hurdles in the form of buggy authoritative servers at some major providers, integration into OpenSSL, Exim, ... The arguments against the proposal continue to ignore the technical issues and focus on perceived delay. If you really want to avoid delay, let's adopt the changes, and we'll be done. If there are technical flaws in the cost/benefit analysis that motivates the changes, please address those in detail. I see nothing in the draft that justifies limiting its scope to just a narrow application profile in which DANE is statically mandated by client policy. That limitation fails to scale. Even with DPRIV it should be possible for a server that no longer has TLSA records to provide a denial of existence proof (thus at least option (A) from the consensus call message) and employ PKIX instead (a domain may become unsigned if they change their mind about implementing DNSSEC). Option (B) supports incremental adoption, and provides downgrade protection after first contact, dramatically increasing the applicability. The changes are small, but needed to not preclude further implementation work in new application areas. There may not be implementors right away, but we should leave the door open for when they are. --=20 Viktor. From nobody Tue Apr 10 20:49:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB29B126DFF for ; Tue, 10 Apr 2018 20:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh7lUZCni-IC for ; Tue, 10 Apr 2018 20:49:01 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42D41201F8 for ; Tue, 10 Apr 2018 20:49:01 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 8549F30005C29; Tue, 10 Apr 2018 20:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=66g4h01aa/6CU5 xj9K1wKl7ln8E=; b=d9uGSu6qz69cbcjU1WduZC84gi0PCynhKrUX4T8IN2kQKJ kk7bXCHNcSi+MeOyP1OVh/jT2j2TPMNe1Wb8weU4fksLznbrBVlFlciCddsxpAnA 5JQQjWJtiEYwRQKtEk6IaigwDV1xARnPFHWd2Hy4PeEfWttUGIOjmkcxhfF8g= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 2276230005C25; Tue, 10 Apr 2018 20:49:01 -0700 (PDT) Date: Tue, 10 Apr 2018 22:42:04 -0500 From: Nico Williams To: Joseph Salowey Cc: "" Message-ID: <20180411034203.GU25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [TLS] A new argument (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:49:04 -0000 Let me synthesize one new argument, though I've implied it before, but I think making it explicit may be useful: The cost of making the requested changes is fixed and can be estimated -- measured even, after the fact. I argue that cost is low. But the cost/risk of not making the requested changes is intangible -- could be very high, or barely more (but not less) than the cost of making the changes. We'd have to be sanguine to dismiss my estimate of the cost/risk of fixing this later. Perhaps that's right anyways, but it can plausibly be very large too, and that surely should trump a small fixed cost, therefore we're better off taking this hit now. I might clarify other points on the main thread, but, really, for me, the whole thing boils down to: are we looking out for the future, and is our contention of risk to future DANE deployment even plausible. It won't surprise anyone that I believe my estimate of the risk to future DANE deployment is not merely plausible. It won't surprise anyone either that I believe that even if the likelihood of reduction of future DANE deployment were low, we, the IETF, and in particular the IESG, ought to care about making our protocols sufficiently generic when the cost of doing so is low, as surely it would be here. We've already incurred what should be much of the cost of making the requested changes. A wee bit little more won't hurt. Let us now then proceed to proposed text. Nico -- From nobody Wed Apr 11 07:54:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDFD1241F3 for ; Wed, 11 Apr 2018 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 xqw4NaZ_sbXs for ; Wed, 11 Apr 2018 07:54:01 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DADC1200F1 for ; Wed, 11 Apr 2018 07:54:01 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id f47-v6so2305269oth.2 for ; Wed, 11 Apr 2018 07:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OA1ArCq1KepikQfZ6CE737jY7eg2N4MOg/bksYtjC3U=; b=AOWD0nE7Zo4ZhQDFk3GH7wvL8JGpu8u0jLLkggZ+jIjfrf4SP9FGufP0VM5fgJYiWt M2+y27mrl3uq0oIGNnwY+q0WYpkmmn3329dUOl6g5nzF3fjIfb8GE7Xs2uvrw6kxAmxE WdcdbP0vPLMFTUCULx1lrEEdVnNvSWeYFc2ctjmQo7U9o8+mCrawJla/pco7mAwzOYYJ HBATY9tb0hVpO4fDHTEd8/vOggIwIlr2Us4UAfsRDZ6tjwKXh+MZv/N0wGXAW9XB3+Lb h1QpgOTHOG8xvy8iK5Ub//3J/rwGg23DtzUz/QeMHHgxeHxmnmUsoyN4/wSYO0IItbf3 FRlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OA1ArCq1KepikQfZ6CE737jY7eg2N4MOg/bksYtjC3U=; b=NkroI7n5BJjn2yNRhXQBWIwBY6wwbx8VmS88bsVXvbY2zoG8yALsZEPJR6A27tvRLQ Y4JhsUUkifvl7Afof1e2EgFaS8llNByBPZc2ZbJKGeLXZx6cZlJbeW1Y5BM8xMTv7l6g W0Jotbzix6ACPzPjmQGXFm5d62iLlRLtNuc+ma9CBGePG3kduEwMcZjch5wQ4LHFssTe ar1WKHbb6fuUwv4/aOyNWs9V5v9+sstUxYJ03/KaaUJ2AVek+D01nTrBVAZMje4oQ6jR r5pvCkK5pNIk+rWYriL9GMyxJGjOxRYrl2ZcJkTtrE9cw4+fjiAGnGxdaHC6qsuMiYj3 66vQ== X-Gm-Message-State: ALQs6tDTzRiiSiyZsJU5TfgADIMMKTuF+Z+Fm6C8Yjx96ou3ZdMewpqK m04MDDFhFmHC45FotxfsmfwmhZVm2BcOpc251tSeD8iB X-Google-Smtp-Source: AIpwx4/3dfnsFu5x0AeWuVZx422Cxy2FPeXmdnNO75+gk6r9zMDDdCtJEB2H490+0fKO6iPOfX7byWcklB8RREnkm00= X-Received: by 2002:a9d:7308:: with SMTP id e8-v6mr2382901otk.271.1523458440609; Wed, 11 Apr 2018 07:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Wed, 11 Apr 2018 07:54:00 -0700 (PDT) In-Reply-To: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Wed, 11 Apr 2018 10:54:00 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000002ee2e9056993cfff" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:54:04 -0000 --0000000000002ee2e9056993cfff Content-Type: text/plain; charset="UTF-8" Hey TLS folks, As I mentioned in my brief presentation at IETF 101, Owen and I have been thinking about how to bring PAKE back to TLS 1.3 (since earlier SRP mechanisms don't really apply). We've just published an I-D describing a proposed mechanism, and I've implemented this mechanism in the `mint` TLS 1.3 stack: https://github.com/bifurcation/mint/pull/193 We would love to hear any feedback on the approach proposed here, and on whether other people here would be interested in working on a PAKE mechanism for TLS in this working group. To address the obvious "Which PAKE?" question: We did a brief survey of the PAKE literature, and SPAKE2 seemed like a good candidate here for a few reasons: - It allows a message pattern that aligns well with the TLS 1.3 handshake - In particular, the key confirmation messages map pretty closely to the TLS Finished MAC - It doesn't require much in the way of exotic operations (just EC point addition) - It's gotten pretty robust review from CFRG Thanks, --Richard ---------- Forwarded message ---------- From: Date: Wed, Apr 11, 2018 at 10:45 AM Subject: New Version Notification for draft-barnes-tls-pake-00.txt To: Richard Barnes , Owen Friel A new version of I-D, draft-barnes-tls-pake-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 00 Title: Usage of SPAKE with TLS 1.3 Document date: 2018-04-11 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-0 0.txt Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake Abstract: The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes how the SPAKE password-authenticated key exchange can be used with TLS 1.3. 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 --0000000000002ee2e9056993cfff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey TLS folks,

As I mentione= d in my brief presentation at IETF 101, Owen and I have been thinking about= how to bring PAKE back to TLS 1.3 (since earlier SRP mechanisms don't = really apply).

We've just published an I-D des= cribing a proposed mechanism, and I've implemented this mechanism in th= e `mint` TLS 1.3 stack:


We would love to hear = any feedback on the approach proposed here, and on whether other people her= e would be interested in working on a PAKE mechanism for TLS in this workin= g group.

To address the obvious "Which PAKE?&= quot; question: We did a brief survey of the PAKE literature, and SPAKE2 se= emed like a good candidate here for a few reasons:

- It allows a message pattern that aligns well with the TLS 1.3 handshake<= /div>
- In particular, the key confirmation messages map pretty closely= to the TLS Finished MAC
- It doesn't require much in the= way of exotic operations (just EC point addition)
- It's= gotten pretty robust review from CFRG

Thanks,
--Richard


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
D= ate: Wed, Apr 11, 2018 at 10:45 AM
Subject: New Version Notification for= draft-barnes-tls-pake-00.txt
To: Richard Barnes <rlb@ipv.sx>, Owe= n Friel <ofriel@ci= sco.com>



A new version of I-D, draft-barnes-tls-pake-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-barnes-tls-pake
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Usage of SPAKE with TLS 1.3
Document date:=C2=A0 2018-04-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-barnes-tls-pake= -00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-barnes-tls-pake-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-barnes-tls-pake


Abstract:
=C2=A0 =C2=A0The pre-shared key mechanism available in TLS 1.3 is not suita= ble for
=C2=A0 =C2=A0usage with low-entropy keys, such as passwords entered by user= s.
=C2=A0 =C2=A0This document describes how the SPAKE password-authenticated k= ey
=C2=A0 =C2=A0exchange can be used with TLS 1.3.




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

The IETF Secretariat


--0000000000002ee2e9056993cfff-- From nobody Wed Apr 11 10:33:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A944812785F for ; Wed, 11 Apr 2018 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 jYEx3X3BR-kS for ; Wed, 11 Apr 2018 10:33:51 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91DC12025C for ; Wed, 11 Apr 2018 10:33:51 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3BHT0fk002146; Wed, 11 Apr 2018 18:33:51 +0100 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=Sk6cB4d187v1U+5f9pC/A0NpxaY2fBRw9wEouoUcDW4=; b=W65XB6t2wN1qyWAzLpqHLmThrKLn8/fp6ytM7mTm4pniHlpwOCdRLYKUsMTKkJ3yTgm+ P++RUSxnDf9EplyJaVn8ehfCGWNqgvTtbUTWuke5ZkPPtCqmQza43xTMGYeS3r9/LVzD MJz6gOXU3tSM9uRpnN+LnO0+XR9tlGQfOVYcT1R+crRYvj/V3rs8WWzhJT8ZkPO9cxm1 KmoepMAW9t+Dnj3Yaw4lxEXNhulBZlezWh+GgtjTHFqKd56ubNrJcM/nGGFL1OOeWIAO H8TRsL9xKyqlqhB8+PNVr3OS+u2DUbmuLdpZ3QeTqX/+c5C/GqmdZpxJUqnDBF9TffdT UQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2h9edu9fqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 18:33:50 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3BHWVXV019167; Wed, 11 Apr 2018 13:33:49 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2h78phxm7w-1; Wed, 11 Apr 2018 13:33:49 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 74FE282F79; Wed, 11 Apr 2018 17:33:49 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f6Jcy-0003gF-FH; Wed, 11 Apr 2018 12:33:48 -0500 Date: Wed, 11 Apr 2018 12:33:48 -0500 From: Benjamin Kaduk To: Nico Williams Cc: "" Message-ID: <20180411173348.GP17433@akamai.com> References: <20180410235321.GR25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410235321.GR25259@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110163 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110162 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 17:33:54 -0000 On Tue, Apr 10, 2018 at 06:53:21PM -0500, Nico Williams wrote: > On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote: > > Assertion of facts not in evidence. We're here because there is a That argument cuts in many directions, of course. > question as to consensus (and/or process). We need to address that. I don't really agree with that characterization. To state my understanding, as responsible AD, of the status of this document: this document is in the RFC Editor's queue being processed. The WG is being asked if the late-breaking issues, raised after consensus was determined, are severe enough to merit clawing the document back from the RFC Editor to make further changes. This is, in effect, asking the WG to overturn a previous consensus, which requires a stronger bar than obtaining an initial consensus from vacuum. [takes AD hat off] > I'll be blunt: I do not care about how long it's taken and neither > should anyone else (besides, it will take longer on the RFC-Editor queue > anyways; as an RFC author myself, I know this all too well). I care > about the quality of the end result, and so should you, and so should > the WG, IETF, and IESG. > > There is bug in the spec. This appears to be an assertion of fact without (immediately local) supporting evidence. :) You believe there is a bug in the details of the spec, sure, and I suspect that this follows naturally from your related belief that there is a bug in the target scope of the spec. If we don't agree on what the target scope of the document should be, then it's unsurprising that we will fail to agree on the protocol details. > > Another important facet of this debate that so far has not surfaced > > on recent mailing list discussions is an assessment of the relative > > benefits of webpki versus dane, and the recognition that there are > > strongly divergent views on this topic. [...] > > This is not the subject matter of this LC. You say this, but to me it seems a relevant factor when determining the target scope for the spec. That is, if some individual believes that DANE is amazing and the Web PKI is crap, then that individual is likely to want to see DANE take over for the Web PKI in authenticating Web TLS connections, and as such see that as a vital motivating factor for any work involving bundling DANE records in the TLS handshake. Someone who is less keen on DANE over the Web PKI may not share that enthusiasm or confidence for focusing the scope on that use case. > > Viktor has asserted that no-one will be motivated to deploy DANE > > without protection against PKIX downgrade, because there is no > > compelling enough additional gain of security. He may be right or > > wrong, but I've already heard several web folks disagree with him. > > [...] > > You're not addressing the glaring downgrade attack. I think this argument would be more compelling if phrased differently. (N.B. that I don't know *how* compelling it would be, and whether that would be *sufficiently* compelling to effect change; I just think it could be more compelling than this phrasing makes it.) In particular, the question of scope arises again. My impression is that at least some proponents of the document as-is want to treat the scope as something like "we allow for the transport of DNSSEC records over channels where they were not previously available in a useful fashion" (whether due to actual blocking or latency considerations), in particular, leaving the question of how those records are used at the endpoing as out of scope. You want to bring in the downgrade attack as being a significant risk/drawback for several, not necessarily all, potential use cases for consumers of the transport. The question in this framing then becomes a balance between the potential/expected scale and importance of the affected use cases and the unaffected use cases. This ties in nicely to your new argument about the cost/risk tradeoff being considered. To you, the "affected use cases" are potentially huge (e.g., "all web TLS connections"), and even if someone thinks that the chance of that happening is somewhat small, the risk of it happening but being broken by the downgrade attack is magnified by the scale into something that merits consideration now. This is to be balanced against more-certain/more-expected use cases that might be perceived as more "fringe" and probably as smaller in scale than "all web connections". I don't expect to get unanimous agreement about the potential scale and likelihood of various perceived use cases, but would hope that people will consider the tradeoff to be made, as you have framed it. -Ben From nobody Wed Apr 11 12:12:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E7129C56 for ; Wed, 11 Apr 2018 12:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8XVJ9dlY8e2H for ; Wed, 11 Apr 2018 12:12:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9DE1271FD for ; Wed, 11 Apr 2018 12:12:51 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E9B6A7A3309 for ; Wed, 11 Apr 2018 19:12:50 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <20180411173348.GP17433@akamai.com> Date: Wed, 11 Apr 2018 15:12:50 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <6C7AC208-6B97-472E-8B82-1BF644ECAEA3@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 19:12:54 -0000 > On Apr 11, 2018, at 1:33 PM, Benjamin Kaduk wrote: > > You say this, but to me it seems a relevant factor when determining the > target scope for the spec. That is, if some individual believes that > DANE is amazing and the Web PKI is crap, then that individual is likely > to want to see DANE take over for the Web PKI in authenticating Web TLS > connections, and as such see that as a vital motivating factor for > any work involving bundling DANE records in the TLS handshake. My motivation for updates to the draft is that *neither* 1. WebPKI sucks, DANE rules 2. WebPKI rules, DANE sucks is a good zealous position. Each have their strengths and weaknesses. For, example, for DV certificates, I am of the opinion that DANE is more resistant to mis-issuance. Given that neither 1. or 2. is objective truth, the draft should support "restrictive" use where neither is fully trusted, and and a server operator publishes (for _443._tcp) *restrictive* DANE TLSA records with certificate usage PKIX-EE(1) or PKIX-TA(0), with the expectation that when/if browsers that adopt and support this specification they'll enforce *both* WebPKI *and* DANE. But that requires downgrade protection. This applies to not just browsers, but to any application in which the installed base is WebPKI, and DANE is of necessity incremental and so opportunistic (used when published, but not a-priori mandated). Examples, IMAP, JMAP, NTTP, XMPP, SUBMIT, LDAP, ... As it stands, this draft fails to provide the downgrade protection needed for opportunistic adoption. It mentions in Section 8 that some clients might apply an infinite pin (a fragile strategy), but fails to describe denial of existence as a valid way to comply with such a pin should TLSA records be removed. And without a server TTL hint, the infinite pins make adoption in multi-datacentre deployments impractical. The draft has a serious scope deficiency. And indeed you're right that the key issue is *scope*, but an overly narrow scope is a substantial technical issue. Further, little attention has been paid in the WG to the scope issue, and the document sailed through with discussion mostly around just the data formats, and the key issue of scope fell through the cracks. > Someone > who is less keen on DANE over the Web PKI may not share that enthusiasm > or confidence for focusing the scope on that use case. I would say that WebPKI adherents would also want to make sure that any use in existing WebPKI applications would be *restrictive* and not either WebPKI or DANE whichever is weaker. But then the draft needs to have downgrade protection, and the applications in question might (converse of RFC7672) require any DANE TLSA records with usages other than PKIX-TA(0) or PKIX-EE(1) to be treated as "unusable". So it all comes down to whether it is appropriate to go forward with a very narrow scope (perhaps even too narrow for the initial applications, but that's debatable) and ask future adopters in new spaces to write new drafts (and pay the delay of having to wait for those to get reviewed and adopted), or amend the draft to anticipate future uses beyond the immediate motivating use case. My view is clearly in favour of an anticipatory scope. Future implementors in new applications would likely not bother to start if the cost of that is going through the IETF process for a new extension to augment this one. -- Viktor. From nobody Thu Apr 12 01:40:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C21242EA for ; Thu, 12 Apr 2018 01:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T8K3IEl38qc for ; Thu, 12 Apr 2018 01:40:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968E9124F57 for ; Thu, 12 Apr 2018 01:40:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40MDrF11sQzC2r; Thu, 12 Apr 2018 10:40:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523522429; bh=r01rpVW3IV19VIY3AMVq9X9VCaMEU244haggDtagKeU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kHYSebR5jick0rwM65XMKvnHFcuDjq0EmHeUZZYBW7L1BanmKTNVshzc0f13X4dy8 +6vENbOJsjByiCVFr34iwLo7vCes4TYTpJC41CsN2AnCskVtzD9DovOWVyU9Yu85y4 RnHaolxq3VSHF+OUm/xfZM426fQ0yf883l3vb73I= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DKLNQwhSNGD8; Thu, 12 Apr 2018 10:40:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 12 Apr 2018 10:40:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8CDF530B3EA; Thu, 12 Apr 2018 04:40:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8CDF530B3EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7B58340008A0; Thu, 12 Apr 2018 04:40:25 -0400 (EDT) Date: Thu, 12 Apr 2018 04:40:25 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: Nico Williams , "" In-Reply-To: <20180411173348.GP17433@akamai.com> Message-ID: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 08:40:33 -0000 On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > I don't really agree with that characterization. To state my understanding, > as responsible AD, of the status of this document: this document is in the > RFC Editor's queue being processed. That was a process mistake. 1) ekr filed a DISCUSS 2) other people raised issues in response 3) ekr's DISCUSS was resolved but not the other people's concern 4) document was placed in RFC Editor queue despite this 5) TLS consensus call done on the list 6) here we are.... I think it is not good to use this process as a way of approving things. A process mistake was made. Paul From nobody Thu Apr 12 05:58:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0812704A for ; Thu, 12 Apr 2018 05:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cEY5U0FXcM7f for ; Thu, 12 Apr 2018 05:58:38 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDA0124207 for ; Thu, 12 Apr 2018 05:58:38 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id a14-v6so5863029otf.6 for ; Thu, 12 Apr 2018 05:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vm6vbUz90WDOwNSu+4r0bZoftWwAE3VEl9OAwbSqaXI=; b=tzCSriplewNaF6KubAUi+jkMzCvf4SGr5rdbvmHRZZAK5s9FryDSa33tQVL3rdlvGG MVqwKqohm03KGMehHVb3E2G4SFCfcw5AuRhgNirMC9pmvxnWwCpKgQGV94LEqUhiBNgn 9fenWuTgcub/oQ3iwwR4XG4WRAqZf7BcMZ/Jq8Yf0Ogxpla2wmlVGnYakFwbm64hnpgY 0fFoLrOca054+M+uzh2zhKPjiqnfonPbTwse/LhICZq2oTSKLPW84ylGlotIhSXNkrWX WihBI42R7mJzSdykFqs6aMDcYIBLkitGWfjnDUS46U4lzM7zKiIhpN0zLa9zxxZSzUz6 pxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vm6vbUz90WDOwNSu+4r0bZoftWwAE3VEl9OAwbSqaXI=; b=Hept/ReVNGlCqR8AQiyZP2aZowI+rrNZZH9FtfmDoLKC3nqbpJuNImC3akW9+Pirbw zf2ctpM7xTShlgZKvwFTjDYiqOc/EM6AjFaqBlMfcD4BzRiYYpO4bAg4TCRIR3UUcNH0 +JDLXRlxDcb9Sotzj2ZU2b5IIAwGa5w/9leDqV6v4xX50GgTtXd+T4FZzPinHHKdJ4nO jpRz0CuR6YJj+aHYUTut4udmDxCeu1QTJxNNk1f6q0iLruTO11O6WCV59DgCbb7CmgmZ Zxtv7uJ4PZ2euvbpflmb36Pau6xsjoVtskXo3UrAr6E8SNyjANHKkCP4iX25yMNhsjEA IrMw== X-Gm-Message-State: ALQs6tDLJPkS4AYx6QpIHiZCKWDHPlz1p9WL5Sa4fNgD/i3TjscOLGt5 12XWE8d+R8Br6iBlPbigF2AhHB7i5tnkPkMmrMjbPG93 X-Google-Smtp-Source: AIpwx48byRzY25U5sRjHIZ+4GesvmLCrJf0C9/RnOhW+wctqh5CNq9LdaN+ygTXjo9t87ecD7uCPp5gxdek2XP91PpU= X-Received: by 2002:a9d:738e:: with SMTP id j14-v6mr569677otk.248.1523537917201; Thu, 12 Apr 2018 05:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Thu, 12 Apr 2018 05:58:36 -0700 (PDT) In-Reply-To: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> From: Richard Barnes Date: Thu, 12 Apr 2018 08:58:36 -0400 Message-ID: To: Paul Wouters Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="0000000000005b5fed0569a65013" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 12:58:40 -0000 --0000000000005b5fed0569a65013 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: > On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > > I don't really agree with that characterization. To state my >> understanding, >> as responsible AD, of the status of this document: this document is in the >> RFC Editor's queue being processed. >> > > That was a process mistake. > > 1) ekr filed a DISCUSS > 2) other people raised issues in response > 3) ekr's DISCUSS was resolved but not the other people's concern > 4) document was placed in RFC Editor queue despite this > 5) TLS consensus call done on the list > 6) here we are.... > > I think it is not good to use this process as a way of approving things. > A process mistake was made. > The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor. Personally, I think the answer is no, and I'm not hearing clear consensus in either direction in this thread. So ISTM the best information the chairs and ADs have to go on is the hum taken in the room (which all of the litigants here participated in), which was pretty clearly in favor of proceeding. --Richard > > Paul > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005b5fed0569a65013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 11 Ap= r 2018, Benjamin Kaduk wrote:

I don't really agree with that characterization.=C2=A0 To state my unde= rstanding,
as responsible AD, of the status of this document: this document is in the<= br> RFC Editor's queue being processed.

 That was a process mistake.

1) ekr filed a DISCUSS
2) other people raised issues in response
3) ekr's DISCUSS was resolved but not the other people's concern 4) document was placed in RFC Editor queue despite this
5) TLS consensus call done on the list
6) here we are....

I think it is not good to use this process as a way of approving things. A process mistake was made.<= br>

The question Ben was aski= ng, though, is whether the impact of that process mistake is serious enough= to merit pulling back the doc from the RFC editor.

Personally, I think the answer is no, and I'm not hearing clear conse= nsus in either direction in this thread.=C2=A0 So ISTM the best information= the chairs and ADs have to go on is the hum taken in the room (which all o= f the litigants here participated in), which was pretty clearly in favor of= proceeding.

--Richard
=C2=A0

Paul


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

--0000000000005b5fed0569a65013-- From nobody Thu Apr 12 06:23:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14691271DF for ; Thu, 12 Apr 2018 06:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VOWIXYbKhSR for ; Thu, 12 Apr 2018 06:23:54 -0700 (PDT) Received: from esa4.dyson.c3s2.iphmx.com (esa4.dyson.c3s2.iphmx.com [68.232.139.183]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F7E127333 for ; Thu, 12 Apr 2018 06:23:51 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8859"; a="31512057" X-IronPort-AV: E=Sophos; i="5.48,441,1517875200"; d="scan'208,217"; a="31512057" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa4.dyson.c3s2.iphmx.com with ESMTP; 12 Apr 2018 14:23:47 +0100 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id EDC0FFA10; Thu, 12 Apr 2018 11:43:05 +0000 (GMT) Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id CD564FA02; Thu, 12 Apr 2018 11:43:05 +0000 (GMT) Received: from UK-MAL-CAS-04.dyson.global.corp (10.1.108.112) by UK-MAL-CAS-02.dyson.global.corp (10.1.108.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 12 Apr 2018 14:23:46 +0100 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-04.dyson.global.corp ([10.1.108.112]) with mapi id 14.03.0319.002; Thu, 12 Apr 2018 14:23:46 +0100 From: Tony Putman To: Richard Barnes CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt Thread-Index: AQHT0aURP8E25F81m0KNzl5SphxWl6P84Y0A Date: Thu, 12 Apr 2018 13:23:44 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1DBF718CUKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 13:23:57 -0000 --_000_140080C241BAA1419B58F093108F9EDC1DBF718CUKMALMBOX01dyso_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KSSB3b3JrIGluIHRoZSBJb1Qgc3BhY2UgYW5kIGFtIGludGVyZXN0ZWQg aW4gaGFuZHNoYWtlcyB0aGF0IGludm9sdmUgbGl0dGxlIGNvbXB1dGF0aW9uIGJ1dCBvZmZlciBi ZXR0ZXIgcHJvdGVjdGlvbiB0aGFuIHN5bW1ldHJpYyBQU0sgaW4gdGhlIGV2ZW50IG9mIHNlcnZl ciBicmVhY2guDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUmljaGFyZCBCYXJuZXMNClNlbnQ6IDExIEFwcmlsIDIwMTggMTU6NTQNCg0KW+KA pl0NCldlIHdvdWxkIGxvdmUgdG8gaGVhciBhbnkgZmVlZGJhY2sgb24gdGhlIGFwcHJvYWNoIHBy b3Bvc2VkIGhlcmUsIGFuZCBvbiB3aGV0aGVyIG90aGVyIHBlb3BsZSBoZXJlIHdvdWxkIGJlIGlu dGVyZXN0ZWQgaW4gd29ya2luZyBvbiBhIFBBS0UgbWVjaGFuaXNtIGZvciBUTFMgaW4gdGhpcyB3 b3JraW5nIGdyb3VwLg0KW+KApl0NCg0KSSB3YXMgaW50ZXJlc3RlZCBpbiB0aGlzIGRyYWZ0IGFz IGl0IHNlZW1lZCB0byB0aWNrIHNvbWUgYm94ZXMsIGFuZCBJIG9mZmVyIHNvbWUgY29tbWVudHMg YmVsb3cuIEJ1dCBpbiB0aGUgZW5kIEkgZG9uJ3QgdGhpbmsgaXQgb2ZmZXJzIHdoYXQgSSdtIGxv b2tpbmcgZm9yLCBzbyBJIGNhbid0IG9mZmVyIHRvIGhlbHAgd2l0aCBpdCBpbiBpdHMgY3VycmVu dCBmb3JtLg0KDQpNeSBtYWluIGNvbW1lbnQgaXMgdGhhdCBJIGRpc2FncmVlIHdpdGggdGhlIGFz c2VydGlvbiBpbiBzZWN0aW9uIDMgdGhhdCAidyIgaXMgZWZmZWN0aXZlbHkgYSBzYWx0ZWQgcGFz c3dvcmQgaGFzaC4gQW4gYXR0YWNrZXIgd2hvIG9idGFpbnMgInciIGNhbiBpbXBlcnNvbmF0ZSB0 aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIsIHNvIGl0IGlzIGVxdWl2YWxlbnQgdG8gYSBwYXNzd29y ZC4gVGhlIG9ubHkgYWR2YW50YWdlIGlzIHRoYXQgYSBzZXJ2ZXIgYnJlYWNoIGNhbm5vdCBiZSBl eHRlbmRlZCB0byBvdGhlciBzZXJ2ZXJzIHdoZXJlIHRoZSB1c2VyIHVzZXMgdGhlIHNhbWUgcGFz c3dvcmQsIGJ1dCBkaWZmZXJlbnQgc2FsdHMgYXJlIHVzZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQg U1BBS0UyKyBwcmV2ZW50cyB0aGlzLCBzbyBwZXJoYXBzIHRoaXMgc2hvdWxkIGJlIHVzZWQgaW5z dGVhZC4NCg0KU2Vjb25kbHksIFNQQUtFMiBpcyBmaXR0ZWQgdG8gdGhlIFRMUyAxLjMgaGFuZHNo YWtlIGJ5IGZvcmNpbmcgdGhlIGNsaWVudCB0byBrbm93IHRoZSBzYWx0LiBUaGlzIHNlZW1zIHVu cmVhc29uYWJsZSB0byBtZSB1bmxlc3MgdGhlcmUgaXMgYWxzbyBzb21lIG1lY2hhbmlzbSB0byBy ZXRyaWV2ZSB0aGUgc2FsdCBmcm9tIHRoZSBzZXJ2ZXIuIENvdWxkIHRoZSBzYWx0IGJlIGEgaGFz aCBvZiBjbGllbnQgaWRlbnRpdHkgYW5kIHNlcnZlciBpZGVudGl0eT8gKEkgc3VzcGVjdCB0aGVy ZSBpcyBub3QgZW5vdWdoIGVudHJvcHkgaW4gdGhpcykuIEJ1dCBpbiBhbnkgY2FzZSBJIHRoaW5r IHRoaXMgaXMgYW4gaXNzdWUgd2hpY2ggbXVzdCBiZSBhZGRyZXNzZWQgaW4gdGhlIGRyYWZ0Lg0K DQpXaHkgZG9lcyB0aGUgZHJhZnQgbmVlZCB0byBzcGVjaWZ5IHdoYXQgdGhlIGlkZW50aXR5IG9m IHRoZSBzZXJ2ZXIgaXM/IEl0IGRvZXNuJ3Qgc2VlbSB0byBiZSB1c2VkLg0KDQpXb3VsZCBpdCBi ZSBoZWxwZnVsIHRvIHNlbmQgYSBsaXN0IG9mIFNQQUtFMlNoYXJlcyBpbiBDbGllbnRIZWxsbz8g Rm9yIGV4YW1wbGUsIGlmIHRoZSBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBpcyBiZWluZyBu ZWdvdGlhdGVkLCB3b3VsZCBpdCBiZSBuZWNlc3NhcnkgdG8gc3VwcGx5IHNoYXJlcyBmb3IgbXVs dGlwbGUgcHJvdG9jb2xzPyBBbHRlcm5hdGl2ZWx5LCBpZiB0aGUgY2xpZW50IGFuZC9vciBzZXJ2 ZXIgc3VwcG9ydCBtdWx0aXBsZSBwcmUtcHJvdmlzaW9uZWQgdmFsdWVzIChHLCBNLCBOLCBIKSwg aG93IHdvdWxkIHRoaXMgYmUgc2lnbmFsbGVkL21hbmFnZWQ/IEFuZCB3b3VsZCB0aGVyZSBiZSBh c3NvY2lhdGVkIHNlY3VyaXR5IGNvbmNlcm5zPw0KDQpJdCBpcyB3b3J0aCBub3RpbmcgZXhwbGlj aXRseSBzb21ld2hlcmUgdGhhdCB4IGFuZCB5IHNob3VsZCBoYXZlIHRoZSBzYW1lIGVwaGVtZXJh bCBjaGFyYWN0ZXJpc3RpY3MgYXMgYXJlIHVzZWQgYnkgdGhlIGtleV9zaGFyZSBlbGVtZW50cywg YW5kIHRoYXQgaWYgdGhpcyBpcyBmb2xsb3dlZCB0aGVuIGZvcndhcmQgc2VjcmVjeSBpcyBwcm92 aWRlZCBieSBTUEFLRTIuDQoNCklNSE8gInciIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgUFNL IGlucHV0LiBJZiBzb21lYm9keSBnZXRzIGhvbGQgb2YgYSBkZXJpdmVkIGtleSAoZS5nLiBlYXJs eV9leHBvcnRlcl9tYXN0ZXJfc2VjcmV0KSB0aGVuIHRoZSBsb3cgZW50cm9weSBvZiAidyIgbWF5 IGFsbG93IGl0IHRvIGJlIHJlY292ZXJlZC4gIksiIHByb3ZpZGVzIGFsbCB0aGF0J3MgbmVlZGVk IGZvciBrZXkgZGVyaXZhdGlvbi4NCg0KVGhlIGRyYWZ0IHNob3VsZCByZWNvbW1lbmQgc29tZXdo ZXJlIChzZWN1cml0eSBzZWN0aW9uPykgdGhhdCBIIHNob3VsZCBiZSBzdWl0YWJsZSBmb3IgcGFz c3dvcmQgaGFzaGluZyAoZS5nLiBBcmdvbjIpIGFuZCBub3QgYSBzdGFuZGFyZCBoYXNoIGZ1bmN0 aW9uLiBUaGlzIGlzIHBhcnRpY3VsYXJseSB0cnVlIGlmIG15IGVhcmxpZXIgc3VnZ2VzdGlvbiB0 byB1c2UgU1BBS0UyKyBpcyBmb2xsb3dlZC4NCg0KUmVnYXJkcywNClRvbnkNCg0KCkR5c29uIFRl Y2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBudW1iZXIgMDE5NTkwOTAsIFRldGJ1cnkgSGlsbCwg TWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLgpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgaXQsIGFuZCBkbyBub3QgdXNlLCBjb3B5 IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG9y IGluIGFueSBhdHRhY2htZW50LgpEeXNvbiBtYXkgbW9uaXRvciBlbWFpbCB0cmFmZmljIGRhdGEg YW5kIGNvbnRlbnQgZm9yIHNlY3VyaXR5ICYgdHJhaW5pbmcuCg== --_000_140080C241BAA1419B58F093108F9EDC1DBF718CUKMALMBOX01dyso_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkhpIFJpY2hhcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg d29yayBpbiB0aGUgSW9UIHNwYWNlIGFuZCBhbSBpbnRlcmVzdGVkIGluIGhhbmRzaGFrZXMgdGhh dCBpbnZvbHZlIGxpdHRsZSBjb21wdXRhdGlvbiBidXQgb2ZmZXIgYmV0dGVyIHByb3RlY3Rpb24g dGhhbiBzeW1tZXRyaWMgUFNLIGluIHRoZSBldmVudCBvZiBzZXJ2ZXIgYnJlYWNoLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUTFMgW21h aWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljaGFyZCBC YXJuZXM8YnI+DQo8Yj5TZW50OjwvYj4gMTEgQXByaWwgMjAxOCAxNTo1NDxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W+KApl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIHdvdWxkIGxvdmUgdG8gaGVhciBhbnkgZmVlZGJhY2sgb24gdGhlIGFwcHJvYWNoIHByb3Bv c2VkIGhlcmUsIGFuZCBvbiB3aGV0aGVyIG90aGVyIHBlb3BsZSBoZXJlIHdvdWxkIGJlIGludGVy ZXN0ZWQgaW4gd29ya2luZyBvbiBhIFBBS0UgbWVjaGFuaXNtIGZvciBUTFMgaW4gdGhpcyB3b3Jr aW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W+KApl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHdhcyBpbnRlcmVz dGVkIGluIHRoaXMgZHJhZnQgYXMgaXQgc2VlbWVkIHRvIHRpY2sgc29tZSBib3hlcywgYW5kIEkg b2ZmZXIgc29tZSBjb21tZW50cyBiZWxvdy4gQnV0IGluIHRoZSBlbmQgSSBkb24ndCB0aGluayBp dCBvZmZlcnMgd2hhdCBJJ20gbG9va2luZyBmb3IsIHNvIEkgY2FuJ3Qgb2ZmZXINCiB0byBoZWxw IHdpdGggaXQgaW4gaXRzIGN1cnJlbnQgZm9ybS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPk15IG1haW4gY29tbWVudCBpcyB0aGF0IEkgZGlzYWdyZWUgd2l0aCB0aGUg YXNzZXJ0aW9uIGluIHNlY3Rpb24gMyB0aGF0ICZxdW90O3cmcXVvdDsgaXMgZWZmZWN0aXZlbHkg YSBzYWx0ZWQgcGFzc3dvcmQgaGFzaC4gQW4gYXR0YWNrZXIgd2hvIG9idGFpbnMgJnF1b3Q7dyZx dW90OyBjYW4gaW1wZXJzb25hdGUgdGhlIGNsaWVudA0KIHRvIHRoZSBzZXJ2ZXIsIHNvIGl0IGlz IGVxdWl2YWxlbnQgdG8gYSBwYXNzd29yZC4gVGhlIG9ubHkgYWR2YW50YWdlIGlzIHRoYXQgYSBz ZXJ2ZXIgYnJlYWNoIGNhbm5vdCBiZSBleHRlbmRlZCB0byBvdGhlciBzZXJ2ZXJzIHdoZXJlIHRo ZSB1c2VyIHVzZXMgdGhlIHNhbWUgcGFzc3dvcmQsIGJ1dCBkaWZmZXJlbnQgc2FsdHMgYXJlIHVz ZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQgU1BBS0UyJiM0MzsgcHJldmVudHMgdGhpcywgc28gcGVy aGFwcyB0aGlzDQogc2hvdWxkIGJlIHVzZWQgaW5zdGVhZC4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNlY29uZGx5LCBTUEFLRTIgaXMgZml0dGVkIHRvIHRoZSBUTFMg MS4zIGhhbmRzaGFrZSBieSBmb3JjaW5nIHRoZSBjbGllbnQgdG8ga25vdyB0aGUgc2FsdC4gVGhp cyBzZWVtcyB1bnJlYXNvbmFibGUgdG8gbWUgdW5sZXNzIHRoZXJlIGlzIGFsc28gc29tZSBtZWNo YW5pc20gdG8gcmV0cmlldmUNCiB0aGUgc2FsdCBmcm9tIHRoZSBzZXJ2ZXIuIENvdWxkIHRoZSBz YWx0IGJlIGEgaGFzaCBvZiBjbGllbnQgaWRlbnRpdHkgYW5kIHNlcnZlciBpZGVudGl0eT8gKEkg c3VzcGVjdCB0aGVyZSBpcyBub3QgZW5vdWdoIGVudHJvcHkgaW4gdGhpcykuIEJ1dCBpbiBhbnkg Y2FzZSBJIHRoaW5rIHRoaXMgaXMgYW4gaXNzdWUgd2hpY2ggbXVzdCBiZSBhZGRyZXNzZWQgaW4g dGhlIGRyYWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoeSBk b2VzIHRoZSBkcmFmdCBuZWVkIHRvIHNwZWNpZnkgd2hhdCB0aGUgaWRlbnRpdHkgb2YgdGhlIHNl cnZlciBpcz8gSXQgZG9lc24ndCBzZWVtIHRvIGJlIHVzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+V291bGQgaXQgYmUgaGVscGZ1bCB0byBzZW5kIGEgbGlzdCBv ZiBTUEFLRTJTaGFyZXMgaW4gQ2xpZW50SGVsbG8/IEZvciBleGFtcGxlLCBpZiB0aGUgYXBwbGlj YXRpb24gbGF5ZXIgcHJvdG9jb2wgaXMgYmVpbmcgbmVnb3RpYXRlZCwgd291bGQgaXQgYmUgbmVj ZXNzYXJ5IHRvIHN1cHBseSBzaGFyZXMNCiBmb3IgbXVsdGlwbGUgcHJvdG9jb2xzPyBBbHRlcm5h dGl2ZWx5LCBpZiB0aGUgY2xpZW50IGFuZC9vciBzZXJ2ZXIgc3VwcG9ydCBtdWx0aXBsZSBwcmUt cHJvdmlzaW9uZWQgdmFsdWVzIChHLCBNLCBOLCBIKSwgaG93IHdvdWxkIHRoaXMgYmUgc2lnbmFs bGVkL21hbmFnZWQ/IEFuZCB3b3VsZCB0aGVyZSBiZSBhc3NvY2lhdGVkIHNlY3VyaXR5IGNvbmNl cm5zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBpcyB3b3J0aCBu b3RpbmcgZXhwbGljaXRseSBzb21ld2hlcmUgdGhhdCB4IGFuZCB5IHNob3VsZCBoYXZlIHRoZSBz YW1lIGVwaGVtZXJhbCBjaGFyYWN0ZXJpc3RpY3MgYXMgYXJlIHVzZWQgYnkgdGhlIGtleV9zaGFy ZSBlbGVtZW50cywgYW5kIHRoYXQgaWYgdGhpcyBpcyBmb2xsb3dlZCB0aGVuDQogZm9yd2FyZCBz ZWNyZWN5IGlzIHByb3ZpZGVkIGJ5IFNQQUtFMi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPklNSE8gJnF1b3Q7dyZxdW90OyBzaG91bGQgbm90IGJlIHVzZWQgYXMgdGhl IFBTSyBpbnB1dC4gSWYgc29tZWJvZHkgZ2V0cyBob2xkIG9mIGEgZGVyaXZlZCBrZXkgKGUuZy4g ZWFybHlfZXhwb3J0ZXJfbWFzdGVyX3NlY3JldCkgdGhlbiB0aGUgbG93IGVudHJvcHkgb2YgJnF1 b3Q7dyZxdW90OyBtYXkgYWxsb3cgaXQgdG8gYmUgcmVjb3ZlcmVkLg0KICZxdW90O0smcXVvdDsg cHJvdmlkZXMgYWxsIHRoYXQncyBuZWVkZWQgZm9yIGtleSBkZXJpdmF0aW9uLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIGRyYWZ0IHNob3VsZCByZWNvbW1lbmQg c29tZXdoZXJlIChzZWN1cml0eSBzZWN0aW9uPykgdGhhdCBIIHNob3VsZCBiZSBzdWl0YWJsZSBm b3IgcGFzc3dvcmQgaGFzaGluZyAoZS5nLiBBcmdvbjIpIGFuZCBub3QgYSBzdGFuZGFyZCBoYXNo IGZ1bmN0aW9uLiBUaGlzIGlzIHBhcnRpY3VsYXJseQ0KIHRydWUgaWYgbXkgZWFybGllciBzdWdn ZXN0aW9uIHRvIHVzZSBTUEFLRTImIzQzOyBpcyBmb2xsb3dlZC4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ub255PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyI+DQpEeXNvbiBUZWNo bm9sb2d5IExpbWl0ZWQsIGNvbXBhbnkgbnVtYmVyIDAxOTU5MDkwLCBUZXRidXJ5IEhpbGwsIE1h bG1lc2J1cnksIFNOMTYgMFJQLCBVSy4NCjxicj4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVh c2UgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBpdCwgYW5kIGRvIG5vdCB1c2Us IGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2Ugb3IgaW4gYW55IGF0dGFjaG1lbnQuDQo8YnI+DQpEeXNvbiBtYXkgbW9uaXRvciBlbWFpbCB0 cmFmZmljIGRhdGEgYW5kIGNvbnRlbnQgZm9yIHNlY3VyaXR5ICZhbXA7IHRyYWluaW5nLg0KPC9z cGFuPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_140080C241BAA1419B58F093108F9EDC1DBF718CUKMALMBOX01dyso_-- From nobody Thu Apr 12 06:47:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85863124BE8 for ; Thu, 12 Apr 2018 06:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF-dvqtuHr1P for ; Thu, 12 Apr 2018 06:46:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5677126CE8 for ; Thu, 12 Apr 2018 06:46:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40MMdm70Z2z1HN; Thu, 12 Apr 2018 15:46:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523540813; bh=t0PEFZ3U0bwe+OwT8v3izLk5eLgvs4leKELeRHpcDNI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CazcVSauLCKmoefzVpvgZdZIwDOjDyD5I6noKDB4hCwH2WzYFg+CyABFPGEHKORTx jup+6UAaigrFWA7rpNG+UKEFnDm77Mu8XmnmKOiD7GH05TQVyQuoFvPS2EftamzgLm 2JkqrjUgaoXPokYHSL8EDtMhJ7zV/EDHgc+41mmw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id F0qal-m4ba68; Thu, 12 Apr 2018 15:46:50 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 12 Apr 2018 15:46:49 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC6FC30B3EA; Thu, 12 Apr 2018 09:46:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DC6FC30B3EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D29B7400169C; Thu, 12 Apr 2018 09:46:48 -0400 (EDT) Date: Thu, 12 Apr 2018 09:46:48 -0400 (EDT) From: Paul Wouters To: Richard Barnes cc: Benjamin Kaduk , "" In-Reply-To: Message-ID: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:46:58 -0000 On Thu, 12 Apr 2018, Richard Barnes wrote: > The question Ben was asking, though, is whether the impact of that process mistake is serious enough to merit pulling back the doc from the RFC editor. That can only be answered after the consensus call. I don't think anyone is really objecting as long as the document isn't forwarded to publication without completing the current discussion. > Personally, I think the answer is no, and I'm not hearing clear consensus in either direction in this thread.  So ISTM the best information the chairs and ADs have to go on is the hum > taken in the room (which all of the litigants here participated in), which was pretty clearly in favor of proceeding. Again, from a process point of view, we do work on the lists. Humms can be used to gage the room on what direction to suggest to the WG, but all those actions are confirmed on their respective lists. In this case, both Viktor and I believe the room was not sufficiently aware of the issues raised. And I believe it was a good call for the IESG to move this discussion back onto the list. It would be odd to then take that hum back into account again for the consensus call on the list. Paul From nobody Thu Apr 12 06:49:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B58127333 for ; Thu, 12 Apr 2018 06:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 G5rpjANPi_UG for ; Thu, 12 Apr 2018 06:49:23 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED1D124BE8 for ; Thu, 12 Apr 2018 06:49:23 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 71-v6so5171511oie.12 for ; Thu, 12 Apr 2018 06:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+PXtSoaktZdUbLv/u6xp8c8aGGyIFfw7FYFFIzyx/Zc=; b=fzCsFcpEg637RHFolixQErt1F7LpgfhCi9Q8RynjZZUXZb59yfCQWML4zRv+whIB5X aWlnMxd7duCbMRtpCKHrUre3/hlme+UnuZmnrq7g1InEV07ZJWLAC5AY4VJkyusPCror J7asM3BgiaInHSmo0hrg7L1c6DgmgTSvA70HqJnkdETDLr2XvjQSOOrjx/gfoKtNNG1w zTo7ZJXCRFpgW8JTY8I7G/rwFxYTQdnZANkfkr7QCa4VAeozvurn8NxA25iSiJSGEYlD AlBly2e1FeSogNbgQtAu8to9bHirO5zfql3v/Iv9OcYz3/jIiCsV+N04je3fAaL4QrkZ ZgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+PXtSoaktZdUbLv/u6xp8c8aGGyIFfw7FYFFIzyx/Zc=; b=EJ+uon7TfjLK/Qtneb+gpoJAW47jO2DCuRTIHx2jy4HpbEgs4U/q2D95voujniAb41 6aWL+xyIv/8iqf1dwvJ7cqKrLA8x+zOT8ldeX8ZLxwxWt18tKzHod6u63AXwfRm1WH+u h2TdJcWTroPFJ8sg/IuMhtwA92Tx5FUr1MtyirAwOoKHzx1dz+TKHKCTtPxZk5OnYMb0 msRsvYoo1S6m1X9fU92Duc4vJvm/pX5d8GdhMaFHmYT8wb72bByjC8aMsqPsalNf2WFj XJ92qOieTEBTBGjvbBWzt6MI7OkoCtQDfjYZN/DG32yymDuIzrtur8raRlVNdmboeebx Tjfg== X-Gm-Message-State: ALQs6tDvYneBVrbpD1+qtAPjtUiK6C5QyQVfZTuAhVu8wYalk8NdON0O vHYY2I8mzVpemroWCN9haGBhiaILbJuXJqWnQYwE6w== X-Google-Smtp-Source: AIpwx4/McQX2RBiFogeyuNGL5pfMzbgzZeNyMywoU768DiXFO/yqW3qrU/LMHmEMIMuG0QtVJZG4znLOmeTTERUrmO8= X-Received: by 2002:aca:5c05:: with SMTP id q5-v6mr5414320oib.77.1523540963083; Thu, 12 Apr 2018 06:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Thu, 12 Apr 2018 06:49:22 -0700 (PDT) In-Reply-To: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> From: Richard Barnes Date: Thu, 12 Apr 2018 09:49:22 -0400 Message-ID: To: Paul Wouters Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="000000000000e7dbc80569a7054d" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:49:26 -0000 --000000000000e7dbc80569a7054d Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters wrote: > On Thu, 12 Apr 2018, Richard Barnes wrote: > > The question Ben was asking, though, is whether the impact of that process >> mistake is serious enough to merit pulling back the doc from the RFC editor. >> > > That can only be answered after the consensus call. I don't think anyone > is really objecting as long as the document isn't forwarded to publication > without completing the current discussion. > > Personally, I think the answer is no, and I'm not hearing clear consensus >> in either direction in this thread. So ISTM the best information the >> chairs and ADs have to go on is the hum >> taken in the room (which all of the litigants here participated in), >> which was pretty clearly in favor of proceeding. >> > > Again, from a process point of view, we do work on the lists. It seems noteworthy, however, that nobody is chiming in on the list who was not also part of the discussion in the room. That seems to me to indicate that their views were already heard and taken into account in the in-person discussion. --Richard > Humms can > be used to gage the room on what direction to suggest to the WG, but > all those actions are confirmed on their respective lists. > > In this case, both Viktor and I believe the room was not sufficiently > aware of the issues raised. And I believe it was a good call for the > IESG to move this discussion back onto the list. It would be odd to > then take that hum back into account again for the consensus call on > the list. > > Paul > --000000000000e7dbc80569a7054d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 12 Ap= r 2018, Richard Barnes wrote:

The question Ben was asking, though, is whether the impact of that process = mistake is serious enough to merit pulling back the doc from the RFC editor= .

 That can only be answered after the consensus call. I don't think anyon= e
is really objecting as long as the document isn't forwarded to publicat= ion
without completing the current discussion.

Personally, I think the answer is no, and I'm not hearing clear consens= us in either direction in this thread.=C2=A0 So ISTM the best information t= he chairs and ADs have to go on is the hum
taken in the room (which all of the litigants here participated in), which = was pretty clearly in favor of proceeding.

 Again, from a process point of view, we do work on the lists.
=

It seems noteworthy, however, that nobody is chiming in= on the list who was not also part of the discussion in the room.=C2=A0 Tha= t seems to me to indicate that their views were already heard and taken int= o account in the in-person discussion.

--Richard

=C2=A0
Humm= s can
be used to gage the room on what direction to suggest to the WG, but
all those actions are confirmed on their respective lists.

In this case, both Viktor and I believe the room was not sufficiently
aware of the issues raised. And I believe it was a good call for the
IESG to move this discussion back onto the list. It would be odd to
then take that hum back into account again for the consensus call on
the list.

Paul

--000000000000e7dbc80569a7054d-- From nobody Thu Apr 12 06:51:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF64127136 for ; Thu, 12 Apr 2018 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sUK2OzCRbFM for ; Thu, 12 Apr 2018 06:51:01 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D211124BE8 for ; Thu, 12 Apr 2018 06:51:01 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q80so6356439ioi.13 for ; Thu, 12 Apr 2018 06:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6T1OwoUuYG7LulCGxzt/QnowGbFvh7r/0N/91eJTYU8=; b=XSrQ/FkWvGE4DXkEgq43phZ647BLhw01ltTDBi2t5ALY4cHOQzfus0WGE/UuDUvmze SL6OYjFi9bt3wS2GRfEqZKDxM3tbJwIG4K4uBAAh0jQr0c7kKZmqamgSi99vdtjAsBsT cWPrZ6wP47ZFHqBYPGPU0n+XYqE5ZkEkxkJBU67wZXAysTTki16VlaRzl+foiyeppilq 1p1jyEx19YPCC44VWJD8HvE7FToidQBAVCcyBPncJgW9f+iGa1fyIbQSe95zOu9hM0Jm 5zSAjuj4bn6AfM6Zkg7Czdeq9jBNSV4rp3hg1RHJtLzYsydABmq/JTTNyIzBswxwh8h0 DLQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6T1OwoUuYG7LulCGxzt/QnowGbFvh7r/0N/91eJTYU8=; b=Iy9qIczXLVjk+Eoje9HDHxZgcytS9pdnUpIiS+QhOyNZJCGZAsXMgZzuj2X83M3UYb rwmei8MyMhFCB+ct6pUYQ6WSBG17/R7CXTfEIF014Sy1QIfAF9F10M7d3Lsme5ReiwcS x0aHhEu8kbCxIGjjpQzrpBTRmayj+3LVBk8taANqtDTCE88mM7yGOWTuqZdUhjn285KB vtyRBtR44mNjJP5SlQbMhKQQmvB5iokAijjisX/Gf/EFgLU1BjwmUkwmBQ/lXnoY+ZUc H2BuHJlk50/t36zMxP7+en7f6zj5QnvKEU0m8OfIVxJRfkToF+LUOgtkrhw508jGCJzi gAjA== X-Gm-Message-State: ALQs6tDf6iwk5xLQd9+tRtk5xpZ/C5EEJE3I13KSoxHN07C3BfWY+/H6 m6Bz7MNvg1qzunOZ0VL3Tr77BTENmJ2v+4YOI2o= X-Google-Smtp-Source: AIpwx49Kslatpv2kHQYpbScYfljLrzLLU/j2dR3YWKv/fU9EKpwVld9uUHEe93pv0zgE5fL9u6Agcw/f/mpC2o/MXjQ= X-Received: by 10.107.18.162 with SMTP id 34mr8951785ios.168.1523541060320; Thu, 12 Apr 2018 06:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.188.16 with HTTP; Thu, 12 Apr 2018 06:50:20 -0700 (PDT) In-Reply-To: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> From: Kathleen Moriarty Date: Thu, 12 Apr 2018 09:50:20 -0400 Message-ID: To: Richard Barnes Cc: Paul Wouters , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 13:51:03 -0000 There's a few steps Paul is missing in his summary of the process. On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote: > > > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: >> >> On Wed, 11 Apr 2018, Benjamin Kaduk wrote: >> >>> I don't really agree with that characterization. To state my >>> understanding, >>> as responsible AD, of the status of this document: this document is in >>> the >>> RFC Editor's queue being processed. >> >> >> That was a process mistake. >> >> 1) ekr filed a DISCUSS >> 2) other people raised issues in response >> 3) ekr's DISCUSS was resolved but not the other people's concern The concerns were discussed at the meeting in London. The chairs reviewed 3 separate issues. The first was agreed upon that a simple wording change that was not significant to hold up for approval was made. No change was needed with one of the other issues. With the third, the room was in full agreement that this should be done in a separate draft. I went to the mic and summarized this and asked for agreement that it was ok to approve the document as a result and there was no opposition, just agreement. It was right of the chairs to put this back out to the list for confirmation as they have the ability to pull a document back if they decide that is the right course of action. The AD can also override the chairs if they decide it should go forward and the AD does not agree (although I don't see that in his messages). Best regards, Kathleen >> 4) document was placed in RFC Editor queue despite this >> 5) TLS consensus call done on the list >> 6) here we are.... >> >> I think it is not good to use this process as a way of approving things. >> A process mistake was made. > > > The question Ben was asking, though, is whether the impact of that process > mistake is serious enough to merit pulling back the doc from the RFC editor. > > Personally, I think the answer is no, and I'm not hearing clear consensus in > either direction in this thread. So ISTM the best information the chairs > and ADs have to go on is the hum taken in the room (which all of the > litigants here participated in), which was pretty clearly in favor of > proceeding. > > --Richard > >> >> >> Paul >> >> >> _______________________________________________ >> 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 From nobody Thu Apr 12 07:06:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9759C12D775 for ; Thu, 12 Apr 2018 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyzBX8TQp0Lw for ; Thu, 12 Apr 2018 07:06:10 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB3812D0C3 for ; Thu, 12 Apr 2018 07:06:10 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id l16so5217203qke.13 for ; Thu, 12 Apr 2018 07:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=8FklEk1LOr2A5XZKsIOdiNdz80+GgPkMd8MLFLUx44A=; b=lVdKtyfHeu17JxZZnsegziiXuBdzk/jxycN8+SEXDaIY3xE2fgg57skTidd+ZC3RbS tbFICZeqJI/QuAT/Xhu6Cf1vgjpCmy2CTNbx3IBG3Hyh1iGGu+9n4bd75B6T/Fj1f/tt FWo87/QLXqXrt0vDSthEGb68B5bJDlGW8nRus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=8FklEk1LOr2A5XZKsIOdiNdz80+GgPkMd8MLFLUx44A=; b=WtPAQ4dmveypoIdX6ZaNOxaBwXjOcwiyS90TONIdmYV716n2dz8nR8Gke8vxJuWpDe 8Ltu3MvwmnYCEesLs/rsj/2GHO4SXXeIKjkP1daIdc2m6GUrmPDC+5DX/s7M1DoJlRbZ qdG95BD+/pFl4QzflKn7yNJrSyjYrqoin96SbCU44+Re9KCT78ItqsjyK9P0/uVpY2fs ZZggQKR+Fr5NtuH6OtBJQ+BLTayrwxoFo1DOvT6fOboOCQIf4GDG6B+wQw/h0s3kMt12 UBpwKSntAniFfg10NdHeqiMmSPP8jjSVY76wS7eWT0jhz1OAni1k+X7upKBQ+aqmZFZh JNyQ== X-Gm-Message-State: ALQs6tBu9s9OPrVyvi3SeiDMD29WbHsC05/DN1ubsgOavyY2fy46y12U 0HsL8jODtEypm5t7wZc6xvELSknB6lI= X-Google-Smtp-Source: AIpwx49wb2944hxvEWY/SJMj8HQ6J9WfLDpuSBmRZnUbkbLLp5P5iEUTOEHjP4Ov3OcxOfQVbpS2QQ== X-Received: by 10.55.99.88 with SMTP id x85mr1385299qkb.142.1523541969364; Thu, 12 Apr 2018 07:06:09 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id q3sm2713502qke.93.2018.04.12.07.06.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 07:06:08 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Thu, 12 Apr 2018 10:06:07 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] TLS and DTLS now on well-known RFC editor abbreviations list X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 14:06:12 -0000 I requested that the RFC editor add TLS and DTLS to their list of = well-known abbreviations [0]. They agreed so now draft editors are free = to expand (or not) TLS and DTLS in drafts. Note that the RFC editor = also added SSL and SSL/TLS to the list. spt [0] https://www.rfc-editor.org/materials/abbrev.expansion.txt= From nobody Thu Apr 12 10:54:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A57126DED for ; Thu, 12 Apr 2018 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UeEtqom36NmO for ; Thu, 12 Apr 2018 10:54:45 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85901276AF for ; Thu, 12 Apr 2018 10:54:45 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3CHrFtG006977; Thu, 12 Apr 2018 18:54:44 +0100 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=j7zQ+FjhyopzPk24EUy6+VmtdcrakEVIPtUIayliDi0=; b=YdwVpBtlRG0BYUWIhyKSvwv7jT3/+Vaxs8Kqh+8f7Vgc6zasoRHkTQYMXZ0J85bJpFPg kbSbS37MiHuGkvLIqn18bYxLuXD+T7I4JSE+an3L3fZQn61i35JwkaREeiGU8Epc72fj b/0LXp8Hnhymlnldq+d0m+byS7NBuZY01yFKKXGSSSTCYitdYQsUs32he2HklwtpiOeC iIzvGeCLXBCwhMeYa07d+1FgIH4M0JgvAYm2aXfze1o+VnphqIXiqwT8OOSyiFbua32t wTy8rQKpykCPu+reCehcsp2yuaJQ8BBEMccWmnn9WR+WM93X1E84r9ySodwOI3vbjDjx fA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2ha52j99c9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Apr 2018 18:54:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3CHp4pT012702; Thu, 12 Apr 2018 13:54:43 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2h6savvn1f-1; Thu, 12 Apr 2018 13:54:42 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id DEBA582F7D; Thu, 12 Apr 2018 17:54:42 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1f6gQk-0000Ae-08; Thu, 12 Apr 2018 12:54:42 -0500 Date: Thu, 12 Apr 2018 12:54:41 -0500 From: Benjamin Kaduk To: Kathleen Moriarty Cc: Richard Barnes , "" Message-ID: <20180412175441.GD20782@akamai.com> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@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=2018-04-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120175 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804120175 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 17:54:48 -0000 On Thu, Apr 12, 2018 at 09:50:20AM -0400, Kathleen Moriarty wrote: > There's a few steps Paul is missing in his summary of the process. > > On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote: > > > > > > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote: > >> > >> On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > >> > >>> I don't really agree with that characterization. To state my > >>> understanding, > >>> as responsible AD, of the status of this document: this document is in > >>> the > >>> RFC Editor's queue being processed. > >> > >> > >> That was a process mistake. > >> > >> 1) ekr filed a DISCUSS > >> 2) other people raised issues in response > >> 3) ekr's DISCUSS was resolved but not the other people's concern > > The concerns were discussed at the meeting in London. The chairs > reviewed 3 separate issues. The first was agreed upon that a simple > wording change that was not significant to hold up for approval was > made. No change was needed with one of the other issues. With the > third, the room was in full agreement that this should be done in a > separate draft. I went to the mic and summarized this and asked for > agreement that it was ok to approve the document as a result and there > was no opposition, just agreement. It's also worth noting that Ekr explicitly disavowed the other concerns as outside the range of his DISCUSS (https://www.ietf.org/mail-archive/web/tls/current/msg25536.html), and the entire IESG had plenty of opportunities to indicate support for these other concerns as being DISCUSS-worthy, but none did so. > It was right of the chairs to put this back out to the list for > confirmation as they have the ability to pull a document back if they > decide that is the right course of action. > > The AD can also override the chairs if they decide it should go > forward and the AD does not agree (although I don't see that in his > messages). I'm waiting to see if anything else comes out of this thread. In particular, I am hoping that some authors/proponents of leaving the document in the RFC Editor queue would speak to the question of the target scope, given the arguments that have been presented regarding the risk/reward tradeoff of the current narrow scope. -Ben From nobody Thu Apr 12 11:20:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F1F129C6C for ; Thu, 12 Apr 2018 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ7WY1m8npvM for ; Thu, 12 Apr 2018 11:20:25 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 DE0CA126DED for ; Thu, 12 Apr 2018 11:20:24 -0700 (PDT) Received: from [192.168.1.214] (happus.xs4all.nl [82.95.141.127]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E11C88AA7; Thu, 12 Apr 2018 20:20:22 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1523557222; bh=9afQagqi9OoSAIxmNvayZXrVSblrwhHD08Zsg+JnxbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PeeTnteop7rapGUbL5dYQr9GvPK3ieMAqwhQpP8Q7KKl3lt/FxBZgF1NdJq1aHyVz l7r7kVyiydqGQ17cj1ej8QdmSs3R56qgIC+//Furiqw3Ninzwb+oHT2bvCm05BhjJT rF39+HyjsMvPT944SyXuDAPros/z+0+AlJ9sjHi0= To: Paul Wouters Cc: "" References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> From: Willem Toorop Message-ID: <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl> Date: Thu, 12 Apr 2018 20:20:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:20:27 -0000 Sorry for being confusing. I meant to say full Denial of Existing is in the draft implicitly already (because of the reference to DANE authentication according to RFC6698 and RFC7671 (which do mention it) in Section 6). I do like the idea of STS for this extension (and augment it with the more restrictive DANE use cases), but I'm unsure about the security of a built-in version. I notice that existing STS documents (HSTS [RFC6797] and MTA-STS [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL conveyed in a ServerHello message secure when it would be just for SSL? I can see this might be different for the DANE use case because of the signed statements that come alongside the TTL, but for example... In case of built-in STS with the extension, what does a 0 TTL mean? - When 0 has been the only value seen ever, it is clear to me that the mechanism is equivalent with what we have in the draft now, but.. - When another value has been seen before, is a value of 0 then enough to clear the pin? Or would a DoE proof (or insecurity proof) alongside it be necessary? In case of the latter, what does that mean for sites that do have DANE records, but no servers that support the extension? Can they be hampered (for an indefinite period) by a MiTM? That would be really bad for DANE deployment. Op 10-04-18 om 17:22 schreef Paul Wouters: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misconception in Willem's statement. See my > previous emails to thist list for my full arguments on this issue. > >> The chain extension already contains verification of Denial Of Existence >> proofs, because that is needed for verifying wildcard expansions. > > This might confuse people. I am talking about denial of existence of any > TLSA record. You are talking about proof of non-existance of other TLSA > records besides the one you are returning. These are completely > different issues. I just want to ensure people realise when I said we > need proof of non-existence, that people do not read your line "already > contains this" as me being wrong. > > >> It does not explicitly mention the fallback to non-PKIX with a Denial of >> Existence proof or insecurity proof for the TLSA record, because it is >> (currently) irrelevant when the extension could simply be left out too. > > So that's not one bug, but two bugs. Defining them out of scope is not > what we should do. For instance, the document could already assume that > the proof of TLS extension (pinning) is going to be solved elsewhere, > and therefor a full denial of existence proof in this document would be > valuable. > > The document does not specify what to do when it does not find a TLSA > record to include. It does state: > >     If the server is configured for DANE >    authentication, then it performs the appropriate DNS queries, builds >    the authentication chain, and returns it to the client. > > So if the server is configured for DANE, and it only finds denial of > existence proofs of its own TLSA record, what is the expected behaviour? > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. > > Paul From nobody Thu Apr 12 11:32:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DC12DA0D; Thu, 12 Apr 2018 11:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aNzPjqshuLH5; Thu, 12 Apr 2018 11:32:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB08126DED; Thu, 12 Apr 2018 11:32:12 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AA9DC7A3309; Thu, 12 Apr 2018 18:32:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 14:32:10 -0400 Cc: dane@ietf.org Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:32:15 -0000 > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: >=20 > If the answer to 1) is no then please indicate if you think the = working group should work on the document to include=20 >=20 > A) Recommendation of adding denial of existence proofs in the chain = provided by the extension > B) Adding signaling to require the use of this extension for a period = of time (Pinning with TTL) > C) Both While I am a vocal supporter of (C), I'd like to take a moment to = explain why AT LEAST (A) is needed. * The present text requires (Section 3.4) that the server's response present a validated TLSA RRset: The first RRset in the chain MUST contain the TLSA record set being presented * The present text (Section 8) says: Green field applications that are designed to always employ = this extension, could of course unconditionally mandate its use. Therefore such "green field" applications (presumably some of the ones ready to implement now) effectively mandate DNSSEC and TLSA records at the server, NOT JUST support for the extension. This needlessly limits the usability of such applications. The server domain cannot continue to support the extension and interoperate with the client if it at some points decides to stop publishing TLSA records or perhaps even stop using DNSSEC. It makes a lot more sense for servers to be able to continue to support the extension, but respond with denial of existence when when the have no TLSA records or the zone is unsigned (no DS RRs at some ancestor). That way a server can communicate its change of status to a client, which may *then* be willing to accept alternative authentication (WebPKI, for example). Option (A) does not change the wire formats, it just relaxes the requirement to provide TLSA records, and would allow or encourage the server to return whatever is the truth about its TLSA records (presense, absence or unsigned zone). The client can then act accordingly. Just (A) would of course still many clients in the dark about when it might be safe to "mandate" the extension for particular domains, and I'd be sad about that (if anyone cares :-), but it is important to realize that not doing (A) is a significant omission. I'd like to encourage the authors and WG to amend the draft to relax section 3.4 to allow (and encourage when applicable) denial of existence replies. This would better serve the "green field" applications that would like to avail themselves of this extension and require it of all servers, whether they have DNSSEC and TLSA records or not. --=20 Viktor. From nobody Thu Apr 12 11:45:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D389012DA0D; Thu, 12 Apr 2018 11:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpa-gtMemx53; Thu, 12 Apr 2018 11:44:54 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83829126DED; Thu, 12 Apr 2018 11:44:54 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id w3CIiqah030722; Thu, 12 Apr 2018 11:44:52 -0700 Message-Id: <201804121844.w3CIiqah030722@new.toad.com> To: TLS WG cc: dane@ietf.org In-reply-to: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> References: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 12 Apr 2018 14:32:10 -0400." Date: Thu, 12 Apr 2018 11:44:52 -0700 From: John Gilmore Archived-At: Subject: Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:44:56 -0000 > * The present text (Section 8) says: > > Green field applications that are designed to always employ this > extension, could of course unconditionally mandate its use. > > Therefore such "green field" applications (presumably some of the ones > ready to implement now) effectively mandate DNSSEC and TLSA records > at the server, NOT JUST support for the extension. Viktor, I believe you have confused a "could" with a "mandate". The text of this RFC does not require future green field applications to mandate the use of this exension. It merely allows them to do so. None need ever do so. If any ever did, the future RFC could specify how servers which do not have validated TLSA records should handle the situation. Different future protocols might choose different ways to handle this (e.g. don't send the extension at all; or send a validated denial; or send some kind of flag saying that the server doesn't even have a validated denial because it isn't using DNS or because some domain on its path to the DNS root isn't doing DNSSEC or isn't using NSECx records). Please, let this RFC go, rather than requiring that this committee first insert into it a paper spec for what some future protocol should do, without even knowing what the future protocol is. John From nobody Thu Apr 12 11:45:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858D212E042 for ; Thu, 12 Apr 2018 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kH01MBgA-01q for ; Thu, 12 Apr 2018 11:45:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D5212E8A9 for ; Thu, 12 Apr 2018 11:45:04 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B14757A3309 for ; Thu, 12 Apr 2018 18:45:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl> Date: Thu, 12 Apr 2018 14:45:02 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <5B17C75E-5CB7-4A18-B288-AC4728824FFB@dukhovni.org> References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:45:21 -0000 > On Apr 12, 2018, at 2:20 PM, Willem Toorop wrote: > > I notice that existing STS documents (HSTS [RFC6797] and MTA-STS > [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL > conveyed in a ServerHello message secure when it would be just for SSL? The reason for that of course is that those "STS-flavours" are commitments to do TLS vs plaintext, and so can't presume TLS as a transport. The question being settled is whether the peer does TLS or not. > I can see this might be different for the DANE use case because of the > signed statements that come alongside the TTL, but for example... Here the issue not whether TLS is supported, but whether the TLS support includes support for this extension, and so TLS as a transport is both natural and simultaneously supports all relevant applications, rather than having to add per-application mechanisms. > In case of built-in STS with the extension, what does a 0 TTL mean? > > - When 0 has been the only value seen ever, it is clear to me that the > mechanism is equivalent with what we have in the draft now, but.. Yes. Don't pin, we're not promising ongoing support for the extension. > > - When another value has been seen before, is a value of 0 then enough > to clear the pin? Or would a DoE proof (or insecurity proof) > alongside it be necessary? > > In case of the latter, what does that mean for sites that do have > DANE records, but no servers that support the extension? Can they > be hampered (for an indefinite period) by a MiTM? That would be > really bad for DANE deployment. * Positive TTL values require TLSA records, denial of existence should not be able to set a positive value. * Once a positive TTL is in effect it can only be set back to 0 in one of two ways: 1. Along with TLSA records that authenticate the handshake. (possibly limited to PKIX-EE/TA per application profile) 2. Along with DNSSEC-authenticated denial of existence of said TLSA records or of zone security. That is downgrades to not pinning require more than a mis-issued WebPKI certs. The domain should either prove non-existence of signed TLSA RRs, or signal a 0 TTL along with valid TLSA RRs that match the cert chain. You can think of the above as an initial draft of the text for option (C). -- Viktor. From nobody Thu Apr 12 11:46:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D212DA09 for ; Thu, 12 Apr 2018 11:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 YsO8RyVTtJou for ; Thu, 12 Apr 2018 11:46:33 -0700 (PDT) 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 22DD9126DED for ; Thu, 12 Apr 2018 11:46:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id DA67D53CB4; Thu, 12 Apr 2018 21:46:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id VuzaAJPoWeMq; Thu, 12 Apr 2018 21:46:30 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (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 6BAE727F; Thu, 12 Apr 2018 21:46:27 +0300 (EEST) Date: Thu, 12 Apr 2018 21:46:27 +0300 From: Ilari Liusvaara To: Willem Toorop Cc: Paul Wouters , "" Message-ID: <20180412184627.GA22922@LK-Perkele-VII> References: <47ba1f3b-5fed-47b6-8701-e12dd2d473f4@nlnetlabs.nl> <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <823877a3-9e51-bcdb-e43f-4313130aff4e@nlnetlabs.nl> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:46:36 -0000 On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote: > Sorry for being confusing. I meant to say full Denial of Existing is in > the draft implicitly already (because of the reference to DANE > authentication according to RFC6698 and RFC7671 (which do mention it) in > Section 6). > > > I do like the idea of STS for this extension (and augment it with the > more restrictive DANE use cases), but I'm unsure about the security of a > built-in version. > > I notice that existing STS documents (HSTS [RFC6797] and MTA-STS > [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL > conveyed in a ServerHello message secure when it would be just for SSL? One has to wait for the handshake to complete for most cases (basically all except the "clear pins with DoE" case). > I can see this might be different for the DANE use case because of the > signed statements that come alongside the TTL, but for example... > In case of built-in STS with the extension, what does a 0 TTL mean? > > - When 0 has been the only value seen ever, it is clear to me that the > mechanism is equivalent with what we have in the draft now, but.. > > - When another value has been seen before, is a value of 0 then enough > to clear the pin? Or would a DoE proof (or insecurity proof) > alongside it be necessary? The way I understand it would work, it would clear the pin at end of handshake (one could clear immediately on DoE, but maybe better to delay that too). > In case of the latter, what does that mean for sites that do have > DANE records, but no servers that support the extension? Can they > be hampered (for an indefinite period) by a MiTM? That would be > really bad for DANE deployment. That type of attack is possible in some scenarios: - The DANE records pin a CA and MITM can get misissued certificate from that CA. - The server private keys get stolen. Since the MITM would need to present a key that exists in the DANE records in order to actually activate this pinning. Recovery would need deploying the extension (the data needed is public in DNS). -Ilari From nobody Thu Apr 12 11:53:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260DD12D9FE for ; Thu, 12 Apr 2018 11:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F3Kxbx7uUB7u for ; Thu, 12 Apr 2018 11:53:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59420126C83 for ; Thu, 12 Apr 2018 11:53:16 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A7B4F7A3309 for ; Thu, 12 Apr 2018 18:53:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <201804121844.w3CIiqah030722@new.toad.com> Date: Thu, 12 Apr 2018 14:53:14 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <2FCC4C5B-112E-4500-AB8C-847C41267E24@dukhovni.org> References: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> <201804121844.w3CIiqah030722@new.toad.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:53:18 -0000 > On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: >=20 > If any ever did, the future RFC could specify > how servers which do not have validated TLSA records should handle the > situation. They'd have to violate the text of this draft: > Different future protocols might choose different ways > to handle this (e.g. don't send the extension at all; or send a = validated > denial; The draft precludes sending denial of existence in Section 3.4 which requires to the first RRset to be the requested TLSA records. Hence option (A) in the initial last-call announcement. > or send some kind of flag saying that the server doesn't even have > a validated denial because it isn't using DNS That'd be vulnerable to downgrade, defeating the purpose of this extension to support DANE. > or because some domain on > its path to the DNS root isn't doing DNSSEC or isn't using NSECx = records). This can be handled by sending denial of existence. The denial of = existence can either prove lack of TLSA records in the server's signed zone, or = can prove lack of signatures on that zone. >=20 > Please, let this RFC go, rather than requiring that this committee > first insert into it a paper spec for what some future protocol should > do, without even knowing what the future protocol is. The present draft limits its own applicability, and neither (A) nor (C) close off future options. Indeed (A) specifically lifts an unfortunate restriction, and (C) provides additional information from the server = that would be quite useful to clients. It is hard to see how either pre=C3=ABm= pt future use-cases. --=20 Viktor. From nobody Thu Apr 12 12:05:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82512D9FE; Thu, 12 Apr 2018 12:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 oBwMDAWR-2il; Thu, 12 Apr 2018 12:05:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D941212D864; Thu, 12 Apr 2018 12:05:10 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C40A47A3309; Thu, 12 Apr 2018 19:05:09 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <201804121844.w3CIiqah030722@new.toad.com> Date: Thu, 12 Apr 2018 15:05:09 -0400 Cc: dane@ietf.org Reply-To: TLS WG Content-Transfer-Encoding: 7bit Message-Id: <051D83E8-B6C0-4755-B267-291E7D97D516@dukhovni.org> References: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> <201804121844.w3CIiqah030722@new.toad.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 19:05:12 -0000 > On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: > > Viktor, I believe you have confused a "could" with a "mandate". As to this point, I'm not now and have never been confused about that. The present draft, as explained upthread, perhaps in too many ways and in too many words, offers no value to applications that don't mandate the use of the extension, if the application also excepts WebPKI, and the extension is optional, then a cost/benefit analysis shows that use of the DANE extension offers only complexity and no security benefit. Opportunistic use-cases of the present draft won't get deployed, they make no sense. -- Viktor. From nobody Thu Apr 12 14:41:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43AF129C59 for ; Thu, 12 Apr 2018 14:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM9nkZvExy49 for ; Thu, 12 Apr 2018 14:41:32 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5C61271FD for ; Thu, 12 Apr 2018 14:41:31 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id p15so4896682pff.11 for ; Thu, 12 Apr 2018 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R46E+RjqCLlw3E5M1TdJhpPzDoTNlB9/jf32LMIEYZc=; b=cYfy9cHIUOmdGXCeTHZ8Yqoiy6MdCzrrtcnHanVysc017kQjoiFCbeLleB9DMxJeUf JCO72dhlC6JlOtFQYxVdFrhCQEB3p87k/xqboV5vqRUMKUw76AzD4Euev8fkE47PUgum kuhaSNwuh5o6crlzSb57ektf3R/dMzqO7HbVeFWCc0kg+F6BzkPypKYWeVtgwtmnvXtw kFo8TR8IfUMDUP4TLWlGHhZxyWWv5G4KGnDxJAPQy/fwEXkwoLzQzSqujlE/Va6Xk41c cqe6nR0gLwFXLYN1Sj5e8kXNPigAZXzX5udkQ3oBX6h9l67b0LZqyHfg1NjFs/bRtcZL yjLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=R46E+RjqCLlw3E5M1TdJhpPzDoTNlB9/jf32LMIEYZc=; b=lek/l/xhVTSKP+1nfyWK/ZamS16y6SsBJc/eKV9OaW/5KI9ov8avp+PxB11AdkWlJS TEpjjmG3BdklKB4LmgOvK1xujpe6Cm20ftLGieQpmSMOJnKo6pTwby7GON0OLqS0UlMP LNKhSzbFWC2S1OFLswDF9t8J+pD7hxEtb2l+oCw/sKHmtrVN0GSGmf2YhesS9Ea05+vU Bp8Ij2a2f5lxqLtkvIuB3YIZufdjv0TiC5pcmMQTkqY9Zf39TkJRmjs9eWE1OD9auigA zQlNSeON/aGZZo4f0uMO4LRvJdNCmUmbkFi0blDucdw7Muuf+ASbDbECgA6Ih3EjbahN mezQ== X-Gm-Message-State: ALQs6tBEY5q6RE28BVJDYIv5ew3LXFDXnGEtuXOL31L6z/Ja7TmhU7Vs BmwUVCaFR0+4Uks3P+Lijh9vp2Q= X-Google-Smtp-Source: AIpwx4/jmVrjfwlyLeESZZE0g1B8DQ+nH4qGd1mP8bfP6T+40rgToQr2Bl5IV5xST3BtUIJCv0in9A== X-Received: by 10.101.88.140 with SMTP id d12mr1962692pgu.408.1523569291202; Thu, 12 Apr 2018 14:41:31 -0700 (PDT) Received: from aspen.local (216-67-115-161-radius.dynamic.acsalaska.net. [216.67.115.161]) by smtp.gmail.com with ESMTPSA id m7sm5679052pgs.31.2018.04.12.14.41.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 14:41:30 -0700 (PDT) To: tls@ietf.org References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PsLBlwQTAQoAQQIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaWd0AhkB AAoJEN+4kXKadtuPmvIQAJvVNnT0qhltq35AQ9Z1Ipx1IkEcQ8+yyMNLgyV9ZYhn9wn9JS/C TSb7HDSyTRiIz8CnaiCIOn2ZpT3sgYFw3cijT6YfRiifCeu4z3ea+XXOA/VyqXo42ARWOvq3 XdY3uj/j1c39PvhbopUwhulHzFJL7cMJCLEws588HdLwT8GVe+aTFPP4buJRqpOM0kSr/gkN 1IYKI0x1w6NgsgrYjCnv/VUwThjcVWPwMvZStvBnGquE6tvEmlnY+5cRktKSFw4X1ijxKzJD m0iqg7P7gNjC0r5uR2fF6BC0OPo9txPnabYph1wZ7V/5gnDwtWimD0ER77EO5Mr3zZHzva5v EwDpEbKXI43XAfpbxz3uc2fmXE2cvOCFgY/fTpX4kjVaxyFvjf1zrsac/7qFzwvgotYrYSc+ E1Ts+n1hWwsDA+qw/9reE1z9w+sn7SKL7zlS9sV54rfcd1AT0aMwlhAkEOaXRutriQ9BWWOv TOZBtRuV5RO/ZieY7lLX2+na2LjxLyak9k6wYwQwKvzvovBrr8zwDfJQDQujdVhk/lrlngAw Qh/U9dOg2hTUNiFHbKe1N+4vNCW/aLqm33LEV/vK/KepGsTl1ezQotOr0d05h2QySsdAgLCX Gv7bb+wTl/8Yx8hZfZO68KoRk8Zy4Yz8kE5LWJir+QQC7m7oo/4wZZcIzsFNBFppZ0gBEACg ZuM18ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1 YZ0OpQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR3 5FAgSnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fE ZHM66phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQ V0yBgc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4 cztvgmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRH RvQs0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBj Ltx1tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI 7qDHFxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnY jMJodU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABwsF8BBgBCgAmFiEET2gtkyoXlvgg8jTA 37iRcpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ7 5iY5pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiF PjkrQIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/J YK75BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApM LL0R/qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV 5abZ+iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJR i+cH7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7 Vz9F+6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloS bbMvP9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjx uLzdLY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+3 1fk1HKwqd9xRxC8= Message-ID: <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> Date: Thu, 12 Apr 2018 13:41:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180412175441.GD20782@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:41:34 -0000 On 4/12/18 9:54 AM, Benjamin Kaduk wrote: > I'm waiting to see if anything else comes out of this thread. > In particular, I am hoping that some authors/proponents of leaving the > document in the RFC Editor queue would speak to the question of the > target scope, given the arguments that have been presented regarding > the risk/reward tradeoff of the current narrow scope. I'm also waiting to see if something new comes up in the discussion, but it seems at this point we're just rehashing previous discussion and nothing much is changing. In particular, no new information is being contributed. The one thing that could change my mind about this would be if there was an intent to actually attack the problem described in the changed scope (well, also if the proposed change could - in fact - lead to the deprecation of the web PKI, but the chance of that seems vanishingly small). Absent that I really don't like adding goo to protocols on the off chance that at some unforeseeable point in the future there's a possibility that someone might actually want to use that feature. I think we've got other ways of handling that eventuality and very little assurance that it will ever happen, anyway. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Thu Apr 12 14:48:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4165812D779 for ; Thu, 12 Apr 2018 14:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEzp7cWqmUoQ for ; Thu, 12 Apr 2018 14:48:06 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58445129C59 for ; Thu, 12 Apr 2018 14:47:48 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id o9-v6so7730777otj.5 for ; Thu, 12 Apr 2018 14:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8IX1Tu+Mwqzjs+EGPnSovyWBP1x1mdlfbDQMxd880Tg=; b=LWZFXjHnXLo06G85fWCoQebrQgxderiYAUVjO9DojZLA5Zxa8pXWmXYWEjuaYaWWuO E38HXejCJBqewQPA5uXcPzlPZJWuYVYBFBhDPnUyWH8UHQADsMDtu0UHS191NNJk8DUS QVl3bL/YwC1ec/3L/FQbwhJuDyvH+QRoU2bR2FUD8nHHeIBkeYpChYb0c1Gpu8NQuX0H 3Q70TvFHLfmHht5V13tWyUbVqQGn1ROB1vueQNzwnbQNHuOvhp1qc1Eh55CjEtRFUiz7 IoDQiIVhZ9y5YRg+s3E6Mz1WJJlI2IOwwhvKxq/rsLa+G+DobdQ60/wlHYQ5Bv2RSLZE wZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8IX1Tu+Mwqzjs+EGPnSovyWBP1x1mdlfbDQMxd880Tg=; b=Ib+2JRYH7G8rObBKQnSPlQI9guiiLelVz466/YOP+cr6HGVjDdCfBWlUPj9EftxgN2 dR2PBqpWAKzpupHAbMzQb4OVJvpMnqkh/of6IAeVifTsIWAO0zmNVelVzJzmRn//LWd/ KniSdGdjJgROSJV4eTwKGoWv7u2dbxq6JjFvu161cwF/VN5hjwIJVVbhWhmTk4yR5qQV TprzFUKAraGWglQKlNTLmluCg0zDj53qqdZbz+p72p5jHTpIuJDBZ5u1gEDFJMiVkjdA zcGDXKhImWG0nOQmYqavuMhEbGYiDeeAVOOgllivPQDkJf2oaRCeiOag7XvGbA8kKSXL Xm0Q== X-Gm-Message-State: ALQs6tALCN8vY6E8L2uSvpSoC776JpNR69UI6w8t6c4/aANn5OR8bIOT Y5lLsUcTjYCQ0mLB6T1G9PZ8hZyfJDXoDzaHOcw= X-Google-Smtp-Source: AIpwx4+9G41yfgoOVHVT89toBr33TQZKiIc5MLAmGAlHiaZ2SeAfiBs+uKnDx2SRnEwu20RZLQxuf+cwQwQUN9/VojY= X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr1771155otd.394.1523569667522; Thu, 12 Apr 2018 14:47:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 14:47:47 -0700 (PDT) In-Reply-To: <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> From: Martin Thomson Date: Fri, 13 Apr 2018 07:47:47 +1000 Message-ID: To: Melinda Shore Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:48:08 -0000 If this is indeed about adding [goo], what prevents Viktor or Paul from proposing a new addition to the protocol in the form of a new I-D that enacts the changes they wish to see? On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore wrote: > On 4/12/18 9:54 AM, Benjamin Kaduk wrote: >> I'm waiting to see if anything else comes out of this thread. >> In particular, I am hoping that some authors/proponents of leaving the >> document in the RFC Editor queue would speak to the question of the >> target scope, given the arguments that have been presented regarding >> the risk/reward tradeoff of the current narrow scope. > > I'm also waiting to see if something new comes up in the > discussion, but it seems at this point we're just rehashing > previous discussion and nothing much is changing. In > particular, no new information is being contributed. > > The one thing that could change my mind about this would be > if there was an intent to actually attack the problem described > in the changed scope (well, also if the proposed change could - > in fact - lead to the deprecation of the web PKI, but the chance > of that seems vanishingly small). Absent that I really don't > like adding goo to protocols on the off chance that at some > unforeseeable point in the future there's a possibility that > someone might actually want to use that feature. I think we've > got other ways of handling that eventuality and very little > assurance that it will ever happen, anyway. > > Melinda > > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 12 14:49:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2422A129C59 for ; Thu, 12 Apr 2018 14:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 35c9s_H3UKvh for ; Thu, 12 Apr 2018 14:49:27 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A941712AF83 for ; Thu, 12 Apr 2018 14:49:27 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id 126-v6so6611142oig.0 for ; Thu, 12 Apr 2018 14:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nUKCK+9irJkD/hpQRwXBjBRGxGPR6GoEDcbDJBZ6Wnc=; b=OPMtSGjM0BxhMqNbKxfQhrOPW8eEavPFwn+6sNkgbGMPU1dpQbJ6vtM7jxmWPkumJH gH8iLcu0THWg0N5LhvCRBnwP6mzvf6oXoSQHkR7vacUThpEQQL4jsBFiW+tXooqiYsoI zrD6EFL2VVYQRBRssQ2k//6f2EixmC7g46PdDF7qp7tevJ53YPLM97Essar1PJSwBK3g ZL1Uoj9tT91y9z50l9JId9vxHJIm3YFgeVe+kYKnV72IFiF7Qc92ZB291dqAmr3lLAV3 qDAya8Tpwz5xmsq9g1v19yq9WUwG0h6AsrjiFa3Y8DL4pByDFkAk+5Rq07fnBX40yyI2 WVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nUKCK+9irJkD/hpQRwXBjBRGxGPR6GoEDcbDJBZ6Wnc=; b=d2LyrRBymO+SLctvpd0fZUZ8OOnN05WhMipv49NYygr2iAlTh6EIfz3FX3XSM6HfoE HifQ1rv7qjRg6m4y9xuBz/zGra1L06Um6PTEipa9/eU8vyDZTaAeom0AdDy8c92fiHHR a5VoJk/K1RPu5w+pLbnYowcthuzf/DjU+zLBbs6GoQk8hP+yHQyyx28pC+OfwAP2Av49 OhNVDHoZYLDoyBZBpyq6eF5Ns3DQdb6AE+Ju6axV7u8DrnnQ++leI1jxzrzz5Gqf0A+O /a5VikET2FKHLjSn3lRwvrI164poBlbZj6nxQazXCSvdAjPUJjFlgzbGHys1p2rvvufo GDdw== X-Gm-Message-State: ALQs6tBJRuylpCGRYFimch8PLAEFAzLabp1lo8AQgIMVt8Rj5XAAPi3d TI6iphxk6gngBElgWYgXff3jI1RtKxH7tJbChen6pQ== X-Google-Smtp-Source: AIpwx4/fvH5OkQlGZmHatfNovJQVzxChjaQ/1lFafHdJGlCBX+GkideGZGCJ2l/SZcwx+/D/hjWWbUn7xeDzM5eOmAE= X-Received: by 2002:aca:5397:: with SMTP id h145-v6mr6649946oib.6.1523569766984; Thu, 12 Apr 2018 14:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Thu, 12 Apr 2018 14:49:26 -0700 (PDT) In-Reply-To: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> From: Richard Barnes Date: Thu, 12 Apr 2018 17:49:26 -0400 Message-ID: To: Martin Thomson Cc: Melinda Shore , "" Content-Type: multipart/alternative; boundary="000000000000c0861c0569adba40" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:49:31 -0000 --000000000000c0861c0569adba40 Content-Type: text/plain; charset="UTF-8" This is in fact what I proposed in the room in London. Let's publish draft this as-is, and handle what they want as a follow-on. On Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson wrote: > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? > > On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore > wrote: > > On 4/12/18 9:54 AM, Benjamin Kaduk wrote: > >> I'm waiting to see if anything else comes out of this thread. > >> In particular, I am hoping that some authors/proponents of leaving the > >> document in the RFC Editor queue would speak to the question of the > >> target scope, given the arguments that have been presented regarding > >> the risk/reward tradeoff of the current narrow scope. > > > > I'm also waiting to see if something new comes up in the > > discussion, but it seems at this point we're just rehashing > > previous discussion and nothing much is changing. In > > particular, no new information is being contributed. > > > > The one thing that could change my mind about this would be > > if there was an intent to actually attack the problem described > > in the changed scope (well, also if the proposed change could - > > in fact - lead to the deprecation of the web PKI, but the chance > > of that seems vanishingly small). Absent that I really don't > > like adding goo to protocols on the off chance that at some > > unforeseeable point in the future there's a possibility that > > someone might actually want to use that feature. I think we've > > got other ways of handling that eventuality and very little > > assurance that it will ever happen, anyway. > > > > Melinda > > > > > > -- > > Software longa, hardware brevis > > > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > > 34C0 DFB8 9172 9A76 DB8F > > > > _______________________________________________ > > 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 > --000000000000c0861c0569adba40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is in fact what I proposed in the room in London.=C2= =A0 Let's publish draft this as-is, and handle what they want as a foll= ow-on.

O= n Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
If this is in= deed about adding [goo], what prevents Viktor or Paul
from proposing a new addition to the protocol in the form of a new I-D
that enacts the changes they wish to see?

On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore
<melinda.shore@nomountai= n.net> wrote:
> On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
>> I'm waiting to see if anything else comes out of this thread.<= br> >> In particular, I am hoping that some authors/proponents of leaving= the
>> document in the RFC Editor queue would speak to the question of th= e
>> target scope, given the arguments that have been presented regardi= ng
>> the risk/reward tradeoff of the current narrow scope.
>
> I'm also waiting to see if something new comes up in the
> discussion, but it seems at this point we're just rehashing
> previous discussion and nothing much is changing.=C2=A0 In
> particular, no new information is being contributed.
>
> The one thing that could change my mind about this would be
> if there was an intent to actually attack the problem described
> in the changed scope (well, also if the proposed change could -
> in fact - lead to the deprecation of the web PKI, but the chance
> of that seems vanishingly small).=C2=A0 Absent that I really don't=
> like adding goo to protocols on the off chance that at some
> unforeseeable point in the future there's a possibility that
> someone might actually want to use that feature.=C2=A0 I think we'= ve
> got other ways of handling that eventuality and very little
> assurance that it will ever happen, anyway.
>
> Melinda
>
>
> --
> Software longa, hardware brevis
>
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 34C0 DFB= 8 9172 9A76 DB8F
>
> _______________________________________________
> 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

--000000000000c0861c0569adba40-- From nobody Thu Apr 12 14:52:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1312D779 for ; Thu, 12 Apr 2018 14:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-C46D-aD5GJ for ; Thu, 12 Apr 2018 14:52:38 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC1412AF83 for ; Thu, 12 Apr 2018 14:52:23 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id a2so4922196pff.8 for ; Thu, 12 Apr 2018 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=58mF8gTGc9lpD0ywhNT+snXNELr8ry1fphc99N7VGb0=; b=Gd7So1z3m/JYsm8A6CYzTHnFqRrTOkflbW773XWWZCaXd+xWXuoHByjZ2+zhdhpSmX MxT9DhSNxaW0KHTz34itDth5KYItBLVne+0BHkiepicONmeABJOPi3OL6gz31v0WXLMs 4CeUcYzbUWbQ9mi0Sp64EZuA6W91VPmASsMohoN/qxndhIXsLGurOSVFwlYYibWt4iu1 Lr7eQxxWScUmI1P7/clVHayDHm6iNGh+z7NivPa7UqJ1Aoq76jAYpQSH74PcQtQuPasP gkNlaSDf8YyNx0+b9MWpwW0s7iHP0pBUMPIn8b61eYOyT6+/P8jAXdYIi+vNEI+t8QEZ O1Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=58mF8gTGc9lpD0ywhNT+snXNELr8ry1fphc99N7VGb0=; b=Og3KU66wpFUsOYqV0Sudgpmhe/CucOfamOK+nBmv5mAFE1TAwfiah5U5GUh9ZJuCxU PdaSq/EKFgso0PQvSQfifGAVd5W1JgIGg5xlpd/EeaHEGsMVnv8o2RTVqKASgOaXos1a klVIkILDvoxFiIOwLFZExx3eQuwyLJvpefQ9Tu58hit+QOT72IbdRT+E2bBkP0yj6sfR 5bQ6llJau/3KZSbjaPaRSK6FqK0ti0zwvkeb9nZsHeGNVBbElXCwxRLSABMFzJgBk+E6 4KqEOsXrYyVGvSlsGa/yIk9HxNkLkoQgWN2LRwgrBMb1S7bBgxwxgkcWG12wiRXUheM1 FrJg== X-Gm-Message-State: ALQs6tCoOR517y9wevkvKpX5FRhXXFF5DIBromcS3RXv2ItjJQffLO7B HZ6gRKDhDNqND2Bs0IfNcRBEwxQ= X-Google-Smtp-Source: AIpwx49HEV5mSoWrh50XdbAbOS76mcIH0CVsOH0ijpvaPuqWW9t9O6e/68Gnu5loi72InvOGpwZPRQ== X-Received: by 10.99.123.78 with SMTP id k14mr1951707pgn.183.1523569943322; Thu, 12 Apr 2018 14:52:23 -0700 (PDT) Received: from aspen.local (216-67-115-161-radius.dynamic.acsalaska.net. [216.67.115.161]) by smtp.gmail.com with ESMTPSA id q75sm10407157pfj.99.2018.04.12.14.52.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 14:52:22 -0700 (PDT) To: Martin Thomson Cc: "" References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PsLBlwQTAQoAQQIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaWd0AhkB AAoJEN+4kXKadtuPmvIQAJvVNnT0qhltq35AQ9Z1Ipx1IkEcQ8+yyMNLgyV9ZYhn9wn9JS/C TSb7HDSyTRiIz8CnaiCIOn2ZpT3sgYFw3cijT6YfRiifCeu4z3ea+XXOA/VyqXo42ARWOvq3 XdY3uj/j1c39PvhbopUwhulHzFJL7cMJCLEws588HdLwT8GVe+aTFPP4buJRqpOM0kSr/gkN 1IYKI0x1w6NgsgrYjCnv/VUwThjcVWPwMvZStvBnGquE6tvEmlnY+5cRktKSFw4X1ijxKzJD m0iqg7P7gNjC0r5uR2fF6BC0OPo9txPnabYph1wZ7V/5gnDwtWimD0ER77EO5Mr3zZHzva5v EwDpEbKXI43XAfpbxz3uc2fmXE2cvOCFgY/fTpX4kjVaxyFvjf1zrsac/7qFzwvgotYrYSc+ E1Ts+n1hWwsDA+qw/9reE1z9w+sn7SKL7zlS9sV54rfcd1AT0aMwlhAkEOaXRutriQ9BWWOv TOZBtRuV5RO/ZieY7lLX2+na2LjxLyak9k6wYwQwKvzvovBrr8zwDfJQDQujdVhk/lrlngAw Qh/U9dOg2hTUNiFHbKe1N+4vNCW/aLqm33LEV/vK/KepGsTl1ezQotOr0d05h2QySsdAgLCX Gv7bb+wTl/8Yx8hZfZO68KoRk8Zy4Yz8kE5LWJir+QQC7m7oo/4wZZcIzsFNBFppZ0gBEACg ZuM18ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1 YZ0OpQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR3 5FAgSnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fE ZHM66phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQ V0yBgc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4 cztvgmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRH RvQs0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBj Ltx1tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI 7qDHFxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnY jMJodU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABwsF8BBgBCgAmFiEET2gtkyoXlvgg8jTA 37iRcpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ7 5iY5pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiF PjkrQIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/J YK75BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApM LL0R/qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV 5abZ+iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJR i+cH7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7 Vz9F+6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloS bbMvP9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjx uLzdLY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+3 1fk1HKwqd9xRxC8= Message-ID: Date: Thu, 12 Apr 2018 13:52:19 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="whoGxlG9ac4E9yIC0oEuc1F0Rj32vJQkz" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:52:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --whoGxlG9ac4E9yIC0oEuc1F0Rj32vJQkz Content-Type: multipart/mixed; boundary="fUs9vvCHSHMUE6eu8SewZves5ze0mJ2jR"; protected-headers="v1" From: Melinda Shore To: Martin Thomson Cc: "" Message-ID: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> In-Reply-To: --fUs9vvCHSHMUE6eu8SewZves5ze0mJ2jR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/12/18 1:47 PM, Martin Thomson wrote: > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? Clearly nothing, and I think this would be a reasonable way forward. Melinda --=20 Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --fUs9vvCHSHMUE6eu8SewZves5ze0mJ2jR-- --whoGxlG9ac4E9yIC0oEuc1F0Rj32vJQkz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAlrP1RQACgkQ37iRcpp2 24/xlA//f+21FIllPpNX3BXZlfaQLEwYruKltovS2q24PeMGirV+LlyXXA5OXkse FrPnxTnCmqb9MEm46V7PDE9Lxc0c7AvJ62DxrV4x557uH5IvAeeVwXktLwrUV6yT TgjArzWzWv8yWQvI64J6SbUvoeKxvgfnWPZ+OU1K2O0BVF85c969jSgSkHx4HGrI EUjyBcphNC0n8oqNO7u1w+sNq8ZFF+HiYrCIOmq+GNkuem8f9VSmz/qLAF6ijYFL IgMNkLeIxv+9y+Muz3Y2WDOF81bOfkAkccat+c7mJDnq0X7caR7WHNFSf48JkbwT Qabmy1bgDrGk4kymlkJd5mVCMoevImMocJQFSRSGImU94J8nITHjoj+npdgllBUP R+2dvkux9uwfWtw0tDrfU38WshucqHuqhMcsgtTq4xqFKmn54S+YlSXRU89xpa3f LZSR6QJ5QCYXW6D0sANzLnhIkUFpkHGgewzifz8KE0kW9maYbp/ANtYmwQuLPeUj 18nFKq5UjjjhhQsFZ7ogff0WI+kN6X9Q3O1vqNunYbdrRYSj//KzVfB3KLZEDITr cYhyttXSXR0fym6tx0nY+24gaf+cXI9oM0ogJ0cTYFSY2hozK3yWweHme9o+bH80 nQ7pGpj9VZ+Op27geaCX+O0C0f3FzbDguKh76R75ykvlfyUggOg= =AU6f -----END PGP SIGNATURE----- --whoGxlG9ac4E9yIC0oEuc1F0Rj32vJQkz-- From nobody Thu Apr 12 15:09:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A312D7F9 for ; Thu, 12 Apr 2018 15:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wSSUvGEGMZyW for ; Thu, 12 Apr 2018 15:09:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4E812895E for ; Thu, 12 Apr 2018 15:09:34 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B97A27A3309 for ; Thu, 12 Apr 2018 22:09:32 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 18:09:31 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:09:35 -0000 > On Apr 12, 2018, at 5:47 PM, Martin Thomson = wrote: >=20 > If this is indeed about adding [goo], what prevents Viktor or Paul > from proposing a new addition to the protocol in the form of a new I-D > that enacts the changes they wish to see? Why publish a crippled specification that needs immediate amendments = that would require a second parallel extension to be defined and used by clients = and servers to fix the issues in the current specification? And the time to get = that second extension would effectively delay the publication of a usable protocol. The protocol as described prohibits denial of existence responses. = Willem acknowledged (thus far in an off-list message) that that's an oversight = that should be corrected, and such a correction is the substance of option = (A). The protocol as described does not provide any mechanism for client to distinguish between servers that are ready to commit to the extension and those are not. This negates applicability in applications that exist in a world dominated by the WebPKI. Note that I also don't advocate any magical vision of the WebPKI going away any time soon. Indeed some of these applications (e.g. browsers) might choose to support only *at least* WebPKI, with DANE for optional hardening (PKIX-TA(0), PKIX-EE(1)), but the present draft provides no downgrade protection for this use-case. The additional commitment signal is a hint to clients, not an = obligation, it carries negligible cost, and can be finalized now. It enables more potential applications, without going back to square-zero and doing = another year in the IETF WG process to address the gap. Let's do the right thing and fix now. The entire cost is just a small delay, there is zero downside after that. No imposed complexity. Just an improved scope. We all want to get stuff published and out the door, but let's take a *little* extra time to make sure it is not needlessly crippled. --=20 Viktor. From nobody Thu Apr 12 15:34:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F303127876 for ; Thu, 12 Apr 2018 15:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8mYiMDdVgn4 for ; Thu, 12 Apr 2018 15:34:13 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D881C12422F for ; Thu, 12 Apr 2018 15:34:03 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 142-v6so896578itl.5 for ; Thu, 12 Apr 2018 15:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=H0C5aThvI/CnqF4EmWl9s51/KqcnfSPxB5w9JCNoHxQ=; b=dxlYrWQP9Nxkho+Qlzc3HX49GCuLApqz2EMw4egNpP7zXEFhLTrnf69r3ac2CZgs0d faWQ3rEsEBH2QuZ5kJdX7Y+HkDphABc1QtR2VabBuvkfAOUt7PLJH3AHb9An2i7tNYCJ QPkKZbAxAMefpZvuhz5KoA5se54CO76Iw+xNgjGHEp7bOk6lokWdE7TBNifKBVcSk0Ob OsWhbcR9rgYwGoaTs8bzL/VVJmgcLjPwWFcf8iF29ve5Z+gbr1xiUWE+j5hbfXXkAl3T HVrZiQao6bCiKcBIo+WvIgaIpqFcDnu79CzqRK8368L1k/6u2V6gKZKCbiJ7rloKoV7q /SnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=H0C5aThvI/CnqF4EmWl9s51/KqcnfSPxB5w9JCNoHxQ=; b=q9Ng3J/l6pJUZZqkp4UyzE9ICRC7ciTzDlPFGYDakNPPZR4SWmWOLiKQbthGU2hcWf hZ8eiw+a1Pen0M/hvQWLcaPpdaMYwmTxCN+oe6xD0DoJy7RFgjoR+Y8+SxaU+HFEVuWu jgbIVUHXDhMGeDA+75Qak3ZRHMwdzTKQNd5weHcKfhyR1hDuA9Uut8XQH9U8138SX2bN 4VEGxyI1jV/BpkKU99PclJoLjAgrHiqc/0H7av29lKGw9kFspCsArNYmhc8C0CiBMEF2 g+P4DVU7w/kDBPdjlgX2MTeNq+9+x9547ksygjmcV0f5C7aKQiTuU2N8wveJOSEzZlRC Ny5g== X-Gm-Message-State: ALQs6tB5q2sHR5UFx3LXpSOwsja+BNsMOuSj5WvhOqJZIFRHBowf/kq9 r9V0fbIc2s1t/nyShMf4GE39T1RCSjE1t/eBj5h3ug== X-Google-Smtp-Source: AIpwx4/SqQeJ1Uje02Kj/L9O0CyKQEsk8uB5dqwBNktb/I+z6xCCaFnev/R4PCXVtntjIZVmwvlN0z3gjpXLV7H7fPU= X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr2751840itg.61.1523572442785; Thu, 12 Apr 2018 15:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.213.131 with HTTP; Thu, 12 Apr 2018 15:34:02 -0700 (PDT) In-Reply-To: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> From: Shumon Huque Date: Thu, 12 Apr 2018 18:34:02 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000003deea20569ae5a33" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:34:15 -0000 --0000000000003deea20569ae5a33 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 5:47 PM, Martin Thomson > wrote: > > > > If this is indeed about adding [goo], what prevents Viktor or Paul > > from proposing a new addition to the protocol in the form of a new I-D > > that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? And the time to get that > second > extension would effectively delay the publication of a usable protocol. > > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight > that > should be corrected, and such a correction is the substance of option (A). > As I said in a previous message, I'll support relaxing the language in the draft to permit delivery of authenticated denial chains for future applications of the protocol - I think that's just adding or modifying a couple of lines to the draft, and no wire changes. Someone actually argued to me in person that the draft could be read as not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but if we want to allow it, I think it's best to be crystal clear. If we can get consensus on that, then you could write a separate extension to convey the pinning information and describe the additional behavior. That in combination with the existing draft would satisfy your use case. That would in fact be an incremental addition, and not a whole new parallel protocol. Implementers that are opposed to pinning would then just ignore this second draft (and not bother with the authenticated denial part of the first draft). Since it seems pretty clear you're not going to consensus on adding pinning to the current draft, I think you should pursue this approach. And then you can try to convince implementers and deployers, now or in the future, that they need to use both extensions in combination. -- Shumon Huque --0000000000003deea20569ae5a33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br>
> On Apr 12, 2018, at 5:47 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D=
> that enacts the changes they wish to see?

Why publish a crippled specification that needs immediate amendments= that would
require a second parallel extension to be defined and used by clients and s= ervers
to fix the issues in the current specification?=C2=A0 And the time to get t= hat second
extension would effectively delay the publication of a usable protocol.

The protocol as described prohibits denial of existence responses.=C2=A0 Wi= llem
acknowledged (thus far in an off-list message) that that's an oversight= that
should be corrected, and such a correction is the substance of option (A).<= br>

As I said in a previous message, I'= ll support relaxing the language in the draft
to permit delivery = of authenticated denial chains for future applications of the
pro= tocol - I think that's just adding or modifying a couple of lines to th= e draft,=C2=A0
and no wire changes.

Some= one actually argued to me in person that the draft could be read as
not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), b= ut
if we want to allow it, I think it's best to be crystal cl= ear.

If we can get consensus on that, then you cou= ld write a separate extension
to convey the pinning informati= on and describe the additional behavior. That=C2=A0
in combinatio= n with the existing draft would satisfy your use case. That would in=C2=A0<= /div>
fact be an incremental addition, and not a whole new parallel pro= tocol.

Implementers that are opposed to pinning wo= uld then just ignore this second=C2=A0
draft (and not bother with= the authenticated denial part of the first draft). Since it=C2=A0
seems pretty clear you're not going to consensus on adding pinning to= the current=C2=A0
draft, I think you should pursue this approach= . And then you can try to convince=C2=A0
implementers and deploye= rs, now or in the future, that they need to use both
extensions i= n combination.

--=C2=A0
Shumon Huque

--0000000000003deea20569ae5a33-- From nobody Thu Apr 12 15:36:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783A712422F for ; Thu, 12 Apr 2018 15:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCtu0vEmrz0f for ; Thu, 12 Apr 2018 15:36:08 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41E01200A0 for ; Thu, 12 Apr 2018 15:36:08 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id a14-v6so7849371otf.6 for ; Thu, 12 Apr 2018 15:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wl9spdB0VnkAexMH8lo+MGXj5/67Mjx9gFYPL+ycuNo=; b=MZdKw2Xz1J7F4IKPxxbCQEzNkf9LXfdv/NQKqedJgAsafJ0757Y60Z9iLs+YYnyDSU RHsYXCXBbMGwQjSUHDmvLPgzmwKQlcGL+ib/WGLw/JVU2BYHeqb/ru5lhrPvSFyXjigJ JSZXpjeHuyUJkpT505q5joeEX6ZuyMIQNHD/tlTYSNFgFg+eHJpVix3UJ6uItpmEKLet 8wJ1ElLztLnccP5R+UryTM/IP9jW4CueVh0gxVyj5964J37jeOi9pXde0HEjrF9Q2r7u A2x8l0scY8UWtb/eQj2zhmQJQe1ncpMCG0EUov0Gb5itJpyLa4bLK01aAqcnXT2HyUL+ 4ILQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wl9spdB0VnkAexMH8lo+MGXj5/67Mjx9gFYPL+ycuNo=; b=e09peqRuJAl6ExzV7GVxC6vD77DTUy7ZPN4pHxINbBCi3oNqXErzf5+eWVDX0Ptwm7 MvnuA72eaw0mcL0ccZtoJq1o60CJTGiV1JnYBkGPYtXDqBTGwDrJmAR/1JJT1g+m1Is/ GkjZ0hbL7Qlu+rga0ZAPR9/6FEn6ZBEtIh3H4FAo+VsfIcCnS44SULW7x0Rq1ejRfMSf WdCBkWws+J4XKcZXamc7MQKzfTjm4x41jhU8xAoY0IRLEr1Li9z9utxGI6Z/77gEOpCA GjRDop91hy61vhORwU6X9bd7ujOUZx0WKG+nKdqQgdZZ4htekjqaELHshYCZpa2rVyrd 5Scg== X-Gm-Message-State: ALQs6tATBsrqmWpsiG4HxjboEjdEAfQdzBRwRrJgD97jMFsr0jZjahpD M+olUQ0krv9OlXOZt+XH6LUu3b35N7a1rDoteQexGg== X-Google-Smtp-Source: AIpwx49qUZgZu/LOYnyFPgwoQwvShRzVhxRZsVYERHeuufOhWqAA4g1zsH0O9h1ldK3edFx5c7vtGo2wJ6aSg3XCsF8= X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr1856322otd.394.1523572567830; Thu, 12 Apr 2018 15:36:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 15:36:07 -0700 (PDT) In-Reply-To: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> From: Martin Thomson Date: Fri, 13 Apr 2018 08:36:07 +1000 Message-ID: To: TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:36:10 -0000 On Fri, Apr 13, 2018 at 8:09 AM, Viktor Dukhovni wrote: >> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote: >> >> If this is indeed about adding [goo], what prevents Viktor or Paul >> from proposing a new addition to the protocol in the form of a new I-D >> that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that would > require a second parallel extension to be defined and used by clients and servers > to fix the issues in the current specification? Three reasons: 1. It clears the current bind. 2. It's abundantly clear (to me at least) that there is no consensus that the specification is indeed crippled. 3. We build by increments all the time. From nobody Thu Apr 12 15:44:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED0A12422F for ; Thu, 12 Apr 2018 15:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzAKnkh3t9mc for ; Thu, 12 Apr 2018 15:44:24 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 0B2801200A0 for ; Thu, 12 Apr 2018 15:44:24 -0700 (PDT) Received: from [192.168.1.141] (happus.xs4all.nl [82.95.141.127]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 14610D352 for ; Fri, 13 Apr 2018 00:44:22 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1523573062; bh=E5gOpQdmHhqNCln/bkk6Jpz2GupjYOKm78Mvu7BBJog=; h=Subject:To:References:From:Date:In-Reply-To; b=p8rEchKTYgSQ4E4Incrr9qoV6wHhbY1QH3jCVbEwZLL2VE375Aiv9+J1MMseGGgr6 RI7JEJ182tvartVfGzJ3b/YP7B6UMNKyeQE66Jw5ux/IEnWCdJXuQS2ne5sFZm51qm 7xEX1RoDfu5uWi0D6JopILte/SHEoMX0yivFdYD4= To: tls@ietf.org References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> From: Willem Toorop Message-ID: Date: Fri, 13 Apr 2018 00:44:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:44:26 -0000 Op 13-04-18 om 00:09 schreef Viktor Dukhovni: > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight that > should be corrected, and such a correction is the substance of option (A). Well... I find it unfortunate that the line you were quoting from section 3.4 could be interpreted as prohibiting the possibility of denial of existence. So I am open to relaxing that text so that it can not be interpreted as such anymore yes. From nobody Thu Apr 12 16:03:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82C0127876 for ; Thu, 12 Apr 2018 16:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2hb-6hTelEr for ; Thu, 12 Apr 2018 16:03:15 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD49E12422F for ; Thu, 12 Apr 2018 16:03:15 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 70F571E42B; Thu, 12 Apr 2018 23:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1523574194; bh=LPy2vmq9e8iiTvTHo0+Tkyfl5zSN+4hszNRT1cO3blQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QMoXvt6r6c90E/GITDe3gjm911WqmO/1S095ADDGfDE8BL4ETSXUwFZGU4I7IhTfj xjRH7q5Erv9SqKr8eIQdLeqFyV3ihFffWCB9eWLbT2e5p4GSW4lUFMfHcisdDmTqz0 llae/wQPje0m+Z/KIYvrjtDQPrKC5eQ2SVNXBA1icjsnqdf9r/g6cSCaLleIJpvQ3U YkascAHfebqBKgPvlvOq0yPo6owkM1r8PSW4jGD7BoWVIfOZkcNwLJZKg8t/n8seFs ywp1r7vVeR9l+Oyo4CnkoWEaEyPfIjPF9RhuwzWNKGyA0HXBs3sSmjZ8KoAbUNqqgc ROoirvfqgfSBQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id E301210A6FF22; Thu, 12 Apr 2018 23:03:07 +0000 (UTC) From: James Cloos To: Richard Barnes Cc: Paul Wouters , "\" In-Reply-To: (Richard Barnes's message of "Thu, 12 Apr 2018 09:49:22 -0400") References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2018 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 12 Apr 2018 19:03:07 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:03:18 -0000 >>>>> "RB" == Richard Barnes writes: RB> It seems noteworthy, however, that nobody is chiming in on the list who was RB> not also part of the discussion in the room. Not true. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Apr 12 16:06:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4C124D6C for ; Thu, 12 Apr 2018 16:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 JEYGh8m5vCtp for ; Thu, 12 Apr 2018 16:06:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E2212422F for ; Thu, 12 Apr 2018 16:06:06 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A72107A3309 for ; Thu, 12 Apr 2018 23:06:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 19:06:04 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:06:08 -0000 > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote: > > Well... I find it unfortunate that the line you were quoting from > section 3.4 could be interpreted as prohibiting the possibility of > denial of existence. So I am open to relaxing that text so that it can > not be interpreted as such anymore yes. Current text: The first RRset in the chain MUST contain the TLSA record set being presented. However, ... Proposed text: When the server has DNSSEC-signed TLSA records, the first RRset in the chain MUST contain the TLSA record set being presented. However, ... When the server either has no TLSA records, or its domain is not DNSSEC-signed, it is RECOMMENDED that the server return a denial of existence of either the TLSA records, or proof of insecure delegation at some parent domain, rather than omit the extension. Clients that are willing to fall back from DANE to some alternative mechanism may require the denial of existence to make that possible. -- Viktor. From nobody Thu Apr 12 16:08:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7719E124D6C for ; Thu, 12 Apr 2018 16:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 guj4lIgCEtDa for ; Thu, 12 Apr 2018 16:07:57 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4133D12D77C for ; Thu, 12 Apr 2018 16:07:57 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id v6-v6so7904130otj.12 for ; Thu, 12 Apr 2018 16:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=64o5Bx09H/JbgDzKyjqtiFzsZq5gf8mMxU11FN4lZLY=; b=hOdTAIdUDlYtaiE5UMHMEvLxdfwTHYMLm7dL9Jm6ekGwEP4FWXcb72ATAZT6kD6xzQ jhSKLZrVDHV2m0Aes8URgOEaTmXsx225UIKqCX10lTw6ap1CbTc0ClhopJVbCZMqe/pd TOZeoglvcdB84hPphYtQ9TOlBVkiAAgnShL0w74AEg/7m2kKWWBtTvoofIphTBfzFPvI FN80evJwvS+jnPhf2uizpPXjUF8/Dts9XaZk1qawctmJpQuJeIsw0PHSRtWqK6PUVVSO ZwOcodukxd/MP5D2MvxA6sNlFcKSeUhTzBOSZ0JfpS5TSlZWxxJn474V4xJULBZ7V0O0 BJSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=64o5Bx09H/JbgDzKyjqtiFzsZq5gf8mMxU11FN4lZLY=; b=I3W9B/NWe7cioa8M9kVecQYGWDYH7RxHJkI+xNpwMQ4zURg+kjkYxwp4pDp5y/2AQy 7j/v1/rwvUGj/GdiFnXONqR6bAogBqepmGRRGe6vrE66I1SnhODkf9ILDC5p1okB5u9j ZY9uRIlqRLJNnGthizmbyDR7G0676CFVyjG6Res+zC2M/TAdHm9yg4jDM9v/3EwCPVb4 /D1tVtw2Ya6Vvb+7ZAjfjShiBn42ybQscJm62bAse6XfVe73nngvQgG6ySB0DhMrxAZE DQmYaK2ixUOxLJ928LPUTcVI7w21ivCIHaVDuQnceszGFk5fCtYYVbLmFsi5sZ2+ER6U etCg== X-Gm-Message-State: ALQs6tCYqQRsY3NLgLvcU+hqxn/3IVYVZ3ZYq52E/zBjh2qtuLSjHMYj 27a35B/ZDr4L8i+FYYxVpMi0gP7ppzBtKXBHLUIsf4dU X-Google-Smtp-Source: AIpwx4+H9l41nv/oZSQOZJhZnPq7zptwcNwmX/DY3+UnPn9Dt5EpP3hWdpqinL8WL8i6YfcTznB7FZ0AH5dc0/bgB/8= X-Received: by 2002:a9d:4289:: with SMTP id r9-v6mr2142507ote.44.1523574476362; Thu, 12 Apr 2018 16:07:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 16:07:15 -0700 (PDT) In-Reply-To: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> From: Eric Rescorla Date: Thu, 12 Apr 2018 16:07:15 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="00000000000073ee620569aed3cc" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:07:59 -0000 --00000000000073ee620569aed3cc Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 5:47 PM, Martin Thomson > wrote: > > > > If this is indeed about adding [goo], what prevents Viktor or Paul > > from proposing a new addition to the protocol in the form of a new I-D > > that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? And the time to get that > second > extension would effectively delay the publication of a usable protocol. > > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight > that > should be corrected, and such a correction is the substance of option (A). > It would be good to get clarity on this. My understanding is that option a involved recommending (at some unspecified level) that people provide those responses, not just making it possible for them to do so. -Ekr --00000000000073ee620569aed3cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 12, 2018, at 5:47 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D=
> that enacts the changes they wish to see?

Why publish a crippled specification that needs immediate amendments= that would
require a second parallel extension to be defined and used by clients and s= ervers
to fix the issues in the current specification?=C2=A0 And the time to get t= hat second
extension would effectively delay the publication of a usable protocol.

The protocol as described prohibits denial of existence responses.=C2=A0 Wi= llem
acknowledged (thus far in an off-list message) that that's an oversight= that
should be corrected, and such a correction is the substance of option (A).<= br>

It would be good to get clarity on this= . My understanding is that option a involved
recommending (at som= e unspecified level) that people provide those responses,
not jus= t making it possible for them to do so.

-Ekr
=

--00000000000073ee620569aed3cc-- From nobody Thu Apr 12 16:11:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FF12422F for ; Thu, 12 Apr 2018 16:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Extw3gdE3apk for ; Thu, 12 Apr 2018 16:11:09 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 1A61512421A for ; Thu, 12 Apr 2018 16:11:09 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id o9-v6so7929475otj.5 for ; Thu, 12 Apr 2018 16:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mQCAs/b8sU8vt1VG1uYx/WwbAyyFdu7ypsIzqS3tNbQ=; b=p+qea0IwP5ODE7iXVzBj44XcH7ZAlkQDL2keepBjEuLEbx1S4RAFBb4b1cijHN7ubq Mkw+f0HvQmuRrRO1W+BIg8SCGtLs7HQGKtewjeGRva3BTYRNbup4bBR6NPHrrz2RDYGk bYLO/htSnyZBg2JsG4UgZ2yu9bpda746VDCrqJdBXp0y9Iv9Z9V2Qscg320ZApRpcA4M bBXgT41+CMhHOjrfO4Rs1PIEtZTraY4B72FQc8MyREamvfyTRcv8D9oIM27pzgPq5Ssv o1m4HEf7EX+K8vEu1o1krsKVh1etGsPWsmCBn8YjPNffZZK2ZF/xsvqBmqfxZK8KEuum wdzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mQCAs/b8sU8vt1VG1uYx/WwbAyyFdu7ypsIzqS3tNbQ=; b=dMlU7uhrtsuuWbXO2hEnuHo/A4zForw8tHOHnaac98QCgQdAYwxvj7VgaKNgY1kAwW F8lB9TLp2ZncXdMGNwzIYdllhwL0y9lZ6GfW2CJXwhhjrCojjbLsI5dUDXTY1vjrvWQH Oan9MAiesgJG4ns7UVrOLbyq6hkxa5cj8YHDPX/+JwiG+y7XPjZy6SSe5Ssw31lc4I0l CbGMsk7WXkuyhRmBVrspIm61cxw/lpYQmqRGMb9NQNsd++X1b9ROL0LFha7BoNQJab7x RUgdBQWGIeWu+VP4udPfGwN5uuKcKF1Tm+NZylnitX7AuuvIX9KzTSWRjKouibd9uSHU 39kw== X-Gm-Message-State: ALQs6tDCO16EfziwoZqa3MoZBt0D1bx3IYll5TT+Et6+Bmmku1SwToz+ xy3hRH6ifhaMIi0T7CjhjZoE577Q5yCRC5D5banBGgAs X-Google-Smtp-Source: AIpwx4+gv8/+mIeq/FxqMOZZzrdmn//AubnZXBSvBQYr3XU4RpVBOjaMI7Dhl2ajYy/GefBh1gmIX8S/MCNUZpDvr64= X-Received: by 2002:a9d:e06:: with SMTP id c6-v6mr2181071otc.371.1523574668349; Thu, 12 Apr 2018 16:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 16:10:27 -0700 (PDT) In-Reply-To: References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> From: Eric Rescorla Date: Thu, 12 Apr 2018 16:10:27 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000e56ac60569aede84" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:11:11 -0000 --000000000000e56ac60569aede84 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote: > > > > Well... I find it unfortunate that the line you were quoting from > > section 3.4 could be interpreted as prohibiting the possibility of > > denial of existence. So I am open to relaxing that text so that it can > > not be interpreted as such anymore yes. > > Current text: > > The first RRset in the chain MUST contain the TLSA record set being > presented. However, ... > > Proposed text: > > When the server has DNSSEC-signed TLSA records, the first RRset in > the chain MUST contain the TLSA record set being presented. > However, ... > > When the server either has no TLSA records, or its domain is not > DNSSEC-signed, it is RECOMMENDED that the server return a denial > of existence of either the TLSA records, or proof of insecure > delegation at some parent domain, rather than omit the extension. > Clients that are willing to fall back from DANE to some alternative > mechanism may require the denial of existence to make that possible. > I believe that that this text would harm ineteroperability. The difficulty here is what the server knows about the clients behavior. Specifically, if the server serves TLSA records and then ceases doing without serving authenticated denial of existence, then it is unable to determine if this would cause clients to fail because it doesn't know if the client implements the text in the final paragraph. One could argue that current clients could pin, but that's totally extratextual, as opposed t having a noninteroperable behavior in the document. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e56ac60569aede84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 12, 2018, at 6:44 PM, Willem Toorop <willem@nlnetlabs.nl> wrote:
>
> Well... I find it unfortunate that the line you were quoting from
> section 3.4 could be interpreted as prohibiting the possibility of
> denial of existence.=C2=A0 So I am open to relaxing that text so that = it can
> not be interpreted as such anymore yes.

Current text:

=C2=A0 =C2=A0The first RRset in the chain MUST contain the TLSA record set = being
=C2=A0 =C2=A0presented.=C2=A0 However, ...

Proposed text:

=C2=A0 =C2=A0When the server has DNSSEC-signed TLSA records, the first RRse= t in
=C2=A0 =C2=A0the chain MUST contain the TLSA record set being presented. =C2=A0 =C2=A0However, ...

=C2=A0 =C2=A0When the server either has no TLSA records, or its domain is n= ot
=C2=A0 =C2=A0DNSSEC-signed, it is RECOMMENDED that the server return a deni= al
=C2=A0 =C2=A0of existence of either the TLSA records, or proof of insecure<= br> =C2=A0 =C2=A0delegation at some parent domain, rather than omit the extensi= on.
=C2=A0 =C2=A0Clients that are willing to fall back from DANE to some altern= ative
=C2=A0 =C2=A0mechanism may require the denial of existence to make that pos= sible.

I believe that that this text wo= uld harm ineteroperability.

The difficulty her= e is what the server knows about the clients behavior.
Specifical= ly, if the server serves TLSA records and then ceases doing
witho= ut serving authenticated denial of existence, then it is unable to
determine if this would cause clients to fail because it doesn't know= if
the client implements the text in the final paragraph. One co= uld argue
that current clients could pin, but that's totally = extratextual, as opposed
t having a noninteroperable behavior in = the document.

-Ekr


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

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

--000000000000e56ac60569aede84-- From nobody Thu Apr 12 16:11:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D46812DA48 for ; Thu, 12 Apr 2018 16:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 giKGMe06QXBg for ; Thu, 12 Apr 2018 16:11:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D6612421A for ; Thu, 12 Apr 2018 16:11:11 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 45C727A3309 for ; Thu, 12 Apr 2018 23:11:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 19:11:10 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <8860CABD-8627-4E3A-879B-5542E6B79BF5@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:11:16 -0000 > On Apr 12, 2018, at 6:34 PM, Shumon Huque wrote: >=20 > Implementers that are opposed to pinning would then just ignore this = second=20 > draft (and not bother with the authenticated denial part of the first = draft). The pin hint is NOT an obligation on the client or the server. It is = OPTIONAL. Servers can send 0, and clients can just IGNORE the pin. It is far = easier to ignore the additional field, than to specify a separate extension. > Since it=20 > seems pretty clear you're not going to consensus on adding pinning to = the current=20 > draft, I think you should pursue this approach. The consensus call is open until Apr 18th, we may not have heard from = everyone yet... --=20 Viktor. From nobody Thu Apr 12 16:14:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B035512421A for ; Thu, 12 Apr 2018 16:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F_fHy-u5KyV2 for ; Thu, 12 Apr 2018 16:14:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329FE1204DA for ; Thu, 12 Apr 2018 16:14:47 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 14F0A7A3309 for ; Thu, 12 Apr 2018 23:14:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 19:14:45 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:14:49 -0000 > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote: > > The difficulty here is what the server knows about the clients behavior. > Specifically, if the server serves TLSA records and then ceases doing > without serving authenticated denial of existence, then it is unable to > determine if this would cause clients to fail because it doesn't know if > the client implements the text in the final paragraph. One could argue > that current clients could pin, but that's totally extratextual, as opposed > t having a noninteroperable behavior in the document. How exactly does telling the client the truth (conveying correct DNS state about the TLSA records) harm interoperability??? Please explain the scenario in which something now fails??? -- Viktor. From nobody Thu Apr 12 16:47:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4DE126CBF for ; Thu, 12 Apr 2018 16:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dv5IF88m43mL for ; Thu, 12 Apr 2018 16:47:51 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8D9124D6C for ; Thu, 12 Apr 2018 16:47:51 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id d9-v6so7981085oth.10 for ; Thu, 12 Apr 2018 16:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aIIyGqKSVL07bELv1qlABK4F4rSK68JETLz0dX9YklM=; b=oKRnSjuQJj3V9eoGPXaoaeiE0tZWCFPg5V8b621KEKuKWXp8ozW/XT+IA/iBq3ydEf qfvfVgBt4k5r2Ns/QuCFstINoT7u8sv/14yIpmqbUzR5rsrUDdAWsKeJ/Oo0E/hRQzUd sf1udyAzHr3xaYFOsgo0ug6KSAf6KLka/OtOSOjb+lTkGBGInm1hxP8zKBegz9DSCJW0 +ca54A8GcL+kea9kJPYrqhwy+1vtrAvTwcYw/n8YzMeW/VjqoZPzV2Viv7xLFCl5okqR VrA6uaqlFYZjzG98nCkfX6PY20iSulbjvy3wUuZ+pGAzw+wWgSDvws1sBuAFAxUQN4iv PX/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aIIyGqKSVL07bELv1qlABK4F4rSK68JETLz0dX9YklM=; b=WHL7h3xIvSY8CvsOYjlTbQIk43aUo6yt8Q7zCwkkVyxU5VgDy8uL73LVWcPvA8njOv cwltmDieyjtPZ/Dh9dG3jx7b3/8ltWW4BINfRPXk0BIVLOGw4vzFEhBsIc+JWDMnfHtl NduH8QH45Z+ojYLcZNZlz+gz9UNr7SMuxuTDVvvMwt0v28e5d+sPWFy0rOPmVADxnmcl NdnfmA1sMLaY8EbDjNFNdtZNElDJA65yDjtZEeKYqQ5Vcay9FC5/djgXO/rP/FVuFop8 ZZ/OZZJDlIAoUGuZSFu7tqGWrjv4Olxj8IkvG5dSr0NYsUTDJlKCWnGxYNopjRgL/GQW /YDw== X-Gm-Message-State: ALQs6tCs81WOHBTXbichugtIhSaRnYQ3kS2Mhib1UKL1ovlaV65Sx4nQ qur9gX0RrAtxP0V1G4vJxmXQmuiCUoCh/HJrnJrch5fi X-Google-Smtp-Source: AIpwx4+4MHXWcWgrWxrE1dTonGL9mW1bkn6ZgYTvpsHQhcqFQ7Dq/jO8xpDGXTq1Q5dLef5pXPn4iedphBTvz/2hVTQ= X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr2120791oth.217.1523576870528; Thu, 12 Apr 2018 16:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 16:47:10 -0700 (PDT) In-Reply-To: <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> From: Eric Rescorla Date: Thu, 12 Apr 2018 16:47:10 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="00000000000027fd6f0569af62fa" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 23:47:53 -0000 --00000000000027fd6f0569af62fa Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote: > > > > The difficulty here is what the server knows about the clients behavior. > > Specifically, if the server serves TLSA records and then ceases doing > > without serving authenticated denial of existence, then it is unable to > > determine if this would cause clients to fail because it doesn't know if > > the client implements the text in the final paragraph. One could argue > > that current clients could pin, but that's totally extratextual, as > opposed > > t having a noninteroperable behavior in the document. > > How exactly does telling the client the truth (conveying correct > DNS state about the TLSA records) harm interoperability??? > > Please explain the scenario in which something now fails??? > I already did this in my previous email, but I'll try again. In the current document, there is no expectation that clients will pin the server's use of TLSA and therefore the server can safely stop using TLSA (or run a mixed server farm). However, because this text implies that the client *could* pin, in order to ensure interoperability the server would have to provide authenticated denial at the risk of connection failure with such clients. However the text also does not require that the server do so. Thus, a conformant client and a conformant server can fail if the server just stops using TLSA. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000027fd6f0569af62fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 12, 2018, at 7:10 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The difficulty here is what the server knows about the clients behavio= r.
> Specifically, if the server serves TLSA records and then ceases doing<= br> > without serving authenticated denial of existence, then it is unable t= o
> determine if this would cause clients to fail because it doesn't k= now if
> the client implements the text in the final paragraph. One could argue=
> that current clients could pin, but that's totally extratextual, a= s opposed
> t having a noninteroperable behavior in the document.

How exactly does telling the client the truth (conveying correct
DNS state about the TLSA records) harm interoperability???

Please explain the scenario in which something now fails???

I already did this in my previous email, but I'll = try again.

In the current document, there is n= o expectation that clients will pin the
server's use of TLSA = and therefore the server can safely stop using
TLSA (or run a mix= ed server farm). However, because this text implies
that the clie= nt *could* pin, in order to ensure interoperability the server
wo= uld have to provide authenticated denial at the risk of connection
failure with such clients. However the text also does not require that
the server do so. Thus, a conformant client and a conformant server=
can fail if the server just stops using TLSA.

-Ekr


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

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

--00000000000027fd6f0569af62fa-- From nobody Thu Apr 12 18:09:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9FD12D77C for ; Thu, 12 Apr 2018 18:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9w75hcE1TPq4 for ; Thu, 12 Apr 2018 18:08:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B1C1205D3 for ; Thu, 12 Apr 2018 18:08:57 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 25F147A3309 for ; Fri, 13 Apr 2018 01:08:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 21:08:35 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <7E1A7FF7-DF9B-411E-ACE5-2948C4A5A140@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 01:08:59 -0000 > On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote: > > In the current document, there is no expectation that clients will pin the > server's use of TLSA and therefore the server can safely stop using > TLSA (or run a mixed server farm). However, because this text implies > that the client *could* pin, in order to ensure interoperability the server > would have to provide authenticated denial at the risk of connection > failure with such clients. However the text also does not require that > the server do so. Thus, a conformant client and a conformant server > can fail if the server just stops using TLSA. Section 8 already says that some clients may require the extension. Providing denial of existence improves interoperability when all that the client requires is the extension, and given denial of existence might accept something else. Servers that support the extension really ought to provide denial of existence, if that's all they can do. Rather than suppress the extension, if the client demands the extension and the server can't provide it, interoperability is lost either way. If your concern is that the new text is "license" for the clients to arbitrarily require the extension in applications where servers have no reason to expect such behaviour, I have no objection to text that says that "the foregoing does not constitute a license for clients to require the extension where this is not expected application behaviour" or some such. The idea is however to encourage servers to provide the denial of existence, because it may be useful, and is not less interoperable than eliding the extension. Giving license to clients to then expect this from servers is not the intent here. I'm trying to sneak in underhanded pinning. That's not the goal. I'd like to see explicit pinning (or not) hints from the server, so we don't need to play guessing games. Servers that consistently return a TTL of zero would then be at liberty to drop the extension rather than deliver DoE (denial of existence) at any time. In your shoes I'd strongly advocate for the pin TTL, and make sure that it is set to zero by any servers that be sure to avoid the concerns that you're expressing. That way we don't have to play guessing games about client behaviour. -- Viktor. From nobody Thu Apr 12 19:55:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB61243F6 for ; Thu, 12 Apr 2018 19:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PBPHYI-xkjW6 for ; Thu, 12 Apr 2018 19:55:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBB7120227 for ; Thu, 12 Apr 2018 19:55:52 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id F3D237A3309 for ; Fri, 13 Apr 2018 02:55:50 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 12 Apr 2018 22:55:49 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 02:55:54 -0000 > On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote: >=20 > In the current document, there is no expectation that clients will pin = the > server's use of TLSA and therefore the server can safely stop using > TLSA (or run a mixed server farm). However, because this text implies > that the client *could* pin, in order to ensure interoperability the = server > would have to provide authenticated denial at the risk of connection > failure with such clients. However the text also does not require that > the server do so. Thus, a conformant client and a conformant server > can fail if the server just stops using TLSA. Another way of looking at this argument is that we should not recommend that servers should return denial of existence, because if we do, then servers that don't return denial of existence might find themselves less interoperable than those that do. So everyone should be less = interoperable, so not that nobody is relatively disadvantaged. An honest assessment of the situation is that indeed returning denial of existence is more generally interoperable in the face of unknown client behaviour, and so should be recommended as suggested. I am only mildly sympathetic to the slippery slope argument that this may facilitate expectations of such behaviour in clients. We are not here to police future design decisions for fidelity to pure interpretations of the draft. If client expectations are desirable in future applications, and servers co=C3=B6perate, then hooray, we have a specification that meets real world needs. That said, the proposed language is not intended to be ann a-priori license to "pin as you see fit" with no prior application-specific standard defining what constitutes interoperable behaviour. This specification provides a mechanism, not policy. Applications will have to define the relevant policy options. My goal all along has been to make sure that the mechanism is sufficiently flexible to accommodate a range of application policies. [ Thus also the proposal for the additional TTL hint, which supports a broader range of possible policies. ] If you'd like me to craft revised option (A) text, that includes a = suitable caveat, I can try. Or you or someone else can propose an alternative. I only ask that it be honest about the server's options: serving the = denial of existence (DoE) records does interoperate with a broader range of = client policies. In an application where the extension is absolutely optional, i.e. = clients MUST NOT (and do not in practice) expect consistent use by the server, returning the DoE records would not be substantively different from = simply leaving out the extension. The client must be able to function in some fashion with the extension missing, whether legitimately or stripped. In applications where some clients expect downgrade protection the = server returning DoE records continues to work and the one not returning them = might not interoperate with clients that expect to consistently learn the = truth (good news or bad) about the servers TLSA records. Does anyone want to propose better text? --=20 Viktor. From nobody Thu Apr 12 20:15:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16A1205D3 for ; Thu, 12 Apr 2018 20:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brG2j46LIj2o for ; Thu, 12 Apr 2018 20:15:44 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 7FF0A124C27 for ; Thu, 12 Apr 2018 20:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1523589343; x=2387502943; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=joOnVNVjTK3wsyMsjMKZ8EOvkxcS8qqQnMft3XREUEs=; b=0FX8xv3bV2C9sk7eOHeXNtpPztFSh4mrP2BwjwdVMwxTLLrpWMFMk2MgitgL7GtM H+5we4BZ+3AoTeIkjp/yogZVJt+xx/BuQB4UhJIZqfKZ3yDKoQPBAJBiXziMfi3P frAoaX30f8jlUjZimYL2eYSDOHhP1AdYjDjNrJv1CQuEiPZZBMgaA8U2EMO1dRyA B3tEQpaNhwL7eWSrnjo5AeAnvXr4L3LIjKkQcv/xHL54WMBLyES/41Fd7Ir+81gp FAJ3XlDiyscydQ92LDLaI+OpmQQ38RjRd4bdVVDI51wRIMdPYZSWgBbfYfxK81en h3apJv+LWFeby8s1oBp9Gw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id BC.CE.11907.FD020DA5; Thu, 12 Apr 2018 20:15:43 -0700 (PDT) X-AuditID: 11ab0216-325f09e000002e83-42-5ad020df97f4 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 9B.BC.23861.FD020DA5; Thu, 12 Apr 2018 20:15:43 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iZH+qRrAN5MAe0Hs8dNTHw)" Received: from [17.234.29.4] (unknown [17.234.29.4]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P73003BAT265R90@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Thu, 12 Apr 2018 20:15:43 -0700 (PDT) Sender: cawood@apple.com From: Chris Wood Date: Thu, 12 Apr 2018 20:15:42 -0700 Message-id: References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> To: tls@ietf.org X-Mailer: iPhone Mail (15F39) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYpXtf4UKUwdY5yhafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/KdPsaC/RYVp2c/Ymlg3G/YxcjJISFgItF/6yhjFyMXh5DA GiaJf1O2sXYxcoAlVh5VgohvYJI4u2ohE0gDr4CgxI/J91hAbGaBMImph5ayQxTNYZJomPOC DSQhLCAh8XrPRGYQm01AWeLCwYXsIDaLgKrE/W13WCFq/CVO7XrODrKMV8BG4mC3NEhYSMBX omN/IxtIWERAQKL5pRjEnbISew4/Yoewf7JKzF6iN4FRYBaSi2YhuQjC1pL4/qgVKM4BZMtL HDwvCxHWlHh27xNUibbEk3cXWBcwsq1iFM5NzMzRzcwzMtJLLCjISdVLzs/dxAgK4dVMYjsY 7702PMQowMGoxMNbUX0+Sog1say4MvcQozQHi5I477XnjVFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGOO8Tv1p4bx0TdumdM+06ztfeb7dtq0rkSF2t+a5nd/Vt1Ue+3D/2s7AuW3qLslP zlmt1og5UtnD8U8kyTlKVZdLd96fmOS/62oWKscukVvWMIenTmiOrPqrng6/xK7iMPFLYslr +STuzQwx9LvQr1BawD7RZ4Ni5cTqPqWvFlbqexuWbgupVGIpzkg01GIuKk4EAOUr1pxCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FB8Rve+woUogwOP+Sw+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuU7fYwF+y0qTs9+xNLAuN+wi5GDQ0LARGLlUaUuRi4OIYEN TBJnVy1k6mLk5OAVEJT4MfkeC4jNLBAmMfXQUnaIojlMEg1zXrCBJIQFJCRe75nIDGKzCShL XDi4kB3EZhFQlbi/7Q4rRI2/xKldz9lBlvEK2Egc7JYGCQsJ+Ep07G9kAwmLCAhINL8UAwlL CMhK7Dn8iH0CI+8sJFfMQnIFhK0l8f1RK1CcA8iWlzh4XhYirCnx7N4nqBJtiSfvLrAuYGRb xShQlJqTWGmml1hQkJOql5yfu4kRHHKFUTsYG5ZbHWIU4GBU4uGtqD4fJcSaWFZcmXuIUYKD WUmEt1nmQpQQb0piZVVqUX58UWlOavEhRmkOFiVx3pmrj0YJCaQnlqRmp6YWpBbBZJk4OKUa GKOM2Zx5/lbsmDfLcPWj14b1F/pMr7nfU9lfV9T1SjA6IqJ38dKWDb/Xf60KXa1e8cy9rl2h a9HOpMeZJq7vPQ3e624/38/omrlsYY7l0781opdzfbeWdd5N50o0X6pXtac3aK+MQML7ia9s lz1f/j9Qefp1r3A5Xr0vvN6OUn8m+ZzQPv4zX4mlOCPRUIu5qDgRAIZ7acs1AgAA Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 03:15:46 -0000 --Boundary_(ID_iZH+qRrAN5MAe0Hs8dNTHw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi everyone, Below is a pointer to a new I-D describing an approach for clients to request session tickets via a new post-handshake message. This is useful for applications that perform parallel connection establishment and racing, e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses and details are given in the document. We would very much appreciate feedback on the mechanism utility and design. Best, Chris Begin forwarded message: > From: internet-drafts@ietf.org > Date: April 12, 2018 at 8:07:35 PM PDT > To: David Schinazi , Christopher Wood , Tommy Pauly , "Christopher A. Wood" > Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt > > > A new version of I-D, draft-wood-tls-ticketrequests-00.txt > has been successfully submitted by Christopher A. Wood and posted to the > IETF repository. > > Name: draft-wood-tls-ticketrequests > Revision: 00 > Title: TLS Ticket Requests > Document date: 2018-04-12 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-00.txt > Status: https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ > Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests > > > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side per-client state. Servers vend session > tickets to clients, at their discretion, upon connection > establishment. Clients store and use tickets when resuming future > connections. Moreover, clients should use tickets at most once for > session resumption, especially if such keying material protects early > application data. Single-use tickets bound the number of parallel > connections a client may initiate by the number of tickets received > from a given server. To address this limitation, this document > describes a mechanism by which clients may request tickets as needed > during a connection. > > > > > 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 > --Boundary_(ID_iZH+qRrAN5MAe0Hs8dNTHw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi everyone,

Below is a p= ointer to a new I-D describing an approach for clients to request session ti= ckets via a new post-handshake message. This is useful for applications that= perform parallel connection establishment and racing, e.g., via Happy Eyeba= lls. It should also help reduce ticket waste. More uses and details are give= n in the document. 

We would very much appreci= ate feedback on the mechanism utility and design.

B= est,
Chris 

Begin forwarded message:

From: internet-drafts@ietf.org
Date: April 12, 2018 at 8= :07:35 PM PDT
To: David Schinazi <dschinazi@apple.com>, Christopher Wood <cawood@apple.com>, Tommy Pauly <tpauly@apple.com>, "Christopher A. Wood" <cawood@apple.com>
Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt

A new version of I-D, draft-wood-tls-ticketrequests-00.txt
has been successfully submitted by Christopher A. Wood and posted to the
IETF repository.

Name:  = ;      draft-wood-tls-ticketrequests
Revision= :    00
Title:        TLS Tick= et Requests
Document date:    2018-04-12Group:        Individual Submission
Pages:        6
URL:   &nbs= p;        https://www.ietf= .org/internet-drafts/draft-wood-tls-ticketrequests-00.txt
Status:         https://datatracke= r.ietf.org/doc/draft-wood-tls-ticketrequests/
Htmlized: &= nbsp;     https://tools.ietf.org/html/draft-wood-tls-t= icketrequests-00
Htmlized:      = ; https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketreques= ts


Abstract:   TLS session tickets enable stateless connection resumpti= on for
  clients without server-side per-client s= tate.  Servers vend session
  tickets to cli= ents, at their discretion, upon connection
  esta= blishment.  Clients store and use tickets when resuming future   connections.  Moreover, clients should use tickets= at most once for
  session resumption, especiall= y if such keying material protects early
  applic= ation data.  Single-use tickets bound the number of parallel
=   connections a client may initiate by the number of ticket= s received
  from a given server.  To addres= s this limitation, this document
  describes a me= chanism by which clients may request tickets as needed
&nbs= p; during a connection.




Please note that it may take a couple o= f minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.= org.

The IETF Secretariat

= --Boundary_(ID_iZH+qRrAN5MAe0Hs8dNTHw)-- From nobody Thu Apr 12 20:49:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85A124239 for ; Thu, 12 Apr 2018 20:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sI5iOT7sqL4 for ; Thu, 12 Apr 2018 20:49:28 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333761205D3 for ; Thu, 12 Apr 2018 20:49:28 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id c3-v6so7208332oib.5 for ; Thu, 12 Apr 2018 20:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7xXfqW5HnGt14ty4jZRnfnJtDlY5viyqYWye7T3g468=; b=HpKA3G2iv7VtlIDNYITXyOJC9BxSNx3ABRVLDirZyBlIOCMeWCeVQdkwYZ4LOQMrYV b4v8WryBwxXsu1tYsY3St5Ru/NsFQdupHzoIK1JffKf0KChpZpCKm+rrPe2uI/tlA4e3 XBHdRy0PjznV6yZ80Rsl5cN1Lz72DVL3hQMPSJ9TQyB/Jig8BlZsxxnXjk1tcLfZzOG+ OChf4Vg7XxmNQg44+UnStaN2M7RUII1C2lzsFAbmjU80XYvjM067AoVlHQAHORiYHKUF naTJ4RQ+G7/l+ZOo2xPQ/CY7rfbiKYuG+CRrhF+XUHHFrP1AMUWxaHFPHQgTOjTw8Jdk lrEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7xXfqW5HnGt14ty4jZRnfnJtDlY5viyqYWye7T3g468=; b=CQQYf7y6smAYSamDj7lPJbcd//eVCTBsoHd9q23NbJOlZqkIEQhP/x3E9sR70Lp/dN CoDk9Q/dUicpDg70Q7AGtvNQ9IE2Z69N1ArwPFo/A9pN8fqtFFnI/Dg0X9i8UokCN1lS cVfw7ayHTKNK461JzjEfSdjoJDMxUUe4z8nwlXKSO9dKGBL7labsLDYThPI/U8zjHS7d unpfRvHPnKASZEN1WmNj2H8PS+oq8hW49CirGfpthqhflBbNNqpRyToFhFs/ebcOeSkS RedyRJSC9YF3Ts3SWiHaj5wVdiMwSP2Zar3yqFalkQ46NKv/1cBd9c77BjYC0EuGniMI 7S3A== X-Gm-Message-State: ALQs6tD5+hfg4JjllLn0GN5Bw+p+v/Ir/X7UeVD3hpenLIpy7F7rNumM 60Mwbd/VRWbMOvJ5StYreQMKI1sEgYQySEXVJHlJow== X-Google-Smtp-Source: AIpwx4+HoxcIEy5rsENSJrCvxJ1BH2kCrbqs4uPG/HrtUDdwFnCJK/D7RItDstUkzXTNE3BaC8zpx4pFIHDDhiJ0IA0= X-Received: by 2002:aca:c68d:: with SMTP id w135-v6mr7620463oif.215.1523591367338; Thu, 12 Apr 2018 20:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 20:49:26 -0700 (PDT) In-Reply-To: References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Fri, 13 Apr 2018 13:49:26 +1000 Message-ID: To: Chris Wood Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 03:49:30 -0000 Hi Chris, Thanks for sharing this. It's a simple idea and seems generally useful. Do you have a use for the identifier and context? I can see that without them there is no way to distinguish between a response to a request and spontaneous ticket issuance, but I just can't see how that is a problem. I think that you want an extension for this. Otherwise, the server is going to explode when it sees a TicketRequest message. If you have an extension, then negotiating that extension might be used suppress spontaneous ticket issuance. That has a catch though: then a server can't issue new tickets that bind to updated state (such as might happen after a connection migration in QUIC). I don't know how much people care about that trade-off. Sorry I didn't catch these before. Cheers, Martin On Fri, Apr 13, 2018 at 1:15 PM, Chris Wood wrote: > Hi everyone, > > Below is a pointer to a new I-D describing an approach for clients to > request session tickets via a new post-handshake message. This is useful for > applications that perform parallel connection establishment and racing, > e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses > and details are given in the document. > > We would very much appreciate feedback on the mechanism utility and design. > > Best, > Chris > > Begin forwarded message: > > From: internet-drafts@ietf.org > Date: April 12, 2018 at 8:07:35 PM PDT > To: David Schinazi , Christopher Wood > , Tommy Pauly , "Christopher A. Wood" > > Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt > > > A new version of I-D, draft-wood-tls-ticketrequests-00.txt > has been successfully submitted by Christopher A. Wood and posted to the > IETF repository. > > Name: draft-wood-tls-ticketrequests > Revision: 00 > Title: TLS Ticket Requests > Document date: 2018-04-12 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ > Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests > > > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side per-client state. Servers vend session > tickets to clients, at their discretion, upon connection > establishment. Clients store and use tickets when resuming future > connections. Moreover, clients should use tickets at most once for > session resumption, especially if such keying material protects early > application data. Single-use tickets bound the number of parallel > connections a client may initiate by the number of tickets received > from a given server. To address this limitation, this document > describes a mechanism by which clients may request tickets as needed > during a connection. > > > > > 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 > From nobody Thu Apr 12 20:53:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474E126BF0 for ; Thu, 12 Apr 2018 20:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s2eWpn7F9QH for ; Thu, 12 Apr 2018 20:53:38 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E16124239 for ; Thu, 12 Apr 2018 20:53:38 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id o9-v6so8470174otj.5 for ; Thu, 12 Apr 2018 20:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t/rilLoOVEU98PvRhbe8muMpIw590NHmKMGpdsA9YXg=; b=odvPxLeBrPA1fW/Zveqy3NbgpjQN0eJrOZwWzu0DryFNgO2tTEAcXOV1e/gyDdrVdT MSGDuaPdKXrnT4791IrsuWevUtmZko0R/8Av27Vnwfl+lz9XAhwD/K9D8FHStzjJpRtd X7km23vnSratYtWu6Xdd5Fz17qhmTGMYoi48eTofxdeIPV8TA/JGJh49h8/VcM+2dAdZ 0d5n4GtwVz1w3NJMrGsmi+LyIekwATtFsScz3kumaoPTipYtA8BqOoa/uxWX6MEkrYwa NlSVVX9+XGPWRRKVKealQlLtq+6Y1pTHiwC8CkXCiqIl51G86jwdNxrrxy9ue7VZ6It+ eZ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t/rilLoOVEU98PvRhbe8muMpIw590NHmKMGpdsA9YXg=; b=YKy/uu7hMfU1Se0Nwph55wZCSI5BJ59Qy3CD3e10O348mxnw/uaMSqWHw4Am5eX+Yz VMBkMm3ETgFEFLvLKkxpdM49df43Z6vJ4DrTJ19pl4gSKac0R48HCygID581pp2rgyu4 gtCq2J9iVUkjrUwugmfxczhPSvlm7gizFYr6S7GmO9K5OUXtydOohbEOT6vzIAPCehZG 0KQDMMva81Uax3y6ZCsIHp1LoCHSjpUrp5x5WSIpezSSf/56n8uIHELq2m+TO59UghQ7 r7C9xxtl1QOcVsQe49WbUHZarKhQE+jmWX4rRo0p0zv/S9kQsY+iJjnMVLRYRNvJ3DKp ULOQ== X-Gm-Message-State: ALQs6tAlJH5sQ37X1UZD1IXG68k2e3fcjnimEhxcJP6PZmgxxLazG+jy LYl7rPxJ3mWGkXm7uENwLj8Eo/SGfnpY/dzrfp4= X-Google-Smtp-Source: AIpwx48JwDjsKo/STTdpADMRnwIDwGHZ1CSjfZeEOkuywPxdTOi9tNXraKItXB2qv4HIqxeMYKkEDzWtTK1BQcUviCE= X-Received: by 2002:a9d:7405:: with SMTP id n5-v6mr2322857otk.283.1523591617601; Thu, 12 Apr 2018 20:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 20:53:37 -0700 (PDT) In-Reply-To: References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Fri, 13 Apr 2018 13:53:37 +1000 Message-ID: To: Chris Wood Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 03:53:40 -0000 Scrub the bit about needing the extension. I read past Section 4 completely. The other comments are still relevant. On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson wrote: > Hi Chris, > > Thanks for sharing this. It's a simple idea and seems generally useful. > > Do you have a use for the identifier and context? I can see that > without them there is no way to distinguish between a response to a > request and spontaneous ticket issuance, but I just can't see how that > is a problem. > > I think that you want an extension for this. Otherwise, the server is > going to explode when it sees a TicketRequest message. > > If you have an extension, then negotiating that extension might be > used suppress spontaneous ticket issuance. That has a catch though: > then a server can't issue new tickets that bind to updated state (such > as might happen after a connection migration in QUIC). I don't know > how much people care about that trade-off. > > Sorry I didn't catch these before. > > Cheers, > Martin > > On Fri, Apr 13, 2018 at 1:15 PM, Chris Wood wrote: >> Hi everyone, >> >> Below is a pointer to a new I-D describing an approach for clients to >> request session tickets via a new post-handshake message. This is useful for >> applications that perform parallel connection establishment and racing, >> e.g., via Happy Eyeballs. It should also help reduce ticket waste. More uses >> and details are given in the document. >> >> We would very much appreciate feedback on the mechanism utility and design. >> >> Best, >> Chris >> >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Date: April 12, 2018 at 8:07:35 PM PDT >> To: David Schinazi , Christopher Wood >> , Tommy Pauly , "Christopher A. Wood" >> >> Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt >> >> >> A new version of I-D, draft-wood-tls-ticketrequests-00.txt >> has been successfully submitted by Christopher A. Wood and posted to the >> IETF repository. >> >> Name: draft-wood-tls-ticketrequests >> Revision: 00 >> Title: TLS Ticket Requests >> Document date: 2018-04-12 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ >> Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests >> >> >> Abstract: >> TLS session tickets enable stateless connection resumption for >> clients without server-side per-client state. Servers vend session >> tickets to clients, at their discretion, upon connection >> establishment. Clients store and use tickets when resuming future >> connections. Moreover, clients should use tickets at most once for >> session resumption, especially if such keying material protects early >> application data. Single-use tickets bound the number of parallel >> connections a client may initiate by the number of tickets received >> from a given server. To address this limitation, this document >> describes a mechanism by which clients may request tickets as needed >> during a connection. >> >> >> >> >> 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 >> From nobody Thu Apr 12 20:55:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5E6126BF0 for ; Thu, 12 Apr 2018 20:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olcSF9yaEzkx for ; Thu, 12 Apr 2018 20:55:45 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C059124239 for ; Thu, 12 Apr 2018 20:55:45 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id b6-v6so5298419pla.11 for ; Thu, 12 Apr 2018 20:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fro9cq0Abl9MoBMIDMII1edZHPjC1cqtRDzSs5H265A=; b=cQFO1bhtCAoMvhaTCN27BPI6PadRYsIqMcJKthxRqVwnxwHOAmMyZyNnU6wPDfQKnb yw2JKAF4qigylewAGrfIj/0zUXAfes21dzHZiQ4spk1aX2ML/fOz5I2pDuRg78v2Ke8Z Jv1Fdl/r54THjsieIY3WK/kRSnYzlByNBhAqmQtXyDzbO8B9eHpEgxKpoKLZRgd2yTTq Z26AHaJGsGZge/HT9Ii7MRBfotHwZLvYwNFQZ8PG2Ka+bQd3hKu2G4tY7ESPPHo0AKyu 2PaL2vfMMpEu/Cs/c+eIw80NjnS+CccPe4wm4qV4zq6L0AEN19DTAd4EXzeq9KBvAk/d 93Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fro9cq0Abl9MoBMIDMII1edZHPjC1cqtRDzSs5H265A=; b=Lg5k+A3xkwhqIKhKbO7vsJDKW+fbNTKmfyD3KCi67txwW5dbixQZaPIsgQTxpxcCqT cAHucjS8RJK5OAzebpOXryY29yawt5Q74gDIjTjSFO6ClKbegaS26B3ump6bJx2BQvmU tRifoY0p2pRSsOIZuOg4Fe4QHrRPm6hbwx8xytTWDoQ7uFTteqzTElIk6noeqAJdHdNS sN3UdIZYq6GbxEp0XUtzDwR9OCY3v0nVCYZVHHsIHvvq02WLDqyHFd5wt//fF+lrq+Bu 1HxcjVNXFrIZzQmHlHD5AzeRIQo6r3wVWNNQ7iNJIR/PreKFu2Yy3qu/TZIpLe/R7gfX rLGQ== X-Gm-Message-State: ALQs6tDCWyzVIEDHB46npIVTHi472K5JITdJNoEOtVLT9MpHG6s/AQ+5 FdCVu8KjrgsY/ih/MCiiRqxZKaCx X-Google-Smtp-Source: AIpwx4+yuAuKMkf3gNbeb4LHFjxPWUUKY0++MSe/0xihmvTgbNJl1cRUgkcJfS3dn6XHvYQO4X4Scg== X-Received: by 2002:a17:902:20cb:: with SMTP id v11-v6mr3680209plg.82.1523591744721; Thu, 12 Apr 2018 20:55:44 -0700 (PDT) Received: from ?IPv6:2601:647:4280:1565:5028:e94f:382a:731d? ([2601:647:4280:1565:5028:e94f:382a:731d]) by smtp.gmail.com with ESMTPSA id e62sm13242070pfl.117.2018.04.12.20.55.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 20:55:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christopher Wood X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Thu, 12 Apr 2018 20:55:43 -0700 Cc: Chris Wood , "" Content-Transfer-Encoding: quoted-printable Message-Id: <50A44539-4602-41B9-BC98-EF8F9F98B08F@gmail.com> References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> To: Martin Thomson Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 03:55:47 -0000 Hi Martin, Please see inline below. > On Apr 12, 2018, at 8:53 PM, Martin Thomson wro= te: >=20 > Scrub the bit about needing the extension. I read past Section 4 > completely. The other comments are still relevant. No problem. >=20 > On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson > wrote: >>=20 >>=20 >> Do you have a use for the identifier and context? I can see that >> without them there is no way to distinguish between a response to a >> request and spontaneous ticket issuance, but I just can't see how that >> is a problem. Yes =E2=80=94 we=E2=80=99re currently working on an I-D that would use the c= ontext for =E2=80=9Cspecial=E2=80=9D tickets. Depending on where that goes, i= f anywhere, we may or may not need to keep the context. As you suggest, dist= inguishing between responses and spurious NSTs doesn=E2=80=99t *seem* like a= problem. Best, Chris= From nobody Thu Apr 12 21:07:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831E2126BF0 for ; Thu, 12 Apr 2018 21:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qimo61MzxRxw for ; Thu, 12 Apr 2018 21:07:57 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F47B124239 for ; Thu, 12 Apr 2018 21:07:57 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id e123-v6so7213092oih.13 for ; Thu, 12 Apr 2018 21:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+7lj/Z3bX5idvB+dhzEagAloqaIfWJZJI2mPHgy1neo=; b=AsyeS0Nm0y0RYj42GecQ3pWxW3lnzr1Jdd0X3sw5xFL7VzMQbvtI/+xZSndhehikg2 fmdZTJnCdldwmEJovsuFPbXwFwbVZwikbgJ3dIfD98ZFRvLz9NPWAAbSbLdE88Z+h/Zd /jLPzRjqwL+jvehIpl0Nyp8lG5K/la++iZt6GJRnWc2RGFHJbHcAow3LdQ2pj0QCridK mTxEsPdL0KKaKVFqseB1amjxZwtS2M3LzKTA5775m8hzmxz3VeaQIi8AJ+JzaP4Rm7t4 Az3+FN6WwqLAdyXdUoGECyiWmyTRYMxpBBcsiYIILSWK6aw8QZGl5wo/m4xaZSrLuDmI +P9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+7lj/Z3bX5idvB+dhzEagAloqaIfWJZJI2mPHgy1neo=; b=oKDdk6ducU5NwsTR73pGdHqWf0+UWij708sAW7JaYAkSX0T1EEI4gnD0AWk6Gu6Znv j8trZPhHX2bmE31/jww1piGNdghOAcROX4141ZGAe2jOXBy8wWwqGu4TwfFoGkToNpHW w8DTWMaMwfu3eIJZYls0ZJSDNW275CNkyTa9ow+AbCDn/4FHYiZr+VQAnEbJSx+9Ic52 TY0ebTQKeAh2QRXqBoCzcsTUYZMERf2++6Pu0qV81S37RefD3+E+tUfnqUAXPbU2Pj6M A5Ghg67EslytML3ClinDDVPX/B4E4SxewrtyDjfPpxvIHUZAOx7nb5/ciHSL8d7jrCIO vWqg== X-Gm-Message-State: ALQs6tBNM4pU+Un97wulnbfGG+HqKNEE5kCXX3ubEy0YMe4GHTsuwcgM Irv0O8DUzxE4mmlAs6WT08mniCxfqlnFR6iMBdc= X-Google-Smtp-Source: AIpwx4/RHKSMO9w7zYeGxnnt2Edm43+XzuZkmgUFT7eoEjgHu+lbld9OIjtDaCUcKxDDXurk/IaSCacInRN1ezTkQwg= X-Received: by 2002:aca:4ac2:: with SMTP id x185-v6mr6934606oia.295.1523592476349; Thu, 12 Apr 2018 21:07:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 21:07:55 -0700 (PDT) In-Reply-To: <50A44539-4602-41B9-BC98-EF8F9F98B08F@gmail.com> References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> <50A44539-4602-41B9-BC98-EF8F9F98B08F@gmail.com> From: Martin Thomson Date: Fri, 13 Apr 2018 14:07:55 +1000 Message-ID: To: Christopher Wood Cc: Chris Wood , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 04:07:58 -0000 On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood wrote: > Yes =E2=80=94 we=E2=80=99re currently working on an I-D that would use th= e context for =E2=80=9Cspecial=E2=80=9D tickets. Depending on where that go= es, if anywhere, we may or may not need to keep the context. As you suggest= , distinguishing between responses and spurious NSTs doesn=E2=80=99t *seem*= like a problem. Maybe the right way to deal with this is to put an extensions block in the request. Then you only have to resolve the question of whether NST answers the ClientHello or this new message... From nobody Thu Apr 12 21:08:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9912D86C for ; Thu, 12 Apr 2018 21:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2mEcWl8v_0D for ; Thu, 12 Apr 2018 21:07:59 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46575124239 for ; Thu, 12 Apr 2018 21:07:59 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c78so5461695pfj.6 for ; Thu, 12 Apr 2018 21:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XQwGsk25pbqQz6373PtsdCalkex8nnGvMK89jyh/lss=; b=wxjqH/Hfq/RVnAZVmVyJOBCUefn+L6gEquV/GC/rb52V60H6hWc8N3LGkrm1rVCkfC 4u7aXSJTjI8QpY6DyjjAM7G0HWPv3OebkKTO59bSOTbJXbD8OrCPOA9BOFA9D4gGTLeE dNBhbCc9u/4mT9uUPIvQ3sMc5w/wZVndlthWKm0KJdYujIkXwq+8dtWtjZM7YyXj1h1x 2GRhTUUEiIhRgrDYmemFUxZvQ1/roXDIAHzsLBI6El1iqDlwWtgOsskIrxmvdy2EfxOS ipDxsWvbyfCt5h5BJZavxmT8d+7VKiShabo1ynLieAe+C/4kuq9GBA3QEwfm/w3BfWcd et9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XQwGsk25pbqQz6373PtsdCalkex8nnGvMK89jyh/lss=; b=ovFhxX0x6+ShlQBqhoJqq1mk7fIxrIUA9gVITiVeCldvobeeXpvmjdG2QAxOulC4ti fo2rBPEtkOkODcJwBJLOrCE2WvaKcgGX4kJnnK7dolCPjz2s/ubf0w+Pr/iN3qJLhDzY hRPNAMeFZ6rvwKKuHmWrbGHguKJ4h47lV+GE2qwQlBJPEwsgERATjp8L2Ju7NExSQikq ZoKcvaH/mOp0dcrLtYRtfX2K1gS507aIPKGfviLcppY6rT7lJjL9D/7CqhAYc7FHjpOd 7DSHKRi5hQ2AEjNaNLnAxY+5YCrqycyvodUMAycU4HFLI8aGq+a9I/E+xudd6CeS0rQQ 0tFQ== X-Gm-Message-State: ALQs6tAHzoEdh2GLO4djQNpb9XSXdr/M2EMh5ABQnaoO4f/+o+jmqC2S Cr3cPoKoFGfdenoiHHw6vLIWPec= X-Google-Smtp-Source: AIpwx4+TO85uN4m2qQrZXo7QfTB8RVR8y2HepWueyOKPSwPPoQUpYFeahfJEPDN7I+EyErhMWb0TJA== X-Received: by 10.98.100.198 with SMTP id y189mr2166458pfb.245.1523592478244; Thu, 12 Apr 2018 21:07:58 -0700 (PDT) Received: from aspen.local (216-67-115-161-radius.dynamic.acsalaska.net. [216.67.115.161]) by smtp.gmail.com with ESMTPSA id g26sm8639067pfh.183.2018.04.12.21.07.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 21:07:57 -0700 (PDT) To: tls@ietf.org References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PsLBlwQTAQoAQQIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaWd0AhkB AAoJEN+4kXKadtuPmvIQAJvVNnT0qhltq35AQ9Z1Ipx1IkEcQ8+yyMNLgyV9ZYhn9wn9JS/C TSb7HDSyTRiIz8CnaiCIOn2ZpT3sgYFw3cijT6YfRiifCeu4z3ea+XXOA/VyqXo42ARWOvq3 XdY3uj/j1c39PvhbopUwhulHzFJL7cMJCLEws588HdLwT8GVe+aTFPP4buJRqpOM0kSr/gkN 1IYKI0x1w6NgsgrYjCnv/VUwThjcVWPwMvZStvBnGquE6tvEmlnY+5cRktKSFw4X1ijxKzJD m0iqg7P7gNjC0r5uR2fF6BC0OPo9txPnabYph1wZ7V/5gnDwtWimD0ER77EO5Mr3zZHzva5v EwDpEbKXI43XAfpbxz3uc2fmXE2cvOCFgY/fTpX4kjVaxyFvjf1zrsac/7qFzwvgotYrYSc+ E1Ts+n1hWwsDA+qw/9reE1z9w+sn7SKL7zlS9sV54rfcd1AT0aMwlhAkEOaXRutriQ9BWWOv TOZBtRuV5RO/ZieY7lLX2+na2LjxLyak9k6wYwQwKvzvovBrr8zwDfJQDQujdVhk/lrlngAw Qh/U9dOg2hTUNiFHbKe1N+4vNCW/aLqm33LEV/vK/KepGsTl1ezQotOr0d05h2QySsdAgLCX Gv7bb+wTl/8Yx8hZfZO68KoRk8Zy4Yz8kE5LWJir+QQC7m7oo/4wZZcIzsFNBFppZ0gBEACg ZuM18ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1 YZ0OpQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR3 5FAgSnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fE ZHM66phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQ V0yBgc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4 cztvgmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRH RvQs0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBj Ltx1tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI 7qDHFxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnY jMJodU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABwsF8BBgBCgAmFiEET2gtkyoXlvgg8jTA 37iRcpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ7 5iY5pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiF PjkrQIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/J YK75BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApM LL0R/qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV 5abZ+iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJR i+cH7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7 Vz9F+6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloS bbMvP9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjx uLzdLY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+3 1fk1HKwqd9xRxC8= Message-ID: Date: Thu, 12 Apr 2018 20:07:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:08:02 -0000 On 4/12/18 6:55 PM, Viktor Dukhovni wrote: > If you'd like me to craft revised option (A) text, that includes a suitable > caveat, I can try. I'm okay with putting denial-of-existence in there as a should, but I do feel strongly that pinning belongs in a separate document. As I said earlier, I have a problem with putting features in protocols that nobody intends to use. It's bad enough when it happens by circumstance but doing it deliberately strikes me as a bad idea. And while this may not be your problem, it's very much mine: this kind of thing is bad for the IETF. It discourages participation (and, ironically, implementation) and it slows the process down further, with no clear benefit (getting back to the implementation question). I've gotten an earful from several implementers about this, and it concerns me. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Thu Apr 12 21:14:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858B126BF0 for ; Thu, 12 Apr 2018 21:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWkVp9AZ3mWQ for ; Thu, 12 Apr 2018 21:14:08 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48016124239 for ; Thu, 12 Apr 2018 21:14:08 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id f132so212329pgc.10 for ; Thu, 12 Apr 2018 21:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKAQssOC0P+zRw1oZVOManpF2OHSpGGoUA2HcEyo+ao=; b=tgwAvAykPtiUdKS3sD4d1xKI4EXe9f/LLlTNHf7JqsrqLC2A9gYrxGJSmguDWpsCuQ MdEJoXRKq+1yFbsJaK1mvaf7u2c5aIx7K9oLBitrEDULqgqqOHautuA8Fk30DvHB1iDt Oo0TGkaSWyNcLMss2cklZHSG8z7MrIGflBVzuZX93yijaagre5d/jrZ2ibHaY65XwAuW CnLUI6eqOUtM7pUo4VnfJIIdn72ARTBnHUTCv+LvUzkF/Qn5kQPKG8qz6t+icZytmoZU uImoI0YmvhVLUePUs8W6Ydi9l3h7MEGkU/DK8qTk4qPOh1P2J3DVXi7rOhC4kFkIDuFr pzSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKAQssOC0P+zRw1oZVOManpF2OHSpGGoUA2HcEyo+ao=; b=e3mDIZOge/f3+IH1u1YjQ/UWMpzUEcSCsOp0S+TJxKMkcQKSAqAuQjbaHlCjEFm1kn VGMMQMK/mC7nvfim88O+Cktrm+qPwng7IiAYb6mjMpcgIWfvGTBwGUrNcJQcLA8nrImK OtATAHpNTFPr2DeYp+hYb4J7+sA5O3jCVIdFwvEb5kz86Wf15jcKr89eyYk4ruTnKIiY YNEOGTfsytjDsVKfzrCP/8r0KNaAl57f0yRO3nWMvMc+q99x9kFz3dnyarTBxX16XP8f j01s8L0qs0GsHSnWIuZfH+b4l/nOkDSKOR7mzJL/LDS2V1QrWbEsd1mt2uEgKiP17v2H W1Fg== X-Gm-Message-State: ALQs6tC+CSfTq/Kd6mAXZvje6TL9WZzkjo9MS3Y2XDWjVrD2uXtEvKng V/dVVt/8v6cGFly4UuKPDb8= X-Google-Smtp-Source: AIpwx483HVb2vYPQamSaK2wf60Wu8OUFMsDU9AA73SgC0HKb0bZiY2XFZNu1foWFB/trLJxZd2LA9g== X-Received: by 10.99.149.21 with SMTP id p21mr2848727pgd.154.1523592847481; Thu, 12 Apr 2018 21:14:07 -0700 (PDT) Received: from ?IPv6:2601:647:4280:1565:5028:e94f:382a:731d? ([2601:647:4280:1565:5028:e94f:382a:731d]) by smtp.gmail.com with ESMTPSA id n73sm12253881pfb.108.2018.04.12.21.14.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 21:14:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christopher Wood X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Thu, 12 Apr 2018 21:14:06 -0700 Cc: Chris Wood , "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> <50A44539-4602-41B9-BC98-EF8F9F98B08F@gmail.com> To: Martin Thomson Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 04:14:09 -0000 > On Apr 12, 2018, at 9:07 PM, Martin Thomson wro= te: >=20 > On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood > wrote: >> Yes =E2=80=94 we=E2=80=99re currently working on an I-D that would use th= e context for =E2=80=9Cspecial=E2=80=9D tickets. Depending on where that goe= s, if anywhere, we may or may not need to keep the context. As you suggest, d= istinguishing between responses and spurious NSTs doesn=E2=80=99t *seem* lik= e a problem. >=20 > Maybe the right way to deal with this is to put an extensions block in > the request. Then you only have to resolve the question of whether > NST answers the ClientHello or this new message...=E2=80=99 Indeed. That might work just as well, if not better.=20 In any case, as written right now, we prohibit servers from sending spurious= NSTs if both parties negotiate request support. If implementations honor th= at requirement, we won=E2=80=99t have a distinguishing problem. We then need= only decide what is the best encoding strategy for request identity/context= , if desired.= From nobody Thu Apr 12 21:43:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D57126BF0 for ; Thu, 12 Apr 2018 21:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4d7mcy2zS7Pn for ; Thu, 12 Apr 2018 21:43:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22006124239 for ; Thu, 12 Apr 2018 21:43:26 -0700 (PDT) Received: from [10.90.70.160] (unknown [38.86.168.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D53197A3309 for ; Fri, 13 Apr 2018 04:43:25 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 13 Apr 2018 00:40:41 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:43:29 -0000 > On Apr 13, 2018, at 12:07 AM, Melinda Shore = wrote: >=20 > I'm okay with putting denial-of-existence in there as a should, > but I do feel strongly that pinning belongs in a separate document. > As I said earlier, I have a problem with putting features in = protocols > that nobody intends to use. It's bad enough when it happens by > circumstance but doing it deliberately strikes me as a bad idea. The great irony of the situation, is that present draft already describes pinning: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. And I've seen no discussion or working group consensus to *prohibit* such pinning, only observations that it would be rather fragile in general. What my proposal (B) (really (C), since (B) requires (A) as a = foundation) provides first and *foremost* is the ability for servers to DISABLE pinning, by giving clients an upper bound pinning TTL of 0. If you don't want to see pinning, voice your support for (B) (really C) and have servers send a TTL of ZERO! Keep in mind that the proposed TTL is an upper bound, it is NOT an obligation to pin, and therefore is always a restriction on pinning, while at the same supporting a signal that pinning may be safe at the server's discretion. So this both serves the overall interoperability objectives voiced by Eric Rescorla, allows servers to disavow any pinning and supports future cases. It is a win-win, and carries ZERO implementation cost, on the server, if pinning is explicitly unwanted, just the field to zero and move along. On the client if no pinning is desired, just ignore the TTL. This feature is a win/win and carries no implementation burden, and the document is about to get a revision for (A) and still awaits an IANA code point assignment. If we act promptly on both (A) and (B) (i.e. (C)) there'll be zero additional delay. I sympathize strongly with the desire to keep specifications lean and mean, but that desire is misplaced here. The technical details do matter, and both supporting DoE and setting a max "pin" TTL are well motivated, improve interoperability and allow the server to opt-out of the sort of fragile ad-hoc pinning described in the draft. So please, let's not allow the general argument to deafen us to the specific context of this document. Though it needs at least (A) it also needs (B) (i.e. (C)). --=20 Viktor. From nobody Thu Apr 12 21:51:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE4126DFB for ; Thu, 12 Apr 2018 21:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 wcTu5tdgO0lb for ; Thu, 12 Apr 2018 21:51:53 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FAF124239 for ; Thu, 12 Apr 2018 21:51:53 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id m22-v6so8536248otf.8 for ; Thu, 12 Apr 2018 21:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QXWbvJdT4f+5hplBJ/9qbieVR8IvT5f/VZTbWwB2DJc=; b=tH7CImft/2JZDKyZ5uuklZdk3fmIJ6Qe5uYT2lkN1UkvIOF+A01jRNuUgbPgACTCXm oAsOVzxWlLf+nu0O8sLeteQHmctta/g6iPHiHNRcYmBfHDx1n7WdL5r+Ia9kNoh9tok1 ndYbiyAAvshub7JbP7qyeigH0oyNJjn2YxDobNWUm86oAqkwZcBd5TWWgLOBARO4suGk ea6fYsfzaaOG02xPP0BL+9AWPmkh4GTBWkeGSVCkpFft3x1o14ydk44jdVjlHjdBKbz3 VRtzUNMqHZzrdymJBjf/87Njznl8QWSC0Psv3sCYZqECZ3G/IvXilxVyTi7j+RdX/NeC 1p+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QXWbvJdT4f+5hplBJ/9qbieVR8IvT5f/VZTbWwB2DJc=; b=tlUw/+pHnsVHMlUH3QNFjnBmfonZqV/FNVASYM8op6K4CkrYfo42ThVCKsIUnaehp+ +w4ltNN7LYH6+Km0YuCowPE6vugDGjzRR/IXIEbdbMRXZEoII2wwt/pG/e/DnFzl+OGd fTdEVcrRB6IUtgb2AeOqzSCK1L4aRy8l+2SziI7iBMBWKgd7dayMkkfrqPtBrwcKH1v9 sLoYiw9y4lE7iDh80nx0Glc8O9JURZBSzK/Mqdz31wRb432xUd+qg+CPWGII7vuiJ/Jz 1p4gA30MyvkeB38apikcwmffGuBKKgBRCJSPrHf7Nt2fKd3rSvgcjGyzgSAKXEIMUtIV OGKQ== X-Gm-Message-State: ALQs6tAW58aoON12G0v8Wtnj58S6DXW7AfrpRRX77KjWFR2kqHNQ+9sb pkWkAFcHzCReL4qjytvm9PqG1fIn7cVhKEsO9Q1lW90o X-Google-Smtp-Source: AIpwx48dYqTerK5Nkay/iDpngG9eX2fiL92XMxI3lCRFxIwNae+7b/iGfj30hMzUMfrQBVmFaO3p3fl3a+sj4x3oBmw= X-Received: by 2002:a9d:e06:: with SMTP id c6-v6mr2741885otc.371.1523595112539; Thu, 12 Apr 2018 21:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 21:51:12 -0700 (PDT) In-Reply-To: <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> From: Eric Rescorla Date: Thu, 12 Apr 2018 21:51:12 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="00000000000076fd500569b3a10c" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:51:56 -0000 --00000000000076fd500569b3a10c Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni wrote: > > > On Apr 13, 2018, at 12:07 AM, Melinda Shore < > melinda.shore@nomountain.net> wrote: > > > > I'm okay with putting denial-of-existence in there as a should, > > but I do feel strongly that pinning belongs in a separate document. > > As I said earlier, I have a problem with putting features in protocols > > that nobody intends to use. It's bad enough when it happens by > > circumstance but doing it deliberately strikes me as a bad idea. > > The great irony of the situation, is that present draft already > describes pinning: > > If TLS applications want to mandate the use of this extension for > specific servers, clients could maintain a whitelist of sites where > the use of this extension is forced. The client would refuse to > authenticate such servers if they failed to deliver this extension. > > And I've seen no discussion or working group consensus to *prohibit* > such pinning, only observations that it would be rather fragile in > general. > Thanks for pointing this out. I agree that this text is likely to cause interop problems and should be removed or at least scoped out in the case where client and server are unrelated. I regret that I didn't catch it during my IESG review. -Ekr --00000000000076fd500569b3a10c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

> On Apr 13, 2018, at 12:07 AM, Melinda Shore <melinda.shore@nomountain.net> wrote:
>
> I'm okay with putting denial-of-existence in there as a should, > but I do feel strongly that pinning belongs in a separate document. > As I=C2=A0 said earlier, I have a problem with putting features in pro= tocols
> that=C2=A0 nobody intends to use.=C2=A0 It's bad enough when it ha= ppens by
> circumstance but doing it deliberately strikes me as a bad idea.

The great irony of the situation, is that present draft already
describes pinning:

=C2=A0 =C2=A0If TLS applications want to mandate the use of this extension = for
=C2=A0 =C2=A0specific servers, clients could maintain a whitelist of sites = where
=C2=A0 =C2=A0the use of this extension is forced.=C2=A0 The client would re= fuse to
=C2=A0 =C2=A0authenticate such servers if they failed to deliver this exten= sion.

And I've seen no discussion or working group consensus to *prohibit* such pinning, only observations that it would be rather fragile in
general.

Thanks for pointing this out. = I agree that this text is likely to cause
interop problems and sh= ould be removed or at least scoped out in
the case where client a= nd server are unrelated. I regret that I didn't
catch it duri= ng my IESG review.

-Ekr

<= /div> --00000000000076fd500569b3a10c-- From nobody Thu Apr 12 22:41:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B5812D7F5 for ; Thu, 12 Apr 2018 22:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zL2qyHK89M9q for ; Thu, 12 Apr 2018 22:41:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D185126D45 for ; Thu, 12 Apr 2018 22:41:25 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 53B177A3309 for ; Fri, 13 Apr 2018 05:41:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 13 Apr 2018 01:41:23 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <283A3EA9-614A-4CD2-8D81-E3EA3E1D71BF@dukhovni.org> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 05:41:27 -0000 > On Apr 13, 2018, at 12:51 AM, Eric Rescorla wrote: > > Thanks for pointing this out. I agree that this text is likely to cause > interop problems and should be removed or at least scoped out in > the case where client and server are unrelated. I regret that I didn't > catch it during my IESG review. Well (B) is a proposal for doing just that, making it possible for servers to suppress any such pinning, but it also allows for future use-cases in which pinning might be desirable. If we're revising the text anyway, and given that implementors suffer no burden to insert (on the server) or ignore (on the client) an extra two bytes in the extension, (so Melinda's issue of added complexity is not a barrier here), the sensible responsive change is to add support for (B) with a requirements that clients not pin longer than requested, and servers should generally set the TTL to zero, unless pinning is understood to be fit for purpose in the given application, and the operator is willing to commit for the indicated time. -- Viktor. From nobody Fri Apr 13 08:26:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF4126D73 for ; Fri, 13 Apr 2018 08:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 ut1BpWLUYHt0 for ; Fri, 13 Apr 2018 08:26:42 -0700 (PDT) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2BB126D0C for ; Fri, 13 Apr 2018 08:26:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 7B08C29E74 for ; Fri, 13 Apr 2018 11:26:37 -0400 (EDT) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TPWs4TyhTss for ; Fri, 13 Apr 2018 11:26:37 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-174-63-85-75.hsd1.ma.comcast.net [174.63.85.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA for ; Fri, 13 Apr 2018 11:26:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A9D2EC6062; Fri, 13 Apr 2018 11:26:35 -0400 (EDT) From: Sam Hartman To: tls@ietf.org Date: Fri, 13 Apr 2018 11:26:35 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:26:43 -0000 I realize I'm not following the TLS working group. I was asked to review this issue by someone who was confused and hurt by the current process and was asking for a less involved opinion. Since I took the trouble to review the document, to review a good chunk of the current list discussion, I decided to share my opinions. I understand that I'm coming at this late. There are both advantages and disadvantages to this. I will answer the questions, but I ask you to please focus more on my analysis of the proposed change than my answers to the question. I don't think I have anything special to bring to the answers to the questions other than the opinion of someone who is trying as hard as they can to inform themselves. I do think an outsider's evaluation of some of the assumptions and implications of the change may help others make up their mind. 1) Do you support publication in its current form? No. I thought I was going to have to quibble about the question and say that while I supported bringing the document back to the WG I wouldn't go so far as to say I didn't support publication. However, reading the discussion, there are key statements related to the scope of this document that based on current discussion don't seem to have consensus now even though they mmay have had consensus in the past: * The scope discussion in the introduction, particularly pointing out that this document is applicable to web browsers and SIP seems very much under debate in the current discussion. * Section 8 states that using this extension in a TOFU manner would be a reasonable thing to do. I think that absent a mechanism to limit the scope of pinning or to securly move away from this extension that claim is harmful to interoperability and ultimately security. So, even if all we do is remove that text in the introduction and remove the TOFU claim, I think a change is worth the cost. 2) Do you support denial-of-existence proofs and TTL for pinning? Yes, I think this work would be valuable; here's why. First I'd like to explain my understanding of the assumptions under which this change is valuable. You don't need this change if you have reliable client configuration. Reliable client configuration can come in an application where this extension is mandated. That is, you know all your code supports this extension and you know you're being deployed with TLSA records signed up to a trust anchor that the client supports. So say you're only deployed on the public DNS in signed zones. Alternatively reliable client configuration could come in a list of sites that are known to support this extension that is centrally managed. Without that reliable configuration, you won't be able to rely on this extension to improve security for first contact. That's true with or without the proposed changes. With the proposed changes you could implement TOFU semantics in a manner that I and the proponents believe is operationally viable. I think that will provide enhanced security under the following assumptions: * Clients talk to server more than once * There is sufficient value in protecting second and follow-on sessions that mittigation is valuable even though we'll never protect the first session * We trust the DNS root more than our X.509 PKI, or at least we gain enhanced security by validating against both * Clients are willing to pin security information--namely that a given server uses this extension * We're talking about an application where we cannot mandate use of this extension. Remember that you need to mandate not only code support that people actually deploy only with signed dnssec zones and TLSA records before you can mandate the extension. I think those assumptions are common enough that it is worth fixing the problem. That said, I'd like to disagree with Victor on one point. I think for any change there is nontrivial work to be done to get it right and there is a potential downside. His cost analysis seems to imply that there's no chance we'll make things worse with the change and that the only cost is delay. In my discussions, I quickly came across a number of issues surrounding how the proposed changes would interact with private DNS that were more complex than the person asking me to review implied. Victor may have considered all those issues, but I think there is a cost to the change. I think it is worth paying, but I'd urge people to be a bit more realistic about the potential cost of making a mistake or making it more likely people will reduce interoperability by complicating the spec. In conclusion, in ranked order, I prefer: 1) Working on Victor's changes 2) Removing the scope text and TOFU language 3) the current spec 4) no spec ever on this topic From nobody Fri Apr 13 08:36:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0F126D73 for ; Fri, 13 Apr 2018 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 0vc8D4gON_TY for ; Fri, 13 Apr 2018 08:36:49 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37BF126D05 for ; Fri, 13 Apr 2018 08:36:48 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id z8-v6so8758021oix.2 for ; Fri, 13 Apr 2018 08:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUVFxpSpcnb0LsZWxeTClvrFLO5zinVSMZvVLx72jk0=; b=o247bklm6ic4oZcMPE+3qaXpAoqK8vpE39z6UWV8/Ugmc6zBu2hgFZCEASW0LZoBrF BHkgRkAejy+mQWZwrdX/fjcWbb0J0ym+UnCImudEShvMr6UjbL5KxYjE6ohzOTeVBx6/ rj4eFFBlFGgfPaYpbovwV1Y9vmfXvNjn2JVViNVOSJ7W4UR16T0Qi8Zh4O6AzUT1O/9x O5UwetvOhsNx8wjPk59yXxi9YPANNVjw534agrLDRr26SwvakrmndvwEB2GLM0lMTO2R EyIj3j4RcFZFO+vNEdExbcJ/c6Tm/nJRrRCjNv9a0ssTgVaL8v5m3TSIV9M4ie32MWDf efJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VUVFxpSpcnb0LsZWxeTClvrFLO5zinVSMZvVLx72jk0=; b=oCtICtEih1aRNOABRDjwKqr1oWqltZbLMtWiqrgidjPveNhZjYhYV5CJrWsO/jOW4b IGHB0mnBdQPxP/Q98nukaFKhnWT+rPMWuzacYP5rthugclJycPlG/pOIbHKR7mNy1xSR EScfOiY93LctBc0NInbZjI+dYgFFFduVd40UBvxBENQNEyWjMjREC4kI+DaaoeAGbWIt qsfNAHPRN7U6Uxev3lKdtca7LTDFMtAZA4S7WP6HKEKyUA3Z+WVIzHosGCavPslSkiya QKKejfOKWqEgSnSz6XbTKn2qmtnyHRYAIzd1Gi04NSsoZokJ57uh1QtQ/Zbxyg4olDQw zpmA== X-Gm-Message-State: ALQs6tDHckrfvoMeHyyxuNtRKdYo86P0nZpgFY1eLrUJXHE5jPM2AmjV 6VRQRnQRuPD1XLRUn7m4LAGerXQRbyvnrxHZ/c/tKE1+ X-Google-Smtp-Source: AIpwx49CT3jk/J9Ok2b5QC4hsvaKYIFlo0c81VcmXH3RaVa8LLg4sg4bjTU/Y5BlSuXYG1SIa++NWa9zB0vBhPQUgQg= X-Received: by 2002:aca:c592:: with SMTP id v140-v6mr9083094oif.92.1523633808354; Fri, 13 Apr 2018 08:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 08:36:07 -0700 (PDT) In-Reply-To: <07edc5ce-6f06-5cba-4f15-17b2352ea076@netmagic.com> References: <07edc5ce-6f06-5cba-4f15-17b2352ea076@netmagic.com> From: Eric Rescorla Date: Fri, 13 Apr 2018 08:36:07 -0700 Message-ID: To: trutkowski@netmagic.com Cc: "" , Benjamin Kaduk , cybersupport@etsi.org Content-Type: multipart/alternative; boundary="000000000000ea48680569bca399" Archived-At: Subject: Re: [TLS] Middlebox Security Protocol initial drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:36:51 -0000 --000000000000ea48680569bca399 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, Thanks for forwarding these. I haven't had time to give them a thorough review, but on a quick skim I notice that this seems to be based on TLS 1.2 and to use a bunch of algorithms we are trying to deprecate (e.g., CBC). Is there a reason not to start with TLS 1.3 and more modern algorithms? -Ekr On Fri, Apr 13, 2018 at 8:07 AM, Tony Rutkowski < trutkowski.netmagic@gmail.com> wrote: > As everyone is aware, the decision was taken > within the IETF TLS community not to undertake > work perceived to compromise TLS 1.3 and related > protocols. At the same time, there has been > recognition that a considerable number of use > cases exist where alternative transport, network > and application layer implementations are > necessary in both network infrastructures and data > centres. > > The work on those alternative implementations has > proceeded over a two year period in ETSI's Cyber > Security Technical Committee (TC CYBER). In the > spirit of some level of collaboration between ETSI > and the IETF community, as well as public > transparency, CYBER is making available two draft > parts of a Technical Specification called the > Middlebox Security Protocol. The motivation is to > address one of the most difficult security > challenges today: how to enable network operators > and end-users to cooperate in managing encryption > security for their applications. The drafts are > available at: > > https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts > > Note that there are two problems being pursued > here. The Middlebox Security Protocol enables the > existence of a =E2=80=9Csmart proxy=E2=80=9D where end-users can > be potentially aware of a middlebox in their > traffic stream (visibility) and control what that > middlebox sees for different purposes > (observability). The result allows for balancing > privacy, network operations, and security for > different applications. With the Protocol, both > users and providers gain the ability to grant or > restrict the permissions for visibility and > observability. > > Part 1 of the Middlebox Security Protocol > specification defines the generic capabilities and > security requirements. Additional parts define > specific implementations in the form of profiles > for different use cases that can be mapped to the > Part 1 requirements. > > Part 2 provides a common profile for widespread > network use known in the research community as > mcTLS. Included with Part 2 are a patch for a > known vulnerability as well as an exemplar of use > by Mobile Network Operators. Other profiles will > be released over the coming months =E2=80=93 especially > one for data centre access control to meet the > critical needs of enterprise network communities. > > These initial two draft specifications are > relatively complete and stable, and derived from > best-of-breed solutions drawn from extensive > surveys and evaluation of the considerable > published technical literature. However, this > work is new, complex, and unique. > > In addition, TC CYBER is proactively sending the > drafts to other industry standards bodies as well > as holding a Hot Middlebox Workshop (12 June 2018) > and Hackathon (12-13 June 2018), in Sophia-Antipolis > France, where the coding community can seek to > implement and hack a test implementation of Part 2. > It is all open, and free. > > In addition to collaboration and comments on this list, > comments are also solicited at cybersupport@etsi.org > > --tony r > > > --000000000000ea48680569bca399 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

Thanks for forwardi= ng these.

I haven't had time to give them a th= orough review, but on a quick skim I notice that this seems to be based on = TLS 1.2 and to use a bunch of algorithms we are trying to deprecate (e.g., = CBC). Is there a reason not to start with TLS 1.3 and more modern algorithm= s?

-Ekr




On Fri, Apr 13, 2018 at 8:07 AM, Tony Rutkowski <trutkowski.= netmagic@gmail.com> wrote:
= As everyone is aware, the decision was taken
within the IETF TLS community not to undertake
work perceived to compromise TLS 1.3 and related
protocols.=C2=A0 At the same time, there has been
recognition that a considerable number of use
cases exist where alternative transport, network
and application layer implementations are
necessary in both network infrastructures and data
centres.

The work on those alternative implementations has
proceeded over a two year period in ETSI's Cyber
Security Technical Committee (TC CYBER). In the
spirit of some level of collaboration between ETSI
and the IETF community, as well as public
transparency, CYBER is making available two draft
parts of a Technical Specification called the
Middlebox Security Protocol.=C2=A0 The motivation is to
address one of the most difficult security
challenges today: how to enable network operators
and end-users to cooperate in managing encryption
security for their applications.=C2=A0 The drafts are
available at:

https://docbox.etsi.org/CYBER/CYBER/Open/= Latest_Drafts

Note that there are two problems being pursued
here.=C2=A0 The Middlebox Security Protocol enables the
existence of a =E2=80=9Csmart proxy=E2=80=9D where end-users can
be potentially aware of a middlebox in their
traffic stream (visibility) and control what that
middlebox sees for different purposes
(observability). The result allows for balancing
privacy, network operations, and security for
different applications. With the Protocol, both
users and providers gain the ability to grant or
restrict the permissions for visibility and
observability.

Part 1 of the Middlebox Security Protocol
specification defines the generic capabilities and
security requirements. Additional parts define
specific implementations in the form of profiles
for different use cases that can be mapped to the
Part 1 requirements.

Part 2 provides a common profile for widespread
network use known in the research community as
mcTLS.=C2=A0 Included with Part 2 are a patch for a
known vulnerability as well as an exemplar of use
by Mobile Network Operators. Other profiles will
be released over the coming months =E2=80=93 especially
one for data centre access control to meet the
critical needs of enterprise network communities.

These initial two draft specifications are
relatively complete and stable, and derived from
best-of-breed solutions drawn from extensive
surveys and evaluation of the considerable
published technical literature. However, this
work is new, complex, and unique.

In addition, TC CYBER is proactively sending the
drafts to other industry standards bodies as well
as holding a Hot Middlebox Workshop (12 June 2018)
and Hackathon (12-13 June 2018), in Sophia-Antipolis
France, where the coding community can seek to
implement and hack a test implementation of Part 2.
It is all open, and free.

In addition to collaboration and comments on this list,
comments are also solicited at cyb= ersupport@etsi.org

--tony r



--000000000000ea48680569bca399-- From nobody Fri Apr 13 09:26:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C9127333 for ; Fri, 13 Apr 2018 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 ftQ46kxJKW9T for ; Fri, 13 Apr 2018 09:26:48 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2256F1201FA for ; Fri, 13 Apr 2018 09:26:48 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id t16-v6so8896517oih.3 for ; Fri, 13 Apr 2018 09:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68xi8XMThHzSwwbYGPUnmdsKuzWkCZSS1McPiQFspsc=; b=CCbRQH+/olI+18sTb33BaBd5PId01ZsHjSVMB8cNC8I6AClyjR/QTqJmqDcmHuA3N7 uVIU8wzAZPjTbdB6Z3JnIun9mYNQfy7ztvnosZR0W6yBDoSMGD7AKWMHNaEe2t6ysGmx Ld8s5AFK/lng1jch7f/OKEEGQ21dv5ib6zkrM96SkpJA7kCb43I+Yepu72+H/w56WuvL WJahI7VTqfKqa/gLnIGY6ybd7Vc8aVjnWpQv7FURta7SxjOreECwWJeZJ/Xu32PwDvQq Jrv6zb5t9Ck705QoeejiIhNrI3b/UN4QTR64dT8l9wfC15ufquu3SQSJ+7QAlEomltYq Kmdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68xi8XMThHzSwwbYGPUnmdsKuzWkCZSS1McPiQFspsc=; b=ftQ+ORL+T8Qf3zamVnjwh0grJXkYNlNROAWQUKN+v//G5xgQPPDgefmU+2Dkway607 kK1WJeVAue687l0laLjrkPai+JsHhSb44rDtBCj35SaUT+BTmNc9mJKrz9q8bAKv2tco ZAXnx0QEHzdtzwb9WHIoh6E1gAsI9euQbrJ7+rrAVyw+8vSXJzg6NT/5JHUzf1dULq+E HIZR3RQlzYCcagvmt1veji0zQa7NLAir5HuOdROBM22y3ejFaNbg2vpIe7hUu+IFEYFC 1Npyd5/IuZelgk9MvKofMHXCN86ruSbBjA7fLDYvo+8RhDNXw+OhUKUEoGs5FjHuYtiy Qo+g== X-Gm-Message-State: ALQs6tDUzSmPNDgiC/CNWbhaEAB2Xu96mGQB0WJ26c7/9rfpIZlxmRPA O25dfATd/GT5MioXVyKMI1sXQRKp6B4U95pogYKu5Q== X-Google-Smtp-Source: AIpwx4+AsE1HsMRvQE6hKOHwVAolKqhvOnsIVXyLmiowpyTg3E9/qTHZNjQIrb917T3qgBu9B4RT09kRf4NhYlE2rvU= X-Received: by 2002:aca:cc53:: with SMTP id c80-v6mr9030003oig.174.1523636807509; Fri, 13 Apr 2018 09:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 09:26:07 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 13 Apr 2018 09:26:07 -0700 Message-ID: To: Tony Rutkowski Cc: "" , Benjamin Kaduk , cybersupport@etsi.org Content-Type: multipart/alternative; boundary="000000000000adb2050569bd56d4" Archived-At: Subject: Re: [TLS] Middlebox Security Protocol initial drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:26:51 -0000 --000000000000adb2050569bd56d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable n Fri, Apr 13, 2018 at 9:19 AM, Tony Rutkowski < trutkowski.netmagic@gmail.com> wrote: > Good observation. When the work started, 1.3 was a work in progress and > the rapporteurs wanted to move forward with an initial test of concept > based on considerable published work out there. In addition, the use of > 1.2 will be around for many years if not forever in some environments. > I certainly agree that this is true, but given that you're designing a new protocol, it's not clear to me that the installed base is that relevant. I also don't think this addresses the question of algorithms, given that TLS 1.2 supports modern algorithms -Ekr The idea is to start a momentum for enabling middlebox visibility and > traffic observability (Part 1), and then rolling out and encouraging > multiple profiles. > > To give credit here, the concepts are those of pioneers like David Naylor > and Justine Sherry. (Her slogan that "middleboxes are the drama queens of > networking" has become legend.) > > Tony > > On Apr 13, 2018 11:36 AM, Eric Rescorla wrote: > > Hi Tony, > > Thanks for forwarding these. > > I haven't had time to give them a thorough review, but on a quick skim I > notice that this seems to be based on TLS 1.2 and to use a bunch of > algorithms we are trying to deprecate (e.g., CBC). Is there a reason not = to > start with TLS 1.3 and more modern algorithms? > > -Ekr > > > > > On Fri, Apr 13, 2018 at 8:07 AM, Tony Rutkowski < > trutkowski.netmagic@gmail.com> wrote: > > As everyone is aware, the decision was taken > within the IETF TLS community not to undertake > work perceived to compromise TLS 1.3 and related > protocols. At the same time, there has been > recognition that a considerable number of use > cases exist where alternative transport, network > and application layer implementations are > necessary in both network infrastructures and data > centres. > > The work on those alternative implementations has > proceeded over a two year period in ETSI's Cyber > Security Technical Committee (TC CYBER). In the > spirit of some level of collaboration between ETSI > and the IETF community, as well as public > transparency, CYBER is making available two draft > parts of a Technical Specification called the > Middlebox Security Protocol. The motivation is to > address one of the most difficult security > challenges today: how to enable network operators > and end-users to cooperate in managing encryption > security for their applications. The drafts are > available at: > > https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts > > Note that there are two problems being pursued > here. The Middlebox Security Protocol enables the > existence of a =E2=80=9Csmart proxy=E2=80=9D where end-users can > be potentially aware of a middlebox in their > traffic stream (visibility) and control what that > middlebox sees for different purposes > (observability). The result allows for balancing > privacy, network operations, and security for > different applications. With the Protocol, both > users and providers gain the ability to grant or > restrict the permissions for visibility and > observability. > > Part 1 of the Middlebox Security Protocol > specification defines the generic capabilities and > security requirements. Additional parts define > specific implementations in the form of profiles > for different use cases that can be mapped to the > Part 1 requirements. > > Part 2 provides a common profile for widespread > network use known in the research community as > mcTLS. Included with Part 2 are a patch for a > known vulnerability as well as an exemplar of use > by Mobile Network Operators. Other profiles will > be released over the coming months =E2=80=93 especially > one for data centre access control to meet the > critical needs of enterprise network communities. > > These initial two draft specifications are > relatively complete and stable, and derived from > best-of-breed solutions drawn from extensive > surveys and evaluation of the considerable > published technical literature. However, this > work is new, complex, and unique. > > In addition, TC CYBER is proactively sending the > drafts to other industry standards bodies as well > as holding a Hot Middlebox Workshop (12 June 2018) > and Hackathon (12-13 June 2018), in Sophia-Antipolis > France, where the coding community can seek to > implement and hack a test implementation of Part 2. > It is all open, and free. > > In addition to collaboration and comments on this list, > comments are also solicited at cybersupport@etsi.org > > --tony r > > > > > --000000000000adb2050569bd56d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
n Fri, Apr 13, 2018 at 9:1= 9 AM, Tony Rutkowski <trutkowski.netmagic@gmail.com> wrote:
Good observation. When the work started, 1.3 was a work in = progress and the rapporteurs wanted to move forward with an initial test of= concept based on considerable published work out there.=C2=A0 In addition,= the use of 1.2 will be around for many years if not forever in some enviro= nments.

I certainly agree that this = is true, but given that you're designing a new protocol, it's not c= lear to me that the installed base is that relevant.

I also don't think this addresses the question of algorithms, given = that TLS 1.2 supports modern algorithms

-Ekr

The ide= a is to start a momentum for enabling middlebox visibility and traffic obse= rvability (Part 1), and then rolling out and encouraging multiple profiles.= =C2=A0=C2=A0

To give credit he= re, the concepts are those of pioneers like David Naylor and Justine Sherry= . (Her slogan that "middleboxes are the drama queens of networking&quo= t; has become legend.)
=

Tony

On Apr 13, 2018 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi Tony,

Thanks for forwarding these= .

I haven't had time to give them a thorough r= eview, but on a quick skim I notice that this seems to be based on TLS 1.2 = and to use a bunch of algorithms we are trying to deprecate (e.g., CBC). Is= there a reason not to start with TLS 1.3 and more modern algorithms?
<= /div>

-Ekr



<= /div>

On Fri,= Apr 13, 2018 at 8:07 AM, Tony Rutkowski <trutkowski.netmagic@= gmail.com> wrote:
As everyone is aware, the= decision was taken
within the IETF TLS community not to undertake
work perceived to compromise TLS 1.3 and related
protocols.=C2=A0 At the same time, there has been
recognition that a considerable number of use
cases exist where alternative transport, network
and application layer implementations are
necessary in both network infrastructures and data
centres.

The work on those alternative implementations has
proceeded over a two year period in ETSI's Cyber
Security Technical Committee (TC CYBER). In the
spirit of some level of collaboration between ETSI
and the IETF community, as well as public
transparency, CYBER is making available two draft
parts of a Technical Specification called the
Middlebox Security Protocol.=C2=A0 The motivation is to
address one of the most difficult security
challenges today: how to enable network operators
and end-users to cooperate in managing encryption
security for their applications.=C2=A0 The drafts are
available at:

https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts=

Note that there are two problems being pursued
here.=C2=A0 The Middlebox Security Protocol enables the
existence of a =E2=80=9Csmart proxy=E2=80=9D where end-users can
be potentially aware of a middlebox in their
traffic stream (visibility) and control what that
middlebox sees for different purposes
(observability). The result allows for balancing
privacy, network operations, and security for
different applications. With the Protocol, both
users and providers gain the ability to grant or
restrict the permissions for visibility and
observability.

Part 1 of the Middlebox Security Protocol
specification defines the generic capabilities and
security requirements. Additional parts define
specific implementations in the form of profiles
for different use cases that can be mapped to the
Part 1 requirements.

Part 2 provides a common profile for widespread
network use known in the research community as
mcTLS.=C2=A0 Included with Part 2 are a patch for a
known vulnerability as well as an exemplar of use
by Mobile Network Operators. Other profiles will
be released over the coming months =E2=80=93 especially
one for data centre access control to meet the
critical needs of enterprise network communities.

These initial two draft specifications are
relatively complete and stable, and derived from
best-of-breed solutions drawn from extensive
surveys and evaluation of the considerable
published technical literature. However, this
work is new, complex, and unique.

In addition, TC CYBER is proactively sending the
drafts to other industry standards bodies as well
as holding a Hot Middlebox Workshop (12 June 2018)
and Hackathon (12-13 June 2018), in Sophia-Antipolis
France, where the coding community can seek to
implement and hack a test implementation of Part 2.
It is all open, and free.

In addition to collaboration and comments on this list,
comments are also solicited at cybersupport@etsi.org

--tony r





--000000000000adb2050569bd56d4-- From nobody Fri Apr 13 10:02:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6C7124234 for ; Fri, 13 Apr 2018 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhsekC4HomLG for ; Fri, 13 Apr 2018 10:02:18 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189771241F3 for ; Fri, 13 Apr 2018 10:02:18 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 78C1A2004CA0F; Fri, 13 Apr 2018 10:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=fhgtG3kKDmTXCQ BcG9Wk9GPa7Wg=; b=SGFmos2/ArtDc5jgpnAaYeMz1TMAlcIP99Z+W+FaLuFwan sQhdJXbpLmI3Bn4LjJuXTsWYRhZjg6bEJ6dCIPdizeeSTKhTY3mQFgQfdPUCJ6P5 Leay+ytTLt2d747odlb8T+WEAXtBgRosau9M10j1ciZFdp5ks/+KDm1w8PX5g= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id CF1892004CA0E; Fri, 13 Apr 2018 10:02:16 -0700 (PDT) Date: Fri, 13 Apr 2018 12:01:14 -0500 From: Nico Williams To: Paul Wouters Cc: Benjamin Kaduk , "" Message-ID: <20180413170112.GV25259@localhost> References: <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:02:19 -0000 On Thu, Apr 12, 2018 at 04:40:25AM -0400, Paul Wouters wrote: > On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > > >I don't really agree with that characterization. To state my understanding, > >as responsible AD, of the status of this document: this document is in the > >RFC Editor's queue being processed. > > That was a process mistake. > > 1) ekr filed a DISCUSS > 2) other people raised issues in response > 3) ekr's DISCUSS was resolved but not the other people's concern > 4) document was placed in RFC Editor queue despite this > 5) TLS consensus call done on the list > 6) here we are.... > > I think it is not good to use this process as a way of approving things. > A process mistake was made. Yes, though this consensus call cures that (and moots that grounds for appeal). However, since it's become clear that the I-D undeniably has a problem because it describes pinning behavior and lacks sufficient functionality for that -- we really must now make a change. IMO, the question is no longer whether to make changes, but which changes to make. Nico -- From nobody Fri Apr 13 11:50:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AFD127775 for ; Fri, 13 Apr 2018 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 ik4MjfYysItn for ; Fri, 13 Apr 2018 11:50:07 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDF9127601 for ; Fri, 13 Apr 2018 11:50:07 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id i5-v6so1492650oth.1 for ; Fri, 13 Apr 2018 11:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SL7q2BszXqXC/PEnvjBKtljdZAQ6Pek9mgOlqyyuQqw=; b=Z8CVksf/Mbx/Nxg029nFnTJkJRVX6RtsS0EFkgGXPaTm9p1SaMvIgoL5e/tcrWAkP4 3dLRvDU8iflJFzEWo4ERmN9zw/ZPATpVAH2q/e9x0941b2fFE9w3byBm+zDgp1IPlYYs DlNn7cXf/1wp7RHQwVxD2cDt0yn/HzOrgdAe+NdkkJDHyaPFl6Ev9GVNyYdndFO+n0uL 75YULUkhq2HpNYodfeqNM9D1tNWGNb9UA7r4Lrnerqo0z37WRDVNJgiCm6w79KXgzf7m tp2lpy2Fn1I2sI2UZw3fHxbSg2iT4i0nz0hhcIWEAQN8l82hVnMAdU6khbBBGMobjuCE pGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SL7q2BszXqXC/PEnvjBKtljdZAQ6Pek9mgOlqyyuQqw=; b=WMlatJk+IIa9gbPl1D4MWyjH1sQndzLtYcO4sn/gHgd6yV1cNe6U+d9+ri4XPAneSS KQm3emAKsZi4lOYOr/uiekIjMe5pRfqdZbF1RNzdzX7hlXDoGed2emC8p0LXzeN/ikEF aoUdrPo8c5QUqzkuC+QjiZHIVLrGOBGoDZOHM3yB7eRAGWt4IAGOXcDDFuOMZFqHdb9v FT1zEgOalBV+i1zJJfNSlBRuNlwCpZzzRdRDNRehQOnh7KP/9oHcS/dwud22P4b1ebqy Vhf94tU0VR/HHZjNraJeQm7MSmG8grjMu2j1jL3/C8YWeo7iSJ5lFkTdXq593f7ouRyP ZcMA== X-Gm-Message-State: ALQs6tD2zLwRy24d9hw4h1b1697qgxGhy+rxVYYmnUBGrOGvMmMsY13I IKSQVqx08OYegSr1JEiPHjw6wac8kBrG3M8ZHh9enwgl8qw= X-Google-Smtp-Source: AIpwx4++UEG2wMacloGxLflNgtG6WBdCPsUwzu2JgpXLUszCpPA827hyZX/yHjHTKrKLGm7PKAfRsYng1YZ2TOqBLKU= X-Received: by 2002:a9d:1361:: with SMTP id q30-v6mr4592351otq.103.1523645406188; Fri, 13 Apr 2018 11:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Fri, 13 Apr 2018 11:50:05 -0700 (PDT) In-Reply-To: <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> From: Richard Barnes Date: Fri, 13 Apr 2018 14:50:05 -0400 Message-ID: To: Tony Putman Cc: "" , Benjamin Kaduk , Watson Ladd Content-Type: multipart/alternative; boundary="0000000000003378650569bf577b" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 18:50:11 -0000 --0000000000003378650569bf577b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Tony, Thanks for the comments. Hopefully we can adapt this document to tick more boxes for you :) Since I had noticed some other errors in the document (e.g., figures not rendering properly), I went ahead and submitted a new version that takes these comments into account. https://tools.ietf.org/html/draft-barnes-tls-pake-01 Some responses inline below. On Thu, Apr 12, 2018 at 9:23 AM, Tony Putman wrote: > Hi Richard, > > > > I work in the IoT space and am interested in handshakes that involve > little computation but offer better protection than symmetric PSK in the > event of server breach. > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Richard Barnes > *Sent:* 11 April 2018 15:54 > > [=E2=80=A6] > > We would love to hear any feedback on the approach proposed here, and on > whether other people here would be interested in working on a PAKE > mechanism for TLS in this working group. > > [=E2=80=A6] > > > > I was interested in this draft as it seemed to tick some boxes, and I > offer some comments below. But in the end I don't think it offers what I'= m > looking for, so I can't offer to help with it in its current form. > > > > My main comment is that I disagree with the assertion in section 3 that > "w" is effectively a salted password hash. An attacker who obtains "w" ca= n > impersonate the client to the server, so it is equivalent to a password. > The only advantage is that a server breach cannot be extended to other > servers where the user uses the same password, but different salts are > used. It seems to me that SPAKE2+ prevents this, so perhaps this should b= e > used instead. > > > > Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client > to know the salt. This seems unreasonable to me unless there is also some > mechanism to retrieve the salt from the server. Could the salt be a hash = of > client identity and server identity? (I suspect there is not enough entro= py > in this). But in any case I think this is an issue which must be addresse= d > in the draft. > I'm not a cryptographer, but it seems to me that combining the client and server identities would probably provide enough salt. After all, the idea of salt is just to make add a small degree of multiplicity to the hash. Your point about SPAKE2+ / having the server only store public keys is probably superseding, though. I agree that we should try to arrange this protocol so that the server only has to store a verifier value, but it's not totally clear whether SPAKE2+ is needed, or whether we can use SPAKE2 and just have the server cache w*N. After all, both w and N are fixed over multiple runs of the protocol, so it doesn't seem like there's much benefit to storing w and not w*N. Given all that, I think my proposal would be: - w =3D H( client identity || SNI || password ) (probably by extending the IdentifierAndPassword struct that's in the document now) - Client stores w or takes identities/password as input - Server stores w*N Maybe Ben or Watson (CCed) could comment on whether this approach seems sound. > Why does the draft need to specify what the identity of the server is? It > doesn't seem to be used. > The identity field that the server sends isn't intended to be the server's identity, but rather to indicate which of the client's offered identities the server has selected. The design pattern here is the same as the key_share extension in TLS 1.3, where the server sends back a (group, key share) pair, and the group identifies which of the client's shares the server is using. https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#key-share > > Would it be helpful to send a list of SPAKE2Shares in ClientHello? For > example, if the application layer protocol is being negotiated, would it = be > necessary to supply shares for multiple protocols? Alternatively, if the > client and/or server support multiple pre-provisioned values (G, M, N, H)= , > how would this be signalled/managed? And would there be associated securi= ty > concerns? > The ClientHello extension in the document (SPAKE2ClientHello) already allows the client to send multiple SPAKE2Shares. Note, however, that the only thing that can be negotiated is which identity/password is to be used. The current document assumes that the group (and thus G, M, N) and the hash function (H) are fixed / pre-negotiated based on the identity. I can understand why people might want negotiation, but it does seem safer to me to only ever use a given password with the same group and hash. It's also consistent with the "server stores w*N" approach above. > It is worth noting explicitly somewhere that x and y should have the same > ephemeral characteristics as are used by the key_share elements, and that > if this is followed then forward secrecy is provided by SPAKE2. > Agreed. > IMHO "w" should not be used as the PSK input. If somebody gets hold of a > derived key (e.g. early_exporter_master_secret) then the low entropy of "= w" > may allow it to be recovered. "K" provides all that's needed for key > derivation. > > Agreed. Using "w" in the key schedule also means that the server has to have it. As noted above, this is bad. > The draft should recommend somewhere (security section?) that H should be > suitable for password hashing (e.g. Argon2) and not a standard hash > function. This is particularly true if my earlier suggestion to use SPAKE= 2+ > is followed. > Agreed. --Richard > > > Regards, > > Tony > > > > Dyson Technology Limited, company number 01959090, Tetbury Hill, > Malmesbury, SN16 0RP, UK. > This message is intended solely for the addressee and may contain > confidential information. If you have received this message in error, > please immediately and permanently delete it, and do not use, copy or > disclose the information contained in this message or in any attachment. > Dyson may monitor email traffic data and content for security & training. > --0000000000003378650569bf577b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Tony,

Thanks for the com= ments.=C2=A0 Hopefully we can adapt this document to tick more boxes for yo= u :)=C2=A0 Since I had noticed some other errors in the document (e.g., fig= ures not rendering properly), I went ahead and submitted a new version that= takes these comments into account.


Some responses in= line below.

On Thu, Apr 12, 2018 at 9:23 AM, Tony Putman <Tony.Putman@dyson.co= m> wrote:

Hi Richard,

=C2=A0

I work in the IoT space and am interested= in handshakes that involve little computation but offer better protection = than symmetric PSK in the event of server breach.

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54

[=E2=80=A6]

We would love to hear any feedback on the approach p= roposed here, and on whether other people here would be interested in worki= ng on a PAKE mechanism for TLS in this working group.

[=E2=80=A6]

=C2=A0

I was interested in this draft as it seem= ed to tick some boxes, and I offer some comments below. But in the end I do= n't think it offers what I'm looking for, so I can't offer to help with it in its current form.

=C2=A0

My main comment is that I disagree with t= he assertion in section 3 that "w" is effectively a salted passwo= rd hash. An attacker who obtains "w" can impersonate the client to the server, so it is equivalent to a password. The only advantage is th= at a server breach cannot be extended to other servers where the user uses = the same password, but different salts are used. It seems to me that SPAKE2= + prevents this, so perhaps this should be used instead.

=C2=A0

Secondly, SPAKE2 is fitted to the TLS 1.3= handshake by forcing the client to know the salt. This seems unreasonable = to me unless there is also some mechanism to retrieve the salt from the server. Could the salt be a hash of client identity and = server identity? (I suspect there is not enough entropy in this). But in an= y case I think this is an issue which must be addressed in the draft.


I'm not a cryp= tographer, but it seems to me that combining the client and server identiti= es would probably provide enough salt.=C2=A0 After all, the idea of salt is= just to make add a small degree of multiplicity to the hash.
Your point about SPAKE2+ / having the server only store public = keys is probably superseding, though.=C2=A0 I agree that we should try to a= rrange this protocol so that the server only has to store a verifier value,= but it's not totally clear whether SPAKE2+ is needed, or whether we ca= n use SPAKE2 and just have the server cache w*N.=C2=A0 After all, both w an= d N are fixed over multiple runs of the protocol, so it doesn't seem li= ke there's much benefit to storing w and not w*N.

<= div>Given all that, I think my proposal would be:

= - w =3D H( client identity || SNI || password ) (probably by extending the = IdentifierAndPassword struct that's in the document now)
- Cl= ient stores w or takes identities/password as input
- Server stor= es w*N

Maybe Ben or Watson (CCed) could commen= t on whether this approach seems sound.

=C2=A0=

Why does the draft need to specify what t= he identity of the server is? It doesn't seem to be used.

=C2=A0
The i= dentity field that the server sends isn't intended to be the server'= ;s identity, but rather to indicate which of the client's offered ident= ities the server has selected.=C2=A0 The design pattern here is the same as= the key_share extension in TLS 1.3, where the server sends back a (group, = key share) pair, and the group identifies which of the client's shares = the server is using.



=C2=A0

Would it be helpful to send a list of SPA= KE2Shares in ClientHello? For example, if the application layer protocol is= being negotiated, would it be necessary to supply shares for multiple protocols? Alternatively, if the client and/or server support= multiple pre-provisioned values (G, M, N, H), how would this be signalled/= managed? And would there be associated security concerns?


The ClientHello ex= tension in the document (SPAKE2ClientHello) already allows the client to se= nd multiple SPAKE2Shares.=C2=A0 Note, however, that the only thing that can= be negotiated is which identity/password is to be used.=C2=A0 The current = document assumes that the group (and thus G, M, N) and the hash function (H= ) are fixed / pre-negotiated based on the identity.=C2=A0
I can understand why people might want negotiation, but it doe= s seem safer to me to only ever use a given password with the same group an= d hash.=C2=A0 It's also consistent with the "server stores w*N&quo= t; approach above.

=C2=A0

It is worth noting explicitly somewhere t= hat x and y should have the same ephemeral characteristics as are used by t= he key_share elements, and that if this is followed then forward secrecy is provided by SPAKE2.


Agreed.
=
=C2=A0

IMHO "w" should not be used as = the PSK input. If somebody gets hold of a derived key (e.g. early_exporter_= master_secret) then the low entropy of "w" may allow it to be rec= overed. "K" provides all that's needed for key derivation.


Agreed.=C2=A0 Using "w" in the key sch= edule also means that the server has to have it.=C2=A0 As noted above, this= is bad.

=C2=A0
<= div>

The draft should recommend somewhere (sec= urity section?) that H should be suitable for password hashing (e.g. Argon2= ) and not a standard hash function. This is particularly true if my earlier suggestion to use SPAKE2+ is followed.


Agreed.
=
--Richard

=C2=A0

=C2=A0

Regards,

Tony

=C2=A0


Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.

--0000000000003378650569bf577b-- From nobody Fri Apr 13 12:16:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2C12785F for ; Fri, 13 Apr 2018 12:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=bluepopcorn.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 PSFLKzHp8ato for ; Fri, 13 Apr 2018 12:16:50 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC4112783A for ; Fri, 13 Apr 2018 12:16:50 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w3DJGmQi004777 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 13 Apr 2018 12:16:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1523647010; bh=dBHc3khiF0e7YMvWqkXl5Q9W4dQKNjABNZF+1YGTQvY=; h=Subject:To:References:From:Date:In-Reply-To; b=cDaMHOGEL21E7CWJlJBrEEcbNoBiLp+K04RG2kxVhk7frJhwu+G8IidAjSsBxLdob ksiqCIBHxx0iEANbS6rRYLlaNtXt8XfwyvUaCeEG/Wxul81cUY5fyz8wGG+BZqcHMQ VUHq1BrjU8hbosX/6c8ifkcxQXZZXcKe8uf1ClS4= To: tls@ietf.org References: From: Jim Fenton Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= xsFNBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABzStrZXliYXNlLmlv L2ppbWZlbnRvbiA8amltZmVudG9uQGtleWJhc2UuaW8+wsF6BBMBCgAkAhsDAwsJBwMVCggC HgECF4ADFgIBAhkBBQJZldiTBQkJKTzQAAoJEBslqLAV0J++/8AP/0T3XoGmX4c12LSjeBeh fAE9gydAHT8ny70yyhcxc/E7deDksmdRW9DBMBdXiN1HSxIJBPsUDl2KXvityxjOAJcorS63 tQ2aE6LcywaguWJ/SswJEWWkCxL3T4VTo5iprGdSW3khj3TmWZjqLGqoTobVDtfjdXeW0193 dnFjzoOA9OHmm7T0ifhRp2fKcQaO2bGtDSFjQYVolGWdNaLZHG7Ayb0HkDGHFGmIqQuiWgZl EGTwSsPY6b2Eov2mB+KN+aqvvrNqOwHHLfyMnuZAt4IUyPkjPGKntRPMAg+5h7JJOwnmlgRZ VW8/W43XWOlqHVjxKD/NKp9TV052opZR/swgLi67LXldBelTRmcc+6B1oXw9KwZ5WInBIVxL tFc5JfevZTHOCaTkUX7ATzygUBkhv6e+nuTCUOygv0gSVSLEeuTh3cJDXvLSjzWIanNqE93I Y859fv7/if5x76ljuynVXBza6yryQCLEYCz0Kj7hIMsRrS7bHTLQicoMlU0ZU9HIZareJGmJ dTspX2is9up+CrTAioYGejoyJJdG2ygaTxJAHhCWXJtMIXptSfFFzZXG+7vPJKFQ3MksD24q gRYII1cJa9Ddj6Wad9ZjR67ntOg87SFloJ+tTqF7mbgHVJZ1feyElU1oYvCxy1kMuE52yxOe lxoV9AvbYOSZfH+7zsFNBFJNz0MBEADBlpdizc7MaWmq9IfcdH0aNLMh4/QSawEKOl8h1ltA HBDdlESIwYic3FX7GR2MsODRy2tbNQJR7emVZ7k0mSmOqb4oxzsYqHJ5YnkxlG1WuHRWkVOq LxTBg9a6YBioTXL9TWZ7/Mel8b0QPB1JioyQ8XvoXLlb6+Fk/YgsppjypZIvIfxM+XmYUYHK l9PxDpS7OVGzZpNuxO0Ff+rAfuDO0xElKNC1ijbQCoKAEEcgD/TFXmoMfsJVjIrI9Di0ktDz /HJPKxRLl97CuPyVmj8b1Jo20LcIS+sljDIDSe9gHr6Ek8yow/+3JFcz/1djeo7hXG5z6bl9 htNlrkZgBk024Hl2+ojVTSwVNYERukB5puoJDjRmcVKP63W0G7B+Ph7L+gnvxZHKDn5VO88p FG5s6ZlyfOPnJ9NLdUbEBlvg2yPVLZ/cos/Rn4K/h23z3cjYlZMKHDuMDWiYXRBNBoGrXjSf Tzg8Wd0Ee52tndzP4A8Lz2KJ7YdDiMZCV1dlecbJIeceUD5ZTJn3CA6mVb0XhD8umzVue6Hl W209Wk1+NfyGJXjxqX5v663id/NcCuKkhFYXdMvvb/omqAQo2FErJGfRLoGJ2J5LIdbOolHd GiL9g1O/JfIuHqLqO0HJvcVueFh//2iWhsOmPQT6RN6YuvCjCt7zmDC6lKmGqXNVJQARAQAB wsFlBBgBAgAPAhsMBQJZldidBQkJKTzaAAoJEBslqLAV0J++ZvIQAMKYNCPNmYQ2Y1JyWeaO k7PohRPkEXphuFxtnJHOiiSSaSMmUB4MaxywOkAJ5vJTu+NllLcL2WjVBqyzhwVtcbVoHHKk +fL5oJ4Mf+Rr/JJa6NO1knFFhnRS9Cfm9DoWU++1w6hTR3xp5FqoRI/y6LTwdMzF+4lkH2EO voGvyJKdt4iK999UFloSWW7OuuVOfylY0vVuvkpE/UGPdty1z+Xr8GvRkoajS9vYLnEPb9CY MWnFitBLGe6xR/2+ysmUeKiS8OYY8c7PalvV0pZ9iqBZTXjSK+z4+Y/Y51LroyR53B3eGOdM HeCoDfd/aPeD960PLkzmVvOzt9jGj8/ggR33SqqAJL95iEAAmWsJCwts2KiN7scdGTUTD9gC LcwbwKDFkSdDMk+nuzRT7rYRPokOAGorb6wknAmbi3RBSH4raBQ11HZ+oOzl16RrEue4AuR8 XJmdH7IPUsMPfA4mwk0PpmDcwKw1U5YCMpDkGL9nhGfyVyccVz8eBa5wDBl04bXhTBY5gGZy begFLusTjnAIXhLR7HfEEI9yPShssw8c4KwkUG0qnHEflwb2W9rsqnVhHD61bjBAE2SX0/pc EyBpZw1gPkRKsD02PZJvebepjW4r/nTfiHOj6yjxiTrgHRmDT3DS9ettiwf15WjfXmdIuWgX 747WdW48X4EpMmWU Message-ID: Date: Fri, 13 Apr 2018 12:16:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------920FC77BBCD36A3E276EE0CE" Content-Language: en-US Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 19:16:53 -0000 This is a multi-part message in MIME format. --------------920FC77BBCD36A3E276EE0CE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I haven't been following this WG closely but read the draft and discussion to see what this was all about, so here's an opinion from a somewhat external reviewer, not in the room in London: On 4/4/18 10:50 AM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the=C2=A0draft-ietf-tls-dnssec-chain-extension. The question before the= > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > -=C2=A0Recommendation of adding denial of existence proofs in the chain= > provided by the extension > - Adding signaling to require the use of this extension for a period > of time (Pinning with TTL) =46rom reading the abstract and introduction to this draft, it appears to= be proposing mostly a performance improvement for retrieving web pages using DANE authentication. There is some security improvement, but that seems to be incidental to the performance improvement. That would argue in favor of publishing the draft as-is. However: > > This is a consensus call on how to progress this document.=C2=A0 Please= > answer the following questions: > > 1) Do you support publication of the document as is,=C2=A0leaving these= two > issues to potentially be addressed in=C2=A0follow-up work? > > If the answer to 1) is no then please indicate if you think the > working group should work on the document to include=C2=A0 > > A)=C2=A0Recommendation of adding denial of existence proofs in the chai= n > provided by the extension There seems to be some disagreement whether the draft as written allows inclusion of denial-of-existence proofs. So that's an ambiguity in the spec, and I support resolving that ambiguity (hopefully in favor of including them). > B) Adding signaling to require the use of this extension for a period > of time (Pinning with TTL) =46rom the discussion I have read, there seems to be disagreement about what even the semantics of this pinning would be. And if it's unclear to the WG participants, it's going to be even less clear to others that are implementing this. I am also of the opinion that pinning is somewhat subtle; it requires a detailed understanding of the mechanism to remove (expire) the pin, and if done wrong can result in availability problems. In addition, the pins here would be maintained in individual browsers. There is less benefit from pinning because unlike some other pinning mechanisms, there isn't any leverage of the TOFU experience had by others= =2E This requires further thought, and I do not support adding pinning to this draft. Perhaps as a separate draft, but the WG needs to decide on th= at. > C) Both Summary: (A) -Jim --------------920FC77BBCD36A3E276EE0CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I haven't been following this WG closely but read the draft and discussion to see what this was all about, so here's an opinion from a somewhat external reviewer, not in the room in London:

On 4/4/18 10:50 AM, Joseph Salowey wrote:
Hi Folks,

Some objections were raised late during the review of the draft-ietf-tls-dnssec-chain-extension. The question before the working group is either to publish the document as is or to bring the document back into the working group to address the following issues:

- Recommendation of adding denial of existence proofs in the chain provided by the extension
- Adding signaling to require the use of this extension for a period of time (Pinning with TTL)

From reading the abstract and introduction to this draft, it appears to be proposing mostly a performance improvement for retrieving web pages using DANE authentication. There is some security improvement, but that seems to be incidental to the performance improvement. That would argue in favor of publishing the draft as-is. However:

This is a consensus call on how to progress this document.  Please answer the following questions:
1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work?

If the answer to 1) is no then please indicate if you think the working group should work on the document to include 
A) Recommendation of adding denial of existence proofs in the chain provided by the extension

There seems to be some disagreement whether the draft as written allows inclusion of denial-of-existence proofs. So that's an ambiguity in the spec, and I support resolving that ambiguity (hopefully in favor of including them).

B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)

From the discussion I have read, there seems to be disagreement about what even the semantics of this pinning would be. And if it's unclear to the WG participants, it's going to be even less clear to others that are implementing this. I am also of the opinion that pinning is somewhat subtle; it requires a detailed understanding of the mechanism to remove (expire) the pin, and if done wrong can result in availability problems. In addition, the pins here would be maintained in individual browsers. There is less benefit from pinning because unlike some other pinning mechanisms, there isn't any leverage of the TOFU experience had by others.

This requires further thought, and I do not support adding pinning to this draft. Perhaps as a separate draft, but the WG needs to decide on that.

C) Both

Summary: (A)

-Jim

--------------920FC77BBCD36A3E276EE0CE-- From nobody Fri Apr 13 13:06:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8C127AD4 for ; Fri, 13 Apr 2018 13:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w570WP64NHZ9 for ; Fri, 13 Apr 2018 13:06:04 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D18127978 for ; Fri, 13 Apr 2018 13:06:04 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id B5C5BA005511; Fri, 13 Apr 2018 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mf0kOwkasHJN2F kREOjGolCwD2w=; b=Ca0VS9YUfAtD2EubHgonuRmdDWecuwIAP3I02l6PhWkQ7E 7DZFYnemWmBfur4L4fki36+Fgrf4CA+NUlRcEMSuFFEoX8ht6VAbI7EQSx8SfCY4 Dg7bv+WcSvDfBAd8mohNX5SiQZswSdKL3UU1a/7zAtmJBEtZZ/ctPzsEZ4zq8= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 77A51A005510; Fri, 13 Apr 2018 13:06:02 -0700 (PDT) Date: Fri, 13 Apr 2018 15:05:35 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180413200534.GW25259@localhost> References: <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 20:06:06 -0000 On Thu, Apr 12, 2018 at 09:51:12PM -0700, Eric Rescorla wrote: > On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni > wrote: > > > On Apr 13, 2018, at 12:07 AM, Melinda Shore < > > melinda.shore@nomountain.net> wrote: > > > > > > I'm okay with putting denial-of-existence in there as a should, > > > but I do feel strongly that pinning belongs in a separate document. > > > As I said earlier, I have a problem with putting features in protocols > > > that nobody intends to use. It's bad enough when it happens by > > > circumstance but doing it deliberately strikes me as a bad idea. > > > > The great irony of the situation, is that present draft already > > describes pinning: > > > > If TLS applications want to mandate the use of this extension for > > specific servers, clients could maintain a whitelist of sites where > > the use of this extension is forced. The client would refuse to > > authenticate such servers if they failed to deliver this extension. > > > > And I've seen no discussion or working group consensus to *prohibit* > > such pinning, only observations that it would be rather fragile in > > general. > > Thanks for pointing this out. I agree that this text is likely to cause > interop problems and should be removed or at least scoped out in > the case where client and server are unrelated. I regret that I didn't > catch it during my IESG review. I think that means we'll end up with consensus to make a change, and indeed, we cannot not make some change. We can still debate whether to do (A), (B), (C), or, now, (D) (remove the text quoted by Viktor). I think it will be easier to get consensus for (A) or (C) than (D), though, of course, that's to be seen. Nico -- From nobody Fri Apr 13 13:31:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4508C129515 for ; Fri, 13 Apr 2018 13:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAY9sLpwZKlQ for ; Fri, 13 Apr 2018 13:31:45 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3877127978 for ; Fri, 13 Apr 2018 13:31:45 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 01DE768004116; Fri, 13 Apr 2018 13:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZIBV96wrMrzByK 2P/BTbFE4ujOI=; b=rNAuc84nSWLRlzuKnZmMYsgqeXtRWLL59sEREC+iWnMTdz 7CocbXhlw/UX7IiEQb1lKfWXz88QhTGgAVEzU3j7BBDR2xw8q14j3wd8gg5WHALd 2p18M3hB6vNBIo9LU3NJya9H/IGQKV9Qp4j9GXFo2HvJ6jXIg+H/VAR0enudE= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 92C7C68004115; Fri, 13 Apr 2018 13:31:44 -0700 (PDT) Date: Fri, 13 Apr 2018 15:30:07 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180413202936.GX25259@localhost> References: <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 20:31:47 -0000 On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote: > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni > wrote: > > Proposed text: > > > > When the server has DNSSEC-signed TLSA records, the first RRset in > > the chain MUST contain the TLSA record set being presented. > > However, ... > > > > When the server either has no TLSA records, or its domain is not > > DNSSEC-signed, it is RECOMMENDED that the server return a denial > > of existence of either the TLSA records, or proof of insecure > > delegation at some parent domain, rather than omit the extension. > > Clients that are willing to fall back from DANE to some alternative > > mechanism may require the denial of existence to make that possible. > > > > I believe that that this text would harm ineteroperability. > > The difficulty here is what the server knows about the clients behavior. > Specifically, if the server serves TLSA records and then ceases doing > without serving authenticated denial of existence, then it is unable to > determine if this would cause clients to fail because it doesn't know if > the client implements the text in the final paragraph. One could argue > that current clients could pin, but that's totally extratextual, as opposed > t having a noninteroperable behavior in the document. It's better to send the denial of existence than no extension -- the client could just as well be pinning (because the I-D said it could, or because the client does it regardless), and not having extension then will cause failure. Now, clients that don't do opportunistic pinning would have to... notice the lack of TLSA RRs, but not necessarily bother validating the denial of existence chain. There's not even a need to say that the client SHOULD (let alone MUST) validate the denial of existence chain. It suffices that the server SHOULD send it. Nico -- From nobody Fri Apr 13 13:39:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8061A129515 for ; Fri, 13 Apr 2018 13:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 sr4ShTdWBoJu for ; Fri, 13 Apr 2018 13:38:57 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFF8127978 for ; Fri, 13 Apr 2018 13:38:57 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id z8-v6so9540615oix.2 for ; Fri, 13 Apr 2018 13:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ZKiA3HrqThNVPfzAcupe2Oym7qPcTwwMmmbaeEj8iw=; b=rYDA4mH1AU62Ap7S3QCgAnZy/7/y39KUvyPrkB04mDfi0l9jagJ7mmX8lXjYdrto6I IRgr9p16reJcxiRLV9dHYrjFF7XRPXR2ola+maRlka774h/FWxcDpkmokzPzvGJ0tGAk Sq5cCcoSwjPjYwsF0faoVD6xT97Vbp6yCIiy8CWkMOFv/CY/x7LY4q7pNPhD5N0LyIuj Zghu0KlEuOmWDKQYIumibUDr3+o6CYjxtRThDp9poZ1bBGpBGHjPnRpK9WeDQZu+bR2D KcpGBgRAvqOr69haJl4XrCT+hvS5UWCWTxv0EtCjyrK1A6rWTOVsErNdkHHVyPK7FO17 vsLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ZKiA3HrqThNVPfzAcupe2Oym7qPcTwwMmmbaeEj8iw=; b=lxeqdwKvuA/RN5VjMSzyCk1TfAA5mu8lRmG3v5gcn750IyGHPdirty5PVbLwAYZhhH QD9xVqLmxPPFgx8PaN0Jrp0uEHtpoyZ0052oM3yhUxfqc3VOpHGa+UHvt08KhUgFcg6o B7Bk3yuF5I6BTMSas+sbbsKP4M3erztzJ3qkeDhN5UqjtsuEuiLx0EEhBcWv8x3E/8GM zGya0HxxE1/DZCQ8/dGuTn9mey9TZT6Vu8KvrS/oVSXMjV8kfEechuZLfe1cCxDxEc8p ZIszoYpxDB4Hf8OUnQ2KFtY4/sTz9kn8jac5524NBPqtkiWLgcZj6G6WzB+X0x1LO7jg x4cQ== X-Gm-Message-State: ALQs6tDMd7XD7enyLyR4gXNxN6V8iKYjNUrMOBPm/NCosm/MDIGRrpAO G/7Wl4Y5Z/R/c8O5bmkxwCkaXISIqjlV9Y4sG52Vgqyb X-Google-Smtp-Source: AIpwx4/nSYnlrc/YQ+QUfkc07QHFQv06wGSw1pEqsGj427f04T21W0L2Bm3Tzqa204axSg4rNb+SF6P97x+HzP8dTQY= X-Received: by 2002:aca:d0d5:: with SMTP id j82-v6mr9622078oiy.276.1523651936305; Fri, 13 Apr 2018 13:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Fri, 13 Apr 2018 13:38:55 -0700 (PDT) In-Reply-To: <20180413202936.GX25259@localhost> References: <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <20180413202936.GX25259@localhost> From: Richard Barnes Date: Fri, 13 Apr 2018 16:38:55 -0400 Message-ID: To: Nico Williams Cc: Eric Rescorla , TLS WG Content-Type: multipart/alternative; boundary="0000000000006cd8910569c0dcc1" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 20:38:59 -0000 --0000000000006cd8910569c0dcc1 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams wrote: > On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote: > > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni > > > wrote: > > > Proposed text: > > > > > > When the server has DNSSEC-signed TLSA records, the first RRset in > > > the chain MUST contain the TLSA record set being presented. > > > However, ... > > > > > > When the server either has no TLSA records, or its domain is not > > > DNSSEC-signed, it is RECOMMENDED that the server return a denial > > > of existence of either the TLSA records, or proof of insecure > > > delegation at some parent domain, rather than omit the extension. > > > Clients that are willing to fall back from DANE to some alternative > > > mechanism may require the denial of existence to make that possible. > > > > > > > I believe that that this text would harm ineteroperability. > > > > The difficulty here is what the server knows about the clients behavior. > > Specifically, if the server serves TLSA records and then ceases doing > > without serving authenticated denial of existence, then it is unable to > > determine if this would cause clients to fail because it doesn't know if > > the client implements the text in the final paragraph. One could argue > > that current clients could pin, but that's totally extratextual, as > opposed > > t having a noninteroperable behavior in the document. > > It's better to send the denial of existence than no extension -- the > client could just as well be pinning (because the I-D said it could, or > because the client does it regardless), and not having extension then > will cause failure. > > Now, clients that don't do opportunistic pinning would have to... notice > the lack of TLSA RRs, but not necessarily bother validating the denial > of existence chain. There's not even a need to say that the client > SHOULD (let alone MUST) validate the denial of existence chain. It > suffices that the server SHOULD send it. > Sure seems like it would be simpler to say "Client MUST NOT cache TLSA state". Yes, that cuts off some use cases. But it avoids all the transition pain that EKR has pointed out. --Richard > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006cd8910569c0dcc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote:
> On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > Proposed text:
> >
> >=C2=A0 =C2=A0 When the server has DNSSEC-signed TLSA records, the = first RRset in
> >=C2=A0 =C2=A0 the chain MUST contain the TLSA record set being pre= sented.
> >=C2=A0 =C2=A0 However, ...
> >
> >=C2=A0 =C2=A0 When the server either has no TLSA records, or its d= omain is not
> >=C2=A0 =C2=A0 DNSSEC-signed, it is RECOMMENDED that the server ret= urn a denial
> >=C2=A0 =C2=A0 of existence of either the TLSA records, or proof of= insecure
> >=C2=A0 =C2=A0 delegation at some parent domain, rather than omit t= he extension.
> >=C2=A0 =C2=A0 Clients that are willing to fall back from DANE to s= ome alternative
> >=C2=A0 =C2=A0 mechanism may require the denial of existence to mak= e that possible.
> >
>
> I believe that that this text would harm ineteroperability.
>
> The difficulty here is what the server knows about the clients behavio= r.
> Specifically, if the server serves TLSA records and then ceases doing<= br> > without serving authenticated denial of existence, then it is unable t= o
> determine if this would cause clients to fail because it doesn't k= now if
> the client implements the text in the final paragraph. One could argue=
> that current clients could pin, but that's totally extratextual, a= s opposed
> t having a noninteroperable behavior in the document.

It's better to send the denial of existence than no extension --= the
client could just as well be pinning (because the I-D said it could, or
because the client does it regardless), and not having extension then
will cause failure.

Now, clients that don't do opportunistic pinning would have to... notic= e
the lack of TLSA RRs, but not necessarily bother validating the denial
of existence chain.=C2=A0 There's not even a need to say that the clien= t
SHOULD (let alone MUST) validate the denial of existence chain.=C2=A0 It suffices that the server SHOULD send it.

Sure seems like it would be simpler to say "Client MUST NOT cache TL= SA state".=C2=A0 Yes, that cuts off some use cases.=C2=A0 But it avoid= s all the transition pain that EKR has pointed out.

--Richard

=C2=A0

Nico
--

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

--0000000000006cd8910569c0dcc1-- From nobody Mon Apr 16 02:50:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8671126D45 for ; Mon, 16 Apr 2018 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMZvPbEtYOKL for ; Mon, 16 Apr 2018 02:50:29 -0700 (PDT) Received: from esa1.dyson.c3s2.iphmx.com (esa1.dyson.c3s2.iphmx.com [68.232.133.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B857126B6E for ; Mon, 16 Apr 2018 02:50:28 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8864"; a="37253381" X-IronPort-AV: E=Sophos;i="5.48,459,1517875200"; d="scan'208";a="37253381" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa1.dyson.c3s2.iphmx.com with ESMTP; 16 Apr 2018 11:01:20 +0100 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 3C90994711; Mon, 16 Apr 2018 08:36:31 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 2E6E494702; Mon, 16 Apr 2018 08:36:31 +0000 (GMT) Received: from UK-MAL-CAS-03.dyson.global.corp (10.1.108.111) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Apr 2018 10:50:21 +0100 Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-03.dyson.global.corp ([10.1.108.111]) with mapi id 14.03.0319.002; Mon, 16 Apr 2018 10:50:20 +0100 From: Tony Putman To: Richard Barnes CC: "" , Benjamin Kaduk , "Watson Ladd" Thread-Topic: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt Thread-Index: AQHT0aURP8E25F81m0KNzl5SphxWl6P84Y0AgAIa3oCABCuigA== Date: Mon, 16 Apr 2018 09:50:20 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 09:50:31 -0000 SGkgUmljaGFyZCwNCg0KSSBkb24ndCB0aGluayB0aGF0IHlvdSBjYW4gcHJvdGVjdCBhZ2FpbnN0 IHNlcnZlciBjb21wcm9taXNlIHdpdGggU1BBS0UyLiBUaGUgc2VydmVyIGNhbiBzdG9yZSB3Kk4g YXMgeW91IHN1Z2dlc3QsIGJ1dCBpdCBhbHNvIGhhcyB0byBzdG9yZSB3Kk0gYmVjYXVzZSBpdCBt dXN0IGNhbGN1bGF0ZSB5KihULXcqTSkuIEFuIGF0dGFja2VyIHRoYXQgbGVhcm5zIHcqTSBhbmQg dypOIGZyb20gYSBjb21wcm9taXNlZCBzZXJ2ZXIgY2FuIHRoZW4gaW1wZXJzb25hdGUgYSBjbGll bnQuIA0KDQpUaGUgcmVzdCBvZiB5b3VyIGNvbW1lbnRzIEkgYWdyZWUgd2l0aCAodGhvdWdoIHRo ZXkgYXJlIG5vdCBhbGwgYWRkcmVzc2VkIGluIHRoZSB1cGRhdGVkIGRyYWZ0KS4gDQoNClRvbnkN Cg0KPiBGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdIA0KPiBTZW50OiAx MyBBcHJpbCAyMDE4IDE5OjUwDQo+DQo+IEhleSBUb255LA0KPg0KPiBUaGFua3MgZm9yIHRoZSBj b21tZW50cy7CoCBIb3BlZnVsbHkgd2UgY2FuIGFkYXB0IHRoaXMgZG9jdW1lbnQgdG8gdGljayBt b3JlIGJveGVzIGZvciB5b3UgOinCoCANCj4gU2luY2UgSSBoYWQgbm90aWNlZCBzb21lIG90aGVy IGVycm9ycyBpbiB0aGUgZG9jdW1lbnQgKGUuZy4sIGZpZ3VyZXMgbm90IHJlbmRlcmluZyBwcm9w ZXJseSksIA0KPiBJIHdlbnQgYWhlYWQgYW5kIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIHRoYXQg dGFrZXMgdGhlc2UgY29tbWVudHMgaW50byBhY2NvdW50Lg0KPg0KPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYmFybmVzLXRscy1wYWtlLTAxDQo+DQo+IFNvbWUgcmVzcG9uc2Vz IGlubGluZSBiZWxvdy4NCgpEeXNvbiBUZWNobm9sb2d5IExpbWl0ZWQsIGNvbXBhbnkgbnVtYmVy IDAxOTU5MDkwLCBUZXRidXJ5IEhpbGwsIE1hbG1lc2J1cnksIFNOMTYgMFJQLCBVSy4KVGhpcyBt ZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZSBhbmQgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRl IGl0LCBhbmQgZG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWVzc2FnZSBvciBpbiBhbnkgYXR0YWNobWVudC4KRHlzb24gbWF5IG1v bml0b3IgZW1haWwgdHJhZmZpYyBkYXRhIGFuZCBjb250ZW50IGZvciBzZWN1cml0eSAmIHRyYWlu aW5nLgo= From nobody Mon Apr 16 02:56:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068471275F4 for ; Mon, 16 Apr 2018 02:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.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 XTuDLw8gy2FK for ; Mon, 16 Apr 2018 02:56:25 -0700 (PDT) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7084126B6E for ; Mon, 16 Apr 2018 02:56:24 -0700 (PDT) Received: from seraph (unknown [112.97.50.4]) by gondrom.org (Postfix) with ESMTPSA id 5F2E86495F for ; Mon, 16 Apr 2018 11:56:18 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=2dglW4zjc6yOJfl6ZmCttl7xC+jAjCbfKmn0ActYkAln7JxW82dWv7QxAmQK4FRQeiNY74VDeTaGSve1o+QqkbU1VDZp5Gf6ujnzs012PLtUyPuvlj88UvkE+WHfMGEtXikI0VuW1wqKrRs/H08WYl79EdqJiS+CvXF7uyCI3NE=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Content-Language:Importance; From: "Tobias Gondrom" To: Date: Mon, 16 Apr 2018 17:56:13 +0800 Message-ID: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_064B_01D3D5AC.3861A190" X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdPVZYk+oWNMQIzzR+6S409zcpHaHQ== Content-Language: en-us Importance: Low Archived-At: Subject: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 09:56:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_064B_01D3D5AC.3861A190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi dear TLS experts, Apologies for my stupid question for advise: I am currently working on some design requirements for mutual authentication and have a question regarding verification of client certificate. In many web scenarios the simple use is server authentication by certificate and verification of client id by username & password or by a simple verification of client certificate. Are there any RFCs that speak (beyond the general verification of the certificate in mutual TLS authentication) to the need to also verify the CN inside the client certificate against an additional whitelist _before_ establishing a TLS connection. For example in this scenario: A client with a valid certificate may be allowed to connect to application 1, but would not be allowed to connect to application 2. (for sake of separation application 1 and 2 are on separate servers (application 1 on server 1 and application 2 on server 2).) >From my current understanding, I would establish the TLS connection in both cases, do mutual authentication and then let application 2 reject access based on that the user is not allowed to access it. There is a question whether this would expose to a risk that server resources could be exhausted by allowing to establish the TLS connection before failing, but this does not seem too bad to me. But maybe I am missing something. Are there any informational (or standard) RFCs for TLS that speak about this risk and best practices to address it? (e.g. using additional whitelist checks of parameters inside the client certificate for access control checks already during phase of establishing the TLS connection) Thank you and sorry for bothering, Tobias ------=_NextPart_000_064B_01D3D5AC.3861A190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi dear TLS experts,

 

Apologies = for my stupid question for advise:

I = am currently working on some design requirements for mutual = authentication and have a question regarding verification of client = certificate.

 

In many web scenarios the simple use is server = authentication by certificate and verification of client id by username = & password or by a simple verification of client certificate. =

 

Are there any RFCs that speak (beyond the general = verification of the certificate in mutual TLS authentication) to the = need to also verify the CN inside the client certificate against an = additional whitelist _before_ establishing a TLS connection. =

 

For example in this scenario:

A client with a valid certificate may be allowed to = connect to application 1, but would not be allowed to connect to = application 2. (for sake of separation application 1 and 2 are on = separate servers (application 1 on server 1 and application 2 on server = 2).)

 

From my current understanding, I would establish the = TLS connection in both cases, do mutual authentication and then let = application 2 reject access based on that the user is not allowed to = access it. There is a question whether this would expose to a risk that = server resources could be exhausted by allowing to establish the TLS = connection before failing, but this does not seem too bad to me. But = maybe I am missing something…

 

Are there = any informational (or standard) RFCs for TLS that speak about this risk = and best practices to address it?  

(e.g. using additional whitelist checks of = parameters inside the client certificate for access control checks = already during phase of establishing the TLS = connection)

 

Thank you = and sorry for bothering, Tobias

 

------=_NextPart_000_064B_01D3D5AC.3861A190-- From nobody Mon Apr 16 04:52:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB12124D68 for ; Mon, 16 Apr 2018 04:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khb3DZ5jSY4s for ; Mon, 16 Apr 2018 04:52:40 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086A91241FC for ; Mon, 16 Apr 2018 04:52:40 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id q189so267159vkb.0 for ; Mon, 16 Apr 2018 04:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z1L7pZyBr19DJHdIj/3H/DFrRTWy1EDjHpRPftVgGrM=; b=jAzIUY3L+fpD7P3WHjc3EaHAfend1BPJ644eHfk0942PoX6KsUp84+zPBLMyjE/3CY B/ci/vbjotGGaI9usgBjN2JXyXi9J18OqU1ODyI8EOlNmMFdsCdY0g+CyMmqPe9WIaTb vsgPyirt/vAus9E71KOyEzORvJhat0UwZVu7KHlxUEZCrfWNcWhihMofW0YAa9903F+p W10qeMWa+ZtiuNExpaRELyEC9TIOrdsnC1u/9h9Y8Gt/SWJHO1Yfd2CgE4enbt+VnorY 32M+JPsQubP8w8/eRx9RI8Bd/7vnuJnH5FG/HbxR8mNxdvYzY44Vyary+TgYCpG2Qmok PSAQ== 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=z1L7pZyBr19DJHdIj/3H/DFrRTWy1EDjHpRPftVgGrM=; b=mUNSK4fHRt2vieQeE+9Stx7Duiq6YW+lQSJCfh+8/lekZ8u5uYJXCdcuhWSqnWcKx5 0x22Vt0RXPQdNFoZEAXrdaJUu49JGyckOmV6MXrocw9k+b2mXddOmynf97e2LKuFnuBf BB47oeuFIUi+7yv9+fHsIeTsFO/nWK3N2YRgGWDkvJhj4AWZZSvxR4tEgOZHlAQL7byX CGx8iq5KgRYPHrDmDT2nHUdVGzrMW5IpfnOUdbHtI/Ma4ER4b9Q/QaeMEmSvn1ysje07 VkrkS5porK/KMb6wqznHImI+itky2ZiXtrp2sRj6vUO0xVTcAzqgvRFvS+b9haduQQfi ByUg== X-Gm-Message-State: ALQs6tCqg8eggWLlpbhiZ6/4lUKvcExPqUN9bKsZ2QgnFB2g3PrTdlrE g+fflIR97kHbmtzhe6qdTDahWB1Rl4TLlzZ4uU4= X-Google-Smtp-Source: AIpwx48at452fJdPShrV6m2QsJfOIji7pQDfdKl6CW33uxd+YcGZNCl50xW+dFaFxDlqLEmWfWnYWmYUr5DfHv/xZRw= X-Received: by 10.31.92.69 with SMTP id q66mr9975956vkb.155.1523879559047; Mon, 16 Apr 2018 04:52:39 -0700 (PDT) MIME-Version: 1.0 References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> In-Reply-To: <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> From: Jonathan Hoyland Date: Mon, 16 Apr 2018 11:52:28 +0000 Message-ID: To: Tony Putman Cc: Richard Barnes , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="001a114f6e0ccc30b00569f5db77" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 11:52:43 -0000 --001a114f6e0ccc30b00569f5db77 Content-Type: text/plain; charset="UTF-8" Hi Richard, A few nits. * In the introduction you have the sentence > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet seen significant security analysis. Iiuc this draft has no connection to MLS, and this is a typo. * In the setup you define > o A DH group "G" of order "p*h", with "p" a large prime and > o A password "p" The variable "p" has two different meanings, which is a bit confusing, especially later on. * The document doesn't explicitly state that X and Y need to be non-zero. The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the warning was carried through. * In terms of security properties, iiuc an active adversary can do online password guessing attacks, but a passive adversary cannot derive the password from observing the messages. If that is the case perhaps a warning about rate-limiting connection attempts is appropriate. Regards, Jonathan On Mon, 16 Apr 2018 at 10:50 Tony Putman wrote: > Hi Richard, > > I don't think that you can protect against server compromise with SPAKE2. > The server can store w*N as you suggest, but it also has to store w*M > because it must calculate y*(T-w*M). An attacker that learns w*M and w*N > from a compromised server can then impersonate a client. > > The rest of your comments I agree with (though they are not all addressed > in the updated draft). > > Tony > > > From: Richard Barnes [mailto:rlb@ipv.sx] > > Sent: 13 April 2018 19:50 > > > > Hey Tony, > > > > Thanks for the comments. Hopefully we can adapt this document to tick > more boxes for you :) > > Since I had noticed some other errors in the document (e.g., figures not > rendering properly), > > I went ahead and submitted a new version that takes these comments into > account. > > > > https://tools.ietf.org/html/draft-barnes-tls-pake-01 > > > > Some responses inline below. > > Dyson Technology Limited, company number 01959090, Tetbury Hill, > Malmesbury, SN16 0RP, UK. > This message is intended solely for the addressee and may contain > confidential information. If you have received this message in error, > please immediately and permanently delete it, and do not use, copy or > disclose the information contained in this message or in any attachment. > Dyson may monitor email traffic data and content for security & training. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114f6e0ccc30b00569f5db77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

A few nits.=

* In the introduction you have the sentence
>=C2=A0DISCL= AIMER: This is a work-in-progress draft of MLS and has not yet
= 
   seen significant se=
curity analysis.
Iiuc this draft has n= o connection to MLS, and this is a typo.
* In the set= up you define=C2=A0
> o  A DH group "G" of order=
 "p*h", with "p" a large prime
and 
> o  A password "p"

The variable "p" = has two different meanings, which is a bit confusing, especially later on.<= br>
* The docume= nt doesn't explicitly state that X and Y need to be non-zero.=C2=A0
The requirement is= in "I-D.irtf-cfrg-spake2", but it would be nice if the warning w= as carried through.

* In terms = of security properties, iiuc an active adversary can do online password gue= ssing attacks, but a passive adversary cannot derive the password from obse= rving the messages. If that is the case perhaps a warning about rate-limiti= ng connection attempts is appropriate.=C2=A0

Regards,

Jonathan

On Mon, 16 Apr 2018 at 1= 0:50 Tony Putman <Tony.Putman@d= yson.com> wrote:
Hi Richard,=

I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-barnes-= tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a114f6e0ccc30b00569f5db77-- From nobody Mon Apr 16 04:55:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44478126E64 for ; Mon, 16 Apr 2018 04:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 Qj-ayxKDrEsX for ; Mon, 16 Apr 2018 04:55:42 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 D0AD91241FC for ; Mon, 16 Apr 2018 04:55:41 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id w2-v6so6051846otj.12 for ; Mon, 16 Apr 2018 04:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FDMf7UBEjt7RLdKr40wVQMq+qN/1QOk1OMfg1HyKozo=; b=PsP6/L3WyRPh2WRTGhcBqXcHgqBrmTrioNlhuaZ6CZqodGdnTRzBl6KSRGMVyAFqsE g2ATgBulZVpLYF0nZZTvcDBf/ZJhd2pOOCZ6+Hl/TNWGCP4ps1c2WkfZgH4cO8SSwpNk N/Trl0gnWMQuL0UccOZvsTcJ3NGkn2rYVWWj4bQe2dROtOpy0vxHl3jNO0U1VcC7X4UE Uck0V7EjaCehrpZDQRSCcPaviMzEcmnuTTz3PctkC5otPud1YStSYYo47UyBF0HB7pNN U/kTXZfKcZ6EV8ndGHM7XWVFEArpCsGWwo+ghNgjFjmADszYGhT0vpXo2GxT7DbH/w7C yXuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FDMf7UBEjt7RLdKr40wVQMq+qN/1QOk1OMfg1HyKozo=; b=XrD4IeDj73yipeCiRvhy84LgzFyBxgrkw/+c6UyddAvu3p786OZK+N8lZpp1R43+JU A4MAnKNawo0M7CiWvhLNX0/RWYma+qdtLJ0bUGK+4KrFwN2ISszee8SWiMSr5gATO0CP abPn9JEXxEgCfe7xjQzOo214Cl8BIGUJyRwI8yzO7+2G/dWpfzT2RVuohuWW/l3CFLVK YGg9Nmx2XnZ5XlfPw2S0tPVhDDzd9NgP1SwrxcoviyjuITDRQLxBokN1maf1KouwkXeA y4nAUMNDeeLCBrpaANpOz4X7trZJg7cNUBH2RMkttEcB2VjW5ioNqY+EQBleYqtc846E 7sHQ== X-Gm-Message-State: ALQs6tBPynOtaZTjz1UR7x+u/zcFlsDyPspdwlsm3RgG0QbWWGJ3PzX4 8k/jtpH/9VbgkOL+ttWBR6hM0Jj/8WKGrkdljeb6DpZ3 X-Google-Smtp-Source: AIpwx4/dgTiWme1nJKEuhUqGDwtnfsDFVyIBAegMFN65r3/LfiTATi9/pHWuEe0aESutFKlOrqHY35acT9tAFyDDODQ= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr1028304otb.101.1523879741072; Mon, 16 Apr 2018 04:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 04:55:00 -0700 (PDT) In-Reply-To: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> From: Eric Rescorla Date: Mon, 16 Apr 2018 04:55:00 -0700 Message-ID: To: Tobias Gondrom Cc: "" Content-Type: multipart/alternative; boundary="000000000000a5bfce0569f5e685" Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 11:55:44 -0000 --000000000000a5bfce0569f5e685 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not aware of anywhere this is documented, primarily because it's so application-specifiic. -Ekr On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom wrote: > Hi dear TLS experts, > > > > Apologies for my stupid question for advise: > > I am currently working on some design requirements for mutual > authentication and have a question regarding verification of client > certificate. > > > > In many web scenarios the simple use is server authentication by > certificate and verification of client id by username & password or by a > simple verification of client certificate. > > > > Are there any RFCs that speak (beyond the general verification of the > certificate in mutual TLS authentication) to the need to also verify the = CN > inside the client certificate against an additional whitelist _*before*_ > establishing a TLS connection. > > > > For example in this scenario: > > A client with a valid certificate may be allowed to connect to applicatio= n > 1, but would not be allowed to connect to application 2. (for sake of > separation application 1 and 2 are on separate servers (application 1 on > server 1 and application 2 on server 2).) > > > > From my current understanding, I would establish the TLS connection in > both cases, do mutual authentication and then let application 2 reject > access based on that the user is not allowed to access it. There is a > question whether this would expose to a risk that server resources could = be > exhausted by allowing to establish the TLS connection before failing, but > this does not seem too bad to me. But maybe I am missing something=E2=80= =A6 > > > > *Are there any informational (or standard) RFCs for TLS that speak about > this risk and best practices to address it? * > > *(e.g. using additional whitelist checks of parameters inside the client > certificate for access control checks already during phase of establishin= g > the TLS connection)* > > > > Thank you and sorry for bothering, Tobias > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000a5bfce0569f5e685 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of anywhere this is documented, primar= ily because it's so application-specifiic.

-Ekr


On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

Hi dear TLS e= xperts,

=C2=A0

Apologies for my stupid question for advise:

I am currently working on some design requi= rements for mutual authentication and have a question regarding verificatio= n of client certificate.

= =C2=A0

In many web scenarios the simple us= e is server authentication by certificate and verification of client id by = username & password or by a simple verification of client certificate. =

=C2=A0

Are there any RFCs that speak (beyond the general verificati= on of the certificate in mutual TLS authentication) to the need to also ver= ify the CN inside the client certificate against an additional whitelist _<= i>before_ establishing a TLS connection.

=C2=A0

For example in th= is scenario:

A client with a valid= certificate may be allowed to connect to application 1, but would not be a= llowed to connect to application 2. (for sake of separation application 1 a= nd 2 are on separate servers (application 1 on server 1 and application 2 o= n server 2).)

=C2=A0=

From my current understanding, I would establish= the TLS connection in both cases, do mutual authentication and then let ap= plication 2 reject access based on that the user is not allowed to access i= t. There is a question whether this would expose to a risk that server reso= urces could be exhausted by allowing to establish the TLS connection before= failing, but this does not seem too bad to me. But maybe I am missing some= thing=E2=80=A6

=C2=A0=

Are there any informational (or standard) RFC= s for TLS that speak about this risk and best practices to address it? =C2= =A0

(e.g. using additional w= hitelist checks of parameters inside the client certificate for access cont= rol checks already during phase of establishing the TLS connection)<= u>

=C2=A0

Thank you and sorry for bothering, Tobias

=C2=A0


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


--000000000000a5bfce0569f5e685-- From nobody Mon Apr 16 06:20:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D8E126E64 for ; Mon, 16 Apr 2018 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QgciHM8lfh9l for ; Mon, 16 Apr 2018 06:20:23 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5934127522 for ; Mon, 16 Apr 2018 06:20:21 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id u84-v6so14463231oie.10 for ; Mon, 16 Apr 2018 06:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ipIrogjOdDtx8UhsVs6AQElLTrOtKYVredYa5IlMIaE=; b=Cy244DWeZP01pOisosqfmdck7v6etgs0p23ilsSpIyPjh3QVxAskTbUi3RWtAYQv5U Iup+S7Fh4DWvnjHeL41F9TMbTG0lcxUpxkGBOzx5Ux4u8y7k2eUsGkKyW/7YoRkee2j6 T3wxkrP834/RNmhiAZx9rwOSMlmfcKWI4W2kzkXHlr9yaHDYIO6y6LHy+kctttk1nPT3 2aMVuD7Skpj5RHYh8haRUS7jLEMg/6PYwkYLBb5N4VJVqU3345yzhW6t/DBhUfnP1r4l 6+mswKpSknJ+kIksPIHYn9C+qu8XS7KIImglk3SlmO3AtwLCjF1unol+C6HgQmKDY7Wt lxCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ipIrogjOdDtx8UhsVs6AQElLTrOtKYVredYa5IlMIaE=; b=UndEltYMfw40TEPT3Ac34znmuOOsXdBQHDAumLr2ESrdiC0otXBY9EQfI0lJglDSOS 2Zda6Q7l+tW4n3DS25GZVH/+vDgJ0f3NxDv1/TC4h+yr/ROFPoUBY1Y5QKOBZTQ6vXja pNz3ew7ZTSbgtAMNTJ2EGrx8G/ppUE2MZg5J6ChkvjzNA+3S5eNaBH1Mb64L03+A6why vBWVD5uFgyYSXLBWgqkpuWLXowoCLMJk+KdoqQvo+1fG9EhIfv673Y4U9ycdneECBkew fOe6DTag1SaRYv7iNLvPEjJiQhwucNl+BmKYRFKmeU2yjF7Ed4yzkPFHA3zH7OqyWQc9 O0Ew== X-Gm-Message-State: ALQs6tALjwMNH8+1tfaPPw/ktuWcNczFCfyS+AeudxchoUU8cEGMJP4n aN/cgde6wSpWzPsr7Pn+D4uZ4PVf X-Google-Smtp-Source: AIpwx4+uFYPNLer8nutA2OzbMvQQnpZaVncVhoY7gd8UDu1JrO9tB9+iCuZnvjr+GnBTes6K3N2Emw== X-Received: by 2002:aca:1204:: with SMTP id 4-v6mr3034613ois.241.1523884821042; Mon, 16 Apr 2018 06:20:21 -0700 (PDT) Received: from [172.20.0.107] ([12.15.241.29]) by smtp.gmail.com with ESMTPSA id c49-v6sm8058868ote.79.2018.04.16.06.20.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 06:20:20 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9AE11407-A791-4475-8986-C80DB17FEA7B Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Mon, 16 Apr 2018 06:20:04 -0700 Cc: Tobias Gondrom , "" Content-Transfer-Encoding: 7bit Message-Id: <0FEA7711-7DC1-487B-A544-FAEFC9377C96@gmail.com> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> To: Eric Rescorla Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 13:20:26 -0000 --Apple-Mail-9AE11407-A791-4475-8986-C80DB17FEA7B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tobias, If you use search terms that include pkix, authorization, access control, an= d attribute certificate profile, you=E2=80=99ll find a few documents. This o= ne should be helpful based on your description: https://tools.ietf.org/html/rfc5755 Best regards, Kathleen=20 Sent from my mobile device > On Apr 16, 2018, at 4:55 AM, Eric Rescorla wrote: >=20 > I am not aware of anywhere this is documented, primarily because it's so a= pplication-specifiic. >=20 > -Ekr >=20 >=20 >> On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom wrote: >> Hi dear TLS experts, >>=20 >> =20 >>=20 >> Apologies for my stupid question for advise: >>=20 >> I am currently working on some design requirements for mutual authenticat= ion and have a question regarding verification of client certificate. >>=20 >> =20 >>=20 >> In many web scenarios the simple use is server authentication by certific= ate and verification of client id by username & password or by a simple veri= fication of client certificate. >>=20 >> =20 >>=20 >> Are there any RFCs that speak (beyond the general verification of the cer= tificate in mutual TLS authentication) to the need to also verify the CN ins= ide the client certificate against an additional whitelist _before_ establis= hing a TLS connection. >>=20 >> =20 >>=20 >> For example in this scenario: >>=20 >> A client with a valid certificate may be allowed to connect to applicatio= n 1, but would not be allowed to connect to application 2. (for sake of sepa= ration application 1 and 2 are on separate servers (application 1 on server 1= and application 2 on server 2).) >>=20 >> =20 >>=20 >> =46rom my current understanding, I would establish the TLS connection in b= oth cases, do mutual authentication and then let application 2 reject access= based on that the user is not allowed to access it. There is a question whe= ther this would expose to a risk that server resources could be exhausted by= allowing to establish the TLS connection before failing, but this does not s= eem too bad to me. But maybe I am missing something=E2=80=A6 >>=20 >> =20 >>=20 >> Are there any informational (or standard) RFCs for TLS that speak about t= his risk and best practices to address it? =20 >>=20 >> (e.g. using additional whitelist checks of parameters inside the client c= ertificate for access control checks already during phase of establishing th= e TLS connection) >>=20 >> =20 >>=20 >> Thank you and sorry for bothering, Tobias >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-9AE11407-A791-4475-8986-C80DB17FEA7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tobias,

If you use se= arch terms that include pkix, authorization, access control, and attribute c= ertificate profile, you=E2=80=99ll find a few documents.  This one shou= ld be helpful based on your description:


I am not aware of anywhere this is documented, primarily because i= t's so application-specifiic.

-Ekr

On M= on, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gondrom= .org> wrote:

Hi dear TLS experts,

 

Apologie= s for my stupid question for advise:

I am currently working on some design requirements for mutual authenticati= on and have a question regarding verification of client certificate. =

 

In many web scenarios the simple use is server authentication by certif= icate and verification of client id by username & password or by a simpl= e verification of client certificate.

 

Are there any RFCs that sp= eak (beyond the general verification of the certificate in mutual TLS authen= tication) to the need to also verify the CN inside the client certificate ag= ainst an additional whitelist _before_ establishing a TLS connection.=

 

For example in this scenario:

A client with a valid certificate may be allowed to connect to applic= ation 1, but would not be allowed to connect to application 2. (for sake of s= eparation application 1 and 2 are on separate servers (application 1 on serv= er 1 and application 2 on server 2).)

 

=46rom my current understa= nding, I would establish the TLS connection in both cases, do mutual authent= ication and then let application 2 reject access based on that the user is n= ot allowed to access it. There is a question whether this would expose to a r= isk that server resources could be exhausted by allowing to establish the TL= S connection before failing, but this does not seem too bad to me. But maybe= I am missing something=E2=80=A6

=  

Are there any informational (= or standard) RFCs for TLS that speak about this risk and best practices to a= ddress it?  

(e.g. using= additional whitelist checks of parameters inside the client certificate for= access control checks already during phase of establishing the TLS connecti= on)

 

Thank you and sorry for bothering, Tobias

 


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


____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-9AE11407-A791-4475-8986-C80DB17FEA7B-- From nobody Mon Apr 16 07:54:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28A8126B6E for ; Mon, 16 Apr 2018 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax9vLhId0CBf for ; Mon, 16 Apr 2018 07:54:17 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC60124319 for ; Mon, 16 Apr 2018 07:54:17 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id i75so4837105vke.8 for ; Mon, 16 Apr 2018 07:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fq3FKhYfR0uQvVJe1JWJk/87hpoOAmeXE0cVIXPcKlE=; b=NgMUkG1Yx1al0s7eKBP8HfaiucwMw3ZBYKsNRIhbrbRQ04aMcxdH0Qm/iV2cOcvw8d OdGydDpCjouDgsYSea3DOc+m5JSLU8tJc/Z3TYRudYLAlnmvs0JtvK3a7BySmLkEZ8Zd gbHT4IObjGKJzVAhpKejD4D6zWsGjuhGVN3t/oRVQaCnUoskgXljvLyEmLOobDzp5L1+ bOF4ZLeBhd7xYRXQNYlAPrOmE3e9JwW2rtCEIiwKJsiEg3MCPjGPjxLgbddHwDQGawam WD0NwSDuWP4I506frmQll0mM6y8svKARxNeLvQ//KoVrW+0iI6758aMH7Srl+shVqPQ9 PHXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fq3FKhYfR0uQvVJe1JWJk/87hpoOAmeXE0cVIXPcKlE=; b=P4N6VUdb6tYBF7iNNq/lSTbXsQSLtfitBNJyObf5H1loUnPEFlvxkxKucpbS8XLmzv F0JUKEp9t0ak8YP0yH2+qCSzzbggUafqGamFhcV5G0FstwxXrVjMy4s3JYDKpGMzQxyd LqR7CcASnpTmh0R/eOJimlNmm6hyEO+v46MbGRBk9goRVpmPliAijmGStiEGFeezxfeU G863lbNa9FkfyB1j6+q8zuRhUwnxO75IG0Qwlt9p3lqsWj65BqkTd3462+iYwFJsjZSB k324jHPMKuO/id4s5oBJ9ohUA0aejjpCWxsSUAZfzP7AVPOZpaxDY9EguVVZFAVZhiw0 VQdg== X-Gm-Message-State: ALQs6tDrrn+a8s/4oYj1KtHeJIq5T11qgiVThXLViWN7/vLX6hEl5ljo 20WlFB3bRb+/882MRMVClE3+9LsxdxW8tMrxvWRPr8yU X-Google-Smtp-Source: AIpwx4+d0eyZxI3AHN9YAdnyUu/kkRoqxRaEKWh9Jyxk/Upo3YoeMBijO5RAvuCrdINJKbVTeFuW/Cff0bD9SUdtBpE= X-Received: by 10.31.192.193 with SMTP id q184mr11131217vkf.114.1523890456706; Mon, 16 Apr 2018 07:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.102.65 with HTTP; Mon, 16 Apr 2018 07:53:56 -0700 (PDT) In-Reply-To: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> From: Tony Arcieri Date: Mon, 16 Apr 2018 07:53:56 -0700 Message-ID: To: Tobias Gondrom Cc: "" Content-Type: multipart/alternative; boundary="001a1143750059452f0569f8654b" Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 14:54:20 -0000 --001a1143750059452f0569f8654b Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom wrote: > Are there any RFCs that speak (beyond the general verification of the > certificate in mutual TLS authentication) to the need to also verify the CN > inside the client certificate against an additional whitelist _*before*_ > establishing a TLS connection. > I'm not sure what you mean by "before establishing a TLS connection", as certificates are generally exchanged during the TLS handshake, so doing anything "before establishing a TLS connection" would require the server somehow know the client's certificate a priori. There are several systems that will abort the handshake unless they receive an acceptable client certificate, however. I don't know of any RFCs for this per se, or anything that uses the Subject CN (I think almost everything has completely moved away from using the CN). However, as an example, SPIFFE is a largely Kubernetes-focused identity system which encodes a "SPIFFE ID" in the client cert's subjectAltName and uses that to determine whether clients are authorized to continue a TLS connection: https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md -- Tony Arcieri --001a1143750059452f0569f8654b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gon= drom.org> wrote:

Are there any RFCs that speak (beyond the= general verification of the certificate in mutual TLS authentication) to t= he need to also verify the CN inside the client certificate against an addi= tional whitelist _before_ establishing a TLS connection.


I'm not sure what you mean by &quo= t;before establishing a TLS connection", as certificates are generally= exchanged during the TLS handshake, so doing anything "before establi= shing a TLS connection" would require the server somehow know the clie= nt's certificate a priori. There are several systems that will abort th= e handshake unless they receive an acceptable client certificate, however.<= /div>

I don't know of any RFCs for this per se, or a= nything that uses the Subject CN (I think almost everything has completely = moved away from using the CN). However, as an example, SPIFFE is a largely = Kubernetes-focused identity system which encodes a "SPIFFE ID" in= the client cert's subjectAltName and uses that to determine whether cl= ients are authorized to continue a TLS connection:

https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md

--
Tony= Arcieri
--001a1143750059452f0569f8654b-- From nobody Mon Apr 16 08:33:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391DB12778D for ; Mon, 16 Apr 2018 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOHNgLHyJQUi for ; Mon, 16 Apr 2018 08:33:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B83D126CD8 for ; Mon, 16 Apr 2018 08:33:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 61262A00492B; Mon, 16 Apr 2018 08:33:08 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 4D0FFA004937; Mon, 16 Apr 2018 08:31:35 -0700 (PDT) Date: Mon, 16 Apr 2018 10:31:11 -0500 From: Nico Williams To: Richard Barnes Cc: Eric Rescorla , TLS WG Message-ID: <20180416153110.GY25259@localhost> References: <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <20180413202936.GX25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:33:11 -0000 On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote: > On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams > wrote: > > It's better to send the denial of existence than no extension -- the > > client could just as well be pinning (because the I-D said it could, or > > because the client does it regardless), and not having extension then > > will cause failure. > > > > Now, clients that don't do opportunistic pinning would have to... notice > > the lack of TLSA RRs, but not necessarily bother validating the denial > > of existence chain. There's not even a need to say that the client > > SHOULD (let alone MUST) validate the denial of existence chain. It > > suffices that the server SHOULD send it. > > Sure seems like it would be simpler to say "Client MUST NOT cache TLSA > state". Yes, that cuts off some use cases. But it avoids all the That's not the right way to say "no pinning". > transition pain that EKR has pointed out. The I-D needs *some* updates. You and I disagree about which updates, but it needs updates. It cannot be published as-is. Even removing any kind of pinning requires WG consensus at this point. And we've already seem that at least one author support (A), and we could probably easily get support for a (C') where we get the two bytes we're asking for as well but with as much semantics as possible left for a follow-on I-D. Nico -- From nobody Mon Apr 16 08:52:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2258412E8DC for ; Mon, 16 Apr 2018 08:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.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 4F4NquJIV-Sv for ; Mon, 16 Apr 2018 08:52:52 -0700 (PDT) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FD712EB64 for ; Mon, 16 Apr 2018 08:52:33 -0700 (PDT) Received: from seraph (unknown [45.56.155.176]) by gondrom.org (Postfix) with ESMTPSA id 13DEF6495F; Mon, 16 Apr 2018 17:52:17 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=P2TqT8Z8JciIAXlPd64onuNqP/yylHHNHY5tTF4+7xyMDnlB+xSOGklLYGc3F9Bjtv95OdPMOyHC3v4rKmtdzpM5D+29/MrmbwDq9/CZnAj74mngRgAaZWe9aYGiY/721ihJCEKa7yKrcheV/DcPPmkqj1mDJfR89+OITLsm4jA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Content-Language:Importance; From: "Tobias Gondrom" To: "'Kathleen Moriarty'" , "'Eric Rescorla'" Cc: References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> <0FEA7711-7DC1-487B-A544-FAEFC9377C96@gmail.com> In-Reply-To: <0FEA7711-7DC1-487B-A544-FAEFC9377C96@gmail.com> Date: Mon, 16 Apr 2018 23:50:53 +0800 Message-ID: <07ef01d3d59a$ebdb1600$c3914200$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07F0_01D3D5DD.FA033800" X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNgGXr0wwxaLPmB2h28wc3ki2Uh3gITVnudAaaDtpigzTGSEA== Content-Language: en-us Importance: Low Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 15:52:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07F0_01D3D5DD.FA033800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kathleen, Ekr and Tony,=20 =20 Thank you so much for your fast feedback.=20 I did google a bit before asking, but didn=E2=80=99t dig deep enough = into the document to find the right one.=20 Your answers were most helpful.=20 And I will dig more into the RFC link from Kathleen and the github link = from Tony.=20 =20 Thanks a lot! =20 Tobias =20 =20 From: Kathleen Moriarty =20 Sent: Monday, April 16, 2018 9:20 PM To: Eric Rescorla Cc: Tobias Gondrom ; = Subject: Re: [TLS] question about verification of client side = certificate for TLS session for mutual authentication =20 Hi Tobias, =20 If you use search terms that include pkix, authorization, access = control, and attribute certificate profile, you=E2=80=99ll find a few = documents. This one should be helpful based on your description: =20 https://tools.ietf.org/html/rfc5755 =20 Best regards, Kathleen=20 Sent from my mobile device On Apr 16, 2018, at 4:55 AM, Eric Rescorla > wrote: I am not aware of anywhere this is documented, primarily because it's so = application-specifiic. =20 -Ekr =20 =20 On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom = > wrote: Hi dear TLS experts,=20 =20 Apologies for my stupid question for advise:=20 I am currently working on some design requirements for mutual = authentication and have a question regarding verification of client = certificate.=20 =20 In many web scenarios the simple use is server authentication by = certificate and verification of client id by username & password or by a = simple verification of client certificate.=20 =20 Are there any RFCs that speak (beyond the general verification of the = certificate in mutual TLS authentication) to the need to also verify the = CN inside the client certificate against an additional whitelist = _before_ establishing a TLS connection.=20 =20 For example in this scenario:=20 A client with a valid certificate may be allowed to connect to = application 1, but would not be allowed to connect to application 2. = (for sake of separation application 1 and 2 are on separate servers = (application 1 on server 1 and application 2 on server 2).)=20 =20 >From my current understanding, I would establish the TLS connection in = both cases, do mutual authentication and then let application 2 reject = access based on that the user is not allowed to access it. There is a = question whether this would expose to a risk that server resources could = be exhausted by allowing to establish the TLS connection before failing, = but this does not seem too bad to me. But maybe I am missing = something=E2=80=A6 =20 Are there any informational (or standard) RFCs for TLS that speak about = this risk and best practices to address it? =20 (e.g. using additional whitelist checks of parameters inside the client = certificate for access control checks already during phase of = establishing the TLS connection) =20 Thank you and sorry for bothering, Tobias =20 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_07F0_01D3D5DD.FA033800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Kathleen, Ekr and Tony,

 

Thank you so = much for your fast feedback.

I did = google a bit before asking, but didn=E2=80=99t dig deep enough into the = document to find the right one.

Your = answers were most helpful.

And I = will dig more into the RFC link from Kathleen and the github link from = Tony.

 

Thanks a lot!

 

Tobias

 

 

From: Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com>
Sent: Monday, April = 16, 2018 9:20 PM
To: Eric Rescorla = <ekr@rtfm.com>
Cc: Tobias Gondrom = <tobias.gondrom@gondrom.org>; <tls@ietf.org> = <tls@ietf.org>
Subject: Re: [TLS] question about = verification of client side certificate for TLS session for mutual = authentication

 

Hi = Tobias,

 

If you use search terms that include pkix, = authorization, access control, and attribute certificate profile, = you=E2=80=99ll find a few documents.  This one should be helpful = based on your description:

 

 

Best regards,

Kathleen 

Sent from my mobile = device


On Apr 16, 2018, at 4:55 AM, Eric = Rescorla <ekr@rtfm.com> = wrote:

I am not aware of anywhere this is documented, = primarily because it's so = application-specifiic.

 

-Ekr

 

 

On Mon, = Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> = wrote:

Hi dear TLS = experts,

 <= /o:p>

Apologies = for my stupid question for advise:

I am = currently working on some design requirements for mutual authentication = and have a question regarding verification of client certificate. =

 <= /o:p>

In many web = scenarios the simple use is server authentication by certificate and = verification of client id by username & password or by a simple = verification of client certificate.

 <= /o:p>

Are there = any RFCs that speak (beyond the general verification of the certificate = in mutual TLS authentication) to the need to also verify the CN inside = the client certificate against an additional whitelist _before_ = establishing a TLS connection.

 <= /o:p>

For example = in this scenario:

A client = with a valid certificate may be allowed to connect to application 1, but = would not be allowed to connect to application 2. (for sake of = separation application 1 and 2 are on separate servers (application 1 on = server 1 and application 2 on server 2).)

 <= /o:p>

From my = current understanding, I would establish the TLS connection in both = cases, do mutual authentication and then let application 2 reject access = based on that the user is not allowed to access it. There is a question = whether this would expose to a risk that server resources could be = exhausted by allowing to establish the TLS connection before failing, = but this does not seem too bad to me. But maybe I am missing = something=E2=80=A6

 <= /o:p>

Are = there any informational (or standard) RFCs for TLS that speak about this = risk and best practices to address it?  

(e.g. = using additional whitelist checks of parameters inside the client = certificate for access control checks already during phase of = establishing the TLS connection)

 <= /o:p>

Thank you = and sorry for bothering, Tobias

 <= /o:p>


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

 

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

------=_NextPart_000_07F0_01D3D5DD.FA033800-- From nobody Mon Apr 16 09:11:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9C12E8E7 for ; Mon, 16 Apr 2018 09:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xaS4N4YkHowy for ; Mon, 16 Apr 2018 09:11:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C9012E8DE for ; Mon, 16 Apr 2018 09:11:42 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3DB727A3309 for ; Mon, 16 Apr 2018 16:11:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni X-Priority: 5 (Lowest) In-Reply-To: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> Date: Mon, 16 Apr 2018 12:11:40 -0400 Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:11:44 -0000 > On Apr 16, 2018, at 5:56 AM, Tobias Gondrom = wrote: >=20 > Are there any informational (or standard) RFCs for TLS that speak = about this risk and best practices to address it? =20 > (e.g. using additional whitelist checks of parameters inside the = client certificate for access control checks already during phase of = establishing the TLS connection) A major obstacle to making access control decisions during the TLS = handshake is that at that time the server often does not yet have enough = information to determine which specific resource the client will ask to = access. If the access control is very coarse, and the client is simply not = allowed any of the features of the application, then one might terminate = the handshake "early", but by the time server has processed the client = certificate it has done pretty much all the heavy lifting (signing its = own key exchange messages, ...) so allowing the handshake to complete = and dealing with access control at the application layer is far more = typical, and makes possible more meaningful (to the client application) = "Permission denied" error responses, which would be far less likely to = be understood if communicated via a handshake failure. --=20 Viktor. From nobody Mon Apr 16 09:33:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B1D12DA13 for ; Mon, 16 Apr 2018 09:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLgVSmDKYfZy for ; Mon, 16 Apr 2018 09:33:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5D112D95F for ; Mon, 16 Apr 2018 09:33:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 024C4A004915; Mon, 16 Apr 2018 09:33:27 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 97BA5A000B32; Mon, 16 Apr 2018 09:33:26 -0700 (PDT) Date: Mon, 16 Apr 2018 11:31:23 -0500 From: Nico Williams To: Jim Fenton Cc: tls@ietf.org Message-ID: <20180416163123.GZ25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:33:29 -0000 On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote: > From reading the abstract and introduction to this draft, it appears to > be proposing mostly a performance improvement for retrieving web pages > using DANE authentication. There is some security improvement, but that > seems to be incidental to the performance improvement. That would argue > in favor of publishing the draft as-is. However: It's not just a performance improvement. It's also a last-mile technology: for clients that cannot perform DNS lookups due to being in, e.g., hotel networks. And it adds security. Using DANE adds security, that's for sure, since one can then rely on both, PKIX *and* DNSSEC, which can only add security. Or, if one does not trust the WebPKI, then only DNSSEC. I have no opinion as to which of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have an opinion as to who ought to decide that: the server operator. This document gives the server operator that power, but it does not give the server operator any power over client pinning behavior, which means that operators will not turn this on for apps where it's not mandatory. That is, without revision, this document really does not help security as much as with a rather minor revision. We should want that minor revision because the (at-this-time-intangible) gain is potentially large, while the (at-this-time-intangible) cost/risk of not making that revision is equally large. > From the discussion I have read, there seems to be disagreement about > what even the semantics of this pinning would be. And if it's unclear to Among proponents there are no disagreements over pinning semantics. Pinning would be only to the use of the _extension_, not to the use of DANE, nor to any particular DANE usage. That is, if the server does not have TLSA RRs, it could still use this extension [to satisfy a client pin] to send the denial of existence proof, and the client's pin would be satisfied. > the WG participants, it's going to be even less clear to others that are > implementing this. I am also of the opinion that pinning is somewhat How would that follow? Shouldn't we see proposed text before we can tell if it would be unclear to implementors? > subtle; it requires a detailed understanding of the mechanism to remove > (expire) the pin, and if done wrong can result in availability problems. Exactly! (A) gives us a modicum of pin-clearing capability: if you get a denial of existence then you could clear the pin on the client. However, (A) + (B) (i.e., (C)) would give us the ability to separate the pin set/clear from the DNSSEC payload of the extension. *This* would give server operators all the control they need to feel safe enabling pinning behavior. It is much simpler to change a TTL in a server configuration than to make changes in the relevant DNS zone(s). Thus (C) or some (C') (see below) would be much better than (A). > In addition, the pins here would be maintained in individual browsers. And other user-agents for other application protocols (e.g., MUAs). > There is less benefit from pinning because unlike some other pinning > mechanisms, there isn't any leverage of the TOFU experience had by others. TOFU works reasonably well. It's risky for an attacker to mount an active attack that will be detected if the client has a pin -- this risk acts as deterrent. > This requires further thought, and I do not support adding pinning to > this draft. Perhaps as a separate draft, but the WG needs to decide on that. I wouldn't mind a (C'): a variant of (C) where we get denial of existence and a one- or two-byte TTL (one by count of weeks or two-byte count of hours) with de minimis text about it, leaving pinning semantics to a separate document. In such a (C') we'd elide all pinning (or most*) in this document. * We might want to say that if the TTL is zero then the clients MUST NOT pin and must clear any pin. And we might do this in spite of not describing any pinning semantics -- explicitly leaving pinning semantics to a future document. Nico -- From nobody Mon Apr 16 10:06:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0CB127869 for ; Mon, 16 Apr 2018 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tb6g3p0Fdbir for ; Mon, 16 Apr 2018 10:06:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B86120721 for ; Mon, 16 Apr 2018 10:06:46 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9783A7A3309 for ; Mon, 16 Apr 2018 17:06:45 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <20180416163123.GZ25259@localhost> Date: Mon, 16 Apr 2018 13:06:44 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <510EC72B-89A6-4B9A-A937-3331FD144C2B@dukhovni.org> References: <20180416163123.GZ25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:06:48 -0000 > On Apr 16, 2018, at 12:31 PM, Nico Williams wrote: > > I wouldn't mind a (C'): a variant of (C) where we get denial of > existence and a one- or two-byte TTL (one by count of weeks or two-byte > count of hours) with de minimis text about it, leaving pinning semantics > to a separate document. In such a (C') we'd elide all pinning (or most*) > in this document. Specifically, this actually would help the cause of those who don't want pinning, because in (C') we can specify: * Client's MUST NOT employ any pinning for downgrade protection when the extension support TTL sent by the server is ZERO. Only a-priori local policy that mandates DANE TLSA records for particular domains can require the extension, in all other cases the extension MUST be optional in future connections when an authenticated server returns a ZERO extension TTL. * Pending future specifications, the server MUST set the extension support TTL to ZERO. With this, we get to explicitly specify that clients MUST NOT pin, rather than removing text and leaving the option up to the implementors imagination. And implementors will want downgrade protection, and the current list of half-baked downgrade protection measures in Section 8 was in place at the time of the WG LC consensus for moving the draft forward, and these were added in lieu of tackling downgrades in a more systematic way, so ripping it all out does not seem like a minor tweak. If we add a two byte extension support TTL field, that servers will set to ZERO, and tell clients to not attempt downgrade protection when it is so set, we leave room for future downgrade protection without having to change the extension wire format. With the TTL always returned as ZERO in the recent past, the server is equally free to return denial of existence or just not present the extension. Operator's choice. This way, the draft retains the option of future downgrade protection, thus not completely abandoning its promised scope, while deferring any pinning for now, and indeed making it very clear to clients that they MUST NOT (yet) do any TOFU or similar pinning. > * We might want to say that if the TTL is zero then the clients MUST NOT > pin and must clear any pin. And we might do this in spite of not > describing any pinning semantics -- explicitly leaving pinning > semantics to a future document. Exactly. I'd like to suggest that this is the most reasonable common ground, and would urge the WG and authors to get behind this as a consensus position. -- Viktor. From nobody Mon Apr 16 10:29:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2A9120721 for ; Mon, 16 Apr 2018 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhwpiNDCIY1o for ; Mon, 16 Apr 2018 10:29:23 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (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 2439C127909 for ; Mon, 16 Apr 2018 10:29:23 -0700 (PDT) Received: from [47.143.125.141] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1f87wO-000AI6-O3; Mon, 16 Apr 2018 13:29:20 -0400 Date: Mon, 16 Apr 2018 10:29:20 -0700 From: Bill Frantz To: Nico Williams cc: Jim Fenton , tls@ietf.org X-Priority: 3 In-Reply-To: <20180416163123.GZ25259@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7928f5cab986287273752e90c0cbd5b2c4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.141 Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 17:29:25 -0000 On 4/16/18 at 9:31 AM, nico@cryptonector.com (Nico Williams) wrote: >I wouldn't mind a (C'): a variant of (C) where we get denial of >existence and a one- or two-byte TTL (one by count of weeks or two-byte >count of hours) with de minimis text about it, leaving pinning semantics >to a separate document. In such a (C') we'd elide all pinning (or most*) >in this document. I have always worried about the trust model in PKIX, and thought=20 that some form of pinning would an excellent enhancement --=20 modeling how individuals work in the real world: Alice, I'd like you to meet Bob. He is an expert in... (Alice=20 learns Bob's voice pattern.) Bob, this is Alice, I'd like you to... (Alice recognizes=20 Bob's voice in the reply.) I strongly support C or C' as the best way forward, allowing a=20 future RFC to address the pinning details. Viktor has some good=20 suggestions as well. Note: I have not been involved in any face-to-face meetings or hums. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345=20 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos,=20 CA 95032 From nobody Mon Apr 16 11:38:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5A1241F5 for ; Mon, 16 Apr 2018 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz-r1WVZPCsP for ; Mon, 16 Apr 2018 11:38:50 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B2812025C for ; Mon, 16 Apr 2018 11:38:50 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id v205so10106221vkv.13 for ; Mon, 16 Apr 2018 11:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=W7skeZU6UCDyzeJvTalBDGYHfQcDy8BgOhw2BzwZSfc=; b=N/T5gYwbmD5JzWfR70/NZO22T4qbIOxkPC2zcG6lMh/6dtbxy+NZW8335sJT4POriz 7xDQ5rlqsAdLKKi1fftFT+0KbryyPAlSVLHRxZI8VXYlSq58IqNtK8xoBp9cCq6qVzvm 6XVqLXmqX7A7tX66AsOhWK1078s37EjVYl0aRCtPeC+vpr8PBUif8ZcqjXyc0LaVp8ZV YnDpYBL0j/JV2mzNgwQPpIPu+nEpJr5BTBwVxxVEamcv+sUhX+FPRm8+/JNEw2ai+xaG IEu6hqiywHMy1dsdZzsdzSCoU0hIMd+nPUOR/u2tHN0MbE+kxiToU5mEHBZXQXmmWDlx HuWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=W7skeZU6UCDyzeJvTalBDGYHfQcDy8BgOhw2BzwZSfc=; b=h0nsqE1OGMwhk/Of4Ch4OAy42gxP5YU+n2/6ipTdikJXpWu0AvxKiDeKJlnXyRs4QL sSuEX5Giw6Wercji02NEMz1aXdwQygEkEJfkrbyi70lzZFBqfnvp1lRXzfBn0erTauY2 upeil5Yos0PHfDDUmRlFdgWsaZzYOWzqrLzDHmu57eguese149y7Bv7keN56vQD8nxog JcViwQxmgU+DiSTp4/ue/bGWPuQm2SR75NbJOWA0Jg1l/K4Al6j+2Ixxb00YpgmlAbq8 TZnhcMvjXXiL8kkv/8Hf1c+RQ34Mr2dWT/0/Y3585CedDUZcCy4hUGureXLRvb3DTbna nGmA== X-Gm-Message-State: ALQs6tB5JP8CF+mPFa6hAQ/0kKtZA6QqzjBLW5pigJ17yW9bjrlYn4/Y yrBVH9y5Dc0amLBoqWo6qEPnazke0zlUeybQN7K8AA== X-Google-Smtp-Source: AIpwx49Bfx8sWszIvzyRtddAFrUX/kzcrM/tkjWFec9U8Z5UBxPmG4A/MR2LMN0SJ5niiNuBMy5xJ+BDhuuKhWfkXLU= X-Received: by 10.31.54.148 with SMTP id d142mr5374902vka.69.1523903928911; Mon, 16 Apr 2018 11:38:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.102.65 with HTTP; Mon, 16 Apr 2018 11:38:28 -0700 (PDT) In-Reply-To: <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org> From: Tony Arcieri Date: Mon, 16 Apr 2018 11:38:28 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="001a1143b67e5acb6a0569fb883d" Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:38:52 -0000 --001a1143b67e5acb6a0569fb883d Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni wrote: > A major obstacle to making access control decisions during the TLS > handshake is that at that time the server often does not yet have enough > information to determine which specific resource the client will ask to > access. There's also the problem that (at least in an SOA/"microservice architecture") people will inevitably want some resources to be accessible without a client certificate, e.g. status endpoints or anything consumed by clients which do not support TLS certificates. In these cases it really helps to force things up a level out of the TLS handshake into something at the application level like an ACL language that lets you whitelist unauthenticated access to these resources. -- Tony Arcieri --001a1143b67e5acb6a0569fb883d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
A major obstacle t= o making access control decisions during the TLS handshake is that at that = time the server often does not yet have enough information to determine whi= ch specific resource the client will ask to access.

There's also the problem that (at least in an SOA/"micros= ervice architecture") people will inevitably want some resources to be= accessible without a client certificate, e.g. status endpoints or anything= consumed by clients which do not support TLS certificates. In these cases = it really helps to force things up a level out of the TLS handshake into so= mething at the application level like an ACL language that lets you whiteli= st unauthenticated access to these resources.

-- =
Tony = Arcieri
--001a1143b67e5acb6a0569fb883d-- From nobody Mon Apr 16 11:43:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D7612E874 for ; Mon, 16 Apr 2018 11:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 fPLZ9Y158dLf for ; Mon, 16 Apr 2018 11:43:28 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A4412E05D for ; Mon, 16 Apr 2018 11:43:28 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id w2-v6so7595023otj.12 for ; Mon, 16 Apr 2018 11:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5JGM+yrVizEWhvPOiYk9BranYHfj7xycm9Zab5CtH5A=; b=s27oWKnGDKqTaAzlaLQD4SMj6rXNhZ8K1jgvTNLqkDZdJATOiE/Bufpp89IdzftmkM 4bIOT5D4aEU5RWe6Nmqqvd2qBVe0iIlttbuKODdZeWG4LkQnMrtMBh693hflkUmQRP0F hXyf5Lk3iHBWUw8fJWqXYabSArF4AuG/CjdF1iXl3/7qYC181gN1lO5c+C981gkrGoj1 TWMkiZQ5fTpi1d0CqJgyO/lQhRyYAZgwURYSdvqXKMyuw1oIlpk0ctMkq4IPRiKO77WS O5SULcXdKwktgT1pnX63qCO/P36xv82nRAVP61nTNagsTk8DhZ4Y9+0LZviJEPHHfDnD tg1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5JGM+yrVizEWhvPOiYk9BranYHfj7xycm9Zab5CtH5A=; b=ZG2jr4DK8H9a9IS9yPvm3j8dLItcicSpid00JP0evQNfAUsAf8QL0yMy+aSqxKp2nr ZiJvYgIhYhtRwtOunJANuuUySTQtPA0XL+pji0kbYV8TFwBEpXtLcfZv/tNgVlWaZpYr KIQa/+5eglVOcgPAlcYPG6YvFsM2PnU4hxDuLTncep2htl7VI2kdh1C0MjxGAWfCAQyh ra2lAyPFGvLSqEzyDJpG9dAD0jFR4lyWu6a6b8R6aPIt0D/M9P93C9BekKpVJsWIVFeB Bt6kHQKB9t3IbA8qdGbVuX3u1KVyKwrYQMn5u/MEELIq0LGK5eey1bkD2f/0VLa0Ps4a Myzw== X-Gm-Message-State: ALQs6tD890U+Z61kRz39EXcUwKOrDYyK8B2g4srcqf2sd/CCPzFZLwJy v7+VDr8G2UWeNfGzdz/ixKCsT6m3tp+peYP6nb9nkg== X-Google-Smtp-Source: AIpwx48UV44xc13wmBRjMw0AOKDqWocJWBWaG2kyZ7LGiA6JWRj0EO1+T395fLcWSjvfy0h8dam+7RebNGESQQZGx24= X-Received: by 2002:a9d:738e:: with SMTP id j14-v6mr11502747otk.248.1523904207530; Mon, 16 Apr 2018 11:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 11:43:26 -0700 (PDT) In-Reply-To: References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> From: Richard Barnes Date: Mon, 16 Apr 2018 14:43:26 -0400 Message-ID: To: Jonathan Hoyland Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000f640630569fb9841" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:43:31 -0000 --000000000000f640630569fb9841 Content-Type: text/plain; charset="UTF-8" Hey Jonathan, Thanks for the comments. I've implemented them in my working copy of the draft, and in my implementation in mint. I have also changed it over to use SPAKE2+; I agree with Tony that this is necessary to guard against server compromise. https://github.com/bifurcation/tls-pake/commit/a9f097c3bfe43cf50001e1a340c7e2e693850d4b https://github.com/bifurcation/mint/pull/193 With regard to security properties: I don't think it's correct that an active attacker can do online password guessing. Everything that is revealed on the wire is blinded with fresh, per-connection entropy, and thus doesn't reveal anything about the password. --Richard On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < jonathan.hoyland@gmail.com> wrote: > Hi Richard, > > A few nits. > > * In the introduction you have the sentence > > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet > > seen significant security analysis. > > Iiuc this draft has no connection to MLS, and this is a typo. > > * In the setup you define > > > o A DH group "G" of order "p*h", with "p" a large prime > > and > > > o A password "p" > > > The variable "p" has two different meanings, which is a bit confusing, > especially later on. > > * The document doesn't explicitly state that X and Y need to be non-zero. > > The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the > warning was carried through. > > * In terms of security properties, iiuc an active adversary can do online > password guessing attacks, but a passive adversary cannot derive the > password from observing the messages. If that is the case perhaps a warning > about rate-limiting connection attempts is appropriate. > > Regards, > > Jonathan > > On Mon, 16 Apr 2018 at 10:50 Tony Putman wrote: > >> Hi Richard, >> >> I don't think that you can protect against server compromise with SPAKE2. >> The server can store w*N as you suggest, but it also has to store w*M >> because it must calculate y*(T-w*M). An attacker that learns w*M and w*N >> from a compromised server can then impersonate a client. >> >> The rest of your comments I agree with (though they are not all addressed >> in the updated draft). >> >> Tony >> >> > From: Richard Barnes [mailto:rlb@ipv.sx] >> > Sent: 13 April 2018 19:50 >> > >> > Hey Tony, >> > >> > Thanks for the comments. Hopefully we can adapt this document to tick >> more boxes for you :) >> > Since I had noticed some other errors in the document (e.g., figures >> not rendering properly), >> > I went ahead and submitted a new version that takes these comments into >> account. >> > >> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >> > >> > Some responses inline below. >> >> Dyson Technology Limited, company number 01959090, Tetbury Hill, >> Malmesbury, SN16 0RP, UK. >> This message is intended solely for the addressee and may contain >> confidential information. If you have received this message in error, >> please immediately and permanently delete it, and do not use, copy or >> disclose the information contained in this message or in any attachment. >> Dyson may monitor email traffic data and content for security & training. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000f640630569fb9841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Jonathan,

Thanks for the= comments.=C2=A0 I've implemented them in my working copy of the draft,= and in my implementation in mint.=C2=A0 I have also changed it over to use= SPAKE2+; I agree with Tony that this is necessary to guard against server = compromise.


With regard to security properties: I don't think it's correct t= hat an active attacker can do online password guessing.=C2=A0 Everything th= at is revealed on the wire is blinded with fresh, per-connection entropy, a= nd thus doesn't reveal anything about the password.=C2=A0

--Richard


On Mon, Apr 16, 2018 at 7:52 AM, Jo= nathan Hoyland <jonathan.hoyland@gmail.com> wrote:<= br>
Hi Richard,

A few nits.

=
* In the introduction you have the sen= tence
>=C2=A0DISCLAIMER: This is a work-in-progress draft o= f MLS and has not yet
   seen significant security analysis.Iiuc this draft has no connection to MLS,=
 and this is a typo.
 
* In the se=
tup you define=C2=A0
> o  A DH group =
"G" of order "p*h", with "p" a large prime
and 
> o  A password "p"

The variable &quo=
t;p" has two different meanings, which is a bit confusing, especially =
later on.
 
* The document doesn't explicitly state that X and Y=
 need to be non-zero.=C2=A0
The requirement is in "I-D.irtf-cfrg=
-spake2", but it would be nice if the warning was carried through.
=

* In terms of security properties,=
 iiuc an active adversary can do online password guessing attacks, but a pa=
ssive adversary cannot derive the password from observing the messages. If =
that is the case perhaps a warning about rate-limiting connection attempts =
is appropriate.=C2=A0

Regards,

Jonathan

On Mon, 16 Apr 2018 at 1=
0:50 Tony Putman <Tony.Putman@dyson.com> wrote:
Hi Richard,



I don't think that you can protect against server compromise with SPAKE=
2. The server can store w*N as you suggest, but it also has to store w*M be=
cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from=
 a compromised server can then impersonate a client. 



The rest of your comments I agree with (though they are not all addressed i=
n the updated draft). 



Tony



> From: Richard Barnes [mailto:rlb@ipv.sx] 

> Sent: 13 April 2018 19:50

>

> Hey Tony,

>

> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to=
 tick more boxes for you :)=C2=A0 

> Since I had noticed some other errors in the document (e.g., figures n=
ot rendering properly), 

> I went ahead and submitted a new version that takes these comments int=
o account.

>

> https://tools.ietf.org/html/draft-ba=
rnes-tls-pake-01

>

> Some responses inline below.



Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury=
, SN16 0RP, UK.

This message is intended solely for the addressee and may contain confident=
ial information. If you have received this message in error, please immedia=
tely and permanently delete it, and do not use, copy or disclose the inform=
ation contained in this message or in any attachment.

Dyson may monitor email traffic data and content for security & trainin=
g.

_______________________________________________

TLS mailing list

TLS@ietf.org

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

--000000000000f640630569fb9841-- From nobody Mon Apr 16 11:51:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F71126CF6 for ; Mon, 16 Apr 2018 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgWUNZv2eAh5 for ; Mon, 16 Apr 2018 11:51:38 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731BB126CC4 for ; Mon, 16 Apr 2018 11:51:38 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id AE61F6000915; Mon, 16 Apr 2018 11:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4H8/NOIIRLypii KGD2SXcl4AojE=; b=ZHR3pbviS4szoO8tTndQMHsEgEN9zVYSE338wzIEFj74ff 7ge0ivFF56ednavOu+cGfYjPltxyuaLaNB6pi/SAXV6atIMJJxtW8+MyWf8WKfFG LJtD2H5NrjnpjcnoIJbvQ8v0A7nr5ppxl2z1WxCbx29BUrVbs2y5SYvfx3P/Y= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 609106000139; Mon, 16 Apr 2018 11:51:37 -0700 (PDT) Date: Mon, 16 Apr 2018 13:45:44 -0500 From: Nico Williams To: Tony Arcieri Cc: TLS WG Message-ID: <20180416184543.GB25259@localhost> References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:51:40 -0000 On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote: > On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni > wrote: > > A major obstacle to making access control decisions during the TLS > > handshake is that at that time the server often does not yet have enough > > information to determine which specific resource the client will ask to > > access. > > There's also the problem that (at least in an SOA/"microservice > architecture") people will inevitably want some resources to be accessible > without a client certificate, e.g. status endpoints or anything consumed by > clients which do not support TLS certificates. In these cases it really > helps to force things up a level out of the TLS handshake into something at > the application level like an ACL language that lets you whitelist > unauthenticated access to these resources. Indeed, one might even say that user authentication should be driven by application needs. This is done in HTTP, for example, via 401 responses, which can trigger HTTP authentication. Granted, HTTP authentication methods are fairly limited. If a client is authenticated at the TLS layer, authorization should still happen at the application layer as much as possible, as otherwise access control is very coarse-grained. Nico -- From nobody Mon Apr 16 11:59:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3772A126CD6 for ; Mon, 16 Apr 2018 11:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWrU0WqA9Pwn for ; Mon, 16 Apr 2018 11:59:30 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36565126CC4 for ; Mon, 16 Apr 2018 11:59:30 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q38so10820203uad.5 for ; Mon, 16 Apr 2018 11:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KA7jbWpOQcElQatOAqRVyanVR6x4TFQdA9xw5oaG56w=; b=gHO9Cp3DQ50yXPYJsAyfxaAGJbAxuJyE6BQkHH7R0QkLK3oUp54P/5EWVG9tr7tO/S 7pulpOMNf8qBLDT8/VV6WCaUQDW00FTiabmTe9e7Z8+RJ+fTXKGPMJHuX8/NOlbld1Zk zOH2rBFOUh/zw+sMzk+2Zw9UP8PzZgj+RTYTWzXe+fRi7IxNwjaW3nNmkLAD52oSqHzO 5A2mwszAdxJdh8XiiL5ZBqmVm3gCROAsw2u9P6rrpPqBsLAtI/h2YSQXJ5HKmDtILuFP gANAVtSDNtfCcTOCOLOPNKZ3C4qF68ucjQJC5inspf/mIQLk/ABPOynMpVQNgu0N10i3 PaPg== 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=KA7jbWpOQcElQatOAqRVyanVR6x4TFQdA9xw5oaG56w=; b=OPqyeheNqQn5NMEsJc/owmaCo4UtDDOl2xFDqAWjjgMIHqcV/k6jnnZKbrVEcN9I/I ovNecDzVSEGZwH2sslf4QE43qnYSCicQdfosNL8Pdu4Pp2tSNI3Soy5dHRS18ZUoIeUA D2j4JP7+8o2RRw7Lobr697mSn8/LuR2cwitTJB/JWIzSfclyrl1lCswD3/Tj0PmXxu/9 enpEz7MGdfnoG1Oq9MI1HQEUEoIqxxBbyevzyPA3uoLb4X2TcuMoi3AudbyEeokLk0k/ z2gAxTGsW9cxjFUoEJhLpqDq/Y4yAmiksCu16ZWMiSEW1tUaoFEC2G079tb0n9yTD9Al JuDg== X-Gm-Message-State: ALQs6tBIHb0T8rdCl9SFIT5aB/T4m9ghiqCZ7eSG97016FUYFZb/sxjX o1/y9q/bsscHeeEKkGyqdzvsGrsxNVsD63McKew= X-Google-Smtp-Source: AIpwx4+HrC68FIClCYyzepvPip/BcI0Mr69j56+q4hRzO6rRcgMLed+sWtkuIP4nMd2zvsza2LF3n9tIKT1uVv3IfnM= X-Received: by 10.176.23.11 with SMTP id j11mr12366958uaf.133.1523905169144; Mon, 16 Apr 2018 11:59:29 -0700 (PDT) MIME-Version: 1.0 References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> In-Reply-To: From: Jonathan Hoyland Date: Mon, 16 Apr 2018 18:59:18 +0000 Message-ID: To: Richard Barnes Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="f40304361bea4742710569fbd214" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:59:33 -0000 --f40304361bea4742710569fbd214 Content-Type: text/plain; charset="UTF-8" Hi Richard, That's correct, however if I have a guess of the password can I not just try and connect using that password? If my guess is correct then the connection will succeed, whereas if my guess is incorrect then the connection will fail. I'm assuming here that the salt is public, because salts in general do not have confidentiality guarantees (otherwise they stretch the metaphor and become pepper). (I also assume that the client identity can be derived from observing a previous session, and that the server identity can be identified through probing.) Regards, Jonathan On Mon, 16 Apr 2018 at 19:43 Richard Barnes wrote: > Hey Jonathan, > > Thanks for the comments. I've implemented them in my working copy of the > draft, and in my implementation in mint. I have also changed it over to > use SPAKE2+; I agree with Tony that this is necessary to guard against > server compromise. > > > https://github.com/bifurcation/tls-pake/commit/a9f097c3bfe43cf50001e1a340c7e2e693850d4b > https://github.com/bifurcation/mint/pull/193 > > With regard to security properties: I don't think it's correct that an > active attacker can do online password guessing. Everything that is > revealed on the wire is blinded with fresh, per-connection entropy, and > thus doesn't reveal anything about the password. > > --Richard > > > On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < > jonathan.hoyland@gmail.com> wrote: > >> Hi Richard, >> >> A few nits. >> >> * In the introduction you have the sentence >> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet >> >> seen significant security analysis. >> >> Iiuc this draft has no connection to MLS, and this is a typo. >> >> * In the setup you define >> >> > o A DH group "G" of order "p*h", with "p" a large prime >> >> and >> >> > o A password "p" >> >> >> The variable "p" has two different meanings, which is a bit confusing, >> especially later on. >> >> * The document doesn't explicitly state that X and Y need to be >> non-zero. >> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the >> warning was carried through. >> >> * In terms of security properties, iiuc an active adversary can do online >> password guessing attacks, but a passive adversary cannot derive the >> password from observing the messages. If that is the case perhaps a warning >> about rate-limiting connection attempts is appropriate. >> >> Regards, >> >> Jonathan >> >> On Mon, 16 Apr 2018 at 10:50 Tony Putman wrote: >> >>> Hi Richard, >>> >>> I don't think that you can protect against server compromise with >>> SPAKE2. The server can store w*N as you suggest, but it also has to store >>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and >>> w*N from a compromised server can then impersonate a client. >>> >>> The rest of your comments I agree with (though they are not all >>> addressed in the updated draft). >>> >>> Tony >>> >>> > From: Richard Barnes [mailto:rlb@ipv.sx] >>> > Sent: 13 April 2018 19:50 >>> > >>> > Hey Tony, >>> > >>> > Thanks for the comments. Hopefully we can adapt this document to tick >>> more boxes for you :) >>> > Since I had noticed some other errors in the document (e.g., figures >>> not rendering properly), >>> > I went ahead and submitted a new version that takes these comments >>> into account. >>> > >>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >>> > >>> > Some responses inline below. >>> >>> Dyson Technology Limited, company number 01959090, Tetbury Hill, >>> Malmesbury, SN16 0RP, UK. >>> This message is intended solely for the addressee and may contain >>> confidential information. If you have received this message in error, >>> please immediately and permanently delete it, and do not use, copy or >>> disclose the information contained in this message or in any attachment. >>> Dyson may monitor email traffic data and content for security & training. >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > --f40304361bea4742710569fbd214 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

That's correct, however= if I have a guess of the password can I not just try and connect using tha= t password?
If my guess is correct then the connection will succe= ed, whereas if my guess is incorrect then the connection will fail.=C2=A0
I'm assuming here that the salt is public, because salts in ge= neral do not have confidentiality guarantees (otherwise they stretch the me= taphor and become pepper).=C2=A0
(I also assume that the client i= dentity can be derived from observing a previous session, and that the serv= er identity can be identified through probing.)

Re= gards,

Jonathan



On Mon, 16 Apr 2018 = at 19:43 Richard Barnes <rlb@ipv.sx> wrote:
Hey Jonathan,

Thanks for the comments.=C2=A0 I've implemented them in my working cop= y of the draft, and in my implementation in mint.=C2=A0 I have also changed= it over to use SPAKE2+; I agree with Tony that this is necessary to guard = against server compromise.


With regard to securi= ty properties: I don't think it's correct that an active attacker c= an do online password guessing.=C2=A0 Everything that is revealed on the wi= re is blinded with fresh, per-connection entropy, and thus doesn't reve= al anything about the password.=C2=A0

--Richard


On Mon, Apr 16, 2018 at 7:52 AM, Jon= athan Hoyland <jonathan.hoyland@gmail.com> wrote:
Hi Richard,

A few nits.

<= /div>
* In the introduction you have the sent= ence
>=C2=A0DISCLAIMER: This is a work-in-progress draft of= MLS and has not yet
   seen significant se=
curity analysis.
Iiuc this draft has n= o connection to MLS, and this is a typo.
<= div style=3D"font-size:small">* In the setup you define=C2=A0
> o  A DH group "G"=
 of order "p*h", with "p" a large prime
and 
> o  A password "p"

The variable "p" has two differe=
nt meanings, which is a bit confusing, especially later on.
 
* The document doesn't explicitly state that X and Y n=
eed to be non-zero.=C2=A0
The requirement is in =
"I-D.irtf-cfrg-spake2", but it would be nice if the warning was c=
arried through.

* In terms of s= ecurity properties, iiuc an active adversary can do online password guessin= g attacks, but a passive adversary cannot derive the password from observin= g the messages. If that is the case perhaps a warning about rate-limiting c= onnection attempts is appropriate.=C2=A0

Regards,

Jonathan
<= br>
<= div dir=3D"ltr">On Mon, 16 Apr 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> = wrote:
Hi Richard,

I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-barnes-= tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f40304361bea4742710569fbd214-- From nobody Mon Apr 16 12:01:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74012EA97 for ; Mon, 16 Apr 2018 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 gqmuqZ0sX6aQ for ; Mon, 16 Apr 2018 12:01:37 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0A212EAA4 for ; Mon, 16 Apr 2018 12:01:24 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id p2-v6so1796614otf.3 for ; Mon, 16 Apr 2018 12:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cz0fytVcCmfNu6DzEBztg0PLx2rZB9Cr9igOTBKT1bg=; b=2S5U9jybc/kEjvWcpkaqtZgSAEacLkfcU7zoJqXOR3TvXL8ObLlMst9VBC4NzL+inp gCGJVLWUwAgCp9DgOxn3llhFeEGmURf+SivD2C+VfOqyvb9qtwdTbPuN7/Bp5FuFMCI+ vxXw+O/gE77jdWdlqGiwca9gmk0KD11sUF8XXcFsJJPIDG1mIZrg01YNtCW8HV6NJTa4 4LV8Apr3vV8iLBiSRJDhntLjExI2GMYtbYpAva1zG7t86tKlL45by9+7pkzfMBoraQa7 1YWWI7aOhWAe/Q8YYw3yS71HRMrXdSnauhdo3RUyl565E+tmeiIolFjMQ6mtM2XSzAW4 i+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cz0fytVcCmfNu6DzEBztg0PLx2rZB9Cr9igOTBKT1bg=; b=RMOBlp5MUfBSVrGetjf/mZalbk0UUnTzW3CDk1J32yzfKCGpkKIz6FEtnG8sZtKSoJ G6hCJ8fEdw4LJe51cKXHu0gPieFkGjs/aMPswe0GHE+wU0inQiWwaNXtfTRLorkfSHpk bXzQLAK6iSHNaaNC42DqTASbpTFCAjcN22nF5U9k5MqrQDk7IXewGsIaWnopt1eHqSVW 777kbuwgBBmxa0+HdAfFzNu04KrquCOkenEt+IuEHxYD4x41KCYjM779CvR5RTyHYLU3 nX121QgPdrRqooEQpmjOsV2MToRIc/DsUTD1SabmT1bSJV1HbuwPBSqz2V9W42gFaIF9 TMZQ== X-Gm-Message-State: ALQs6tCt9fzJL8rR0jiAfUmyLH4uSBsr11PgXpSUoZTQivDFrYlH/+50 aA9SxhSuf2fHIrsMJLgeo4CkVpG3MPHv6NsaP6YDxw== X-Google-Smtp-Source: AIpwx4/N1EWqoFvMqYCVwc7iXzgmVu8AHKgYapASwLCyaSGm+r2foy1S8IILN8qZcMQeVplRQTgSDDfzgHNeXvq6PGw= X-Received: by 2002:a9d:1920:: with SMTP id j32-v6mr11792464ota.383.1523905282011; Mon, 16 Apr 2018 12:01:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 12:01:21 -0700 (PDT) In-Reply-To: References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> From: Richard Barnes Date: Mon, 16 Apr 2018 15:01:21 -0400 Message-ID: To: Jonathan Hoyland Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000000188fa0569fbd975" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:01:39 -0000 --0000000000000188fa0569fbd975 Content-Type: text/plain; charset="UTF-8" > That's correct, however if I have a guess of the password can I not just > try and connect using that password? > If my guess is correct then the connection will succeed, whereas if my > guess is incorrect then the connection will fail. > Sure, but aren't you going to have that with any password-authenticated protocol? --Richard > I'm assuming here that the salt is public, because salts in general do not > have confidentiality guarantees (otherwise they stretch the metaphor and > become pepper). > (I also assume that the client identity can be derived from observing a > previous session, and that the server identity can be identified through > probing.) > > Regards, > > Jonathan > > > > On Mon, 16 Apr 2018 at 19:43 Richard Barnes wrote: > >> Hey Jonathan, >> >> Thanks for the comments. I've implemented them in my working copy of the >> draft, and in my implementation in mint. I have also changed it over to >> use SPAKE2+; I agree with Tony that this is necessary to guard against >> server compromise. >> >> https://github.com/bifurcation/tls-pake/commit/ >> a9f097c3bfe43cf50001e1a340c7e2e693850d4b >> https://github.com/bifurcation/mint/pull/193 >> >> With regard to security properties: I don't think it's correct that an >> active attacker can do online password guessing. Everything that is >> revealed on the wire is blinded with fresh, per-connection entropy, and >> thus doesn't reveal anything about the password. >> >> --Richard >> >> >> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < >> jonathan.hoyland@gmail.com> wrote: >> >>> Hi Richard, >>> >>> A few nits. >>> >>> * In the introduction you have the sentence >>> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet >>> >>> seen significant security analysis. >>> >>> Iiuc this draft has no connection to MLS, and this is a typo. >>> >>> * In the setup you define >>> >>> > o A DH group "G" of order "p*h", with "p" a large prime >>> >>> and >>> >>> > o A password "p" >>> >>> >>> The variable "p" has two different meanings, which is a bit confusing, >>> especially later on. >>> >>> * The document doesn't explicitly state that X and Y need to be >>> non-zero. >>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if >>> the warning was carried through. >>> >>> * In terms of security properties, iiuc an active adversary can do >>> online password guessing attacks, but a passive adversary cannot derive the >>> password from observing the messages. If that is the case perhaps a warning >>> about rate-limiting connection attempts is appropriate. >>> >>> Regards, >>> >>> Jonathan >>> >>> On Mon, 16 Apr 2018 at 10:50 Tony Putman wrote: >>> >>>> Hi Richard, >>>> >>>> I don't think that you can protect against server compromise with >>>> SPAKE2. The server can store w*N as you suggest, but it also has to store >>>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and >>>> w*N from a compromised server can then impersonate a client. >>>> >>>> The rest of your comments I agree with (though they are not all >>>> addressed in the updated draft). >>>> >>>> Tony >>>> >>>> > From: Richard Barnes [mailto:rlb@ipv.sx] >>>> > Sent: 13 April 2018 19:50 >>>> > >>>> > Hey Tony, >>>> > >>>> > Thanks for the comments. Hopefully we can adapt this document to >>>> tick more boxes for you :) >>>> > Since I had noticed some other errors in the document (e.g., figures >>>> not rendering properly), >>>> > I went ahead and submitted a new version that takes these comments >>>> into account. >>>> > >>>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >>>> > >>>> > Some responses inline below. >>>> >>>> Dyson Technology Limited, company number 01959090, Tetbury Hill, >>>> Malmesbury, SN16 0RP, UK. >>>> This message is intended solely for the addressee and may contain >>>> confidential information. If you have received this message in error, >>>> please immediately and permanently delete it, and do not use, copy or >>>> disclose the information contained in this message or in any attachment. >>>> Dyson may monitor email traffic data and content for security & >>>> training. >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> >> --0000000000000188fa0569fbd975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
That's correct, ho= wever if I have a guess of the password can I not just try and connect usin= g that password?
If my guess is correct then the connection will = succeed, whereas if my guess is incorrect then the connection will fail.=C2= =A0

Sure, but aren't you go= ing to have that with any password-authenticated protocol?
<= br>
--Richard

=C2=A0
I'm assuming here that the salt = is public, because salts in general do not have confidentiality guarantees = (otherwise they stretch the metaphor and become pepper).=C2=A0
(I= also assume that the client identity can be derived from observing a previ= ous session, and that the server identity can be identified through probing= .)

Regards,

Jonathan



On Mon, 16 Apr 2018 at 19= :43 Richard Barnes <rlb@ipv.sx> wrote:
Hey Jonathan,

Than= ks for the comments.=C2=A0 I've implemented them in my working copy of = the draft, and in my implementation in mint.=C2=A0 I have also changed it o= ver to use SPAKE2+; I agree with Tony that this is necessary to guard again= st server compromise.


With r= egard to security properties: I don't think it's correct that an ac= tive attacker can do online password guessing.=C2=A0 Everything that is rev= ealed on the wire is blinded with fresh, per-connection entropy, and thus d= oesn't reveal anything about the password.=C2=A0

--Richard


On Mon, Apr 16, 2018 = at 7:52 AM, Jonathan Hoyland <jonathan.hoyland@gmail.com><= /span> wrote:
Hi Richard,

=
A few nits.

* In the introduction yo= u have the sentence
>=C2=A0DISCLAIMER: This is a work-in-pr= ogress draft of MLS and has not yet
   seen significant security analysis.
Iiuc this draft has no connection to MLS, and this is a typo= .
* In the setup you define=C2=A0
> o  A DH group "G&qu=
ot; of order "p*h", with "p" a large prime
and 
> o  A password "p"

The variable "p" has two different meanin= gs, which is a bit confusing, especially later on.
* The document doesn't explicitly state that= X and Y need to be non-zero.=C2=A0
The requirement is in "I-D.irtf-cfrg-spake2", but it wou= ld be nice if the warning was carried through.

* In terms of security properties, iiuc an active adversary= can do online password guessing attacks, but a passive adversary cannot de= rive the password from observing the messages. If that is the case perhaps = a warning about rate-limiting connection attempts is appropriate.=C2=A0

R= egards,

Jonathan

On Mon,= 16 Apr 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> wrote:
<= /div>
Hi Richard,

I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-ba= rnes-tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--0000000000000188fa0569fbd975-- From nobody Mon Apr 16 12:07:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7BF12EA9E for ; Mon, 16 Apr 2018 12:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWvIR4F8zwB2 for ; Mon, 16 Apr 2018 12:07:05 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 C271312EAA5 for ; Mon, 16 Apr 2018 12:07:04 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id q38so10835960uad.5 for ; Mon, 16 Apr 2018 12:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VRGwSC3xbLZqvcIn3bEh5YzwM3jW9XElxIjlq8mDEQ4=; b=lsO9p4/hmTzdTNFwjbbeogiMZejEePD650IyMR9tG0TQ7soHWvrsU+iIMRu48rbJek 09tG3dvEXvJxyN/i7Delngfy3U5W7D19GEH1YuZuaerlNZv/WsmVx/7ttu0yya5TxWqP Y6NwkUJqc9dNg7ZHov/BihT/EA3VEZ5P/0wfm7c35JYeOPPvgcF0A5oDt8lj7qGZxif4 aVfC6g1WTZLFTdRKUPCmYz0gt3f1wbUpt3TLei+s5pr3I4wFkZ08TfoiAGYc+FniYhH3 jkdhW0/VDwYE5uvKewO2V0X8dcN+bXICMKwxaTCLZC2z5e62HZ7rZTW1HZG3gHjqbSUS t7Gg== 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=VRGwSC3xbLZqvcIn3bEh5YzwM3jW9XElxIjlq8mDEQ4=; b=CsqjHgNdkT4B1yo/c/gW/ZT0Tg/Y7TiL5Nez+ESgoPNv2EGs4RFdBv7v8YeFMpmzNP /bQ3w1wyJjyuCgWeODjL7HSII5NGzPWywFRmPw5UqiWzARLVsS2mS+Pl6zI/NykNBd2h r3iTL0CgPgkdkCW4VeC3/Bok1MQkv4+HHMHqgcATbw49kzqullPhRugFKUIK18JJjkt6 BaxUsF+mvDGpX2zuIa8rsTqdhkLL2dDmjAl62hM49lbK2h3Rl82WuVO3bfa8Wj/N49Ej JLkQFHwEg+zu29ktmLcMi/yEw0j6DjYTMy7oVLlHfsJ4uWjv228sj7IiRZrW0loYdEnZ uZcw== X-Gm-Message-State: ALQs6tAz6iiPEZ8nMqwBo79vWfxdIwi7FGowg9nZnrf700/fmyirRFg0 hk567BBhfEb+dA4Ido6GTuke9bRpLuLqspoIjHY= X-Google-Smtp-Source: AIpwx498fuqfl7e1esyuzUOoF7BN2OGDe8BDY1CMgyB+5Jok/Taum9rDl6S7am1PmPi1qRA1LeLp0J8KJhvIsMyHeS8= X-Received: by 10.159.55.46 with SMTP id z43mr8248196uad.117.1523905623842; Mon, 16 Apr 2018 12:07:03 -0700 (PDT) MIME-Version: 1.0 References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> In-Reply-To: From: Jonathan Hoyland Date: Mon, 16 Apr 2018 19:06:53 +0000 Message-ID: To: Richard Barnes Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="001a1145c8566165b60569fbedac" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:07:08 -0000 --001a1145c8566165b60569fbedac Content-Type: text/plain; charset="UTF-8" You are, but it's not mentioned in the security section. As it's a security consideration that you don't get in vanilla TLS I feel that it should be mentioned. Regards, Jonathan On Mon, 16 Apr 2018 at 20:01 Richard Barnes wrote: > That's correct, however if I have a guess of the password can I not just >> try and connect using that password? >> If my guess is correct then the connection will succeed, whereas if my >> guess is incorrect then the connection will fail. >> > > Sure, but aren't you going to have that with any password-authenticated > protocol? > > --Richard > > > >> I'm assuming here that the salt is public, because salts in general do >> not have confidentiality guarantees (otherwise they stretch the metaphor >> and become pepper). >> (I also assume that the client identity can be derived from observing a >> previous session, and that the server identity can be identified through >> probing.) >> >> Regards, >> >> Jonathan >> >> >> >> On Mon, 16 Apr 2018 at 19:43 Richard Barnes wrote: >> >>> Hey Jonathan, >>> >>> Thanks for the comments. I've implemented them in my working copy of >>> the draft, and in my implementation in mint. I have also changed it over >>> to use SPAKE2+; I agree with Tony that this is necessary to guard against >>> server compromise. >>> >>> >>> https://github.com/bifurcation/tls-pake/commit/a9f097c3bfe43cf50001e1a340c7e2e693850d4b >>> https://github.com/bifurcation/mint/pull/193 >>> >>> With regard to security properties: I don't think it's correct that an >>> active attacker can do online password guessing. Everything that is >>> revealed on the wire is blinded with fresh, per-connection entropy, and >>> thus doesn't reveal anything about the password. >>> >>> --Richard >>> >>> >>> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < >>> jonathan.hoyland@gmail.com> wrote: >>> >>>> Hi Richard, >>>> >>>> A few nits. >>>> >>>> * In the introduction you have the sentence >>>> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet >>>> >>>> seen significant security analysis. >>>> >>>> Iiuc this draft has no connection to MLS, and this is a typo. >>>> >>>> * In the setup you define >>>> >>>> > o A DH group "G" of order "p*h", with "p" a large prime >>>> >>>> and >>>> >>>> > o A password "p" >>>> >>>> >>>> The variable "p" has two different meanings, which is a bit confusing, >>>> especially later on. >>>> >>>> * The document doesn't explicitly state that X and Y need to be >>>> non-zero. >>>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if >>>> the warning was carried through. >>>> >>>> * In terms of security properties, iiuc an active adversary can do >>>> online password guessing attacks, but a passive adversary cannot derive the >>>> password from observing the messages. If that is the case perhaps a warning >>>> about rate-limiting connection attempts is appropriate. >>>> >>>> Regards, >>>> >>>> Jonathan >>>> >>>> On Mon, 16 Apr 2018 at 10:50 Tony Putman wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> I don't think that you can protect against server compromise with >>>>> SPAKE2. The server can store w*N as you suggest, but it also has to store >>>>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and >>>>> w*N from a compromised server can then impersonate a client. >>>>> >>>>> The rest of your comments I agree with (though they are not all >>>>> addressed in the updated draft). >>>>> >>>>> Tony >>>>> >>>>> > From: Richard Barnes [mailto:rlb@ipv.sx] >>>>> > Sent: 13 April 2018 19:50 >>>>> > >>>>> > Hey Tony, >>>>> > >>>>> > Thanks for the comments. Hopefully we can adapt this document to >>>>> tick more boxes for you :) >>>>> > Since I had noticed some other errors in the document (e.g., figures >>>>> not rendering properly), >>>>> > I went ahead and submitted a new version that takes these comments >>>>> into account. >>>>> > >>>>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >>>>> > >>>>> > Some responses inline below. >>>>> >>>>> Dyson Technology Limited, company number 01959090, Tetbury Hill, >>>>> Malmesbury, SN16 0RP, UK. >>>>> This message is intended solely for the addressee and may contain >>>>> confidential information. If you have received this message in error, >>>>> please immediately and permanently delete it, and do not use, copy or >>>>> disclose the information contained in this message or in any attachment. >>>>> Dyson may monitor email traffic data and content for security & >>>>> training. >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>>> >>> --001a1145c8566165b60569fbedac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are, but it's not mentioned in the security sectio= n.
As it's a security consideration= that you don't get in vanilla TLS I feel that it should be mentioned.<= /span>

Regards,

Jonathan


On Mon, 16 Apr 2018 at 20:01 Richard Barnes &= lt;rlb@ipv.sx> wrote:
That's correct, however if I h= ave a guess of the password can I not just try and connect using that passw= ord?
If my guess is correct then the connection will succeed, whe= reas if my guess is incorrect then the connection will fail.=C2=A0

Sure, but aren't you = going to have that with any password-authenticated protocol?

--Richard

<= div>=C2=A0
I'= m assuming here that the salt is public, because salts in general do not ha= ve confidentiality guarantees (otherwise they stretch the metaphor and beco= me pepper).=C2=A0
(I also assume that the client identity can be = derived from observing a previous session, and that the server identity can= be identified through probing.)

Regards,

Jonathan


<= br>
On Mon, 16 Apr 2018 at 19:43= Richard Barnes <rlb@ipv.sx> wrote:
Hey Jonathan,

Thanks = for the comments.=C2=A0 I've implemented them in my working copy of the= draft, and in my implementation in mint.=C2=A0 I have also changed it over= to use SPAKE2+; I agree with Tony that this is necessary to guard against = server compromise.


With regard to security prope= rties: I don't think it's correct that an active attacker can do on= line password guessing.=C2=A0 Everything that is revealed on the wire is bl= inded with fresh, per-connection entropy, and thus doesn't reveal anyth= ing about the password.=C2=A0

--Richard

=
On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Ho= yland <jonathan.hoyland@gmail.com> wrote:
H= i Richard,

A few nits.

* In the introduction you have the sentence
>=C2=A0DISCLAIMER: This is a work-in-progress draft of MLS and= has not yet
   seen significant security analysis.
Iiuc this draft has no connection to MLS, and this is a typo.<= /span>
=
* In the setup you define=C2=A0
> o  A DH group "G" of order "p*h", with =
"p" a large prime
and 
> o  A password "p"

The variable "p&qu= ot; has two different meanings, which is a bit confusing, especially later = on.
 * The document doesn't explicitly state that X and Y need to be non-ze=
ro.=C2=A0=

The requirement is in "I-D.irtf-cfrg-spake2", but it would be=
 nice if the warning was carried through.

* In terms of security properties, iiuc an active adversary can = do online password guessing attacks, but a passive adversary cannot derive = the password from observing the messages. If that is the case perhaps a war= ning about rate-limiting connection attempts is appropriate.=C2=A0

Regard= s,

Jonathan

On Mon, 16 Apr 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> wrote:<= br>
Hi Richard,<= br>
I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-barnes-= tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1145c8566165b60569fbedac-- From nobody Mon Apr 16 12:22:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FCC126D05 for ; Mon, 16 Apr 2018 12:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 stGs_uPdO9wC for ; Mon, 16 Apr 2018 12:22:53 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389BB120725 for ; Mon, 16 Apr 2018 12:22:49 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m22-v6so18682282otf.8 for ; Mon, 16 Apr 2018 12:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/EEZX0+T3tpEfNTskYJBrhdHp4vkru2YyPd8B2Tsl0=; b=lpa/ZAvIS9o60ATEulA0yvRcigBzIYUfxnph95HbI5A3RTFL4x/m+mRFc8F0uaAuwm u5+GWODYaHdaeJ/Dy3o5NV1chzoRbb/VK6zGNADovfuXHxeF7xjs9xMvR7LZpinQ8vDt btF0DFYIB2AgnY1aVSIp/OL8FjoWjDfc+J10luNAKmO5FtZtP0Mo7PZk3rj3/PB4E9Or Ltj8eLffdR5fGwRW2pRubqHudZwvcRDiUT3tYD2rzlYmo7NRZaUAgPAk+bnkQcg7oSiR Sr+Pg8kbLrkXmvRvYfaG5z5QMhBh886gObIUz6ZXfIMBJUD+QouydQKo0dfh4kB+7E24 fcXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y/EEZX0+T3tpEfNTskYJBrhdHp4vkru2YyPd8B2Tsl0=; b=Xo9M3EA9vdUrQy+lCex9jAm98/QfzEHQEn02/QVnFsDLCfnW3xA5rrWWMI0QIcBany cQGfDEwOTNjN5tKBHo1s0yh4++mQHpKB9TkKl4AoQYc1UgleikAYtlpZtDdkhXJXZggt /xkRKUEIba0BfGqGMfvMBFc3PNaN7NEys3Jt5h0iiDRoJ13NaLIJrJp+aRJLXLcmE2/j cwAe8ps7RHtTd/Z0FazQe2+AshlR+AVJDmSZTnXYxFuVbp+Gi6iSW6gO18zppJuPH59J Q/tuJAX5+RbHFf/5z9BR2qOGL9g8NpcIDcdswCzi8sS65hCXMlqWuNhXxkE4y+bc3+bF 4VCQ== X-Gm-Message-State: ALQs6tC5AO7YvwvqcbIzUydiPF8MuVjfQCZZfOzsflpYQ3Yug0/Jw3sj uDGWBlA+xvtIY+CrHRb1TMKP1aNMFsXN1DbfxqCPKQ== X-Google-Smtp-Source: AIpwx48ptavRnCjIJm2FSH1wRHzxa07DPj81QZ5GdTe9HveGkD3ptE7N6sN+Plba/AKKjCL+oBikrjJE8RyKPU8XeDI= X-Received: by 2002:a9d:22e8:: with SMTP id y95-v6mr11910732ota.84.1523906568383; Mon, 16 Apr 2018 12:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 12:22:47 -0700 (PDT) In-Reply-To: References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> From: Richard Barnes Date: Mon, 16 Apr 2018 15:22:47 -0400 Message-ID: To: Jonathan Hoyland Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000ae103e0569fc2551" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:22:56 -0000 --000000000000ae103e0569fc2551 Content-Type: text/plain; charset="UTF-8" Oh, sure. In a similar vein, an attacker can also probe for which identities are known to the server. https://github.com/bifurcation/tls-pake/commit/0e72bd5244e89970fe61e5434ca7df3d769d057c On Mon, Apr 16, 2018 at 3:06 PM, Jonathan Hoyland < jonathan.hoyland@gmail.com> wrote: > You are, but it's not mentioned in the security section. > As it's a security consideration that you don't get in vanilla TLS I feel > that it should be mentioned. > > Regards, > > Jonathan > > > On Mon, 16 Apr 2018 at 20:01 Richard Barnes wrote: > >> That's correct, however if I have a guess of the password can I not just >>> try and connect using that password? >>> If my guess is correct then the connection will succeed, whereas if my >>> guess is incorrect then the connection will fail. >>> >> >> Sure, but aren't you going to have that with any password-authenticated >> protocol? >> >> --Richard >> >> >> >>> I'm assuming here that the salt is public, because salts in general do >>> not have confidentiality guarantees (otherwise they stretch the metaphor >>> and become pepper). >>> (I also assume that the client identity can be derived from observing a >>> previous session, and that the server identity can be identified through >>> probing.) >>> >>> Regards, >>> >>> Jonathan >>> >>> >>> >>> On Mon, 16 Apr 2018 at 19:43 Richard Barnes wrote: >>> >>>> Hey Jonathan, >>>> >>>> Thanks for the comments. I've implemented them in my working copy of >>>> the draft, and in my implementation in mint. I have also changed it over >>>> to use SPAKE2+; I agree with Tony that this is necessary to guard against >>>> server compromise. >>>> >>>> https://github.com/bifurcation/tls-pake/commit/ >>>> a9f097c3bfe43cf50001e1a340c7e2e693850d4b >>>> https://github.com/bifurcation/mint/pull/193 >>>> >>>> With regard to security properties: I don't think it's correct that an >>>> active attacker can do online password guessing. Everything that is >>>> revealed on the wire is blinded with fresh, per-connection entropy, and >>>> thus doesn't reveal anything about the password. >>>> >>>> --Richard >>>> >>>> >>>> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < >>>> jonathan.hoyland@gmail.com> wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> A few nits. >>>>> >>>>> * In the introduction you have the sentence >>>>> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet >>>>> >>>>> seen significant security analysis. >>>>> >>>>> Iiuc this draft has no connection to MLS, and this is a typo. >>>>> >>>>> * In the setup you define >>>>> >>>>> > o A DH group "G" of order "p*h", with "p" a large prime >>>>> >>>>> and >>>>> >>>>> > o A password "p" >>>>> >>>>> >>>>> The variable "p" has two different meanings, which is a bit confusing, >>>>> especially later on. >>>>> >>>>> * The document doesn't explicitly state that X and Y need to be >>>>> non-zero. >>>>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if >>>>> the warning was carried through. >>>>> >>>>> * In terms of security properties, iiuc an active adversary can do >>>>> online password guessing attacks, but a passive adversary cannot derive the >>>>> password from observing the messages. If that is the case perhaps a warning >>>>> about rate-limiting connection attempts is appropriate. >>>>> >>>>> Regards, >>>>> >>>>> Jonathan >>>>> >>>>> On Mon, 16 Apr 2018 at 10:50 Tony Putman >>>>> wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> I don't think that you can protect against server compromise with >>>>>> SPAKE2. The server can store w*N as you suggest, but it also has to store >>>>>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and >>>>>> w*N from a compromised server can then impersonate a client. >>>>>> >>>>>> The rest of your comments I agree with (though they are not all >>>>>> addressed in the updated draft). >>>>>> >>>>>> Tony >>>>>> >>>>>> > From: Richard Barnes [mailto:rlb@ipv.sx] >>>>>> > Sent: 13 April 2018 19:50 >>>>>> > >>>>>> > Hey Tony, >>>>>> > >>>>>> > Thanks for the comments. Hopefully we can adapt this document to >>>>>> tick more boxes for you :) >>>>>> > Since I had noticed some other errors in the document (e.g., >>>>>> figures not rendering properly), >>>>>> > I went ahead and submitted a new version that takes these comments >>>>>> into account. >>>>>> > >>>>>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >>>>>> > >>>>>> > Some responses inline below. >>>>>> >>>>>> Dyson Technology Limited, company number 01959090, Tetbury Hill, >>>>>> Malmesbury, SN16 0RP, UK. >>>>>> This message is intended solely for the addressee and may contain >>>>>> confidential information. If you have received this message in error, >>>>>> please immediately and permanently delete it, and do not use, copy or >>>>>> disclose the information contained in this message or in any attachment. >>>>>> Dyson may monitor email traffic data and content for security & >>>>>> training. >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>> >>>> --000000000000ae103e0569fc2551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, sure.=C2=A0 In a similar vein, an attacker can al= so probe for which identities are known to the server.

On Mon, Apr 16, 2018 a= t 3:06 PM, Jonathan Hoyland <jonathan.hoyland@gmail.com> wrote:
You are, bu= t it's not mentioned in the security section.
As it's a security consideration that you don't get in v= anilla TLS I feel that it should be mentioned.

= Regards,

Jonathan


On Mon, 16 Apr 2018 at 20:01 Rich= ard Barnes <rlb@ipv.sx> wrote:
That's correct, howe= ver if I have a guess of the password can I not just try and connect using = that password?
If my guess is correct then the connection will su= cceed, whereas if my guess is incorrect then the connection will fail.=C2= =A0

Sure, but are= n't you going to have that with any password-authenticated protocol?

--Richard
=

=C2=A0
I'm assuming here that the salt is public, because salts in gener= al do not have confidentiality guarantees (otherwise they stretch the metap= hor and become pepper).=C2=A0
(I also assume that the client iden= tity can be derived from observing a previous session, and that the server = identity can be identified through probing.)

Regar= ds,

Jonathan



On Mon, 16 Apr 2018 at 19:43 Richard Barnes <= ;rlb@ipv.sx> wrote:
Hey Jonathan,

Thanks for the comments.= =C2=A0 I've implemented them in my working copy of the draft, and in my= implementation in mint.=C2=A0 I have also changed it over to use SPAKE2+; = I agree with Tony that this is necessary to guard against server compromise= .


With regard to security pr= operties: I don't think it's correct that an active attacker can do= online password guessing.=C2=A0 Everything that is revealed on the wire is= blinded with fresh, per-connection entropy, and thus doesn't reveal an= ything about the password.=C2=A0

=
--Richard


On Mon, Apr 16, 2018 at 7:52 AM, Jonathan= Hoyland <jonathan.hoyland@gmail.com> wrote:
Hi Richard,

A few nits.

=
* In the introduction you have the sentence<= /div>
>=C2=A0DISCLAIMER: This is a work-in-progress draft of MLS = and has not yet
   seen significant security analysis.=
Iiuc this draft has no connection to = MLS, and this is a typo.
* In the setup you define=C2=A0
> o A DH group "G" of order "p*h", with "= p" a large prime
and 
> o  A password &=
quot;p"

The variable "p" has two dif= ferent meanings, which is a bit confusing, especially later on.
* The document doesn't explicitly state that X and Y need to be= non-zero.=C2=A0
The requirement is in "I-D.irtf-cfrg-= spake2", but it would be nice if the warning was carried through.
<= br>
* In terms of security properties, = iiuc an active adversary can do online password guessing attacks, but a pas= sive adversary cannot derive the password from observing the messages. If t= hat is the case perhaps a warning about rate-limiting connection attempts i= s appropriate.=C2=A0

Regards,

Jonathan

On Mon, 16 Apr = 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> wrote:
Hi Richard,
I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-ba= rnes-tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--000000000000ae103e0569fc2551-- From nobody Mon Apr 16 13:21:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6A612704A for ; Mon, 16 Apr 2018 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViSDpDyG8LoO for ; Mon, 16 Apr 2018 13:21:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F82126CE8 for ; Mon, 16 Apr 2018 13:21:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Q0CG75Rxz2kb for ; Mon, 16 Apr 2018 22:21:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523910091; bh=9p334x2IPsfQiv/9kVaq9WRjflPuGU3Wyh5DjiowW6k=; h=Date:From:To:Subject:In-Reply-To:References; b=G9u03kyXTVDsbmcZWLUZpLAzqicFj1Gf15Yifr3CBriNQa4Opev6Q6vi5ODVe6nob 86jbasCd0bFm41nJq5VspjaPGzRYGmH14aLAMmVNmPaE+0hcj/JvIuQMYyw0csasU6 TCLzOoVQhSLyiyhzSjTMi/rZm5b8+WYgdVPqrC9s= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vNaJ8bZ7idKj for ; Mon, 16 Apr 2018 22:21:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 16 Apr 2018 22:21:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 89D8262D29; Mon, 16 Apr 2018 16:21:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 89D8262D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7D69F40D358A for ; Mon, 16 Apr 2018 16:21:27 -0400 (EDT) Date: Mon, 16 Apr 2018 16:21:27 -0400 (EDT) From: Paul Wouters To: TLS WG In-Reply-To: <510EC72B-89A6-4B9A-A937-3331FD144C2B@dukhovni.org> Message-ID: References: <20180416163123.GZ25259@localhost> <510EC72B-89A6-4B9A-A937-3331FD144C2B@dukhovni.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 20:21:36 -0000 On Mon, 16 Apr 2018, Viktor Dukhovni wrote: >> * We might want to say that if the TTL is zero then the clients MUST NOT >> pin and must clear any pin. And we might do this in spite of not >> describing any pinning semantics -- explicitly leaving pinning >> semantics to a future document. > > Exactly. I'd like to suggest that this is the most reasonable > common ground, and would urge the WG and authors to get behind > this as a consensus position. This seems dangerous. If an attacker can re-route and get a rogue cert, they can set TTL to 0, negating a previously set TTL, without requiring proof by presenting the denial-of-existence of the TLSA record. That is also a downgrade attack. How to go from TTL != 0 to TTL == 0 should be specified carefully, either in this document or its own document. The only known save way of going to TTL == 0 is by presenting DoE of TLSA records (but it does bind using the TLS extension to the existence of TLSA records) Paul From nobody Mon Apr 16 13:33:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2ED12EAA5 for ; Mon, 16 Apr 2018 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 eb_g4Qmkao4L for ; Mon, 16 Apr 2018 13:33:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E45126CE8 for ; Mon, 16 Apr 2018 13:33:45 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3D19E7A3309 for ; Mon, 16 Apr 2018 20:33:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 16 Apr 2018 16:33:18 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <9D5599C6-5990-475C-9B20-474418CA1B2D@dukhovni.org> References: <20180416163123.GZ25259@localhost> <510EC72B-89A6-4B9A-A937-3331FD144C2B@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 20:33:47 -0000 > On Apr 16, 2018, at 4:21 PM, Paul Wouters wrote: > > This seems dangerous. If an attacker can re-route and get a rogue > cert, they can set TTL to 0, negating a previously set TTL, without > requiring proof by presenting the denial-of-existence of the TLSA > record. That is also a downgrade attack. > > How to go from TTL != 0 to TTL == 0 should be specified carefully, > either in this document or its own document. I did not spell out all the details, which would belong in the later pinning specification (some of this was described upthread). Once a non-zero pin is in place, a pin TTL of 0 would require a denial of existence proof or a handshake authenticated with extant TLSA RRs. > The only known save way of going to TTL == 0 is by presenting DoE of > TLSA records (but it does bind using the TLS extension to the existence > of TLSA records) While some previous TTL has not expired, getting to zero requires either DoE or TLSA-authenticated handshake with TTL == 0. But, if we're compromising on (C'), then this discussion becomes out of scope for the present draft, and will be one of the key design elements of the future downgrade protection ("pinning") draft. -- Viktor. From nobody Mon Apr 16 14:26:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A2D12704A for ; Mon, 16 Apr 2018 14:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwVmqOO7ops9 for ; Mon, 16 Apr 2018 14:26:09 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F2A124234 for ; Mon, 16 Apr 2018 14:26:09 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id CA5CB2004CA12; Mon, 16 Apr 2018 14:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9oHDPZ5rDaubqq BiRw+AqYzQ5js=; b=rU10ERLfINP7hgjM3hsC86UoEfPDqfAoghz3qc8i5GgNpc a4pmx9OTKbXFufvXSNt7zcV6hd/e12aR+h/sMPch49f2QsyGW5Jd+C7yP9EZwI4d xNUrRkZblKvegfngtfmrUGQoz0PpE9t9rQ6IZA+PDxOtQqeszTaAQmxsGRyOo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id 8F9392004CA0E; Mon, 16 Apr 2018 14:26:08 -0700 (PDT) Date: Mon, 16 Apr 2018 16:16:29 -0500 From: Nico Williams To: Paul Wouters Cc: TLS WG Message-ID: <20180416211628.GC25259@localhost> References: <20180416163123.GZ25259@localhost> <510EC72B-89A6-4B9A-A937-3331FD144C2B@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 21:26:11 -0000 On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote: > On Mon, 16 Apr 2018, Viktor Dukhovni wrote: > >>* We might want to say that if the TTL is zero then the clients MUST NOT > >> pin and must clear any pin. And we might do this in spite of not > >> describing any pinning semantics -- explicitly leaving pinning > >> semantics to a future document. > > > >Exactly. I'd like to suggest that this is the most reasonable > >common ground, and would urge the WG and authors to get behind > >this as a consensus position. > > This seems dangerous. If an attacker can re-route and get a rogue > cert, they can set TTL to 0, negating a previously set TTL, without > requiring proof by presenting the denial-of-existence of the TLSA > record. That is also a downgrade attack. The extension would have to be present and contain either the TLSA RRs and chain, OR the denial of existence chain, in order to even to carry any TTL value. Only in the denial of existence case could an impersonator set a TTL value of the impersonator's choice, and in this case the client must treat it as zero in order to avoid a DoS. In the other case, the impersonator could *not* set a TTL of their choice without compromising DNSSEC. > How to go from TTL != 0 to TTL == 0 should be specified carefully, > either in this document or its own document. If the server sends a denial of existence, then the TTL can't be fully trusted, and there is a DoS if the client uses non-zero TTL values. If the server sends TLSA RRs and chain then all TTL values can be trusted and should be used, though we might specify how in a later document. > The only known save way of going to TTL == 0 is by presenting DoE of > TLSA records (but it does bind using the TLS extension to the existence > of TLSA records) The TTL will be coerced zero on DoE, but it can be set to zero in the TLSA case as well. Nico -- From nobody Wed Apr 18 09:25:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99775127735 for ; Wed, 18 Apr 2018 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7TFnnTJ_bU2 for ; Wed, 18 Apr 2018 09:25:36 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C7F1242F7 for ; Wed, 18 Apr 2018 09:25:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F3985300687 for ; Wed, 18 Apr 2018 12:25:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4KV-DBKf1O95 for ; Wed, 18 Apr 2018 12:25:33 -0400 (EDT) Received: from [172.20.3.209] (unknown [65.216.167.67]) by mail.smeinc.net (Postfix) with ESMTPSA id ECA86300558 for ; Wed, 18 Apr 2018 12:25:32 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> Date: Wed, 18 Apr 2018 12:25:33 -0400 To: IETF TLS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 16:25:43 -0000 In London, I was on the agenda to talk about certificate-based = authentication with external pre-shared key (PSK). We ran out of time, = and I did not get to make the presentation. The slides are in the = proceedings; see = https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-ce= rtificate-based-authentication-with-external-psk-00. Please review the document and send comments to the list. I would like the TLS WG to adopt this document. Russ= From nobody Wed Apr 18 11:22:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F974120454 for ; Wed, 18 Apr 2018 11:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM_MtoHgExuv for ; Wed, 18 Apr 2018 11:22:46 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143A91200FC for ; Wed, 18 Apr 2018 11:22:46 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id v2so2760737qkh.10 for ; Wed, 18 Apr 2018 11:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4acwQPnoaz7HuT8jrLDy6Sj7kQTR3NpaIxV949PWioc=; b=tI/UqK6430CXbzzt9u6eOPZsX1qmZbHQ23lATvOT6pwOzbRVU8yuMsWhIdFnnFpOnZ Oym1M5tX5f09diG+Co93afuFucwxIzFjSI8FWFQHlJOKX7c/wwBzAG9VYADlkeVF+3u1 KG2pMgNzjUvRyf44Rb5PkyrxEjVXQebRw3q6gWCU+bogWO/nE3CKXcNYU7CJp//GXvX8 9Xg8iIVOLDnw+5Fqeonj/MQsDMq7MPrT725KkFHGxonrPq+LS4aEe5tAn8DdFIWMJAfI MWzUxo1UjUj9wKjZS3ywkyLE7COffujpyATXSf5S5uDVOzAOeM27xVtZwgbyXPC3zAD2 lnLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4acwQPnoaz7HuT8jrLDy6Sj7kQTR3NpaIxV949PWioc=; b=IUn+mtEAl9s1/tvqMxX/QuDfK6rvLstlFMlZGcoGUZMr4bLD6H6JqBHtZPWcIqUn5X KhTj3OL81vlGO4exd6t1uQ53xbxrSRGhEISj47LuAxu/ZFvwethircJI48X+099oIKNV 16HejPUfg9xOJ3RMwsfMBvhmpaPkx/kJ5sRcZH4ObKBvShSfQzjmwk7CXa/mGDc2kuDa 8yMRO+Ou4wyagIICw/ydXunANFwvxl5Lm3I3j5UMEVlHD2qov0Wu01SekKqQrQOI9ROT pZHH22t8wnNiK1pC1UuEWL/m91W0pkk8p3IOta4jsWD6TFzTQvaAG2dga40bD25VIzoi fC2A== X-Gm-Message-State: ALQs6tDr/OoCS3DgwE6tnsqhrTsOs8b0WHfBjeZqWmP0RM76/VS5uF7b L9sXqUTvFHpgtRojuX0GZA4RfRCF9dVVpFWvajU91QO7 X-Google-Smtp-Source: AB8JxZqOxleyfRrPWniWRcDbVdsS1/HNcT/h1e4G/ulAeONlgcsMPoKtu2FRV1n5mhhyfIDIgj3EG2PSiUOesQTQmiU= X-Received: by 10.55.131.196 with SMTP id f187mr2768973qkd.97.1524075764926; Wed, 18 Apr 2018 11:22:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.24.250 with HTTP; Wed, 18 Apr 2018 11:22:24 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Wed, 18 Apr 2018 11:22:24 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c07019294621c056a238afc" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 18:22:48 -0000 --94eb2c07019294621c056a238afc Content-Type: text/plain; charset="UTF-8" We've had a lot of discussion on this thread that has pointed out that there are enough issues with the current document that we should recommend that the AD pull it back from the RFC editor. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: 1. Scope the document to the assertive use cases 2. Explicitly allow (but do not require) DoE be included 3. Remove current text about pinning 4. Re-submit the document for publication and start work on a separate extension that supports pinning I understand that not everyone is happy with publishing the document scoped down in this way, but there is a community of users who would find it useful. I am soliciting suggestions for text for the 1-3 and I encourage proponents of the more restrictive use case to get a draft together that we can consider for adoption by the working group. I also want to thank the participants for keeping the discussion mostly civil and having patience as we go through this process. Joe On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both > > This call will be open until April 18, 2018. > > Thanks, > > Joe > > > --94eb2c07019294621c056a238afc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've had a lot of discussion on this thread that has = pointed out that there are enough issues with the current document that we = should recommend that the AD pull it back from the RFC editor.=C2=A0=C2=A0<= /div>

Concerns have been raised about the trade-offs associated wi= th pinning and I do not think we currently have consensus to add pinning.= =C2=A0 While I think it may be possible to come to consensus on pinning I t= hink it may take some time.=C2=A0 I believe we can quickly get consensus fo= r the following approach:

1. Scope the document to the assertive use cases
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial"><= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal= ;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex= t-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:= initial;text-decoration-color:initial">2. Explicitly allow (but do not requ= ire) DoE be included
3. Remove= current text about pinning
4.= Re-submit the document for publication and start work on a separate extens= ion that supports pinning

=
I understand that not everyone is happy with publishing = the document scoped down in this way, but there is a community of users who= would find it useful.=C2=A0 I am soliciting suggestions for text for the 1= -3 and I encourage proponents of the more restrictive use case to get a dra= ft together that we can consider for adoption by the working group.
I also want to thank the participants for keeping the discussion mo= stly civil and having patience as we go through this process.=C2=A0=C2=A0
Joe


On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey <joe@salowey.net> wrote:
Hi F= olks,

Some objections were raised late during the rev= iew of the=C2=A0draft-ietf-tls-dnssec-chain-extension. The question be= fore the working group is either to publish the document as is or to bring = the document back into the working group to address the following issues:

-=C2=A0Recommendation of adding de= nial of existence proofs in the chain provided by the extension
- Adding signaling to require the use of this e= xtension for a period of time (Pinning with TTL)

This is a consensu= s call on how to progress this document.=C2=A0 Please answer the following = questions:

<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;text-decoration-style= :initial;text-decoration-color:initial;background-color:rgb(255,255,255)"><= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12= .8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb= (255,255,255);text-decoration-style:initial;text-decoration-color:initial;f= loat:none;display:inline">1) Do you support publication of the document as = is,=C2=A0leaving these two issues t= o potentially be addressed in=C2=A0follow= -up work?

If = the answer to 1) is no then please indicate if you think the working group = should work on the document to include=C2=A0

A)=C2=A0Rec= ommendation of adding denial of existence proofs in the chain provided by t= he extension
B) Adding signaling to require the use of this extension f= or a period of time (Pinning with TTL)
C) Both

This call will be open until April 18, 2018.

Thanks= ,

Joe



--94eb2c07019294621c056a238afc-- From nobody Wed Apr 18 12:23:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E241126C26 for ; Wed, 18 Apr 2018 12:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 ATMx8tykEQjE for ; Wed, 18 Apr 2018 12:23:04 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D85126CC7 for ; Wed, 18 Apr 2018 12:23:04 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id 126-v6so2650939oig.0 for ; Wed, 18 Apr 2018 12:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ZVMXmRgL3IjprEor8CI0k4B2DYolx9XxwM9XTcqUGc=; b=Hc1FlAydxdnfrAwxC6Lv9ZPchpv0dTPOOu+64/ssEXdbFBcNEUyBEcLmq3TqZB3YxL tWsKlQaPhwBNoKRaUeENkN9d6tBXgAW8wW39NiPsEK6ZsWpte4XZI1G1mhoiFfYTz6I7 3YxuwxlnVrci7PXyuZfLb+DNYEvBIlysDPm5Br4fKIiaqDijbVmPZEyLGXcR8Zso65qp AzkVdOzxSAEEG5MGXP89CXooLB2yqbJQBNCEkgpXM6/3vMplSkkdWwzSgjJuZMsjob4v B1RqL62INJlY1adXMPSbhY1I3gPLnUuc7lbCyZ5IJcimY3S7MQjrhG/DJe+f755f8I3/ lt5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ZVMXmRgL3IjprEor8CI0k4B2DYolx9XxwM9XTcqUGc=; b=VzFVOIIfaQMsr+05nmkMRlmNBop/1XEExR/21IM3E+vFU4TNm/MF1oDVsu8cMsKph4 bFJiwd+VoIL9EMODUUUq1UlsBAvJH5GbVcXL1KyAw3p5I0yBJQ9wD/11OtmM0lCloFrA fP9Yn1iyjR4FB5vpRMuMi/ljRYdMModYWVi7E+NDvpOwDUoq8fJbBvbIjvfROorZUGQt GLuWnIZeVz1LuOaT3tmRAnJcvyFiQqxPRJP3YEMgqdT7hdMstPuQq72w1RYaxtW9q8mj c1+4Xqs8LV5nQYFw6DVK4bivX2eIOupbjiashj5rDXvYiN3J1NHvtsi8v6/Dv7jcne20 8SOw== X-Gm-Message-State: ALQs6tDWqnYezvF2Bz3AsoKRITqcf/c4NKunVw2zfolySIaTYDamTIsr Y2jc2ttMqAOgoZPm3Mb4gfs8pLwGwM0cWIaPusFxQg== X-Google-Smtp-Source: AIpwx49ylyPCtfy0HvFAO+CxAWNtbFSmkelVXWE93gDSywfZ4/gkWjVgJl5T3FHlDNLv4gFmfTnH4Yz6nseC2LRoeNo= X-Received: by 2002:aca:b985:: with SMTP id j127-v6mr1870336oif.6.1524079383600; Wed, 18 Apr 2018 12:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 12:23:02 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 18 Apr 2018 15:23:02 -0400 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="00000000000044f46e056a24624c" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 19:23:13 -0000 --00000000000044f46e056a24624c Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > We've had a lot of discussion on this thread that has pointed out that > there are enough issues with the current document that we should recommend > that the AD pull it back from the RFC editor. > > Concerns have been raised about the trade-offs associated with pinning and > I do not think we currently have consensus to add pinning. While I think > it may be possible to come to consensus on pinning I think it may take some > time. I believe we can quickly get consensus for the following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate > extension that supports pinning > SGTM > > I understand that not everyone is happy with publishing the document > scoped down in this way, but there is a community of users who would find > it useful. I am soliciting suggestions for text for the 1-3 and I > encourage proponents of the more restrictive use case to get a draft > together that we can consider for adoption by the working group. > > I also want to thank the participants for keeping the discussion mostly > civil and having patience as we go through this process. > > Joe > > > On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey wrote: > >> Hi Folks, >> >> Some objections were raised late during the review of >> the draft-ietf-tls-dnssec-chain-extension. The question before the >> working group is either to publish the document as is or to bring the >> document back into the working group to address the following issues: >> >> - Recommendation of adding denial of existence proofs in the chain >> provided by the extension >> - Adding signaling to require the use of this extension for a period of >> time (Pinning with TTL) >> >> This is a consensus call on how to progress this document. Please answer >> the following questions: >> >> 1) Do you support publication of the document as is, leaving these two >> issues to potentially be addressed in follow-up work? >> >> If the answer to 1) is no then please indicate if you think the working >> group should work on the document to include >> >> A) Recommendation of adding denial of existence proofs in the chain >> provided by the extension >> B) Adding signaling to require the use of this extension for a period of >> time (Pinning with TTL) >> C) Both >> >> This call will be open until April 18, 2018. >> >> Thanks, >> >> Joe >> >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --00000000000044f46e056a24624c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey <<= a href=3D"mailto:joe@salowey.net" target=3D"_blank">joe@salowey.net>= wrote:
We've= had a lot of discussion on this thread that has pointed out that there are= enough issues with the current document that we should recommend that the = AD pull it back from the RFC editor.=C2=A0=C2=A0

Concerns h= ave been raised about the trade-offs associated with pinning and I do not t= hink we currently have consensus to add pinning.=C2=A0 While I think it may= be possible to come to consensus on pinning I think it may take some time.= =C2=A0 I believe we can quickly get consensus for the following approach:

1. Scope the document to the assertive use cases
2. Explicitly allow (but do not require) D= oE be included
3. Remove curre= nt text about pinning
4. Re-su= bmit the document for publication and start work on a separate extension th= at supports pinning

SGTM

=C2=A0

I understand that not everyone is happy with publishing the = document scoped down in this way, but there is a community of users who wou= ld find it useful.=C2=A0 I am soliciting suggestions for text for the 1-3 a= nd I encourage proponents of the more restrictive use case to get a draft t= ogether that we can consider for adoption by the working group.

I also want to thank the participants for keeping the discussion mostly= civil and having patience as we go through this process.=C2=A0=C2=A0
=
Joe


On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey <= ;joe@salowey.net&g= t; wrote:
Hi Folks,

Some objections were raised la= te during the review of the=C2=A0draft-ietf-tls-dnssec-chain-extension= . The question before the working group is either to publish the document a= s is or to bring the document back into the working group to address the fo= llowing issues:

-=C2=A0Recommenda= tion of adding denial of existence proofs in the chain provided by the exte= nsion
- Adding signaling to require = the use of this extension for a period of time (Pinning with TTL)

T= his is a consensus call on how to progress this document.=C2=A0 Please answ= er the following questions:

1) Do you support publication of the document as is,<= span>=C2=A0leaving these two issues to po= tentially be addressed in=C2=A0follow-up = work?

If the answer to 1) is no then please indicate if you think t= he working group should work on the document to include=C2=A0
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial"><= span style=3D"font-size:12.8px">
A)=C2=A0Recommendation of adding denial of existence proofs in the = chain provided by the extension
B) Adding signaling to require the use = of this extension for a period of time (Pinning with TTL)
C) Bo= th

This call will be open until April 18, 2018.<= /div>

Thanks,

Joe




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


--00000000000044f46e056a24624c-- From nobody Wed Apr 18 13:20:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5512D94C for ; Wed, 18 Apr 2018 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geoY6ZG3sBHR for ; Wed, 18 Apr 2018 13:20:32 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87934126DFB for ; Wed, 18 Apr 2018 13:20:25 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id g14so1457087pfh.3 for ; Wed, 18 Apr 2018 13:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=seODA0dYY2WKBUMJ4jlZCHLsR1zo8gn0+NHKTmxlq/M=; b=sECVFElKcG4rBF9pPVJFqkkinbIxDFCovjBvp6PX5BQ256iXA1hLyh+whGjtmtVdW/ kKG/7GCb32iICS4+aqxIiGcKzAwMVDQAfcG2nn076HkbnADOiTYJNcHIbnKOVgOFu//w iPNwYCvMd+cUG2sgxaWFEJlg0tMrQast6YoOpIVD2FyU86OFwatEHQrJF+RkRYUu9pFY dXEvANNMSTTj4H/UZEjdYVfa3P7CJyr3SPhqDD5NWeX7xfTCPVESz/nomxa1b2p9Q9JK TsfsvjcPJjbbl/4l7FZAJqcpYpzKxOOvgEfX4/L5J9liEozPCyW9KVTCbCDqmU8rc4yR 30mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=seODA0dYY2WKBUMJ4jlZCHLsR1zo8gn0+NHKTmxlq/M=; b=G1ys7P/M8+ZmGf6VwPEmcZbBJvN2svcHzauRp36oHRPhY8Xv31aVetSYlBSSpgb41/ HHhS4r9rs4/sVqiSbzXu3pxnkGm2G9U12oV/QFe2xZPFcJ7NfB5LOTQ/cpBwFH7JUPYX aTwp2684JEKAcVdQf8X5oHRUfPs1ow+yhyFSYmPKq1bnnRrGVRNomUgZUit48y67tt6j FUNCO23TVXKrZAGNcMXUcKNLfiRvDPmxsl8HLfgwpK7a6Zl3/EiAB22CeWOgMVnF/Y2v g8jO6PgZwcNg/2fLdSQQrYhJNwCtN2S2DMqQHcMCUqKYBj85TAkwLzr1Za+qoE23j/Rd zgeQ== X-Gm-Message-State: ALQs6tD7kRSF0lcJeHsrUzAb697fSba4lQQXaXIgBy75LDCFv9GNcOU2 trhXxjFhWU5Sr/+j6mOdy60TjYk= X-Google-Smtp-Source: AIpwx4+mBDJMBg5msMSPIBAHRh19lvsQPyVIFVeCQrf9MbBfM31fhfdcNJmm67hhQ6sqaQsWpSwsJQ== X-Received: by 10.99.121.76 with SMTP id u73mr2827805pgc.380.1524082824781; Wed, 18 Apr 2018 13:20:24 -0700 (PDT) Received: from aspen.local (216-67-115-161-radius.dynamic.acsalaska.net. [216.67.115.161]) by smtp.gmail.com with ESMTPSA id k72sm1454196pgc.28.2018.04.18.13.20.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 13:20:23 -0700 (PDT) To: tls@ietf.org References: From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PsLBlwQTAQoAQQIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaWd0AhkB AAoJEN+4kXKadtuPmvIQAJvVNnT0qhltq35AQ9Z1Ipx1IkEcQ8+yyMNLgyV9ZYhn9wn9JS/C TSb7HDSyTRiIz8CnaiCIOn2ZpT3sgYFw3cijT6YfRiifCeu4z3ea+XXOA/VyqXo42ARWOvq3 XdY3uj/j1c39PvhbopUwhulHzFJL7cMJCLEws588HdLwT8GVe+aTFPP4buJRqpOM0kSr/gkN 1IYKI0x1w6NgsgrYjCnv/VUwThjcVWPwMvZStvBnGquE6tvEmlnY+5cRktKSFw4X1ijxKzJD m0iqg7P7gNjC0r5uR2fF6BC0OPo9txPnabYph1wZ7V/5gnDwtWimD0ER77EO5Mr3zZHzva5v EwDpEbKXI43XAfpbxz3uc2fmXE2cvOCFgY/fTpX4kjVaxyFvjf1zrsac/7qFzwvgotYrYSc+ E1Ts+n1hWwsDA+qw/9reE1z9w+sn7SKL7zlS9sV54rfcd1AT0aMwlhAkEOaXRutriQ9BWWOv TOZBtRuV5RO/ZieY7lLX2+na2LjxLyak9k6wYwQwKvzvovBrr8zwDfJQDQujdVhk/lrlngAw Qh/U9dOg2hTUNiFHbKe1N+4vNCW/aLqm33LEV/vK/KepGsTl1ezQotOr0d05h2QySsdAgLCX Gv7bb+wTl/8Yx8hZfZO68KoRk8Zy4Yz8kE5LWJir+QQC7m7oo/4wZZcIzsFNBFppZ0gBEACg ZuM18ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1 YZ0OpQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR3 5FAgSnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fE ZHM66phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQ V0yBgc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4 cztvgmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRH RvQs0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBj Ltx1tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI 7qDHFxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnY jMJodU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABwsF8BBgBCgAmFiEET2gtkyoXlvgg8jTA 37iRcpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ7 5iY5pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiF PjkrQIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/J YK75BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApM LL0R/qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV 5abZ+iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJR i+cH7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7 Vz9F+6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloS bbMvP9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjx uLzdLY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+3 1fk1HKwqd9xRxC8= Message-ID: <4dfbb5f1-926f-1ac6-5c0a-974ba6d18431@nomountain.net> Date: Wed, 18 Apr 2018 12:20:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q3wu2vzLD2yULRwvEuzcAFQcwnjKsLglN" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:20:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q3wu2vzLD2yULRwvEuzcAFQcwnjKsLglN Content-Type: multipart/mixed; boundary="xq4HA15VFZa95k3KQwq5zeqzodzZ6Tl3R"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: <4dfbb5f1-926f-1ac6-5c0a-974ba6d18431@nomountain.net> Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension References: In-Reply-To: --xq4HA15VFZa95k3KQwq5zeqzodzZ6Tl3R Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/18/18 10:22 AM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning > and I do not think we currently have consensus to add pinning.=C2=A0 Wh= ile I > think it may be possible to come to consensus on pinning I think it may= > take some time.=C2=A0 I believe we can quickly get consensus for the > following approach: >=20 > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate > extension that supports pinning This sounds reasonable. I'll talk with co-editors about text changes. Melinda --=20 Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --xq4HA15VFZa95k3KQwq5zeqzodzZ6Tl3R-- --q3wu2vzLD2yULRwvEuzcAFQcwnjKsLglN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAlrXqIUACgkQ37iRcpp2 24/1Nw/9G9QUqSKT9QX3/84bTYx1Mw5vl3Z/413dRUAEcs0+NKsPiU23HQXPutck 7afD9A6c3lpiK4PJeD/a2+J0CO2Dp9iWhRP5JFobKIQD5giEljZn0Bj9hazUA7iT 7GkRMJKk0iyK81pdbx4A8r13+60zkg1+tCX4fDF/Rjpe3NBrk22mYmNeTh7HauUy MOsjSvO499CmrIikN0xM39RuDiirKV4LutbSArYBCipC2rS7AEF/p2Nhu37QHt+g pa15NcpoyVE9br+bB8TA/n3HLXVeLdo2STLgLTxplm0wyKuwNrnITJIYAjPqV1n+ 9vgE5nHVsExMjesSbs7L1hPvZ3OV71wSSmmqDxgVzRE90kO+LGdQqaFKHyn8jg8V BBI8mweLpMF9VCrcWeyV3zCWHYMmznMhU2wNLiRj1AK1jPiSL7AYF0evufhb+Quk vb1QHf9tLg2n0j9pKUEgeLGrwndUUedyXRmO2Ar2Lpxd0pvGVngD3/vU3kr/GiSg hNbco/6ul6abHPPr6wzKzGuF2SiTEkVCALhMJii3PbHZ/szgJAQZUsaHpTOakxK+ wAMmeOcfoviPnklsuDCkJCmwizHkmyXZkxEGEx+EcqsEyW5aqrjBlGiVvMj9SR9j R0eadq5qxzNX3NDNQnd0jRN/GvAcA/0pKLMbyWR3xsrgJLH3EQY= =Oge8 -----END PGP SIGNATURE----- --q3wu2vzLD2yULRwvEuzcAFQcwnjKsLglN-- From nobody Wed Apr 18 13:42:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5496127876 for ; Wed, 18 Apr 2018 13:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-4G-AX7KJUt for ; Wed, 18 Apr 2018 13:42:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695291241F5 for ; Wed, 18 Apr 2018 13:42:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40RDZr6fXKz39h; Wed, 18 Apr 2018 22:42:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524084164; bh=8TqLutCcxtJUnlRGFHMJEKA7tB5pV1EihbvXCyWATM4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=METRIS6MeFAocHMBAKkehSVQWP1kaXv3e/BWekP+GTVQ4p7G0Elm3josNNOay+LvB e6caO+V5SYtECwOKZ858drEWFH74FvhAeS5BsO42uzhUR/tRd8GmVtGiTjoTR6CgA1 7/q8ZjH2QCcjkZP9ixrTfZBMb25KhWQCVBZsRJEI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vRYEswfZWl9r; Wed, 18 Apr 2018 22:42:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 18 Apr 2018 22:42:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 856A233AA19; Wed, 18 Apr 2018 16:42:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 856A233AA19 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7B58E411635E; Wed, 18 Apr 2018 16:42:42 -0400 (EDT) Date: Wed, 18 Apr 2018 16:42:42 -0400 (EDT) From: Paul Wouters To: Joseph Salowey cc: "" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:42:50 -0000 On Wed, 18 Apr 2018, Joseph Salowey wrote: This is a combined response of Viktor, Nico and Paul. > Concerns have been raised about the trade-offs associated with pinning and I > do not think we currently have consensus to add > pinning.  While I think it may be possible to come to consensus on pinning I > think it may take some time.  I believe we can > quickly get consensus for the following approach: A slight correction here. The call that there is no consensus on pinning is not entirely correct. The discussion showed a majority of people in favour of some kind of pinning, but with most people being agreeable that this can be in its own document and not hold up this document further. A pinning document is inevitably coming. > 1. Scope the document to the assertive use cases This means actually leaving out what some of us think are the most important use case - an alternative for webpki. While we are okay to reduce the scope of this document, it seems logical that such decision comes with some guarantees to allow the other use cases. Which gets us back to a new document about pinning (see below) > 2. Explicitly allow (but do not require) DoE be included The document does not currently allow the extension to be empty. So if there is no TLSA record and the extension would be present, it therefore can only contain a DoE chain. So what do you mean with item 2? Possibly you mean to say "if there is no TLSA record, the extension can be omited or the extension can be included with a DoE chain" ? That would be okay with us. > 3. Remove current text about pinning That is fine, but one caveat below. > 4. Re-submit the document for publication and start work on a separate > extension that supports pinning While we agree we can move pinning to a separate document, it makes much less sense for this to become an additional fully independent TLS extension, especially since the pinning will depend on DNSSEC properties only delivered by the TLS-DNSSEC extension. So as we suggested before, the best solution therefore would be to define this two byte pin in the current document, and be defined as "ignore completely unless you implement this other RFC". That is, The proposed 16-byte "extension support lifetime" field will: * Have 0 as the only value defined in the present draft * Servers that implement only the present draft SHALL send 0. * Clients that implement only the present draft SHALL treat any value received as though it were 0. * A zero "extension support lifetime" field prohibits the client from unilaterally mandating the extension based on prior observation of its presence (pinning). This a win-win for both opponents and proponents of pinning. And not only that, it will allow us to put the pinning inside the extension it relates to. Additionally, with no pin set to 0 in the current document, and no mentioning of pinning since the consensus agrees to remove it that, client implementations will not be told to not pin, and will start doing something like TOFU like pinning. It would actually be better to specify this zero pin to prevent this from happening. If you take it as a given that we will write this document, then it only makes logical sense to already reserve these two bytes in the current document, even it if states "must be 0". Our document will Update: this document to describe the pinning in detail. Nico, Paul and Viktor From nobody Wed Apr 18 13:47:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2746A1241F5 for ; Wed, 18 Apr 2018 13:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 b7yxIkLskvDw for ; Wed, 18 Apr 2018 13:47:27 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B30127876 for ; Wed, 18 Apr 2018 13:47:27 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x9-v6so2859337oig.7 for ; Wed, 18 Apr 2018 13:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aotlusnJsB+xTco0RhmhLYp+I2ZOROVrZK7LQVIwMWE=; b=P+fSCnc0bmEW/wimtwYvkVGYsgIjf5vS6ejmti337fbnyZCbeL5rbZYbXJz6S6fZFx tCHBRTt/UeBBwEolWjkVsZlDzWNQWI3lmO56GRF+t5504jle1Pk+ztu3HSIv0FS8BfO/ mqPeOfl0HyAeX1ipHpaSLNGELiARjAuKrO9BymlWFHkCTSFk1naSk+scuwT9T0J5B75W BrvQZ3yqNRMWILmzVHV8fb62j8HCqDqbV2SLN4e/TVo27UjFOhv394UDCcRCEQCqfppx 1SipVf1m4UROIdbFAnfXu4ZaG2KrlHFG3XibRKJ1YFbbXacynxpWTrzyqcdfKvITQDZd 6tiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aotlusnJsB+xTco0RhmhLYp+I2ZOROVrZK7LQVIwMWE=; b=CHr+pJ5l6H6eZt/qX4lEfFdkE/2eaS0+XC/Cdntat0cKUSCNk0gWeVTdtMyc3PyXsA 65uSrKLVg1zbUaa9bpSodVD9m8JciR9tQ0bY3i7aWKi0Pn6xE53mqKdjf8XzDJDgDbYA iVreLGfwhUIUvdrQpx/g0ZIoMumFbOQ8BN5a9betPCVhzKwbqYvGoXs8wnttNnBnzlHw YX2nxWknoaWWvkyzNBmy9wuHednBl0IX1y3x+WoGj//sJe3uF98nrOWU4UiMzSsr4pBo VSz6vXlGmgpmeeHB5UQYuXhKytvBxVdxUxWX0ukYLlmQt6dw2OfxlaVKQ4tr0Klig/bS 2Byw== X-Gm-Message-State: ALQs6tCKUM1vejkxin/Xr5lyPvgQyeaWYulRbMt2fPM7TGFzqR5NUaRw icQhbkND73q74SI6+r0H9YwGPwbgZ/tRbmnSPmIvRbtg X-Google-Smtp-Source: AIpwx48RnQScJeRb5PpoJz6ks7Sv3iY0BsZvsCpFUBIUTuxQnlnK0moO7MVnSnLDOChWJ2k1M0mfofYrahhUoRTwB8k= X-Received: by 2002:aca:b985:: with SMTP id j127-v6mr2017049oif.6.1524084446336; Wed, 18 Apr 2018 13:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 13:47:25 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 18 Apr 2018 16:47:25 -0400 Message-ID: To: Paul Wouters Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="000000000000082b56056a2590b4" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:47:30 -0000 --000000000000082b56056a2590b4 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote: > On Wed, 18 Apr 2018, Joseph Salowey wrote: > > This is a combined response of Viktor, Nico and Paul. > > Concerns have been raised about the trade-offs associated with pinning >> and I >> do not think we currently have consensus to add >> pinning. While I think it may be possible to come to consensus on >> pinning I >> think it may take some time. I believe we can >> quickly get consensus for the following approach: >> > > A slight correction here. The call that there is no consensus on pinning > is not entirely correct. The discussion showed a majority of people in > favour of some kind of pinning, but with most people being agreeable that > this can be in its own document and not hold up this document further. A > pinning document is inevitably coming. > > 1. Scope the document to the assertive use cases >> > > This means actually leaving out what some of us think are the most > important use case - an alternative for webpki. A down-scoped document can perfectly well be used as an alternative to the Web PKI. As noted before, clients can offer what they support, and servers can switch. > While we are okay > to reduce the scope of this document, it seems logical that such > decision comes with some guarantees to allow the other use cases. > Which gets us back to a new document about pinning (see below) > > 2. Explicitly allow (but do not require) DoE be included >> > > The document does not currently allow the extension to be empty. So if > there is no TLSA record and the extension would be present, it therefore > can only contain a DoE chain. So what do you mean with item 2? Possibly > you mean to say "if there is no TLSA record, the extension can be omited > or the extension can be included with a DoE chain" ? That would be okay > with us. > > 3. Remove current text about pinning >> > > That is fine, but one caveat below. > > 4. Re-submit the document for publication and start work on a separate >> extension that supports pinning >> > > While we agree we can move pinning to a separate document, it makes much > less sense for this to become an additional fully independent TLS > extension, especially since the pinning will depend on DNSSEC properties > only delivered by the TLS-DNSSEC extension. So as we suggested before, the > best solution therefore would be to define this two byte pin in the > current document, and be defined as "ignore completely unless you > implement this other RFC". That is, > > The proposed 16-byte "extension support lifetime" field will: > > * Have 0 as the only value defined in the present draft > * Servers that implement only the present draft SHALL send 0. > * Clients that implement only the present draft SHALL treat > any value received as though it were 0. > * A zero "extension support lifetime" field prohibits the > client from unilaterally mandating the extension based > on prior observation of its presence (pinning). > > This a win-win for both opponents and proponents of pinning. And not > only that, it will allow us to put the pinning inside the extension > it relates to. > I do not support adding a field to the protocol with semantics to be defined later. Especially a 16-byte field, which is a fair bit of cruft to carry around. This seems perfectly suitable for a separate extension. --Richard > Additionally, with no pin set to 0 in the current document, and no > mentioning of pinning since the consensus agrees to remove it that, > client implementations will not be told to not pin, and will start doing > something like TOFU like pinning. It would actually be better to specify > this zero pin to prevent this from happening. > > If you take it as a given that we will write this document, then it only > makes logical sense to already reserve these two bytes in the current > document, even it if states "must be 0". Our document will Update: > this document to describe the pinning in detail. > > Nico, Paul and Viktor > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000082b56056a2590b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 18 Apr 2018, Joseph Sa= lowey wrote:

This is a combined response of Viktor, Nico and Paul.

=C2=A0Concerns have been raised about the trade-offs associated with pinnin= g and I
=C2=A0do not think we currently have consensus to add
=C2=A0pinning.=C2=A0 While I think it may be possible to come to consensus = on pinning I
=C2=A0think it may take some time.=C2=A0 I believe we can
=C2=A0quickly get consensus for the following approach:

 A slight correction here. The call that there is no consensus on pinning is not entirely correct. The discussion showed a majority of people in
favour of some kind of pinning, but with most people being agreeable that this can be in its own document and not hold up this document further. A pinning document is inevitably coming.

=C2=A01. Scope the document to the assertive use cases

 This means actually leaving out what some of us think are the most
important use case - an alternative for webpki.

A down-scoped document can perfectly well be used as an alternative t= o the Web PKI.=C2=A0 As noted before, clients can offer what they support, = and servers can switch.
=C2=A0
While we are okay
to reduce the scope of this document, it seems logical that such
decision comes with some guarantees to allow the other use cases.
Which gets us back to a new document about pinning (see below)

=C2=A02. Explicitly allow (but do not require) DoE be included

 The document does not currently allow the extension to be empty. So if
there is no TLSA record and the extension would be present, it therefore can only contain a DoE chain. So what do you mean with item 2? Possibly
you mean to say "if there is no TLSA record, the extension can be omit= ed
or the extension can be included with a DoE chain" ? That would be oka= y
with us.

=C2=A03. Remove current text about pinning

 That is fine, but one caveat below.

=C2=A04. Re-submit the document for publication and start work on a separat= e
=C2=A0extension that supports pinning

 While we agree we can move pinning to a separate document, it makes much less sense for this to become an additional fully independent TLS
extension, especially since the pinning will depend on DNSSEC properties only delivered by the TLS-DNSSEC extension. So as we suggested before, the<= br> best solution therefore would be to define this two byte pin in the
current document, and be defined as "ignore completely unless you
implement this other RFC". That is,

=C2=A0 =C2=A0 =C2=A0The proposed 16-byte "extension support lifetime&q= uot; field will:

=C2=A0 =C2=A0 =C2=A0 =C2=A0* Have 0 as the only value defined in the presen= t draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0* Servers that implement only the present draft = SHALL send 0.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* Clients that implement only the present draft = SHALL treat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any value received as though it were 0. =C2=A0 =C2=A0 =C2=A0 =C2=A0* A zero "extension support lifetime" = field prohibits the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client from unilaterally mandating the ex= tension based
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on prior observation of its presence (pin= ning).

This a win-win for both opponents and proponents of pinning. And not
only that, it will allow us to put the pinning inside the extension
it relates to.

I do not support adding = a field to the protocol with semantics to be defined later.=C2=A0 Especiall= y a 16-byte field, which is a fair bit of cruft to carry around.
=
This seems perfectly suitable for a separate extension.=C2= =A0

--Richard

=C2=A0=
Additionally, with no pin set to 0 in the current document, and no
mentioning of pinning since the consensus agrees to remove it that,
client implementations will not be told to not pin, and will start doing something like TOFU like pinning. It would actually be better to specify this zero pin to prevent this from happening.

If you take it as a given that we will write this document, then it only makes logical sense to already reserve these two bytes in the current
document, even it if states "must be 0". Our document will Update= :
this document to describe the pinning in detail.

Nico, Paul and Viktor


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

--000000000000082b56056a2590b4-- From nobody Wed Apr 18 13:48:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88D3127201 for ; Wed, 18 Apr 2018 13:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xnusmlzYxr_1 for ; Wed, 18 Apr 2018 13:48:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFFE126C3D for ; Wed, 18 Apr 2018 13:48:49 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 758237A3309 for ; Wed, 18 Apr 2018 20:48:48 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 18 Apr 2018 16:48:47 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:48:51 -0000 > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: >=20 > I do not support adding a field to the protocol with semantics to be = defined later. Especially a 16-byte field, which is a fair bit of cruft = to carry around. The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. --=20 Viktor. From nobody Wed Apr 18 13:52:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE4127201 for ; Wed, 18 Apr 2018 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 uSvcTUgXuq9W for ; Wed, 18 Apr 2018 13:52:15 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC47126DFB for ; Wed, 18 Apr 2018 13:52:15 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id h55-v6so3465773ote.9 for ; Wed, 18 Apr 2018 13:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=njBMz5KfMq0+mGpy28Iy+seiPZsCe8GCoSdhtZlpk88=; b=h4uXhL/dB4nJBYAMUa9RtS/YaoM/yIoLotD3Qwx505GxzspidBnDAGdWY4l75eWuPR cJAPnTUoJxM7RK/xgM2ALd5uG7yvQqDGBa26iL4YFO5d2N5yQFwWAA7AB76+l+7NnviZ QopbbFWsxFpeGEltJrnOtEmjJW61Nqs57eJTQoxJ89S9h5u8VBjS97W7T09I7gtpJezA p4F0iQjADyb4JeCB5pQ2CVOQ1tSEiEBg0msKhGze32ukb94NY5XWg8QjWAwUzZUDvxsQ k4x79g1ZWWpI3DJekunfHA+Z6d9nTD+0+veTIG12e3FFYwN6CxRudnWThP6JG1hfXXsw dWKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=njBMz5KfMq0+mGpy28Iy+seiPZsCe8GCoSdhtZlpk88=; b=TgTl/G0ih/7pWQE9VCcYoWbx3xmWIAvPUcJXWFe6/Eat5U4MHkBihyE+DM9ZclKQmn FtxRMdV5q0LNgBjQ0+DGzirkW4nNFJgVIS5jek0wfX5bR45bPgFINBqdWvD0RO3QsjBx Ur7VCoWXuKQc7SKM8Al5oq4rPcwUI5Vp48prqYnsfzNHu8kQZOvtwS8f1iROWAKLlGLF 6wSTQDF2/rL2HtA+6lUviNph3BiWrz8T8xh9IjBUxR/za6A07wPiQlRVHmJR7aqaaQhR YGIYJmFNHjM/LCNhFAq6usxxVEnSZIFNn2HdINqbicMnFVC6Uh2vugDi28CtiIVLtc2B GG4w== X-Gm-Message-State: ALQs6tB455FxkLmEdTmEjp5XxipB/aegKogvBeBhXaT4MkUdxkXYYAeN UeEfbH1eRCrp56ZFn7KgXLYHWzyLoWL/LY9QTooK/WxK X-Google-Smtp-Source: AIpwx48YN/O005MOwBpOJX7OAzI365Sru4xoEJRCpvLRcCgnMaUJSjNRPd74NSJ9Y9gRSGMXUhb82uucIc14OIz1P5E= X-Received: by 2002:a9d:5403:: with SMTP id j3-v6mr2430384oth.52.1524084734741; Wed, 18 Apr 2018 13:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 13:52:14 -0700 (PDT) In-Reply-To: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> From: Richard Barnes Date: Wed, 18 Apr 2018 16:52:14 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="00000000000038e460056a25a112" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:52:17 -0000 --00000000000038e460056a25a112 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > I do not support adding a field to the protocol with semantics to be > defined later. Especially a 16-byte field, which is a fair bit of cruft to > carry around. > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > Secondary point. Still don't think we should deliberately include undefined fields, e.g., because part of the discussion is whether 16 bits is the right size. --Richard > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000038e460056a25a112 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 18, 2018, at 4:47 PM, Richard Barnes <rlb@ipv.sx> wrote:<= br> >
> I do not support adding a field to the protocol with semantics to be d= efined later.=C2=A0 Especially a 16-byte field, which is a fair bit of cruf= t to carry around.

The 16-byte is a typo.=C2=A0 It was supposed to be 16-bit.=C2=A0 My = fault. Sorry.

Secondary point.=C2=A0 St= ill don't think we should deliberately include undefined fields, e.g., = because part of the discussion is whether 16 bits is the right size.

--Richard

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--00000000000038e460056a25a112-- From nobody Wed Apr 18 13:53:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20BB126DFB for ; Wed, 18 Apr 2018 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LF9MUivFbY4J for ; Wed, 18 Apr 2018 13:53:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8327B126C3D for ; Wed, 18 Apr 2018 13:53:55 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AE5C67A3309 for ; Wed, 18 Apr 2018 20:53:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 18 Apr 2018 16:53:53 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:53:57 -0000 > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: >=20 > I do not support adding a field to the protocol with semantics to be = defined later.=20 And the semantics are defined. The server must send zero, and the = client must read it as zero. The propose semantics PROHIBIT pinning, = which is what everyone seems to want presently. Future semantics when BOTH client and server implement a forthcoming = spec will to support pinning as described for up to the indicated time = (in suitable units). --=20 Viktor. From nobody Wed Apr 18 13:56:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3369B127909 for ; Wed, 18 Apr 2018 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4urY432aKX6u for ; Wed, 18 Apr 2018 13:56:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6780126C3D for ; Wed, 18 Apr 2018 13:56:40 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1CA4E7A3309 for ; Wed, 18 Apr 2018 20:56:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 18 Apr 2018 16:56:39 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:56:42 -0000 > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: >=20 > Secondary point. Still don't think we should deliberately include = undefined fields, e.g., because part of the discussion is whether 16 = bits is the right size. 16 bits is clearly enough. If the units are hours that gets you ~7.5 = years. Pinning for less than an hour is pointless, it then becomes = smaller than typical DNS TTLs for the TLSA RRset the client got = previously, which it can cache without any pinning. Pinning for more than 7.5 years is absurd, it only protect clients that = connect less than twice per decade... --=20 Viktor. From nobody Wed Apr 18 13:59:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790A0126C3D for ; Wed, 18 Apr 2018 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm4GrRbg9HAs for ; Wed, 18 Apr 2018 13:59:42 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018C4126CF6 for ; Wed, 18 Apr 2018 13:59:41 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 749C168024A4C; Wed, 18 Apr 2018 13:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=UEI7zbyCgU2H00 9U1dVtpqO9p1U=; b=UOh1ahRdt0cAY6yRlWqM5ZA4X4Sl5aziIROikUJCw5912/ 78qDY8mt074PWLYcsNjYKzuE2sRn4KX2FH8YBPI9Ju3/SQpCn4zl2Ufh9xK2JUsD irGLqafES7hJ5Ya70XfFuj4aY3a0a6iMLKQ5GwEXrWFymZTdCHbHjtnurPhMs= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 2BE8D68024A4B; Wed, 18 Apr 2018 13:59:41 -0700 (PDT) Date: Wed, 18 Apr 2018 15:56:04 -0500 From: Nico Williams To: Richard Barnes Cc: TLS WG Message-ID: <20180418205604.GE25259@localhost> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 20:59:43 -0000 On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > wrote: > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > I do not support adding a field to the protocol with semantics to be > > defined later. Especially a 16-byte field, which is a fair bit of cruft to > > carry around. > > > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether 16 bits > is the right size. It's not as if we've never had reserved fields. From nobody Wed Apr 18 14:01:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6CA128954 for ; Wed, 18 Apr 2018 14:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] 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 Su0pK3mX1OkH for ; Wed, 18 Apr 2018 14:01:55 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E95126CF6 for ; Wed, 18 Apr 2018 14:01:55 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id j10-v6so2893508oii.12 for ; Wed, 18 Apr 2018 14:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DKiNKqbhZEzdZPiCq1HhkV6oszpM5+T+jBzNqQapXlY=; b=MN6fx7TxEtmu8p8GfY95k6UZZz63/NZ90DJQqOf4CSWUGeT9hmYtqIX2tIwQJVBq5N 1RbnbvORa8rYIE1fUJpUvhjnhmSlN+mLPKTrC1RQZFi/PCFD+R6NmEyDMAYpXF/8AtyD t41CkNpGPFgGg6bl22wBGJ3nM/SJommhpjr/sffeJwuOnQYt5VSJpylE0YyrRxBBR5P7 pEwUB3vGPXGjlqKCQr0pIRMRucxKlxTqRe9B65J0dP0QENg8eXc1zoZMLs2xiO6Zsbzh gfTdiokKlrmENyW4gc3ctpm4TappL2rEClu6lWOHrqALDGqhouxu7ljbSvd1dDuvfp1m 7b7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DKiNKqbhZEzdZPiCq1HhkV6oszpM5+T+jBzNqQapXlY=; b=ESVDTRrBojx5xMSbpbBL+6liQzc4irMr99ZeH4ERoXTKR2+DGeNOp2R2DXrjELudGw m7iAFxX/MCPkskVrQZZo4/4Dbl0H/sh6aOqMOwxtAno6bpnhpEpIgQwnrmT5sDVUY2M/ iffzkIPKNzfPFJi1tn8wbAl7akiz2ZqYWo3OvxSQFBmt9BOEX2LX3La7m0gYUsYdR3n9 SEq5fKTi4Mf/FyNovo/TPC/cDagZAYaq6wkCqMG6poY/eWw+1eC9/iJvePobJY/NmBWx zD4AiHxb3AID5Cl2Ir6XiYEsQLY3JRUWyyYOig4pqtqE4hgZTr1zHayhGYUMqisPD1Ul rP8Q== X-Gm-Message-State: ALQs6tB8vhLNsb7UTjmQLkhX2TGL8rdq7EPPtFiOaRT6jDWMURX/bZB1 HSBDYhUaKD4YC1hdZrfp3AMrD4Dq6Asv82CRTnJQPpPz X-Google-Smtp-Source: AIpwx48rSRLsOOS/1mdgD6rOiL2zjR3o+NghsLXiXyVLYNPEhpQlXBwk66lumQcWw6LoL09afsX7iY8l2SRLql3zWrE= X-Received: by 2002:aca:aa4c:: with SMTP id t73-v6mr2016191oie.225.1524085314427; Wed, 18 Apr 2018 14:01:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 14:01:54 -0700 (PDT) In-Reply-To: References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> From: Richard Barnes Date: Wed, 18 Apr 2018 17:01:54 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000c6306e056a25c327" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:01:57 -0000 --000000000000c6306e056a25c327 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether 16 bits > is the right size. > > 16 bits is clearly enough. If the units are hours that gets you ~7.5 > years. Pinning for less than an hour is pointless, it then becomes smaller > than typical DNS TTLs for the TLSA RRset the client got previously, which > it can cache without any pinning. > > Pinning for more than 7.5 years is absurd, it only protect clients that > connect less than twice per decade... > 640k should be enough for anyone. `preload`? `includeSubdomains`? Experience with HSTS and HPKP shows you need more than an integer. --Richard > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c6306e056a25c327 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 18, 2018, at 4:52 PM, Richard Barnes <rlb@ipv.sx> wrote:<= br> >
> Secondary point.=C2=A0 Still don't think we should deliberately in= clude undefined fields, e.g., because part of the discussion is whether 16 = bits is the right size.

16 bits is clearly enough.=C2=A0 If the units are hours that gets yo= u ~7.5 years.=C2=A0 Pinning for less than an hour is pointless, it then bec= omes smaller than typical DNS TTLs for the TLSA=C2=A0 RRset the client got = previously, which it can cache without any pinning.

Pinning for more than 7.5 years is absurd, it only protect clients that con= nect less than twice per decade...

640k= should be enough for anyone.=C2=A0

`preload`= ?=C2=A0 `includeSubdomains`?=C2=A0 Experience with HSTS and HPKP shows you = need more than an integer.

--Richard
=

=C2=A0

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

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

--000000000000c6306e056a25c327-- From nobody Wed Apr 18 14:04:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A3126CD6 for ; Wed, 18 Apr 2018 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 D64b_00etDYS for ; Wed, 18 Apr 2018 14:03:59 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E0B126C3D for ; Wed, 18 Apr 2018 14:03:59 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i5-v6so3526691oth.1 for ; Wed, 18 Apr 2018 14:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V5C2CAOEdVSunrcKAzYIuD4gDVpp2l2MEbWazghly3k=; b=b89lBVHtLwCxODEvJemU1h9Qx7WOUhjUS/WGG9EsAw8ri39VMOtraTis+2eb6naovH nm7d+A1X4kfCeJnPHlK3LmEfQ37Orh29s48cs+q8hoTLkz/U5Lgv1NcNglP1bndBq+X/ nugtocwzxt6ce6fsxl4Bs05Ryst5t+cAEMGtdpHzc+1JCeCQLHf1AuzNTe54UhiEbrCn JGgpzS4rQ5qRkoK0k0aPhaw7UjSwdIghLDgOVJJtsA+a3zAoXwMPGkiNaUPeg43jMSwn kaSPqvpKYz4dj8AdOV71h99GyWCWEti9q+rLN0B66fKZXXRRbrKvJIyUdxB3SerPQuKH YtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V5C2CAOEdVSunrcKAzYIuD4gDVpp2l2MEbWazghly3k=; b=LdydJTKPwXVGrbjUbj9tWZIN3khZpEG/kn7sMi03tFoPZA4C5Z+DgnIa/xN6JrAD/u aAk+Frx9cHdu8CyOFHKjRNVNCBfOIL/hmtsPM0VeQAdJ4FrJrX4ed3FKKAl25rkkGkGI uPdCVm1SUP9jE0Wx/5qYIBJlLKChNzCx6QmCRF8SRGin/EoaIHZwlDBtQ5iuyyeme0eV 0QfioA1KcztLVLPAH/WwgYQ5mqZeKPJPTUHHUfL4Q8WMrVZL1tN0muyPfDlw8M6t7c5h GYi8WKdguRRoGl70XvYAwXPZt67ymJUUTnAHPDJlQzilq4XqIc6QZ1HFgHyr4DjCffjE s4Qg== X-Gm-Message-State: ALQs6tCxT0srdrMsH+ZqlGC+8d/1WeD304EwUnKExvw2soR0gFHSruhT wRFWdeMX9h7FWtRcimlihMQxDSoNOFzbQoQULvtB0fP2 X-Google-Smtp-Source: AIpwx499g2VyAibHQwvbB6J5CtAR3E0KELo6ju8NH0AnBVqP+p04sD9zML1vEQDFwdv8R+eFAqrwLehefYtNHk+iG1k= X-Received: by 2002:a9d:1920:: with SMTP id j32-v6mr2420806ota.383.1524085438640; Wed, 18 Apr 2018 14:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 14:03:58 -0700 (PDT) In-Reply-To: <20180418205604.GE25259@localhost> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> <20180418205604.GE25259@localhost> From: Richard Barnes Date: Wed, 18 Apr 2018 17:03:58 -0400 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000002d864f056a25cbe0" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:04:01 -0000 --0000000000002d864f056a25cbe0 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams wrote: > On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > > > wrote: > > > > > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > > > I do not support adding a field to the protocol with semantics to be > > > defined later. Especially a 16-byte field, which is a fair bit of > cruft to > > > carry around. > > > > > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > > > > > > > Secondary point. Still don't think we should deliberately include > > undefined fields, e.g., because part of the discussion is whether 16 bits > > is the right size. > > It's not as if we've never had reserved fields. > The only "reserved" in RFC 5246 is a few code points that are reserved for private use. No reserved fields. --Richard --0000000000002d864f056a25cbe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
> >
> >
> > > On Apr 18, 2018, at 4:47 PM, Richard Barnes <rlb@ipv.sx&g= t; wrote:
> > >
> > > I do not support adding a field to the protocol with semanti= cs to be
> > defined later.=C2=A0 Especially a 16-byte field, which is a fair = bit of cruft to
> > carry around.
> >
> > The 16-byte is a typo.=C2=A0 It was supposed to be 16-bit.=C2=A0 = My fault. Sorry.
> >
>
> Secondary point.=C2=A0 Still don't think we should deliberately in= clude
> undefined fields, e.g., because part of the discussion is whether 16 b= its
> is the right size.

It's not as if we've never had reserved fields.

The only "reserved" in RFC 5246 is a few code point= s that are reserved for private use.=C2=A0 No reserved fields.

--Richard
<= /div>
--0000000000002d864f056a25cbe0-- From nobody Wed Apr 18 14:10:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF92126C3D for ; Wed, 18 Apr 2018 14:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enj-2850Q0FP for ; Wed, 18 Apr 2018 14:09:58 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FCB126CD6 for ; Wed, 18 Apr 2018 14:09:58 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 4DE3768024A4A; Wed, 18 Apr 2018 14:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WOYAj84THB8xLx dF3BwXbxBI7ZE=; b=mig9LWpltryY3gNJ7j3HggJv2YYjsh2onee+QF1Ayg/RPy UvgNTMJxsiG0ja/VqT2R39MOt0aJ85fbesmDwJsRyVYc4FzP7PUiMmTKcpVmmoV4 l/zHTKtOCeumPZhs4KzjfszadMxl+euXqYGFpVL9N7cvPoDlMhCPG6JDXJf+w= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 01C1868024A42; Wed, 18 Apr 2018 14:09:57 -0700 (PDT) Date: Wed, 18 Apr 2018 16:06:16 -0500 From: Nico Williams To: Richard Barnes Cc: TLS WG Message-ID: <20180418210615.GF25259@localhost> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:10:02 -0000 On Wed, Apr 18, 2018 at 05:01:54PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni > wrote: > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > > > Secondary point. Still don't think we should deliberately include > > undefined fields, e.g., because part of the discussion is whether 16 bits > > is the right size. > > > > 16 bits is clearly enough. If the units are hours that gets you ~7.5 > > years. Pinning for less than an hour is pointless, it then becomes smaller > > than typical DNS TTLs for the TLSA RRset the client got previously, which > > it can cache without any pinning. > > > > Pinning for more than 7.5 years is absurd, it only protect clients that > > connect less than twice per decade... > > 640k should be enough for anyone. That's just silly. Really, 7.5 years (relative, not absolute) measured in hours is plenty good enough, and more than outlives current device obsolescence. This isn't subject to Moore's law or anything like it. > `preload`? `includeSubdomains`? Experience with HSTS and HPKP shows you > need more than an integer. No, we need none of those things. We want only to pin the presence of this extension. Anything else would be operationally difficult (as seen with HPKP). As to subdomains, we're willing to live with TOFU semantics for all of them. Nico -- From nobody Wed Apr 18 14:15:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01091126C3D for ; Wed, 18 Apr 2018 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KsVheVdMzdSl for ; Wed, 18 Apr 2018 14:15:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420F7120047 for ; Wed, 18 Apr 2018 14:15:14 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 892327A3309 for ; Wed, 18 Apr 2018 21:15:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 18 Apr 2018 17:15:12 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <23E9C80F-AC93-4D10-B9A3-7F65AFB1DF5D@dukhovni.org> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> <20180418205604.GE25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:15:16 -0000 > On Apr 18, 2018, at 5:03 PM, Richard Barnes wrote: >=20 > The only "reserved" in RFC 5246 is a few code points that are reserved = for private use. No reserved fields. The field is NOT reserved, it carries an "extension support lifetime" of = 16-bits whose zero value means "DO NOT PIN". Other values will be = defined in a follow-on draft, but clients must interpret those also as = zero unless they implement the other draft. Therefore, a client implementing this draft has complete semantics for = the field, it explicitly prohibits pinning, which might otherwise = happen, especially if no follow-on document materializes. --=20 Viktor. From nobody Wed Apr 18 15:35:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6AE126CE8 for ; Wed, 18 Apr 2018 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVFfsDQJ73Nw for ; Wed, 18 Apr 2018 15:35:45 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E89D124D37 for ; Wed, 18 Apr 2018 15:35:45 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f3-v6so4349201iob.13 for ; Wed, 18 Apr 2018 15:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DRjLe0kA58d2fFMplfNB6OPB2mjzt/TgSt1qHA/qt8U=; b=IyZyuYdgYSb/UH21GneQtqB9kSJx6YzIBnhWv3Gu1iFa3Fph1v661tplOxPub5VoKf 3M+BmRrnbumu73HAhRo5thmeb7LcnsBL4sa2Gt4yB2otOWv+ccgrWdqCkPulH4qaPAAO lpkh6VWCI5VcaE0tSTrRVZyN7lMwvTncY+MIU96VnPTsFcSN5sQr2gESRxddJV879pZN XeF6tq2v6dlOG5ud2I2WX2slhDv2ECD3GyLTyKoZXdHdY7D4DMtYBZqtYFwlxdqJxPwZ xhMXpBnb5mS5BFYZo2kafWdCtNrZAlqWvDKifEhjF8gauleI9yQdJQ5QPqzOKHf+NSO0 esKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DRjLe0kA58d2fFMplfNB6OPB2mjzt/TgSt1qHA/qt8U=; b=L0JrB2kYRT2rr287KmbjVaZ7EvdkA83HQu8crXQh1JD5dt3us9iKgTYIXRSI8UZKV2 4ZIFjG2/w0YwomOpdDEOEj6AWMgS3vYdwghkwP93j19/nzkhaOeIFQseCuCIzDxMSlId c7E4IgKoW0jssNbB4YViDDrwWipHQeKDEahsmwi/tuhQnYAJr1hdNHKk7eJDuTe2sQlT Hc/x3xjdYf88LEUIGhba5Luoj+HLENhOMpBEBSgIwFtekub1rwbssgnZs44usaF87sDg Go/y8OHZl/LxV0dv0KepN0zify/r62SpCphFdY2jiTS8AuBv8XzO2pqRrH3fp0kW9oyw n/dQ== X-Gm-Message-State: ALQs6tBOYvV44rfFgn1mZKbMkIdOel8NJ+f8zcH8ZYipSSmpvFtVkNnP /fiP3DpiTjn3UpEJNTtn0eVsG7yAT0jKGXaWMvQ= X-Google-Smtp-Source: AB8JxZpVdnyL9FFMKG1u3pWQU9sZIMMm8xrdmu7cczxG91IygzYDFLNIw3cVsApcrZDu79yNA3g1jnLwa3lXKOAnd0o= X-Received: by 2002:a6b:9b15:: with SMTP id d21-v6mr4154660ioe.243.1524090944363; Wed, 18 Apr 2018 15:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 15:35:43 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Wed, 18 Apr 2018 18:35:43 -0400 Message-ID: To: Paul Wouters Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="0000000000005823bd056a27131d" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 22:35:47 -0000 --0000000000005823bd056a27131d Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote: > > 2. Explicitly allow (but do not require) DoE be included >> > > The document does not currently allow the extension to be empty. So if > there is no TLSA record and the extension would be present, it therefore > can only contain a DoE chain. So what do you mean with item 2? Possibly > you mean to say "if there is no TLSA record, the extension can be omited > or the extension can be included with a DoE chain" ? That would be okay > with us. Yes, my understanding is that's what it means. Note that Section 8 ("Mandating Use") already did hint at the future possibility of this extension carrying a DoE chain that could be deployed in a TLS application ecosystem where all servers understood and were prepared to respond to this extension. The plan is to now add text that allows DoE chains more generally, with details of use defined in subsequent documents. Shumon. --0000000000005823bd056a27131d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 18, 2018 at 4:42 PM, Paul Wouters <paul@nohats.ca> wrot= e:

=C2=A02. Explicitly allow (but do not require) DoE be included

 The document does not currently allow the extension to be empty. So if
there is no TLSA record and the extension would be present, it therefore can only contain a DoE chain. So what do you mean with item 2? Possibly
you mean to say "if there is no TLSA record, the extension can be omit= ed
or the extension can be included with a DoE chain" ? That would be oka= y
with us.

Yes, my understanding is that'= s what it means.

Note that Section 8 ("Mandat= ing Use") already did hint at the future possibility of=C2=A0
this extension carrying a DoE chain that could be deployed in a TLS appli= cation
ecosystem where all servers understood and were prepared t= o respond to this
extension. The plan is to now add text that all= ows DoE chains more generally,
with details of use defined in sub= sequent documents.

Shumon.

--0000000000005823bd056a27131d-- From nobody Wed Apr 18 20:25:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2A4127867 for ; Wed, 18 Apr 2018 20:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xstrt8eBIxDQ for ; Wed, 18 Apr 2018 20:25:30 -0700 (PDT) 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 B92BE127369 for ; Wed, 18 Apr 2018 20:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1524108329; x=1555644329; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xwYSUFSrcDa74bNeLCVLY4oQs6f/GjT97zzx8S80M/I=; b=URkR7XO3sbVA9vBlKQMIkG65BV9TuvbNKLRpFrwhhdHZgxb7bRlwE4QL UTigq3YbYE55Y1rBO8xAEHAfn3eHKtYS3aIPtCUvSeTcsHuXO87osJ/ZK ifFMljnI6o3OpGJ0GjEmYJyi8ERC/MuoJ4NZDyqnHVkv55ur5GJgKVGSu u/o3wHeW6h1h8+IhrVS8TqfIv7kn02S2Iry0Opp1QuWnbJeS1GmAEIa4p sXkNw26Jffs5vWL5YKtbLlUZxDRSAoOe9M1viKXGon0KYV5PkktBMQfc4 uNn8RUP40w6oWgU1IfadAN/L00iWpgDcbv3VxSRRx/1CFzjnnsgPnSXwq Q==; X-IronPort-AV: E=Sophos;i="5.48,467,1517828400"; d="scan'208";a="7879682" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Apr 2018 15:25:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Apr 2018 15:25:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 19 Apr 2018 15:25:25 +1200 From: Peter Gutmann To: Nico Williams , Richard Barnes CC: TLS WG Thread-Topic: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension Thread-Index: AQHT10IyxLHb1Ci+M0S/bRNjWd2bm6QGM+kAgAABUYCAAABigIAAAPcAgAABPICAAAF3AIAAATgAgAEygpM= Date: Thu, 19 Apr 2018 03:25:24 +0000 Message-ID: <1524108318840.45277@cs.auckland.ac.nz> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> , <20180418210615.GF25259@localhost> In-Reply-To: <20180418210615.GF25259@localhost> 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:25:32 -0000 Nico Williams writes:=0A= =0A= >That's just silly. Really, 7.5 years (relative, not absolute) measured in= =0A= >hours is plenty good enough, and more than outlives current device=0A= >obsolescence. This isn't subject to Moore's law or anything like it.=0A= =0A= I don't know what devices you work with, but for the ones where my code is= =0A= used ten years is the baseline life expectancy, going out to 15-20 years fo= r=0A= longer-life ones (I still have to deal with SSH bugs from the late 1990s,= =0A= because the lifetime of the equipment that's used in is 20 years and counti= ng.=0A= I think I've finally managed to get away from having to do SSLv3 within the= =0A= last year or two).=0A= =0A= OTOH I doubt any of these devices will do pinning, they just bake in the ce= rts=0A= at manufacture/provisioning, so I'm fine with any kind of lifetime. Just= =0A= wanted to point out, yet again, that the entire world doesn't live in a "we= =0A= can patch the entire deployed base in 24 hours" situation.=0A= =0A= peter.=0A= From nobody Wed Apr 18 20:34:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12DD120713 for ; Wed, 18 Apr 2018 20:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 T1ERhIVJKTAn for ; Wed, 18 Apr 2018 20:34:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E5B127369 for ; Wed, 18 Apr 2018 20:34:17 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 068EA7A3309 for ; Thu, 19 Apr 2018 03:34:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <1524108318840.45277@cs.auckland.ac.nz> Date: Wed, 18 Apr 2018 23:34:14 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> <20180418210615.GF25259@localhost> <1524108318840.45277@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:34:20 -0000 > On Apr 18, 2018, at 11:25 PM, Peter Gutmann = wrote: >=20 >> That's just silly. Really, 7.5 years (relative, not absolute) = measured in >> hours is plenty good enough, and more than outlives current device >> obsolescence. This isn't subject to Moore's law or anything like it. >=20 > I don't know what devices you work with, but for the ones where my = code is > used ten years is the baseline life expectancy, going out to 15-20 = years for > longer-life ones (I still have to deal with SSH bugs from the late = 1990s, > because the lifetime of the equipment that's used in is 20 years and = counting. > I think I've finally managed to get away from having to do SSLv3 = within the > last year or two). >=20 > OTOH I doubt any of these devices will do pinning, they just bake in = the certs > at manufacture/provisioning, so I'm fine with any kind of lifetime. = Just > wanted to point out, yet again, that the entire world doesn't live in = a "we > can patch the entire deployed base in 24 hours" situation. Indeed, but if pinning were desired, all the device would have to do is = call the mother ship at least twice per decade, it can then work for = multiple decades. I agree for many devices that don't wander the web in search of the = latest cute kitten photos, and just "call home", a single fixed cert is = a more plausible security model than either WebPKI or DANE. --=20 Viktor. From nobody Wed Apr 18 20:42:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82506128959 for ; Wed, 18 Apr 2018 20:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exssD7S7be9O for ; Wed, 18 Apr 2018 20:42:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221EF120713 for ; Wed, 18 Apr 2018 20:42:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 91C688019502; Wed, 18 Apr 2018 20:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=U39023dNue4NjrITde0EavPXsvQ =; b=gDhas2MN4Px493iyb5THOgR9WctP++jkm88AD9CfxmShsF92Cd/O2biaLGt a9PpFcm8HHHiwd4SOKIMad0uK9XKs0TPfVGdfRYP44L3/dE9JLMEhaK+L5NChhu6 OYoIHwLvf+akfzDrhKkJj4oEAioUvpJ11FC5GMxJkqtQDsGc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 6014B8019501; Wed, 18 Apr 2018 20:42:27 -0700 (PDT) Date: Wed, 18 Apr 2018 22:25:17 -0500 From: Nico Williams To: TLS WG Message-ID: <20180419032516.GG25259@localhost> References: <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> <20180418210615.GF25259@localhost> <1524108318840.45277@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 03:42:29 -0000 On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote: > > On Apr 18, 2018, at 11:25 PM, Peter Gutmann wrote: > >> That's just silly. Really, 7.5 years (relative, not absolute) measured in > >> hours is plenty good enough, and more than outlives current device > >> obsolescence. This isn't subject to Moore's law or anything like it. > > > > I don't know what devices you work with, but for the ones where my code is > > used ten years is the baseline life expectancy, going out to 15-20 years for > > longer-life ones (I still have to deal with SSH bugs from the late 1990s, > > because the lifetime of the equipment that's used in is 20 years and counting. > > I think I've finally managed to get away from having to do SSLv3 within the > > last year or two). > > > > OTOH I doubt any of these devices will do pinning, they just bake in the certs > > at manufacture/provisioning, so I'm fine with any kind of lifetime. Just > > wanted to point out, yet again, that the entire world doesn't live in a "we > > can patch the entire deployed base in 24 hours" situation. > > Indeed, but if pinning were desired, all the device would have to do > is call the mother ship at least twice per decade, it can then work > for multiple decades. Exactly. From nobody Thu Apr 19 13:32:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7B12E048 for ; Thu, 19 Apr 2018 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM8L2dDG-KGq for ; Thu, 19 Apr 2018 13:32:35 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1EF12E044 for ; Thu, 19 Apr 2018 13:32:35 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id s70so6710934qks.13 for ; Thu, 19 Apr 2018 13:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NG6NJq7OpdvwP0Yjv3HH6DDWVVH/FGeWNfVPTu0WMsI=; b=Ii128eMshdylgOay8uay3Dbp8CoBO/zlrZJ2YQxqOY78jvsAccOzkcplZOo6nHh/jS eAGxQwluDFT/imoGc913+fjrwoNnJXGwn+tkCpxqc3w/p0EKJu3caOagQ2CgEv1v2kA2 AS8yuHo+CgfQZryF+MNGGxwp43yrhXHG20Qug= 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=NG6NJq7OpdvwP0Yjv3HH6DDWVVH/FGeWNfVPTu0WMsI=; b=sUMOV1VSnN5G300IP5sWPXdtJH+YPm6wQ5DJkaHM4fstWPCVBFQC7aXIxLVKCmoj4j uR0aTn/xPzIo0QeHrkdoIp0MO19G3pEsLk7SUBnOzVOwSLtEG1nIeFz91lyfakYahdPv SH6WuzDKnp1siCV5zrKSusKakbwyWWTy+NDpaO17/vp7qFjDA6nrBcxk/1XT8hQrWwDd Gf8DIIuca15MccLO0Hdorj2EnBCxuXmKetkVOmQ4zMWmcug56LEf4OpoNSa75cAW+owy g21+KqiMC1l1X0dUyB2iIf65HcgZLg6rW698+9pBLJ2+vj2sFpU0YM/M9Loh7OypiqF2 BfiA== X-Gm-Message-State: ALQs6tCrEtFpFzDQXGCquuxbhH5GIRYTnSCLH6q3TKYgAbXjIziyxwZF ydyPNt1f1sbIoFzzAncMEoAmJPrfD5E= X-Google-Smtp-Source: AB8JxZrmd3HHLKWApYbdMldvd2pgr+353KDAI1gwVKOkaj8mXinzmEFQmcrfGgfpLDYyhV2FsPHbHQ== X-Received: by 10.55.34.129 with SMTP id i123mr7638026qki.119.1524169954254; Thu, 19 Apr 2018 13:32:34 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id l52-v6sm3632299qtc.45.2018.04.19.13.32.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 13:32:33 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 16:32:31 -0400 References: <152028170546.31682.17720971813299921457.idtracker@ietfa.amsl.com> To: "tls@ietf.org" In-Reply-To: Message-Id: <1015610F-D0A5-48F6-8717-BB67A90CAABA@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] New Version Notification for draft-ietf-tls-exported-authenticator-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 20:32:37 -0000 To make sure nobody is caught off guard, I=E2=80=99m going to issue the = WGLC shortly for this draft. We were waiting on getting a security = review and we got that in London and from the security proofs = perspective it looks like we=E2=80=99re good to go for a WGLC. spt > On Mar 5, 2018, at 20:07, Nick Sullivan wrote: >=20 > FYI, I've published an updated version of exported authenticators = incorporating into account the changes discussed at IETF 100 and on the = list. >=20 > ---------- Forwarded message --------- > From: > Date: Mon, Mar 5, 2018 at 12:28 PM > Subject: New Version Notification for = draft-ietf-tls-exported-authenticator-06.txt > To: Nick Sullivan >=20 >=20 >=20 > A new version of I-D, draft-ietf-tls-exported-authenticator-06.txt > has been successfully submitted by Nick Sullivan and posted to the > IETF repository. >=20 > Name: draft-ietf-tls-exported-authenticator > Revision: 06 > Title: Exported Authenticators in TLS > Document date: 2018-03-05 > Group: tls > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-tls-exported-authenticator= -06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticato= r-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-exported-authenticator-= 06 >=20 > Abstract: > This document describes a mechanism in Transport Layer Security = (TLS) > to provide an exportable proof of ownership of a certificate that = can > be transmitted out of band and verified by the other party. >=20 >=20 >=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 > The IETF Secretariat >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 19 13:33:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D391F12E044 for ; Thu, 19 Apr 2018 13:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgdD5Re2qR9s for ; Thu, 19 Apr 2018 13:32:59 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D5D12E048 for ; Thu, 19 Apr 2018 13:32:58 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w12-v6so7263924qti.4 for ; Thu, 19 Apr 2018 13:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=abfGmP/8q0h1kwiGbHHHAshdHQ6flQ2GXK/CYMT6bx8=; b=UTjvAD2GJelH0K+V0ijdFzKrudB2fhTRwSl2qSAbEZrbo7RRBWmAIJ+cNO2NjOGwI6 JQStxqp2Wcm806CUUOTxpq62NngC5X9QqhjBoaOS9mszgnKCk8KlRmpBAuyYRRBfR/CY RcjXKt42Qs3f6E3FVw2gdSOms119q/SPVJEEw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=abfGmP/8q0h1kwiGbHHHAshdHQ6flQ2GXK/CYMT6bx8=; b=GfxU1A1ODzGRYZGTtZRFRgv2AluXOwC1kGEY9y5/AU9AAXSiIlwC/rRHznf6exgwRr zDNHxpNRRR/cakkXgBJO7CIq9azV109rIAgBFw0XS7IP4Jr7iJjRDy8C3job62f4SYb/ FooNsQo063WlhQ5L130bZBp7Ub3/z+GeIyCmEB1Ux4XgEvD9V6FIZA93Xn5sVKukaR45 K3W56w5EDlxGnHvx0VRuF3C1KfoplTwPga7u9R685LfpJrJ1EVslE4kwuVPJ9Ppd/C2U dlWfC6vqryLEFkgtoO/jo49IsB+zda092rqXCzdzSA5KqWjEFE93GLdFNYeU2z+ehlN1 trsg== X-Gm-Message-State: ALQs6tA7uUVG63XrGMLulp2At7zbftE1B338UGON2gBt+qcEvmHRAaQ0 GSnI2FZWJjRAf2m1/3rsuSPNuXcCC9o= X-Google-Smtp-Source: AIpwx48U/e+X6oPbbXMWS/pd5RNi4H6ledMrCCxql4oOhTOnO+UQ6ChqOuzUsuirsrVQS9ANLZ94Hg== X-Received: by 2002:ac8:f96:: with SMTP id b22-v6mr8122088qtk.301.1524169977341; Thu, 19 Apr 2018 13:32:57 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id l52-v6sm3632299qtc.45.2018.04.19.13.32.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 13:32:56 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> Date: Thu, 19 Apr 2018 16:32:55 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 20:33:02 -0000 All, This is the working group last call for the "Exported Authenticators in = TLS" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. = Please review the document and send your comments to the list by 2359 = UTC on 4 April 2018. Thanks - J&S= From nobody Thu Apr 19 14:40:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A182126D73 for ; Thu, 19 Apr 2018 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8Bqf3ieOD7kW for ; Thu, 19 Apr 2018 14:40:50 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F32C12420B for ; Thu, 19 Apr 2018 14:40:50 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v2so6922191qkh.10 for ; Thu, 19 Apr 2018 14:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VxslnJSjzv+kElpS6s5Q8IMzTpajAeZaaZToF4MNBA=; b=o7aXLS+gAukkyjla/iP/Ev0+W+DFT11yONhp2ig3NZgpnlT/h+eWTSNB5Hvd7MsUif On9gbLd5Y8rNQPeDKJxA08B831QzImtEqbZze0pt1iFmYo5AHCFrJTRZWp1v20avWN3X ly6JtdkdtW2SywQw++/dhuhaynXys+LXu2CtVNt2ly83antTGW+EhEkNK7q1Vv8Utk30 g2e4I/0CZrnk7MWXT9UyzQq5XogayZAywvMksU0jwoKPpV4TEcw6Yh1A2i1qlN/EEYoI dgozl3kRfr6cTZMVR3VMW5rCpZIL1OcxTePr7QVaKC7EBxAwSzJNHNUgks+koBUarBvo 9tPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VxslnJSjzv+kElpS6s5Q8IMzTpajAeZaaZToF4MNBA=; b=I+DwijFZ4gQ0oEqsEweRs35QhFTG836EVEP3ynAjgpscqxY95SjIncwXk/7VxSNKz6 aB/CePNNGKaKHMol8UbltV/zVU+3xd73ovdRIsHK1efwpWO6dRLvp8gk/lCKiwwSkBI3 zw9IJzz1ksPuP2P8dVanD/aR8MZlt1R1dVszyxLcf/joUI1CrbPQVN6uqGfZL9buAl+7 igwlDygUNlZfPZ4jUgXJp5CE++pH7BikH8I6pXNHxApfdNM0BLOI1l5O0QUb81Ai3/LM QAUt/DxrHLw7PSfBc4m25J+W0A2XjZ4l2stCJuxCv9lO/kjE32/GLjgZBItboqa0jxM6 NzMQ== X-Gm-Message-State: ALQs6tDR3zPdmIdKQebO3TEeKeDqx3ShfLORnx6//wSZSTp9112luG0+ 0oWbr80Wl/I7nCrLkWLQUUwKUgQRyzH40mb3I6D+AUW6 X-Google-Smtp-Source: AB8JxZqeA3WWhHu/LEVnggkUFlkVIRSs8+5Db2RR0UWPoOCD3Bx5rMOuTl33+Vuxm2AfBPRclWv0NG32b1fHshZsJtE= X-Received: by 10.55.24.83 with SMTP id j80mr8356075qkh.23.1524174048999; Thu, 19 Apr 2018 14:40:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.18.41 with HTTP; Thu, 19 Apr 2018 14:40:48 -0700 (PDT) In-Reply-To: <20180322183941.GA31902@bolet.org> References: <20180322171000.GA23594@LK-Perkele-VII> <20180322183941.GA31902@bolet.org> From: Victor Vasiliev Date: Thu, 19 Apr 2018 14:40:48 -0700 Message-ID: To: Thomas Pornin Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142980cc50856056a3a6caf" Archived-At: Subject: Re: [TLS] potential attack on TLS cert compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for 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 Apr 2018 21:40:52 -0000 --001a1142980cc50856056a3a6caf Content-Type: text/plain; charset="UTF-8" Did we ever reach any agreement about what to do here? For me, the threat model here seems fairly far-fetched and infeasible, in the sense that the threat only exists in some very specific bugs in multithreaded decompressor. I'd be less reluctant to do this if it were not for the fact that all solutions I've considered for this are quite annoying. Putting the hash on the wire means wasting bytes, and altering the transcript hash introduces a lot of complexity into some implementations. On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin wrote: > > Certificate compression would be challenging to implement, though. > Usually, compression relies on at least a "window" over the decompressed > data (32 kB for Zlib/Deflate). Some rudimentary forms of compression > don't need that (e.g. run-length encoding) but usually offer poor > compression ratios. A 32 kB window is a lot for the kind of architecture > that BearSSL targets. > This is roughly my intuition -- you could parse certificate messages in a streaming manner, but if you're on a sufficiently limited platform that this is a worthwhile investment, you're probably not going to use certificate compression anyways. --001a1142980cc50856056a3a6caf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Did = we ever reach any agreement about what to do here?

For me, the threat model here = seems fairly far-fetched and infeasible, in the sense that the threat only = exists in some very specific bugs in multithreaded decompressor.

I'd be less = reluctant to do this if it were not for the fact that all solutions I'v= e considered for this are quite annoying.=C2=A0 Putting the hash on the wir= e means wasting bytes, and altering the transcript hash introduces a lot of= complexity into some implementations.

=
On Thu, Mar 22, 2018 at 11:39 AM, Thomas P= ornin <pornin@bolet.org> wrote:
Certificate compression would be challenging to implement, though.
Usually, compression relies on at least a "window" over the decom= pressed
data (32 kB for Zlib/Deflate). Some rudimentary forms of compression
don't need that (e.g. run-length encoding) but usually offer poor
compression ratios. A 32 kB window is a lot for the kind of architecture that BearSSL targets.

This is roughly m= y intuition -- you could parse certificate messages in a streaming manner, = but if you're on a sufficiently limited platform that this is a worthwh= ile investment, you're probably not going to use certificate compressio= n anyways.
--001a1142980cc50856056a3a6caf-- From nobody Thu Apr 19 21:09:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8E12D874 for ; Thu, 19 Apr 2018 21:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCdpWv-6q0rX for ; Thu, 19 Apr 2018 21:09:22 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB58127871 for ; Thu, 19 Apr 2018 21:09:21 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id b131so3377951qkg.2 for ; Thu, 19 Apr 2018 21:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ICANo1AEaDgmmdb6lcC9ONhgBeDSeo83Mep2RotDdAs=; b=s1+9uCIUuIL+vnSvl+C61Rf6eICIJHqQPAwXP/kR4PCEVOvHHq2PjRhKcC5UC2vUgf lZkApvRgX6xgmfl0JxtHy5OATVZsgh6gk+xAPWkL7c0Xx9hunb+o3e1+rn3ugOXCG3Ie ab33+dA8Ors1n+/Ej3FJ9Rjv5M1zT1GDWoF/o7HH75AfWT7gGACkUc0lgwo1V3gxuWww 5ss6a9O3MkS3SepeWxEp6Dk3rahOQJp6eEEK59HQt6zrk4Msfx2AGa2COkmu7Z31YH4e L5db00nUkR0iGQxFIpvdjho3iSIjs89HfisM56TGzhEXwWQVpxsIGOmlVz79PNB1zXd1 TCHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ICANo1AEaDgmmdb6lcC9ONhgBeDSeo83Mep2RotDdAs=; b=deiaqwlIoO5h6tsnwj794a8+W2lCsYcFJN7RN8jz0+GI5RUiu1ypn0QH7BuF5Rsfm1 Ne4nJkCTE1z8BwdH3ckrZMXZGiSNv7yZonpj6Wr+9iSwUhpSZN7icSHUVnK2r6uRatXc MuwwxZ2AXoRHrVfu07F14AtA8xpX54RXm6ajGnB6BeeSAa+YCNBUw66hEEzBa0ilbTaV 9Dm7iJxv0I4bpyXotaUP7zWVmcx+LH4XIqYRV4+Z6NRmTssuyHeBOm1z1MpxmTZOr7mu yRL6Xlld/lA736YyWUYSMFkCJ7R9DuqADKh/mSW02mdYIdI0c1NlyERyhSs66b2vLrHg zq0A== X-Gm-Message-State: ALQs6tC9KCRMZs8IOSMd1eMEZvnHcOXvB6jtOCxRfLFEdfFPFjPT4b0I /AnwBFQ02EqRQ49OBh1WXl0pQNjCSOyYm+6MT5Mvjw== X-Google-Smtp-Source: AB8JxZrOhUR2PDMdy+ST+fIJO/WTUX11zWdBz32w1Jv6uU5AMrVP4OA0NLo/VD4A9WkVU8G0hnYFvJ8e58/KgZFNfAQ= X-Received: by 10.55.132.132 with SMTP id g126mr8554170qkd.108.1524197360867; Thu, 19 Apr 2018 21:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.112.198 with HTTP; Thu, 19 Apr 2018 21:09:00 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Thu, 19 Apr 2018 21:09:00 -0700 Message-ID: To: Paul Wouters Cc: "" Content-Type: multipart/alternative; boundary="94eb2c0779a2432df7056a3fda76" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 04:09:24 -0000 --94eb2c0779a2432df7056a3fda76 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters wrote: > > > 4. Re-submit the document for publication and start work on a separate >> extension that supports pinning >> > > While we agree we can move pinning to a separate document, it makes much > less sense for this to become an additional fully independent TLS > extension, especially since the pinning will depend on DNSSEC properties > only delivered by the TLS-DNSSEC extension. So as we suggested before, the > best solution therefore would be to define this two byte pin in the > current document, and be defined as "ignore completely unless you > implement this other RFC". That is, > > The proposed 16-byte "extension support lifetime" field will: > > * Have 0 as the only value defined in the present draft > * Servers that implement only the present draft SHALL send 0. > * Clients that implement only the present draft SHALL treat > any value received as though it were 0. > * A zero "extension support lifetime" field prohibits the > client from unilaterally mandating the extension based > on prior observation of its presence (pinning). > > This a win-win for both opponents and proponents of pinning. And not > only that, it will allow us to put the pinning inside the extension > it relates to. > > Additionally, with no pin set to 0 in the current document, and no > mentioning of pinning since the consensus agrees to remove it that, > client implementations will not be told to not pin, and will start doing > something like TOFU like pinning. It would actually be better to specify > this zero pin to prevent this from happening. > > If you take it as a given that we will write this document, then it only > makes logical sense to already reserve these two bytes in the current > document, even it if states "must be 0". Our document will Update: > this document to describe the pinning in detail. > > [Joe] This can also be done with a new extension code point that defines a replacement extension that adds the pinning policy. This seems like viable possibility, we are not running short on extension code points. > Nico, Paul and Viktor > > --94eb2c0779a2432df7056a3fda76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters <paul@nohats.ca> wrote:

<snip>

=C2=A04. Re-submit the document for publication and start work on a separat= e
=C2=A0extension that supports pinning

 While we agree we can move pinning to a separate document, it makes much less sense for this to become an additional fully independent TLS
extension, especially since the pinning will depend on DNSSEC properties only delivered by the TLS-DNSSEC extension. So as we suggested before, the<= br> best solution therefore would be to define this two byte pin in the
current document, and be defined as "ignore completely unless you
implement this other RFC". That is,

=C2=A0 =C2=A0 =C2=A0The proposed 16-byte "extension support lifetime&q= uot; field will:

=C2=A0 =C2=A0 =C2=A0 =C2=A0* Have 0 as the only value defined in the presen= t draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0* Servers that implement only the present draft = SHALL send 0.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* Clients that implement only the present draft = SHALL treat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any value received as though it were 0. =C2=A0 =C2=A0 =C2=A0 =C2=A0* A zero "extension support lifetime" = field prohibits the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client from unilaterally mandating the ex= tension based
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on prior observation of its presence (pin= ning).

This a win-win for both opponents and proponents of pinning. And not
only that, it will allow us to put the pinning inside the extension
it relates to.

Additionally, with no pin set to 0 in the current document, and no
mentioning of pinning since the consensus agrees to remove it that,
client implementations will not be told to not pin, and will start doing something like TOFU like pinning. It would actually be better to specify this zero pin to prevent this from happening.

If you take it as a given that we will write this document, then it only makes logical sense to already reserve these two bytes in the current
document, even it if states "must be 0". Our document will Update= :
this document to describe the pinning in detail.


[Joe] This can also be done with a new= extension code point that defines a replacement extension that adds the pi= nning policy.=C2=A0 This seems like viable possibility, we are not running = short on extension code points.=C2=A0=C2=A0

=C2=A0=
Nico, Paul and Viktor


--94eb2c0779a2432df7056a3fda76-- From nobody Thu Apr 19 22:33:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6AD127871 for ; Thu, 19 Apr 2018 22:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Yr86cl6xwmWo for ; Thu, 19 Apr 2018 22:33:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E27C127775 for ; Thu, 19 Apr 2018 22:33:26 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 074F97A3309 for ; Fri, 20 Apr 2018 05:33:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 20 Apr 2018 01:33:23 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 05:33:28 -0000 > On Apr 20, 2018, at 12:09 AM, Joseph Salowey wrote: >=20 > [Joe] This can also be done with a new extension code point that = defines a replacement extension that adds the pinning policy. This = seems like viable possibility, we are not running short on extension = code points. =20 This looks like the lose-lose version. * The present extension loses all downgrade from original LC, and gets a reduced scope, all without a clear consensus to limit the scope or lose all downgrade protection, with the path forward on restoring it more uncertain. * No explicit do not pin signal in the present extension. * Should a second extension be defined later, clients have to signal two separate extensions, and servers have to respond with two separate extensions. Complicating implementation, all to save two bytes in the present extension, with those two bytes providing a clear do not pin signal, not pinning at this time does have consensus. * With the extra two bytes the next specification merely needs to allow new interpretations of non-zero values, with no new wire formats for anyone to implement. THe upgrade path for both clients and servers becomes simple, just extend the capabilities of an extension they may already support, or which existing code can be found. The requested 2-bytes carry no implementation burden for parties that would implement the extension without those bytes. Worst-case they'll never be used, but they do signal good-will on the part of those who want a minimal extension now to allow the follow-on specification to be developed. The close attention to the content of this document that resulted from the disparate views of its proper scope has found important issues that were missed, and corrected an unnecessary limitation (prohibition of denial of existence). Though some delay has resulted, the document is better off for it. I think it is fair to ask for good faith in return, at a negligible cost of 16 bits that might if things don't go to plan forever remain zero, but will at least explicitly signal to the client that pinning based on prior observation of the extension should not take place. Refusing to make a trivial concession to gain a broader base of support for the document, just to save two bytes does not look like an inclusive process to me. --=20 Viktor. From nobody Fri Apr 20 16:46:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52812D958 for ; Fri, 20 Apr 2018 16:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdTjAM_nS8h9 for ; Fri, 20 Apr 2018 16:46:43 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BC6127201 for ; Fri, 20 Apr 2018 16:46:43 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id q5-v6so7286824lff.12 for ; Fri, 20 Apr 2018 16:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E1rB+famMGmZ1Ea0h6X5McbQzQhsLo9b5eesLqDLunE=; b=QA+qm86ks6q4LOrEzm+GehBtHwi3TQ+UTkH83VJKef2c+vDpNgboyJVaptFLFCo2nv i2Z+VF9jMm4bzt8mWv3n4RNhOgJyqV6adSvs/wH5DHDDsP/uiLd7z0eo4SqxGkZJVAUH YIr/O44VBG355t0VJqNlo/4j8s3QsYZWUZEKGN0ZXPGRi/ushcVKFF7DM4vB/vx3ilzm GJEEMlbInlpuGV/zcXgvKWWXWnzgqzDrsc1/4VM/XISNS6uoZQVU0flR0kODVDdXe4re 4LGLvpdt6tzWvPZiCDbvQCD31n1V3VyFom6EeWM0VrN77oKEMdR3OQbQ15JhIOcWicG8 8xmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E1rB+famMGmZ1Ea0h6X5McbQzQhsLo9b5eesLqDLunE=; b=h8rpff+BntUbsc3vuodl2iA+8UIMLvyK0/uaLrCv36FIDV+nTqlvA1E4jpJApDCKTp dn5sYT7t5kq4N99S1izhgkie3Sysd8F9ClYNBbu7MFagwmJq3qgHp1wkjYMzbS60p7+u tHlcVvvfwjiSEGkSw0yMoo5MQUr9jOBddO65gyS9s0CgXSrE1FRQuPoiPF3kZ0UawKxX 2vEBb+ucAKaZJO0PeLKaN+iwIHZ/UBFJdDacytAbwT8Muc4hX5cmFNoCu9GHlWn96Abd Kqt2EG/uHLmnyi42sysIcZsXeTexROPYGnaXs/MDD1ej0GAaFMgG+LaIxkI1IZ7TaLc6 zJTg== X-Gm-Message-State: ALQs6tDCvgf+KkIZ2y4OKcVRqDL684d+x55f0ZyOECqgvpQ0t41kihsu rKS+fg5G7VWrO5stTFkM3jW6g0JhZ7V3Hm9wiiw= X-Google-Smtp-Source: AB8JxZpjaf3TR9pulmq8kjHiEvxMiNkmKPuRhf9peHaaP+oBwse9gWRS0tBcBbB+Mulb+TDE40lWL3yinERGsvz8BTE= X-Received: by 2002:a19:f203:: with SMTP id q3-v6mr3738354lfh.54.1524268001581; Fri, 20 Apr 2018 16:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.71.1 with HTTP; Fri, 20 Apr 2018 16:46:41 -0700 (PDT) In-Reply-To: References: <20180322171000.GA23594@LK-Perkele-VII> <20180322183941.GA31902@bolet.org> From: Alex C Date: Sat, 21 Apr 2018 11:46:41 +1200 Message-ID: To: Victor Vasiliev Cc: Thomas Pornin , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6e0f0056a504cff" Archived-At: Subject: Re: [TLS] potential attack on TLS cert compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 23:46:46 -0000 --000000000000c6e0f0056a504cff Content-Type: text/plain; charset="UTF-8" It seems to me that if this is a valid threat model, then all software is potentially vulnerable. TLS records are carried over TCP segments. What if an attacker can change the way records are divided into segments, and thereby trigger a bug in the record parser? On Fri, Apr 20, 2018 at 9:40 AM, Victor Vasiliev wrote: > Did we ever reach any agreement about what to do here? > > For me, the threat model here seems fairly far-fetched and infeasible, in > the sense that the threat only exists in some very specific bugs in > multithreaded decompressor. > > I'd be less reluctant to do this if it were not for the fact that all > solutions I've considered for this are quite annoying. Putting the hash on > the wire means wasting bytes, and altering the transcript hash introduces a > lot of complexity into some implementations. > > On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin wrote: >> >> Certificate compression would be challenging to implement, though. >> Usually, compression relies on at least a "window" over the decompressed >> data (32 kB for Zlib/Deflate). Some rudimentary forms of compression >> don't need that (e.g. run-length encoding) but usually offer poor >> compression ratios. A 32 kB window is a lot for the kind of architecture >> that BearSSL targets. >> > > This is roughly my intuition -- you could parse certificate messages in a > streaming manner, but if you're on a sufficiently limited platform that > this is a worthwhile investment, you're probably not going to use > certificate compression anyways. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000c6e0f0056a504cff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that if this is a valid threat model, = then all software is potentially vulnerable.

TLS records are c= arried over TCP segments. What if an attacker can change the way records ar= e divided into segments, and thereby trigger a bug in the record parser?

On Fri, Ap= r 20, 2018 at 9:40 AM, Victor Vasiliev <vasilvv@google.com>= wrote:
Did we ever reach any agreement about= what to do here?

For me, the threat model here seems fairly far-fetched and infe= asible, in the sense that the threat only exists in some very specific bugs= in multithreaded decompressor.

<= div class=3D"gmail_quote">I'd be less reluctant to do this if it were n= ot for the fact that all solutions I've considered for this are quite a= nnoying.=C2=A0 Putting the hash on the wire means wasting bytes, and alteri= ng the transcript hash introduces a lot of complexity into some implementat= ions.

= On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin <pornin@b= olet.org> wrote:
Certificate compression would be challenging to implement, though.
Usually, compression relies on at least a "window" over the decom= pressed
data (32 kB for Zlib/Deflate). Some rudimentary forms of compression
don't need that (e.g. run-length encoding) but usually offer poor
compression ratios. A 32 kB window is a lot for the kind of architecture that BearSSL targets.

This is ro= ughly my intuition -- you could parse certificate messages in a streaming m= anner, but if you're on a sufficiently limited platform that this is a = worthwhile investment, you're probably not going to use certificate com= pression anyways.

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


--000000000000c6e0f0056a504cff-- From nobody Fri Apr 20 16:48:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02E12D958 for ; Fri, 20 Apr 2018 16:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 BT6V1NlxRVIK for ; Fri, 20 Apr 2018 16:48:21 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C862127201 for ; Fri, 20 Apr 2018 16:48:21 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w3KNkVqw028489; Sat, 21 Apr 2018 00:48:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=TygN6wICON8R+Fzpvjz/GPFB9BXw3HXdAQ3hehrhqZc=; b=PlkvyWwroLf8LBADvYtYpaKTVCa75UyuE7HzuYgQJg9UVSkVGJ3yPCijM9H/51MwzeYN Aq8EUfS9eg7B7xrTeZt+Vz99k4V3KnGVnun/t6z6ttPLmPCQ3C+ETP4YAO/GIMhgOdlI UjCbC4rLcXmJhlsRgizCtOvYEGZ/yNvmIrOrb+S6dVk6oIa+b9M6pjzB8QPieu8CS6db y7KNU8D3fAOfgd4qdH9dziZ+kKb6pXYr7eldMYlfgjQ18IKsqZuZ+T+j6JNZRmRRrENP rEX5pOcdi0m9qUUrTCPeBdN1OOVriDZGaQ24REWrvj9Kk0nvCxRmCbhtmA08hYncPLlK iA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2hfkn5rw8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Apr 2018 00:48:17 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w3KNjxaw024548; Fri, 20 Apr 2018 19:48:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hbd0caq92-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Apr 2018 19:48:16 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 20 Apr 2018 16:48:15 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 20 Apr 2018 18:48:15 -0500 From: "Salz, Rich" To: Alex C , Victor Vasiliev CC: "tls@ietf.org" Thread-Topic: [TLS] potential attack on TLS cert compression Thread-Index: AQHT2CcdhfShvuqCXUyGfiC9/jUx9KQKpyyA//+9YQA= Date: Fri, 20 Apr 2018 23:48:14 +0000 Message-ID: <86365A0D-40AC-44C2-8B39-88D4CE07644B@akamai.com> References: <20180322171000.GA23594@LK-Perkele-VII> <20180322183941.GA31902@bolet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.51] Content-Type: multipart/alternative; boundary="_000_86365A0D40AC44C28B3988D4CE07644Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-20_11:, , 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=970 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804200237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-20_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=903 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804200237 Archived-At: Subject: Re: [TLS] potential attack on TLS cert compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 23:48:23 -0000 --_000_86365A0D40AC44C28B3988D4CE07644Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVExTIHJlY29yZHMgYXJlIGNhcnJpZWQgb3ZlciBUQ1Agc2VnbWVudHMuIFdoYXQgaWYg YW4gYXR0YWNrZXIgY2FuIGNoYW5nZSB0aGUgd2F5IHJlY29yZHMgYXJlIGRpdmlkZWQgaW50byBz ZWdtZW50cywgYW5kIHRoZXJlYnkgdHJpZ2dlciBhIGJ1ZyBpbiB0aGUgcmVjb3JkIHBhcnNlcj8N Cg0KV2h5IGRvIHlvdSB0aGluayB0aGlzIGlzIHBvc3NpYmxlPyAgVGhlIHNpenNlIG9mIHRoZSBy ZWNvcmQgaXMgcGFydCBvZiB3aGF04oCZcyBzZWN1cmVkLg0K --_000_86365A0D40AC44C28B3988D4CE07644Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <616C5DD4C0D7D64AB7C7F2FB8E002BA8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MTM0NjM5NjsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0NzU1ODg1NTIgLTIxMjk3NTM2NTQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo1 OTA3Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNp LWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PGEgbmFtZT0iX01h aWxPcmlnaW5hbEJvZHkiPlRMUyByZWNvcmRzIGFyZSBjYXJyaWVkIG92ZXIgVENQIHNlZ21lbnRz LiBXaGF0IGlmIGFuIGF0dGFja2VyIGNhbiBjaGFuZ2UgdGhlIHdheSByZWNvcmRzIGFyZSBkaXZp ZGVkIGludG8gc2VnbWVudHMsIGFuZCB0aGVyZWJ5IHRyaWdnZXIgYSBidWcgaW4gdGhlIHJlY29y ZA0KIHBhcnNlcj88bzpwPjwvbzpwPjwvYT48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+V2h5IGRvIHlvdSB0aGluayB0aGlz IGlzIHBvc3NpYmxlPyZuYnNwOyBUaGUgc2l6c2Ugb2YgdGhlIHJlY29yZCBpcyBwYXJ0IG9mIHdo YXTigJlzIHNlY3VyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_86365A0D40AC44C28B3988D4CE07644Bakamaicom_-- From nobody Sat Apr 21 07:25:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE921270B4 for ; Sat, 21 Apr 2018 07:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5ZObfxS00sW for ; Sat, 21 Apr 2018 07:25:23 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7AE1270AE for ; Sat, 21 Apr 2018 07:25:23 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s78so11588472qkl.8 for ; Sat, 21 Apr 2018 07:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NzYnhaXEUUPiSGO4XxBGtjc/U/k4gBpPpFRq70ClFsY=; b=fnyVqoq/LCOIdgpBcWrEMLy6RHORXc5+ChCa78KPsgOn8Xq7IsxiSzGkSvX4oJz/mQ nfG+l1IcbBSoU6xVUbg219VCXan7lG+tXuz+3k8ggLvlPhFzL5fkeHPdfnHRIduvvB7K ojg/kuUAunM6RTjW5yGrLd8mmbbMjy9EUuoko= 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=NzYnhaXEUUPiSGO4XxBGtjc/U/k4gBpPpFRq70ClFsY=; b=A8JUZmjKBPLSvOWwVL+l/5gNh+Ht3gL4pzxnA4KQbSJsG6IC5azFCIR4WCwgdjAosN /oun0pkWDV5G1UsqT21WvMHNprAMehG7xy56vRxWPnjgDKI0jDggsTyD1yr5pqK+k9cQ JnTf4OmbXAcDlTAXE4zKN+3P24lX3MIs5VCsR257MSd6WwPISzaGaV+OJ9qhtq2/RuxS noZ/NjsOeTnccXTJ0XsunHkeUYWmi83CZNpWGLXuUGpskN5H+SxnQ6L3wflNV+DM6VZ8 8/mghpo+rdWPYtp63QZdxVhnhKhlvrRc7F20Cu7d3A6UcpsZgzcXnSLWggaTTOg92xQa npHg== X-Gm-Message-State: ALQs6tB5PcpSRWpc0AOajTN2wfYqRHpYgBHJuZW0f7OhAzrVlJCUty69 sphnbvisHLPJtB8sJnaOtOw2ydZBd5Q= X-Google-Smtp-Source: AB8JxZrjyT1gyDHBL+reJhzF4lHZYW1KEk23vWPg5/tl4fpKV/qcfxGhwgzu/FoSYO1xWgXn74TW3w== X-Received: by 10.55.172.6 with SMTP id e6mr5982011qkm.360.1524320722290; Sat, 21 Apr 2018 07:25:22 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id j1-v6sm7488075qtc.53.2018.04.21.07.25.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 07:25:21 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sat, 21 Apr 2018 10:25:20 -0400 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> To: TLS WG In-Reply-To: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> Message-Id: <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 14:25:25 -0000 > On Apr 19, 2018, at 16:32, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the "Exported Authenticators = in TLS" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. = Please review the document and send your comments to the list by 2359 = UTC on 4 April 2018. =E2=80=A6 4 May 2018 ...= From nobody Mon Apr 23 02:02:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BFA127241 for ; Mon, 23 Apr 2018 02:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 AP2hMO4pfbRd for ; Mon, 23 Apr 2018 02:02:03 -0700 (PDT) Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BBE120713 for ; Mon, 23 Apr 2018 02:02:02 -0700 (PDT) Received: by mail-wr0-f170.google.com with SMTP id v15-v6so20887812wrm.10 for ; Mon, 23 Apr 2018 02:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ys1LlnAdhYV6zIWFwlGWtTthoIyF63M78ThC+PJ/qlM=; b=oxhGtLz/ovYz7GctpSwbHPvh0xkIboYkzUm80XuWELiRMnEzb6zc/8iomeWz4q/1gF A+f5mPlEP+riSVLeKlPrtL9rFJRIwOAoMWRLQFTvQG68jbDm6xxBOXmkVLnNyqhtqxLH H4rMqS3RdTqWPhpAeZSpOnksWXjofUebxM+fuGDASOsAuLn1ZLicScuS89h7RVXTV4MW nes4Mosx5QVxfV7TOlgqzbR76423tD1pg+sqlA/dAgdGA1XZDrSE6buY7iZLaQOQB7Y+ 8s1+f4IdJH4uxImIBfO+SUGMUPRLB5nLfGIHEDcnqqRHhW+yq1h5eXGx+8A2dIwdbN2c O0tA== X-Gm-Message-State: ALQs6tBTF1Fg6GXDL/kEi2ChTlnF3RuQlpp4e68otEP2MEcttOGFsvyr K9FJIZdtU0laEjsmODZ7tZ+5y+sAvfU= X-Google-Smtp-Source: AIpwx49YcI12oWgIQMGz5fd8Vpi9eRAuSabpR8Ko7vpeIqL/2DoFLNxAdM07efM6iVH7Pnvw20PczQ== X-Received: by 10.28.46.208 with SMTP id u199mr8388714wmu.99.1524474121224; Mon, 23 Apr 2018 02:02:01 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id u138sm10662088wmu.24.2018.04.23.02.02.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Apr 2018 02:02:00 -0700 (PDT) Message-ID: <1524474119.4793.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley , IETF TLS Date: Mon, 23 Apr 2018 11:01:59 +0200 In-Reply-To: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> References: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 09:02:05 -0000 On Wed, 2018-04-18 at 12:25 -0400, Russ Housley wrote: > In London, I was on the agenda to talk about certificate-based > authentication with external pre-shared key (PSK). We ran out of > time, and I did not get to make the presentation. The slides are in > the proceedings; see https://datatracker.ietf.org/meeting/101/materia > ls/slides-101-tls-sessa-certificate-based-authentication-with- > external-psk-00. > > Please review the document and send comments to the list. > > I would like the TLS WG to adopt this document. In the presentation the main driver for it seems to be quantum computer resistance as temporary measure. If that's the main argument I don't think it is really significant. PSK can hardly be used with PKI, and as a matter of fact we use PKI because of PSK key distribution problems. If we switch to PSK for quantum computer resistance there is there a reason to use PKI? Probably no (I may be wrong here, if there is a reason for a hubrid model I'm missing, I'd be glad to know). I could see the main driver for such proposal the replacement of the RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not sure whether that is significant to require update to TLS1.3. On the implementation side, why not use post-handshake authentication here? I.e., extend it to be usable from client-side, and on a PSK key exchange, have the client request server authentication after the handshake? regards, Nikos From nobody Mon Apr 23 04:45:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF042126CC4 for ; Mon, 23 Apr 2018 04:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9fQutmxrlTJD for ; Mon, 23 Apr 2018 04:45:38 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BE2124D6C for ; Mon, 23 Apr 2018 04:45:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7AF92406C791 for ; Mon, 23 Apr 2018 11:45:37 +0000 (UTC) Received: from localhost.localdomain (unknown [10.43.21.161]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C8FC2026DFD for ; Mon, 23 Apr 2018 11:45:34 +0000 (UTC) Message-ID: From: Daiki Ueno To: tls@ietf.org Date: Mon, 23 Apr 2018 13:45:34 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 23 Apr 2018 11:45:37 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 23 Apr 2018 11:45:37 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dueno@redhat.com' RCPT:'' Archived-At: Subject: [TLS] psk_key_exchange_mode question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 11:45:40 -0000 Hello, I have a question about handling the psk_key_exchange_mode extension. 4.2.9. Pre-Shared Key Exchange Modes says: This extension also restricts the modes for use with PSK resumption; servers SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes Is this compatibility defined externally to the protocol, or does it depend on the initial handshake? To take an example, suppose the server uses the ticket construction mechanism described in RFC 5077. If the former is the case, the server requires PSK with (EC)DHE when the ticket encryption key is required to be forward secret. From the implementation point of view, that would be provided as an option in the server configuration. On the other hand, if the latter is the case, the server requires PSK with (EC)DHE when the initial handshake chose (EC)DHE key exchange, because the ticket is tied to resumption_master_secret derived from the (EC)DHE secret. Since the above paragraph is followed by: however, if a server does so, the impact will just be that the client=E2=80=99s attempts at resumption fail. I thought the latter is more plausible; however, in that case psk_ke would only be meaningful when the initial handshake is PSK-only. Regards, --=20 Daiki Ueno From nobody Mon Apr 23 09:10:00 2018 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 DE55F12D7EA; Mon, 23 Apr 2018 09:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152449979388.21797.5969505080408346422@ietfa.amsl.com> Date: Mon, 23 Apr 2018 09:09:53 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 16:09:54 -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 : Transport Layer Security (TLS) Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-03.txt Pages : 7 Date : 2018-04-23 Abstract: In Transport Layer Security (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-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 23 09:33:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF712D7F1 for ; Mon, 23 Apr 2018 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMR5rpDp5YYg for ; Mon, 23 Apr 2018 09:33:12 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BDC12D7E5 for ; Mon, 23 Apr 2018 09:33:12 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v2so16751240qkh.10 for ; Mon, 23 Apr 2018 09:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=iAYItgwP6AZFjcirV8Nj0yCjikRTQHFM4PAftu0hYJ4=; b=hh7Mz/Wwo4bwrzrRQui0oKldOLtZ/x7b2XYNSiIJr+5FyCvsQzkdCOU9i2gPM0cfkp d9yncH78Jxdfxj1Xsi75W/AILzOkW747rsbyySjKm7il7vvTRSUkN6nX6E+JLYpR/2rk vrH0bajE57W5G+qBw7fKbjXhHYGCOOdE/ssOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=iAYItgwP6AZFjcirV8Nj0yCjikRTQHFM4PAftu0hYJ4=; b=oW5tJQ7fC6tNIeqwhKAYWRr+hdsB20xyYOY6QGoERnedCsYNY6YQl4sVcCX3TJ9ghk ZKsLjWHLyMK/3eipRH5iboPTBMdjT3Z0wD23+++ZZ2wswmg+IiMV3QuUt86YpHgDiWSy 7mCSNAwNar6AEag+XPYZMLLgnberoRK5eH/2iyMJNyQIAo2DjSbRI/pNY3mq+QEAlIcD AwErF2lIFAclvvB2mA07bcIH5Qk5DFfI6YBLZkHlp9ww34CAgJLjrqYG6RitnmvigoSG 1vLxxlF7QlIjLsNZUAMHeADo5U6Ao/9G773izSZOCyhiMDnMxsVa/QYK7cyZXaKbfcUA +nvA== X-Gm-Message-State: ALQs6tCAbzqpLqKmXI2oSjdCPmQFPwUhFHs7MzB1WL1JN4P3nIHfSGrI 8XP2ajwOphwbeLz69+11MIYOxxGNrYs= X-Google-Smtp-Source: AB8JxZobQ5MLjA7kdO2caXGIm7AQHoMxPoi0OqZTFElT5t6NrTFRkGM/vkG3mX/GvrO8R36/FY0v0A== X-Received: by 10.55.138.196 with SMTP id m187mr14488840qkd.119.1524501191020; Mon, 23 Apr 2018 09:33:11 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id l70sm11282405qkl.13.2018.04.23.09.33.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 09:33:10 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> Date: Mon, 23 Apr 2018 12:33:08 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] early code point assignment for draft-ietf-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:33:14 -0000 All, tl;dr: If you object to the following early code point assignments 1) = add the compress_certificate in the TLS ExtensionType Registry and 2) = compressed_certificate in the TLS HandshakeType Registry, then please = let the list know why by 2359UTC on 10 May 2018. The Certificate = Compression Algorithm IDs will be populated with two values: zlib and = brotli. At IETF101, we discussed beginning the process of getting an early code = point assignment for the extension defined in = draft-ietf-tls-certificate-compression. The one technical comments = raised at the meeting was extending the compression code point space = from 1 byte to 2 might be a good idea. The authors have merged a PR to = address this in the gh repo and once they submit a new version of the = draft the process for an early code point assignment will begin. The = rules for this are specified in RFC7120, and the four criteria for a = draft to be eligible for early code point assignment are: Criteria A The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. The Transport Layer Security (TLS) Extensions and TLS HandshakeType = Registry registries are both RFC Required. While we=E2=80=99re changing = that registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, = there=E2=80=99s still every intention to publish = draft-ietf-tls-certificate-compression as an RFC so we=E2=80=99re still = good to go. Criteria B The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. When asked at IETF101 what other outstanding comments there were on the = draft the only one identified was increasing the code point size for the = compression algorithms. Version -05 will address this point. Criteria C The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. At IETF101, it was noted that this specification was stable enough. = Implementation issues might be identifier later, but, well, that=E2=80=99s= the point. Criteria D The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. 5 WG participants all from different organizations indicated their = interest in implementing this draft (even if it was just for = experimentation). There are also 6 steps identified in RFC 7120 for early assignment, but = only four involve the chairs: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. An in-person request was made at IETF 101 for the early code point = assignments. There was also an earlier on-list request. 2. The WG chairs determine whether the conditions for early allocations described in Section 2 are met, particularly conditions (c) and (d). The chairs agree that the four conditions have been met. 3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate for the given document. The sense of the room at IETF 101 was that yes early allocation is = appropriate, but this email is verifying that. 4. If steps 2) and 3) are satisfied, the WG chairs request approval from the Area Director(s). The Area Director(s) may apply judgement to the request, especially if there is a risk of registry depletion. Once the chairs have determined WG consensus, we=E2=80=99ll pass it to = Ben. spt= From nobody Mon Apr 23 09:51:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09A12D87D for ; Mon, 23 Apr 2018 09:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_RHS_DOB=1.514] autolearn=no 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 M-NTsYs9trU0 for ; Mon, 23 Apr 2018 09:51:00 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0209412D87B for ; Mon, 23 Apr 2018 09:51:00 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id v64-v6so17977662otb.13 for ; Mon, 23 Apr 2018 09:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=emWTsO0hlm6LqT9W232kVikA4RwbZ7z9oG+AVgC7yxk=; b=lSuDypxqlqHkclbiHKy5dlFI844thxLx6ymYv8pGmp2Ni8j35bhdFdw2MD/epXI8To 942LZRq3QNCvc8eFwTUGX7JYWEjIhQ4IWRbqwEPhVuNRqCmiIFc7eJVCUJW/qhKNDqii 5SSwsKy8IthqIr+jYT19ms4cH2xZPNclXQ5fMvm/mRTqEhzSiSAQNqH66kYloj3P260t sq1sf85bznMbnRfGXGqb2reqFMLq+Q4b9IkNhZ2sQ75rXTFu9mncS/OsEylUcdmJofpt 1CTPbDVZ7yPloVGRm352Gh8+5X1HcYGwfPEQFIywXOVcvvRQdQZr1kaz1QC/a4qJn1Sm oOKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=emWTsO0hlm6LqT9W232kVikA4RwbZ7z9oG+AVgC7yxk=; b=mbnLIj1F6ZXNqo/8hgjawx/fvPkfH+xnn2BOJyTbnoEs7aeZKmXrrjoyyw5LGaCu7d LOx4qqXoLNf4XgVOlS8GFSmcXeEbaLo6SdTgNmXBvHQRTpwOYFmUbR7E+H/ndQ4vcMpv Lm32cvwO41zqAc49zKQBw9bdWBNRlJmkyM5ULboEwyRogZCFaXIo4azFr/fwf89tXOqr vIWZDm1pbE78QhBrla616sSlltCsNrCrzEa5JQc+IkVZP47GAqceydIgjFQGEZEYevUg 7UY8YCpvvAXjM0Zj70aGi35oh0dw65rUAlkrAykiDscS7A7zTdUWMHpI2/eR3JOtV9Oy eU6A== X-Gm-Message-State: ALQs6tApw6ru3dFWjMOjumE8TyhF/l+la51nN2FbDHv0DvbK8rjtMewZ UwhAahqNIbQhkfEMsIx9emqCU9vs3rqUbyJjrNqqKCGg X-Google-Smtp-Source: AB8JxZryOXHc0znv+NE74pGEI1WJYnrJqMkKWZYWsoFXmduCS0dkHJIUIkRFsWJXi6d0OdEisBSw0A+2f63YAmTmz0o= X-Received: by 2002:a9d:334f:: with SMTP id u15-v6mr2854450otd.214.1524502259216; Mon, 23 Apr 2018 09:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Mon, 23 Apr 2018 09:50:18 -0700 (PDT) In-Reply-To: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> From: Eric Rescorla Date: Mon, 23 Apr 2018 09:50:18 -0700 Message-ID: To: Sean Turner Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000009edc18056a86d758" Archived-At: Subject: Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 16:51:02 -0000 --0000000000009edc18056a86d758 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote: > All, > > tl;dr: If you object to the following early code point assignments 1) add > the compress_certificate in the TLS ExtensionType Registry and 2) > compressed_certificate in the TLS HandshakeType Registry, then please let > the list know why by 2359UTC on 10 May 2018. The Certificate Compression > Algorithm IDs will be populated with two values: zlib and brotli. > > At IETF101, we discussed beginning the process of getting an early code > point assignment for the extension defined in draft-ietf-tls-certificate-= compression. > The one technical comments raised at the meeting was extending the > compression code point space from 1 byte to 2 might be a good idea. The > authors have merged a PR to address this in the gh repo and once they > submit a new version of the draft the process for an early code point > assignment will begin. The rules for this are specified in RFC7120, and > the four criteria for a draft to be eligible for early code point > assignment are: > > Criteria A > > The code points must be from a space designated as "RFC > Required", "IETF Review", or "Standards Action". Additionally, > requests for early assignment of code points from a > "Specification Required" registry are allowed if the > specification will be published as an RFC. > > The Transport Layer Security (TLS) Extensions and TLS HandshakeType > Registry registries are both RFC Required. While we=E2=80=99re changing = that > registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, there= =E2=80=99s still > every intention to publish draft-ietf-tls-certificate-compression as an > RFC so we=E2=80=99re still good to go. > > Criteria B > > The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet-Draft. > > When asked at IETF101 what other outstanding comments there were on the > draft the only one identified was increasing the code point size for the > compression algorithms. Version -05 will address this point. > > Criteria C > > The specifications of these code points must be stable; i.e., if > there is a change, implementations based on the earlier and later > specifications must be seamlessly interoperable. > > At IETF101, it was noted that this specification was stable enough. > Implementation issues might be identifier later, but, well, that=E2=80=99= s the > point. > > Criteria D > > The Working Group chairs and Area Directors (ADs) judge that > there is sufficient interest in the community for early (pre-RFC) > implementation and deployment, or that failure to make an early > allocation might lead to contention for the code point in the > field. > > 5 WG participants all from different organizations indicated their > interest in implementing this draft (even if it was just for > experimentation). > > > There are also 6 steps identified in RFC 7120 for early assignment, but > only four involve the chairs: > > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > > An in-person request was made at IETF 101 for the early code point > assignments. There was also an earlier on-list request. > > 2. The WG chairs determine whether the conditions for early > allocations described in Section 2 are met, particularly > conditions (c) and (d). > > The chairs agree that the four conditions have been met. > > 3. The WG chairs gauge whether there is consensus within the WG that > early allocation is appropriate for the given document. > > The sense of the room at IETF 101 was that yes early allocation is > appropriate, but this email is verifying that. > > 4. If steps 2) and 3) are satisfied, the WG chairs request approval > from the Area Director(s). The Area Director(s) may apply > judgement to the request, especially if there is a risk of > registry depletion. > > Once the chairs have determined WG consensus, we=E2=80=99ll pass it to Be= n. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009edc18056a86d758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner = <sean@sn3rd.com&= gt; wrote:
All,

tl;dr: If you object to the following early code point assignments 1) add t= he compress_certificate in the TLS ExtensionType Registry and 2) compressed= _certificate in the TLS HandshakeType Registry, then please let the list kn= ow why by 2359UTC on 10 May 2018.=C2=A0 The Certificate Compression Algorit= hm IDs will be populated with two values: zlib and brotli.

At IETF101, we discussed beginning the process of getting an early code poi= nt assignment for the extension defined in draft-ietf-tls-certificate-= compression.=C2=A0 The one technical comments raised at the meeting was ext= ending the compression code point space from 1 byte to 2 might be a good id= ea.=C2=A0 The authors have merged a PR to address this in the gh repo and o= nce they submit a new version of the draft the process for an early code po= int assignment will begin.=C2=A0 The rules for this are specified in RFC712= 0, and the four criteria for a draft to be eligible for early code point as= signment are:

Criteria A

=C2=A0 =C2=A0 =C2=A0 =C2=A0The code points must be from a space designated = as "RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review", or &quo= t;Standards Action".=C2=A0 Additionally,
=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code points fro= m a
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" registry are = allowed if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RFC.

The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registr= y registries are both RFC Required.=C2=A0 While we=E2=80=99re changing that= registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, t= here=E2=80=99s still every intention to publish draft-ietf-tls-certificate-= compression as an RFC so we=E2=80=99re still good to go.

Criteria B

=C2=A0 =C2=A0 =C2=A0 =C2=A0The format, semantics, processing, and other rul= es related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0handling the protocol entities defined by the co= de points
=C2=A0 =C2=A0 =C2=A0 =C2=A0(henceforth called "specifications") m= ust be adequately described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in an Internet-Draft.

When asked at IETF101 what other outstanding comments there were on the dra= ft the only one identified was increasing the code point size for the compr= ession algorithms.=C2=A0 Version -05 will address this point.

Criteria C

=C2=A0 =C2=A0 =C2=A0 =C2=A0The specifications of these code points must be = stable; i.e., if
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is a change, implementations based on the = earlier and later
=C2=A0 =C2=A0 =C2=A0 =C2=A0specifications must be seamlessly interoperable.=

At IETF101, it was noted that this specification was stable enough.=C2=A0 I= mplementation issues might be identifier later, but, well, that=E2=80=99s t= he point.

Criteria D

=C2=A0 =C2=A0 =C2=A0 =C2=A0The Working Group chairs and Area Directors (ADs= ) judge that
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is sufficient interest in the community fo= r early (pre-RFC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0implementation and deployment, or that failure t= o make an early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation might lead to contention for the code= point in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0field.

5 WG participants all from different organizations indicated their interest= in implementing this draft (even if it was just for experimentation).


There are also 6 steps identified in RFC 7120 for early assignment, but onl= y four involve the chairs:

=C2=A0 1.=C2=A0 The authors (editors) of the document submit a request for = early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation to the Working Group chairs, specifyi= ng which code
=C2=A0 =C2=A0 =C2=A0 =C2=A0points require early allocation and to which doc= ument they should
=C2=A0 =C2=A0 =C2=A0 =C2=A0be assigned.

An in-person request was made at IETF 101 for the early code point assignme= nts.=C2=A0 There was also an earlier on-list request.

=C2=A0 =C2=A02.=C2=A0 The WG chairs determine whether the conditions for ea= rly
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocations described in Section 2 are met, part= icularly
=C2=A0 =C2=A0 =C2=A0 =C2=A0conditions (c) and (d).

The chairs agree that the four conditions have been met.

=C2=A0 =C2=A03.=C2=A0 The WG chairs gauge whether there is consensus within= the WG that
=C2=A0 =C2=A0 =C2=A0 =C2=A0early allocation is appropriate for the given do= cument.

The sense of the room at IETF 101 was that yes early allocation is appropri= ate, but this email is verifying that.

=C2=A0 =C2=A04.=C2=A0 If steps 2) and 3) are satisfied, the WG chairs reque= st approval
=C2=A0 =C2=A0 =C2=A0 =C2=A0from the Area Director(s).=C2=A0 The Area Direct= or(s) may apply
=C2=A0 =C2=A0 =C2=A0 =C2=A0judgement to the request, especially if there is= a risk of
=C2=A0 =C2=A0 =C2=A0 =C2=A0registry depletion.

Once the chairs have determined WG consensus, we=E2=80=99ll pass it to Ben.=

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

--0000000000009edc18056a86d758-- From nobody Mon Apr 23 11:47:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3714612D810 for ; Mon, 23 Apr 2018 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 6PvLzNyIH7L7 for ; Mon, 23 Apr 2018 11:47:01 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9554126C0F for ; Mon, 23 Apr 2018 11:47:00 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h2-v6so6858038qtp.7 for ; Mon, 23 Apr 2018 11:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=22aqZRv5ZXeeTvgYtqfqy5nXlW0lcSNc2QKGbMDDyhU=; b=i8123MlKJLRXREQznuAd9KLdpO2OCXGV+WfXu1k5ZSneWcE7g3R1pcMhiGpPdhTmEx QrU3zmsxxURv58gIVFH/F5Ob9rn95+gueZwxGKD8M//0SAC+cRibWiZv9ejnSx86nbde XKvYJBPyLH3DTy2Iy/mD7pd6VyRX+DXMw/4aE= 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=22aqZRv5ZXeeTvgYtqfqy5nXlW0lcSNc2QKGbMDDyhU=; b=sS1sBAH8lLOsu9xyY3bTWgivB2MT9bxbfDJXq1EUmvgDxQZpf3ruX6baQyVpW31RVF WduzAPpX7/Ctw4bvgHKx0wwWKCofu8H59yeq66OuyH4OKtUKMxIZFP4bnyTkiWOmmuWK RgDJd3hKQbP7/OCH2L23G0sL9TLInNmfRt9U5AWhhEVa20KMY8F3bPdEYTg0PFBlfJcR 8XKadplQohOuyP2xBJaScoEWj0BZuaBumKgiE6Fi0G0zl/8Zk+ECiXBVc4CkE0wFq28s CCj6kanCqoHQwwz9g+Y/JxOuQX1nI1uLIvpnTAYuj0Fpe63hs4/sid4MEXDrfxSE6p+U dNEw== X-Gm-Message-State: ALQs6tBHA6bF+o155Fp3PzZGaf7O+mIkFFulCbRnuEBjK0R3jpD37uDE DJ2sVH8c/C7RmxjtzZdMckek8neEvNXY51uc8wjRLSo= X-Google-Smtp-Source: AIpwx4+i/m5W/f780Y/qR/fw688ClNdBQgWWcLVfqSOMRioeBCufvEhvz8PqiQxh/Id8pZFTsMA75HKufW933iE6XYc= X-Received: by 2002:ac8:3f72:: with SMTP id w47-v6mr24648199qtk.318.1524509219739; Mon, 23 Apr 2018 11:46:59 -0700 (PDT) MIME-Version: 1.0 References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> In-Reply-To: From: David Benjamin Date: Mon, 23 Apr 2018 18:46:49 +0000 Message-ID: To: Eric Rescorla Cc: Sean Turner , TLS WG Content-Type: multipart/alternative; boundary="000000000000805f7c056a887694" Archived-At: Subject: Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 18:47:03 -0000 --000000000000805f7c056a887694 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla wrote: > +1 > > On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote: > >> All, >> >> tl;dr: If you object to the following early code point assignments 1) ad= d >> the compress_certificate in the TLS ExtensionType Registry and 2) >> compressed_certificate in the TLS HandshakeType Registry, then please le= t >> the list know why by 2359UTC on 10 May 2018. The Certificate Compressio= n >> Algorithm IDs will be populated with two values: zlib and brotli. >> >> At IETF101, we discussed beginning the process of getting an early code >> point assignment for the extension defined in >> draft-ietf-tls-certificate-compression. The one technical comments rais= ed >> at the meeting was extending the compression code point space from 1 byt= e >> to 2 might be a good idea. The authors have merged a PR to address this= in >> the gh repo and once they submit a new version of the draft the process = for >> an early code point assignment will begin. The rules for this are >> specified in RFC7120, and the four criteria for a draft to be eligible f= or >> early code point assignment are: >> >> Criteria A >> >> The code points must be from a space designated as "RFC >> Required", "IETF Review", or "Standards Action". Additionally, >> requests for early assignment of code points from a >> "Specification Required" registry are allowed if the >> specification will be published as an RFC. >> >> The Transport Layer Security (TLS) Extensions and TLS HandshakeType >> Registry registries are both RFC Required. While we=E2=80=99re changing= that >> registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, ther= e=E2=80=99s still >> every intention to publish draft-ietf-tls-certificate-compression as an = RFC >> so we=E2=80=99re still good to go. >> >> Criteria B >> >> The format, semantics, processing, and other rules related to >> handling the protocol entities defined by the code points >> (henceforth called "specifications") must be adequately described >> in an Internet-Draft. >> >> When asked at IETF101 what other outstanding comments there were on the >> draft the only one identified was increasing the code point size for the >> compression algorithms. Version -05 will address this point. >> >> Criteria C >> >> The specifications of these code points must be stable; i.e., if >> there is a change, implementations based on the earlier and later >> specifications must be seamlessly interoperable. >> >> At IETF101, it was noted that this specification was stable enough. >> Implementation issues might be identifier later, but, well, that=E2=80= =99s the >> point. >> >> Criteria D >> >> The Working Group chairs and Area Directors (ADs) judge that >> there is sufficient interest in the community for early (pre-RFC) >> implementation and deployment, or that failure to make an early >> allocation might lead to contention for the code point in the >> field. >> >> 5 WG participants all from different organizations indicated their >> interest in implementing this draft (even if it was just for >> experimentation). >> >> >> There are also 6 steps identified in RFC 7120 for early assignment, but >> only four involve the chairs: >> >> 1. The authors (editors) of the document submit a request for early >> allocation to the Working Group chairs, specifying which code >> points require early allocation and to which document they should >> be assigned. >> >> An in-person request was made at IETF 101 for the early code point >> assignments. There was also an earlier on-list request. >> >> 2. The WG chairs determine whether the conditions for early >> allocations described in Section 2 are met, particularly >> conditions (c) and (d). >> >> The chairs agree that the four conditions have been met. >> >> 3. The WG chairs gauge whether there is consensus within the WG that >> early allocation is appropriate for the given document. >> >> The sense of the room at IETF 101 was that yes early allocation is >> appropriate, but this email is verifying that. >> >> 4. If steps 2) and 3) are satisfied, the WG chairs request approval >> from the Area Director(s). The Area Director(s) may apply >> judgement to the request, especially if there is a risk of >> registry depletion. >> >> Once the chairs have determined WG consensus, we=E2=80=99ll pass it to B= en. >> >> spt >> _______________________________________________ >> 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 > --000000000000805f7c056a887694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On M= on, Apr 23, 2018 at 12:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
+1

On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <= ;sean@sn3rd.com>= wrote:
All,

tl;dr: If you object to the following early code point assignments 1) add t= he compress_certificate in the TLS ExtensionType Registry and 2) compressed= _certificate in the TLS HandshakeType Registry, then please let the list kn= ow why by 2359UTC on 10 May 2018.=C2=A0 The Certificate Compression Algorit= hm IDs will be populated with two values: zlib and brotli.

At IETF101, we discussed beginning the process of getting an early code poi= nt assignment for the extension defined in draft-ietf-tls-certificate-compr= ession.=C2=A0 The one technical comments raised at the meeting was extendin= g the compression code point space from 1 byte to 2 might be a good idea.= =C2=A0 The authors have merged a PR to address this in the gh repo and once= they submit a new version of the draft the process for an early code point= assignment will begin.=C2=A0 The rules for this are specified in RFC7120, = and the four criteria for a draft to be eligible for early code point assig= nment are:

Criteria A

=C2=A0 =C2=A0 =C2=A0 =C2=A0The code points must be from a space designated = as "RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review", or &quo= t;Standards Action".=C2=A0 Additionally,
=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code points fro= m a
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" registry are = allowed if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RFC.

The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registr= y registries are both RFC Required.=C2=A0 While we=E2=80=99re changing that= registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, there= =E2=80=99s still every intention to publish draft-ietf-tls-certificate-comp= ression as an RFC so we=E2=80=99re still good to go.

Criteria B

=C2=A0 =C2=A0 =C2=A0 =C2=A0The format, semantics, processing, and other rul= es related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0handling the protocol entities defined by the co= de points
=C2=A0 =C2=A0 =C2=A0 =C2=A0(henceforth called "specifications") m= ust be adequately described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in an Internet-Draft.

When asked at IETF101 what other outstanding comments there were on the dra= ft the only one identified was increasing the code point size for the compr= ession algorithms.=C2=A0 Version -05 will address this point.

Criteria C

=C2=A0 =C2=A0 =C2=A0 =C2=A0The specifications of these code points must be = stable; i.e., if
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is a change, implementations based on the = earlier and later
=C2=A0 =C2=A0 =C2=A0 =C2=A0specifications must be seamlessly interoperable.=

At IETF101, it was noted that this specification was stable enough.=C2=A0 I= mplementation issues might be identifier later, but, well, that=E2=80=99s t= he point.

Criteria D

=C2=A0 =C2=A0 =C2=A0 =C2=A0The Working Group chairs and Area Directors (ADs= ) judge that
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is sufficient interest in the community fo= r early (pre-RFC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0implementation and deployment, or that failure t= o make an early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation might lead to contention for the code= point in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0field.

5 WG participants all from different organizations indicated their interest= in implementing this draft (even if it was just for experimentation).


There are also 6 steps identified in RFC 7120 for early assignment, but onl= y four involve the chairs:

=C2=A0 1.=C2=A0 The authors (editors) of the document submit a request for = early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation to the Working Group chairs, specifyi= ng which code
=C2=A0 =C2=A0 =C2=A0 =C2=A0points require early allocation and to which doc= ument they should
=C2=A0 =C2=A0 =C2=A0 =C2=A0be assigned.

An in-person request was made at IETF 101 for the early code point assignme= nts.=C2=A0 There was also an earlier on-list request.

=C2=A0 =C2=A02.=C2=A0 The WG chairs determine whether the conditions for ea= rly
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocations described in Section 2 are met, part= icularly
=C2=A0 =C2=A0 =C2=A0 =C2=A0conditions (c) and (d).

The chairs agree that the four conditions have been met.

=C2=A0 =C2=A03.=C2=A0 The WG chairs gauge whether there is consensus within= the WG that
=C2=A0 =C2=A0 =C2=A0 =C2=A0early allocation is appropriate for the given do= cument.

The sense of the room at IETF 101 was that yes early allocation is appropri= ate, but this email is verifying that.

=C2=A0 =C2=A04.=C2=A0 If steps 2) and 3) are satisfied, the WG chairs reque= st approval
=C2=A0 =C2=A0 =C2=A0 =C2=A0from the Area Director(s).=C2=A0 The Area Direct= or(s) may apply
=C2=A0 =C2=A0 =C2=A0 =C2=A0judgement to the request, especially if there is= a risk of
=C2=A0 =C2=A0 =C2=A0 =C2=A0registry depletion.

Once the chairs have determined WG consensus, we=E2=80=99ll pass it to Ben.=

spt
_______________________________________________
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
--000000000000805f7c056a887694-- From nobody Mon Apr 23 12:31:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F4512D93F for ; Mon, 23 Apr 2018 12:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NUWa0jesQVq for ; Mon, 23 Apr 2018 12:30:56 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C32126B6E for ; Mon, 23 Apr 2018 12:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7AB1D300A0C for ; Mon, 23 Apr 2018 15:30:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W3TLoR40vV8h for ; Mon, 23 Apr 2018 15:30:53 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 480F4300434; Mon, 23 Apr 2018 15:30:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1524474119.4793.7.camel@redhat.com> Date: Mon, 23 Apr 2018 15:30:54 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> <1524474119.4793.7.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Apr 2018 19:30:58 -0000 > On Apr 23, 2018, at 5:01 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Wed, 2018-04-18 at 12:25 -0400, Russ Housley wrote: >> In London, I was on the agenda to talk about certificate-based >> authentication with external pre-shared key (PSK). We ran out of >> time, and I did not get to make the presentation. The slides are in >> the proceedings; see https://datatracker.ietf.org/meeting/101/materia >> ls/slides-101-tls-sessa-certificate-based-authentication-with- >> external-psk-00. >>=20 >> Please review the document and send comments to the list. >>=20 >> I would like the TLS WG to adopt this document. >=20 > In the presentation the main driver for it seems to be quantum = computer > resistance as temporary measure. If that's the main argument I don't > think it is really significant. PSK can hardly be used with PKI, and = as > a matter of fact we use PKI because of PSK key distribution problems. > If we switch to PSK for quantum computer resistance there is there a > reason to use PKI? Probably no (I may be wrong here, if there is a > reason for a hubrid model I'm missing, I'd be glad to know). I am not advocating for a pairwise PSK between every client and server. = If that were available to us, then as you say, we would always use the = PSK without any PKI. I envision a PSK being distributed to a group of clients and group of = severs. At some point in the future a large-scale quantum computer = might get invented, and if any member of the group has access to it, = then they can recover the traffic. However, parties outside the group = cannot recover the traffic because the large-scale quantum computer does = not assist with the discovery of the PSK. > I could see the main driver for such proposal the replacement of the > RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not > sure whether that is significant to require update to TLS1.3. This is not my goal. > On the implementation side, why not use post-handshake authentication > here? I.e., extend it to be usable from client-side, and on a PSK key > exchange, have the client request server authentication after the > handshake? I'm not sure why that is easier to implement. Can you say more? Russ From nobody Mon Apr 23 20:20:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0F8126D73 for ; Mon, 23 Apr 2018 20:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aviGfqEhuS8i for ; Mon, 23 Apr 2018 20:20:47 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE2212420B for ; Mon, 23 Apr 2018 20:20:46 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v132-v6so551886ywc.6 for ; Mon, 23 Apr 2018 20:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Snf/2iwNsJT7L/wduP0LNZQuCBReVOQEpdjpGfoN7ow=; b=nhUg8hTWIzch/dBzv99LZqOQ42z9GX8t1CywXPK7RVdAg29PYbcTaMPAFcYmcqR1Qa otA7zY/Rt+6OpQ4ZfQKFaK0IAvGYsXZluLcwmyUwEg3WELo3VPzkhQohJj0aMqZ3qC5D r7tSRptWfNHntDj60WFHXxRDoUT6qpdYihRrs7YeRKh/IWSXw/80Bd0hVEvZQ1hp802K QIrpINU0chsos8WjMm3adx56cKFODeBfbr/hupUAheunAdbuWmfOS7zvPq5MZxMQ+95h hFyGsX3oaQXOFsTmK0JciSEw+z03OGEoCxGqg2iqLTrG+zfN/oZAnTes2GG2Ysz0Qp9X T9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Snf/2iwNsJT7L/wduP0LNZQuCBReVOQEpdjpGfoN7ow=; b=S+0CEUI28aMYnmcqZz5G7zsg7LtCE+s2QSQbhfOqxzIWqMMQkAvyI48c6O88m9CWi0 QLYr2tG8zrILc/6MLc8eBLL1owDnvvyxZzbHqtax+BW0tfp1Yv8c/5dqI6qBPDBHqncm dAPzkIhmjReFmJJcEitNW8LTWLv9ifDTyCGg+OBQ4ytwaVto4yjkA0ngT5TJZ8s4HHE3 WVtLbEZH+MhklpOoIbLZsvgK443QdcZXelkfmEh58OseE6c04Xzu2rnmMCoXqldIlMXE /gTSw4usPF/aC3evTs6j/3N1KI9AV313ZURqV//h3VWkX/zcaQJ/saqN6ELyK89nkmAP NBlA== X-Gm-Message-State: ALQs6tAhWqAV00p4pu3kQ9qmKhbO8nnJNiZomT5cJXkj3+f9bq0kSg03 ejahIFGUdlX/LkJgQgYUBrLkgmlhK1kooNayacM= X-Google-Smtp-Source: AIpwx4+Scs2KTKCLcJivU50Uigk3zC7Vf9dcoiKb32dsY2oF1C9u5HPqd9VXWXcaE1drQeevdV/0r2fm1R2jt6bgRYI= X-Received: by 2002:a81:4705:: with SMTP id u5-v6mr4829403ywa.350.1524540046095; Mon, 23 Apr 2018 20:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.157.140 with HTTP; Mon, 23 Apr 2018 20:20:45 -0700 (PDT) In-Reply-To: References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> From: Christopher Wood Date: Mon, 23 Apr 2018 22:20:45 -0500 Message-ID: To: David Benjamin Cc: Eric Rescorla , TLS WG Content-Type: multipart/alternative; boundary="000000000000e4be60056a8fa345" Archived-At: Subject: Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2018 03:20:50 -0000 --000000000000e4be60056a8fa345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Monday, April 23, 2018, David Benjamin wrote: > +1 > > On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla wrote: > >> +1 >> >> On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote: >> >>> All, >>> >>> tl;dr: If you object to the following early code point assignments 1) >>> add the compress_certificate in the TLS ExtensionType Registry and 2) >>> compressed_certificate in the TLS HandshakeType Registry, then please l= et >>> the list know why by 2359UTC on 10 May 2018. The Certificate Compressi= on >>> Algorithm IDs will be populated with two values: zlib and brotli. >>> >>> At IETF101, we discussed beginning the process of getting an early code >>> point assignment for the extension defined in draft-ietf-tls-certificat= e-compression. >>> The one technical comments raised at the meeting was extending the >>> compression code point space from 1 byte to 2 might be a good idea. Th= e >>> authors have merged a PR to address this in the gh repo and once they >>> submit a new version of the draft the process for an early code point >>> assignment will begin. The rules for this are specified in RFC7120, an= d >>> the four criteria for a draft to be eligible for early code point >>> assignment are: >>> >>> Criteria A >>> >>> The code points must be from a space designated as "RFC >>> Required", "IETF Review", or "Standards Action". Additionally, >>> requests for early assignment of code points from a >>> "Specification Required" registry are allowed if the >>> specification will be published as an RFC. >>> >>> The Transport Layer Security (TLS) Extensions and TLS HandshakeType >>> Registry registries are both RFC Required. While we=E2=80=99re changin= g that >>> registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, the= re=E2=80=99s >>> still every intention to publish draft-ietf-tls-certificate-compression >>> as an RFC so we=E2=80=99re still good to go. >>> >>> Criteria B >>> >>> The format, semantics, processing, and other rules related to >>> handling the protocol entities defined by the code points >>> (henceforth called "specifications") must be adequately describe= d >>> in an Internet-Draft. >>> >>> When asked at IETF101 what other outstanding comments there were on the >>> draft the only one identified was increasing the code point size for th= e >>> compression algorithms. Version -05 will address this point. >>> >>> Criteria C >>> >>> The specifications of these code points must be stable; i.e., if >>> there is a change, implementations based on the earlier and late= r >>> specifications must be seamlessly interoperable. >>> >>> At IETF101, it was noted that this specification was stable enough. >>> Implementation issues might be identifier later, but, well, that=E2=80= =99s the >>> point. >>> >>> Criteria D >>> >>> The Working Group chairs and Area Directors (ADs) judge that >>> there is sufficient interest in the community for early (pre-RFC= ) >>> implementation and deployment, or that failure to make an early >>> allocation might lead to contention for the code point in the >>> field. >>> >>> 5 WG participants all from different organizations indicated their >>> interest in implementing this draft (even if it was just for >>> experimentation). >>> >>> >>> There are also 6 steps identified in RFC 7120 for early assignment, but >>> only four involve the chairs: >>> >>> 1. The authors (editors) of the document submit a request for early >>> allocation to the Working Group chairs, specifying which code >>> points require early allocation and to which document they shoul= d >>> be assigned. >>> >>> An in-person request was made at IETF 101 for the early code point >>> assignments. There was also an earlier on-list request. >>> >>> 2. The WG chairs determine whether the conditions for early >>> allocations described in Section 2 are met, particularly >>> conditions (c) and (d). >>> >>> The chairs agree that the four conditions have been met. >>> >>> 3. The WG chairs gauge whether there is consensus within the WG tha= t >>> early allocation is appropriate for the given document. >>> >>> The sense of the room at IETF 101 was that yes early allocation is >>> appropriate, but this email is verifying that. >>> >>> 4. If steps 2) and 3) are satisfied, the WG chairs request approval >>> from the Area Director(s). The Area Director(s) may apply >>> judgement to the request, especially if there is a risk of >>> registry depletion. >>> >>> Once the chairs have determined WG consensus, we=E2=80=99ll pass it to = Ben. >>> >>> spt >>> _______________________________________________ >>> 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 >> > --000000000000e4be60056a8fa345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1

On Monday, April 23, 2018, David Benjamin <davidben@chromium.org> wrote:
+1

On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
+1

On Mon, Apr 23, 2018 at 9:33 A= M, Sean Turner <sean@sn3rd.com> wrote:
All,

tl;dr: If you object to the following early code point assignments 1) add t= he compress_certificate in the TLS ExtensionType Registry and 2) compressed= _certificate in the TLS HandshakeType Registry, then please let the list kn= ow why by 2359UTC on 10 May 2018.=C2=A0 The Certificate Compression Algorit= hm IDs will be populated with two values: zlib and brotli.

At IETF101, we discussed beginning the process of getting an early code poi= nt assignment for the extension defined in draft-ietf-tls-certificate-= compression.=C2=A0 The one technical comments raised at the meeting was ext= ending the compression code point space from 1 byte to 2 might be a good id= ea.=C2=A0 The authors have merged a PR to address this in the gh repo and o= nce they submit a new version of the draft the process for an early code po= int assignment will begin.=C2=A0 The rules for this are specified in RFC712= 0, and the four criteria for a draft to be eligible for early code point as= signment are:

Criteria A

=C2=A0 =C2=A0 =C2=A0 =C2=A0The code points must be from a space designated = as "RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review", or &quo= t;Standards Action".=C2=A0 Additionally,
=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code points fro= m a
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" registry are = allowed if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RFC.

The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registr= y registries are both RFC Required.=C2=A0 While we=E2=80=99re changing that= registry=E2=80=99s rules with draft-ietf-tls-iana-registry-updates, t= here=E2=80=99s still every intention to publish draft-ietf-tls-certificate-= compression as an RFC so we=E2=80=99re still good to go.

Criteria B

=C2=A0 =C2=A0 =C2=A0 =C2=A0The format, semantics, processing, and other rul= es related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0handling the protocol entities defined by the co= de points
=C2=A0 =C2=A0 =C2=A0 =C2=A0(henceforth called "specifications") m= ust be adequately described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in an Internet-Draft.

When asked at IETF101 what other outstanding comments there were on the dra= ft the only one identified was increasing the code point size for the compr= ession algorithms.=C2=A0 Version -05 will address this point.

Criteria C

=C2=A0 =C2=A0 =C2=A0 =C2=A0The specifications of these code points must be = stable; i.e., if
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is a change, implementations based on the = earlier and later
=C2=A0 =C2=A0 =C2=A0 =C2=A0specifications must be seamlessly interoperable.=

At IETF101, it was noted that this specification was stable enough.=C2=A0 I= mplementation issues might be identifier later, but, well, that=E2=80=99s t= he point.

Criteria D

=C2=A0 =C2=A0 =C2=A0 =C2=A0The Working Group chairs and Area Directors (ADs= ) judge that
=C2=A0 =C2=A0 =C2=A0 =C2=A0there is sufficient interest in the community fo= r early (pre-RFC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0implementation and deployment, or that failure t= o make an early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation might lead to contention for the code= point in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0field.

5 WG participants all from different organizations indicated their interest= in implementing this draft (even if it was just for experimentation).


There are also 6 steps identified in RFC 7120 for early assignment, but onl= y four involve the chairs:

=C2=A0 1.=C2=A0 The authors (editors) of the document submit a request for = early
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation to the Working Group chairs, specifyi= ng which code
=C2=A0 =C2=A0 =C2=A0 =C2=A0points require early allocation and to which doc= ument they should
=C2=A0 =C2=A0 =C2=A0 =C2=A0be assigned.

An in-person request was made at IETF 101 for the early code point assignme= nts.=C2=A0 There was also an earlier on-list request.

=C2=A0 =C2=A02.=C2=A0 The WG chairs determine whether the conditions for ea= rly
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocations described in Section 2 are met, part= icularly
=C2=A0 =C2=A0 =C2=A0 =C2=A0conditions (c) and (d).

The chairs agree that the four conditions have been met.

=C2=A0 =C2=A03.=C2=A0 The WG chairs gauge whether there is consensus within= the WG that
=C2=A0 =C2=A0 =C2=A0 =C2=A0early allocation is appropriate for the given do= cument.

The sense of the room at IETF 101 was that yes early allocation is appropri= ate, but this email is verifying that.

=C2=A0 =C2=A04.=C2=A0 If steps 2) and 3) are satisfied, the WG chairs reque= st approval
=C2=A0 =C2=A0 =C2=A0 =C2=A0from the Area Director(s).=C2=A0 The Area Direct= or(s) may apply
=C2=A0 =C2=A0 =C2=A0 =C2=A0judgement to the request, especially if there is= a risk of
=C2=A0 =C2=A0 =C2=A0 =C2=A0registry depletion.

Once the chairs have determined WG consensus, we=E2=80=99ll pass it to Ben.=

spt
_______________________________________________
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
--000000000000e4be60056a8fa345-- From nobody Mon Apr 23 21:42:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C09127078 for ; Mon, 23 Apr 2018 21:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NXVrjv7YdQaA for ; Mon, 23 Apr 2018 21:42:35 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16537124B0A for ; Mon, 23 Apr 2018 21:42:35 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id b13-v6so20432937qtp.12 for ; Mon, 23 Apr 2018 21:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=atHnhLz8YNGYnJzJALxenBY5fzkDevaUd7h0iKkbAvs=; b=gWBjfP8N9M8DXAjzmfzqawWgGyILKLSxwWx5KpSyBNd2vmeCz4p1s3+c8sT7CvpzkU Pa80Ze20zbN46l/J0IriAPmKYJBHgqcoAZfJgUdYKZkJmfoz31C8EoDGJLsaCxvjw24C j0xhbaF91tev71RVmWqkE3H4gWd9FAAukzDht3s3AY0f6xhgwMnpyFE6gQqgVh3jOW7V b7yyh75pACma3hNCAIs/IkAn2ToLnilBxIdXfHSsLTEr4+C+sHyz+FrajVCjABOGngyG 1bZIfSd0mdQ3d4ITI2y/zY+AmL26P+SBnTvQYEckYE40UkUGt5jf/k4iiLZe9a3kukP0 /lHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=atHnhLz8YNGYnJzJALxenBY5fzkDevaUd7h0iKkbAvs=; b=PpqSYYxkUaKI7l6j9/uMkf7DbrHptrIW6fk92VUlH21evbLKO0WhSrGZxrf55/rfnQ PyzFPhCrY+oQAd5AQSar0QRotGtzlcTuTHFOr01EG7vuoFOKwX83/oPNzF6UCaXKpW1D PJl4F8C5kD1DDcZyhn5jd+0FTSmdk4YbgEcbrYaihz+YZdI60jIUpcanqNKX6JD+wCo9 iJQ+mGdbvaB0fH7Ghr60ShWxfbIPIofSyxD5X1ndcisfiCSvrQ/khCNq/dIFwN9MAARr m8FZPNSN6T3PGuNGEpRpUAdZlsXrUxro4Ol/Z3+bGJpxZyBo7y72nBrrnygJxFw/TT+/ vvhg== X-Gm-Message-State: ALQs6tBAO5KPBDyWoaFrb/PH9E9b2O7nX0FipP0u8OmOFeR4soJyb/pP eR6ZaEjIDEsjgTw+RchzWLDXqWsnVg5EuZQmTPuZ5Q== X-Google-Smtp-Source: AB8JxZpH8aDrRGrP03Pa55ggxAlsefDyMSnpa7O86ChWo/J0FfjYk6+Jufpjm1M5Xne+/rBET0yXrw3cGT1DNm64XPA= X-Received: by 10.12.153.106 with SMTP id i39mr2877834qvd.236.1524544954124; Mon, 23 Apr 2018 21:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.56.70 with HTTP; Mon, 23 Apr 2018 21:42:13 -0700 (PDT) In-Reply-To: <4dfbb5f1-926f-1ac6-5c0a-974ba6d18431@nomountain.net> References: <4dfbb5f1-926f-1ac6-5c0a-974ba6d18431@nomountain.net> From: Joseph Salowey Date: Mon, 23 Apr 2018 21:42:13 -0700 Message-ID: To: Melinda Shore Cc: "" Content-Type: multipart/alternative; boundary="001a114174026f6340056a90c895" Archived-At: Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2018 04:42:37 -0000 --001a114174026f6340056a90c895 Content-Type: text/plain; charset="UTF-8" When your revisions are ready please post them to the list in OLD and NEW format so the working group can evaluate them. Thanks, Joe On Wed, Apr 18, 2018 at 1:20 PM, Melinda Shore wrote: > On 4/18/18 10:22 AM, Joseph Salowey wrote: > > Concerns have been raised about the trade-offs associated with pinning > > and I do not think we currently have consensus to add pinning. While I > > think it may be possible to come to consensus on pinning I think it may > > take some time. I believe we can quickly get consensus for the > > following approach: > > > > 1. Scope the document to the assertive use cases > > 2. Explicitly allow (but do not require) DoE be included > > 3. Remove current text about pinning > > 4. Re-submit the document for publication and start work on a separate > > extension that supports pinning > > This sounds reasonable. I'll talk with co-editors about text > changes. > > Melinda > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114174026f6340056a90c895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When your revisions are ready please post them to the list= in OLD and NEW format so the working group can evaluate them.

Thanks,

Joe

On Wed, Apr 18, 2018 at 1:20 PM, Meli= nda Shore <melinda.shore@nomountain.net> wrote:
On 4/18/18 10:22 AM, Jose= ph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning=
> and I do not think we currently have consensus to add pinning.=C2=A0 W= hile I
> think it may be possible to come to consensus on pinning I think it ma= y
> take some time.=C2=A0 I believe we can quickly get consensus for the > following approach:
>
> 1. Scope the document to the assertive use cases
> 2. Explicitly allow (but do not require) DoE be included
> 3. Remove current text about pinning
> 4. Re-submit the document for publication and start work on a separate=
> extension that supports pinning

This sounds reasonable.=C2=A0 I'll talk with co-editors about te= xt
changes.

Melinda

--
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A034C0 DFB8 917= 2 9A76 DB8F


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


--001a114174026f6340056a90c895-- From nobody Tue Apr 24 09:18:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0912E8CE for ; Tue, 24 Apr 2018 09:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 adYU2bPNEmf9 for ; Tue, 24 Apr 2018 09:18:21 -0700 (PDT) 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 6352F129C6E for ; Tue, 24 Apr 2018 09:18:21 -0700 (PDT) Received: from localhost (unknown [IPv6:2a06:98c0:1000:8200:d955:f79a:3ad3:8b19]) by blastoise.ghedini.me (Postfix) with ESMTPSA id B8F6BDFAFE; Tue, 24 Apr 2018 16:18:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1524586699; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=PcM5HsOq4CQTPR3uAJYtXCW0jrnqqrX2GJQOlgzNo8E=; b=I4SEpVwUxu4G69c5rVvQuatT9gqrDaTNx6AhvDyDDC4FUjjqlJxQ+t9CTlQIy/ayHd5kg4 QqsAPJuhCAqHYOw6fEbr0qzvn/LkmBlacM/GTm9FoSUFHGsHyNT11G8I/G0koQgCFSPhv5 +ZqG4aPqjMLDSmJyLMGF8++bHO4z6bg= Date: Tue, 24 Apr 2018 17:18:18 +0100 From: Alessandro Ghedini To: Sean Turner Cc: TLS WG Message-ID: <20180424161818.GA2935@mandy> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> User-Agent: Mutt/1.9.5 (2018-04-13) Archived-At: Subject: Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2018 16:18:24 -0000 On Mon, Apr 23, 2018 at 12:33:08PM -0400, Sean Turner wrote: > Criteria B > > The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet-Draft. > > When asked at IETF101 what other outstanding comments there were on the draft the only one identified was increasing the code point size for the compression algorithms. Version -05 will address this point. Small correction, the code point size change was included in draft-03 (not -05) that was published yesterday. Cheers From nobody Tue Apr 24 22:34:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8E126FB3 for ; Tue, 24 Apr 2018 22:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0uEuhPuVqGQs for ; Tue, 24 Apr 2018 22:34:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6712126B7E for ; Tue, 24 Apr 2018 22:34:16 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CF5477A3309 for ; Wed, 25 Apr 2018 05:34:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: TLS WG Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> Date: Wed, 25 Apr 2018 01:33:54 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 05:34:19 -0000 I've been asked to write up proposed changes to the DNSSEC chain extension draft (with the 16-bit extension support lifetime field). In doing that I've discovered that adding the 16-bit field is a minor tweak to the document text, but, ironically, describing denial of existence, though a simple idea, requires extensive surgery to the document. Below I do both, in the hope that either or both will prove useful. Perhaps a concrete proposal will make it easier to reach a mutually-agreeable consensus position, and make it clear that the requested 16-bits are a reasonable consensus outcome. I'm also willing to create a pull request against: https://github.com/MelindaShore/dnssec-serialization if there's interest in me doing that. Below I list OLD/NEW text chunks with the name of the section in which they fit. --- Change 1: Section 2. Introduction. * Add denial of existence OLD: The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding to its DANE record. If the server is configured for DANE authentication, then it performs the appropriate DNS queries, builds the authentication chain, and returns it to the client. The server will usually use a previously cached authentication chain, but it will need to rebuild it periodically as described in Section 5. The client then authenticates the chain using a pre-configured trust anchor. NEW: The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding to its DANE TLSA resource record set (RRset), or authenticated denial of existence of that RRset. If the server supports this extension it performs the appropriate DNS queries, builds the authentication chain, and returns it to the client. The server will usually use a previously cached authentication chain, but it will need to rebuild it periodically as described in Section 5. The client then authenticates the chain using a pre-configured trust anchor. When the requested TLSA RRset does not exist, and/or the containing DNS zone is not DNSSEC-signed, the server MAY return a chain of records that establish authenticated denial of existence of the TLSA RRset, or prove insecure delegation (an ancestor) of that domain. Alternatively, the server MAY simply not negotiate the extension. --- Change 2: Section 3.4. DNSSEC Authentication Chain Data * Add 16-bit SupportLifetime field OLD: The "extension_data" field of the "dnssec_chain" extension MUST contain a DNSSEC Authentication Chain encoded in the following form: opaque AuthenticationChain<1..2^16-1> NEW: The "extension_data" field of the "dnssec_chain" extension MUST contain a DNSSEC Authentication Chain encoded in the following form: struct { uint16 SupportLifetime; opaque AuthenticationChain<1..2^16-1>; } DnssecChainExtension; A zero "SupportLifetime" prohibits the client from unilaterally requiring ongoing use of the extension based on prior observation of its use (pinning). A future specification will define the semantics of non-zero values of the SupportLifetime field. Servers implementing only the present specification MUST set the SupportLifetime element to zero. Clients implementing only the present specification MUST treat any value received as though it were zero. --- Change 3: Section 3.4. DNSSEC Authentication Chain Data * Add denial of existence OLD: The first RRset in the chain MUST contain the TLSA record set being presented. [...] The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. [...] NEW: When the response contains validated TLSA records, the first RRset in the chain MUST contain the TLSA record set being presented. [...] When the response is an authenticated denial of existence, after any initial DNSSEC-signed CNAME and/or DNAME records redirecting the requested TLSA RRset, the next RRset in the chain MUST be the signed SOA record of the domain that is proving the non-existence of the TLSA RRset or its insecure delegation. The SOA record MUST be followed by the relevant signed NSEC or NSEC3 records. The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set or denial of existence response via the server's trust anchor. [...] --- Change 4: Section 3.4. DNSSEC Authentication Chain Data * Add denial of existence examples: OLD: The following is an example of the records in the AuthenticationChain [...] RRSIG(. DNSKEY) NEW: The following is an example of the records in the AuthenticationChain [...] RRSIG(. DNSKEY) The following is a TLSA RRset denial-of-existence example: example.com. IN SOA RRSIG(example.com. SOA) example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC RRSIG(example.com. NSEC) example.com. DNSKEY RRSIG(example.com. DNSKEY) example.com. DS RRSIG(example.com. DS) com. DNSKEY RRSIG(com. DNSKEY) com. DS RRSIG(com. DS) . DNSKEY RRSIG(. DNSKEY) The following is an insecure delegation example (with NSEC3 opt-out): com. IN SOA RRSIG(com. SOA) GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 - - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB NS DS RRSIG) RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3) com. DNSKEY RRSIG(com. DNSKEY) com. DS RRSIG(com. DS) . DNSKEY RRSIG(. DNSKEY) --- Change 5: Section 6. Verification * Add denial of existence * Note that TLSA records might not be "usable" (new issue in the document, sorry, but clients should not have to honour unusable TLSA records) OLD: A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, MUST use this information to perform DANE authentication of the server. In order to do this, it uses the mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. NEW: A TLS client making use of this specification, which receives a verifiable DNSSEC authentication chain extension from a server, MUST use this information to perform DANE authentication of the server when the response is not a denial of existence and has at least one "usable" TLSA record as defined in [RFC6698], [RFC7671] and any other applicable specifications (perhaps application-specific). Verification of the authentication chain extension uses the mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. [... New final paragraph for Section 6 ...] Clients MAY also cache a denial of existence response up to the validated negative TTL of such a response. --- Change 6: Section 8. Mandating use of this extension * Prohibit unilateral pinning, clarify downgrade. OLD: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. This protocol currently provides no way for a server to prove that it doesn't have a TLSA record. Hence absent whitelists, a client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication. This could be solved by enhancing this protocol to require that servers without TLSA records need to provide a DNSSEC authentication chain that proves this (i.e. the chain includes NSEC or NSEC3 records that demonstrate either the absence of the TLSA record, or the absence of a secure delegation to the associated zone). Such an enhancement would be impossible to deploy incrementally though since it requires all TLS servers to support this protocol. NEW: Pending a future specification that defines the semantics of non-zero values of the SupportLifetime element of the extension, clients MUST NOT employ "pinning" to require use of the extension by servers previously observed to support it. Servers that implement only this specification MUST set the SupportLifetime element to zero. In the absence of "pinning", when the extension is not mandatory, a client cannot reliably determine which servers don't have TLSA records. Hence, a client communicating with a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to a rogue server that simply omits this extension. --- Editorial Appendix A. Test vectors s/reproducability/reproducibility/ This section should probably include new denial of existence test vectors. -- Viktor. From nobody Wed Apr 25 02:52:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903B124BFA for ; Wed, 25 Apr 2018 02:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O6Y00fuMJ99 for ; Wed, 25 Apr 2018 02:52:02 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F6512025C for ; Wed, 25 Apr 2018 02:52:01 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id v5-v6so1931378wrf.9 for ; Wed, 25 Apr 2018 02:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=FvQJW6nfOWcNnnb5pt41WQ+FlY9DhWfXdYb1ZmrYlug=; b=SsVfBI4IQv1toxOuX/7GtUxo8g79Zm9Rmw2QpWGw3q0fp0VWFkj0NH+0i3otcA/VPs DJu28URwB7TaJovhnK7MCsttl5Qxcj0JwVezp672kRPn222XrogPCTpdKNLJOp3H4LkN Cqh5ANuv7yAZwUAbgm1Xhv+5ptqTidfJ54UIkSqqNSwrDGGnjeLEviU786PhfG8XdpKB 7WtmacYAu7YFp2uBcKIFrzI7dIyzpavcjwI0LzRVzb5IT35G/2pYRaB9RYrEkE6VshWT jZYBtGRUXFK6u6bNpKFIsFMsI5GqKMeXkDBypIG+TimpcKmaBpEbW0HN16Wk1Y6F8RYx yHQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=FvQJW6nfOWcNnnb5pt41WQ+FlY9DhWfXdYb1ZmrYlug=; b=UsQRhDDq7PfAGEEKFz1msfUk9DFiMiI2275mBjabj0wwrjkvCsJhZlcCDrzzI0D+b/ WYSY6HKdsBke9MX4CcwJpxA3y2SUuNK3OHBYirJM9p2b8tRS6y+bI5bUsGMUEmt8K9cl lbXowzM64X06veIIp/QDxX+Aity3fbT2CdDPA4HPCENssRXlHQHr/Lt615zkPsGEw2/n ON2TGsbmFs7oZl7OrZ+INHtcQKq6OiF/SPpgcxCupPV+CpVEOsH813XkPMSyDdK6WHVK rMJ/jDRxbwV1r0rsyJYunfJWXCd1dErzkAmx3aQZx1qo69r896gbWixglksHLOEu6uDk YPfA== X-Gm-Message-State: ALQs6tD5BgQb2BGNG6YLjfmKnftTZE58oioxP5fj90+xidXRkF9KyF/l AIn48xNiOpdF7DenheKe9vSEMvusRA== X-Google-Smtp-Source: AIpwx4+sCdsG6TVuRD+wbs3R4DIXloltTk3apxbfTsyu5mEEqqel8490exHB0woZNR5tm509d5LIbA== X-Received: by 2002:adf:d207:: with SMTP id g7-v6mr22584531wri.59.1524649920043; Wed, 25 Apr 2018 02:52:00 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (100.1.71.37.rev.sfr.net. [37.71.1.100]) by smtp.gmail.com with ESMTPSA id w6-v6sm15844935wra.84.2018.04.25.02.51.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 02:51:58 -0700 (PDT) To: tls@ietf.org References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= xsFNBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABzSdNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbT7CwZcEEwEKAEECGwMFCQlnUwAFCwkIBwMF FQoJCAsFFgIDAQACHgECF4AWIQRPaC2TKheW+CDyNMDfuJFymnbbjwUCWml0ZAIZAQAKCRDf uJFymnbbjwiCEACjyYe2HGofiuEla4aI3CvIEzEpn2HsMWXrrqqybtPwIMv3aQ0XrxFPkeWk JN9CYwG23IZIE9h7gB2PMIEtzOswzEUGioryHjqZ6NWbX9yjoyIPkVKAAGcn66shF/8ZPhxu cG2dLNY0UxrbF6NmWlGLGSHkd2wTYCQUVNKq7gWrHIYzSXBwKL+zlOhw9JqPk8a/+JeSFLE/ dZBlKJLpllELGSGtvpOuCJz/ICK/jXiEKDFaiMveResRNIP7SsLcoxwcIdVra5q0oQbE/zlD tlq6yPR8aO3cYm6MTkFcZW0pPQiFqXXOpZJGCxJMjd10qKBAr3uJ+czomFp0kVkosckSau5Q +h66MY73PDQnfmjDCzgN4w+TU5dv5wM6Zq9nutFuBtf0EELN0tKuSakI2mlpvIjPzSHh0Xmi mBhjWurmWXyHAV3PDbEMwEePJKAOeP8xx/qalmD8f424TA897nVqZ/oKtrVeIua+P6v87z5+ 9EFvrAX3ZDb9YOk+HvnNLBpDl3Vk7aZzNTjsNZcVbYTGZBOOtjMw5dOz/5xDv8kpaf4ORxEL Nf5BZaSEWZLW+pRtNE3fWJ5uuJvqDitwnI6WLS7Q5MkuHRz0/nVMqT0JRuFOChGQrY6/kmbH JK82xf1Xy2y7UFADuhlx6iOCaG08BFEDVmsGDna0SF3nNq//gc7BTQRaaWdIARAAoGbjNfII c0robr/p9JFslgnhFq8fRMtNxIBY+WpQbeefji793TrHcgRycY7XdHGUtV2imZYK9WGdDqUD b/1ssvLkltgWeochtUijff9TJnySzZ448WgUD+MmjMA3Ut8F+4aFmNfSKVT2R2A0d+RQIEpx v7OsHviDiEzNUyaDibOPsoHiuXQuy30aI/pZBB2K03IJWFbsLMithTc/7BfJCVtXxGRzOuqY Um4Qr8GxAlm2+Hgxl2ymWPdltUU0OVObXfAzC18mIqUKYa3KHkV6W9fA2zpxNFsCEFdMgYHP 604lLf8FY2rHdUa7AjwUAv7ifmR5J769jKMSFgQbEbSmBxuumji/pw1fF9Zorheo+HM7b4Jn aq8Dx6QClcYX8HfxuLLjQbp2MOP5AFfW9vnonV+XptzbTzzZf6jY7JhB0Bp/+SSkR0b0LNMr ooFw4TdjdJHqB62xghPJMgP3fNy+xPXfeYbH9ycaUc5nmk83vjaXCGl+bl3SjmggYy7cdbTq wwOF1+2N52PsGimWGt0bwu8rpRSYin2Fg0q4lnkF3F49OqfB+rxerMvS3l/cUUY0yO6gxxcc LjECChqoLn17cbtKccXDKl0xFD2Z8VFlL7hY42LxJrTvdvjrfzbqLVfCb0T8INjp2IzCaHVN V+4cxLPHY7YGRvrdxRBit4tRCVEAEQEAAcLBfAQYAQoAJhYhBE9oLZMqF5b4IPI0wN+4kXKa dtuPBQJaaWdIAhsMBQkJZ1MAAAoJEN+4kXKadtuPJK4P/R/PeirQEAgFdEXFd0Kme+YmOaQs aUcsQGkdD4xOY4mFeYFBzwira/VD2beAYvm8zS0NiiSukceFzX+ZUFqKRKNSMbTohT45K0CK TZGJhVsjhqSqUiA4YLCabMGasTwy6aPufRjZUlBur97DAJ8fhr7b6nM5L4OlDwzfyWCu+QSB qAhmTMqK9QdBJkWI/fC3cI0/eXUGV42b1gQ3iMfjcVGSqAOwJUf8YLDdzxxquEgKTCy9Ef6m 4iyM1D50z7ebAbNKXn5VbzK7YCDImfRXWDxPlVsufl9gJnhYOmZeVu+h0FD+nmGUFeWm2foo lvZWNU5qrKqUyA7v2TMu6S5J8VeRNb0MvsLIoZbg2MnWkOB1qDWmO0BW/se07L4yUYvnB+wc uI8aIU1lLmrpLjJk9HhGnrFiUq2gJsbH36icA6bItHIWbJLl4xJvYF+q2OzIczmZe1c/Rfuj GE7U5k9ZqZCwDFn9fybilAn50gB0ZQ8VDgBukEiaB1gBqmMt14hfWzet8kOsZZZaEm2zLz/V VtHv4hSjChCL3yLwINCK5T3HygBrrk9WscCFO3WvzeyznF8gw0hFLks71y/wZFso8bi83S2O nk7wumU/3wOYkvzwFI9Fm61jax0LUOTmNvmpdr+iXS7v8OiGSQgaU6LDgDs85q3vt9X5NRys KnfcUcQv Message-ID: Date: Wed, 25 Apr 2018 11:51:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gd70T26hPLeNhpPPdTJSkCLn8mnoamB0N" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 09:52:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gd70T26hPLeNhpPPdTJSkCLn8mnoamB0N Content-Type: multipart/mixed; boundary="RteuwCA8rOB4EeBE5BZVtudTHXk88LxkV"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> In-Reply-To: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> --RteuwCA8rOB4EeBE5BZVtudTHXk88LxkV Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > Perhaps a concrete proposal will make it > easier to reach a mutually-agreeable consensus position, and make it > clear that the requested 16-bits are a reasonable consensus outcome. Hi, Viktor: This doesn't actually reflect the consensus called by the chairs, as I understand what was posted. It may be useful to start work on a new draft describing your proposal. Melinda --=20 Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --RteuwCA8rOB4EeBE5BZVtudTHXk88LxkV-- --gd70T26hPLeNhpPPdTJSkCLn8mnoamB0N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAlrgT74ACgkQ37iRcpp2 24+4aA/+K9kfo0XmYyBCc2hD6dp+7BpFCOG9d2xJgo1qxp+pGCqyCvvtDa8hbq8E vv+LZue4DR2Am6vXsAfKeH+4ix4/cEGQO96lYinp0mttm2H2Dc1Sq7I07RwGVMHE Tv046AsWzaPgHFE2XhwZjUXPAPbuCqFUyD5FFcCCGhZIztduE58KpjmJ4pVg7q9/ 0yCyh6h87h77x6FRp53JbIw55E/2owT6DgiQDqHLf11J8r3Q11LZ90b9+qmjAcwq LgvJHcSoOc9R/gQKhzIajiHEYYTlW3QjZJgSNzIdtGOLevaj07EMNXBbAoobxHFb n3eoDOnwDaHE2uk5F5MGyPvF1A4xFHnNsZRdUndt0jULjuf1PfpoOdaJff4CufhN N68V9Eh8BeiF09BDXNf7YegrPBL62qscn/QnQMjZtgcyTnoSDMuKU6cjIhMu1nTf 1EPF3NWqrBn9Qx91dsPjIFgFzk5xRPz7ITxCqcntFwaIM39xJ67E5VBeDVTcftAG 8vdR54BGPqMLgpH1H6QK3yrvVTUapvlDpvvo8Md231b8ghKLG6hJM2UDgbkxVMZb mvOFN6uLkkYNM/EgXpE1zhq5E+X4NqgKq1NvYA/QAjwzkp1DgPR8uqjRVutZwD84 G9DN6gY5nZn7/cGKXIJCTKMQG4FSr38aF+7Xb0lTccZxTRvJ+4I= =IH7o -----END PGP SIGNATURE----- --gd70T26hPLeNhpPPdTJSkCLn8mnoamB0N-- From nobody Wed Apr 25 07:02:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8B1126D45 for ; Wed, 25 Apr 2018 07:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKYZ6c3uj8lG for ; Wed, 25 Apr 2018 07:02:35 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 29F47120047 for ; Wed, 25 Apr 2018 07:02:35 -0700 (PDT) Received: from [IPv6:2a04:b900:0:1:2444:446d:7bb7:5185] (unknown [IPv6:2a04:b900:0:1:2444:446d:7bb7:5185]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id F2AD287F3 for ; Wed, 25 Apr 2018 16:02:32 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1524664952; bh=NaB0XcLtsOf4KuAFgx5qAR8q6Uaw7Gj9UoWQo66AaQY=; h=Subject:To:References:From:Date:In-Reply-To; b=FJ6SiWyhdxVo0nZCZ/4eBjtvHF0dCSdpL4qXLaxeM0+mzDi8RyDKBQpbybLak1PY5 lDfALZ9/frP5cqd3t684JlxzY6K5emAWzuijgW5O68CWzCR+RXzXEJxhQ1sbhnq+BN dLSUZ5TYLoWrSBZggd18xTdNXUgCdpDuLvWtqlT4= To: tls@ietf.org References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> From: Willem Toorop Message-ID: Date: Wed, 25 Apr 2018 16:02:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 14:02:38 -0000 Thanks for the suggestions, Op 25-04-18 om 07:33 schreef Viktor Dukhovni: > > I've been asked to write up proposed changes to the DNSSEC chain > extension draft (with the 16-bit extension support lifetime field). > In doing that I've discovered that adding the 16-bit field is a > minor tweak to the document text, but, ironically, describing > denial of existence, though a simple idea, requires extensive > surgery to the document. Below I do both, in the hope that either > or both will prove useful. Perhaps a concrete proposal will make it > easier to reach a mutually-agreeable consensus position, and make it > clear that the requested 16-bits are a reasonable consensus outcome. > > I'm also willing to create a pull request against: > > https://github.com/MelindaShore/dnssec-serialization We're actually working on https://github.com/tlswg/dnssec-chain-extension > if there's interest in me doing that. Below I list OLD/NEW text > chunks with the name of the section in which they fit. If you do, could you please make separate pull requests for denial of existence and another one for the lifetime field. Are you sure 16 bits is enough? Other STS specs appear to use seconds for the max-age directive. They are also extensible with new directives (which have been introduced too, to overcome initial unforeseen limitations (i.e. preloading)). Why do you require the SOA? It is not needed for the denial of existence (or insecurity) proof. NSEC ttls tell how long to cache the non-existence so it is not needed for the minimum field either. > --- Change 1: Section 2. Introduction. > * Add denial of existence > > OLD: > > The extension described here allows a TLS client to request that the > TLS server return the DNSSEC authentication chain corresponding to > its DANE record. If the server is configured for DANE > authentication, then it performs the appropriate DNS queries, builds > the authentication chain, and returns it to the client. The server > will usually use a previously cached authentication chain, but it > will need to rebuild it periodically as described in Section 5. The > client then authenticates the chain using a pre-configured trust > anchor. > > NEW: > > The extension described here allows a TLS client to request that the > TLS server return the DNSSEC authentication chain corresponding to > its DANE TLSA resource record set (RRset), or authenticated denial > of existence of that RRset. If the server supports this extension > it performs the appropriate DNS queries, builds the authentication > chain, and returns it to the client. The server will usually > use a previously cached authentication chain, but it will need > to rebuild it periodically as described in Section 5. The client > then authenticates the chain using a pre-configured trust anchor. > > When the requested TLSA RRset does not exist, and/or the containing > DNS zone is not DNSSEC-signed, the server MAY return a chain of > records that establish authenticated denial of existence of the > TLSA RRset, or prove insecure delegation (an ancestor) of that domain. > Alternatively, the server MAY simply not negotiate the extension. > > > --- Change 2: Section 3.4. DNSSEC Authentication Chain Data > * Add 16-bit SupportLifetime field > > OLD: > > The "extension_data" field of the "dnssec_chain" extension MUST > contain a DNSSEC Authentication Chain encoded in the following form: > > > opaque AuthenticationChain<1..2^16-1> > > > NEW: > > The "extension_data" field of the "dnssec_chain" extension MUST > contain a DNSSEC Authentication Chain encoded in the following form: > > struct { > uint16 SupportLifetime; > opaque AuthenticationChain<1..2^16-1>; > } DnssecChainExtension; > > A zero "SupportLifetime" prohibits the client from unilaterally > requiring ongoing use of the extension based on prior observation > of its use (pinning). > > A future specification will define the semantics of non-zero > values of the SupportLifetime field. Servers implementing only > the present specification MUST set the SupportLifetime element > to zero. Clients implementing only the present specification MUST > treat any value received as though it were zero. > > --- Change 3: Section 3.4. DNSSEC Authentication Chain Data > * Add denial of existence > > OLD: > > The first RRset in the chain MUST contain the TLSA record set being > presented. [...] > > The subsequent RRsets MUST contain the full set of DNS records needed > to authenticate the TLSA record set from the server's trust anchor. > [...] > > NEW: > > When the response contains validated TLSA records, > the first RRset in the chain MUST contain the TLSA record set being > presented. [...] > > When the response is an authenticated denial of existence, after > any initial DNSSEC-signed CNAME and/or DNAME records redirecting > the requested TLSA RRset, the next RRset in the chain MUST be the > signed SOA record of the domain that is proving the non-existence > of the TLSA RRset or its insecure delegation. The SOA record MUST > be followed by the relevant signed NSEC or NSEC3 records. > > The subsequent RRsets MUST contain the full set of DNS records > needed to authenticate the TLSA record set or denial of existence > response via the server's trust anchor. [...] > > --- Change 4: Section 3.4. DNSSEC Authentication Chain Data > * Add denial of existence examples: > > OLD: > > The following is an example of the records in the AuthenticationChain > [...] > RRSIG(. DNSKEY) > > NEW: > The following is an example of the records in the AuthenticationChain > [...] > RRSIG(. DNSKEY) > > The following is a TLSA RRset denial-of-existence example: > > example.com. IN SOA > RRSIG(example.com. SOA) > example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC > RRSIG(example.com. NSEC) > example.com. DNSKEY > RRSIG(example.com. DNSKEY) > example.com. DS > RRSIG(example.com. DS) > com. DNSKEY > RRSIG(com. DNSKEY) > com. DS > RRSIG(com. DS) > . DNSKEY > RRSIG(. DNSKEY) > > The following is an insecure delegation example (with NSEC3 opt-out): > > com. IN SOA > RRSIG(com. SOA) > GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 - > - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB NS DS RRSIG) > RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3) > com. DNSKEY > RRSIG(com. DNSKEY) > com. DS > RRSIG(com. DS) > . DNSKEY > RRSIG(. DNSKEY> > --- Change 5: Section 6. Verification > * Add denial of existence > * Note that TLSA records might not be "usable" (new issue > in the document, sorry, but clients should not have to > honour unusable TLSA records) > > OLD: > > A TLS client making use of this specification, and which receives a > DNSSEC authentication chain extension from a server, MUST use this > information to perform DANE authentication of the server. In order > to do this, it uses the mechanism specified by the DNSSEC protocol > [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a > DNSSEC validation engine or library. > > NEW: > > A TLS client making use of this specification, which receives > a verifiable DNSSEC authentication chain extension from a server, > MUST use this information to perform DANE authentication of the > server when the response is not a denial of existence and has > at least one "usable" TLSA record as defined in [RFC6698], [RFC7671] > and any other applicable specifications (perhaps application-specific). > > Verification of the authentication chain extension uses the > mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. > This mechanism is sometimes implemented in a DNSSEC validation > engine or library. > > [... New final paragraph for Section 6 ...] > > Clients MAY also cache a denial of existence response up to the > validated negative TTL of such a response. > > --- Change 6: Section 8. Mandating use of this extension > * Prohibit unilateral pinning, clarify downgrade. > > OLD: > > If TLS applications want to mandate the use of this extension for > specific servers, clients could maintain a whitelist of sites where > the use of this extension is forced. The client would refuse to > authenticate such servers if they failed to deliver this extension. > Client applications could also employ a Trust on First Use (TOFU) > like strategy, whereby they would record the fact that a server > offered the extension and use that knowledge to require it for > subsequent connections. > > This protocol currently provides no way for a server to prove that it > doesn't have a TLSA record. Hence absent whitelists, a client > misdirected to a server that has fraudulently acquired a public CA > issued certificate for the real server's name, could be induced to > establish a PKIX verified connection to the rogue server that > precluded DANE authentication. This could be solved by enhancing > this protocol to require that servers without TLSA records need to > provide a DNSSEC authentication chain that proves this (i.e. the > chain includes NSEC or NSEC3 records that demonstrate either the > absence of the TLSA record, or the absence of a secure delegation to > the associated zone). Such an enhancement would be impossible to > deploy incrementally though since it requires all TLS servers to > support this protocol. > > NEW: > > Pending a future specification that defines the semantics of > non-zero values of the SupportLifetime element of the extension, > clients MUST NOT employ "pinning" to require use of the extension > by servers previously observed to support it. Servers that > implement only this specification MUST set the SupportLifetime > element to zero. > > In the absence of "pinning", when the extension is not mandatory, > a client cannot reliably determine which servers don't have TLSA > records. Hence, a client communicating with a server that has > fraudulently acquired a public CA issued certificate for the real > server's name, could be induced to establish a PKIX verified > connection to a rogue server that simply omits this extension. > > > --- Editorial Appendix A. Test vectors > > s/reproducability/reproducibility/ > > This section should probably include new denial of existence test vectors. From nobody Wed Apr 25 07:36:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB20C127909 for ; Wed, 25 Apr 2018 07:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoyVDdQZcjcR for ; Wed, 25 Apr 2018 07:36:17 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 36A1F127AD4 for ; Wed, 25 Apr 2018 07:36:16 -0700 (PDT) Received: from [IPv6:2a04:b900:0:1:2444:446d:7bb7:5185] (unknown [IPv6:2a04:b900:0:1:2444:446d:7bb7:5185]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 621968925 for ; Wed, 25 Apr 2018 16:36:14 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1524666974; bh=6EsJ++VXj7BbAtkb4qAXRH5sUpjshCZ7c/7bVdw4mu8=; h=Subject:To:References:From:Date:In-Reply-To; b=AqOCzxoVEdQDR/nD4hbdz1VCC9tU6fePMrqdqIzsV5Ep6JLFWH0QC0tvpKwZw2bzP 1GKXYSLw1rpAsvVAY6rBRz/cPksV9KvukKgqXSKvMLeHelEDbjUXRyuiA3M8QRporO 0ZRceg9J+SR5aQNjtENNQXYpoi9tG/7gATL6BSyA= To: tls@ietf.org References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> From: Willem Toorop Message-ID: Date: Wed, 25 Apr 2018 16:36:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 14:36:19 -0000 Op 25-04-18 om 07:33 schreef Viktor Dukhovni: > The following is a TLSA RRset denial-of-existence example: > > example.com. IN SOA > RRSIG(example.com. SOA) > example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC Hopefully the DNSKEY rrtype is included in this NSEC too :), so: example.com. IN NSEC www.example.com. A NS SOA MX RRSIG NSEC DNSKEY > RRSIG(example.com. NSEC) > example.com. DNSKEY > RRSIG(example.com. DNSKEY) > example.com. DS > RRSIG(example.com. DS) > com. DNSKEY > RRSIG(com. DNSKEY) > com. DS > RRSIG(com. DS) > . DNSKEY > RRSIG(. DNSKEY) From nobody Wed Apr 25 08:08:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F26124239 for ; Wed, 25 Apr 2018 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwuSeteBp9kP for ; Wed, 25 Apr 2018 08:08:36 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0E2124205 for ; Wed, 25 Apr 2018 08:08:36 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 428C3480056DB; Wed, 25 Apr 2018 08:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=c+C+GB+WczO7jh FygAdx9xC/JWA=; b=BxF8+ZkaFa1X8KCaOV8Jj7H1OonHhjeshsT9cz0nZJPirc 3uXSad5SYoIDQUfHmu3WSfBAx2oIbu8+49E0PiNRIaoOz+DfapXON4AwIgrkrxth arAa7jB7N35wxBHnNaZXSy8BanLpnUqUpzYzaPBoEvRZ7UyscMSzXwNDdifhg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id D2BC0480056CE; Wed, 25 Apr 2018 08:08:34 -0700 (PDT) Date: Wed, 25 Apr 2018 09:57:22 -0500 From: Nico Williams To: Melinda Shore Cc: tls@ietf.org Message-ID: <20180425145721.GH25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:08:37 -0000 On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > Perhaps a concrete proposal will make it > > easier to reach a mutually-agreeable consensus position, and make it > > clear that the requested 16-bits are a reasonable consensus outcome. > > Hi, Viktor: > > This doesn't actually reflect the consensus called by the > chairs, as I understand what was posted. It may be useful > to start work on a new draft describing your proposal. The chair said there is consensus for (A) with no pinning. Viktor's proposal is (A) with no pinning. It's not at all clear to me that the two reserved bytes are outside the consensus, and anyways, their cost is minimal. However, if you object to turning the extension contents into a struct, then I would propose a slight tweak to Viktor's proposal: Two-byte elements of the AuthenticationChain are reserved for future use. Pending future specifications, clients MUST discard any two- byte elements of the AuthenticationChain, and servers MUST NOT send any such elements. We might as well say that all too-small-to-be-DNS-payloads elements of the AuthenticationChain are reserved and discarded: Any elements of the AuthenticationChain that are too small to contain DNS RRset payloads are reserved for future use. Pending future specifications, clients MUST discard any such AuthenticationChain elements, and servers MUST NOT send any such elements. The nice thing about this is that it makes it easier to extend this extension later, while also adding minimal complexity now ("clients MUST discard such elements"). Nico -- From nobody Wed Apr 25 08:19:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2839126DEE for ; Wed, 25 Apr 2018 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3HUoq64PEpyP for ; Wed, 25 Apr 2018 08:19:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CB91267BB for ; Wed, 25 Apr 2018 08:19:36 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C26127A3309 for ; Wed, 25 Apr 2018 15:19:35 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 25 Apr 2018 11:19:35 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <5F44331C-6B94-47AD-8A9A-785E9A11E10A@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:19:39 -0000 > On Apr 25, 2018, at 10:02 AM, Willem Toorop = wrote: >=20 > We're actually working on >=20 > https://github.com/tlswg/dnssec-chain-extension >=20 >=20 >> if there's interest in me doing that. Below I list OLD/NEW text >> chunks with the name of the section in which they fit. >=20 > If you do, could you please make separate pull requests for denial of > existence and another one for the lifetime field. I'll try to get that done. Thanks for the right repository pointer. > Are you sure 16 bits is enough? Other STS specs appear to use seconds > for the max-age directive. Yes, I'm sure that 16-bits is enough. This is because an extension = support lifetime measured in seconds makes little sense, once this gets below an hour it is commensurate with and often smaller than the TTL of the TLSA = RRset. There's no point in "pinning" the extension for a shorter time, the = client can just cache the TLSA records instead. The point of the extension = support lifetime is for ongoing downgrade resistance *beyond* the DNS TTL of the = TLSA records. 16 bits of hours is sufficient for a commitment between 1 hour = and 7.5 years. > They are also extensible with new directives > (which have been introduced too, to overcome initial unforeseen > limitations (i.e. preloading)). Here I'm proposing a simple and general mechanism broadly applicable to all TLS applications. It would cover, for example, downgrade protection for SUBMIT, POP, IMAP and XMPP clients. There is deliberately no = support for including sub-domains as that would likely drag in the public suffix list as a co-requisite and complicate deployment. Preloading is rather browser-specific, and can be handled at the HTTPS layer if desired. Preloading only scales to the extent that it is not too popular. > Why do you require the SOA? It is not needed for the denial of > existence (or insecurity) proof. NSEC ttls tell how long to cache the > non-existence so it is not needed for the minimum field either. You're probably right about that, the NSEC or NSEC3 records are required to carry the same negative TTL (also limited by the RRSIG original TTL and RRSIG expiration). So probably the SOA can be omitted, with the = NSEC or NSEC3 records first after the relevant DNAME/CNAME chain. --=20 Viktor. From nobody Wed Apr 25 08:49:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA911276AF for ; Wed, 25 Apr 2018 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44-pth5oQ3CH for ; Wed, 25 Apr 2018 08:49:03 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DF31267BB for ; Wed, 25 Apr 2018 08:49:03 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a202so23005230qkg.3 for ; Wed, 25 Apr 2018 08:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ddoiYP1jCsmgOtdSJQgaL1W0WS5q3xMLN4gaXRna1hI=; b=QfUh1EtlomT1lkUaj31bvLOhj02z4M4E2VBGuVuJvdtMarGSbL5bZaSt9PxDOB3Eik hVHzDys86HP1jWgUI8lX+JhaeW4oiHysQF/oK7QDbRCxe8A9hobIA+xrwT1hE1aczECM ZvIA6vQrXWvi/BRsj9RkbS0IxECCZigyh8SxfGgfR+Lzq0y29L0l/d7DZbQ1fJtSg6vt +Wqi7CDJzGrbtBqKJAjXh3x/Q68ceHrcsGYSnBmOQvtsgRc3uvo7NCZ32tKK0qssazQG xCKqe4dQBIXQ9aRBeXmrnQmSZLaEQSugLC/5ujfCxT6eidiPl5naioQNNYMxqX48iaJw CbMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ddoiYP1jCsmgOtdSJQgaL1W0WS5q3xMLN4gaXRna1hI=; b=XvLyc3cZSmp3e+l+nPXXBWky1oBf3kWsI0yucEFeYfC/MM8JPkU87OKlPrlrSJy0JG r4C9jRy8x0bSbFM9tu9txaqaE11zO1t38vKmMzdcq4NBv6ex5ON9my2E9j3Oyd+GD3IL 2xK42JmBHIgMerMJhBx8mMT2+HpDbIHgjnOYbQfbs3FMdgaVaykkfFG9munEWqrHDxFL VnpJkagW1v7xDABNiCGRT1k7zkytKBzX6/Ib66LC+ROmex+YbeGfXxIgq6heCxzidklo l38motYufG7i4hrjpyWQKUV4AJTt8UIzfaDkcONP4FBlVYTDxq5dci8Uc78MCrf1wSx1 egbQ== X-Gm-Message-State: ALQs6tDWqVxXSAxcvNZ3f9flW+duoYbEPSkd9ZQ5wDwTn4R1ZP30vB7j APeW+4UP6CxsBYrJ84ZJ5T3SID40dM6yJ/LIxHIxuw== X-Google-Smtp-Source: AB8JxZr61KOcbAicm3kYBOfNGgD5DzkaT4G2g8yWo8hQWUSgK6NMvTbCGGNezmXhurcTS/dzO0SuyjM0A+J5Ut85ito= X-Received: by 10.55.131.196 with SMTP id f187mr29475718qkd.97.1524671342051; Wed, 25 Apr 2018 08:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.112.211 with HTTP; Wed, 25 Apr 2018 08:48:41 -0700 (PDT) In-Reply-To: References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> From: Joseph Salowey Date: Wed, 25 Apr 2018 08:48:41 -0700 Message-ID: To: Melinda Shore Cc: "" Content-Type: multipart/alternative; boundary="94eb2c070192be2fa9056aae3563" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:49:05 -0000 --94eb2c070192be2fa9056aae3563 Content-Type: text/plain; charset="UTF-8" To clarify, I asked for exact text to understand better what is being asked for, since it wasn't very clear to me what the scope fo the change is. On Wed, Apr 25, 2018 at 2:51 AM, Melinda Shore wrote: > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > Perhaps a concrete proposal will make it > > easier to reach a mutually-agreeable consensus position, and make it > > clear that the requested 16-bits are a reasonable consensus outcome. > > Hi, Viktor: > > This doesn't actually reflect the consensus called by the > chairs, as I understand what was posted. It may be useful > to start work on a new draft describing your proposal. > > Melinda > > > -- > Software longa, hardware brevis > > PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c070192be2fa9056aae3563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To clarify, I asked for exact text to understand better wh= at is being asked for, since it wasn't very clear to me what the scope = fo the change is.=C2=A0

On Wed, Apr 25, 2018 at 2:51 AM, Melinda Shore <mel= inda.shore@nomountain.net> wrote:
On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it > clear that the requested 16-bits are a reasonable consensus outcome.
Hi, Viktor:

This doesn't actually reflect the consensus called by the
chairs, as I understand what was posted.=C2=A0 It may be useful
to start work on a new draft describing your proposal.

Melinda


--
Software longa, hardware brevis

PGP key fingerprint=C2=A0 4F68 2D93 2A17 96F8 20F2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A034C0 DFB8 9172 9A76 DB8F


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


--94eb2c070192be2fa9056aae3563-- From nobody Wed Apr 25 08:52:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130A8127775 for ; Wed, 25 Apr 2018 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mlCSFMfqTu6 for ; Wed, 25 Apr 2018 08:52:33 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BC8127735 for ; Wed, 25 Apr 2018 08:52:33 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 895AC480056D2; Wed, 25 Apr 2018 08:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JgwwDCjvQGaaXg gGMLmSGTSG4aU=; b=JQlGnJIjzl3t7w2Xw5Uufmrr4XB0udZOzILqqpRw4wiRNu VtYWV7Z3EslWcO+dLiWpisZ3IrYMzSQ1Q3LmviKGVp3Y4ZS0ijP/7AW4ZPi6Sf9+ F2wfJ5m30bIfCsdBLoF0ikVz7WJgbhsgjRE08yGcWg0f3ryRugXV2vHfd6AVY= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 4B9F7480056CE; Wed, 25 Apr 2018 08:52:32 -0700 (PDT) Date: Wed, 25 Apr 2018 10:40:02 -0500 From: Nico Williams To: Melinda Shore Cc: tls@ietf.org Message-ID: <20180425154001.GI25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180425145721.GH25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180425145721.GH25259@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:52:34 -0000 On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > Perhaps a concrete proposal will make it > > > easier to reach a mutually-agreeable consensus position, and make it > > > clear that the requested 16-bits are a reasonable consensus outcome. > > > > Hi, Viktor: > > > > This doesn't actually reflect the consensus called by the > > chairs, as I understand what was posted. It may be useful > > to start work on a new draft describing your proposal. > > The chair said there is consensus for (A) with no pinning. Viktor's > proposal is (A) with no pinning. It's not at all clear to me that the > two reserved bytes are outside the consensus, and anyways, their cost is > minimal. > > However, if you object to turning the extension contents into a struct, > then I would propose a slight tweak to Viktor's proposal: > > Two-byte elements of the AuthenticationChain are reserved for future > use. Pending future specifications, clients MUST discard any two- > byte elements of the AuthenticationChain, and servers MUST NOT send > any such elements. Ay, never mind, this isn't XDR, so that wouldn't work. From nobody Wed Apr 25 08:59:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5444712785F for ; Wed, 25 Apr 2018 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3n83ugzGmkV for ; Wed, 25 Apr 2018 08:58:59 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A824127735 for ; Wed, 25 Apr 2018 08:58:59 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A375348005E8E; Wed, 25 Apr 2018 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=1PZ/bGjHjmuqSr VtpMBjJk61M8s=; b=gP4GFNyfG9AlnCvyaA+lAIhe3um7fzjLk7Q7PFnA4y0mxM a3dsYYACmvvNQmOVKn6+intZJhd8BFBFqpblpQkhjpsPpuXZi/9ryWgJQUjRsW5/ lRgkp2cTaDyJQjvDVMnwgkvOfgJz4laaGmc3jjYa0vgNs680hVR3IjIIKaNqc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 3FD8848005E8C; Wed, 25 Apr 2018 08:58:58 -0700 (PDT) Date: Wed, 25 Apr 2018 10:46:27 -0500 From: Nico Williams To: Melinda Shore Cc: tls@ietf.org Message-ID: <20180425154626.GJ25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180425145721.GH25259@localhost> <20180425154001.GI25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180425154001.GI25259@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:59:00 -0000 On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote: > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > > Perhaps a concrete proposal will make it > > > > easier to reach a mutually-agreeable consensus position, and make it > > > > clear that the requested 16-bits are a reasonable consensus outcome. > > > > > > Hi, Viktor: > > > > > > This doesn't actually reflect the consensus called by the > > > chairs, as I understand what was posted. It may be useful > > > to start work on a new draft describing your proposal. > > > > The chair said there is consensus for (A) with no pinning. Viktor's > > proposal is (A) with no pinning. It's not at all clear to me that the > > two reserved bytes are outside the consensus, and anyways, their cost is > > minimal. > > > > However, if you object to turning the extension contents into a struct, > > then I would propose a slight tweak to Viktor's proposal: > > > > Two-byte elements of the AuthenticationChain are reserved for future > > use. Pending future specifications, clients MUST discard any two- > > byte elements of the AuthenticationChain, and servers MUST NOT send > > any such elements. > > Ay, never mind, this isn't XDR, so that wouldn't work. Actually, since the extension's body is an opaque<1..2^16-1>, and the extension is itself an opaque<>, it's possible to have data past the end of the body of the extension. But at this point I prefer Viktor's struct proposal. From nobody Wed Apr 25 21:14:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F0112DA04 for ; Wed, 25 Apr 2018 21:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fl6gTyqJFaSY for ; Wed, 25 Apr 2018 21:13:59 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0121127867 for ; Wed, 25 Apr 2018 21:13:58 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f16-v6so26021935qth.0 for ; Wed, 25 Apr 2018 21:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ILWhUmVFr+iskCmhVujRW2LAx1E4mvd0C+5aEIpbZ4s=; b=l53Nx5pSuJjU8h/r44Eovp3/tIFLOkvXqOlmST4OL1LK5m9xFC5Eo1DW2vprISzxk5 XavmsCzjfRS8pRcxoILcWqMboDpi+GGS+ofy+aFUk8gB/Uhh7qzl6ytHegnre9mMKvoL nGL1En6SgxJBh+X/UTZ4EC+z7zyvi4Hrsc5At/KWJoFoLOA2m376ZrDcNaWlEFoeAuwx AGdXlWsGWj2L25w+sV8qDiftUeL2MUYj+NJsvewDdchtXAqmbU86/6NjihuCjqbUbAAl QZtO7+zz6iIduC65YLKp6zRY5CPoIMqNaZNJSKQKYy7QMfIOt7rFv8XndQfdqD93vgPc eqnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ILWhUmVFr+iskCmhVujRW2LAx1E4mvd0C+5aEIpbZ4s=; b=NRJZMBXtYFUJpo82oJONn5uRh692j/0rtCCOwLdOvmeSbB4exyGhoPOoTPKBpGqIkS fJ3RD09CDjKSixDbi1aYnhrDn68kdG9yYMnVK2E9/Qh+vNgAfR0iFQ9F4a/mTcVQ0Rsc zSzsB4bIw/zdzI4kiZG4z9Jn4Fd+9yRDY+QCxY5BPjWG14L/x1PZTmAo71/o9txkeHQn uThibBUC0hnrFmciVTiEhWHaTZ0fMi7/BPAzP9MaP5m/5OV4yKF+j+ZR/KkZTW40DAIN iu1zceNER91td2XlzGDFUMrCqhUgL+Rvn4WalLJTY+v4R5RuVU1L6GTIyckJKJuJi55H H7xQ== X-Gm-Message-State: ALQs6tDOX3e4PRIu/pzUlA3SGwCIW4voxyXeNoSFV8CvmME5+u/jmcdj DzdqVr5T25EyXPogB2ePqAxWF9vxu/rjdb5rqD0f21Be X-Google-Smtp-Source: AB8JxZr9HtgsXoNQdjfqjfzTUBioO1Rhh4c6q2UNz7amLUeZ+dvejlKAfpZQKBl71FqC4JLhFddofJYb9uWKkfk8qIQ= X-Received: by 2002:aed:2a67:: with SMTP id k36-v6mr34589293qtf.302.1524716037742; Wed, 25 Apr 2018 21:13:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.112.211 with HTTP; Wed, 25 Apr 2018 21:13:37 -0700 (PDT) In-Reply-To: <20180425154626.GJ25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180425145721.GH25259@localhost> <20180425154001.GI25259@localhost> <20180425154626.GJ25259@localhost> From: Joseph Salowey Date: Wed, 25 Apr 2018 21:13:37 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000d03537056ab89d24" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 04:14:01 -0000 --000000000000d03537056ab89d24 Content-Type: text/plain; charset="UTF-8" This proposal is quite a bit more than just a two byte reserved field. On Wed, Apr 25, 2018 at 8:46 AM, Nico Williams wrote: > On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote: > > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > > > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > > > Perhaps a concrete proposal will make it > > > > > easier to reach a mutually-agreeable consensus position, and make > it > > > > > clear that the requested 16-bits are a reasonable consensus > outcome. > > > > > > > > Hi, Viktor: > > > > > > > > This doesn't actually reflect the consensus called by the > > > > chairs, as I understand what was posted. It may be useful > > > > to start work on a new draft describing your proposal. > > > > > > The chair said there is consensus for (A) with no pinning. Viktor's > > > proposal is (A) with no pinning. It's not at all clear to me that the > > > two reserved bytes are outside the consensus, and anyways, their cost > is > > > minimal. > > > > > > However, if you object to turning the extension contents into a struct, > > > then I would propose a slight tweak to Viktor's proposal: > > > > > > Two-byte elements of the AuthenticationChain are reserved for future > > > use. Pending future specifications, clients MUST discard any two- > > > byte elements of the AuthenticationChain, and servers MUST NOT send > > > any such elements. > > > > Ay, never mind, this isn't XDR, so that wouldn't work. > > Actually, since the extension's body is an opaque<1..2^16-1>, and the > extension is itself an opaque<>, it's possible to have data past the end > of the body of the extension. But at this point I prefer Viktor's > struct proposal. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d03537056ab89d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal is quite a bit mor= e than just a two byte reserved field.=C2=A0=C2=A0

On Wed, Apr 25, 2018 at 8= :46 AM, Nico Williams <nico@cryptonector.com> wrote:
=
On Wed, Apr 25, 2018 at 10:= 40:02AM -0500, Nico Williams wrote:
> On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > > > Perhaps a concrete proposal will make it
> > > > easier to reach a mutually-agreeable consensus position= , and make it
> > > > clear that the requested 16-bits are a reasonable conse= nsus outcome.
> > >
> > > Hi, Viktor:
> > >
> > > This doesn't actually reflect the consensus called by th= e
> > > chairs, as I understand what was posted.=C2=A0 It may be use= ful
> > > to start work on a new draft describing your proposal.
> >
> > The chair said there is consensus for (A) with no pinning.=C2=A0 = Viktor's
> > proposal is (A) with no pinning.=C2=A0 It's not at all clear = to me that the
> > two reserved bytes are outside the consensus, and anyways, their = cost is
> > minimal.
> >
> > However, if you object to turning the extension contents into a s= truct,
> > then I would propose a slight tweak to Viktor's proposal:
> >
> >=C2=A0 =C2=A0 Two-byte elements of the AuthenticationChain are res= erved for future
> >=C2=A0 =C2=A0 use.=C2=A0 Pending future specifications, clients MU= ST discard any two-
> >=C2=A0 =C2=A0 byte elements of the AuthenticationChain, and server= s MUST NOT send
> >=C2=A0 =C2=A0 any such elements.
>
> Ay, never mind, this isn't XDR, so that wouldn't work.

Actually, since the extension's body is an opaque<1..2^16-1&g= t;, and the
extension is itself an opaque<>, it's possible to have data past = the end
of the body of the extension.=C2=A0 But at this point I prefer Viktor's=
struct proposal.

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

--000000000000d03537056ab89d24-- From nobody Wed Apr 25 21:17:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1F4127867 for ; Wed, 25 Apr 2018 21:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jgEl5FjkpEio for ; Wed, 25 Apr 2018 21:17:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBC912426E for ; Wed, 25 Apr 2018 21:17:23 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B7EFE7A3309 for ; Thu, 26 Apr 2018 04:17:22 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 00:17:21 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <5E452933-1085-44CF-AF19-8DBB8870C5F8@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 04:17:25 -0000 > On Apr 25, 2018, at 10:02 AM, Willem Toorop wrote: > > If you do, could you please make separate pull requests for denial of > existence and another one for the lifetime field. I made a single pull request with two commits, I hope that's OK. The 16-bit field is the second commit, and if that fails to get adopted, then you can use just the first commit. https://github.com/tlswg/dnssec-chain-extension/pull/14 The text is slightly different from my earlier post based on a revisions already staged by the authors which adds a section containing a brief overview of the the two types of a denial of existence response. The first commit makes what I think are additional necessary adjustments elsewhere in the document. It also changes MUST use DANE when TLSA records are present to SHOULD use DANE when TLSA records are present AND "usable". With the protocol subject to downgrade attacks, the MUST does not afford any downgrade resistance. The client may do as it pleases and the server is none the wiser, so MUST does not make sense here. -- Viktor. [ Drafting revisions to a document sure forces one to read the fine print in ways that a mere "review" often fails to achieve. :-( ] From nobody Wed Apr 25 21:21:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0B127867 for ; Wed, 25 Apr 2018 21:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpR8EWwwgA7I for ; Wed, 25 Apr 2018 21:21:48 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDD212426E for ; Wed, 25 Apr 2018 21:21:48 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 9BF18A004B82; Wed, 25 Apr 2018 21:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=dPn/fNkExPlbng eGTHLv2/XVEiQ=; b=oovwCaCruVCTaSHgimDpUQjSCltKMzrfyZYY+tPqHuhBik 8cs+o3Y2Zrk7923oaLog+9lrDMkYFzwKzEreBgIqFTekzH9URIhJW0m3nwFSN9LR qZTAwhHMBF+hoJwcPDBA2GP7HDuhdOB5L6zIC4qIPlRs5PxpBUeD8jiro93zI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 3BAA1A004B81; Wed, 25 Apr 2018 21:21:47 -0700 (PDT) Date: Wed, 25 Apr 2018 23:15:53 -0500 From: Nico Williams To: Joseph Salowey Cc: "" Message-ID: <20180426041552.GK25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180425145721.GH25259@localhost> <20180425154001.GI25259@localhost> <20180425154626.GJ25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 04:21:49 -0000 On Wed, Apr 25, 2018 at 09:13:37PM -0700, Joseph Salowey wrote: > This proposal is quite a bit more than just a two byte reserved field. What, Viktor's text? Most of it has to do with the denial of existence, not with those two bytes. From nobody Wed Apr 25 21:26:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E0E126C2F for ; Wed, 25 Apr 2018 21:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 v0fIeYyMDDGA for ; Wed, 25 Apr 2018 21:26:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A0712426E for ; Wed, 25 Apr 2018 21:26:04 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 009697A3309 for ; Thu, 26 Apr 2018 04:26:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 00:26:03 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <855EDC72-651A-44B7-86FB-693A4B31A7A0@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180425145721.GH25259@localhost> <20180425154001.GI25259@localhost> <20180425154626.GJ25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 04:26:07 -0000 > On Apr 26, 2018, at 12:13 AM, Joseph Salowey wrote: >=20 > This proposal is quite a bit more than just a two byte reserved field. I am not sure what you mean. The proposed text adds the field, tells servers to set it to zero, and tells clients to treat it as though it were zero even if a non-zero value is seen. So far, so good right? Please help me understand... The only extra bit is that the client *explicitly* MUST NOT PIN when the field is zero. So the pinning prohibition is stronger than what you get if you just remove description of pinning, and my bet would be that left unsaid, and if we don't standardize downgrade-protection in a timely manner, some clients might unilaterally decide to pin. I did not expect prohibiting pinning at this time to be controversial. That should have broad support. The relevant diff is at: = https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/034da27062= b53fe4a7460536187220585df13f0d Or see below: commit 034da27062b53fe4a7460536187220585df13f0d Author: Viktor Dukhovni Date: Thu Apr 26 00:00:55 2018 -0400 Describe new 16-bit SupportLifetime extension element =20 This both actively inhibits "pinning" in the present, and serves to facilitate it in the future. diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml = b/draft-ietf-tls-dnssec-chain-extension-08.xml index ffec606..5a4b685 100644 --- a/draft-ietf-tls-dnssec-chain-extension-08.xml +++ b/draft-ietf-tls-dnssec-chain-extension-08.xml @@ -304,13 +304,29 @@ =20
- - opaque AuthenticationChain<1..2^16-1> + struct { + uint16 SupportLifetime; + opaque AuthenticationChain<1..2^16-1>; + } DnssecChainExtension;
=20 - The AuthenticationChain structure is composed of a sequence of=20 + A zero "SupportLifetime" prohibits the client from unilaterally + requiring ongoing use of the extension based on prior observation + of its use (pinning). + + + + A future specification will define the semantics of non-zero + values of the SupportLifetime field. Servers implementing only + the present specification MUST set the SupportLifetime element + to zero. Clients implementing only the present specification = MUST + treat any value received as though it were zero. + + + + The AuthenticationChain is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and=20 corresponding signatures (RRSIG) record sets. @@ -691,6 +707,15 @@ RRSIG(. DNSKEY) extension, could of course unconditionally mandate its use. =20 + + Pending a future specification that defines the semantics of + non-zero values of the SupportLifetime element of the extension, + clients MUST NOT employ "pinning" to require use of the extension + by servers previously observed to support it. Servers that + implement only this specification MUST set the SupportLifetime + element to zero. + + This protocol allows TLS servers to prove that they don't have a signed TLSA record by returning a denial of existence chain. --=20 Viktor. From nobody Wed Apr 25 23:30:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CEF126D85 for ; Wed, 25 Apr 2018 23:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FgITWu5whUpq for ; Wed, 25 Apr 2018 23:30:44 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A481205F0 for ; Wed, 25 Apr 2018 23:30:44 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h8-v6so24456601otb.2 for ; Wed, 25 Apr 2018 23:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=U9OoaK19mNOJwLM7kUiQtuPvP9YjnyG7GMv1sV+9m3g=; b=IwMAP9TV2kahe9UHxDYG9QGxBZ4Siuk6WAhKuGx6ybvUbFZybDIiUpeArIwo0QsXUX K5j83jzm4TWQ4faP51f2IPESFR/DcC6PAmrAUUl0Odp/ZQr+kL9K3eFZii2vQkyrFixW Y73UzvrHia2NbZaOKjJdtL4TGFcIzBXDUR7G/ZaWL8e+0E7raue+e1EubzLeGopai+/z ArC5SSXCfmlZDMQYn8tzxN7QmwpETMsaR4uksiXETwubLA5nFu0k5MMa2fN1oO7x6mlw uPJN9vyZnzO4rD0hokT0TpvrcDzrJCRLp9PYigaf6OHm1IKFN50KjtedRejTwR31Hlys Ya7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=U9OoaK19mNOJwLM7kUiQtuPvP9YjnyG7GMv1sV+9m3g=; b=str/Rxf+w42UubNfsncc0YOSIbNmfjGJRKxJyRcXiZBNkdRoR0GAAbDGvgUGTGJ1Xd XCKAtGVRTjlofWhn5QuMQYnyralcrufSD4mVf2kOd7TB2rr6Swetv7F2z3eA7qDLs8j/ S0rDtnPzNiZbpIyLGsorv3rd2+02NF5IZoF8vDE7sLfCFPmM51fAusVhO/y7DtKejJgd rhNn8GU6Mgcjc48o9RaRRxiyJhY7CiYo+W1mtJC1LSXJB1+OgL8WisXWRavoQjaPeG5C 9KYalpvj/dWTP0j6eWCt1Kx+VVDlKQWrO2VGkl9rcKk4zrNXy7zD75bxKL1x7un48mQW C08g== X-Gm-Message-State: ALQs6tD4aaPzoXu/WcI96HOTAiOg20NXGwAJ2Bmh+jTDoUib5NODnh0k 6m+M+Fl/nvurgLaGGZCFC5u4nY8BXpKOsO624NvVc+x8 X-Google-Smtp-Source: AB8JxZrCxgs/QYARsjGJCkiuXOHIfN7cDk3qVcTW9SKl8XHkrSThT+PPMUEH1lz4duPDt7TWkniZ34BttC++iBk9FH0= X-Received: by 2002:a9d:2225:: with SMTP id o34-v6mr55769ota.101.1524724243333; Wed, 25 Apr 2018 23:30:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Wed, 25 Apr 2018 23:30:02 -0700 (PDT) In-Reply-To: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> From: Eric Rescorla Date: Wed, 25 Apr 2018 23:30:02 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000e79ee3056aba8638" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 06:30:48 -0000 --000000000000e79ee3056aba8638 Content-Type: text/plain; charset="UTF-8" Hi Victor, Thanks for producing some text. I understand why one might think that having a reserved 16-bit field is useful here, but I don't really agree. The conventional reason to reserve this kind of field is that you need to leave space for an extension in some PDU, because it's hard to add later. But that's not true here (or in TLS in general) because we already have an extension mechanism (indeed, the one that's being used by this specification). If we end up having consensus to do pinning, then it's straightforward to define a new TLS extension that provides it. If you look at HPKP and Expect-CT, you will note that there are a number of other fields besides just lifetime (report-uri, include subdomains). I recognize that opinions vary about whether these are good, but the advantage of having a whole new extension is that we need not resolve those now in order to move this document forward. As far as I can tell, the primary disadvantage of a new extension is a slight increase in the size of the TLS handshake if the extension is used (balanced against two wasted bytes in this proposed design if it is not used). That doesn't seem like a good set of tradeoffs. -Ekr On Tue, Apr 24, 2018 at 10:33 PM, Viktor Dukhovni wrote: > > I've been asked to write up proposed changes to the DNSSEC chain > extension draft (with the 16-bit extension support lifetime field). > In doing that I've discovered that adding the 16-bit field is a > minor tweak to the document text, but, ironically, describing > denial of existence, though a simple idea, requires extensive > surgery to the document. Below I do both, in the hope that either > or both will prove useful. Perhaps a concrete proposal will make it > easier to reach a mutually-agreeable consensus position, and make it > clear that the requested 16-bits are a reasonable consensus outcome. > > I'm also willing to create a pull request against: > > https://github.com/MelindaShore/dnssec-serialization > > if there's interest in me doing that. Below I list OLD/NEW text > chunks with the name of the section in which they fit. > > --- Change 1: Section 2. Introduction. > * Add denial of existence > > OLD: > > The extension described here allows a TLS client to request that the > TLS server return the DNSSEC authentication chain corresponding to > its DANE record. If the server is configured for DANE > authentication, then it performs the appropriate DNS queries, builds > the authentication chain, and returns it to the client. The server > will usually use a previously cached authentication chain, but it > will need to rebuild it periodically as described in Section 5. The > client then authenticates the chain using a pre-configured trust > anchor. > > NEW: > > The extension described here allows a TLS client to request that the > TLS server return the DNSSEC authentication chain corresponding to > its DANE TLSA resource record set (RRset), or authenticated denial > of existence of that RRset. If the server supports this extension > it performs the appropriate DNS queries, builds the authentication > chain, and returns it to the client. The server will usually > use a previously cached authentication chain, but it will need > to rebuild it periodically as described in Section 5. The client > then authenticates the chain using a pre-configured trust anchor. > > When the requested TLSA RRset does not exist, and/or the containing > DNS zone is not DNSSEC-signed, the server MAY return a chain of > records that establish authenticated denial of existence of the > TLSA RRset, or prove insecure delegation (an ancestor) of that domain. > Alternatively, the server MAY simply not negotiate the extension. > > > --- Change 2: Section 3.4. DNSSEC Authentication Chain Data > * Add 16-bit SupportLifetime field > > OLD: > > The "extension_data" field of the "dnssec_chain" extension MUST > contain a DNSSEC Authentication Chain encoded in the following form: > > > opaque AuthenticationChain<1..2^16-1> > > > NEW: > > The "extension_data" field of the "dnssec_chain" extension MUST > contain a DNSSEC Authentication Chain encoded in the following form: > > struct { > uint16 SupportLifetime; > opaque AuthenticationChain<1..2^16-1>; > } DnssecChainExtension; > > A zero "SupportLifetime" prohibits the client from unilaterally > requiring ongoing use of the extension based on prior observation > of its use (pinning). > > A future specification will define the semantics of non-zero > values of the SupportLifetime field. Servers implementing only > the present specification MUST set the SupportLifetime element > to zero. Clients implementing only the present specification MUST > treat any value received as though it were zero. > > --- Change 3: Section 3.4. DNSSEC Authentication Chain Data > * Add denial of existence > > OLD: > > The first RRset in the chain MUST contain the TLSA record set being > presented. [...] > > The subsequent RRsets MUST contain the full set of DNS records needed > to authenticate the TLSA record set from the server's trust anchor. > [...] > > NEW: > > When the response contains validated TLSA records, > the first RRset in the chain MUST contain the TLSA record set being > presented. [...] > > When the response is an authenticated denial of existence, after > any initial DNSSEC-signed CNAME and/or DNAME records redirecting > the requested TLSA RRset, the next RRset in the chain MUST be the > signed SOA record of the domain that is proving the non-existence > of the TLSA RRset or its insecure delegation. The SOA record MUST > be followed by the relevant signed NSEC or NSEC3 records. > > The subsequent RRsets MUST contain the full set of DNS records > needed to authenticate the TLSA record set or denial of existence > response via the server's trust anchor. [...] > > --- Change 4: Section 3.4. DNSSEC Authentication Chain Data > * Add denial of existence examples: > > OLD: > > The following is an example of the records in the AuthenticationChain > [...] > RRSIG(. DNSKEY) > > NEW: > The following is an example of the records in the AuthenticationChain > [...] > RRSIG(. DNSKEY) > > The following is a TLSA RRset denial-of-existence example: > > example.com. IN SOA > RRSIG(example.com. SOA) > example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC > RRSIG(example.com. NSEC) > example.com. DNSKEY > RRSIG(example.com. DNSKEY) > example.com. DS > RRSIG(example.com. DS) > com. DNSKEY > RRSIG(com. DNSKEY) > com. DS > RRSIG(com. DS) > . DNSKEY > RRSIG(. DNSKEY) > > The following is an insecure delegation example (with NSEC3 opt-out): > > com. IN SOA > RRSIG(com. SOA) > GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 - > - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB NS DS RRSIG) > RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3) > com. DNSKEY > RRSIG(com. DNSKEY) > com. DS > RRSIG(com. DS) > . DNSKEY > RRSIG(. DNSKEY) > > --- Change 5: Section 6. Verification > * Add denial of existence > * Note that TLSA records might not be "usable" (new issue > in the document, sorry, but clients should not have to > honour unusable TLSA records) > > OLD: > > A TLS client making use of this specification, and which receives a > DNSSEC authentication chain extension from a server, MUST use this > information to perform DANE authentication of the server. In order > to do this, it uses the mechanism specified by the DNSSEC protocol > [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a > DNSSEC validation engine or library. > > NEW: > > A TLS client making use of this specification, which receives > a verifiable DNSSEC authentication chain extension from a server, > MUST use this information to perform DANE authentication of the > server when the response is not a denial of existence and has > at least one "usable" TLSA record as defined in [RFC6698], [RFC7671] > and any other applicable specifications (perhaps application-specific). > > Verification of the authentication chain extension uses the > mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. > This mechanism is sometimes implemented in a DNSSEC validation > engine or library. > > [... New final paragraph for Section 6 ...] > > Clients MAY also cache a denial of existence response up to the > validated negative TTL of such a response. > > --- Change 6: Section 8. Mandating use of this extension > * Prohibit unilateral pinning, clarify downgrade. > > OLD: > > If TLS applications want to mandate the use of this extension for > specific servers, clients could maintain a whitelist of sites where > the use of this extension is forced. The client would refuse to > authenticate such servers if they failed to deliver this extension. > Client applications could also employ a Trust on First Use (TOFU) > like strategy, whereby they would record the fact that a server > offered the extension and use that knowledge to require it for > subsequent connections. > > This protocol currently provides no way for a server to prove that it > doesn't have a TLSA record. Hence absent whitelists, a client > misdirected to a server that has fraudulently acquired a public CA > issued certificate for the real server's name, could be induced to > establish a PKIX verified connection to the rogue server that > precluded DANE authentication. This could be solved by enhancing > this protocol to require that servers without TLSA records need to > provide a DNSSEC authentication chain that proves this (i.e. the > chain includes NSEC or NSEC3 records that demonstrate either the > absence of the TLSA record, or the absence of a secure delegation to > the associated zone). Such an enhancement would be impossible to > deploy incrementally though since it requires all TLS servers to > support this protocol. > > NEW: > > Pending a future specification that defines the semantics of > non-zero values of the SupportLifetime element of the extension, > clients MUST NOT employ "pinning" to require use of the extension > by servers previously observed to support it. Servers that > implement only this specification MUST set the SupportLifetime > element to zero. > > In the absence of "pinning", when the extension is not mandatory, > a client cannot reliably determine which servers don't have TLSA > records. Hence, a client communicating with a server that has > fraudulently acquired a public CA issued certificate for the real > server's name, could be induced to establish a PKIX verified > connection to a rogue server that simply omits this extension. > > > --- Editorial Appendix A. Test vectors > > s/reproducability/reproducibility/ > > This section should probably include new denial of existence test > vectors. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e79ee3056aba8638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,

Thanks for produc= ing some text. I understand why one might think that having a
res= erved 16-bit field is useful here, but I don't really agree.
=
The conventional reason to reserve this kind of field is tha= t you need to leave
space for an extension in some PDU, because i= t's hard to add later. But that's
not true here (or in TL= S in general) because we already have an extension
mechanism (ind= eed, the one that's being used by this specification). If we
= end up having consensus to do pinning, then it's straightforward to def= ine
a new TLS extension that provides it.

If you look at HPKP and Expect-CT, you will note that there are a n= umber of
other fields besides just lifetime (report-uri, include= subdomains). I recognize
that opinions vary about whether these = are good, but the advantage of having
a whole new extension is th= at we need not resolve those now in order to move
this document f= orward. As far as I can tell, the primary disadvantage of a new
e= xtension is a slight increase in the size of the TLS handshake if the exten= sion
is used (balanced against two wasted bytes in this proposed = design if it is
not used). That doesn't seem like a good set = of tradeoffs.

-Ekr



On Tue,= Apr 24, 2018 at 10:33 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

I've been asked to write up proposed changes to the DNSSEC chain
extension draft (with the 16-bit extension support lifetime field).
In doing that I've discovered that adding the 16-bit field is a
minor tweak to the document text, but, ironically, describing
denial of existence, though a simple idea, requires extensive
surgery to the document.=C2=A0 Below I do both, in the hope that either
or both will prove useful.=C2=A0 Perhaps a concrete proposal will make it easier to reach a mutually-agreeable consensus position, and make it
clear that the requested 16-bits are a reasonable consensus outcome.

I'm also willing to create a pull request against:

=C2=A0 =C2=A0https://github.com/MelindaShor= e/dnssec-serialization

if there's interest in me doing that.=C2=A0 Below I list OLD/NEW text chunks with the name of the section in which they fit.

--- Change 1:=C2=A0 Section 2.=C2=A0 Introduction.
=C2=A0 * Add denial of existence

OLD:

=C2=A0 =C2=A0The extension described here allows a TLS client to request th= at the
=C2=A0 =C2=A0TLS server return the DNSSEC authentication chain correspondin= g to
=C2=A0 =C2=A0its DANE record.=C2=A0 If the server is configured for DANE =C2=A0 =C2=A0authentication, then it performs the appropriate DNS queries, = builds
=C2=A0 =C2=A0the authentication chain, and returns it to the client.=C2=A0 = The server
=C2=A0 =C2=A0will usually use a previously cached authentication chain, but= it
=C2=A0 =C2=A0will need to rebuild it periodically as described in Section 5= .=C2=A0 The
=C2=A0 =C2=A0client then authenticates the chain using a pre-configured tru= st
=C2=A0 =C2=A0anchor.

NEW:

=C2=A0 =C2=A0The extension described here allows a TLS client to request th= at the
=C2=A0 =C2=A0TLS server return the DNSSEC authentication chain correspondin= g to
=C2=A0 =C2=A0its DANE TLSA resource record set (RRset), or authenticated de= nial
=C2=A0 =C2=A0of existence of that RRset.=C2=A0 If the server supports this = extension
=C2=A0 =C2=A0it performs the appropriate DNS queries, builds the authentica= tion
=C2=A0 =C2=A0chain, and returns it to the client.=C2=A0 The server will usu= ally
=C2=A0 =C2=A0use a previously cached authentication chain, but it will need=
=C2=A0 =C2=A0to rebuild it periodically as described in Section 5.=C2=A0 Th= e client
=C2=A0 =C2=A0then authenticates the chain using a pre-configured trust anch= or.

=C2=A0 =C2=A0When the requested TLSA RRset does not exist, and/or the conta= ining
=C2=A0 =C2=A0DNS zone is not DNSSEC-signed, the server MAY return a chain o= f
=C2=A0 =C2=A0records that establish authenticated denial of existence of th= e
=C2=A0 =C2=A0TLSA RRset, or prove insecure delegation (an ancestor) of that= domain.
=C2=A0 =C2=A0Alternatively, the server MAY simply not negotiate the extensi= on.


--- Change 2:=C2=A0 Section 3.4.=C2=A0 DNSSEC Authentication Chain Data
=C2=A0 * Add 16-bit SupportLifetime field

OLD:

=C2=A0 =C2=A0The "extension_data" field of the "dnssec_chain= " extension MUST
=C2=A0 =C2=A0contain a DNSSEC Authentication Chain encoded in the following= form:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque AuthenticationChain&= lt;1..2^16-1>


NEW:

=C2=A0 =C2=A0The "extension_data" field of the "dnssec_chain= " extension MUST
=C2=A0 =C2=A0contain a DNSSEC Authentication Chain encoded in the following= form:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 SupportLifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque AuthenticationChain&= lt;1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } DnssecChainExtension;

=C2=A0 =C2=A0A zero "SupportLifetime" prohibits the client from u= nilaterally
=C2=A0 =C2=A0requiring ongoing use of the extension based on prior observat= ion
=C2=A0 =C2=A0of its use (pinning).

=C2=A0 =C2=A0A future specification will define the semantics of non-zero =C2=A0 =C2=A0values of the SupportLifetime field.=C2=A0 Servers implementin= g only
=C2=A0 =C2=A0the present specification MUST set the SupportLifetime element=
=C2=A0 =C2=A0to zero.=C2=A0 Clients implementing only the present specifica= tion MUST
=C2=A0 =C2=A0treat any value received as though it were zero.

--- Change 3:=C2=A0 Section 3.4.=C2=A0 DNSSEC Authentication Chain Data
=C2=A0 * Add denial of existence

OLD:

=C2=A0 =C2=A0The first RRset in the chain MUST contain the TLSA record set = being
=C2=A0 =C2=A0presented.=C2=A0 [...]

=C2=A0 =C2=A0The subsequent RRsets MUST contain the full set of DNS records= needed
=C2=A0 =C2=A0to authenticate the TLSA record set from the server's trus= t anchor.
=C2=A0 =C2=A0[...]

NEW:

=C2=A0 =C2=A0When the response contains validated TLSA records,
=C2=A0 =C2=A0the first RRset in the chain MUST contain the TLSA record set = being
=C2=A0 =C2=A0presented.=C2=A0 [...]

=C2=A0 =C2=A0When the response is an authenticated denial of existence, aft= er
=C2=A0 =C2=A0any initial DNSSEC-signed CNAME and/or DNAME records redirecti= ng
=C2=A0 =C2=A0the requested TLSA RRset, the next RRset in the chain MUST be = the
=C2=A0 =C2=A0signed SOA record of the domain that is proving the non-existe= nce
=C2=A0 =C2=A0of the TLSA RRset or its insecure delegation.=C2=A0 The SOA re= cord MUST
=C2=A0 =C2=A0be followed by the relevant signed NSEC or NSEC3 records.

=C2=A0 =C2=A0The subsequent RRsets MUST contain the full set of DNS records=
=C2=A0 =C2=A0needed to authenticate the TLSA record set or denial of existe= nce
=C2=A0 =C2=A0response via the server's trust anchor.=C2=A0 [...]

--- Change 4:=C2=A0 Section 3.4.=C2=A0 DNSSEC Authentication Chain Data
=C2=A0 * Add denial of existence examples:

OLD:

=C2=A0 =C2=A0The following is an example of the records in the Authenticati= onChain
=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(. DNSKEY)

NEW:
=C2=A0 =C2=A0The following is an example of the records in the Authenticati= onChain
=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(. DNSKEY)

=C2=A0 =C2=A0The following is a TLSA RRset denial-of-existence example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. IN SOA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(example.com. SOA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. IN NSEC www.exampl= e.com. SOA NS MX A RRSIG NSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(example.com. NSEC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. DNSKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(example.com. DNSKEY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example.com. DS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(example.com. DS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com. DNSKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(com. DNSKEY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com. DS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(com. DS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. DNSKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(. DNSKEY)

=C2=A0 =C2=A0The following is an insecure delegation example (with NSEC3 op= t-out):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com. IN SOA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(com. SOA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPINPHP5MI1PVD5L045CP3KP81E= 0JHAS.com. NSEC3 (1 1 0 -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - GPIOVE5CC3CA0D1H1= 4G1GI4J0835GEKB=C2=A0 NS DS RRSIG)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(GPINPHP5MI1PVD5L= 045CP3KP81E0JHAS.com. NSEC3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com. DNSKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(com. DNSKEY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com. DS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(com. DS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. DNSKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRSIG(. DNSKEY)

--- Change 5: Section 6.=C2=A0 Verification
=C2=A0 * Add denial of existence
=C2=A0 * Note that TLSA records might not be "usable" (new issue<= br> =C2=A0 =C2=A0 in the document, sorry, but clients should not have to
=C2=A0 =C2=A0 honour unusable TLSA records)

OLD:

=C2=A0 =C2=A0A TLS client making use of this specification, and which recei= ves a
=C2=A0 =C2=A0DNSSEC authentication chain extension from a server, MUST use = this
=C2=A0 =C2=A0information to perform DANE authentication of the server.=C2= =A0 In order
=C2=A0 =C2=A0to do this, it uses the mechanism specified by the DNSSEC prot= ocol
=C2=A0 =C2=A0[RFC4035] [RFC5155].=C2=A0 This mechanism is sometimes impleme= nted in a
=C2=A0 =C2=A0DNSSEC validation engine or library.

NEW:

=C2=A0 =C2=A0A TLS client making use of this specification, which receives<= br> =C2=A0 =C2=A0a verifiable DNSSEC authentication chain extension from a serv= er,
=C2=A0 =C2=A0MUST use this information to perform DANE authentication of th= e
=C2=A0 =C2=A0server when the response is not a denial of existence and has<= br> =C2=A0 =C2=A0at least one "usable" TLSA record as defined in [RFC= 6698], [RFC7671]
=C2=A0 =C2=A0and any other applicable specifications (perhaps application-s= pecific).

=C2=A0 =C2=A0Verification of the authentication chain extension uses the =C2=A0 =C2=A0mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]= .
=C2=A0 =C2=A0This mechanism is sometimes implemented in a DNSSEC validation=
=C2=A0 =C2=A0engine or library.

=C2=A0 =C2=A0[... New final paragraph for Section 6 ...]

=C2=A0 =C2=A0Clients MAY also cache a denial of existence response up to th= e
=C2=A0 =C2=A0validated negative TTL of such a response.

--- Change 6: Section 8.=C2=A0 Mandating use of this extension
=C2=A0 * Prohibit unilateral pinning, clarify downgrade.

OLD:

=C2=A0 =C2=A0If TLS applications want to mandate the use of this extension = for
=C2=A0 =C2=A0specific servers, clients could maintain a whitelist of sites = where
=C2=A0 =C2=A0the use of this extension is forced.=C2=A0 The client would re= fuse to
=C2=A0 =C2=A0authenticate such servers if they failed to deliver this exten= sion.
=C2=A0 =C2=A0Client applications could also employ a Trust on First Use (TO= FU)
=C2=A0 =C2=A0like strategy, whereby they would record the fact that a serve= r
=C2=A0 =C2=A0offered the extension and use that knowledge to require it for=
=C2=A0 =C2=A0subsequent connections.

=C2=A0 =C2=A0This protocol currently provides no way for a server to prove = that it
=C2=A0 =C2=A0doesn't have a TLSA record.=C2=A0 Hence absent whitelists,= a client
=C2=A0 =C2=A0misdirected to a server that has fraudulently acquired a publi= c CA
=C2=A0 =C2=A0issued certificate for the real server's name, could be in= duced to
=C2=A0 =C2=A0establish a PKIX verified connection to the rogue server that<= br> =C2=A0 =C2=A0precluded DANE authentication.=C2=A0 This could be solved by e= nhancing
=C2=A0 =C2=A0this protocol to require that servers without TLSA records nee= d to
=C2=A0 =C2=A0provide a DNSSEC authentication chain that proves this (i.e. t= he
=C2=A0 =C2=A0chain includes NSEC or NSEC3 records that demonstrate either t= he
=C2=A0 =C2=A0absence of the TLSA record, or the absence of a secure delegat= ion to
=C2=A0 =C2=A0the associated zone).=C2=A0 Such an enhancement would be impos= sible to
=C2=A0 =C2=A0deploy incrementally though since it requires all TLS servers = to
=C2=A0 =C2=A0support this protocol.

NEW:

=C2=A0 =C2=A0Pending a future specification that defines the semantics of =C2=A0 =C2=A0non-zero values of the SupportLifetime element of the extensio= n,
=C2=A0 =C2=A0clients MUST NOT employ "pinning" to require use of = the extension
=C2=A0 =C2=A0by servers previously observed to support it.=C2=A0 Servers th= at
=C2=A0 =C2=A0implement only this specification MUST set the SupportLifetime=
=C2=A0 =C2=A0element to zero.

=C2=A0 =C2=A0In the absence of "pinning", when the extension is n= ot mandatory,
=C2=A0 =C2=A0a client cannot reliably determine which servers don't hav= e TLSA
=C2=A0 =C2=A0records. Hence, a client communicating with a server that has<= br> =C2=A0 =C2=A0fraudulently acquired a public CA issued certificate for the r= eal
=C2=A0 =C2=A0server's name, could be induced to establish a PKIX verifi= ed
=C2=A0 =C2=A0connection to a rogue server that simply omits this extension.=


--- Editorial Appendix A.=C2=A0 Test vectors

=C2=A0 s/reproducability/reproducibility/

=C2=A0 This section should probably include new denial of existence test ve= ctors.

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

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

--000000000000e79ee3056aba8638-- From nobody Thu Apr 26 02:31:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C757612420B for ; Thu, 26 Apr 2018 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HzXw9L-BRZzw for ; Thu, 26 Apr 2018 02:31:52 -0700 (PDT) Received: from 10.mo178.mail-out.ovh.net (10.mo178.mail-out.ovh.net [46.105.76.150]) (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 A7DCC126579 for ; Thu, 26 Apr 2018 02:31:52 -0700 (PDT) Received: from player728.ha.ovh.net (unknown [10.109.108.48]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 91D031188A for ; Thu, 26 Apr 2018 11:31:50 +0200 (CEST) Received: from [10.41.51.106] (134.163-14-84.ripe.coltfrance.com [84.14.163.134]) (Authenticated sender: contact@simonbernard.eu) by player728.ha.ovh.net (Postfix) with ESMTPSA id 5BB56540098; Thu, 26 Apr 2018 11:31:43 +0200 (CEST) To: Eric Rescorla Cc: "tls@ietf.org" References: From: Simon Bernard Message-ID: Date: Thu, 26 Apr 2018 11:31:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------07139250823B819C74864B97" Content-Language: en-US X-Ovh-Tracer-Id: 11278702319763732721 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrleefgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 09:31:57 -0000 This is a multi-part message in MIME format. --------------07139250823B819C74864B97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Eric, thx a lot for your answer. We are discussing a lot about that with our community and there is still no consensus ... So I come back to you to have clearer information to help us to make the good decision. Using DTLS with PSK over UDP, without re-negotiation allowed : - Is there known security issue about sending the same alert for both "unknown identity" and "bad_psk"(invalid record for handshake message) ? "Discarding records aims to preserve current association", if we are able to preserve current association using : - no renegotiation allowed, - send alert for invalid record only for handshake record and if we have an ongoing handshake, - In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, destroy the existing association only if the client has demonstrated reachability by completing a cookie exchange. Should it be OK ? Thx again for your time. Simon Le 06/04/2018 à 19:26, Eric Rescorla a écrit : > > > On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard > > wrote: > > Hi, > > We are implementing DTLS with PSK over UDP and I would like to > know how "unknown identity" and "bad psk" should be handled > > Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says : > (https://tools.ietf.org/html/rfc4279#section-2 > ) > > >   If the server does not recognize the PSK identity, it MAY respond > >   with an "unknown_psk_identity" alert message. Alternatively, > if the > >   server wishes to hide the fact that the PSK identity was not > known, > >   it MAY continue the protocol as if the PSK identity existed > but the > >   key was incorrect: that is, respond with a "decrypt_error" alert. > > In TLS the safer way seems to send a "decrypt_error" alert for both. > > But in DTLS : > https://tools.ietf.org/html/rfc6347#section-4.1.2.7 > > > >   In general, invalid records > >   SHOULD be silently discarded, thus preserving the association; > >   however, an error MAY be logged for diagnostic purposes. > >   Implementations which choose to generate an alert instead, MUST > >   generate fatal level alerts to avoid attacks where the attacker > >   repeatedly probes the implementation to see how it responds to > >   various types of error.  Note that if DTLS is run over UDP, > then any > >   implementation which does this will be extremely susceptible to > >   denial-of-service (DoS) attacks because UDP forgery is so easy. > >   Thus, this practice is NOT RECOMMENDED for such transports. > > Is this record layer recommendation for all type of record ? even > HANDSHAKE(22) record (and so FINISHED message) or is it mainly for > APPLICATION_DATA(23) record ? > > Is it acceptable to send fatal alert "decrypt_error" in DTLS or > should we just ignore bad credentials silently ? > > > Hi  Simon, > > The advice in 4279 is basically "make an unknown identity look like a > bad key". So the idea would be to just randomize the key and then get > the TLS or DTLS-type behavior. I.e., with TLS you would send > decrypt_error and in DTLS the handshake would just stall because you > would drop packets. > > -Ekr > > -- > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --------------07139250823B819C74864B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Eric, thx a lot for your answer.

We are discussing a lot about that with our community and there is still no consensus ...

So I come back to you to have clearer information to help us to make the good decision.

Using DTLS with PSK over UDP, without re-negotiation allowed :
- Is there known security issue about sending the same alert for both "unknown identity" and "bad_psk"(invalid record for handshake message) ?

"Discarding records aims to preserve current association", if we are able to preserve current association using :
- no renegotiation allowed,
- send alert for invalid record only for handshake record and if we have an ongoing handshake,
- In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, destroy the existing association only if the client has demonstrated reachability by completing a cookie exchange.

Should it be OK ?

Thx again for your time.

Simon

Le 06/04/2018 à 19:26, Eric Rescorla a écrit :


On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <contact@simonbernard.eu> wrote:
Hi,

We are implementing DTLS with PSK over UDP and I would like to know how "unknown identity" and "bad psk" should be handled

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)

>   If the server does not recognize the PSK identity, it MAY respond
>   with an "unknown_psk_identity" alert message. Alternatively, if the
>   server wishes to hide the fact that the PSK identity was not known,
>   it MAY continue the protocol as if the PSK identity existed but the
>   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7

>   In general, invalid records
>   SHOULD be silently discarded, thus preserving the association;
>   however, an error MAY be logged for diagnostic purposes.
>   Implementations which choose to generate an alert instead, MUST
>   generate fatal level alerts to avoid attacks where the attacker
>   repeatedly probes the implementation to see how it responds to
>   various types of error.  Note that if DTLS is run over UDP, then any
>   implementation which does this will be extremely susceptible to
>   denial-of-service (DoS) attacks because UDP forgery is so easy.
>   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even HANDSHAKE(22) record (and so FINISHED message) or is it mainly for APPLICATION_DATA(23) record ?

Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we just ignore bad credentials silently ?

Hi  Simon,

The advice in 4279 is basically "make an unknown identity look like a bad key". So the idea would be to just randomize the key and then get the TLS or DTLS-type behavior. I.e., with TLS you would send decrypt_error and in DTLS the handshake would just stall because you would drop packets.

-Ekr

--
Simon

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


--------------07139250823B819C74864B97-- From nobody Thu Apr 26 06:51:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013531243F3 for ; Thu, 26 Apr 2018 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XTMQA-5O51qF for ; Thu, 26 Apr 2018 06:51:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595E912422F for ; Thu, 26 Apr 2018 06:51:40 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 886A07A3309 for ; Thu, 26 Apr 2018 13:51:39 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 09:51:37 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 13:51:50 -0000 > On Apr 26, 2018, at 2:30 AM, Eric Rescorla wrote: >=20 > If you look at HPKP and Expect-CT, you will note that there are a = number of > other fields besides just lifetime (report-uri, include subdomains). I = recognize > that opinions vary about whether these are good, but the advantage of = having > a whole new extension is that we need not resolve those now in order = to move > this document forward. Let's ignore HPKP, as discussed previously it is a poor analogy here, (and, not entirely surprisingly an impractical design). A somewhat better comparison is Expect-CT or MTA-STS. Both of these have a max-age. Neither of them is "forever". We can safely assume that *any* mechanism to negotiate downgrade protection for this extension between server and client will have a finite duration. Neither of the comparison specs are TLS extensions intended to cover a broad range of applications. They are single application policy mechanisms communicated via HTTP headers. Here, our scope is *all* end-user applications that choose to use the DNSSEC chain extension to access the server's DANE TLSA records. If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we find: * a lifetime field * enforce vs. test * a report URI This specification is always "enforce" (though my pull request changes a MUST use DANE to a SHOULD with some necessary added conditions) and since the report URI is in good measure to support non-enforce mode, we're back to just max-age. > As far as I can tell, the primary disadvantage of a new > extension is a slight increase in the size of the TLS handshake if the = extension > is used (balanced against two wasted bytes in this proposed design if = it is > not used). That doesn't seem like a good set of tradeoffs. Well, here I appeal to Melinda's observation that specifications need to closely consider implementation complexity, not just specification complexity. Indeed implementation complexity should be the primary concern. A major disadvantage of a separate extension (rather than adding semantics to an existing field) is that implementations will then need to add code to generate and consume a second extension, integrate the new code point, handle combinatorial logic of receiving either extension or both, ... Including the field now removes the need to ask libraries to add code for a second extension, complicating the API and complicating the code that applications need to call to make use of the combined data. Worst case the chain extension carries an extra 16 bits of zeros, which by the way explicitly signal: do not do unilateral pinning. There's really much too little to object to and real potential benefit. --=20 Viktor. From nobody Thu Apr 26 07:50:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7812DA15 for ; Thu, 26 Apr 2018 07:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 46PhrZJpJIH9 for ; Thu, 26 Apr 2018 07:50:50 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52AC126BF7 for ; Thu, 26 Apr 2018 07:50:49 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id f63-v6so24386626oic.4 for ; Thu, 26 Apr 2018 07:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=75AbODfrpiB3PcmOzpsKU7RWAyNG8uFhq3E7IO/tewo=; b=KA650/0DkmDboFSwMLBce43C7v2xGuEpOlrURNamL9wf/ZsItdTqOiDZnQ2F7zM1ji unEteDkNkutqe++/ZE0irJeX33pXjZFgnRlboiHuRZLKnfHsnMPNCnL6GYD0BSPt8UTq rNjMvaZMTNP9e5VdyJRdKsm8dg7bBl/ueANPBg5ZA1hdXphGbIYn+HL+UZ3F4yv0qcWU F77H+Vpv5LfqgY2+msPgQrNae75yt1y6UROeuViOufxLmJzX6WcxGCbZMWnVPRruZa+M 0q4hv1SjWDHWgjhaXWyZxiddRcyaqpcDSgkd0SmI3frGAZiTVunFH7Z9UxqJwq+05pLD lCkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=75AbODfrpiB3PcmOzpsKU7RWAyNG8uFhq3E7IO/tewo=; b=YYkoN0adi5VPZIl6r8+NVE56RG5wqR9MlNVNaTI4v5JGNZoa07xLduisfvtR+BL6P6 FQz9k414nOhnOVoEZ81W0m8Y+nMTB6NB5Goc1m3ZJdBdW7cdEVj+JO1K6iA9oXMTC8pc Sz79hhE410431YBft1bLFLgX8bskXVu0zXOGH9hIqSrNaYG5eSN4BcCRv2dFvhBBmpsQ mijrNdh1RYXye7S09E1ua02tzelQSDD1zUf7ta6MDmHeXG1w1IOOhwHmBbiUQ3JkN21H Q+HX9TtSleIOirmFAy9ORCONbgkNvZquTngajmcNHpoJmxz9yYxeNHgE2gxTCwP4QqiN 3g6A== X-Gm-Message-State: ALQs6tBTG89I2KKXpSsgxYsdhKi1orPOWEa4v85cMJRo7l500JCiKsoH dLIv4i5qsJ51chUsEqYxF+re0mM8xhbpszIx2f2Zv1PC X-Google-Smtp-Source: AIpwx4+vpBhRCYfpldPmP3SrEsXVRymlhm/Rdv7IzKQ6UVEhhqVGiFQO8t/zw+av6IcAjJnvuHOZV4hM7vWWMkX2br8= X-Received: by 2002:aca:c754:: with SMTP id x81-v6mr14151957oif.43.1524754248880; Thu, 26 Apr 2018 07:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 26 Apr 2018 07:50:08 -0700 (PDT) In-Reply-To: <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> From: Eric Rescorla Date: Thu, 26 Apr 2018 07:50:08 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000005fe903056ac1837f" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 14:50:51 -0000 --0000000000005fe903056ac1837f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni wrote: > > > > On Apr 26, 2018, at 2:30 AM, Eric Rescorla wrote: > > > > If you look at HPKP and Expect-CT, you will note that there are a number > of > > other fields besides just lifetime (report-uri, include subdomains). I > recognize > > that opinions vary about whether these are good, but the advantage of > having > > a whole new extension is that we need not resolve those now in order to > move > > this document forward. > > Let's ignore HPKP, as discussed previously it is a poor analogy > here, (and, not entirely surprisingly an impractical design). > A somewhat better comparison is Expect-CT or MTA-STS. > > Both of these have a max-age. Neither of them is "forever". We > can safely assume that *any* mechanism to negotiate downgrade > protection for this extension between server and client will > have a finite duration. > > Neither of the comparison specs are TLS extensions intended to cover > a broad range of applications. They are single application policy > mechanisms communicated via HTTP headers. > > Here, our scope is *all* end-user applications that choose to use > the DNSSEC chain extension to access the server's DANE TLSA > records. > If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we > find: > > * a lifetime field > * enforce vs. test > * a report URI > > This specification is always "enforce" (though my pull request > changes a MUST use DANE to a SHOULD with some necessary added > conditions) and since the report URI is in good measure to > support non-enforce mode, we're back to just max-age. > But this reinforces my point. I think we ought to have an enforce vs test flag and a report URI (and I I don't find your arguments above about why we shouldn't do this persuasive.) Standardizing this functionality would require resolving these issues. -Ekr --0000000000005fe903056ac1837f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 26, 2018, at 2:30 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> If you look at HPKP and Expect-CT, you will note that there are a numb= er of
> other fields besides just lifetime (report-uri, include subdomains). I= recognize
> that opinions vary about whether these are good, but the advantage of = having
> a whole new extension is that we need not resolve those now in order t= o move
> this document forward.

Let's ignore HPKP, as discussed previously it is a poor analogy<= br> here, (and, not entirely surprisingly an impractical design).
A somewhat better comparison is Expect-CT or MTA-STS.

Both of these have a max-age.=C2=A0 Neither of them is "forever".= =C2=A0 We
can safely assume that *any* mechanism to negotiate downgrade
protection for this extension between server and client will
have a finite duration.

Neither of the comparison specs are TLS extensions intended to cover
a broad range of applications.=C2=A0 They are single application policy
mechanisms communicated via HTTP headers.

Here, our scope is *all* end-user applications that choose to use
the DNSSEC chain extension to access the server's DANE TLSA
records.

If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
find:

=C2=A0 * a lifetime field
=C2=A0 * enforce vs. test
=C2=A0 * a report URI

This specification is always "enforce" (though my pull request changes a MUST use DANE to a SHOULD with some necessary added
conditions) and since the report URI is in good measure to
support non-enforce mode, we're back to just max-age.
<= div>
But this reinforces my point. I think we ought to have a= n enforce vs test flag and a report URI (and I I don't find your argume= nts above about why we shouldn't do this persuasive.)=C2=A0 Standardizi= ng this functionality would require resolving these issues.
<= br>
-Ekr

--0000000000005fe903056ac1837f-- From nobody Thu Apr 26 08:05:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D302612DA17 for ; Thu, 26 Apr 2018 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 L27dqcJlw5_V for ; Thu, 26 Apr 2018 08:05:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1D3127241 for ; Thu, 26 Apr 2018 08:05:35 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 00ABE7A3309 for ; Thu, 26 Apr 2018 15:05:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 11:05:32 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:05:37 -0000 > On Apr 26, 2018, at 10:50 AM, Eric Rescorla wrote: >=20 >> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we >> find: >>=20 >> * a lifetime field >> * enforce vs. test >> * a report URI >>=20 >> This specification is always "enforce" (though my pull request >> changes a MUST use DANE to a SHOULD with some necessary added >> conditions) and since the report URI is in good measure to >> support non-enforce mode, we're back to just max-age. >>=20 > But this reinforces my point. I think we ought to have an enforce vs = test flag and a report URI (and I I don't find your arguments above = about why we shouldn't do this persuasive.) Standardizing this = functionality would require resolving these issues. We should observe that "enforce vs. test" is already moot, this document implies enforce. If you wanted a test mode and a reporting URI, these would have to be part of the present extension. When the server = presents is DANE TLSA records, the client will enforce them (for just one = session, but we should assume that downgrade attacks, while evermore common are = not the norm). The signal to do DANE (by virtue of delivering TLSA records) is the = primary change, and it is delivered via the present extension, the "pinning" = we're proposing is NOT "pinning" to deliver TLSA records and do DANE, it is = merely downgrade protection for the signalling channel! The "pin" can be = satisfied with a denial of existence response. Compliant servers merely need a = software capability (to send the signal), the "pin" does not enforce new security mechanisms. Downgrade protection for DANE signalling DOES NOT need any of those = other bells and whistles. They would, if needed, belong in this = specification, not in a tweak to harden the signalling. --=20 Viktor. From nobody Thu Apr 26 08:15:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5E12DA17 for ; Thu, 26 Apr 2018 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 t5iKyyqnXt1S for ; Thu, 26 Apr 2018 08:14:57 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CBA127241 for ; Thu, 26 Apr 2018 08:14:57 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id t27-v6so24424854oij.9 for ; Thu, 26 Apr 2018 08:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ejUCtxf0ur6JIzXrU7slkcNe2LGKzWL9BWwRny/Xu+M=; b=itUmJ1IvCj0OoHp8FXVwfVs5/hyEqtczdzZelGS4kU/Ud8aho8Zja1CFGXFYVpastb yAPq9g8+4rFWDwxIBaKiupcD20cEqITQ6ejbPY0yQqETOVe+Tr5jIEl9wpNjvn7hy7q9 YpHHQjpLD8j02GXHzzKWFJRRBsHZ3aWrlaDa1LGoe0/NP+G0+YZZ+csERhFv7Ulm4Z6d 4aJkIYGflLxLCxX86tzFlfXPfCMQ4DbVQi+yQyN7KLdF5vDD776Tfo8M0gD49I6fzspk Jrqm1b/+UCk+2jnUHot02bQSrGBHB7c1jEFkS014GXOItJQ1k59V+bLsssSqg193c2zs iX6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ejUCtxf0ur6JIzXrU7slkcNe2LGKzWL9BWwRny/Xu+M=; b=FyF0WFHyxwjlYy0u2pcRD+2OE78RQaECPVqoSGGHtXe18Snje8/WTVdJZcm7o8W4rD idGmahvxzunuZDrPgOe6Kkxm+87HgfjORDbTWvE8e7VVAlUzVMfGNQ9bHyhqreBuYdhn 8btXnSp32LHcnKte7xq4hcAJE9NN/1nfsLOJEkbWzNGhx9dXR/UNRyI0yseRxSAOIby1 OiS84CPpdIfpgWQ3QL5Wz+nty7ic/NjkD7bBIMheMpqM41IQV21ecfbAIz1q1kiAm9ih kor/tSjM86X/3UE3TkXLax+NfCHY+3E3/TfsxjYsLjNPP59GQc6RkWP+QC3mfQFe/U+b dhrQ== X-Gm-Message-State: ALQs6tAujQcHx7+aem7t3ZUQygQKe4TqPdkJlL6JgOVhJ3yhID7hVBCR uNOpr5/vOvatVN6wnjSh4s+8za7QUdf4Fa31arEt1u0o X-Google-Smtp-Source: AB8JxZoIX/RnIM+HRyzQD7CE+K6GEx/pqCnJYxFRyHIjQMsH+5/Ep3/VFz8AuJIAMOiz1nW0IM8SwJExQo+1/mtF63c= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr6839355oin.108.1524755696726; Thu, 26 Apr 2018 08:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 26 Apr 2018 08:14:16 -0700 (PDT) In-Reply-To: References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> From: Eric Rescorla Date: Thu, 26 Apr 2018 08:14:16 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000ac81d5056ac1d919" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:14:59 -0000 --000000000000ac81d5056ac1d919 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni wrote: > > > > On Apr 26, 2018, at 10:50 AM, Eric Rescorla wrote: > > > >> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we > >> find: > >> > >> * a lifetime field > >> * enforce vs. test > >> * a report URI > >> > >> This specification is always "enforce" (though my pull request > >> changes a MUST use DANE to a SHOULD with some necessary added > >> conditions) and since the report URI is in good measure to > >> support non-enforce mode, we're back to just max-age. > >> > > But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments above about > why we shouldn't do this persuasive.) Standardizing this functionality > would require resolving these issues. > > We should observe that "enforce vs. test" is already moot, this document > implies enforce. If you wanted a test mode and a reporting URI, these > would have to be part of the present extension. You seem to be assuming that the only thing you might want to test is the DANE chain for this specific connection. Consider the case where you have a big server farm and you want to roll this mechanism out, but you're concerned about whether you're getting every server configured properly. You set this with pinning on and test mode + reporting URI, and then wait to see if you get reports, which would indicate that a server is misconfigured. Anyway, we're now having the discussion about exactly what would be be required to make pinning work, which, as I said, demonstrates that it's premature to just add a placeholder age field for this functionality. -Ekr --000000000000ac81d5056ac1d919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On Apr 26, 2018, at 10:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
>> find:
>>
>>=C2=A0 =C2=A0* a lifetime field
>>=C2=A0 =C2=A0* enforce vs. test
>>=C2=A0 =C2=A0* a report URI
>>
>> This specification is always "enforce" (though my pull r= equest
>> changes a MUST use DANE to a SHOULD with some necessary added
>> conditions) and since the report URI is in good measure to
>> support non-enforce mode, we're back to just max-age.
>>
> But this reinforces my point. I think we ought to have an enforce vs t= est flag and a report URI (and I I don't find your arguments above abou= t why we shouldn't do this persuasive.)=C2=A0 Standardizing this functi= onality would require resolving these issues.

We should observe that "enforce vs. test" is already moot,= this document
implies enforce.=C2=A0 If you wanted a test mode and a reporting URI, these=
would have to be part of the present extension.

= You seem to be assuming that the only thing you might want to test is
=
the DANE chain for this specific connection.

Con= sider the case where you have a big server farm and you want to
roll th= is mechanism out, but you're concerned about whether you're getting=
every server configured properly. You set this with pinning on a= nd test mode
+ reporting URI, and then wait to see if you get rep= orts, which would indicate
that a server is misconfigured.
<= div>
Anyway, we're now having the discussion about exactl= y what would be be
required to make pinning work, which, as I sai= d, demonstrates that it's
premature to just add a placeholder= age field for this functionality.

-Ekr
<= div>


--000000000000ac81d5056ac1d919-- From nobody Thu Apr 26 08:19:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3842127241 for ; Thu, 26 Apr 2018 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqzPDPVKy9jS for ; Thu, 26 Apr 2018 08:19:37 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC41B12DA17 for ; Thu, 26 Apr 2018 08:19:37 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 28559A004B84; Thu, 26 Apr 2018 08:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZxlifciczDxjF+ z2ac1wvg6Ykbs=; b=J++otNZLTimn240oS49WD3Q6t6WiyRdgku/MEWRtLwE7fd DPLNXCpwZXt8cJAGKmhd9u+VLbnKrq14hXddBbypNankgH7ohV6ux4qjUwUlRN0T PEusZZ0AU9SFo2b2DwcYEc+87fOVRoTe3uvsOU5u3qYRhreFpXdDkecziImLo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id BC9B6A004B82; Thu, 26 Apr 2018 08:19:36 -0700 (PDT) Date: Thu, 26 Apr 2018 10:13:07 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180426151305.GL25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:19:39 -0000 On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote: > Thanks for producing some text. I understand why one might think that > having a reserved 16-bit field is useful here, but I don't really > agree. > > The conventional reason to reserve this kind of field is that you need > to leave space for an extension in some PDU, because it's hard to add > later. But that's not true here (or in TLS in general) because we -07 has text on pinning. There is no consensus on making that work _now_. There is only consensus on removing that text and revisiting pinning later. Well, later we will need these two bytes. So there's the conventional reason to reserve this kind of field: because we know we will need it, and adding it via some extension facility will be harder than... already having it. And yes, we (the IETF) do use reserved fields even in protocols where there is extensibility. > already have an extension mechanism (indeed, the one that's being used > by this specification). If we end up having consensus to do pinning, > then it's straightforward to define a new TLS extension that provides > it. Having these two bytes now will mean that they are always present, which will make it a lot easier for implementations to a) start sending non-zero values, b) start handling non-zero values, once we write a spec on what non-zero values mean. (And we know what that spec will say, which is why we know we need two bytes.) > If you look at HPKP and Expect-CT, you will note that there are a > [...] HPKP is completely different. The idea here is NOT to pin key material, CAs, or anything of the sort. The idea here is to pin only the use of this extension, and this does not even bind one to use DANE because the extension can carry a denial of existence. Nico -- From nobody Thu Apr 26 08:22:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68112DA27 for ; Thu, 26 Apr 2018 08:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 l8tSnlGN--4i for ; Thu, 26 Apr 2018 08:22:41 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6B6127241 for ; Thu, 26 Apr 2018 08:22:41 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id f63-v6so24495281oic.4 for ; Thu, 26 Apr 2018 08:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kCIggaYA/71vPMJZc9zILCDgq5tSouTYaTXsmSwSrik=; b=Tys1cY5P28Wn94toCJpQ3Su0CnEikRaBpyPKn/Xs3CMnh6YCefsHKZAEBJnjxVH33I iuJlVyCoIWb/tUySMOVvgdPVULUuYHGq7HYSdf/EygEiDPB5qMkkRfbDQcMR1UALpHHQ bY6UHCvqTFkMooKLx9lUhb6i3x1VQQrIV9ueAHMaY0rDeOTSfUI5r/ongtoSBUtnKG5e V83ySUwFOko+3sb9jZcJMgiuNqQ7YxBWviuoPF3WwpWlFBfe7lH4MMnkCwqo0VuP40PV nypXcEtDkVzG0sCIUUZmYFi0BTyEPCCSndo/foVZzhA5i4lkrNBZIo9su1E2FbyLPqnx nvnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kCIggaYA/71vPMJZc9zILCDgq5tSouTYaTXsmSwSrik=; b=EfDJ7pIdCIq+1GRnKoko2WaqKYdd2jC1czJEtB6TJ71NsToIUJ5LloQMswfbROWeMP daz7ML+Awcup1P+DqPuuv88HlxGTLMxMluG+HTgOJBDaePY09T6BYiMj9W4p7wVgJyoK nu9SU1xoYMxTAGcZeANIKc6dZ4mPZay1McLLKVvXg6TIhAOS8vHgiR33z+YBF5bO2PmV +LUXNCPvtTNXNH0jDA1lL9ioaXhNxMuB45RAGoGrBQgQH5X/REIkhGiwhHEdQ76CYomW HWu36Vf2bZWcoqxmRFj4SFNv1IgDyhzp9TzQikIZF0INKURGUrjbXILmL7okRrJtr9yK 1YSg== X-Gm-Message-State: ALQs6tBf5aA1fMqiBanv6kNqZLwfarQu9/oy9BdQoDNSO4znsz3KDBHE GuIW+iJcWvFryqbMTSHnpWdKgayrcVookyZU/H/MZXfe X-Google-Smtp-Source: AIpwx49Rb5H8JihKpy5PV2esAgRsF4erpqOo/lWIjusCBIRq8LX2QBuv11yFThZQlqeEA9k9q5vsyE7+LPaGO09vlZU= X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr19670611oig.155.1524756160498; Thu, 26 Apr 2018 08:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.121.149 with HTTP; Thu, 26 Apr 2018 08:22:40 -0700 (PDT) In-Reply-To: <20180426151305.GL25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <20180426151305.GL25259@localhost> From: Richard Barnes Date: Thu, 26 Apr 2018 11:22:40 -0400 Message-ID: To: Nico Williams Cc: Eric Rescorla , TLS WG Content-Type: multipart/alternative; boundary="00000000000050e1b9056ac1f586" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:22:43 -0000 --00000000000050e1b9056ac1f586 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams wrote: > On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote: > > Thanks for producing some text. I understand why one might think that > > having a reserved 16-bit field is useful here, but I don't really > > agree. > > > > The conventional reason to reserve this kind of field is that you need > > to leave space for an extension in some PDU, because it's hard to add > > later. But that's not true here (or in TLS in general) because we > > -07 has text on pinning. There is no consensus on making that work > _now_. There is only consensus on removing that text and revisiting > pinning later. Well, later we will need these two bytes. > > So there's the conventional reason to reserve this kind of field: > because we know we will need it, and adding it via some extension > facility will be harder than... already having it. > > And yes, we (the IETF) do use reserved fields even in protocols where > there is extensibility. > [citation-needed] All the instances of "reserved" I can think of are either due to bit alignment or blocking off old stuff. --Richard > > already have an extension mechanism (indeed, the one that's being used > > by this specification). If we end up having consensus to do pinning, > > then it's straightforward to define a new TLS extension that provides > > it. > > Having these two bytes now will mean that they are always present, which > will make it a lot easier for implementations to a) start sending > non-zero values, b) start handling non-zero values, once we write a spec > on what non-zero values mean. (And we know what that spec will say, > which is why we know we need two bytes.) > > > If you look at HPKP and Expect-CT, you will note that there are a > > [...] > > HPKP is completely different. The idea here is NOT to pin key material, > CAs, or anything of the sort. The idea here is to pin only the use of > this extension, and this does not even bind one to use DANE because the > extension can carry a denial of existence. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000050e1b9056ac1f586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> Thanks for producing some text. I understand why one might think that<= br> > having a reserved 16-bit field is useful here, but I don't really<= br> > agree.
>
> The conventional reason to reserve this kind of field is that you need=
> to leave space for an extension in some PDU, because it's hard to = add
> later. But that's not true here (or in TLS in general) because we<= br>
-07 has text on pinning.=C2=A0 There is no consensus on making that = work
_now_.=C2=A0 There is only consensus on removing that text and revisiting pinning later.=C2=A0 Well, later we will need these two bytes.

So there's the conventional reason to reserve this kind of field:
because we know we will need it, and adding it via some extension
facility will be harder than... already having it.

And yes, we (the IETF) do use reserved fields even in protocols where
there is extensibility.

[citation-needed]

All the instances of &q= uot;reserved" I can think of are either due to bit alignment or blocki= ng off old stuff.

--Richard

=C2=A0
> already have an extension mechanism (indeed, the one that's being = used
> by this specification). If we end up having consensus to do pinning, > then it's straightforward to define a new TLS extension that provi= des
> it.

Having these two bytes now will mean that they are always present, w= hich
will make it a lot easier for implementations to a) start sending
non-zero values, b) start handling non-zero values, once we write a spec on what non-zero values mean.=C2=A0 (And we know what that spec will say, which is why we know we need two bytes.)

> If you look at HPKP and Expect-CT, you will note that there are a
> [...]

HPKP is completely different.=C2=A0 The idea here is NOT to pin key materia= l,
CAs, or anything of the sort.=C2=A0 The idea here is to pin only the use of=
this extension, and this does not even bind one to use DANE because the
extension can carry a denial of existence.

Nico
--

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

--00000000000050e1b9056ac1f586-- From nobody Thu Apr 26 08:28:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6512DA21 for ; Thu, 26 Apr 2018 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.611 X-Spam-Level: * X-Spam-Status: No, score=1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mauz2PUYBVtu for ; Thu, 26 Apr 2018 08:28:50 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F06126B7E for ; Thu, 26 Apr 2018 08:28:50 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id A73ACA004B85; Thu, 26 Apr 2018 08:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OeswSNFe4y85yf K5U5v7xGfVUnM=; b=GEeZR6qfPqF0yjdq15V8Sp9pt5mAA+nNHOw2/QH8GpCCgE lIK4/8yXRtHPN7KSGx9iRYfrl9D1meY0drr8qYSXogoqIsB6U/rETavvHH8313Ui By4vHRTsn3ECH6lEyRYhLySiJ1TbS1dFP2dT5tJ4zHY+H8qVrX1EwJTaagV+A= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 4F533A004B82; Thu, 26 Apr 2018 08:28:49 -0700 (PDT) Date: Thu, 26 Apr 2018 10:22:07 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180426152206.GM25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:28:51 -0000 On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > wrote: > > On Apr 26, 2018, Eric Rescorla wrote: > > > > * a lifetime field > > * enforce vs. test > > * a report URI We will need only the TTL. We will not need anything else. This is NOT like HPKP. This will pin only the use of the extension, and NOT EVEN the use of DANE since you can send a denial of existence and you can *always*[*] do that if you stop wanting DANE. [*] unless you're operating in an alternate DNS universe where no zone is signed, not even the root zone, but then you wouldn't have used this extension ever, and you'd not have pinned it). Because we'd pin only to the use of this extension, the TTL is sufficient. > > This specification is always "enforce" (though my pull request > > changes a MUST use DANE to a SHOULD with some necessary added > > conditions) and since the report URI is in good measure to > > support non-enforce mode, we're back to just max-age. > But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments above > about why we shouldn't do this persuasive.) Standardizing this > functionality would require resolving these issues. Strawman. These are make-believe issues. Is it just to give the appearance that we couldn't possibly reach consensus on just two bytes? Nico -- From nobody Thu Apr 26 08:31:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DE612DA21 for ; Thu, 26 Apr 2018 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-D2auy7z_SM for ; Thu, 26 Apr 2018 08:30:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20AC126FDC for ; Thu, 26 Apr 2018 08:30:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40X1HN52fYz1q2; Thu, 26 Apr 2018 17:30:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524756656; bh=NuOglzq9Pp+N0RY9Ej0iAlsG1Lrje652g7IvrkmM5L0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uoLKxkbt8JrJZWzIc4LrK2bvA/S1gL+SYvOxCap/3MrDmktdvrkbUV6sZN6DIqsOK OTjphRZDT0b7h+qWRQ3734jIMBaQTDwQbg40bhwvweFWgxEkVkM6gIIi0GHGWNGkun QS0jkLlP11ehVyyt++p6LWEcKBKe+WIWlkccPX/4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MaSR42J_GOyW; Thu, 26 Apr 2018 17:30:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Apr 2018 17:30:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8AE8A59F119; Thu, 26 Apr 2018 11:30:53 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8AE8A59F119 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E2B540C103E; Thu, 26 Apr 2018 11:30:53 -0400 (EDT) Date: Thu, 26 Apr 2018 11:30:53 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: TLS WG In-Reply-To: Message-ID: References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:31:01 -0000 On Wed, 25 Apr 2018, Eric Rescorla wrote: > The conventional reason to reserve this kind of field is that you need to leave > space for an extension in some PDU, because it's hard to add later. But that's > not true here (or in TLS in general) because we already have an extension > mechanism (indeed, the one that's being used by this specification). If we > end up having consensus to do pinning, then it's straightforward to define > a new TLS extension that provides it. The pinning is not about DANE pinning but about extension pinning. To make a 2nd extension to pin a 1st extension seems very wrong to me. Additionally, as explained before, since all pinning text has consensus to be removed, this would leave clients completely in the dark about what to do when the extension vanishes. Adding the two byte zeroes allows the document to clearly and unequivocally say to NOT pin this extension with some magic local policy. > That doesn't seem like a good set of tradeoffs. This has nothing to do with trade-offs. It has to do with carefully specifying client behaviour for use with _this_ extension. It makes no sense to leave that unspecified for another document. Paul From nobody Thu Apr 26 08:41:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F7512711A for ; Thu, 26 Apr 2018 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YCOtqeeuz6uQ for ; Thu, 26 Apr 2018 08:41:07 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B37B126D45 for ; Thu, 26 Apr 2018 08:41:07 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id l22-v6so19377770otj.0 for ; Thu, 26 Apr 2018 08:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yAPx+EadgMw8VTM3ThlHPNgdzPt4yw7bW82r/PdN08Y=; b=nPqH8TPp54GZZqPDlawwpNkcG8lfvh8B8PL0Wn6DEgW65CmQ6u45GLE5gqG6LWRSBR 3fOMknHQczZaLe0gfjn4vv+5+OIclb8Bq5etTny7b0qx+cfyAJ6QL/KZY/1dnvtCYbxz h4SFywF6CmlwRVHOtQqWNhVe9jaSUwOwXtKz5pH3vty2ZK6iyL1HLVtkJk1a9cZSBiNt wKZ5rC4+RvK2SYBxFPDtrCPEbGOsJtxzMBaWVkVGsYSXtYIj7+YKM942VkBP+7g1eQ9L HoNwRwFNxmq807OOIpRUjWa64pRRwfapNjT3/bDRTIPQzWcHnbKCGdnC7PKRHSEEeAyU QZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yAPx+EadgMw8VTM3ThlHPNgdzPt4yw7bW82r/PdN08Y=; b=NPeVl2A925J+Jmm6ZnEwhI55n9W1ha6ZQvyGU0qwVipawS3fd3wqm+7UmF0qCyxtnL AVInX4PGWVg9d1Hwy1QlX7zC9HHnHRxkEQ3BB0iTYYMO31spbVUPT5Y097b98zIJMBSQ iDiUGv5AIDZOZMe2BIe7hu6NEYvEwOtH9MqYodY9nqOw4DITJAQLayC9OJCbwJ2zEc0D oxbMdOH0Yjic3dw8Z2y5nRuVIn1klumkxnk/yrloBtX5D1Ht/JgYzqsNGdZceajaPYqi lIomYMW+d4fimEjQT+NoVaFa54WsH7t+qy6rnROKK08lebz7ZJs4rEe3QIjKJ6nlDmFX tlvQ== X-Gm-Message-State: ALQs6tDB1JrNHWEjPI1xs6OINu8DTlxYA76Qu5RgUzz8OhsHnf2xvZgO i5TwlAKF4J+AFTzEPEi18PpO4L9oE/nFYptemElnQDEY X-Google-Smtp-Source: AIpwx48avgLdqtUP0JVvj5LKgxNIz4HxborTr58PEytFqAoVmaf/q/zcxMC6uVhmBCht8FCyzGiO7/3GtIbnBHt/+kA= X-Received: by 2002:a9d:310b:: with SMTP id e11-v6mr18485373otc.84.1524757266344; Thu, 26 Apr 2018 08:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.121.149 with HTTP; Thu, 26 Apr 2018 08:41:05 -0700 (PDT) In-Reply-To: <20180426152206.GM25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> From: Richard Barnes Date: Thu, 26 Apr 2018 11:41:05 -0400 Message-ID: To: Nico Williams Cc: Eric Rescorla , TLS WG Content-Type: multipart/alternative; boundary="0000000000003ac124056ac2376f" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:41:09 -0000 --0000000000003ac124056ac2376f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams wrote: > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > > > wrote: > > > On Apr 26, 2018, Eric Rescorla wrote: > > > > > > * a lifetime field > > > * enforce vs. test > > > * a report URI > > We will need only the TTL. We will not need anything else. This is NOT > like HPKP. This will pin only the use of the extension, and NOT EVEN > the use of DANE since you can send a denial of existence and you can > *always*[*] do that if you stop wanting DANE. > Until my DNSSEC signing infra breaks, the signatures expire, and now my server is bricked. --Richard > > [*] unless you're operating in an alternate DNS universe where no zone > is signed, not even the root zone, but then you wouldn't have used > this extension ever, and you'd not have pinned it). > > Because we'd pin only to the use of this extension, the TTL is > sufficient. > > > > This specification is always "enforce" (though my pull request > > > changes a MUST use DANE to a SHOULD with some necessary added > > > conditions) and since the report URI is in good measure to > > > support non-enforce mode, we're back to just max-age. > > > But this reinforces my point. I think we ought to have an enforce vs > > test flag and a report URI (and I I don't find your arguments above > > about why we shouldn't do this persuasive.) Standardizing this > > functionality would require resolving these issues. > > Strawman. These are make-believe issues. Is it just to give the > appearance that we couldn't possibly reach consensus on just two bytes? > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000003ac124056ac2376f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > On Apr 26, 2018, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >=C2=A0 =C2=A0* a lifetime field
> >=C2=A0 =C2=A0* enforce vs. test
> >=C2=A0 =C2=A0* a report URI

We will need only the TTL.=C2=A0 We will not need anything else.=C2= =A0 This is NOT
like HPKP.=C2=A0 This will pin only the use of the extension, and NOT EVEN<= br> the use of DANE since you can send a denial of existence and you can
*always*[*] do that if you stop wanting DANE.

Until my DNSSEC signing infra breaks, the signatures expire, and now= my server is bricked.

--Richard
=C2=A0

[*] unless you're operating in an alternate DNS universe where no zone<= br> =C2=A0 =C2=A0 is signed, not even the root zone, but then you wouldn't = have used
=C2=A0 =C2=A0 this extension ever, and you'd not have pinned it).

Because we'd pin only to the use of this extension, the TTL is
sufficient.

> > This specification is always "enforce" (though my pull = request
> > changes a MUST use DANE to a SHOULD with some necessary added
> > conditions) and since the report URI is in good measure to
> > support non-enforce mode, we're back to just max-age.

> But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments abov= e
> about why we shouldn't do this persuasive.)=C2=A0 Standardizing th= is
> functionality would require resolving these issues.

Strawman.=C2=A0 These are make-believe issues.=C2=A0 Is it just to g= ive the
appearance that we couldn't possibly reach consensus on just two bytes?=

Nico
--

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

--0000000000003ac124056ac2376f-- From nobody Thu Apr 26 08:42:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58C4126FDC for ; Thu, 26 Apr 2018 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J02djE0wP0XN for ; Thu, 26 Apr 2018 08:42:00 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1A7126B7E for ; Thu, 26 Apr 2018 08:41:59 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id p2-v6so29913401otf.3 for ; Thu, 26 Apr 2018 08:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zKut7w3wBnQDlIhZ81ET2g1g5kK7EWAzntqDZhAp/bs=; b=kpxkJRZywSzK46KJdbYIYFmSpxKHoKoYk/MRvKAZ1yZ+HfFoM2oc+Hgxg4wPLqR6bI kJMLEM0OJcZ9+1auYdV6K+/HLRBeMkYck02udqJVduSPFOTEb/UnxgBuSNWfMsQWeagi NpytibwNBsY8wbixbNwEaHXHe/woVKITDO8dBtv4Nr9PtsCU4FvKDgDKtkE/uaR38e4N sK3qDNQrwKmtitWSjbTX8tro/ptbNDkIPJOf7jh6aB0iR0vzd4Ey2pJLhTTxAeZHmp7h 2AjBimJoI4LhZrEEPgfqJctKGxoJN8S+v1WTqy7k+TnFCWAoFpC38BiMaq93NKEEfsoB Fj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zKut7w3wBnQDlIhZ81ET2g1g5kK7EWAzntqDZhAp/bs=; b=fVOyrRlkcWH+zqKni5SMMzLwFmsBzmvwjjPWiAjuSEGDJqVQx4O+64U9BdUYcspeqf JfixbutyW72ZhztiUPeg+tO7Y0hfWUcfpOqT9LxTf3YEBU8Q1fo2OFZ4rljYhQf7Q+O1 T9fHiRzPpe4CBCi25m18/thIND7yxzsm73J6BPVHjtvCkcClpzqoT4REylb1+0fvaeiZ smzGKM5R/vpS8ZNj2qcJ9neTcflXNxv9BAZwJovxHlksnAaLlJCJfydBETN4Yty/nKRv ELgRLZZNats+yM/nF6qX62zhwApG+4VwYU5Auz44giV6ALEsXrAPFYlow2ue1CW74dYW vzcg== X-Gm-Message-State: ALQs6tAYyHQwCPL2q2ThUI1c0lr+IBOsn9t6p53SbB+cVXnqeWWy8LFo tJFE2EiJZlMEzg53Ko/cRsyiuzxRZXY5yfMeCUX56Q== X-Google-Smtp-Source: AB8JxZqMcJk14AMkr0++MGuVp1RqQ+Nnh2buurMaaIHDHhRtvvIhbBNfJlRQIamHk8+0YHh5ZWGifA+T7Nkzflkojmg= X-Received: by 2002:a9d:719a:: with SMTP id o26-v6mr9144775otj.44.1524757319195; Thu, 26 Apr 2018 08:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 26 Apr 2018 08:41:18 -0700 (PDT) In-Reply-To: <20180426152206.GM25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> From: Eric Rescorla Date: Thu, 26 Apr 2018 08:41:18 -0700 Message-ID: To: Nico Williams Cc: TLS WG Content-Type: multipart/alternative; boundary="000000000000612f18056ac23a9c" Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:42:02 -0000 --000000000000612f18056ac23a9c Content-Type: text/plain; charset="UTF-8" On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams wrote: > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > > > wrote: > > > On Apr 26, 2018, Eric Rescorla wrote: > > > > > > * a lifetime field > > > * enforce vs. test > > > * a report URI > > We will need only the TTL. We will not need anything else. This is NOT > like HPKP. This will pin only the use of the extension, and NOT EVEN > the use of DANE since you can send a denial of existence and you can > *always*[*] do that if you stop wanting DANE. > > [*] unless you're operating in an alternate DNS universe where no zone > is signed, not even the root zone, but then you wouldn't have used > this extension ever, and you'd not have pinned it). > > Because we'd pin only to the use of this extension, the TTL is > sufficient. > I explained in my response to Victor why this isn't so. > > This specification is always "enforce" (though my pull request > > > changes a MUST use DANE to a SHOULD with some necessary added > > > conditions) and since the report URI is in good measure to > > > support non-enforce mode, we're back to just max-age. > > > But this reinforces my point. I think we ought to have an enforce vs > > test flag and a report URI (and I I don't find your arguments above > > about why we shouldn't do this persuasive.) Standardizing this > > functionality would require resolving these issues. > > Strawman. These are make-believe issues. Is it just to give the > appearance that we couldn't possibly reach consensus on just two bytes? > This discussion would probably be a lot more productive if you were able to have it without accusing other participants of acting in bad faith. -Ekr > Nico > -- > --000000000000612f18056ac23a9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams <nico@cryptonector.= com> wrote:
On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > On Apr 26, 2018, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >=C2=A0 =C2=A0* a lifetime field
> >=C2=A0 =C2=A0* enforce vs. test
> >=C2=A0 =C2=A0* a report URI

We will need only the TTL.=C2=A0 We will not need anything else.=C2= =A0 This is NOT
like HPKP.=C2=A0 This will pin only the use of the extension, and NOT EVEN<= br> the use of DANE since you can send a denial of existence and you can
*always*[*] do that if you stop wanting DANE.

[*] unless you're operating in an alternate DNS universe where no zone<= br> =C2=A0 =C2=A0 is signed, not even the root zone, but then you wouldn't = have used
=C2=A0 =C2=A0 this extension ever, and you'd not have pinned it).

Because we'd pin only to the use of this extension, the TTL is
sufficient.

I e= xplained in my response to Victor why this isn't so.


> > This specification is always "enforce" (though my pull = request
> > changes a MUST use DANE to a SHOULD with some necessary added
> > conditions) and since the report URI is in good measure to
> > support non-enforce mode, we're back to just max-age.

> But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments abov= e
> about why we shouldn't do this persuasive.)=C2=A0 Standardizing th= is
> functionality would require resolving these issues.

Strawman.=C2=A0 These are make-believe issues.=C2=A0 Is it just to g= ive the
appearance that we couldn't possibly reach consensus on just two bytes?=

This discussion would probably be a lo= t more productive if you were able to have it without accusing other partic= ipants of acting in bad faith.

-Ekr
=

Nico
--

--000000000000612f18056ac23a9c-- From nobody Thu Apr 26 08:53:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EFB126D45 for ; Thu, 26 Apr 2018 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0bu9qTFedo0g for ; Thu, 26 Apr 2018 08:53:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421AF124205 for ; Thu, 26 Apr 2018 08:53:31 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 816F17A3309 for ; Thu, 26 Apr 2018 15:53:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 11:53:29 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <7E825613-AB1B-42BC-A3E9-13AFE9604347@dukhovni.org> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:53:33 -0000 > On Apr 26, 2018, at 11:41 AM, Richard Barnes wrote: >=20 > Until my DNSSEC signing infra breaks, the signatures expire, and now = my server is bricked. If that happens, you're bricked anyway, the 1.1.1.1, 8.8.8.8, 9.9.9.9, 64.6.64.6, ... resolvers all validate and are used by a broad and rapidly growing set of users. Sites that consider DNSSEC too risky, won't deploy DNSSEC and then of course won't deploy this extension. That said, the explicit lifetime field also in part addresses your concerns about recovery from operational errors. Set it to zero or a small number (of hours, units deliberately left out of proposed changes to this draft to make sure non-zero values are unspecified). Of course given evermore sophisticated BGP attacks: https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ you might actually want to consider DNSSEC, implement it properly and monitor, and the bricking won't happen. --=20 --=20 Viktor. From nobody Thu Apr 26 08:57:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA987126C26 for ; Thu, 26 Apr 2018 08:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.611 X-Spam-Level: * X-Spam-Status: No, score=1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCIZ4p68vTiY for ; Thu, 26 Apr 2018 08:57:12 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE768124205 for ; Thu, 26 Apr 2018 08:57:12 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 6181BA004B85; Thu, 26 Apr 2018 08:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BpcLEXrwi3SqFp fz38sJpUiJmnY=; b=sUiSF02fmTeaUnMqZWijX7uM294JDZx1zhgBvZpbHcwZLJ UK4Ro5rPNNn6yBf/5ELki7DLmBn3uc/YOR5mN/EAn+Zrj17kGjomIsSKU+OrFi/y caDp8CpSp+bMQMeWKOkxnNRAhkMTnPDZVZ0FyyyfK9kBq9/T/MlSJ4kFRjCsg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id DA103A004B83; Thu, 26 Apr 2018 08:57:11 -0700 (PDT) Date: Thu, 26 Apr 2018 10:49:35 -0500 From: Nico Williams To: Richard Barnes Cc: Eric Rescorla , TLS WG Message-ID: <20180426154934.GN25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:57:19 -0000 On Thu, Apr 26, 2018 at 11:41:05AM -0400, Richard Barnes wrote: > On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams > wrote: > > > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > > > > > wrote: > > > > On Apr 26, 2018, Eric Rescorla wrote: > > > > > > > > * a lifetime field > > > > * enforce vs. test > > > > * a report URI > > > > We will need only the TTL. We will not need anything else. This is NOT > > like HPKP. This will pin only the use of the extension, and NOT EVEN > > the use of DANE since you can send a denial of existence and you can > > *always*[*] do that if you stop wanting DANE. > > Until my DNSSEC signing infra breaks, the signatures expire, and now my > server is bricked. There is no way in which you can break your zone such that this pinning gets you into trouble. Here's why, there are only these possible states: - you have TLSA RRs with a valid chain all the way to the root (works) - you don't have TLSA RRs and have a denial of existence chain (works) - your zone isn't signed, in which case you can prove this and we call that a denial of existence too (works) - your zone is bricked (fails because lookups fail) If your zone is bricked then this extension doesn't even come into play because clients will not be able to resolve your servers' hostnames, therefore they won't even connect. Nico -- From nobody Thu Apr 26 08:58:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B969126FDC for ; Thu, 26 Apr 2018 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.611 X-Spam-Level: * X-Spam-Status: No, score=1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtoEQ-DBgjFE for ; Thu, 26 Apr 2018 08:58:19 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6AF126DED for ; Thu, 26 Apr 2018 08:58:19 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id B6E6DA004B83; Thu, 26 Apr 2018 08:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GJUTZMqUd/6tcI uCAZrpnRcbhvM=; b=c5AAbhEob4jfw4YvLpGmiVhT2UfYMN62hlxwmVt1w80Kex 0b+lU9yUAbLF4nip0i4DV+3eevI3VXyURqvSrEuTIMxMI37cTlHK22yDjHBjDbRR e9+gLAdFeyYFZ1u3QSs2Myv6/Ll3CIvnnxQLlwCrAUwSFDkMVhYhtgWEMFtqg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id EFD87A004B82; Thu, 26 Apr 2018 08:58:17 -0700 (PDT) Date: Thu, 26 Apr 2018 10:50:39 -0500 From: Nico Williams To: Eric Rescorla Cc: TLS WG Message-ID: <20180426155038.GO25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 15:58:20 -0000 On Thu, Apr 26, 2018 at 08:41:18AM -0700, Eric Rescorla wrote: > On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams > wrote: > > Because we'd pin only to the use of this extension, the TTL is > > sufficient. > > I explained in my response to Victor why this isn't so. I don't accept that explanation. It's based on a strawman argument. > > > But this reinforces my point. I think we ought to have an enforce vs > > > test flag and a report URI (and I I don't find your arguments above > > > about why we shouldn't do this persuasive.) Standardizing this > > > functionality would require resolving these issues. > > > > Strawman. These are make-believe issues. Is it just to give the > > appearance that we couldn't possibly reach consensus on just two bytes? > > This discussion would probably be a lot more productive if you were able to > have it without accusing other participants of acting in bad faith. Sounds good to me. One way to make this more civil is to not make strawman arguments. Nico -- From nobody Thu Apr 26 09:01:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADF126FDC for ; Thu, 26 Apr 2018 09:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.611 X-Spam-Level: * X-Spam-Status: No, score=1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH8uykFZPy-O for ; Thu, 26 Apr 2018 09:01:39 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AE5126DED for ; Thu, 26 Apr 2018 09:01:39 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 7D124A004B84; Thu, 26 Apr 2018 09:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=5BA758gbZ6zXEWLNIpWjWEZXBY0 =; b=CdAZcO5AtjAokFiLFJG699UAP1RVihj75AQZIaqjElfrSg0kJgXaYwyhNwi mS4RGkqtC7mb6rIRMZq9RMR5ZOkqppK9MXDIRqXv1JeyDwlmkcYXKnJv8b/C9zRx LlCgZ3T23/4SIYUTLn7pJ4tCYQRXEz+hoObOASBMlAp3+XV0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 3923CA004B83; Thu, 26 Apr 2018 09:01:38 -0700 (PDT) Date: Thu, 26 Apr 2018 10:53:49 -0500 From: Nico Williams To: TLS WG Message-ID: <20180426155348.GP25259@localhost> References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> <7E825613-AB1B-42BC-A3E9-13AFE9604347@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E825613-AB1B-42BC-A3E9-13AFE9604347@dukhovni.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 16:01:40 -0000 On Thu, Apr 26, 2018 at 11:53:29AM -0400, Viktor Dukhovni wrote: > Of course given evermore sophisticated BGP attacks: > > https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ > > you might actually want to consider DNSSEC, implement it properly > and monitor, and the bricking won't happen. Good point! DNSSEC is the only defense against such attacks at this point. Pinning this extension sure seems like a desirable thing in that context! We're not asking for pinning _now_ because as the WG chair says there is no consensus to add pinning _now_. We're only trying to make it *easier* to add it _later_. Nico -- From nobody Thu Apr 26 09:06:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42799126D85 for ; Thu, 26 Apr 2018 09:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0lqv9gslT9D9 for ; Thu, 26 Apr 2018 09:06:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8113B124205 for ; Thu, 26 Apr 2018 09:06:47 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A8BF37A3309 for ; Thu, 26 Apr 2018 16:06:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Apr 2018 12:06:45 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: <1D2EB7F1-B796-4459-93C2-443A7104F33A@dukhovni.org> <1EA85624-3A19-4EA3-9A2E-D1DE19414F8C@dukhovni.org> <20180426152206.GM25259@localhost> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Proposed text for dnsssec chain extension draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 16:06:49 -0000 > On Apr 26, 2018, at 11:41 AM, Eric Rescorla wrote: > > This discussion would probably be a lot more productive if you were > able to have it without accusing other participants of acting in bad > faith. [ Well the objections do seem rather hypothetical, and the thing being objected to (a 16-bit reserved field) so minimally objectionable, that it is perplexing why it is so important to avoid reaching a compromise by allowing the 2-byte to be added. Indeed it sure looks like the separate document that might define the follow-on extension would be strongly opposed in any form by those opposing the reserved 2 bytes, but I'd be thrilled to learn of your support in principle for such a document, perhaps you'd even be willing to author (or co-author) the initial draft? ] I rather like Paul's point that the lifetime of support for this extension belongs with this extension. Adding an extension to signal ongoing support for another extension rather unnatural. -- Viktor. From nobody Thu Apr 26 09:58:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26D4127863 for ; Thu, 26 Apr 2018 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F_f-N8ItAFB for ; Thu, 26 Apr 2018 09:58:20 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D21267BB for ; Thu, 26 Apr 2018 09:58:19 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Apr 2018 09:55:46 -0700 From: Jim Schaad To: 'Simon Bernard' , 'Eric Rescorla' CC: References: In-Reply-To: Date: Thu, 26 Apr 2018 09:58:10 -0700 Message-ID: <028e01d3dd7f$c38cdc50$4aa694f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028F_01D3DD45.172EC7A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGfAj8TWuI97DkQGLAMwRiwCwdXewEvWvd6Awdw5BqkW0QbsA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 16:58:23 -0000 ------=_NextPart_000_028F_01D3DD45.172EC7A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a secondary issue related to this. My client is currently = implementing the handshake protocol a little too faithfully to the 1.2 = DTLS specification. Since the client side reliability loop does not = have any discussion on deciding that the server has gone dark or is just = never going to respond there is an infinite loop that is created. The = client will always do a back off resend of the last set of handshake = messages. =20 Jim =20 =20 From: TLS On Behalf Of Simon Bernard Sent: Thursday, April 26, 2018 2:32 AM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? =20 Eric, thx a lot for your answer.=20 We are discussing a lot about that with our community and there is still = no consensus ... So I come back to you to have clearer information to help us to make the = good decision. Using DTLS with PSK over UDP, without re-negotiation allowed : - Is there known security issue about sending the same alert for both = "unknown identity" and "bad_psk"(invalid record for handshake message) ? "Discarding records aims to preserve current association", if we are = able to preserve current association using : - no renegotiation allowed, - send alert for invalid record only for handshake record and if we have = an ongoing handshake, - In cases where a server believes it has an existing association on a = given host/port quartet and it receives an epoch=3D0 ClientHello, = destroy the existing association only if the client has demonstrated = reachability by completing a cookie exchange. Should it be OK ?=20 Thx again for your time. Simon Le 06/04/2018 =C3=A0 19:26, Eric Rescorla a =C3=A9crit : =20 =20 On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard > wrote: Hi, We are implementing DTLS with PSK over UDP and I would like to know how = "unknown identity" and "bad psk" should be handled Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says : (https://tools.ietf.org/html/rfc4279#section-2) > If the server does not recognize the PSK identity, it MAY respond > with an "unknown_psk_identity" alert message. Alternatively, if the > server wishes to hide the fact that the PSK identity was not known, > it MAY continue the protocol as if the PSK identity existed but the > key was incorrect: that is, respond with a "decrypt_error" alert. In TLS the safer way seems to send a "decrypt_error" alert for both. But in DTLS : https://tools.ietf.org/html/rfc6347#section-4.1.2.7 > In general, invalid records > SHOULD be silently discarded, thus preserving the association; > however, an error MAY be logged for diagnostic purposes. > Implementations which choose to generate an alert instead, MUST > generate fatal level alerts to avoid attacks where the attacker > repeatedly probes the implementation to see how it responds to > various types of error. Note that if DTLS is run over UDP, then any > implementation which does this will be extremely susceptible to > denial-of-service (DoS) attacks because UDP forgery is so easy. > Thus, this practice is NOT RECOMMENDED for such transports. Is this record layer recommendation for all type of record ? even = HANDSHAKE(22) record (and so FINISHED message) or is it mainly for = APPLICATION_DATA(23) record ? Is it acceptable to send fatal alert "decrypt_error" in DTLS or should = we just ignore bad credentials silently ? =20 Hi Simon, =20 The advice in 4279 is basically "make an unknown identity look like a = bad key". So the idea would be to just randomize the key and then get = the TLS or DTLS-type behavior. I.e., with TLS you would send = decrypt_error and in DTLS the handshake would just stall because you = would drop packets. =20 -Ekr =20 -- Simon _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 =20 ------=_NextPart_000_028F_01D3DD45.172EC7A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As a secondary issue = related to this.=C2=A0 My client is currently implementing the handshake = protocol a little too faithfully to the 1.2 DTLS specification.=C2=A0 = Since the client side reliability loop does not have any discussion on = deciding that the server has gone dark or is just never going to respond = there is an infinite loop that is created.=C2=A0 The client will always = do a back off resend of the last set of handshake = messages.

 

Jim

 

 

From: TLS <tls-bounces@ietf.org> On = Behalf Of Simon Bernard
Sent: Thursday, April 26, 2018 = 2:32 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: = tls@ietf.org
Subject: Re: [TLS] [DTLS]: how to handle unknown = identity and bad psk ?

 

Eric, thx a lot for your = answer.

We are discussing a lot about that with our = community and there is still no consensus ...

So I come = back to you to have clearer information to help us to make the good = decision.

Using DTLS with PSK over UDP, without = re-negotiation allowed :
- Is there known security issue about = sending the same alert for both "unknown identity" and = "bad_psk"(invalid record for handshake message) = ?

"Discarding records aims to preserve current = association", if we are able to preserve current association using = :
- no renegotiation allowed,
- send alert for invalid record only = for handshake record and if we have an ongoing handshake,
- In cases = where a server believes it has an existing association on a given = host/port quartet and it receives an epoch=3D0 ClientHello, destroy the = existing association only if the client has demonstrated reachability by = completing a cookie exchange.

Should it be OK ? =

Thx again for your = time.

Simon

Le = 06/04/2018 =C3=A0 19:26, Eric Rescorla a = =C3=A9crit :

 

 

On Fri, = Apr 6, 2018 at 10:16 AM, Simon Bernard <contact@simonbernard.eu> = wrote:

Hi,

We are implementing DTLS with PSK over UDP = and I would like to know how "unknown identity" and "bad = psk" should be handled

Pre-Shared Key Ciphersuites for = Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)
<= br>>   If the server does not recognize the PSK identity, = it MAY respond
>   with an = "unknown_psk_identity" alert message. Alternatively, if = the
>   server wishes to hide the fact that the PSK = identity was not known,
>   it MAY continue the protocol = as if the PSK identity existed but the
>   key was = incorrect: that is, respond with a "decrypt_error" = alert.

In TLS the safer way seems to send a = "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7=

>   In general, invalid records
>   = SHOULD be silently discarded, thus preserving the = association;
>   however, an error MAY be logged for = diagnostic purposes.
>   Implementations which choose to = generate an alert instead, MUST
>   generate fatal level = alerts to avoid attacks where the attacker
>   = repeatedly probes the implementation to see how it responds = to
>   various types of error.  Note that if DTLS = is run over UDP, then any
>   implementation which does = this will be extremely susceptible to
>   = denial-of-service (DoS) attacks because UDP forgery is so = easy.
>   Thus, this practice is NOT RECOMMENDED for = such transports.

Is this record layer recommendation for all type = of record ? even HANDSHAKE(22) record (and so FINISHED message) or is it = mainly for APPLICATION_DATA(23) record ?

Is it acceptable to send = fatal alert "decrypt_error" in DTLS or should we just ignore = bad credentials silently ?

 

Hi  Simon,

 

The advice in 4279 is basically "make an unknown = identity look like a bad key". So the idea would be to just = randomize the key and then get the TLS or DTLS-type behavior. I.e., with = TLS you would send decrypt_error and in DTLS the handshake would just = stall because you would drop packets.

 

-Ekr

 

--
Simon

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

 

 

------=_NextPart_000_028F_01D3DD45.172EC7A0-- From nobody Fri Apr 27 13:17:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781D9127873 for ; Fri, 27 Apr 2018 13:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lJ2821f9qUAX for ; Fri, 27 Apr 2018 13:17:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9FB127869 for ; Fri, 27 Apr 2018 13:17:16 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9C93A7A3309 for ; Fri, 27 Apr 2018 20:17:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: TLS WG Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Fri, 27 Apr 2018 16:17:14 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2018 20:17:19 -0000 Over the past too many weeks we have struggled to arrive at a rough consensus on downgrade protection for the dnssec-chain extension. Originally, and largely unnoticed by all, the specification described an all too fragile approach that involved unilateral extension pinning by the client. After I pointed this out, there was no controversy around removing this, and I am not sad to see it go. We've also reached consensus on adding denial of existence support, the authors have started work on that, and perhaps some of the additional text I'm proposing in that direction will be helpful. The remaining issue is how to repair the gash in the specification created by ripping out its original downgrade protection mechanism. Though the original text was flawed the problem it attempted to address does not go away just because we're not solving it yet. Only applications where the extension is mandatory get by as-is. There is in front of us a proposal to reserve 16-bits at the front of the extension, that can later be used as part of a future downgrade protection mechanism. The DNSSEC payload of the extension will be multiple kilobytes, holding a signed TLSA RRset, and DNSKEY and DS RRsets for multiple domains. It is hard to argue that prepending 16 zero bits is a burden on anyone, unless one is opposed not only to implementing downgrade protection for this extension in one's own applications at present, but is in fact opposed to ever implementing it, and indeed opposed to giving others that same option (offering a non-zero extension support lifetime is of course optional, as is acting on such an offer). Any negotiated (non-unilateral) downgrade protection will have finite duration, and will include such a field. A principled stand against 16-bits of "wasted" payload, compared to the size of the included DNSSEC chains, to block reaching a compromise on this draft suggests a deeper opposition to any variant of downgrade protection one might propose in a separate draft. It would be helpful to know where opponents stand on negotiating continued use of the extension in general and in the future. We are confused by their statements so far, and wonder if they are not just generally in opposition to any negotiation of continued support for the extension (in all applications), and whether that might be driving their opposition to the 16 bits, whether consciously or not. -- Viktor. -- Viktor. From nobody Sat Apr 28 09:19:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7D126C25 for ; Sat, 28 Apr 2018 09:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNxOhzMWq5O2 for ; Sat, 28 Apr 2018 09:19:51 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A86124234 for ; Sat, 28 Apr 2018 09:19:51 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id x144-v6so5120567itc.0 for ; Sat, 28 Apr 2018 09:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1nk9i0trKtsLjAmp++7/mSYyZNgfnZdpT6aOMRHRuJk=; b=DS44+MuimpZF4ULHcHaQlRuOn5p7Xp/4b2+s5qv9R1GUUs8GnSsr4hcGew8uiIt4OW K03O3pOvR71GR1vRW75dym+VxGHXzNOp4KKKey/dVt04f329WZqXkoLFVcrztwfg+tJ6 gUEA50dMAwL27XB4ZMYMULO9Ix26WpRuP+Zs+9JUNaPRnq5Ix6p3+oWt2vOzDZX35HBh fyw1JURXEfeQ5tKIsufxxMQNSnH1CMBceKMHvYLWcz/kvp+/opHTZLv2XRECk9omibb2 DW+MVWOxNOceiUxSt2pyVl/5h/T0JdMbMMFAeIq7Tbpe602103yTEk9KyZZEJjWsTubV mFwQ== 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=1nk9i0trKtsLjAmp++7/mSYyZNgfnZdpT6aOMRHRuJk=; b=LGgyecNPwvtZYqcYh8akA31Kq1tvael8yx0TOdGcIkYTWXBYSoHjYTd8IVTbNBAXpH 1FzJloZFND1txA1fed8d+6NUbg3YuE7ALbLuCuKhzKOX1FSoiNdtOoROFp2BxHvAJx8R N4aBzt7kVo21d9ISiwNvWPpkNOSXyJ9aoG8KG2e10A+NDYm1qh1rBN+/Q/bLuygwHCQx C1RzhgQNhU8NUkfAVWmSRNSMA/4g4H3Qi/ajuhVdZa5gfYZWMABvPyyzz5tpSvx9Aa62 ylnLxsYu2+Pc7EYw8yr6Bq/zdlTBAEMHSpNKiOoVcAjQghs1sIacLHt4uhfokTmF8T1b X7/w== X-Gm-Message-State: ALQs6tAQMZ4xrVjWTGjyS0qDJQ2bGc0/xWwWZ+bjXnIdCAQ5ZtSlinNR 1zdRkWBhwNUpmQcn1akBdlpLsxkTIUASp9DQWARerXJU X-Google-Smtp-Source: AB8JxZr1l+RL/5vqAt/3AMRrMkaiBByzgFF6JA9T+2ViP6h8SZeAOmcIWQHTBd/EVlHNeB2/hECU6wB+s2gFSLiH/mA= X-Received: by 2002:a24:5fca:: with SMTP id r193-v6mr5653652itb.89.1524932390453; Sat, 28 Apr 2018 09:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 09:19:49 -0700 (PDT) From: Shumon Huque Date: Sat, 28 Apr 2018 12:19:49 -0400 Message-ID: To: TLS WG , Joseph Salowey Content-Type: multipart/alternative; boundary="0000000000007089e1056aeafd4d" Archived-At: Subject: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 16:19:53 -0000 --0000000000007089e1056aeafd4d Content-Type: text/plain; charset="UTF-8" > On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate extension that supports pinning Hi Joe, Here is the proposed text for items 1, 2, and 3. It's also in the tls-wg github repo. We'll probably tweak and wordsmith some more, but this is the gist of it. > 1. Scope the document to the assertive use cases * Added scope description to Intro: This specification can also be used to optionally convey authenticated denial of existence of TLSA records. Restrictive uses that might require such proofs (such as the PKIX constraining modes of DANE, or where DANE should always be preferred over other modes of authentication such as traditional PKIX) are thus not in its intended scope. Such restrictive uses can however be supported opportunistically. > 2. Explicitly allow (but do not require) DoE be included (Note: I've noticed Viktor has submitted some expanded text describing denial of existence. We'll review and likely incorporate much of that) * New section: 3.4.1, that permits but doesn't require authenticated denial: 3.4.1. Support for Authenticated Denial of Existence TLS servers that do not have a signed TLSA record MAY instead return a DNSSEC chain that provides authenticated denial of existence. This specification does not require TLS servers to provide such a denial of existence chain, otherwise it could not be deployed incrementally in environments where not all TLS servers support this extension. Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts: o The TLSA record does not exist. o There is no signed delegation to a DNS zone which is either an ancestor of, or the same as, the TLSA record name. * Text in Section 8 (Mandating) that rewrites language that in the previous draft stated that it doesn't support denial of existence: This protocol allows TLS servers to prove that they don't have a signed TLSA record by returning a denial of existence chain. However, as explained in Section 3.4.1, it does not require TLS servers to do so. In the absence of such a proof, a TLS client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. > 3. Remove current text about pinning * Remove client initiated pinning para from Section 8: This paragraph was entirely deleted: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. Thanks, -- Shumon Huque --0000000000007089e1056aeafd4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey = <joe@salowey.net> wrote:

> Concerns have been raised about the trade-offs= associated with pinning and I do not think we currently have consensus to = add pinning.=C2=A0 While I think it may be possible to come to consensus on= pinning I think it may take some time.=C2=A0 I believe we can quickly get = consensus for the following approach:
>
> 1. Scop= e the document to the assertive use cases
> 2. Explicitly allo= w (but do not require) DoE be included
> 3. Remove current tex= t about pinning
> 4. Re-submit the document for publication an= d start work on a separate extension that supports pinning


Hi Joe,

Here is the propos= ed text for items 1, 2, and 3. It's also in the
tls-wg github= repo. We'll probably tweak and wordsmith some more,
but this= is the gist of it.


> 1. Sco= pe the document to the assertive use cases

* Added= scope description to Intro:

=C2=A0 =C2=A0This spe= cification can also be used to optionally convey
=C2=A0 =C2=A0aut= henticated denial of existence of TLSA records.=C2=A0 Restrictive uses
=C2=A0 =C2=A0that might require such proofs (such as the PKIX constra= ining modes
=C2=A0 =C2=A0of DANE, or where DANE should always be = preferred over other modes of
=C2=A0 =C2=A0authentication such as= traditional PKIX) are thus not in its intended
=C2=A0 =C2=A0scop= e.=C2=A0 Such restrictive uses can however be supported
=C2=A0 = =C2=A0opportunistically.


> 2. Ex= plicitly allow (but do not require) DoE be included

(Note: I've noticed Viktor has submitted some expanded text
describing denial of existence. We'll review and likely incorporate
much of that)

* New section: 3.4.1, that p= ermits but doesn't require authenticated denial:

3.4.1.=C2=A0 Support for Authenticated Denial of Existence
=C2=A0 =C2=A0TLS servers that do not have a signed TLSA record = MAY instead return
=C2=A0 =C2=A0a DNSSEC chain that provides auth= enticated denial of existence.=C2=A0 This
=C2=A0 =C2=A0specificat= ion does not require TLS servers to provide such a denial
=C2=A0 = =C2=A0of existence chain, otherwise it could not be deployed incrementally<= /div>
=C2=A0 =C2=A0in environments where not all TLS servers support th= is extension.

=C2=A0 =C2=A0Authenticated denial ch= ains include NSEC or NSEC3 records that
=C2=A0 =C2=A0demonstrate = one of the following facts:

=C2=A0 =C2=A0o=C2=A0 T= he TLSA record does not exist.

=C2=A0 =C2=A0o=C2= =A0 There is no signed delegation to a DNS zone which is either an
=C2=A0 =C2=A0 =C2=A0 ancestor of, or the same as, the TLSA record name.


* Text in Section 8 (Mandating) that= rewrites language that in the
=C2=A0 previous draft stated that = it doesn't support denial of existence:

=C2=A0= =C2=A0This protocol allows TLS servers to prove that they don't have a=
=C2=A0 =C2=A0signed TLSA record by returning a denial of existen= ce chain.
=C2=A0 =C2=A0However, as explained in Section 3.4.1, it= does not require TLS
=C2=A0 =C2=A0servers to do so.=C2=A0 In the= absence of such a proof, a TLS client
=C2=A0 =C2=A0misdirected t= o a server that has fraudulently acquired a public CA
=C2=A0 =C2= =A0issued certificate for the real server's name, could be induced to
=C2=A0 =C2=A0establish a PKIX verified connection to the rogue ser= ver that
=C2=A0 =C2=A0precluded DANE authentication.=C2=A0 Applic= ation ecosystems where all TLS
=C2=A0 =C2=A0servers are expected = to implement this extension could require such
=C2=A0 =C2=A0authe= nticated denial proofs to be delivered by TLS servers that don't
<= div>=C2=A0 =C2=A0have signed TLSA records.


> 3. Remove current text about pinning

= * Remove client initiated pinning para from Section 8:

=
=C2=A0 This paragraph was entirely deleted:

= =C2=A0 =C2=A0If TLS applications want to mandate the use of this extension = for
=C2=A0 =C2=A0specific servers, clients could maintain a white= list of sites where
=C2=A0 =C2=A0the use of this extension is for= ced.=C2=A0 The client would refuse to
=C2=A0 =C2=A0authenticate s= uch servers if they failed to deliver this extension.
=C2=A0 =C2= =A0Client applications could also employ a Trust on First Use (TOFU)
<= div>=C2=A0 =C2=A0like strategy, whereby they would record the fact that a s= erver
=C2=A0 =C2=A0offered the extension and use that knowledge t= o require it for
=C2=A0 =C2=A0subsequent connections.
<= br>

Thanks,
--=C2=A0
Shumon Hu= que

--0000000000007089e1056aeafd4d-- From nobody Sat Apr 28 09:26:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515FC126BFD for ; Sat, 28 Apr 2018 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKugRMa-_kpd for ; Sat, 28 Apr 2018 09:26:28 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44E81243F3 for ; Sat, 28 Apr 2018 09:26:27 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id e12-v6so5878205iob.8 for ; Sat, 28 Apr 2018 09:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HWksXgOxz8tUAsDVQ9NdyW7ZtjTL1AfhGCCvI2cydRs=; b=vQKamN70JVE+k4kK94e8zvbpCIyBWvIvOZqDzT1AtVOJIexOiGwWPfQtgxbOMBewwe aVlzmhNhyJ5zELrnGLQ4zjHz4hzwwFEm08dwFI2wdG+jA3m9Sw6y4jomsesyOknc8pvr vCvmCL2IklIxpoBCxvocCZM8qso19jpMoxOpLpC9ERkE87WUIcEf8beViN4u1fRqPf7s PHwWuzj6jZfdHSohWUQ48TkuVPcvuSTvc9J8ifbQGvB6SFmT9aR5InLs9ULzOQljOZZL qcrCtIKb6SOYbMz/8AcJv6L2dAoUJCtTa3AZbjDSooSgU6kIgUcV3LvgOD3S0mcZu/vr PEmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HWksXgOxz8tUAsDVQ9NdyW7ZtjTL1AfhGCCvI2cydRs=; b=JpuQfWpEPy3TNrflGmGGMO1dE+9AfWpOE9hgbA7dijaYwKiYWbPDA2cGsVihEKNHv+ TFEJ8CD3TEP2K9kKca9dlZpeXTe/OSf4Esj9yCsgf4OQ+2LBH2hSZE6staeIwOwXAfjk quUz6SXh+dq4ZSQP31c1dqLOlHmxfSox3QxzoXGSB88RXb0QzQ4BGGKuJvePTMmx4mRe wrMQkzqP16JRy7V885lQIfr6oaJTCHcII8TGv53hXAa1plnIO67I2KLDCYmkDRD5eRcl H6iL5+9EtVTEuh7UK2MSTczkjBYRFHUSV6wfdYZTUGQCHewTqlTKxOD671DhzK9tmOvo i4+w== X-Gm-Message-State: ALQs6tAucEfkJYq+s6Pv1Vr/+wbhQcAzapzV/NIaofinbDp9fz+3f+Yf ls+vxRQIT/n3A72LoG0PrQ2FCBcl5zsb05ekv3RZkszR X-Google-Smtp-Source: AB8JxZoSaOa71Xf/BG7EEu+9NCQ+00bwkhD6FIxKW5wg4sClcSJAyJu2DhbqS3jwHqsb2C5x1zUq26uvdollvlPyivw= X-Received: by 2002:a6b:bcc5:: with SMTP id m188-v6mr7221781iof.292.1524932786774; Sat, 28 Apr 2018 09:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 09:26:26 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Sat, 28 Apr 2018 12:26:26 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000000fe8b4056aeb1536" Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 16:26:30 -0000 --0000000000000fe8b4056aeb1536 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni wrote: > > It would be helpful to know where opponents stand on negotiating > continued use of the extension in general and in the future. We > are confused by their statements so far, and wonder if they are > not just generally in opposition to any negotiation of continued > support for the extension (in all applications), and whether that > might be driving their opposition to the 16 bits, whether consciously > or not. > Hi Viktor, I am in support of doing the pinning in a new extension, and will even help you write the draft if you like. I'm pretty sure we could have easily done this in the time that has been taken up on list endlessly and repetitively discussing this. Clearly I can speak only for myself, but I strongly suspect others in the WG will also support this (as long as it's in a separate extension), so if you pursue this approach, I think you'll succeed in adding this functionality, and will not be actively blocked by others. As far as I can assess, the reason you are getting resistance for adding a pinning field in this spec is two fold: First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This can be clearly seen from various comments on list and at IETF/London, such as the point made many times that the original purpose of this draft was to add DANE as an additional possible authentication mechanism in TLS, not to position it as a mechanism that if available unconditionally trumps PKIX authentication. If you look back at my back-and-forth answering IESG review comments, you will observe that I had to add text to the draft that says TLS clients can fail back to normal PKIX authentication if DANE fails for any reason (i.e. a protocol behavior that is the opposite of downgrade resistance). There are other comments like (paraphrasing) "What's the downgrade problem? The only security downgrade issue I see is DNSSEC's use of legacy crypto"? Clearly, for most DANE proponents, an obvious goal for the protocol would be to protect against PKIX attacks. In an ideal world, I share that view also. But I also recognize the other views I just described, and am willing to make compromises to get a foot in the door for DANE first. There will always be opportunities to improve the protocol later. In fact, the legacy crypto issue will always be a huge impediment for any DANE proponent in arguing against the Internet PKI. An argument I've heard many times: Since most of the Internet PKI has moved to 2048-bit RSA or better, why would I degrade the security of my system by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's in the weakest part of the chain (some chains are even weaker)? And if so, why should PKIX not need downgrade resistance against DANE, rather than vice versa? For DANE proponents to make a stronger case, they need to urgently solve this problem. I'm not sure how to do that quickly - it probably involves getting ICANN to impose rules on TLDs prohibiting weak keys (which would likely take years). The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult. I won't repeat all the arguments and concerns expressed already, many of which I share by the way. So moving this feature into a new optional extension (both the pinning field and a description of the associated behavior) appears to me to be the past of least resistance. By continuing to argue your position, the most you can hope to achieve is deadlock. Shumon. (Addendum: I did want to thank you for pushing on the issue of explicitly allowing authenticated denial of existence chains in the current draft. In environments where all TLS servers support this extension, this allows the protocol to be bulletproof in a way that satisfies even the security purist, so I'm glad it's in the core spec.). -- Shumon Huque --0000000000000fe8b4056aeb1536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

It would be helpful to know where opponents stand on negotiating
continued use of the extension in general and in the future.=C2=A0 We
are confused by their statements so far, and wonder if they are
not just generally in opposition to any negotiation of continued
support for the extension (in all applications), and whether that
might be driving their opposition to the 16 bits, whether consciously
or not.

Hi Viktor,
<= br>
I am in support of doing the pinning in a new extension, and = will
even help you write the draft if you like. I'm pretty su= re we could
have easily done this in the time that has been taken= up on list
endlessly and repetitively discussing this.

Clearly I can speak only for myself, but I strongly suspect= others
in the WG will also support this (as long as it's in = a separate
extension), so if you pursue this approach, I think yo= u'll succeed
in adding this functionality, and will not be ac= tively blocked by
others.

As far as I ca= n assess, the reason you are getting resistance for
adding a pinn= ing field in this spec is two fold:

First, there i= s no agreement that your reason for doing pinning,
i.e. that DANE= needs downgrade resistance against PKIX attacks
is even valid. T= his can be clearly seen from various comments on
list and at IETF= /London, such as the point made many times that=C2=A0
the origina= l purpose of this draft was to add DANE as an additional=C2=A0
po= ssible authentication mechanism in TLS, not to position it as a=C2=A0
=
mechanism that if available unconditionally trumps PKIX authentication= .=C2=A0
If you look back at my back-and-forth answering IESG revi= ew comments,=C2=A0
you will observe that I had to add text to the= draft that says TLS clients=C2=A0
can fail back to normal PKIX a= uthentication if DANE fails for any reason
(i.e. a protocol behav= ior that is the opposite of downgrade resistance).=C2=A0
There ar= e other comments like (paraphrasing) "What's the downgrade=C2=A0
problem? The only security downgrade issue I see is DNSSEC's u= se of=C2=A0
legacy crypto"?

Clearly= , for most DANE proponents, an obvious goal for the protocol
woul= d be to protect against PKIX attacks. In an ideal world, I share
= that view also. But I also recognize the other views I just described,
and am willing to make compromises to get a foot in the door for DANE=
first. There will always be opportunities to improve the protoco= l
later.

In fact, the legacy crypto issu= e will always be a huge impediment for
any DANE proponent in argu= ing against the Internet PKI. An argument
I've heard many tim= es: Since most of the Internet PKI has moved to
2048-bit RSA or b= etter, why would I degrade the security of my system
by moving to= DANE, which in most cases is protected by 1024-bit RSA ZSK's
in the weakest part of the chain (some chains are even weaker)? And if so,=
why should PKIX not need downgrade resistance against DANE, rath= er than
vice versa? For DANE proponents to make a stronger case, = they need to
urgently solve this problem. I'm not sure how to= do that quickly - it
probably involves getting ICANN to impose r= ules on TLDs prohibiting
weak keys (which would likely take years= ).

The second reason is that pinning really is a c= ontroversial feature.
And for this reason, putting it in the core= spec will be difficult.
I won't repeat all the arguments and= concerns expressed already, many
of which I share by the way. So= moving this feature into a new optional
extension (both the pinn= ing field and a description of the associated
behavior) appears t= o me to be the past of least resistance.

By contin= uing to argue your position, the most you can hope to achieve
is = deadlock.

Shumon.

(Addend= um: I did want to thank you for pushing on the issue of
explicitl= y allowing authenticated denial of existence chains in the
curren= t draft. In environments where all TLS servers support this
exten= sion, this allows the protocol to be bulletproof in a way that
sa= tisfies even the security purist, so I'm glad it's in the core
spec.).

--=C2=A0
Shumon Huqu= e

=C2=A0
--0000000000000fe8b4056aeb1536-- From nobody Sat Apr 28 10:40:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6E1270FC for ; Sat, 28 Apr 2018 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mqct-BpqcL6E for ; Sat, 28 Apr 2018 10:40:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5951200B9 for ; Sat, 28 Apr 2018 10:40:28 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DC6747A3309 for ; Sat, 28 Apr 2018 17:40:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 13:40:25 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 17:40:31 -0000 > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote: >=20 > I am in support of doing the pinning in a new extension, and will > even help you write the draft if you like. I'm pretty sure we could > have easily done this in the time that has been taken up on list > endlessly and repetitively discussing this. I should note that substantial issues were discovered (and will be addressed) during the consensus call, which ended Apr 18th, and that there is not yet a revised version of the draft that addresses these, so while the discussion back and forth has been lengthy, it has gone on in parallel with process that needed to take place and is ongoing. So discussion of doing more than removing the unilateral pinning that was present and adding denial of existence which was needed has not as yet caused any additional delay. > Clearly I can speak only for myself, but I strongly suspect others > in the WG will also support this (as long as it's in a separate > extension), so if you pursue this approach, I think you'll succeed > in adding this functionality, and will not be actively blocked by > others. We may yet have to see how much support or opposition the follow-on document will meet. What continues to be puzzling is resistance to adding a field that imposes negligible burden on the present spec, and would clearly be included in the follow-on extension. It might well be the only thing that's in the follow-on extension, and so provisioning space for it has a strong chance of simplifying the burden on future implementations that would need only implement code for just one extension structure instead of two. Worst-case we have two reserved bytes in the current extension. > As far as I can assess, the reason you are getting resistance for > adding a pinning field in this spec is two fold: >=20 > First, there is no agreement that your reason for doing pinning, > i.e. that DANE needs downgrade resistance against PKIX attacks > is even valid. The reasons are an easy exercise in logic if one is to be able to deploy DANE at all, incrementally in *any* existing WebPKI application (say IMAP). This was addressed weeks back when I explained that without downgrade protection the deployment of this extension is all cost and no benefit. There was agreement on this point even from those who opposed adding the downgrade protection. > This can be clearly seen from various comments on > list and at IETF/London, such as the point made many times that=20 > the original purpose of this draft was to add DANE as an additional=20 > possible authentication mechanism in TLS, not to position it as a=20 > mechanism that if available unconditionally trumps PKIX = authentication.. Those comments are gut reactions that have not considered the issue with care. We must discount them. This extension can only work as a = mandatory sole mechanism. All other models fail the cost/benefit analysis. Some may want to deny others the opportunity to use this extension in additional contexts. My reaction to that is that they are under no obligation do use it themselves, and setting the field to zero opts them out of such use. Nothing I'm proposing mandates downgrade = protection for the extension. I am just asking for it to be possible, on a mutual opt-in basis between client and server. > If you look back at my back-and-forth answering IESG review comments,=20= > you will observe that I had to add text to the draft that says TLS = clients=20 > can fail back to normal PKIX authentication if DANE fails for any = reason > (i.e. a protocol behavior that is the opposite of downgrade = resistance). Clients can choose to do that whether or not the downgrade protection is available, and servers can opt-out of downgrade protection. What we are talking about is whether downgrade protection is to be = unavailable even if both sides wanted it, and the application supported it. I have no intention of forcing anyone to enable downgrade protection in code they develop and support or systems and applications they deploy. Their choice to leave it off. My problem is with the IETF leaving a gap in the specification that removes the option of downgrade = protection. > There are other comments like (paraphrasing) "What's the downgrade=20 > problem? The only security downgrade issue I see is DNSSEC's use of=20 > legacy crypto"? Folks who don't trust DNSSEC are unlikely to deploy the extension, but if they do, will presumably want PKIX-EE(1) or PKIX-TA(0) so that WebPKI is also employed. These however require downgrade protection. Without downgrade protection you're stuck sometimes trusting just DANE. If one considers DANE to be too weak the solution is to make it STRONGER not weaker!!! To make it stronger you need downgrade protection so that you can use PKIX-EE(1) and PKIX-TA(0) and ignore DANE-EE(3) and DANE-TA(2) as "unusable". > Clearly, for most DANE proponents, an obvious goal for the protocol > would be to protect against PKIX attacks. In an ideal world, I share > that view also. But I also recognize the other views I just described, > and am willing to make compromises to get a foot in the door for DANE > first. There will always be opportunities to improve the protocol > later. The other views are either largely irrelevant or self-contradictory. * Those with no plans to use this extension have little standing to dictate its content. * Those who plan to use it, but only in mandatory contexts have little standing to preclude other uses. * Those who would use this extension in opportunistic contexts (incremental deployment, when available), but oppose downgrade protection, have failed to consider the threat model and = cost/benefit analysis in any detail: + If one considers DANE weak then it must not be used alone, and to be useful in combination with WebPKI it requires downgrade protection. + If one considers DANE strong than one should want to avoid = downgrades to the weaker WebPKI. > In fact, the legacy crypto issue will always be a huge impediment for > any DANE proponent in arguing against the Internet PKI. In the context of this extension I am NOT arguing for or against the = WebPKI, nor for or against DANE. I am arguing for a sensible definition of this mechanism that is not crippled to handle just one deployment model (just applications where it is mandatory, what are these applications where the extension is to be mandatory?) > An argument > I've heard many times: Since most of the Internet PKI has moved to > 2048-bit RSA or better, why would I degrade the security of my system > by moving to DANE, which in most cases is protected by 1024-bit RSA = ZSK's > in the weakest part of the chain (some chains are even weaker)? Then they should oppose the present draft, require downgrade protection and limit their applications to just PKIX-EE(1) and PKIX-TA(2). The present draft says: = https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#secti= on-6 A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, MUST use this information to perform DANE authentication of the server. My pull request changes MUST to SHOULD and adds necessary caveats about "unusable" TLSA records (such as perhaps DANE-EE(3) and DANE-TA(2) if the application wants to always use *at least* WebPKI). Another option is to just delete this paragraph, though it would be better to then say "MAY" and still list the proposed caveats, silence is worse than explaining the additional considerations. Visceral dislike of DNSSEC is not a good reason to further weaken DNSSEC-based mechanisms. > And if so, > why should PKIX not need downgrade resistance against DANE, rather = than > vice versa? Indeed, hence PKIX-EE(1) and PKIX-TA(0), and potential application profiles that support just these certificate usages, but then (surprise!) you need downgrade protection for this extension to be at all useful. > For DANE proponents to make a stronger case, they need to > urgently solve this problem. I'm not sure how to do that quickly - it > probably involves getting ICANN to impose rules on TLDs prohibiting > weak keys (which would likely take years). We are NOT arguing for or against DANE or WebPKI. We're defining an extension that makes it possible to obtain DANE TLSA records, from the TLS server. This mechanism with some rare exceptions (greenfield applications that purportedly mandate DANE, do they?) needs downgrade protection to be useful. > The second reason is that pinning really is a controversial feature. Which is why it is OPTIONAL, and disabled explicitly in the initial draft. > And for this reason, putting it in the core spec will be difficult. There is no pinning in the core document, only a reserved field that explicitly proscribes unilateral pinning. > I won't repeat all the arguments and concerns expressed already, many > of which I share by the way. Most of those arguments are substantially flawed. Only if one believes that downgrade protection must not be allowed to be specified and one not only never intends to use this extension in one's own applications, but would want to make sure that the option to do so is not available others (be it out of paternal considerations to save them from their own folly?) would it make sense to oppose the reserved field. Secondarily, one might just give up the fight or choose to to fight another day, but then one can stay silent, it is not a valid opposing view. > So moving this feature into a new optional > extension (both the pinning field and a description of the associated > behavior) appears to me to be the past of least resistance. I wish I could be confident that such a specification would be allowed to move forward. My fear is that the same visceral opposition to DANE and DNSSEC would play out, and so I may as well try to get past these now. > By continuing to argue your position, the most you can hope to > achieve is deadlock. The topic is fair-game while the draft is still being revised. > (Addendum: I did want to thank you for pushing on the issue of > explicitly allowing authenticated denial of existence chains in the > current draft. In environments where all TLS servers support this > extension, this allows the protocol to be bulletproof in a way that > satisfies even the security purist, so I'm glad it's in the core > spec.). Thanks. Please a look at the first commit in the pull-request. It covers blocks of text that I think need revision now that denial of existence is an option. Please also see the proposed change to the first paragraph of section 6. --=20 Viktor. From nobody Sat Apr 28 10:52:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034C312E854 for ; Sat, 28 Apr 2018 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 alDA64uv_9vI for ; Sat, 28 Apr 2018 10:52:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A6E12E056 for ; Sat, 28 Apr 2018 10:52:07 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B4A987A3309 for ; Sat, 28 Apr 2018 17:52:06 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 13:52:05 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 17:52:09 -0000 > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: > > This specification can also be used to optionally convey > authenticated denial of existence of TLSA records. Restrictive uses > that might require such proofs (such as the PKIX constraining modes > of DANE, or where DANE should always be preferred over other modes of > authentication such as traditional PKIX) are thus not in its intended > scope. Such restrictive uses can however be supported > opportunistically. The last sentence makes no sense. The term "Restrictive uses" is poorly defined. The reduction in scope is effectively a reduction to just the cases where the extension is mandatory, if that's what you intend to do then say so (expect pushback). Please do not imply that any non-mandatory "additive" use-cases are viable. They are not. -- Viktor. From nobody Sat Apr 28 11:17:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073E612E86A for ; Sat, 28 Apr 2018 11:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wbBzj82Q3BnW for ; Sat, 28 Apr 2018 11:17:22 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29CD1276AF for ; Sat, 28 Apr 2018 11:17:21 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id 11-v6so4350437ois.8 for ; Sat, 28 Apr 2018 11:17:21 -0700 (PDT) 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; bh=friOWPNOSlB6peIv+AI1vcWYlOCsTQjZyA+wwBMIyxQ=; b=wNIonujUaJwbiIyT2Q7OwnEKWmW0DDDjoMKdsJf51ZvbQAx7iU4PLPsP55AUyLUt8s s4oC++/EdJUNoOpwxBesuwnxu/fzhnF8G9GUhF3kdBRndLe/6AU0mSHkrPKNu+qabu8W IzcQ/1Pb/rj6Hg0//VK87BFonav43voIkdWf8nxI+UqyHHU6ogfzNR4zNQvF7T/8rAtr QpSuI1Mr3Zqn7+spPE9/UMZX/4j0ScEQzfuWM7jjZaEBWfzLU4lITrNXpJe17cXn5TiC /KE4MQXwVJpytkpNMYWtz3kAlI9j7c7a3Y4dkds9NqPOToNBHTfn+GqqngX/bNdKSsHc SZrQ== 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=friOWPNOSlB6peIv+AI1vcWYlOCsTQjZyA+wwBMIyxQ=; b=nvV7dmnUg45UsZlp5T84rDmMuGgQYSiO4XDE8OZJgQt6FcawnPaS5/F9s/FRk1mvRs 77jIfbMVrmFWTyrJ/INmWJ/jBva1KNMwht9+DlTBqruMyN8/TJdq89QK3Bi8NGll24fN CNWpDgs9AbY3HPJZOQjiL5g/BtoFH3c0hPVv7bjydnAPMD/rbwDiSaBXvW5LzNwd7KGb hpYpMoy+URN5dF4xlL4dvv8WNcJMwDqQtcsdUvu2juaroXby5Th2CZBVKBvHOQU9XslM gPcs3yIYMxWcxl0EKpwO4OOjwHyf2f1HYGiNJKEXcg2wSk+Mcl5xMweKbKVF/59Vf6IR 8oxA== X-Gm-Message-State: ALQs6tCNysMWNiGwr8qI4qlbtG2iq4h0jQskGzjIRh5gIjDTBDscP1KB 84J6iH0uz5SmfLB8CSNw6sN1IKbZTLGgLcfWFGSU3RKY X-Google-Smtp-Source: AB8JxZpuyXmXNtVgVE6a3OcrsdigPyW5ISvgkIbyhUg861liU0IqJPEDgxDYXhdKmpOUXast6o6/ZenEPf8TjjK56ww= X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr3790843oig.155.1524939440977; Sat, 28 Apr 2018 11:17:20 -0700 (PDT) MIME-Version: 1.0 References: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> In-Reply-To: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> From: Richard Barnes Date: Sat, 28 Apr 2018 18:17:10 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000af10ff056aeca108" Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 18:17:24 -0000 --000000000000af10ff056aeca108 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni wrote: > > > > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: > > > > This specification can also be used to optionally convey > > authenticated denial of existence of TLSA records. Restrictive uses > > that might require such proofs (such as the PKIX constraining modes > > of DANE, or where DANE should always be preferred over other modes of > > authentication such as traditional PKIX) are thus not in its intended > > scope. Such restrictive uses can however be supported > > opportunistically. > > The last sentence makes no sense. The term "Restrictive uses" is poorly > defined. The reduction in scope is effectively a reduction to just the > cases where the extension is mandatory, if that's what you intend to do > then say so (expect pushback). > > Please do not imply that any non-mandatory "additive" use-cases are > viable. They are not. > I agree with Viktor here. You could imagine enforcing a restriction you see in a DANE extension the cert you get milliseconds later, but that's pretty useless given that an attacker can just not send the extension. Let's just scope this to the additive case. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000af10ff056aeca108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Apr 28, 2018 at 1:52 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:


> On Apr 28, 2018, at 12:19 PM, Shumon Huque <shuque@gmail.com> wrote:
>
>=C2=A0 =C2=A0 This specification can also be used to optionally convey<= br> >=C2=A0 =C2=A0 authenticated denial of existence of TLSA records.=C2=A0 = Restrictive uses
>=C2=A0 =C2=A0 that might require such proofs (such as the PKIX constrai= ning modes
>=C2=A0 =C2=A0 of DANE, or where DANE should always be preferred over ot= her modes of
>=C2=A0 =C2=A0 authentication such as traditional PKIX) are thus not in = its intended
>=C2=A0 =C2=A0 scope.=C2=A0 Such restrictive uses can however be support= ed
>=C2=A0 =C2=A0 opportunistically.

The last sentence makes no sense.=C2=A0 The term "Restrictive uses&quo= t; is poorly
defined.=C2=A0 The reduction in scope is effectively a reduction to just th= e
cases where the extension is mandatory, if that's what you intend to do=
then say so (expect pushback).

Please do not imply that any non-mandatory "additive" use-cases a= re
viable.=C2=A0 They are not.

I agree wit= h Viktor here.

You could imagine enforcing a restr= iction you see in a DANE extension the cert you get milliseconds later, but= that's pretty useless given that an attacker can just not send the ext= ension.=C2=A0 Let's just scope this to the additive case.

=C2=A0

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000af10ff056aeca108-- From nobody Sat Apr 28 11:34:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241AA127201 for ; Sat, 28 Apr 2018 11:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zU_pepTEh-ae for ; Sat, 28 Apr 2018 11:34:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E29C126DFB for ; Sat, 28 Apr 2018 11:34:04 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 991687A3309 for ; Sat, 28 Apr 2018 18:34:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 14:34:02 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <965A64B5-CFD2-44BE-A0C6-6549DA5930D3@dukhovni.org> References: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 18:34:06 -0000 > On Apr 28, 2018, at 2:17 PM, Richard Barnes wrote: >=20 > Let's just scope this to the additive case. When you say "additive case" do you mean to cover just applications where the extension is mandatory? Or you expect the extension to also have some value when it is optional? I thought I explained fairly well why optional use does not pan out, there was no cost/benefit to refute the one I posted (quoted below). Servers will never start deploying the non-mandatory 'additive case', absent downgrade protection, it makes no sense for them to do that: --- Viktor Dukhovni , 2018-04-08 19:27:36-0400 = --- And yet, as it stands, the deployment cost-benefit analysis for this extension in existing applications plays out as follows: COSTS: * You still manage WebPKI certificates to support the majority of = existing clients. * If the WebPKI is compromised, you're compromised. * If DNSSEC is compromised, you're compromised * You pay the complexity cost of also supporting the extension * You might present incorrect TLSA records and the connection might = fail even when it would otherwise succeed with WebPKI BENEFITS: * Nothing other than bragging rights that you're cool enough to deploy a shiny new technology --- Notably, just a confirmation that the above is basically sound: --- Martin Thomson , 2018-04-05 12:07:57+1000 = --- Your cost benefit analysis seems about right though. --- So with downgrade protection out, the present scope is *exactly* the applications where the extension is mandatory (whatever these might be). --=20 Viktor. From nobody Sat Apr 28 11:35:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5006F1276AF for ; Sat, 28 Apr 2018 11:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnYKxXKRsKh2 for ; Sat, 28 Apr 2018 11:34:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C4F126DFB for ; Sat, 28 Apr 2018 11:34:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40YKGd23yrzCq8; Sat, 28 Apr 2018 20:34:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524940489; bh=Dj8/klsRFIZB3xiVuABUxf6itooYf/Ad/kEIHbt8IYA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K6/gTJdZkFfhxSf05zLVOmn+eNjSvNtNGkAsvx7yqNbiFO5XOnwZjeRu3Ng7i+h7X 9OeOdO4W3JtO3rh3GsO/UCqDZooxcOi/Q32vtI5Y5olWj1/94A88oGIdi/HqKqB9oV h75qiraQG+XX2/RyphDfdKeRQT6oxUff31nkt4cc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Fp4rkAVQQW4E; Sat, 28 Apr 2018 20:34:47 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Apr 2018 20:34:46 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 167E661CD5; Sat, 28 Apr 2018 14:34:45 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 167E661CD5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E8DC40C1031; Sat, 28 Apr 2018 14:34:45 -0400 (EDT) Date: Sat, 28 Apr 2018 14:34:45 -0400 (EDT) From: Paul Wouters To: Shumon Huque cc: TLS WG , Joseph Salowey In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 18:34:59 -0000 On Sat, 28 Apr 2018, Shumon Huque wrote: >    TLS servers that do not have a signed TLSA record MAY instead return >    a DNSSEC chain that provides authenticated denial of existence.  This >    specification does not require TLS servers to provide such a denial >    of existence chain, The second sentence is just repeating the MAY and is not needed. But more importantly, it does not specify what the extension content should be in the absense of a signed TLSA record and not wanting to put in the denial of existene. Are you expecting an empty payload? A single NULL payload? Or are you expecting the extension should be omitted entirely? And what is the expected client behaviour in that case? > otherwise it could not be deployed incrementally >    in environments where not all TLS servers support this extension. It can be deployed incremendally as Viktor, Nico and I have shown repeatedly with a two byte value. >    Authenticated denial chains include NSEC or NSEC3 records that >    demonstrate one of the following facts: > >    o  The TLSA record does not exist. > >    o  There is no signed delegation to a DNS zone which is either an >       ancestor of, or the same as, the TLSA record name. "s/one of the following facts/either" >    In the absence of such a proof, a TLS client >    misdirected to a server that has fraudulently acquired a public CA >    issued certificate for the real server's name, could be induced to >    establish a PKIX verified connection to the rogue server that >    precluded DANE authentication.  Application ecosystems where all TLS >    servers are expected to implement this extension could require such >    authenticated denial proofs to be delivered by TLS servers that don't >    have signed TLSA records. I think this belongs in the Security Section. It's a big security problem and so should be explained in the Security Section. > > 3. Remove current text about pinning > > * Remove client initiated pinning para from Section 8: > >   This paragraph was entirely deleted: > >    If TLS applications want to mandate the use of this extension for >    specific servers, clients could maintain a whitelist of sites where >    the use of this extension is forced.  The client would refuse to >    authenticate such servers if they failed to deliver this extension. >    Client applications could also employ a Trust on First Use (TOFU) >    like strategy, whereby they would record the fact that a server >    offered the extension and use that knowledge to require it for >    subsequent connections. And as stated before, removing this is not enough. You need to explain what the expected client behaviour is when the extension appears and disappears, either in this section, a seperate section, or the Security Section. Paul From nobody Sat Apr 28 11:51:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602591272E1 for ; Sat, 28 Apr 2018 11:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 p49RBAjxIiAK for ; Sat, 28 Apr 2018 11:51:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8885B127241 for ; Sat, 28 Apr 2018 11:51:22 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 133027A3309 for ; Sat, 28 Apr 2018 18:51:21 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 14:51:18 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <52DD3AEA-B1A5-43AB-8BC5-3CA0F1879672@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 18:51:24 -0000 > On Apr 28, 2018, at 2:34 PM, Paul Wouters wrote: >=20 > But more importantly, it does not specify what the extension content > should be in the absense of a signed TLSA record and not wanting to > put in the denial of existene. Are you expecting an empty payload? > A single NULL payload? Or are you expecting the extension should be > omitted entirely? And what is the expected client behaviour in that = case? The first commit in my pull-request provides a more complete description of DoE processing. = https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/859b164a53= 69e8c997713711771cfb3f7d87c90a#diff-bcaaf747fc40b8dd4fe4e10917b518f2L370 Don't know whether the authors have had a chance to take a look. The present text is IMHO still a bit too skimpy as you note: = https://github.com/tlswg/dnssec-chain-extension/blob/master/draft-ietf-tls= -dnssec-chain-extension-08.xml --=20 Viktor. From nobody Sat Apr 28 11:54:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AEB1272E1 for ; Sat, 28 Apr 2018 11:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EWT60Cxg5Zg for ; Sat, 28 Apr 2018 11:54:34 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43864127241 for ; Sat, 28 Apr 2018 11:54:34 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id p3-v6so5758962itc.0 for ; Sat, 28 Apr 2018 11:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zg48FmUOFJgd8OaQaiLZpBCowlXq55dXzDtHduO0bZA=; b=jmJULSYpN7LhWvIu4Yv84IJSmKeBGvXbSLn8B0n6YbmwsiAmkbLbiP6TC0vsgIXsg+ gvUPL/ZXjs74KmawQpsTKyNtHXZam0EnPUguusyBwEWTAjoKDWm+3+zV4V207d28GL9Y 8xS315HlgSTWj7LfE8oGnGRbmBZcfkAo9R8vzxeIce5FzR58fXzgkXSxpXujZOndVvnk c25fkQyZG4qct9yan6Tm5NduE4jBbS8SV5F/rMd3bGR7Wcytaf5dKbTJqOFevy9NQmTW bSg9gOcmHiQts/s/iy+ORkakW+2AHNvqSPS3JLWuEs7Rfawt6zgmIQ9ngLFQPQ2wRlsG fIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zg48FmUOFJgd8OaQaiLZpBCowlXq55dXzDtHduO0bZA=; b=L2NJEqWpO77ysEcIoGhEIuSa41f4FIqCgG0g9mM/rC+O3Wp9bpDYFa51Ci4sTLXCV5 wT6YTzkqaJpB94AlUbscBtg6wVAgR9i98tOFHRttjNSWnAsWpviMxuSwO3vpda9J/87k wd0bsVQq4z1rEsPXxSEoaTYDUY7HJxLOuviIl9Pw+Z+7rhHG/6y83MID8sLTiWyczOtD HDQaHrv8cm/T14igx4gOcn23KMDuDhaIHlXxXqMpV/Z3LgYhElKrRXxtHopsUya17gKC 9Kelf/u8t2IFccZW1Bv4KvFOQs5AcDmEL17YNFLY0n5Fa89u7HLgTnptH+aYnOji0HAa +VvQ== X-Gm-Message-State: ALQs6tB+EkrTufRJhv8TAxz6NYzHxnTyQbdoAm6zecQHsMtXv8BxWkBt zAleDd5mCSw02QQ6wQnpcT9UVPsylQqrUZDBBMIcwg== X-Google-Smtp-Source: AB8JxZppUJWnyuaOlP8EgU/pxOorAWfBfSfWEkw2XlPstpRur2RTrHgFClz0WduUj9dpEQDGNP4qNJzZkpMZ8mqCJYU= X-Received: by 2002:a24:7ac7:: with SMTP id a190-v6mr7022124itc.151.1524941673429; Sat, 28 Apr 2018 11:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 11:54:32 -0700 (PDT) In-Reply-To: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> References: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> From: Shumon Huque Date: Sat, 28 Apr 2018 14:54:32 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000bf82f2056aed2617" Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 18:54:36 -0000 --000000000000bf82f2056aed2617 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni wrote: > > > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote: > > > > So moving this feature into a new optional > > extension (both the pinning field and a description of the associated > > behavior) appears to me to be the past of least resistance. > > I wish I could be confident that such a specification would > be allowed to move forward. My fear is that the same visceral > opposition to DANE and DNSSEC would play out, and so I may as > well try to get past these now. > I would like to explore this. Is there anyone in the working group who would oppose such a new spec moving forward? (Maybe the WG chairs need to ask this question officially). Shumon --000000000000bf82f2056aed2617 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br> > On Apr 28, 2018, at 12:26 PM, Shumon Huque <shuque@gmail.com> wrote:
>
> So moving this feature into a new optional
> extension (both the pinning field and a description of the associated<= br> > behavior) appears to me to be the past of least resistance.

I wish I could be confident that such a specification would
be allowed to move forward.=C2=A0 My fear is that the same visceral
opposition to DANE and DNSSEC would play out, and so I may as
well try to get past these now.

I would= like to explore this. Is there anyone in the working group
who w= ould oppose such a new spec moving forward?=C2=A0

= (Maybe the WG chairs need to ask this question officially).

<= /div>
Shumon

--000000000000bf82f2056aed2617-- From nobody Sat Apr 28 12:01:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF0E127342 for ; Sat, 28 Apr 2018 12:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn1P5hQYPAr8 for ; Sat, 28 Apr 2018 12:01:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61488127241 for ; Sat, 28 Apr 2018 12:01:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40YKsc72cHz34Z; Sat, 28 Apr 2018 21:01:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524942101; bh=d1Hzu8h7qk+GwJg82siGg6GKbcou6oVRS5X2nGN4x84=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PNP01nB5y9kjy4fNuv1ScRLoyYgE2qF/eeYxRfPTs0PcnbBicRwrqCNcC6FfD3ltP QSJ5IcY7bSd0RH41T0VIyemSMnBctZzAPr0o65pIDjVv0vNnh78DHMCep4AeBvGpB1 ptIU69pc3XSgFCQPBGhXD8JAREctEu/eJPvXaoPU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1Ar_iy1w5aHw; Sat, 28 Apr 2018 21:01:37 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Apr 2018 21:01:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8108361CD5; Sat, 28 Apr 2018 15:01:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8108361CD5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7527440C1031; Sat, 28 Apr 2018 15:01:34 -0400 (EDT) Date: Sat, 28 Apr 2018 15:01:34 -0400 (EDT) From: Paul Wouters To: Shumon Huque cc: TLS WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:01:46 -0000 On Sat, 28 Apr 2018, Shumon Huque wrote: [ not going to repeat my technical arguments here, just going to comment on process ] > First, there is no agreement that your reason for doing pinning, > i.e. that DANE needs downgrade resistance against PKIX attacks > is even valid. This is incorrect. From the replies to the consensus call on the list, it actually weights in favour of _some_ kind of downgrade resistance. In fact, it worries me that the consensus call outcome seems to come from non-public voices and not from a tally of those participants on the TLS list. > This can be clearly seen from various comments on > list and at IETF/London, such as the point made many times that  > the original purpose of this draft was to add DANE as an additional  > possible authentication mechanism in TLS, not to position it as a  > mechanism that if available unconditionally trumps PKIX authentication..  This is actually upsetting. I can assure you that since the late 90's, people were working on DNSSEC as an alternative for the webpki. I wrote RFC 7901 as a building block for doing so, and that RFC is now the basis of the format of the data in this document. It is an explicit goal of _some_ people at IETF and has been for decades. What the motivation is of the individual document editor is not relevant. Once the document was adopted by the WG it became a document that needs to represent WG consensus, not original author intent. I will agree to the point that people in the webpki sphere dislike DNSSEC and don't want to see it competing against webpki. But writing specifications to limit alternatives is not what the IETF is about. The two byte is too much argument is simply a strawman argument. The "additive use case" is a completely made up concept. No one in their right minds will want a security model of "DANE or WebPKI, whichever is weaker". > If you look back at my back-and-forth answering IESG review comments,  > you will observe that I had to add text to the draft that says TLS clients  > can fail back to normal PKIX authentication if DANE fails for any reason > (i.e. a protocol behavior that is the opposite of downgrade resistance).  No one is objecting to that text. > There are other comments like (paraphrasing) "What's the downgrade  > problem? The only security downgrade issue I see is DNSSEC's use of  > legacy crypto"? Everyone makes mistakes, even people in the IESG. Viktor, Nico and I have clearly explained the downgrade attack. If your argument is that the IESG said otherwise and we should believe them, then the IESG is wearing no clothes, unless the specific IESG individual will show us the technical argument of why there allegedly is no downgrade attack. > Clearly, for most DANE proponents, an obvious goal for the protocol > would be to protect against PKIX attacks. In an ideal world, I share > that view also. But I also recognize the other views I just described, > and am willing to make compromises to get a foot in the door for DANE > first. There will always be opportunities to improve the protocol > later. This is again not the proper argument to have. We make arguments based on technical merit and not based on "other [political] views". The technical points against a two byte zero value are non-existent. > In fact, the legacy crypto issue will always be a huge impediment for > any DANE proponent in arguing against the Internet PKI. An argument > I've heard many times: Since most of the Internet PKI has moved to > 2048-bit RSA or better, why would I degrade the security of my system > by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's > in the weakest part of the chain (some chains are even weaker)? And if so, At this rate, this RFC won't be ready before .com is using 2048bit ZSK's. The argument is pretty weak and ephemeral and should not be an argument when writing RFCs. > why should PKIX not need downgrade resistance against DANE It already has that by simply not using DANE, which is what all current browsers already (sadly) do. The refusal of the two byte value however, does not reciprocate that freedom to those users who voluntarilly want to move away from webpki towards dane-only. > vice versa? For DANE proponents to make a stronger case, they need to > urgently solve this problem. I'm not sure how to do that quickly - it > probably involves getting ICANN to impose rules on TLDs prohibiting > weak keys (which would likely take years). Strawman. From what I know, Versign is already investigating the ZSK key length for its zones. Regardless of if that would take years or not, publishing new RFCs that for no reason prohibit moving towards this added security is not what the IETF should be doing. > The second reason is that pinning really is a controversial feature. > And for this reason, putting it in the core spec will be difficult. That is not a technical argument. And Viktor's proposal of just adding the two bytes set to a mandatory 0 in this specification moves the discussion of how/when to pin this extension to that other new document that will see new (technical) discussion. So your argument here is only in favour of those two bytes to ensure proper extension pinning discussion happens in the new to be written specification. > I won't repeat all the arguments and concerns expressed already, many > of which I share by the way. So moving this feature into a new optional > extension (both the pinning field and a description of the associated > behavior) appears to me to be the past of least resistance. The path of least resistance is not the same as rough consensus. > By continuing to argue your position, the most you can hope to achieve > is deadlock. The exact same can be said of you, when you will face the inevitable Appeal Process. Paul From nobody Sat Apr 28 12:04:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C93127342 for ; Sat, 28 Apr 2018 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_f9kUhxCSiX for ; Sat, 28 Apr 2018 12:04:23 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C580A127241 for ; Sat, 28 Apr 2018 12:04:23 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id z4-v6so6141638iof.5 for ; Sat, 28 Apr 2018 12:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EgMsg3LIzHjF3E+TaHIxSBAdNaTuubH+1m2mltX0Uj0=; b=Epluwa3tfo6PU+G+aRuENF8eGBQ4bmOyC5PcRiX2vePp21EKehgBbTU60zw3G9xI2b J3NJ/nfBOC6M8YBCQrxhgaOAWQGbFwvXEQiE/zus3tSfh+shyqpcPJhUdQhW7RhpPv44 TBoXuFimssDFDzr0fh7T+MdMVFTQbf9TtFo5vNpAgNRYJn5BtOaP+tGrkJy2fRaYAihF DkaXO7iUJ+Vf4GFbQNM1A9XXSn27+6SN5HVY+Ms8Hg7XBqGJ1U6PBXH010Fq1sK4ReWJ rQX9w9b7Jm9LXMbBzDWXQuwh6RqxodSsZblAIHc/upa9eRzC5EwTDZCs5Evvwx/3/zi9 LLzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EgMsg3LIzHjF3E+TaHIxSBAdNaTuubH+1m2mltX0Uj0=; b=BtUg0JRr+FT3u2AYS1QuU43YTksZeBrFzGDnAxuOBrWswvxRMIiismV9UOABCA10Jl 7zJdY75hDqCtIFSQy6ylR75EWuQY+cRjmJJ7vDK+2jawIsIBEc0skMVWrh+4InC/t0Ci mNlHwWuUd9D4nJhZtaVWyYWm+3gGxZxh1xPFRuLfrhWrUKVuqQGHXiCmAgO9s5VDCUIE GcjeQBTp6zG1jh6jcnrlA/jmowy5anGBkGQh1ntzOaUuSstzKUN4TRVECvW41yc+ywq/ aOJ9VqSsn+W+nUJw0oqK+2OihrDMdyFgpFykgtT5aMXZxnVfLeP38AAK7dDt0DFSTnmv RAIg== X-Gm-Message-State: ALQs6tC88t7uZbaRgktbdcjiMglZc86Mtic0zsWVEXQa6xdraO9NKATF bNshB7lHBd5ju1bCjHIxbymI2L5BFx7oamDHOdY= X-Google-Smtp-Source: AB8JxZo9H+UK73Kpd2lTObXdd/yYApddvAONpsFif05oTb5viPe3inUs7d9EGIL1ojmR/n1D7HIKEFf6ULShj1cJdcI= X-Received: by 2002:a6b:d43:: with SMTP id 64-v6mr6979399ion.128.1524942263044; Sat, 28 Apr 2018 12:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 12:04:22 -0700 (PDT) In-Reply-To: References: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> From: Shumon Huque Date: Sat, 28 Apr 2018 15:04:22 -0400 Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/alternative; boundary="000000000000e44e9c056aed4982" Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:04:26 -0000 --000000000000e44e9c056aed4982 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes wrote: > > > On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni > wrote: > >> >> >> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: >> > >> > This specification can also be used to optionally convey >> > authenticated denial of existence of TLSA records. Restrictive uses >> > that might require such proofs (such as the PKIX constraining modes >> > of DANE, or where DANE should always be preferred over other modes of >> > authentication such as traditional PKIX) are thus not in its intended >> > scope. Such restrictive uses can however be supported >> > opportunistically. >> >> The last sentence makes no sense. The term "Restrictive uses" is poorly >> defined. The reduction in scope is effectively a reduction to just the >> cases where the extension is mandatory, if that's what you intend to do >> then say so (expect pushback). >> > Yeah, I agree the assertive and restrictive terms are poorly defined. I was using terminology that this WG has been using for a while, but we can reword. > >> Please do not imply that any non-mandatory "additive" use-cases are >> viable. They are not. >> > > I agree with Viktor here. > > You could imagine enforcing a restriction you see in a DANE extension the > cert you get milliseconds later, but that's pretty useless given that an > attacker can just not send the extension. Let's just scope this to the > additive case. > > This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes the latter case, I assume based on his (unproven) assertion that there will no incentive to deploy this. I don't agree. Lots of sites already publish DANE for HTTPS records even before browsers can use them (IETF, freebsd, debian, torproject, defcon, ripe, etc). Once code is implemented/deployed they will be using it. Shumon. --000000000000e44e9c056aed4982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Apr 28, 2018 at 2:17 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Sat, Apr 28, 2018 at 1:52 PM Viktor = Dukhovni <ie= tf-dane@dukhovni.org> wrote:


> On Apr 28, 2018, at 12:19 PM, Shumon Huque <shuque@gmail.com> wrote:
>
>=C2=A0 =C2=A0 This specification can also be used to optionally convey<= br> >=C2=A0 =C2=A0 authenticated denial of existence of TLSA records.=C2=A0 = Restrictive uses
>=C2=A0 =C2=A0 that might require such proofs (such as the PKIX constrai= ning modes
>=C2=A0 =C2=A0 of DANE, or where DANE should always be preferred over ot= her modes of
>=C2=A0 =C2=A0 authentication such as traditional PKIX) are thus not in = its intended
>=C2=A0 =C2=A0 scope.=C2=A0 Such restrictive uses can however be support= ed
>=C2=A0 =C2=A0 opportunistically.

The last sentence makes no sense.=C2=A0 The term "Restrictive uses&quo= t; is poorly
defined.=C2=A0 The reduction in scope is effectively a reduction to just th= e
cases where the extension is mandatory, if that's what you intend to do=
then say so (expect pushback).

Yeah, I agree the assertive and restrictive terms a= re poorly defined. I was
using terminology that this WG has been = using for a while, but we can
reword.
=C2=A0

Please do not imply that any non-mandatory "additive" use-cases a= re
viable.=C2=A0 They are not.

I ag= ree with Viktor here.

You could imagine enforcing = a restriction you see in a DANE extension the cert you get milliseconds lat= er, but that's pretty useless given that an attacker can just not send = the extension.=C2=A0 Let's just scope this to the additive case.

This mean "additive" mandatory or non-mandatory, I as= sume. Viktor opposes=C2=A0
the latter case, I assume based on his= (unproven) assertion that there will no
incentive to deploy this= . I don't agree. Lots of sites already publish DANE for=C2=A0
HTTPS records even before browsers can use them (IETF, freebsd, debian,
torproject, defcon, ripe, etc). Once code is implemented/deployed t= hey will be
using it.

Shumon.
=
--000000000000e44e9c056aed4982-- From nobody Sat Apr 28 12:08:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64A127342 for ; Sat, 28 Apr 2018 12:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEVH5ZKDLB-P for ; Sat, 28 Apr 2018 12:08:15 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FC41275AB for ; Sat, 28 Apr 2018 12:08:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40YL193Hn4zCq8; Sat, 28 Apr 2018 21:08:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524942493; bh=96dnN2GaQewBrGI2Pgy+Lki9AMk0hqTw9eS7AiS6wrQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=W8hWw66DJK9F7KwHi/hFdMQfwiLQe5OnLDqJrokQNRn8hOaCCBZEwY2IOxrri9aAm Qt6ish41v9VL/88jmOLxLIuB51BX5OhJ6+kNSGExoQbm0/M5eS1DoDCvUhVR1T6M90 /uSAa7Hdhrep2Gjeglik4Q4Lom31nBdI+YgeKQ78= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KqhJ3lMmFt36; Sat, 28 Apr 2018 21:08:12 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Apr 2018 21:08:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 74DDB61CD5; Sat, 28 Apr 2018 15:08:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 74DDB61CD5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C16640C1031; Sat, 28 Apr 2018 15:08:11 -0400 (EDT) Date: Sat, 28 Apr 2018 15:08:11 -0400 (EDT) From: Paul Wouters To: Shumon Huque cc: tls@ietf.org In-Reply-To: Message-ID: References: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:08:16 -0000 On Sat, 28 Apr 2018, Shumon Huque wrote: > I wish I could be confident that such a specification would > be allowed to move forward.  My fear is that the same visceral > opposition to DANE and DNSSEC would play out, and so I may as > well try to get past these now. > > I would like to explore this. Is there anyone in the working group > who would oppose such a new spec moving forward?  > > (Maybe the WG chairs need to ask this question officially). There is not much point in doing this, as everyone can "change their mind" later when this document's process has completed. In other words, it won't make me feel any better if no one objects now, unless the chairs would make it a discussion to update the TLS charter to add this work item. And even then, the more inevitable this new work item becomes, the more sense it makes to add the two bytes now to avoid more "designed by committee" weirdness like one extention mandating another extension and figuring out what it means if the mandating-extension itself vanishes. Our two byte proposal is technically sound. Paul From nobody Sat Apr 28 12:21:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE9E12D96A for ; Sat, 28 Apr 2018 12:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YeSxojt7NsJs for ; Sat, 28 Apr 2018 12:21:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5879C124205 for ; Sat, 28 Apr 2018 12:21:56 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 409267A3309 for ; Sat, 28 Apr 2018 19:21:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 15:21:54 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <26F2AEF3-EE90-40E7-90F9-1B4D6A94CFFE@dukhovni.org> References: <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Draft updates: tls-dnssec-chain X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:21:58 -0000 > On Apr 28, 2018, at 3:04 PM, Shumon Huque wrote: >=20 > This mean "additive" mandatory or non-mandatory, I assume. Viktor = opposes=20 > the latter case, I assume based on his (unproven) assertion that there = will no > incentive to deploy this.. I don't agree. Lots of sites already = publish DANE for=20 > HTTPS records even before browsers can use them (IETF, freebsd, = debian, > torproject, defcon, ripe, etc). Once code is implemented/deployed they = will be > using it. My arguments are sound. Would you care to estimate what fraction of published _443._tcp TLSA records actually match the site's certificate chain? What non-hobbyist sites publish such records? It may be cool to play DANE for HTTPS when nobody is verifying, and there's no operational burden of keeping the records correct, (the one BENEFIT listed in my cost/benefit list), but real deployments need real incentives. With Let's Encrypt available, and no downgrade protection for HTTPS with DANE (via this extension) the incentive to support it is nil. --=20 Viktor. From nobody Sat Apr 28 12:28:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40412778D for ; Sat, 28 Apr 2018 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pBGUEQXNREC for ; Sat, 28 Apr 2018 12:28:39 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CC9124205 for ; Sat, 28 Apr 2018 12:28:39 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id e20-v6so6174927iof.4 for ; Sat, 28 Apr 2018 12:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UegmHQNbLDZDn9/KW4HQjvjsFex1Hidu+wnsUYpj37k=; b=NMPFEZbjiymnluRlH3AczYPow95rAk4FLsfPtgBzW7vWehebOIknwKjrL21AT/FenH hoMVVPWBfgPw3+DIpTMLlad408f9Wfm046zHVxo7SehIsubyoK29j8CqFR+NS+dYgr1R C2F7VWPoAcAxw1byUyn014tosSxjyKtmkR36vVyhONPit7Boro9OAjzkcxVd3SS9K9H+ LtATM/DEt+cATs3A0a6eT1LiofatgGdGe7o1Rh3QBju1BI9O5e+7j5gMxnsGLrqjM9tI Ys46xNBzFaV5/koyNDGdemZVwJipCU8vq5W7bYgzi+HhUub/kKCUPKxNM652eZmMlb1Y dIEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UegmHQNbLDZDn9/KW4HQjvjsFex1Hidu+wnsUYpj37k=; b=cRu6d4qQNIMJFe9dr8D9sapTougKh1Jx9NVNEL3sNLV140uFxmoybApC1OF9JR//hx hp9BEVCIp1YW5RqwqEFnJZOJeFFjwDKfM56uwWnk+ongUW8GEnadlFi+FRDDMVKX+yUk nKVrGsatcDER3e/bwBfEaHSEIQ++YDehZDlsmi/rzSum2Rro1I0Gj6hz/ooTtSQ8T1Zk +JxNSxY3LYEg7rF3XNWus3S3FvS9RKCRJcRdbtRWK6IylnaagJvP0af5SqC4QVLWG61E xx8ja64aakDNGX2S5cvgaqYRqDYdxjXpJEJ3NnGI/HAL0nJYj6uFHMNtsJ2VLNrG0Vix OvIw== X-Gm-Message-State: ALQs6tAh7ACek+W5bcJH7y8wBC7zFgwSLx8HmxfmMALJyVgSuEL/i6K/ NFgHOr3CxgZmD/pyt+/DL/Trxn4oWP7iHp0LMWw= X-Google-Smtp-Source: AB8JxZphwwNTeYoGpTTIHOLmWofLkQ4NdYIHRA1eHoUxV7MBa3vNd5tWGC5cCgi9yL5vjHbYmeOYjHReCsBXJ+uxBGc= X-Received: by 2002:a6b:bcc5:: with SMTP id m188-v6mr7684569iof.292.1524943718887; Sat, 28 Apr 2018 12:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 12:28:38 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Sat, 28 Apr 2018 15:28:38 -0400 Message-ID: To: Paul Wouters Cc: TLS WG Content-Type: multipart/alternative; boundary="000000000000aab80a056aeda031" Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:28:41 -0000 --000000000000aab80a056aeda031 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > [ not going to repeat my technical arguments here, just going to comment > on process ] > > First, there is no agreement that your reason for doing pinning, >> i.e. that DANE needs downgrade resistance against PKIX attacks >> is even valid. >> > > This is incorrect. From the replies to the consensus call on the list, > it actually weights in favour of _some_ kind of downgrade resistance. > This isn't clear to me at all. What I observe is that some folks who don't want pinning in the draft are okay with it being an optional separate extension (which they can ignore, but others that want it can implement). Sadly, only a handful of people are actually participating on the list. What you are ignoring is the many people who spoke up in person at IETF/London against pinning. Most of those folks are not speaking up on list now. So if we do put the pinning field in this draft, what I suspect will happen is that it will be discussed at some future IETF TLS WG meeting, and will be shot down, and we'll be back to square one again, and this draft will never make progress. Thus my pragmatic side is encouraging going in the direction of the new extension, which I believe has more chance of success. Shumon. --000000000000aab80a056aeda031 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Apr 28, 2018 at 3:01 PM, Paul Wouters <paul@nohats.ca> wrot= e:
On Sat, 28 Apr 2018, Shumon Huque wrot= e:

[ not going to repeat my technical arguments here, just going to comment on process ]

First, there is no agreement that your reason for doing pinning,
i.e. that DANE needs downgrade resistance against PKIX attacks
is even valid.

 This is incorrect. From the replies to the consensus call on the list,
it actually weights in favour of _some_ kind of downgrade resistance.

This isn't clear to me at all. What I ob= serve is that some folks who don't=C2=A0
want pinning in the = draft are okay with it being an optional separate=C2=A0
extension= (which they can ignore, but others that want it can implement).
=
Sadly, only a handful of people are actually participating o= n the list.=C2=A0
What you are ignoring is the many people who sp= oke up in person at=C2=A0
IETF/London against pinning. Most of th= ose folks are not speaking up=C2=A0
on list now. So if we do put = the pinning field in this draft, what I suspect
will happen is th= at it will be discussed at some future IETF TLS WG=C2=A0
meeting,= and will be shot down, and we'll be back to square one again,
and this draft will never make progress.

Thus my= pragmatic side is encouraging going in the direction of the
new = extension, which I believe has more chance of success.

=
Shumon.

--000000000000aab80a056aeda031-- From nobody Sat Apr 28 12:34:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EC412778D for ; Sat, 28 Apr 2018 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZpWw8YzWvjNe for ; Sat, 28 Apr 2018 12:34:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA80124205 for ; Sat, 28 Apr 2018 12:34:56 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 67FAC7A3309 for ; Sat, 28 Apr 2018 19:34:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 15:34:54 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <2108D5B2-DB05-4841-A018-8E0E61EEF22B@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 19:34:58 -0000 > On Apr 28, 2018, at 3:28 PM, Shumon Huque wrote: >=20 > Sadly, only a handful of people are actually participating on the = list.=20 > What you are ignoring is the many people who spoke up in person at=20 > IETF/London against pinning. Most of those folks are not speaking up=20= > on list now. So if we do put the pinning field in this draft, what I = suspect > will happen is that it will be discussed at some future IETF TLS WG=20 > meeting, and will be shot down, and we'll be back to square one again, > and this draft will never make progress. Consensus is verified on the mailing list. NOT in the room. If we get this draft revised promptly, I would expect it to complete the process before the next IETF in any case. --=20 Viktor. From nobody Sat Apr 28 13:11:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21040127863 for ; Sat, 28 Apr 2018 13:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjqOM8JfcoCh for ; Sat, 28 Apr 2018 13:11:46 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A2412778D for ; Sat, 28 Apr 2018 13:11:46 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id c3-v6so5631277itj.4 for ; Sat, 28 Apr 2018 13:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/oVTrOVmx8+0HD5Ff+knx6tU2kUgke48CdGshxXnRWU=; b=ubfhy1776d1vvpsCcnYEKyGuvlDVbk7sh+8zN78UxO1qPoxixghHi3zTn5UhEuuYSf +twVFwCbyXJt3vEkD+hCngcRvDhiDLsK4xMiumEkRJVrJQ5SEJdJZjmkmQriWML4QhWa RaK57EwIvT49kOIGbUwhoN9yLaC16cN1h5jY2eBb5KgmrFOs57YvBin1XFsxckESw9rY Zo8+u9QBVHqAcMid9u/WghdfmGvUrbkjghKwYiqDZqpOcupFWWWm6CK8km5tV2vlWxX6 Y89G60m7ywUteew0+SDkXUSuxYy87z73j7sTRJC0NpaAYtPCSYG3F7dJA5Ch3WRXqWCJ YJ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/oVTrOVmx8+0HD5Ff+knx6tU2kUgke48CdGshxXnRWU=; b=dQ63V5tRIJ6wDfTAasK44ZSXq19z01ruOMyP+0HHHiMK+F3f3VVRooXZIasuOb9LjB J49Ia6p6UYmHcW3Oo1wU1mc4RHLlslymsD7Rb01pXWOd/mK2KfrR5peibGA9rRP1GgKE 0r0PKyM800FOjAOxah0ix1uGBZuN+AVuC2E4pYCkGGiWxvZStwNr0TSWQwFrra/Z3ygL eObtXBP4eEO53rTjgnAIaYXaOl0uNyA3aNwHwE7Dy6fdO1qidibzdHHSZtIAqABVFftP 8gkuh1B8X0/W1Wt4yLrSG32UPUGWmpgDznDdDTUZw4yU8DPNdm4INweqWzZgeCnElVCy aXIQ== X-Gm-Message-State: ALQs6tB+1CWtoFidvePAjgcGqH2wAazYqN8ovSwj5DwZIuH4zmlZcW4U VXDPW8TCWqWcaTKxaOlJSeVyzPNnILQwGkZg1I8= X-Google-Smtp-Source: AB8JxZqUgsGcx753OsHWLzlddvIKzUB/oc7Zj3XyaAneh9S9JN8FFLS8GntG2DYRQ6X7a3AlEgVK0ZML83COxQtXFJU= X-Received: by 2002:a24:5151:: with SMTP id s78-v6mr6662639ita.103.1524946305566; Sat, 28 Apr 2018 13:11:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 13:11:44 -0700 (PDT) In-Reply-To: References: From: Shumon Huque Date: Sat, 28 Apr 2018 16:11:44 -0400 Message-ID: To: Paul Wouters Cc: TLS WG Content-Type: multipart/alternative; boundary="000000000000d8504d056aee3a0d" Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 20:11:48 -0000 --000000000000d8504d056aee3a0d Content-Type: text/plain; charset="UTF-8" On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > This can be clearly seen from various comments on >> list and at IETF/London, such as the point made many times that >> the original purpose of this draft was to add DANE as an additional >> possible authentication mechanism in TLS, not to position it as a >> mechanism that if available unconditionally trumps PKIX authentication.. >> > > This is actually upsetting. I can assure you that since the late 90's, > people were working on DNSSEC as an alternative for the webpki. I wrote > RFC 7901 as a building block for doing so, and that RFC is now the basis > of the format of the data in this document. It is an explicit goal of > _some_ people at IETF and has been for decades. What the motivation is > of the individual document editor is not relevant. Once the document > was adopted by the WG it became a document that needs to represent WG > consensus, not original author intent. > This is a case where clarifying the scope and limitations of the protocol from the outset would have been helpful. Many DNSSEC people I know who have followed this draft and participated in the much earlier discussions around DNSSEC stapling in certificates were acutely aware of lack of authenticated denial and its obvious implication that there was no downgrade resistance against PKIX. So I always assumed there was at least an implicit understanding of the scope. What greatly surprised me was that Viktor (and you) did not come to this realization until a few months ago (I believe that was shortly after I asked Viktor in private email to read the entire draft and I assume he came upon the text that described the issue, and the possibility of extending the protocol to include DoE later). We probably should have put this text in much earlier versions of the draft. Shumon --000000000000d8504d056aee3a0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Apr 28, 2018 at 3:01 PM, Paul Wouters <paul@nohats.ca> wrot= e:
On Sat, 28 Apr 2018, Shumon Huque wrot= e:

This can be clearly seen from various comments on
list and at IETF/London, such as the point made many times that=C2=A0
the original purpose of this draft was to add DANE as an additional=C2=A0 possible authentication mechanism in TLS, not to position it as a=C2=A0
= mechanism that if available unconditionally trumps PKIX authentication..=C2= =A0

This is actually upsetting. I can assure you that since the late 90's,<= br> people were working on DNSSEC as an alternative for the webpki. I wrote
RFC 7901 as a building block for doing so, and that RFC is now the basis of the format of the data in this document. It is an explicit goal of
_some_ people at IETF and has been for decades. What the motivation is
of the individual document editor is not relevant. Once the document
was adopted by the WG it became a document that needs to represent WG
consensus, not original author intent.

= This is a case where clarifying the scope and limitations of the protocol
from the outset would have been helpful.

= Many DNSSEC people I know who have followed this draft and=C2=A0
= participated in the much earlier discussions around DNSSEC stapling
in certificates were acutely aware of lack of authenticated denial and= =C2=A0
its obvious implication that there was no downgrade resist= ance against=C2=A0
PKIX. So I always assumed there was at least a= n implicit understanding
of the scope.

W= hat greatly surprised me was that Viktor (and you) did not come to
this realization until a few months ago (I believe that was shortly after= I
asked Viktor in private email to read the entire draft and I a= ssume he=C2=A0
came upon the text that described the issue, and t= he possibility of
extending the protocol to include DoE later). W= e probably should have
put this text in much earlier versions of = the draft.

Shumon

=
--000000000000d8504d056aee3a0d-- From nobody Sat Apr 28 13:19:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C740E1200C5 for ; Sat, 28 Apr 2018 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RZLZH49Xy2jJ for ; Sat, 28 Apr 2018 13:19:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0A21200A0 for ; Sat, 28 Apr 2018 13:19:05 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 931207A3309 for ; Sat, 28 Apr 2018 20:19:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 28 Apr 2018 16:19:03 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <616F4599-7409-4ECA-BD78-B16FDE8206A2@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2018 20:19:08 -0000 > On Apr 28, 2018, at 4:11 PM, Shumon Huque wrote: > > What greatly surprised me was that Viktor (and you) did not come to > this realization until a few months ago (I believe that was shortly after I > asked Viktor in private email to read the entire draft and I assume he > came upon the text that described the issue, and the possibility of > extending the protocol to include DoE later). In my case, too many of the available cycles for this document were consumed by the necessary, but not security relevant, discussion of the payload format, and I had no time left for take in the big picture. I wish it were otherwise. It would have been far better to deal with this at the outset... -- Viktor.