From nobody Tue May 1 18:11:32 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 E794612D77D; Tue, 1 May 2018 18:11:24 -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: <152522348490.11353.11257993789744405807@ietfa.amsl.com> Date: Tue, 01 May 2018 18:11:24 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-04.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: Wed, 02 May 2018 01:11:25 -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 : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename : draft-ietf-tls-tls13-vectors-04.txt Pages : 60 Date : 2018-05-01 Abstract: Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and ivs are shown so that implementations might be checked incrementally against these values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 1 18: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 C171812D77D for ; Tue, 1 May 2018 18:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gS5PMV4wSanI for ; Tue, 1 May 2018 18:19:06 -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 A9D6F126C0F for ; Tue, 1 May 2018 18:19:06 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id v2-v6so11522526oif.3 for ; Tue, 01 May 2018 18:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HJsJjBpTeNnEyigrhTQ8vPkvluQ5NedjsNlRwVmy5b0=; b=priqF2DMZzsS82XY0VHs/Xgcn+Q31Vmxf2aWuKanZ//kEe73yzDnafIhd44Kk5QR7J ljZLp/aZzsJbyzQ/H4ZJ/y47io6sNV/ZYfaFmR9MSI4DMoafAmXUoimDKZp/BUGVI3M9 hAAIULa3czuaSCzlkblmwvfen4IDHOYbyqWP96tgwCXKZNOGG56SFulQnRIXcs5a7+s6 5XpctQZnLCHf5PBmfMZMRrzTAHipu7oHakuxNV6oKm2ud9rJgbHr54kbadKK5TXeEJcf 6E9A7I/W4Kps61g+QQz5HNvuWk41b9YfRghGU+vFobfQpiBIGDaApBfia0EbaJAUzPSB frjQ== 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=HJsJjBpTeNnEyigrhTQ8vPkvluQ5NedjsNlRwVmy5b0=; b=fqFC2DW6ytqRszy4tc1IhP7Gm5YznIst3hnCsVU2xpYGSFPZeA3+SJX3bglb+S7u79 c6HtJ9MQM5KpVv7p/pGxOI6EURQUkJ+L8lw/oDVVgwd4WxzYZKDf2PJ+q8iA8AhX9WqF wvUBcecjrgSG1onKo5T+X+PiUd9cY9PTj3dmq98LFu94QTlGbJrQDOLetpKmz6tWFmBf 4BOz9aKs6IMnaD66aI0uf7CxAc3l79z8DCbTo1SAvhGKWg7JMLCpVYEurZYrmSs9YEDI lGZ9OcT4imvVs/9KP5iEzK3S3Wg+DIKC5xuBfeb2r5T8T/gV7EBXTxSQYh63+5Mcrv+b u0uw== X-Gm-Message-State: ALQs6tC88jlVvAf/G7Z5MbC0XaWDOax8i3bhNqhrPy8RD4MlctyKKLep mNxj4LfraA5UGmV9GahRpDwQIcE5CFKt3HC0WbuuYg== X-Google-Smtp-Source: AB8JxZoRa6DDiuIDcNadm2Abft46mhdGWEFiVwkzXXxrupA0UKATnMXhfzYHlq0TlyerhfCTJ9NZSooJfkvXdrOP+TQ= X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr10191933oib.254.1525223945597; Tue, 01 May 2018 18:19:05 -0700 (PDT) MIME-Version: 1.0 References: <152522348490.11353.11257993789744405807@ietfa.amsl.com> In-Reply-To: <152522348490.11353.11257993789744405807@ietfa.amsl.com> From: Martin Thomson Date: Wed, 02 May 2018 01:18:55 +0000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-04.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, 02 May 2018 01:19:09 -0000 Updated to -28. Hopefully this is the last revision before we go to RFC on TLS 1.3. I'd say we're at the point that WGLC makes sense. On Wed, May 2, 2018 at 11:12 AM wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > Title : Example Handshake Traces for TLS 1.3 > Author : Martin Thomson > Filename : draft-ietf-tls-tls13-vectors-04.txt > Pages : 60 > Date : 2018-05-01 > Abstract: > Examples of TLS 1.3 handshakes are shown. Private keys and inputs > are provided so that these handshakes might be reproduced. > Intermediate values, including secrets, traffic keys and ivs are > shown so that implementations might be checked incrementally against > these values. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-04 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-04 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-04 > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 2 16:57: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 7247412E8A0 for ; Wed, 2 May 2018 16:57:11 -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 XmUR2Vzz-Nfu for ; Wed, 2 May 2018 16:57:09 -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 C881F12E8C1 for ; Wed, 2 May 2018 16:57:08 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w42Nqbra005914; Thu, 3 May 2018 00:57:08 +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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=EQ590ZoS+d3zkTJpQn51i/3b5/yfJun5SML02wikOxU=; b=QcZ7b97H/xKv6w3yYURVmJLzp4PhUvtK10UpNGFkLXQQXyEUv/2L7AZyIDYjD2DW2Xiy Ab125WwJA9rJF+NO+Vwvo9biE5vpJrVqGW7JSOb0cE2aaCegDpwQIyp/DOHTlfnn2ohX DO9QTMXemaDfqtWagasEcdgEaHSNfST3iKMvNzNAWM+TR6IzomP/NpAahJ0cWBjdhHFV /uROkhBT8TjENKT6hGG3w+cvb4lDH2vddUaRJ9qrXQUsF8hoXZ+cWdW1pHTTpQY7CqGZ okd2ttwM4UpKBHhmSxUNEA/u4vBjbK2CvHhmtuixC3vVaDNxRuTgkzylnVaqS6O9GJtv yQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2hqgvugwn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 00:57:08 +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 w42NpTgO003999; Wed, 2 May 2018 19:57:07 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hmm9wh6ux-1; Wed, 02 May 2018 19:57:06 -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 C954C82EF3; Wed, 2 May 2018 23:57:06 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fE1cQ-00038i-3T; Wed, 02 May 2018 18:57:06 -0500 Date: Wed, 2 May 2018 18:57:05 -0500 From: Benjamin Kaduk To: Daiki Ueno Cc: tls@ietf.org Message-ID: <20180502235705.GJ5742@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-02_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-1805020200 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-02_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-1805020200 Archived-At: Subject: Re: [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: Wed, 02 May 2018 23:57:15 -0000 On Mon, Apr 23, 2018 at 01:45:34PM +0200, Daiki Ueno wrote: > 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’s 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. It looks like this came in with https://github.com/tlswg/tls13-spec/pull/672 which doesn't provide much commentary on the motivation for it. I believe the latter is the case, in that the issued ticket contains information about the psk_key_exchange_modes sent in the initial handshake, but I disagree with your interpretation that it is only meaningful when the initial handshake is PSK-only. (To be fair, the existing text is not very clear about what it should mean, so confusion is understandable.) In particular, I think "also restricts the modes for use with PSK resumption" means that the psk_key_exchange_modes value(s) sent in the ClientHello is supposed to be retained by both parties and associated with the session ticket, and the saved value(s) then restrict what mode can be used for resumption, along with what values are sent in the resumption handshake itself. This would be useful if, for example, a client sends psk_key_exchange_modes of just psk_dhe_ke in an initial (non-resumption) handshake, so the server can store state in the session ticket that indicates the session ticket must not be used for a psk_ke resumption flow. The text about "SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes" is then pretty devoid of content, since any given PSK (considered as a string of bits) could be used for either psk_ke or psk_dhe_ke -- the math doesn't care. It perhaps means that if the server gets this psk_dhe_ke initial handshake and then stores a session ticket which only references psk_ke, the resumption would fail, but the server has no reason to do that, so we probably didn't even need to say it. -Ben From nobody Thu May 3 04:23: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 1A23612D947 for ; Thu, 3 May 2018 04:22:58 -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 gc7cYMY2jQdY for ; Thu, 3 May 2018 04:22:55 -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 6A96412D959 for ; Thu, 3 May 2018 04:22:55 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id b130-v6so15718136oif.12 for ; Thu, 03 May 2018 04:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zjEA27Eg6XF3eKGeHuHUg4Y9VCQuoz9AH6MD+L6AeIk=; b=xEi0BYYbf6Mzl3FvtvbIUuPYajzftGkx1BUWWGROD3hJFFAUo8fcm3Lsh0lDV4AK5n eFGNIRo/mGQj5+GfhlYHnRUEb9vrPrEvxknHn4/OnC+BaroGEOyHge2kunAwqGLNXr4A y3Dns+5szSc3pMZkVP8540bEKRBD+ZNnOgWNB2xYOb+lBVT6bYWzVmQxcsSBlEL9ITUT BQXsNfByonnhAu/SYifBg0E6TfM4M13bmQBEGcMf9cahd0SzhrFwMqPGv60Zy3qr9Tc6 /XTi+JbvGnGnbHUSXcBgrKE/dfY8/Kjeg4vR587iDA2JI/lZCZfWxW3k5xL3nH1SKwjh w6qg== 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=zjEA27Eg6XF3eKGeHuHUg4Y9VCQuoz9AH6MD+L6AeIk=; b=lt6YQcrJILnT+ZU2nMHDw+x+6GGwE56LkPxUbbcrFxT9tkx3oxvtJ6S/yNdAEDUFqE ILD6ZQ8GnNwOWepyjzDNQ8qihxzfq20hJ1UXbJggkyQfdWhs7htstCMtuLjz3jBV/rAa b5XO1XYYLk9RLmZMrDzheXBTFKFDSwMdz8W59DGRUvMg/MBAYOflfbuKU+GGLheNU39b eSDLeW03kkztGMDMDhQ308waWMHwWFHWTpjDisJDqb+wmdoilV6BZpsCAc9Z9K1nRO7S 9UdC+3T184iNMDpb3kNTtC4CzQzDI4ieBk2Yt7Wp3riQncaYH7OIbh1OeG58jMm31Cfx 3s0g== X-Gm-Message-State: ALQs6tBqS21NuC4LPggVYZvV3c4NAuohUGvCfNXfLEzVoHiliSj9YBk/ Dxtc4AatYfUCaTuWRtSpHbq4MLp3z2LLSZ/YXGtPZQ== X-Google-Smtp-Source: AB8JxZoQPDD/nmtmxyDeX8U/VfTSjsua6Z8zI8PVluvtm5quqKWingAc2go/4nJocrQ/ZjcuKyrL42cMe3NOoVMDxn8= X-Received: by 2002:aca:3cc1:: with SMTP id j184-v6mr14973684oia.91.1525346574595; Thu, 03 May 2018 04:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 04:22:14 -0700 (PDT) In-Reply-To: <20180502235705.GJ5742@akamai.com> References: <20180502235705.GJ5742@akamai.com> From: Eric Rescorla Date: Thu, 3 May 2018 04:22:14 -0700 Message-ID: To: Benjamin Kaduk Cc: Daiki Ueno , "" Content-Type: multipart/alternative; boundary="000000000000bd136b056b4b6c17" Archived-At: Subject: Re: [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: Thu, 03 May 2018 11:22:58 -0000 --000000000000bd136b056b4b6c17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2018 at 4:57 PM, Benjamin Kaduk wrote: > On Mon, Apr 23, 2018 at 01:45:34PM +0200, Daiki Ueno wrote: > > 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 th= e > > ticket encryption key is required to be forward secret. From the > > implementation point of view, that would be provided as an option in th= e > > 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. > > It looks like this came in with https://github.com/tlswg/ > tls13-spec/pull/672 which doesn't > provide much commentary on the motivation for it. > > I believe the latter is the case, in that the issued ticket contains > information > about the psk_key_exchange_modes sent in the initial handshake, but I > disagree with > your interpretation that it is only meaningful when the initial handshake > is PSK-only. > (To be fair, the existing text is not very clear about what it should > mean, so > confusion is understandable.) > > In particular, I think "also restricts the modes for use with PSK > resumption" > means that the psk_key_exchange_modes value(s) sent in the ClientHello is > supposed > to be retained by both parties and associated with the session ticket, an= d > the > saved value(s) then restrict what mode can be used for resumption, along > with > what values are sent in the resumption handshake itself. This would be > useful if, > for example, a client sends psk_key_exchange_modes of just psk_dhe_ke in > an initial > (non-resumption) handshake, so the server can store state in the session > ticket that > indicates the session ticket must not be used for a psk_ke resumption flo= w. > The text about "SHOULD NOT send NewSessionTicket with tickets that are no= t > compatible > with the advertised modes" is then pretty devoid of content, since any > given PSK > (considered as a string of bits) could be used for either psk_ke or > psk_dhe_ke -- > the math doesn't care. It perhaps means that if the server gets this > psk_dhe_ke > initial handshake and then stores a session ticket which only references > psk_ke, > the resumption would fail, but the server has no reason to do that, so we > probably > didn't even need to say it. > What this text is supposed to mean is that the server shouldn't send tickets if it doesn't like the client's psk_ke modes. So, say that the client only supports psk_dhe_ke and the server only supports psk_ke, then the server shouldn't advertise tickets, because future resumption will be useless. -Ekr _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000bd136b056b4b6c17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 2, 2018 at 4:57 PM, Benjamin Kaduk <bkaduk@akamai.com&= gt; wrote:
On Mon= , Apr 23, 2018 at 01:45:34PM +0200, Daiki Ueno wrote:
> Hello,
>
> I have a question about handling the psk_key_exchange_mode extension.<= br> >
> 4.2.9. Pre-Shared Key Exchange Modes says:
>
>=C2=A0 =C2=A0This extension also restricts the modes for use with PSK r= esumption;
>=C2=A0 =C2=A0servers SHOULD NOT send NewSessionTicket with tickets that= are not
>=C2=A0 =C2=A0compatible 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 t= he
> ticket encryption key is required to be forward secret.=C2=A0 From the=
> implementation point of view, that would be provided as an option in t= he
> server configuration.
>
> On the other hand, if the latter is the case, the server requires PSK<= br> > with (EC)DHE when the initial handshake chose (EC)DHE key exchange, > because the ticket is tied to resumption_master_secret derived from th= e
> (EC)DHE secret.
>
> Since the above paragraph is followed by:
>
>=C2=A0 =C2=A0however, if a server does so, the impact will just be that= the
>=C2=A0 =C2=A0client=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.

It looks like this came in with https://github.co= m/tlswg/tls13-spec/pull/672 which doesn't
provide much commentary on the motivation for it.

I believe the latter is the case, in that the issued ticket contains inform= ation
about the psk_key_exchange_modes sent in the initial handshake, but I disag= ree with
your interpretation that it is only meaningful when the initial handshake i= s PSK-only.
(To be fair, the existing text is not very clear about what it should mean,= so
confusion is understandable.)

In particular, I think "also restricts the modes for use with PSK resu= mption"
means that the psk_key_exchange_modes value(s) sent in the ClientHello is s= upposed
to be retained by both parties and associated with the session ticket, and = the
saved value(s) then restrict what mode can be used for resumption, along wi= th
what values are sent in the resumption handshake itself.=C2=A0 This would b= e useful if,
for example, a client sends psk_key_exchange_modes of just psk_dhe_ke in an= initial
(non-resumption) handshake, so the server can store state in the session ti= cket that
indicates the session ticket must not be used for a psk_ke resumption flow.=
The text about "SHOULD NOT send NewSessionTicket with tickets that are= not compatible
with the advertised modes" is then pretty devoid of content, since any= given PSK
(considered as a string of bits) could be used for either psk_ke or psk_dhe= _ke --
the math doesn't care.=C2=A0 It perhaps means that if the server gets t= his psk_dhe_ke
initial handshake and then stores a session ticket which only references ps= k_ke,
the resumption would fail, but the server has no reason to do that, so we p= robably
didn't even need to say it.

What th= is text is supposed to mean is that the server shouldn't send tickets i= f it doesn't
like the client's psk_ke modes. So, say that= the client only supports psk_dhe_ke and the
server only supports= psk_ke, then the server shouldn't advertise tickets, because future
resumption will be useless.

-Ekr
=

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

--000000000000bd136b056b4b6c17-- From nobody Thu May 3 05:42: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 CEC8512426E for ; Thu, 3 May 2018 05:42:17 -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 4SdEsP6j-rEu for ; Thu, 3 May 2018 05:42: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 7A4211204DA for ; Thu, 3 May 2018 05:42:16 -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 w43CSAog009667; Thu, 3 May 2018 13:42:15 +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=H6x1YiSr1jPwVhaNKWay7BUOVB+gLy8ePJwYHQmQbdo=; b=b+MiF72/pqKYXxhjAHZavujkX23hdD33OLc4daqb0/8gC+SRfMWYVRjG13TRYbqRh5qj em1sEUWTTOffVJICTKwZV1tGsqQIii3TP5+uPpNgiG5twix5r3BQpnaUWqP9eWBo4kty VPVRpkCJj1YCOayvAugLxvKz2B9TxZYgElpZ/LZJmdxbIaNgLHctOULm9Ci5Kn1yJ5WD F3gBBI/Awfdo5GoO42Js95RUFyfMp3tQHGE7uQL66Xjgu25HJzd8u7vznBxncCMr59gS TttTRYZ804aRliNy/9QBk6W1Xqc/CZvQT97I6O4B1Oapcjrb4mBbBRLGieDyaaBxxXG9 Kg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2hqyfp8cuj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 13:42:14 +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 w43CflZQ009674; Thu, 3 May 2018 08:42:13 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2hr1anr8qq-1; Thu, 03 May 2018 08:42:13 -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 6028C27E2F; Thu, 3 May 2018 12:42:13 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fEDYq-0005Lf-Ph; Thu, 03 May 2018 07:42:12 -0500 Date: Thu, 3 May 2018 07:42:12 -0500 From: Benjamin Kaduk To: Paul Wouters Cc: TLS WG Message-ID: <20180503124212.GK5742@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-05-03_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-1805030114 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030113 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: Thu, 03 May 2018 12:42:18 -0000 On Sat, Apr 28, 2018 at 03:01:34PM -0400, 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. > > 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. Given that this mail is framed as just a process comment, and even though you rightly refer to "technical merits" in a later (trimmed) portion, I must object to the use of "tally of those participants on the TLS list". "Tallying participants" implies counting votes, but of course the person making the consensus call is charged with using their technical judgment to assess the replies received on the merits. -Ben From nobody Thu May 3 05:54: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 0EC36126C83 for ; Thu, 3 May 2018 05:54:15 -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 Qw5Y4XVJTrqw for ; Thu, 3 May 2018 05:54:14 -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 CC9301204DA for ; Thu, 3 May 2018 05:54:13 -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 w43CqZrf028704 for ; Thu, 3 May 2018 13:54:13 +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=aAFR9rvZLxyqwhhI/+KILHyLeFwxYMXKz6dwa2sDVCM=; b=J/1OmRnh3KZKVnG5zTYf9lz5XJmoCpSFRK2f4NqZCv1dlcjG16gq00FBFVAIRGM2JD6k PLEgd1O+TGai12vOui8HVUO/TeZaQ0vWzysFltlckW0/u2YKPdLp36Dl59Y2RnwM93N2 0lwkvgat04WTFMzWrK7p+ftLWCv/scI7AkHqjf1h3/sMko+bC71szd1XLcsMBFX4de5F IVa9N2wLX2SoH9+cfDOJdkJn3Wk83djy0b1//HyD5KsZDInp05YSsixu1f8QT1zPfAGz drQk/Lyo10WPj5zEFNogViMv/rAS38Xb0kDSy3ISfFmn3HL8Vgmq2vSSM6f8uIy2q/wo bw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2hqyfp8dmy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 03 May 2018 13:54:12 +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 w43CkgEg017520 for ; Thu, 3 May 2018 08:54:12 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hmm9wkbhd-1 for ; Thu, 03 May 2018 08:54:12 -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 121DC81FA2 for ; Thu, 3 May 2018 12:54:12 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fEDkR-0005Mw-6X for tls@ietf.org; Thu, 03 May 2018 07:54:11 -0500 Date: Thu, 3 May 2018 07:54:11 -0500 From: Benjamin Kaduk To: TLS WG Message-ID: <20180503125410.GL5742@akamai.com> References: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_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=806 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_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=777 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030116 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: Thu, 03 May 2018 12:54:15 -0000 On Sat, Apr 28, 2018 at 01:40:25PM -0400, Viktor Dukhovni wrote: > > > 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 It is not puzzling to me, for two reasons: (1) fairly early on, the proposal was framed as something that might be obtained from "good faith in return", which can be interpreted as the sort of "horse trading" that many IETFers have a visceral objection to. It is hard to erase this memory when considering subsequent discussions. (2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority that the 16-bit value (in hours) is sufficient, and no other fields or semantic changes would be needed. While I (and presumably others) do have a great deal of confidence in your collective technical expertise, it still seems to be presumptuous and a coopting of the WG consensus process for the follow-up pinning document. > 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. The above notwithstanding, I'm not sure that I can dispute this worst case assessment, at present. (Presumably "egg on our collective faces" doesn't really count.) -Ben From Ipsito.Ghosh@ncr.com Thu May 3 05:57: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 C0E3A126C83 for ; Thu, 3 May 2018 05:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncr.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQl2pu3AVFAY for ; Thu, 3 May 2018 05:57:05 -0700 (PDT) Received: from mx0b-00209e01.pphosted.com (mx0b-00209e01.pphosted.com [148.163.152.55]) (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 0FC281204DA for ; Thu, 3 May 2018 05:57:04 -0700 (PDT) Received: from pps.filterd (m0115756.ppops.net [127.0.0.1]) by mx0b-00209e01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w43CsJUq020348 for ; Thu, 3 May 2018 08:57:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncr.com; h=from : to : subject : date : message-id : content-type : mime-version; s=mail; bh=iWSGzoYT0UfrhoM3WGDbe0lAwGK9QAFt07ODXprPtqs=; b=uRO3d+kuz9OMsH9YVZlv+lCHaDMyy4+7RnWEn1/cUfS9WJioiU/dtgCtz9l2DYL4jues Qi0zgTo54IHKpeUzEOXvLQmzmK1WrBSx6u3JnfI+9OFOVuxYMXWflVTQNedAiJKpaLG8 IWjtm3Yxjpv7HU8NXWbwDNKMM4Ztxyy3UEAvTymWdD02eH9xdVY56X6EnCM8Pwc4psGC u4qGe6OfC8IcGXG59j79AIOOxtTL+wWqqYxmKE2GDfTVCYdCgAXdH1H1oJdCINQqFffm /bszjtGDinHrIKshDyDiVQyYoOhrWTf2vmA9gH3LLgw0DcaAWQD4Bqj5NId0PEWfUZh4 +A== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0080.outbound.protection.outlook.com [207.46.163.80]) by mx0b-00209e01.pphosted.com with ESMTP id 2hr2118ckx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 03 May 2018 08:57:03 -0400 Received: from DM6PR15MB2266.namprd15.prod.outlook.com (20.176.70.20) by DM6PR15MB2345.namprd15.prod.outlook.com (20.176.70.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.16; Thu, 3 May 2018 12:57:02 +0000 Received: from DM6PR15MB2266.namprd15.prod.outlook.com ([fe80::ed4f:6ddd:a0cb:d373]) by DM6PR15MB2266.namprd15.prod.outlook.com ([fe80::ed4f:6ddd:a0cb:d373%13]) with mapi id 15.20.0715.024; Thu, 3 May 2018 12:57:02 +0000 From: "Ghosh, Ipsito" To: "tls@ietf.org" Thread-Topic: TLS 1.3 Specification Thread-Index: AdPi3fA199fOfW2UTSmoI1fKcLXZ9g== Date: Thu, 3 May 2018 12:57:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.82.222.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR15MB2345; 7:6Fs+B7ohkxJhfBhHf4/uYAHoHBmlm5QoCRm/WwPUHvFgavEvl0EmT3RvbLrZppKMLAKphLU1OApTve3MT9jRSehlh1mn1PvflUxZafVi7PwsqXWWFJYsuOURADJcPXyNwp91dOxMGenUEdrfNKh8ggEWraRVh1jttLKu/Dt8tSROyRbOaCCQ3YH6pUA3nbylOZPpl3R4NzKBU69erdV+katxR/Yf5fWFmHmdGbiRGuGCMINCbc1Q1wVVs+nWoJKa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM6PR15MB2345; x-ms-traffictypediagnostic: DM6PR15MB2345: x-from-ncr-tenant: Processed x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM6PR15MB2345; BCL:0; PCL:0; RULEID:; SRVR:DM6PR15MB2345; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(376002)(396003)(346002)(189003)(199004)(86362001)(74316002)(186003)(102836004)(3280700002)(316002)(3846002)(3660700001)(99286004)(53936002)(2900100001)(26005)(6506007)(97736004)(2906002)(66066001)(558084003)(790700001)(7696005)(6116002)(5660300001)(5640700003)(8936002)(606006)(5250100002)(33656002)(81166006)(105586002)(2501003)(7116003)(6436002)(81156014)(8676002)(476003)(1730700003)(478600001)(6306002)(5630700001)(486006)(413944005)(966005)(25786009)(236005)(9686003)(54896002)(72206003)(2351001)(106356001)(68736007)(4743002)(7736002)(6916009)(55016002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2345; H:DM6PR15MB2266.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncr.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DCF4ju0s47J9Epy5j0DLRBpPGabT/Y0QOGH6oz9F+zkXmgCBTs2pLOUONUCG0wxeXPWIXGegrrCDLzVZxNRwLJjHTuRFCv0H4fDJPa8SWuBOELrHufuNjdWooNMwT4ITW8onyLx7sxqbAxiKULRNVkurg28LioliBUcojZV2p/R63EPl/eEP5danwvvcVIk8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2266E95752925D1E5D990FFC87870DM6PR15MB2266namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 14c22253-8851-4cd0-221c-08d5b0f55d72 X-OriginatorOrg: ncr.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14c22253-8851-4cd0-221c-08d5b0f55d72 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 12:57:02.3248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ae4df1f7-611e-444f-897e-f964e1205171 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2345 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=606 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030116 Archived-At: X-Mailman-Approved-At: Thu, 03 May 2018 06:05:31 -0700 Subject: [TLS] TLS 1.3 Specification X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 12:59:29 -0000 --_000_DM6PR15MB2266E95752925D1E5D990FFC87870DM6PR15MB2266namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Team, Some of the SSL providers are already rolled out TLS 1.3 ( OpenSSL , Boring= SSL etc) . Does the TLS 1.3 draft is finalized yet ? https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Regards, Ipsito --_000_DM6PR15MB2266E95752925D1E5D990FFC87870DM6PR15MB2266namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Team,

 

Some of the SSL providers are already rolled out TLS= 1.3 ( OpenSSL , BoringSSL etc) .

 

Does the TLS 1.3 draft is finalized yet ?

 

https://tools.ietf.org/html/draft-ietf-tls-tls13-28

 

 

Regards,

Ipsito

--_000_DM6PR15MB2266E95752925D1E5D990FFC87870DM6PR15MB2266namp_-- From nobody Thu May 3 06:08: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 AB5B112DA3E for ; Thu, 3 May 2018 06:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QZ4exqD_kK10 for ; Thu, 3 May 2018 06:08:27 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFA212DA22 for ; Thu, 3 May 2018 06:08:27 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id m16-v6so22689448qtg.13 for ; Thu, 03 May 2018 06:08:27 -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=hJJOVX4vLhnH08Yd1E2DPsVeBBJzfhoTu2URqf8dLQE=; b=HpCBSyR9yHH9Ns0tKx73NaIreSM11F9DdkRrSiVW0aRYNtu7KOFoWqR6XSnefI9FTB Uix/uYcAnNTveGEwAe5sOeQRhCE2L/uNOWigECi2121ZS9LoWItv4IP2ANxDL59dxyOX pntwTDIEkhjdlOhWUvI3rhVDAQixqb/rsnRwI= 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=hJJOVX4vLhnH08Yd1E2DPsVeBBJzfhoTu2URqf8dLQE=; b=nAvtIE0/pOyi68UQqIa5i0z4o04yK0w6B/nd1pYu2XinHPJQXFQk6PzIat+QPIUF9q kwS/lAD9Gc/sjDTPP8fYqIJ1Z29PBsytqJD5kdir09NxQ6HBH2iuppVRmiGoLFyBAljt vNzWsRrec88Pn2nKZ+NiFOmLZAFVkFiQH8w/CpOjjy8RyrgG1o9daFs3YWdPohLZp7Tq CzibkcZT9Eqf1bQXfOnh6LHkP2/cx0Lv/vYiCfGvsC7njEXfrWzMgQXvDtBWNKVt+eo8 NPFfZ6cyH+Gt8Qb/TgYb87EgbazLCKRIcwAFDcYsZfBMJc4ePDLAf8pkai1KvbzLNNRf kOWg== X-Gm-Message-State: ALQs6tBBpBAKMRVXG6FMFT1j53QTmOLVSWrmp3JsxzrVIUC1kgTXsP7v 0g3iynpEPfcbS8dOQYI/QBjkNg== X-Google-Smtp-Source: AB8JxZqePAo3GGZvD7YeBIqQ8DAQ+mchAqAxJI8IQme4ZwdAcxDODbKCdLc5IWK8l54EUPsZOqr0rQ== X-Received: by 2002:ac8:2627:: with SMTP id u36-v6mr20561464qtu.189.1525352906584; Thu, 03 May 2018 06:08:26 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id y188sm418951qka.19.2018.05.03.06.08.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 06:08:25 -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: Thu, 3 May 2018 09:08:24 -0400 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Ghosh, Ipsito" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS 1.3 Specification X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:08:30 -0000 The IESG has approved the draft, but it still needs to complete the RFC = editor phase where copy editing, changing of the boilerplate, assigning = an RFC #, etc gets done to make it an RFC. You can see the RFC = editor=E2=80=99s queue here: https://www.rfc-editor.org/current_queue.php spt > On May 3, 2018, at 08:57, Ghosh, Ipsito wrote: >=20 > Dear Team,=20 > =20 > Some of the SSL providers are already rolled out TLS 1.3 ( OpenSSL , = BoringSSL etc) . > =20 > Does the TLS 1.3 draft is finalized yet ?=20 > =20 > https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > =20 > =20 > Regards,=20 > Ipsito > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 3 06:10: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 3ED1112DA25 for ; Thu, 3 May 2018 06:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zmATBpOPwxg3 for ; Thu, 3 May 2018 06:10:16 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BB212DA22 for ; Thu, 3 May 2018 06:10:16 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id b131so13847851qkg.2 for ; Thu, 03 May 2018 06:10:16 -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=qpyzUWPLm8AeYWJnJTpiAIN59HngyoUusrDmcm0J334=; b=BcoAhBrnoyzroBwoMadsjD1qZfJFK+fcrxox2kmIdT41OhyvlXd4GXg8Q2BHkS/D3M 6ThL0W43BN/zhpXaW08FPnCvbQ7BL6fojDv3Sn/FyS3eexPRf7I8R+kWnN/p3zU7Mt6s AZxJ3avkzA1eHRvUEwYF9TYv6nD9GddZL38Pw= 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=qpyzUWPLm8AeYWJnJTpiAIN59HngyoUusrDmcm0J334=; b=bBXJWg6t/XWFSLUiqvrDobDlY1fdTqp9ySk3bM6590eNylFy8sJwqYit/SRYjB2Vm1 nHN9GF+aspHjEKcJYskQZ011186SDQbAqEfzH+Slo4JUXiAIhrsdWpy6g+5MWkOnqdmQ BEj39xGzaBtY5zxbzpHuqJsX2PNWATjsayp+R1UlbQlqpvKA8KkiIV1IDv+ynQu56vNF Gol9OeM0eZq6Em5RqZg/Uz/J9AVTEOq//+CwWxyMgC/MwtlX4Sv427AMhto/UnzVcpky UliujYnzzyFxwKqotkENrz+aPa0AYYyQ8ermjg2RFiRLk4MUzOY+N/I4w5OgFEM2JHnw rmUQ== X-Gm-Message-State: ALQs6tBNyQdRE6kJNVvx8efD5ACji5adJAzi+8Whrmi9tSeQKOEUE6VR OrSY6THRieMbZ3Hc3m5AAII2fw== X-Google-Smtp-Source: AB8JxZoptVdncHVb5gIXVRpa5UF2UmkNZbzGcfIbW6TfmeKIPvEnKvuuSFGjDsvZNYx0qlcECRp2vg== X-Received: by 10.55.77.140 with SMTP id a134mr18183026qkb.404.1525353015728; Thu, 03 May 2018 06:10:15 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id c123sm11228878qkd.74.2018.05.03.06.10.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 06:10:14 -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: Thu, 3 May 2018 09:10:13 -0400 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <152522348490.11353.11257993789744405807@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-04.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, 03 May 2018 13:10:18 -0000 Martin, We=E2=80=99ll get this WGLC started soon. spt > On May 1, 2018, at 21:18, Martin Thomson = wrote: >=20 > Updated to -28. Hopefully this is the last revision before we go to = RFC on > TLS 1.3. I'd say we're at the point that WGLC makes sense. > On Wed, May 2, 2018 at 11:12 AM wrote: >=20 >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 >> Title : Example Handshake Traces for TLS 1.3 >> Author : Martin Thomson >> Filename : draft-ietf-tls-tls13-vectors-04.txt >> Pages : 60 >> Date : 2018-05-01 >=20 >> Abstract: >> Examples of TLS 1.3 handshakes are shown. Private keys and inputs >> are provided so that these handshakes might be reproduced. >> Intermediate values, including secrets, traffic keys and ivs are >> shown so that implementations might be checked incrementally = against >> these values. >=20 >=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ >=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-04 >=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-vectors-04 >=20 >=20 >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 3 06:58: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 5C16A12E03E for ; Thu, 3 May 2018 06:58:00 -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 FM7ix8ZQ9sDz for ; Thu, 3 May 2018 06:57:59 -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 C89E512DA6E for ; Thu, 3 May 2018 06:57: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 6FCD77A3309 for ; Thu, 3 May 2018 13:57:57 +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: <20180503125410.GL5742@akamai.com> Date: Thu, 3 May 2018 09:57:55 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <7409EE8A-425E-4D7A-AAB5-1AB6B36AD4B9@dukhovni.org> References: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> <20180503125410.GL5742@akamai.com> 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: Thu, 03 May 2018 13:58:00 -0000 > On May 3, 2018, at 8:54 AM, Benjamin Kaduk wrote: > > (2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority > that the 16-bit value (in hours) is sufficient, and no other fields or > semantic changes would be needed. While I (and presumably others) do have > a great deal of confidence in your collective technical expertise, it still > seems to be presumptuous and a coopting of the WG consensus process for the > follow-up pinning document. Well, MTA-STS is not getting objections for having just "max-age" and "testing", with a separate specification for an optional reporting address (that also retroactively supports DANE). The address is not part of the STS policy to be delivered in-band with each policy lookup. It is a obtained separately from a TXT record in DNS. It is easy to observe that: 1. If TLS is to support some sort of contact address for resolving operational issues that affect TLS interoperability, then it *should not* be restricted to just a particular extension. Such address would be accessed independently of the DNSSEC chain extension. Perhaps in DNS, or perhaps solicited via a separate suitable client extension. 2. The idea of "testing" makes little sense for negotiating a support lifetime for the DNSSEC chain extension that is not itself subject to any sort of "testing". The complex new behaviour here that one might have wanted to test, is introduction of DANE-based authentication. Expecting (client side) the extension to be supported on an ongoing basis for a time no longer than *advertised by the server* involves nothing one would want to "test". If not sure about ongoing support, the server operator should leave the field at zero, or set it to just an hour or two. There's no need here for anything beyond the time field. And if we turn out to be wrong about that, then the follow-on document can still specify a new extension with any additional fields there, with the lifetime in this extension and the other data in the new extension. Surely the new extension will have at least at least a time field which can still be included in this one, with additional fields in the new extension. A second extension to protect a first against downgrades looks add to me in this day and age. Integrated downgrade protection makes more sense. Let's take a chance on getting it right from the start. -- Viktor. From nobody Thu May 3 08:21: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 56708127978 for ; Thu, 3 May 2018 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0afTG6NRF0uZ for ; Thu, 3 May 2018 08:21:53 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBBE1277BB for ; Thu, 3 May 2018 08:21:53 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id b39so14216935qkb.5 for ; Thu, 03 May 2018 08:21:53 -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=pbi/3vUiQr5rpxItfGMveDyjpiScvfh/nDz8p2JjdHI=; b=nsRKL938uu9eWZafuX2gK8MmC4lApsoTdz/y3UsX214YD+LYmchhgP2UH3Ac1Ne1+1 nJkFzZOw35L3wd60UKkpPAFPbxUFNzXETQZCGHFYqen6mJbtRRmRkAHO50P5qSvz73i+ P1SRsheN0HZJNdP1uYDi6RtZLeqQOWkhwJkrQ= 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=pbi/3vUiQr5rpxItfGMveDyjpiScvfh/nDz8p2JjdHI=; b=SwC9QKPFpTqy7rWgUP199owPjb0bQwoFDqBcIeYFiCveD84cwCpjerahN7hK0NH5gF ozKk1HpG+Iet3PpopjonP9wxAdhcZNlMj1bbMZtx2GnSUOk2EX5i8qif0awfHZu63rSe Wr9Z3hOEpYI7iQOSwoJMr5ZY3zsjstc22pKrU4AsC4+t/g2dzYBDbsNFieXjyd9JVcEJ zLiM6D91HC6LAdNZoigMqO+CElcbXlKIeIfPq/lJtNRyYbwyu6DNBiQxENlozyMDRGW7 qR9pWqfmhn3ANOcqQ1jpeIOkenUAvN1TQzVLSzV/EjEbfPphwMRMzp+Yty56fw9cencg wHRg== X-Gm-Message-State: ALQs6tDRQgJFyLI6024zp1mLjcFZHoTV4iLypsElHvhxO7cA7EEwXogb K97XCtfXiLPxCvOH7ByNGJ23dRCYtfODMJtFwZD3 X-Google-Smtp-Source: AB8JxZqswT1Rv2WHlHMSob4KAvl45gbUF/9geaRgUM7PLpYcMFgHXlpm3zxodemNZOVTY2zOd/Eoygtfu1IRcAYoBl0= X-Received: by 10.233.220.129 with SMTP id q123mr14866310qkf.318.1525360911972; Thu, 03 May 2018 08:21:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 03 May 2018 15:21:41 +0000 Message-ID: To: Sean Turner Cc: "Ghosh, Ipsito" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c04551250aabf056b4ec3cd" Archived-At: Subject: Re: [TLS] TLS 1.3 Specification X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 15:21:55 -0000 --94eb2c04551250aabf056b4ec3cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BoringSSL and OpenSSL have are draft versions which use different version numbers from the final RFC, so as not to collide. Early experimental deployment is generally useful to help inform the final standard and flush out any non-compliant TLS 1.2 implementations that may cause deployment difficulties. (This, of course, also means that any draft versions are experimental and doomed to be replaced by the final RFC once published.) On Thu, May 3, 2018 at 9:08 AM Sean Turner wrote: > The IESG has approved the draft, but it still needs to complete the RFC > editor phase where copy editing, changing of the boilerplate, assigning a= n > RFC #, etc gets done to make it an RFC. You can see the RFC editor=E2=80= =99s queue > here: > > https://www.rfc-editor.org/current_queue.php > > spt > > > On May 3, 2018, at 08:57, Ghosh, Ipsito wrote: > > > > Dear Team, > > > > Some of the SSL providers are already rolled out TLS 1.3 ( OpenSSL , > BoringSSL etc) . > > > > Does the TLS 1.3 draft is finalized yet ? > > > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28 > > > > > > Regards, > > Ipsito > > _______________________________________________ > > 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 > --94eb2c04551250aabf056b4ec3cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BoringSSL and OpenSSL have are draft versions which use di= fferent version numbers from the final RFC, so as not to collide. Early=C2= =A0experimental deployment is generally useful to help inform the final sta= ndard and flush out any non-compliant TLS 1.2 implementations that may caus= e deployment difficulties. (This, of course, also means that any draft vers= ions are experimental and doomed to be replaced by the final RFC once publi= shed.)

O= n Thu, May 3, 2018 at 9:08 AM Sean Turner <sean@sn3rd.com> wrote:
= The IESG has approved the draft, but it still needs to complete the RFC edi= tor phase where copy editing, changing of the boilerplate, assigning an RFC= #, etc gets done to make it an RFC.=C2=A0 You can see the RFC editor=E2=80= =99s queue here:

https://www.rfc-editor.org/current_queue.php

spt

> On May 3, 2018, at 08:57, Ghosh, Ipsito <Ipsito.Ghosh@ncr.com> wrote:
>
> Dear Team,
>=C2=A0
> Some of the SSL providers are already rolled out TLS 1.3 ( OpenSSL , B= oringSSL etc) .
>=C2=A0
> Does the TLS 1.3 draft is finalized yet ?
>=C2=A0
> https://tools.ietf.org/html/draft-ietf-tls-t= ls13-28
>=C2=A0
>=C2=A0
> Regards,
> Ipsito
> _______________________________________________
> 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
--94eb2c04551250aabf056b4ec3cd-- From nobody Thu May 3 13:12: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 0EFC212EA6A for ; Thu, 3 May 2018 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 sHnXbAhbvcMx for ; Thu, 3 May 2018 13:12:17 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D85912DA11 for ; Thu, 3 May 2018 13:12:17 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id g13-v6so24590436qth.8 for ; Thu, 03 May 2018 13:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=VDk+nAX+whrj0/OMhKPgL/RrbvPgWhWjdrc3piFiY7A=; b=NBvEsnAjqUZo7/lp7vwbS2zu+xX4TcbJLoVoP08Qgss4W9eJtJTUHdBiwqgsdXS7KB YnSTy6tokhc4I9KlBN/cltN4O1prmSUCn/lh8+CBe1KococBC6a0Pl6bAbas/uT4PYuY Vgl5aE3RUof7QvJOW5YPBvPtU7yMH9ZczCZmI= 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=VDk+nAX+whrj0/OMhKPgL/RrbvPgWhWjdrc3piFiY7A=; b=dFgho7NQpzeRcLtMp4wAgAp9aQT9kpIo/LPYME/OWOyRqN4GcTVsUs3qbKu1A0VUpi HeU8lzDd/0LHp5pZQ6MT1s3xkfM5jSiEIF+CsHMNDLFROA7Eweu3SMe5obz9U5Oefj4h 5cvGRJUBdm6e7U0d5tzbq0e8AROISQy2ijtXiz83tNh4FBN+DyQr5iC8+JVy1gD4Lib9 BDIx6IqyRlxu9MeTnGQ7txJiVcz+ZjP5uCmoRGAG3/f2gdUYl0Y2+vLsGwCUwTefrfLB Q7aEykaVNT6zq7UIcZQCEl42G3CZKMM962APWtcCStM7voJ123uEEKYMdtKJfwvvLBzE UjmA== X-Gm-Message-State: ALQs6tBQtCjXC+CmheHBBEZCgFbFVEXfhrxhH93kzLhhwHOLLKMMENED PF6qH4CONCTuZxhQbGz8f7ZTFuW51Yc= X-Google-Smtp-Source: AB8JxZqShs1ajIAN3gRN4QNqZuPkFKBpypWuhoh2Sb/zbc86vm+c8DSTLEtWFEhI/oRvbNmbS6kx4g== X-Received: by 2002:ac8:2a77:: with SMTP id l52-v6mr20123217qtl.396.1525378336141; Thu, 03 May 2018 13:12:16 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id g67sm11868448qkb.51.2018.05.03.13.12.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 13:12:15 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 3 May 2018 16:12:14 -0400 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> To: TLS WG In-Reply-To: <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> Message-Id: <19A28612-65CA-4667-9E4E-D47717AC9009@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: Thu, 03 May 2018 20:12:19 -0000 > On Apr 21, 2018, at 10:25, Sean Turner wrote: >=20 >=20 >> 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. >=20 > =E2=80=A6 4 May 2018 ... Just a reminder the WGLC ends tomorrow. spt= From nobody Thu May 3 13:16: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 B2BD512EAC0 for ; Thu, 3 May 2018 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRf18rCDBJhv for ; Thu, 3 May 2018 13:16:16 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 75E5612DA11 for ; Thu, 3 May 2018 13:16:16 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id o4-v6so18856551wrm.0 for ; Thu, 03 May 2018 13:16:16 -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=n+PvnZgOQAypPwYDG43BIEpjIta++3tENIELfqGOluo=; b=OTxFQlIdNh74o7Win+unyPGuTcvZLNHYfPZejc1ixIL8bfi3GHQkDT48rVllSdhTwP vG/V7KzKnICm5COZGkFUE2WS+LnDA3G+W4RmPIewJPCi7fqD3SGme1ucvb+BFr1s8r4Y YH65Bmt+JLTPabDxXL4PkW3WmLGxDFOUdOsyRH9nOSuX61tgeHnEz5PAmgBFuG4kUt7n 1+pQFYghzgsciePkpQGYazfhlAr/7cJGIsOe+Dddywi1oXG5gX8/Giacwm/4fgfpWyz7 KGp2QSPeLQC2V5XCci4lzMyHSHS9HQONG7Pv8EY1zEkCLpr4p2hwCsIO8vY1L+xH+0Ui +wgw== 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=n+PvnZgOQAypPwYDG43BIEpjIta++3tENIELfqGOluo=; b=Bk/HHVO/JfSM9593LWtsVL4GeioZperwfxTaDQ9RNZdSuFgrYa+zSN2X9AkltPhsxo /g3BWJVgOeBD9xn6YXY4VGTmr3IjklX0zxokAN+a0pX/q17GE+x/HAwqRhLp3DFATz3w PxC9CNZFuTUJsxGzw84mAUWMAHsrSV1UERNolEZV2XBhaqk65LuyNroxrV/RxjSWs5zG WyRENkBlsAujvLwPGLGFcviok7DytW0/BdQAsIJJoyHOnQ+k/DdpuKNSHJOySZtQubsP rvDMJdWctsuyBXG/DNwWJojyNZXv7Ol9sCaY1FvaNbAcPSH8YAI9qBKOuAJGxqUIhLiI yPRg== X-Gm-Message-State: ALQs6tBdICipt5WZTkhqXrTqQwp2yL4zrY2lMI/lZZV3RvLb1gXHmYXf zPvamqYMopXXfY9leCrj5xWjEHbA+OpYl4WP8F0= X-Google-Smtp-Source: AB8JxZpKbOuLgbiXBVgUzmCQ0q78Mt+ffeKax9Fmc9hDrlm7tqP4b2YhSmfAbN59T8/rgkj3ekUT7ASxIk3TfItH500= X-Received: by 2002:adf:dc0d:: with SMTP id t13-v6mr17398437wri.153.1525378574941; Thu, 03 May 2018 13:16:14 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> From: Nick Sullivan Date: Thu, 03 May 2018 20:16:04 +0000 Message-ID: To: Sean Turner Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000001b827b056b52e096" 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: Thu, 03 May 2018 20:16:19 -0000 --0000000000001b827b056b52e096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does anyone have any comments about the draft, criticisms, or votes of support? Nick On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: > > > > On Apr 21, 2018, at 10:25, Sean Turner wrote: > > > > > >> On Apr 19, 2018, at 16:32, Sean Turner wrote: > >> > >> All, > >> > >> This is the working group last call for the "Exported Authenticators i= n > 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 ... > > Just a reminder the WGLC ends tomorrow. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001b827b056b52e096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does anyone have any comments about the draft, critic= isms, or votes of support?

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turne= r <sean@sn3rd.com> wrote:


> On Apr 21, 2018, at 10:25, Sean Turner <sean@sn3rd.com> wrote:
>
>
>> On Apr 19, 2018, at 16:32, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the working group last call for the "Exported Authent= icators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authen= ticator/.=C2=A0 Please review the document and send your comments to th= e list by 2359 UTC on 4 April 2018.
>
> =E2=80=A6 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

spt
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001b827b056b52e096-- From nobody Thu May 3 17:53: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 B3EA41271FD for ; Thu, 3 May 2018 17:53:41 -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 oRXWLE8kGyBI for ; Thu, 3 May 2018 17:53:40 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0237126DFB for ; Thu, 3 May 2018 17:53:39 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id c70so15459662qkg.0 for ; Thu, 03 May 2018 17:53:39 -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=sQfd1MRILaFlq6dyOArYWc3Apw2r1mRJQcshZGRrooE=; b=BtL9iKIz163l8NckDu2j30fsaiAz3kKeJMoB5oCiL3vZ7up2H4DpZuRfBoTlSoaXH+ 0FnOLW4QTwH26TaDxZR0wm+u/ogo17ygXjzGLZN3p0hvTZ7GRSciQg+HmoAx49SwkK66 Zj/ZnawTTXv/zNbzRF+lWxH9DUAkgZqIoCZuM= 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=sQfd1MRILaFlq6dyOArYWc3Apw2r1mRJQcshZGRrooE=; b=CZhE4qSLqU1QdmGqy3Lj/zqUSs/v+WSg0PUx4XjAbZk7peZXBlRsiV3pFRlKD7qFAN GG3D9r1qCT79lcNrw5QQ8n0iEmOt2O5/fB4FO9NaViy+J+wQ/M7rz5r3lW+fWeG0tTNf 1IXkr1ILt4AZB6qW4vKDzJ/ino2Nk7PDqWFkRfOLBS2LG/YtDD9EcVznLWTKKiGYxK7E 3PtNrvu7JnlvW/WgH8D29vzVQvnBppQMjb3MYmEusGgRbt5OX7qeiS7oghKcG8V32cK6 rVc+AhxB4kSJegLbKt088AQI3xjTnQ1tN1nNbtQJa2hBq0lacK1yqgMz2OclUNBJporc kn6Q== X-Gm-Message-State: ALQs6tDxubb6Muxv5/mMUlEZsFV+YHpD/ZTaeyPwLXswQLrdw33FNDs6 mdDAQeUewK5ReA2QSDQk7cWmhGhUhKE= X-Google-Smtp-Source: AB8JxZrJ15SxmGj5FextDikJFktFYSpbepwjwyPo7MimxQsRCOXYBEGZJXjoyBxGUBnmIcVbWWy57Q== X-Received: by 10.55.13.212 with SMTP id 203mr19209508qkn.1.1525395218883; Thu, 03 May 2018 17:53:38 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id g199sm12318828qke.29.2018.05.03.17.53.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 17:53:38 -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: <4BDEC453-ADA5-4E5B-B2BC-6CCD797A48D1@sn3rd.com> Date: Thu, 3 May 2018 20:53:37 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] TLS@IETF101 Minutes Posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 00:53:42 -0000 The meeting minutes have been posted. If you have any suggestions = please send them in. = https://datatracker.ietf.org/meeting/101/materials/minutes-101-tls-2018031= 91740-00 = https://datatracker.ietf.org/meeting/101/materials/minutes-101-tls-2018032= 10930-00 spt= From nobody Thu May 3 19:24: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 69FBD126DCA for ; Thu, 3 May 2018 19:24: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, 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 4ieIHQgoOAGe for ; Thu, 3 May 2018 19:24:16 -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 E7595124F57 for ; Thu, 3 May 2018 19:24:15 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id g7-v6so22918304otj.11 for ; Thu, 03 May 2018 19:24:15 -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=Y/OCo8/JIv9iUlJ6mSBmN8b/4qvSbFFWKUVnqdLXZS4=; b=JscAcxhenu/xtNM99opEC0bmdom+CSwGtnTwegDSlB7vsGliOdHrl4yNsAiBYlgFFu ldAzh9HFoYBdOutmSanBrsfM5M/j/OPgxCKKcfD3QgrMe7xjEe2eckNgnrP28TsKtDD+ bdQF6gjM/qbJRkvYJJFjmEGot2RrPcCP5ShlHz5uHqM1lwCJrC6kgEKN1NiCqw8gr3dm GbVX9WdldP/aN4c8eDq1Zgy3p/M4EOEx6PgylBsBBjJBUM6ewkuJVkp8aw1jgel10oU/ dDalfLDPaszqD1ft6KiuUDpihKnPAy/Jo7ebE0r87w2zDE3VBbCZCDMBF0pnXHjKwmdw STAg== 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=Y/OCo8/JIv9iUlJ6mSBmN8b/4qvSbFFWKUVnqdLXZS4=; b=AReluDm6SiRioABFt+/g6IFymSNh5Bn02IRcm6eVfV/PxqXG2zQk5EkCWFOUULgiab aGAVMfrPfYP1KuYa0exKqTKlxECWiDYib5UaRMB3dAKvmFD1zLL4KXCm3xRn4E8l0UeB OYwGU22DNwu6eJ3ivtQOR0w4akxC1zTHXbng0JqOCVl1mYPzToY9izUTSfqonFb+sSdq aXVs9OI0GDBBzeP8Zy/EbKVWH8Q0Lk8TeGHz24hDSKrt3aDSn1IMY9CMQGLeAd0WlRkm tHtJK8KUMiBoHAoifz5oILSNrNj8/IelgSJnt5Pa4hpOo0IyEoRZaJVrJ0lAYfMlT6qp I8Mg== X-Gm-Message-State: ALQs6tB883wswxoxGmX2C3UwVOX15U/h/DAN5T9li4SnseZVOVdduGMz JuTVuCy9Ra4UqsiXxO0q/LdWhbPAnRRTZySAzTg= X-Google-Smtp-Source: AB8JxZr7PZfoypkrwVutvMbAq+LuhQerkHP+PpiMO1KrwqJDKJGCAuaZLQl7j/pl/VMT9L/z78rKwiWyqLx8zBfxJe8= X-Received: by 2002:a9d:39e2:: with SMTP id y89-v6mr17345958otb.394.1525400655127; Thu, 03 May 2018 19:24:15 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Martin Thomson Date: Fri, 04 May 2018 02:24:04 +0000 Message-ID: To: Nick Sullivan Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" 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: Fri, 04 May 2018 02:24:17 -0000 I've already provided enough input on this draft, but I sent in a few editorial PRs. Otherwise, this looks fine to go from my perspective. I would like to see some other opinions though, I'm probably too close to this. From nobody Fri May 4 02:01: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 4BE24127871 for ; Fri, 4 May 2018 02:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUlC1guc5zJ6 for ; Fri, 4 May 2018 02:00:59 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60793126CD6 for ; Fri, 4 May 2018 02:00:59 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id j4so2892479wme.1 for ; Fri, 04 May 2018 02:00:59 -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=scajO9oVWaD/o88dntRijUEjgw0uRHKK1NRu8cL95Cc=; b=i2uFE7GyrslbLlyfPIWvwKMe5CflHkXvnPOn58KXk+AZYhtkXszrNINZ4gQ0Dpm+Pi qJnjZapktF5siwaSxjCwJ3XRlqp9CCv3G+tbT/tIEZvlmziEX8qC5ah6dPP4oqqqILs+ a8Yy3ra2nvMI2ziVq37r2UgyUfRsM4PlrEbhMLc/5HQkWd4m+FtGoIXLZFMBjSnq/u7O yHldWQPxiu+Y8RmBOPvE3ah54R4sI3p6SMZgPqWiNFs6Z2LAvWWmt8ZTtNpXSsU6SkX+ GK4LxZFvMwa3GttsgdkpOXqWbW+dPqsgVHB0lYBriHdWzg3YrX8rf6RzPzCbgia8RztG quZw== X-Gm-Message-State: ALQs6tDAqvq4+DzvyrCDmmoUFxbX/SWhM3pslAXH2iljc74VZq/lIiJq 8TQZAzAIqnbgkmsSdITXl6CBIQ6q7nM= X-Google-Smtp-Source: AB8JxZo9ndW5MdfDMGejGkxoMWbPzaf4SveFRROHG5Ei88809JmzmyA3rjhqy2pEyIcmuub9O/ZP7g== X-Received: by 10.28.50.135 with SMTP id y129mr9883164wmy.22.1525424457497; Fri, 04 May 2018 02:00:57 -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 42-v6sm27417500wrx.24.2018.05.04.02.00.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 May 2018 02:00:56 -0700 (PDT) Message-ID: <1525424456.3094.14.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner , TLS WG Date: Fri, 04 May 2018 11:00:56 +0200 In-Reply-To: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.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] 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: Fri, 04 May 2018 09:01:01 -0000 On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote: > All, > > This is the working group last call for the "Exported Authenticators > in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet > f-tls-exported-authenticator/. Please review the document and send > your comments to the list by 2359 UTC on 4 April 2018. I have not checked the mechanism, but I have few questions based on the description in the introduction. "Post-handshake authentication is defined in TLS 1.3, but it has the disadvantage of requiring additional state to be stored in the TLS state machine and it composes poorly with multiplexed connection protocols like HTTP/2. It is also only available for client authentication. This mechanism is intended to be used as part of a replacement for post-handshake authentication in applications." * Was this proposed to be included in TLS 1.3 as post-handshake authentication mechanism instead? * What are the actual problems that post-handshake authentication has with HTTP/2? regards, Nikos From nobody Fri May 4 05:44: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 70C0F126BFD for ; Fri, 4 May 2018 05:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SXMwm4g7Xu_h for ; Fri, 4 May 2018 05:44:28 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (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 934BD126BF0 for ; Fri, 4 May 2018 05:44:28 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-14.bemta-8.messagelabs.com id D6/E0-02128-BA55CEA5; Fri, 04 May 2018 12:44:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTbUwTSRjHO7vddkVqxpbKYwNeXEgUTCueGKt +UaMe5iRy5k5jJeoW17a5vpBuNTVqxEQ/WJAYLQZ73qEeUaxCogHF9xZFoyBEJZcDQUWJxJYE lRgjGrXD4NuXyW+f/3+e/zOTWZ7V7lIbeMnvk7xu0SmokpTtpn89xvAfA5ac2qeZ5tbrrxhzR 3gna37dHkDz2bwLoR51XnX1OyYvGkUFrIVzuK0e/3rOHmk/qS6ucvsruivVJajFFkBjeCUeZO B8//QASuK1uJyBTyU1DP14hODu+34lcalwDvx35RZDOAXnQ92xIEeYxRMh8P9eNoB4XocXwOn QdoIpeCEMXDJS9xI48aSMo1mZ0PXkHSKswYXQeHKQo1HPETweOjBiGoN/g46H9SrCCE+At3dO MzQqFbr6qkYYcAr03mtRUdbDi2cfOeovhL+HmkbrAtQNdI/60+F+VSkiYYDrGahu/qSkghFeV lSwVIggaCyLj+7Ohq59JxDlP2F35C+GnAzwGqgNL6flahaGSsdSToO+oXNq2qdBBQd7z40ka/ EGCIbJRER4huBaYJglgg4boKdjD9qHskPfnS6U8LG4CkH7xU4mNHJP4+H2oT4lNVmg61QlRzk bKmpjo/VpcPxonA0lBmRxFtx8IPxYJjwPKoejKsqTIVjaq6Y8C+LNr9ARNDaMpsqSd7PkNebm mqxeh83uc4kOp3FGjtnkkmRZtElO0SqbijyusyjxCncoFKgRfbixpglN5BlBr5myKm7RjrN6N myxi7J9nXeTU5KbUBrPC6Cx/D5g0Y73SjbJv9HhTDzlLzLwyUKKRiayRi4WXbLDRqU7aA7fXb +/jOWbBoOJtY2sWqXb45YMqZpcsgGTDfZN7q/tvvwc91G6QadBCoVCm1wseV0O3496DKXySNB pCkiXZIfb9zU1lhiISQykG4yTgXziN8lQgn5akJS/wvBLNHJmUqe1lTt+xD27aKq8lvn4c+ev V7kCfYtvV39A55gT0ze8ZcvTzBkZLStzMkwLpWH28JtWX8/Ww1M2xpbPfVCjN17eX7esbad/2 8O0df/k10Sb9Z7MS21ni7Km+bJW7z1aMCs3+DJ9aaSyeHHmwZmF5ZuFC9GyhkWCUraLM7JZry x+BgMrw2sXBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-5.tower-220.messagelabs.com!1525437865!193146783!1 X-Originating-IP: [207.46.163.111] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31827 invoked from network); 4 May 2018 12:44:26 -0000 Received: from mail-sn1nam01lp0111.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (207.46.163.111) by server-5.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 4 May 2018 12:44:26 -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=lM34SFQ3p7U8jhGBOi5kTYkAqyh2TB0aXafxkQrMRws=; b=TTYdIoJwIuXP98cN77rUyOy93ffpFjbxN2TgXsPUiDYHowd8/8DcNWhOB3Z7mzWlgzyF923ERs3v2zXIH/FZ4Q0T8gnaLHU14ICGi/iNHANVj+xNs6NeTrckkA0UgKJZ2+ZrFn3WWVvP72BPRbBJY3hwMd2sGCBBZ86tKvAaBFA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1524.namprd14.prod.outlook.com (10.172.152.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.16; Fri, 4 May 2018 12:44:24 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0735.016; Fri, 4 May 2018 12:44:24 +0000 From: Tim Hollebeek To: Nick Sullivan , Sean Turner CC: TLS WG Thread-Topic: [TLS] WGLC for draft-ietf-tls-exported-authenticator Thread-Index: AQHT2B2mvtcKSY6ZIUiPsbUgpPIwhqQLSOsAgBM85wCAAAESAIABExCw Date: Fri, 4 May 2018 12:44:24 +0000 Message-ID: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1524; 7:m+4E4tfwSHk1JW6r/a19ED2koDAs5KVcpOwPjRew7q2fkDYJP7bB7AMbJeu5CB56OFLdRF2Mm/SlBT1bZMiopumqysDEmMOWwRd7WqMamRDnTANMdjXqR8GvFatoICENFT7CS0vzZOSM5M2IcYStTmFMY8LznUQ1pg525f/iU/6JheacVQlQsLmtbD4TOHo5eBrXNStCda0okylK0HbTPo62EYPM5Yi+82pHlhJfVRyPH4NG5ncAVX8m85VDgI7h x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1524; x-ms-traffictypediagnostic: BN6PR14MB1524: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR14MB1524; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1524; x-forefront-prvs: 06628F7CA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(366004)(376002)(346002)(189003)(199004)(53434003)(5660300001)(86362001)(476003)(446003)(2906002)(14454004)(6436002)(105586002)(2900100001)(229853002)(11346002)(66066001)(106356001)(606006)(44832011)(486006)(97736004)(316002)(3660700001)(68736007)(7696005)(8936002)(74316002)(110136005)(3280700002)(186003)(5250100002)(25786009)(33656002)(99286004)(478600001)(81166006)(7736002)(81156014)(39060400002)(4326008)(99936001)(54896002)(53546011)(93886005)(790700001)(6306002)(3846002)(6506007)(6246003)(236005)(26005)(9686003)(102836004)(6116002)(76176011)(966005)(59450400001)(53936002)(55016002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1524; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cEzkYgCLP2T/NO9AF9q1a4E/qPDia0YOEYXJoBfQv5DW/N4n+nO7MShzYFzI/5I52PPFLJAdShCVpZ3I/Zq6TgZd+MwtsPgtnhUpvzchYcEaKkS0iruNE2hi1Oe8LZhZPRu2vWIn77D0XVE4QzqbMKtFl7oYRw8LhBPNfwNOZ6fYKIgLQVoG418LMe+eYhOL 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_0047_01D3E384.184A0A10" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5fd6f591-aed3-469c-33f2-08d5b1bcc40d X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fd6f591-aed3-469c-33f2-08d5b1bcc40d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2018 12:44:24.2398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1524 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: Fri, 04 May 2018 12:44:31 -0000 ------=_NextPart_000_0047_01D3E384.184A0A10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0048_01D3E384.184A0A10" ------=_NextPart_001_0048_01D3E384.184A0A10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I generally really like it. =20 My only comment is about the use of a zero byte as a separator in a = string (4.2.2). =20 There are commonly used languages where this is likely to lead to = implementation bugs, causing the signature to be computed over a shorter = length than expected. =20 While I doubt this causes any problems other than failures and debugging = pain, the first 64 bytes contain the octet 32; I don=E2=80=99t see any = reason why byte 87 can=E2=80=99t also be octet 32. =20 -Tim =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nick Sullivan Sent: Thursday, May 3, 2018 4:16 PM To: Sean Turner Cc: TLS WG Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator =20 Does anyone have any comments about the draft, criticisms, or votes of = support? =20 Nick On Thu, May 3, 2018 at 1:12 PM Sean Turner > wrote: > On Apr 21, 2018, at 10:25, Sean Turner > wrote: >=20 >=20 >> 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. >=20 > =E2=80=A6 4 May 2018 ... Just a reminder the WGLC ends tomorrow. spt _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_001_0048_01D3E384.184A0A10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I = generally really like it.

 

My only = comment is about the use of a zero byte as a separator in a string = (4.2.2).

 

There are commonly used languages where this is likely = to lead to implementation bugs, causing the signature to be computed = over a shorter length than expected.

 

While I = doubt this causes any problems other than failures and debugging pain, = the first 64 bytes contain the octet 32; I don=E2=80=99t see any reason = why byte 87 can=E2=80=99t also be octet 32.

 

-Tim

 

From: TLS = [mailto:tls-bounces@ietf.org] On Behalf Of Nick = Sullivan
Sent: Thursday, May 3, 2018 4:16 PM
To: = Sean Turner <sean@sn3rd.com>
Cc: TLS WG = <tls@ietf.org>
Subject: Re: [TLS] WGLC for = draft-ietf-tls-exported-authenticator

 

Does anyone have any comments about the draft, = criticisms, or votes of support?

 

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner <sean@sn3rd.com> = wrote:



> On Apr 21, 2018, at 10:25, Sean Turner = <sean@sn3rd.com> wrote:
>
> =
>> On Apr 19, 2018, at 16:32, Sean Turner <sean@sn3rd.com> = wrote:
>>
>> 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-exporte= d-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 ...

Just a reminder the WGLC ends = tomorrow.

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

------=_NextPart_001_0048_01D3E384.184A0A10-- ------=_NextPart_000_0047_01D3E384.184A0A10 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 CQUxDxcNMTgwNTA0MTI0NDIwWjAvBgkqhkiG9w0BCQQxIgQgeMsvui60SJHkyY0YjTA2mUicPSMz L0BKGd1CU4GDx7EwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALwzOY/7psaSVZ1h9z60IPTxzFHgc7HpJHVIztlN7XLYfgdLyZkW8hmuvKtBSU5T7QUGqtN3 7PISjBP8QcJ2TGkekCFjupV05rh/USbetqCuXsRhuJrIUEzKXvKe0CrgAtGeYa+Y7/C/g4LWzXOQ eJ3T+R/EhQ7W9QrPSzGr/GzXLs30InNoVtTE4GtRuxhLT9i+wfSGaHHq0EH8IhmMpRvJAfv7IfaD LwdcPVGQ1401peyXG53GnnhaDR3fHPOE13cWE+JViQNG8It5DQ1MHwGZ9TyeGkddn4mTGvftpMJt R91fhULiQvu7ydPimJgy7vjmXB+ogvN+SMuxxMAP4agAAAAAAAA= ------=_NextPart_000_0047_01D3E384.184A0A10-- From nobody Fri May 4 06:16: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 CF456124E15 for ; Fri, 4 May 2018 06:16:11 -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 QphZxMAh95ql for ; Fri, 4 May 2018 06:16:09 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E54E120724 for ; Fri, 4 May 2018 06:16:09 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id f3so13999095uan.9 for ; Fri, 04 May 2018 06:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72NFZMwJ2ncgAedfHPmmvFvZzmxHMSSdejtr9h4PfNI=; b=vaWlOhLSx/RVY8fBdgXJOCTmuj0dJTEbY0Oj+AowDi/vTNuaWAg/zUxxlgpB6uf6X3 q+A9CyGRdXtQ5LfhWtA7LwFww3YrPBqaLpYtdj5oC/VyZuNXKtfSMUXrirj5aOu1P+bU BCweMaMYmForvKqW8zVUzXCjkZSUCIYQCdo36F+Ql8Z3jEobfbvtidOIbwqiQspZQ1fZ hlzrwz9DRHnwEWBO7Xp/hJmGd8a/ibAOldEZqlrn2E+N6WDbNmBMvaIxJ7dptfZ8BOoN N3oBjCWFdQt1vgrw7PIu2AeWlFah8fI3XDR+og23htgUB0mTE73vKUX72P1BDK672fHZ Q0sg== 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=72NFZMwJ2ncgAedfHPmmvFvZzmxHMSSdejtr9h4PfNI=; b=a+AIK0ySmadSUf70TnDutybXV8DNPZeoTqLzvH+4mnVpJJos5qIW+8YYzUwrB6Ewkd O8C2Myf2To3+KPHx+JuOzpSq0LhnQU3E9REHdjGhqgAdKp8ijB7yFradF4Xv7kngXYcR s40njEj01F3zrAMAh8GQ6WhAMKG6T0TFTb3qi/E6MaEHR41S4lPYBRx5JfojweRRXCSf hq1FXHrUyI2HzbZI7sqLdAqy1leuwR2yvrdsh5xMI0ASVZ/kC4s94+8Y0/90hOb1VTYe 7XjM2YuZH2BtcTYpzFT7N5uFESAOHhvqrSFlhUk52oCqru1HI1lEO9F8DLAo6IkZDInB JNzA== X-Gm-Message-State: ALQs6tB4V9mtuGWNUtYZ4AJNfmZl48ku8KQuTzJ5RHEWpPvKQnvgLED/ GuLFIqNR/Im2bbWRkZ9RP/NnGQG85lTcZ2uRNfA= X-Google-Smtp-Source: AB8JxZrz5XlqjKqHaz5prBk15RJqn072iO19ui6sOJtjJVKFC9vwPF4CqprKV3k1gG/FGehh7qB01lO14NZfA0pMUo4= X-Received: by 10.159.49.199 with SMTP id w7mr24918951uad.176.1525439768303; Fri, 04 May 2018 06:16:08 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1525424456.3094.14.camel@redhat.com> In-Reply-To: <1525424456.3094.14.camel@redhat.com> From: Jonathan Hoyland Date: Fri, 04 May 2018 13:15:57 +0000 Message-ID: To: Nikos Mavrogiannopoulos Cc: Sean Turner , TLS WG Content-Type: multipart/alternative; boundary="001a1144fb12841c7e056b611f6f" 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: Fri, 04 May 2018 13:16:12 -0000 --001a1144fb12841c7e056b611f6f Content-Type: text/plain; charset="UTF-8" Hi Nikos, The problems post-handshake authentication has with HTTP/2 are described in draft-ietf-httpbis-http2-secondary-certs-00 a.k.a. draft-Bishop. See Section 1.2.3 in particular. In brief, the problem is that requests and responses are multiplexed in HTTP/2, and threfore there is not a tight coupling between TLS frames and HTTP/2 streams. With post-handshake authentication, the authentication happens in band, and so the HTTP/2 layer doesn't have visibility into whether or not specific data was sent before or after the authentication. Regards, Jonathan On Fri, 4 May 2018 at 10:01 Nikos Mavrogiannopoulos wrote: > On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote: > > All, > > > > This is the working group last call for the "Exported Authenticators > > in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet > > f-tls-exported-authenticator/. Please review the document and send > > your comments to the list by 2359 UTC on 4 April 2018. > > I have not checked the mechanism, but I have few questions based on the > description in the introduction. > "Post-handshake authentication is defined in TLS 1.3, but it has the > disadvantage of requiring additional state to be stored in the TLS > state machine and it composes poorly with multiplexed connection > protocols like HTTP/2. It is also only available for client > authentication. This mechanism is intended to be used as part of a > replacement for post-handshake authentication in applications." > > * Was this proposed to be included in TLS 1.3 as post-handshake > authentication mechanism instead? > > * What are the actual problems that post-handshake authentication has > with HTTP/2? > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1144fb12841c7e056b611f6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nikos,

The problems post-handshake a= uthentication has with HTTP/2 are described in=C2=A0draft-ietf-httpbis-http2-sec= ondary-certs-00=C2=A0a.k= .a. draft-Bishop. See Section 1.2.3 in particular.

In brief, the problem is that requests and responses are multiplexed in HT= TP/2, and threfore there is not a tight coupling between TLS frames and HTT= P/2 streams.

With post-handshake authentication, t= he authentication happens in band, and so the HTTP/2 layer doesn't have= visibility into whether or not specific data was sent before or after the = authentication.

Regards,

= Jonathan

On Fri, = 4 May 2018 at 10:01 Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote:
> All,
>
> This is the working group last call for the "Exported Authenticat= ors
> in TLS" draft available at https://datatracker.i= etf.org/doc/draft-iet
> f-tls-exported-authenticator/.=C2=A0 Please review the document and se= nd
> your comments to the list by 2359 UTC on 4 April 2018.

I have not checked the mechanism, but I have few questions based on the
description in the introduction.
=C2=A0 =C2=A0"Post-handshake authentication is defined in TLS 1.3, but= it has the
=C2=A0 =C2=A0disadvantage of requiring additional state to be stored in the= TLS
=C2=A0 =C2=A0state machine and it composes poorly with multiplexed connecti= on
=C2=A0 =C2=A0protocols like HTTP/2.=C2=A0 It is also only available for cli= ent
=C2=A0 =C2=A0authentication.=C2=A0 This mechanism is intended to be used as= part of a
=C2=A0 =C2=A0replacement for post-handshake authentication in applications.= "

* Was this proposed to be included in TLS 1.3 as post-handshake
authentication mechanism instead?

* What are the actual problems that post-handshake authentication has
with HTTP/2?

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1144fb12841c7e056b611f6f-- From nobody Fri May 4 08:21: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 1997612D86D for ; Fri, 4 May 2018 08:21:12 -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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqjBeS2R2gXP for ; Fri, 4 May 2018 08:21:10 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D1F12D779 for ; Fri, 4 May 2018 08:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525447266; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; l=912; bh=L3whNgOfvNe1rO6heifOacKqGBhIgm/q3pEIDm1s6Tw=; b=DQiORG6KISKbGupKtuV5qjnPhyXTZth2FRmW1TJEMkv5Oa6MWjmJ+pzUuvCthgOZ rZreYsxTVPy3M3DpMI1SsxpK8KM/9+q9btxoeOjAFsmDRdhLpYraxFrIH+ohXUWPosO Yei4nwKmaoR930p6EJ/i08YsfvfK3QVuAtr+jab0= Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525447265985604.3622528056787; Fri, 4 May 2018 08:21:05 -0700 (PDT) From: Roelof duToit Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 May 2018 11:20:55 -0400 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> To: TLS WG In-Reply-To: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> Message-Id: <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Fri, 04 May 2018 15:21:12 -0000 How will this (and any mechanism built on top of RFC 5705 exported key = material) interoperate with middleboxes? This use of the mechanism is = not negotiated on the TLS level, so there is no extension for the = middlebox to strip that would warn the endpoints not to use exported = authenticators. Are application level proxies the only compatible = middleboxes? =E2=80=94Roelof > On Apr 19, 2018, at 4:32 PM, 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. >=20 > Thanks - J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 4 12:54: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 B2EB41200C1 for ; Fri, 4 May 2018 12:54:10 -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 SMGv1D1zp8QW for ; Fri, 4 May 2018 12:54:07 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DBE12D7ED for ; Fri, 4 May 2018 12:54:07 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f5-v6so15586039qth.2 for ; Fri, 04 May 2018 12:54:07 -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=3x6A0X3/q6TQZmBsEsyW2fNFcQASb56+jpXps3uR6tc=; b=Z42uoCYykT4difST4B1GV8EJsXlUt2xPLUUghUgKlK8QZ6/WkZuWQKM3RXFRn3amBD R1dUxbM7O/HGu84/44CLGv0Q8J4AhxrKkE6dhDfMicTCdVSHfIDcUepOxDyhWW4rEOb2 pzM2IYoJAlayBRUukMqt3SHjox6tvywQdXWHc= 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=3x6A0X3/q6TQZmBsEsyW2fNFcQASb56+jpXps3uR6tc=; b=KwlKo3HFj2rfaA1k/nr/Hw5aQ3zBbxgA2iwX+QxYI+k7k+zKGZR94ZgULFtfCRQxhN JMlY0mYiy6TfogddB5Z3hQR6XwQ3VHbf3roHy1uvtf0YUh0vC/RcSq/yXYcKIPbPds/N K4lZBtjlZH89i2KLfz/qkCkhtFmIqsgYJkM6hTh1peWEW0ozSfDzqVvtR59laqj81qPx p4qFZat9aMTjdASaD7p/9mHYJBp3YtcpygeeM6X1UTrGtGEVNZPclcOD+zIdX4Vj1jaJ e+k6M/yx8c34PI74aAL9wdZ+nArjE6viBdMo60lsWLOKmxlPwDcvwZk4kjCXSoBye73Z /lww== X-Gm-Message-State: ALQs6tCWwIX/sy1vU4fcpWutItTo8R+39XfVOTQqLEFL6m4jo9iDuUcl Ikpx+VVe+OIpCYWevi0JCRykxuqvE6k= X-Google-Smtp-Source: AB8JxZosLYA9c8nWgnBGNJ4BJ1LGC7df9mAV8oz1BwLMBcsk/LlpmkXeLUMJ97pK33K+PgB1Tj6CBA== X-Received: by 2002:aed:2a31:: with SMTP id c46-v6mr25497904qtd.238.1525463645836; Fri, 04 May 2018 12:54:05 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id t47-v6sm15355380qtc.1.2018.05.04.12.54.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 12:54:05 -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: <079B8933-C079-4929-AB2C-93DBC5E8B8EA@sn3rd.com> Date: Fri, 4 May 2018 15:54:03 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] Reserve or close HashAlgorithm and SignatureAlgorithm registries? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 May 2018 19:54:11 -0000 The open issue in draft-ietf-tls-iana-registry-updates is whether we = should close the registries or simply reserve the remaining values. = I=E2=80=99ve submitted the following PR to simply reserve the values and = point to the SignatureScheme registry for 1.3 values: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/75 I did this because a) closing a registry is really just symbolic; a = draft (or the IESG) can later reopen the registry, and b) At least = person has indicated they might want code points for a TLS1.2 = implementation. Regardless of what we do we should point to the = SignatureScheme registry for 1.3, but I just don=E2=80=99t really see = the point in =E2=80=9Cclosing=E2=80=9D the registry. If this PR makes = you really sad please let us know. Please note that the gh editor=E2=80=99s copy also includes the = IESG-related changes. I=E2=80=99d characterize most of them as good = catches (e.g., cached_info was missing) and consistency (e.g., some of = the DE language was not consistent). I=E2=80=99d also like to point out that IANA specifically asked about = the DE doing such a minimal review and we let them know that yes in some = cases it was going to be just that. But, this also made us consider = adding the text that was in the security considerations and elsewhere to = every DE-related note. It is clearer now what the DE will do in the = notes in case people don=E2=80=99t want to take the time to review this = draft, which is actually what I think happens in most cases. spt= From nobody Fri May 4 13:24: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 CB1A312D947 for ; Fri, 4 May 2018 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EzjCEspiB9lC for ; Fri, 4 May 2018 13:24:32 -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 883941200C1 for ; Fri, 4 May 2018 13:24:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A8D3300A3A for ; Fri, 4 May 2018 16:24:30 -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 0FqSGyZ_iWZv for ; Fri, 4 May 2018 16:24:29 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 21C96300434; Fri, 4 May 2018 16:24:29 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <079B8933-C079-4929-AB2C-93DBC5E8B8EA@sn3rd.com> Date: Fri, 4 May 2018 16:24:29 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <25C01745-249F-40C9-89D4-A78D05A0BE4A@vigilsec.com> References: <079B8933-C079-4929-AB2C-93DBC5E8B8EA@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Reserve or close HashAlgorithm and SignatureAlgorithm registries? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 May 2018 20:24:35 -0000 I think that reserving them is the right thing for now. TLS 1.2 and = earlier will take a while to disappear, so the ability to assign more = values if there is a huge surprise seems prudent. Russ > On May 4, 2018, at 3:54 PM, Sean Turner wrote: >=20 > The open issue in draft-ietf-tls-iana-registry-updates is whether we = should close the registries or simply reserve the remaining values. = I=E2=80=99ve submitted the following PR to simply reserve the values and = point to the SignatureScheme registry for 1.3 values: > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/75 > I did this because a) closing a registry is really just symbolic; a = draft (or the IESG) can later reopen the registry, and b) At least = person has indicated they might want code points for a TLS1.2 = implementation. Regardless of what we do we should point to the = SignatureScheme registry for 1.3, but I just don=E2=80=99t really see = the point in =E2=80=9Cclosing=E2=80=9D the registry. If this PR makes = you really sad please let us know. >=20 > Please note that the gh editor=E2=80=99s copy also includes the = IESG-related changes. I=E2=80=99d characterize most of them as good = catches (e.g., cached_info was missing) and consistency (e.g., some of = the DE language was not consistent). >=20 > I=E2=80=99d also like to point out that IANA specifically asked about = the DE doing such a minimal review and we let them know that yes in some = cases it was going to be just that. But, this also made us consider = adding the text that was in the security considerations and elsewhere to = every DE-related note. It is clearer now what the DE will do in the = notes in case people don=E2=80=99t want to take the time to review this = draft, which is actually what I think happens in most cases. >=20 > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 4 13:57: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 43C3512D969 for ; Fri, 4 May 2018 13:56:57 -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 VaIeBD5dTDtv for ; Fri, 4 May 2018 13:56:55 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB46D12D967 for ; Fri, 4 May 2018 13:56:55 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id p64-v6so8124115ybc.13 for ; Fri, 04 May 2018 13:56:55 -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=HdBLpadnfaunALMcOyshjsnKnfyEKecxcGsuDYKJtP8=; b=sNY1TNtXHnFVjdckaf7k7i8KKV/GuFVmiVbyBixw5BFuHXCtRryjNoqlRZXyBeBcCW 5rVagVn3G76Eya9MCr9oXtb4iqIJDur90jw55PSq/Rnc7+TlKUywehvJKTQqs4vGTWYg ZGR6Z5E7m2OM3UCx1KaF/Aj/lDQa/V5WJcZquxeP+cKX/wMRYlKX04wB9YlolzhlNPMB G6GoWZcBRUKekwvdi9NlaoyvB1+RX63mbIh7Q243tkiSJwCphcI3RVL35M/mWEY79XsD 0qIYzitX8xuFvoBYbd1dh18wdz4dVouSOQSFRIgyO1cYEfVMEezo7KcdHFgFNsRk/FTB e6Jw== 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=HdBLpadnfaunALMcOyshjsnKnfyEKecxcGsuDYKJtP8=; b=scRGX/8VsHG6C55BO2k046xeXd3cidxYntUejZrCwgLISfypBbp/34/2kaUOyJHf1Y ggQEDjub730C0vl5hs20J+0plmM4Yv48CLqMmQWKVC2VOgF0d63BV52Hdyy5KVVW5b9U o79vsH/u9O+oX0Npk+lo0+pv69HFZdUJIGZ/wrvFgk0jbseHXk2CcjA17UnQksWetM5E xiSirJhJxRKD3eAXuonZ0Pfkhh1VO/xWv/jQEuAZe8IGXvZ0ohRvjQC3XLT8J24SrqYw oikHhwvRE1wwta8z08S903scGyovMGMTgCPSofG8LX/j1U32gV1OKBUj9BO9OgZaFQ23 gMcg== X-Gm-Message-State: ALQs6tCITQdI1USh+4RQJSk3gMdxddK0Uspx8unSsKwgj3Nt3Q8Fhh5r Gp1UOSjelLVu0W+W1xhdHyzdVn0P70xWrfeKdko= X-Google-Smtp-Source: AB8JxZpVakWT+kzJCAK/LsNkHTUjcwSS58FQQ9SAAGLL8UDnjhfhUyxUL+c8ojwc8jAWJQg39FJdFFkZE5r9i3bVtHk= X-Received: by 2002:a25:3d46:: with SMTP id k67-v6mr8828969yba.321.1525467414535; Fri, 04 May 2018 13:56:54 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Christopher Wood Date: Fri, 04 May 2018 20:56:43 +0000 Message-ID: To: Martin Thomson Cc: nicholas.sullivan@gmail.com, "" Content-Type: text/plain; charset="UTF-8" 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: Fri, 04 May 2018 20:56:57 -0000 I sent in one editorial PR as well. Pending the suggested change, I think the document is ready to go. Best, Chris On Thu, May 3, 2018 at 7:24 PM Martin Thomson wrote: > I've already provided enough input on this draft, but I sent in a few > editorial PRs. > Otherwise, this looks fine to go from my perspective. I would like to see > some other opinions though, I'm probably too close to this. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 4 14:37: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 44B8012DA13 for ; Fri, 4 May 2018 14:37:27 -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 L5f6bPfmreaQ for ; Fri, 4 May 2018 14:37:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA7B12DA12 for ; Fri, 4 May 2018 14:37:25 -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 w44LRlxo007321; Fri, 4 May 2018 22:37:24 +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=Akvj6dMqg7N+zfOkUU3p9ANBbu+GWBkjr9928xcPOvQ=; b=mQd/6Z042ewHO+LZiNRUqQum5C1iG4HSk01MvYH5aNklSle4FBwvFhx/zd1hRsBEPSrv OnWhVWFKyNvQyjP7SIrYuagcVZpsUXpAmStZrgImz9MOdiQivia0AT+y+xBLvcBa2rOi saDPgVMPM8ecjd6AgEcBX1FoThVJhD/lKUJGvDVYrY3jD7MJ3/vYRpmBLg7PvgQgysPY Fr00xWDTuxxNpXcf2Etw8bupAKc3wwm7PG6ys16xXLMRU/rXsqvLq5SlTR5dYmQUu4WQ pc+KWlu9uk3O9F9sbC9b+ip02rv/cqxtMQYdmP+OnrL0wRZw+BE4Mp6MeBhT5OUDAWGM BQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2hqyfpcbmp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 May 2018 22:37:24 +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 w44LQWOj007478; Fri, 4 May 2018 17:37:23 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hmm9ws6cb-1; Fri, 04 May 2018 17:37:23 -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 8402982A0C; Fri, 4 May 2018 21:37:23 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fEiOI-0002p0-Pk; Fri, 04 May 2018 16:37:22 -0500 Date: Fri, 4 May 2018 16:37:22 -0500 From: Benjamin Kaduk To: Sean Turner Cc: TLS WG Message-ID: <20180504213722.GR5742@akamai.com> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-04_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-1805040194 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805040194 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: Fri, 04 May 2018 21:37:27 -0000 On Thu, Apr 19, 2018 at 04:32:55PM -0400, Sean Turner wrote: > 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. Are we using values in the same certificate_request_context space as those that in-TLS post-handshake authentication would use? If so, we should probably have some text in Section 3 (and maybe more explanation in Section 5.2 as well?) about the application coordinating with the TLS stack to avoid conflicts (since just from a data structure point of view the application could send a CertficiateRequest without checking with the TLS stack). We may also need the TLS stack to accound for context values chosen arbitrarily for spontaneous authentications. The API considerations might also be more clear that there are different spaces for the context values for server auth and client auth. Section 4.1 talks of the length of the exporter value in terms of the length of the TLS PRF hash, adding that cipher suites not using TLS PRF have to define a hash function. But TLS 1.3 ciphersuites do not use the TLS PRF and we say nothing about them... It doesn't look like we adapted to the addition of the signature_algorithms_cert extension in TLS 1.3. -Ben (with no hats) From nobody Fri May 4 14:48: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 20B6112DA0C for ; Fri, 4 May 2018 14:48:39 -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 7trtUpNI_enJ for ; Fri, 4 May 2018 14:48:37 -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 BA54212D80E for ; Fri, 4 May 2018 14:48:37 -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 w44Lkif0011766; Fri, 4 May 2018 22:48:37 +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=eSEjJ1mtJV3QHTu8Kz54L4JHilB3zf8v6yAkjvLlvto=; b=NJi7BAMhU5TGid4ldgcN8UaVW5xRyokd2UV1+ZjgU54VwDp2VJUMtgXljREg5NhzCMSH hp3UyluNL8EssjQiRFJjHY6tbb0pLbnSVsrw2909gwM6iHICq9eJLwRt7dq+rsWANMWG gt/Ucsj8gEPpvBNnETuZZllvUdbncynIyRRKhw6YMhqfVNoVtLE3dYJVsDApYEzJ/kvt LWgemBzZ63RvH4AHlEtE6bBtMb8P4wPQFUY/hjED/i9wp+MHkseMJ24lFjZvokS/E8b2 MdYQs3WPtc69jQ4MjPO1saWtgMXy1hIyjDKcXCd6V+nE1uMs6Zr7qzKHkRG+AlZpsC7V mQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2hqemvf5ef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 May 2018 22:48: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 w44Lk2uZ022700; Fri, 4 May 2018 17:48:36 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hmm9vc9u5-1; Fri, 04 May 2018 17:48:35 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id CB1B11FC77; Fri, 4 May 2018 21:48:35 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fEiZ9-0002we-76; Fri, 04 May 2018 16:48:35 -0500 Date: Fri, 4 May 2018 16:48:35 -0500 From: Benjamin Kaduk To: Roelof duToit Cc: TLS WG Message-ID: <20180504214834.GS5742@akamai.com> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-04_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=290 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805040196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=284 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805040196 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: Fri, 04 May 2018 21:48:39 -0000 On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: > How will this (and any mechanism built on top of RFC 5705 exported key material) interoperate with middleboxes? This use of the mechanism is not negotiated on the TLS level, so there is no extension for the middlebox to strip that would warn the endpoints not to use exported authenticators. Are application level proxies the only compatible middleboxes? I'm not sure I properly understand the question, in particular what kind of middlebox you're considering. Note that application protocols will need to have some way to negotiate the use of this functionality, which presumably a middlebox could also inspect. -Ben From nobody Mon May 7 01:58: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 6B77E126CE8 for ; Mon, 7 May 2018 01:58:14 -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 FG6uKuFE-Dek for ; Mon, 7 May 2018 01:58: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 D689B126B6D for ; Mon, 7 May 2018 01:58:12 -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 EC61B8DC48; Mon, 7 May 2018 08:58:11 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-31.brq.redhat.com [10.40.200.31]) by smtp.corp.redhat.com (Postfix) with ESMTP id 495E810848F; Mon, 7 May 2018 08:58:10 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 07 May 2018 10:58:10 +0200 Message-ID: <1615071.jqzUaHJvPy@pintsize.usersys.redhat.com> In-Reply-To: <079B8933-C079-4929-AB2C-93DBC5E8B8EA@sn3rd.com> References: <079B8933-C079-4929-AB2C-93DBC5E8B8EA@sn3rd.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2175947.LvMkQIRgIm"; 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.2]); Mon, 07 May 2018 08:58:11 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 07 May 2018 08:58:11 +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] Reserve or close HashAlgorithm and SignatureAlgorithm registries? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 May 2018 08:58:14 -0000 --nextPart2175947.LvMkQIRgIm Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 4 May 2018 21:54:03 CEST Sean Turner wrote: > The open issue in draft-ietf-tls-iana-registry-updates is whether we shou= ld > close the registries or simply reserve the remaining values. I=E2=80=99ve > submitted the following PR to simply reserve the values and point to the > SignatureScheme registry for 1.3 values: > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/75 I d= id > this because a) closing a registry is really just symbolic; a draft (or t= he > IESG) can later reopen the registry, and=20 every IETF protocol is just symbolic, there is no IETF police ;) > b) At least person has indicated > they might want code points for a TLS1.2 implementation.=20 then they can ask for SignatureScheme codepoints that follow the TLS 1.2 us= age=20 patterns, but even in TLS 1.2 you couldn't ask for ecdsa+md5, so the separa= te=20 registries weren't a reflection of reality anyway either way, I don't feel strongly about it, it's mostly a semantic differen= ce =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 --nextPart2175947.LvMkQIRgIm 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+dkqjRuAHS9fUFAlrwFSIACgkQkqjRuAHS 9fWpaw/9G0USkshsInaOPADp1MR+qDF0qN8WWpwXfWtBZRurVUC7r7RLEJtCd/T8 Lv4gsqpLgjXZOjqr10hM0oXnpv6xH0FzbAMn0Z/KzAg1HxrxK6ZnO98H4Zv4NPNq A4KdAT3Mu8FL2GDdRE+sFHcM9Nd1zOLDanbZxgwpMi/mQz1/61IK+ul2uH9W3Db5 HuPqjJOE3z8uiIjOHiBxlxuFL9+EQVbKOnmx9nIoTRsHt3O9Z6qJ5bMkldYKSZBz yIeAz46Kl2CUCtpU5wYPgHVhHpTDm/T6NUdlHJTNJ3Z/hLxJjLHST51+E6kvtasO h9Y9JJ1nWpCfHGphSx/j8bLD1uFyK+eqxcVIRf3wzuhPak0K27IlmlwPCYRCtT8K 21oc7bIZnRK8nFkUy8Ub0F9a5mFYAOj6CLOA6x6deVLgcODIZyL1MqbtaE/9wd3J 0DnNcH4rvOmMH6hrdmlax8DgeGQ3dxa1g6w6Qy4MCFLcvX5SovIXyrXW9sqhOscb 6Pz3YxZYwaH88bKfAGvkPb7ETcOne0JsWkUMSy2uuKO5vC2uS7kNpRmFUvBkL5no nLRUeX96cQ8938kc3N+jTKxSsq4I3pCczRcvr8ui8oPTbF0QfWTPNq8IwugAWlXT w8COOdgQC4t+loU7NcTFj5OGEWl06OsSY8MgcosPTDsi+ppEzR0= =pjt7 -----END PGP SIGNATURE----- --nextPart2175947.LvMkQIRgIm-- From nobody Mon May 7 08:06: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 65BFF126CB6 for ; Mon, 7 May 2018 08:06: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, 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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5hFhu4bY9Qx for ; Mon, 7 May 2018 08:06:21 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0945126CC4 for ; Mon, 7 May 2018 08:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525705574; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1431; bh=twBJrM8EBb8NtG8+vlK1GZfFBjwfPJBEeXeemdJCf5A=; b=ijx/9jn9KpNWmECWDAZK+5/7Y3lE7NkOOGCbYc7JJCxkpVoi88p3qN56x1EiGFIj kCxq13p9M45kb2oTpgIHBnuTdkezkMpwOanEtJ+Sd6ZHDF/1tqOgqCU1pByzKHNVmQa Jgv7UZXf6jDWRBX646KU0CrjDl3KLdUp2sV1Fb9I= Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525705574518923.7374743472676; Mon, 7 May 2018 08:06:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Roelof duToit In-Reply-To: <20180504214834.GS5742@akamai.com> Date: Mon, 7 May 2018 11:06:10 -0400 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Mon, 07 May 2018 15:06:23 -0000 > On May 4, 2018, at 5:48 PM, Benjamin Kaduk wrote: >=20 > On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: >> How will this (and any mechanism built on top of RFC 5705 exported = key material) interoperate with middleboxes? This use of the mechanism = is not negotiated on the TLS level, so there is no extension for the = middlebox to strip that would warn the endpoints not to use exported = authenticators. Are application level proxies the only compatible = middleboxes? >=20 > I'm not sure I properly understand the question, in particular what = kind of > middlebox you're considering. Note that application protocols will = need to > have some way to negotiate the use of this functionality, which = presumably a > middlebox could also inspect. That is the problem.. some middleboxes are protocol agnostic and are = used to strip the TLS layer before feeding the rest of the security = stack - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs = =E2=80=9CApplication Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport= Layer Passive Intercept=E2=80=9D for the moment). Some middleboxes = might also perform transport layer active intercept in combination with = passive application detection, i.e. L7 analysis vs L7 termination. In summary: the endpoints cannot assume that exported key material is = identical in a middlebox environment. From nobody Mon May 7 09:07: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 1A50F126DFF for ; Mon, 7 May 2018 09:07: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, 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 NJUA8hc-HN1J for ; Mon, 7 May 2018 09:06:54 -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 4127F126D3F for ; Mon, 7 May 2018 09:06:54 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id g7-v6so32565164otj.11 for ; Mon, 07 May 2018 09:06:54 -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=WOXrZCq0DYC+uAF5tFJ+MhfcAGtoxqaCgyM3iM/FpVk=; b=PsEBTQTjCakkl3rAgBe1lLwLtLCefg6V23ZKEtD1c54Nf65Rpr5xFyFLLAlO12n9zi 7+ttjIgPor7VQNwZK+WGggotMaBZcsfH+dLrQkM4GECV63P/mFitWdU40Dk3EpKwvpt2 G/u0JA6V8HDg6o0FqBx57whT+JzRn1sinzRnfBlmb6EawXlWS4ivzOC9h/HlZjZDyBlu /VaeKksMKbHInG2w2yfenfJKg6djkLbIWX/ONCMVel9C3giIG1yWCfsZfRwRO0L69mXa Elvj+dCc1JdDhJEcLol8Qh0HdNTb/TTEBfc+nYLvLVohrimAEX0AfKZdsjG5bUz/Btx3 WGKA== 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=WOXrZCq0DYC+uAF5tFJ+MhfcAGtoxqaCgyM3iM/FpVk=; b=LezCDZt9QrIYPgGuNJWbRlS0ah50brO4yH2RK1pYn1OX+/+ZrMkFDjE47idux85TZj qT0tQjIthJIQNqr0Xs1TVUfLVsIqpZ6RaY7LW0imgz7pii9XfpaS31KvGq+eI7XqKojS 5OmKqNfL/GYWDVF8EDVKKMYDE3zGk08XZonx3eqq61Sgnm4jsy1c8oQeZYdMjELW3752 UGUiBQLqCvV6Ookqy7gjpMi4IUhHF3MJLgyLnqDObm0vbXKstIesmLoxCfAeUFEnsKPT 8uZ4PvZMEedrdmUZnotG+s084FPwlfVVK+ARU6ZS5bRUWh5Vem372ocwTk4A4jLbj/oS Kv9w== X-Gm-Message-State: ALQs6tCo5gHVExnFAOe7yllJEJ32d5ChRtutpAgy8GWajlCffihJnYPz aYOKmepKMJEghhCF4KixIQdRX8PaZO2dLlARy443RQ== X-Google-Smtp-Source: AB8JxZpQ2d3NOZZevatc85HTsYkUuS9IrPzYJ1bhoAqIi+u+FsTmz0HuSxyRd3/Io2PzTSLOOMO1zxwcwkgs6GcRepg= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr13781895otk.392.1525709213611; Mon, 07 May 2018 09:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Mon, 7 May 2018 09:06:13 -0700 (PDT) In-Reply-To: <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> From: Eric Rescorla Date: Mon, 7 May 2018 09:06:13 -0700 Message-ID: To: Roelof duToit Cc: Benjamin Kaduk , TLS WG Content-Type: multipart/alternative; boundary="000000000000b54b47056b9fdbdc" 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: Mon, 07 May 2018 16:07:01 -0000 --000000000000b54b47056b9fdbdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note that this is different from Token Binding because that's negotiated by an extension, so per S 9.3, non-supporting middleboxes need to strip out the extension -Ekr On Mon, May 7, 2018 at 8:06 AM, Roelof duToit wrote: > > > On May 4, 2018, at 5:48 PM, Benjamin Kaduk wrote: > > > > On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: > >> How will this (and any mechanism built on top of RFC 5705 exported key > material) interoperate with middleboxes? This use of the mechanism is no= t > negotiated on the TLS level, so there is no extension for the middlebox t= o > strip that would warn the endpoints not to use exported authenticators. > Are application level proxies the only compatible middleboxes? > > > > I'm not sure I properly understand the question, in particular what kin= d > of > > middlebox you're considering. Note that application protocols will nee= d > to > > have some way to negotiate the use of this functionality, which > presumably a > > middlebox could also inspect. > > > That is the problem.. some middleboxes are protocol agnostic and are used > to strip the TLS layer before feeding the rest of the security stack - so > called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs =E2=80=9CApp= lication Layer Intercept=E2=80=9D > (ignoring =E2=80=9CTransport Layer Passive Intercept=E2=80=9D for the mom= ent). Some > middleboxes might also perform transport layer active intercept in > combination with passive application detection, i.e. L7 analysis vs L7 > termination. > In summary: the endpoints cannot assume that exported key material is > identical in a middlebox environment. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b54b47056b9fdbdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that this is different from Token Binding becaus= e that's negotiated by an extension, so per S 9.3, non-supporting middl= eboxes need to strip out the extension

-Ekr


On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <= r@nerd.ninja> wrote:

> On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>
> On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
>> How will this (and any mechanism built on top of RFC 5705 exported= key material) interoperate with middleboxes?=C2=A0 This use of the mechani= sm is not negotiated on the TLS level, so there is no extension for the mid= dlebox to strip that would warn the endpoints not to use exported authentic= ators.=C2=A0 Are application level proxies the only compatible middleboxes?=
>
> I'm not sure I properly understand the question, in particular wha= t kind of
> middlebox you're considering.=C2=A0 Note that application protocol= s will need to
> have some way to negotiate the use of this functionality, which presum= ably a
> middlebox could also inspect.


That is the problem.. some middleboxes are protocol agnostic and are= used to strip the TLS layer before feeding the rest of the security stack = - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs =E2=80=9C= Application Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport Layer Pas= sive Intercept=E2=80=9D for the moment).=C2=A0 Some middleboxes might also = perform transport layer active intercept in combination with passive applic= ation detection, i.e. L7 analysis vs L7 termination.
In summary: the endpoints cannot assume that exported key material is ident= ical in a middlebox environment.



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

--000000000000b54b47056b9fdbdc-- From nobody Mon May 7 09:16: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 B31FA126DFF for ; Mon, 7 May 2018 09:16: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DldLMtT8yRnC for ; Mon, 7 May 2018 09:16:41 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C13120726 for ; Mon, 7 May 2018 09:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525709797; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=6286; bh=6j7Nrg2Ys+n11sbzIHxXJFglijCz4INIIhxpSc/tgns=; b=qeWdxMNMYTQMG/Xacm25GoneeDIzGtOUPeW+VOaGjgr6/XwPyIDKSJa6yWgDAzUj 3EnBpxO8/T0SNSyF8+FEUSxC1Z3N9CXyQfExz5b/LKvwiWYlMubHhWXB2vP3QFay7t7 uVs0Ueo8SFQErA0jAIHPwSNIEF4oeDAX4AvBR4pA= Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525709797347959.4615496468837; Mon, 7 May 2018 09:16:37 -0700 (PDT) From: Roelof duToit Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F29301-4C96-4A67-96BA-D73F3C390296" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 May 2018 12:16:30 -0400 In-Reply-To: Cc: Benjamin Kaduk , TLS WG To: Eric Rescorla References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Mon, 07 May 2018 16:16:43 -0000 --Apple-Mail=_B6F29301-4C96-4A67-96BA-D73F3C390296 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree. Middleboxes can signal on the TLS layer that token-binding is = not supported, but not for exported-authenticator. > On May 7, 2018, at 12:06 PM, Eric Rescorla wrote: >=20 > Note that this is different from Token Binding because that's = negotiated by an extension, so per S 9.3, non-supporting middleboxes = need to strip out the extension >=20 > -Ekr >=20 >=20 > On Mon, May 7, 2018 at 8:06 AM, Roelof duToit > wrote: >=20 > > On May 4, 2018, at 5:48 PM, Benjamin Kaduk > wrote: > >=20 > > On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: > >> How will this (and any mechanism built on top of RFC 5705 exported = key material) interoperate with middleboxes? This use of the mechanism = is not negotiated on the TLS level, so there is no extension for the = middlebox to strip that would warn the endpoints not to use exported = authenticators. Are application level proxies the only compatible = middleboxes? > >=20 > > I'm not sure I properly understand the question, in particular what = kind of > > middlebox you're considering. Note that application protocols will = need to > > have some way to negotiate the use of this functionality, which = presumably a > > middlebox could also inspect. >=20 >=20 > That is the problem.. some middleboxes are protocol agnostic and are = used to strip the TLS layer before feeding the rest of the security = stack - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs = =E2=80=9CApplication Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport= Layer Passive Intercept=E2=80=9D for the moment). Some middleboxes = might also perform transport layer active intercept in combination with = passive application detection, i.e. L7 analysis vs L7 termination. > In summary: the endpoints cannot assume that exported key material is = identical in a middlebox environment. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_B6F29301-4C96-4A67-96BA-D73F3C390296 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Agree.  Middleboxes can signal on the = TLS layer that token-binding is not supported, but not for = exported-authenticator.

On May 7, 2018, at 12:06 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:

Note that this is different from = Token Binding because that's negotiated by an extension, so per S 9.3, = non-supporting middleboxes need to strip out the extension

-Ekr


On Mon, = May 7, 2018 at 8:06 AM, Roelof duToit <r@nerd.ninja> wrote:

> On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bkaduk@akamai.com> = wrote:
>
> On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
>> How will this (and any mechanism built on top of RFC 5705 = exported key material) interoperate with middleboxes?  This use of = the mechanism is not negotiated on the TLS level, so there is no = extension for the middlebox to strip that would warn the endpoints not = to use exported authenticators.  Are application level proxies the = only compatible middleboxes?
>
> I'm not sure I properly understand the question, in particular what = kind of
> middlebox you're considering.  Note that application protocols = will need to
> have some way to negotiate the use of this functionality, which = presumably a
> middlebox could also inspect.


That is the problem.. some middleboxes are protocol agnostic and = are used to strip the TLS layer before feeding the rest of the security = stack - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs = =E2=80=9CApplication Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport= Layer Passive Intercept=E2=80=9D for the moment).  Some = middleboxes might also perform transport layer active intercept in = combination with passive application detection, i.e. L7 analysis vs L7 = termination.
In summary: the endpoints cannot assume that exported key material is = identical in a middlebox environment.



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


= --Apple-Mail=_B6F29301-4C96-4A67-96BA-D73F3C390296-- From nobody Tue May 8 09:20: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 42BB012E891 for ; Tue, 8 May 2018 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXRsS1usWBcC for ; Tue, 8 May 2018 09:20:24 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D8D12D967 for ; Tue, 8 May 2018 09:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525796418; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; l=7942; bh=7t2qeTPBp+VgQrHxE1Vws/J0cvIwrjbDGQ2FTwoHbl0=; b=NUQD1GLP/+VMp2iAfoIWLH/1qLdjAfYVxc3WRFo9shXt8xcvr/6OT2EliaHTDfnk 5aDGYEjAiXfaRdlmHFIIePzs/UHeOHyedSKe4UFJACvk83uy+NlhlZbSlzUW+rVHjAq 1QTk7Vv9GkBlw30M4b/Ri0B6JQ2Eg6BuZzpYkPxI= Received: from m2657400hhtdd.lan (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1525796418641368.0730765794344; Tue, 8 May 2018 09:20:18 -0700 (PDT) From: Roelof duToit Content-Type: multipart/alternative; boundary="Apple-Mail=_F4810240-270B-4C57-AD83-FDB5F1942102" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 8 May 2018 12:20:13 -0400 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> To: Eric Rescorla , TLS WG In-Reply-To: Message-Id: <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Tue, 08 May 2018 16:20:27 -0000 --Apple-Mail=_F4810240-270B-4C57-AD83-FDB5F1942102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I understand that there is not really anything to negotiate per se, but = would it not be prudent to add a TLS extension to negotiate support for = exported-authenticator in the TLS layer prior to using it in the = application layer? =E2=80=94Roelof > On May 7, 2018, at 12:16 PM, Roelof duToit wrote: >=20 > Agree. Middleboxes can signal on the TLS layer that token-binding is = not supported, but not for exported-authenticator. >=20 >> On May 7, 2018, at 12:06 PM, Eric Rescorla > wrote: >>=20 >> Note that this is different from Token Binding because that's = negotiated by an extension, so per S 9.3, non-supporting middleboxes = need to strip out the extension >>=20 >> -Ekr >>=20 >>=20 >> On Mon, May 7, 2018 at 8:06 AM, Roelof duToit > wrote: >>=20 >> > On May 4, 2018, at 5:48 PM, Benjamin Kaduk > wrote: >> >=20 >> > On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: >> >> How will this (and any mechanism built on top of RFC 5705 exported = key material) interoperate with middleboxes? This use of the mechanism = is not negotiated on the TLS level, so there is no extension for the = middlebox to strip that would warn the endpoints not to use exported = authenticators. Are application level proxies the only compatible = middleboxes? >> >=20 >> > I'm not sure I properly understand the question, in particular what = kind of >> > middlebox you're considering. Note that application protocols will = need to >> > have some way to negotiate the use of this functionality, which = presumably a >> > middlebox could also inspect. >>=20 >>=20 >> That is the problem.. some middleboxes are protocol agnostic and are = used to strip the TLS layer before feeding the rest of the security = stack - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs = =E2=80=9CApplication Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport= Layer Passive Intercept=E2=80=9D for the moment). Some middleboxes = might also perform transport layer active intercept in combination with = passive application detection, i.e. L7 analysis vs L7 termination. >> In summary: the endpoints cannot assume that exported key material is = identical in a middlebox environment. >>=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=_F4810240-270B-4C57-AD83-FDB5F1942102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I understand that there is not really anything to negotiate = per se, but would it not be prudent to add a TLS extension to negotiate = support for exported-authenticator in the TLS layer prior to using it in = the application layer?

=E2=80=94Roelof

On = May 7, 2018, at 12:16 PM, Roelof duToit <r@nerd.ninja> = wrote:

Agree.  Middleboxes can signal on the TLS layer that = token-binding is not supported, but not for = exported-authenticator.

On May 7, 2018, at 12:06 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

Note that this is different from Token = Binding because that's negotiated by an extension, so per S 9.3, = non-supporting middleboxes need to strip out the extension

-Ekr


On Mon, = May 7, 2018 at 8:06 AM, Roelof duToit <r@nerd.ninja> wrote:

> On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bkaduk@akamai.com> = wrote:
>
> On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
>> How will this (and any mechanism built on top of RFC 5705 = exported key material) interoperate with middleboxes?  This use of = the mechanism is not negotiated on the TLS level, so there is no = extension for the middlebox to strip that would warn the endpoints not = to use exported authenticators.  Are application level proxies the = only compatible middleboxes?
>
> I'm not sure I properly understand the question, in particular what = kind of
> middlebox you're considering.  Note that application protocols = will need to
> have some way to negotiate the use of this functionality, which = presumably a
> middlebox could also inspect.


That is the problem.. some middleboxes are protocol agnostic and = are used to strip the TLS layer before feeding the rest of the security = stack - so called =E2=80=9CTransport Layer Active Intercept=E2=80=9D vs = =E2=80=9CApplication Layer Intercept=E2=80=9D (ignoring =E2=80=9CTransport= Layer Passive Intercept=E2=80=9D for the moment).  Some = middleboxes might also perform transport layer active intercept in = combination with passive application detection, i.e. L7 analysis vs L7 = termination.
In summary: the endpoints cannot assume that exported key material is = identical in a middlebox environment.



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


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

= --Apple-Mail=_F4810240-270B-4C57-AD83-FDB5F1942102-- From nobody Tue May 8 09: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 2FFCD12E9D9 for ; Tue, 8 May 2018 09:30: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=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 M3yuDhUavrgw for ; Tue, 8 May 2018 09:30:57 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEBF126D73 for ; Tue, 8 May 2018 09:30:57 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id q6-v6so41811909qtn.3 for ; Tue, 08 May 2018 09:30:57 -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=RhtF2mY8AhIN+haRwuaJf3ijheS9j37+AzZTmfd2pCM=; b=GGHCgxrk9W3QWqoX6sy5/HCzIt3UTt5cUxO2Ez22+N0IGvutKWWtLJymS/v/HWkR2z 2loz1Vn0snnIp093IRYX3C1Yf4lDeb74YNtDHSXOkeeoawF3NkREG+tlhnHfw9LRusnK NRMWp0Y+wAjhou0QnGPwblfZn64F4zzMUhqqM= 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=RhtF2mY8AhIN+haRwuaJf3ijheS9j37+AzZTmfd2pCM=; b=BoES2bHOJDWw0KNgrnTMIZIKWgKzTsxqSkJUObnWVZGKSuiLYa3L/a9qMspeaZRZ2R 1x1aqCJ4wIDVYH+4C4u+jTJb0yhBGX+sXeCm354vYMtFsRugJCLV/X+jVqV1TpsOyn4H EmzjelGa8b5sYGeTWtz6fPjn9mReoM6uua5/SJsgyBupcFvCLlahFYzKhs16sGu2Easi gobJDN7GWaNe4BCpyBOsQlWlLC6xV77qxyDy4lt1Gx8pRpUFVErvgAsG5PgkDl/dS0TY Qz4xlg/D3Jqot6zMv8IbvWOVR0DVHEUg+B6NB0oHU4UQ2ji+ELFrqQViRdSWqgwFRJz6 1ehg== X-Gm-Message-State: ALQs6tBjOP4DvCV5lzb2OMxqi14TZ+Ae4FeS9fCrvnmzfJzmbXPYCDty qWV+qXcPv1IoLJJ6c2780iDWx6G+obg= X-Google-Smtp-Source: AB8JxZrk31HNEWvwyp8sJcZwsKrwVIoGxO4aUCBj8dpuDmjbT7gfGybUI51evFZUO+QjbLmf9fXQog== X-Received: by 2002:a0c:d790:: with SMTP id z16-v6mr22719905qvi.33.1525797056303; Tue, 08 May 2018 09:30:56 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id y84sm19377951qkb.23.2018.05.08.09.30.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 09:30:55 -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: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> Date: Tue, 8 May 2018 12:30:54 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 May 2018 16:30:59 -0000 All, This is the working group last call for the "Example Handshake Traces = for TLS 1.3" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/. Please = review the document and send your comments to the list by 2359 UTC on 22 = May 2018. Thanks - J&S= From nobody Tue May 8 09:49: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 0E57B12EA67 for ; Tue, 8 May 2018 09:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gwBwSZNLhHpA for ; Tue, 8 May 2018 09:49:06 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF0512EA58 for ; Tue, 8 May 2018 09:49:06 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id h2-v6so41906648qtp.7 for ; Tue, 08 May 2018 09:49:06 -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=KZyGY+iaX9OFj3JSUOcxBq7XZ+Txlzf4T9qphOWuVBc=; b=PXR860TsmeplA8RyW5GYpQUjQB7XvYG5G/D5Az0tcNT5AWuKIAPzpioY/695kEAxRD yne5JoVFgHsckJf0EuD3CENN8phMdtBwexPXBjE7tIEznn6z7BFFijNDk/oszEKQn0D+ 9rogqVY9oDrJWotYx0Tv1E5hu/DDKSey2EokI= 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=KZyGY+iaX9OFj3JSUOcxBq7XZ+Txlzf4T9qphOWuVBc=; b=h8kbhKBlncGqManSTa488g8cLhm79ZeNcFvpGony/hOpFkQ03kW82cqgx+qPQaw+oF 4gUN44CIp4uLjPtZ+vsY6UeORpEB0H8KHkHi8Fj4jY/pkerXYzZEzCP5bJTnzIMpcZoX nEeBgGAxV7m3M/tvcfjZ1C+dsuhmd7UEQgiUOpCpWExJUF/DmZRUfKyYnYZUGqacQQ18 1h8XvmV54SEqUce9ym035m0kU9b/e2SosANen/LL1D2A/4bRSb6ThHx0OLXMxNxHeR4I +BAi0NKVvO6I5jEB5qGgB7V9czO8XCIo586ryuXJ8EsPNB29qGyMd+VtPz5O9kD0FpSH VdVQ== X-Gm-Message-State: ALQs6tDs5gRSzDn/x+0K2EwNlh7sQDz3sZu6jmHh6Vv019FTuo9NF3Tt SarC5x3/KNygqtNaV2eiETXeX7wnkYU= X-Google-Smtp-Source: AB8JxZpQHDU+tacOX0fnAa5FzfJsFbm5y3jSxrdrgf/Pfc1KYkUd66onLvMWPC3R0O8LoEnu/lBb4w== X-Received: by 2002:ac8:7c6:: with SMTP id m6-v6mr37618352qth.381.1525798145451; Tue, 08 May 2018 09:49:05 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id k188sm19102982qkf.57.2018.05.08.09.49.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 09:49:04 -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: Tue, 8 May 2018 12:49:03 -0400 References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> To: TLS WG In-Reply-To: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 May 2018 16:49:09 -0000 I noted two things that I didn=E2=80=99t think we needed to wait for: 1. The draft needs an IANA Considerations section to at least get = through the GENART process (the section can later be removed during = AUTH48 if requested). I submitted a PR to address this: https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/4 2. Intended RFC status=20 I don=E2=80=99t have a strong opinion on this, but many of the = =E2=80=9Cexample" drafts are Informational, but some are BCP and this = one current indicates Proposed Standard. Let the list know if you=E2=80=99= ve got strong feelings one way or another. I submitted an issue to make = sure we track this this: https://github.com/tlswg/draft-ietf-tls-tls13-vectors/issues/5 Cheers, spt > On May 8, 2018, at 12:30, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the "Example Handshake Traces = for TLS 1.3" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/. Please = review the document and send your comments to the list by 2359 UTC on 22 = May 2018. >=20 > Thanks - J&S From nobody Tue May 8 09:56: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 6CBC112EA64 for ; Tue, 8 May 2018 09:55:59 -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 sRnjkhChUFfT for ; Tue, 8 May 2018 09:55:58 -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 020C7126E64 for ; Tue, 8 May 2018 09:55:57 -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 w48Gsosd006724; Tue, 8 May 2018 17:55:57 +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=whob/khLjOC0s35UGx3mVv9UhG9vZFJO6AJPFrOYbrI=; b=YNreCuGoGz6Bokn3wXIDqkTrk5wjBdi4OfsWijKHX7euFuQAygY9hrBfOHl/bWM2xsI5 wU6WmukKcuXJTML7wDE2ViQ/gKY5QruelszREx2hCdxEHlQMSsRPrdH6hisw5SQCeRfw eviVjgHUtB0noIIhFBh9xQbmzVdPRghWWFg2KnkV7e2Pb6nPXDt++6SNR9ElXeOAxUzH 7xAZ/qzKbRkdkZiSTd3BPG4/X4lrjyZWGGM/KCvu7LB3BjmI2IZBaOpft5408Pq0x7hF WIbGym+wWcf2UZzM9NErIPPcH4d4Eo95YxuSs0TMhKewOMgGgKkxG1TMiuj3F42SzlI+ cw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2hue76g9g7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 May 2018 17:55:57 +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 w48Gp19h024811; Tue, 8 May 2018 12:55:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2hs7yavs7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 May 2018 12:55:56 -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; Tue, 8 May 2018 12:55:55 -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; Tue, 8 May 2018 12:55:55 -0400 From: "Salz, Rich" To: Sean Turner , "tls@ietf.org" Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-vectors Thread-Index: AQHT5un8KmgeAEs+SEa21GDHJl2dAqQmTiqA//++1IA= Date: Tue, 8 May 2018 16:55:55 +0000 Message-ID: <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.40] Content-Type: text/plain; charset="utf-8" Content-ID: <3638A55A142B9A4D806817FD022C10B4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_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=623 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805080162 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_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=584 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805080162 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 May 2018 16:55:59 -0000 SSBkaXNsaWtlIHN0YW5kYXJkLCBhbmQgYW0gZmluZSB3aXRoIEluZm9ybWF0aW9uYWwgb3IgQkNQ Lg0KIA0KDQo= From nobody Tue May 8 13:26: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 6BBC312EAB1 for ; Tue, 8 May 2018 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qVqWRdu2i9f for ; Tue, 8 May 2018 13:26:33 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 317DE12DA06 for ; Tue, 8 May 2018 13:26:32 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w48KQSjn042479; Tue, 8 May 2018 16:26:28 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" , Sean Turner , "tls@ietf.org" Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-vectors Thread-Index: AQHT5un4JfKJUK4PqEWWp9/ditCkLaQmTiqAgAAB7ID///fEgA== Date: Tue, 8 May 2018 20:26:28 +0000 Message-ID: <3D980955-3C7A-46C2-A43E-1CC4A6BE02BD@ll.mit.edu> References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> In-Reply-To: <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-originating-ip: [172.25.87.160] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3608641587_1561328940" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-08_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-1805080191 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 May 2018 20:26:37 -0000 --B_3608641587_1561328940 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If it's intended to be a "test-vector", then by all means it should be a st= andard. If it's just for illustration - Informational or BCP is fine. My $0.02. -- Regards, Uri Blumenthal =EF=BB=BFOn 5/8/18, 12:56, "TLS on behalf of Salz, Rich" wrote: I dislike standard, and am fine with Informational or BCP. =20 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 --B_3608641587_1561328940 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQggoVbJHXVin8voiB4 mfSL2/6rdqIr6+8TkqQXy/8DLWAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwNTA4MjAyNjI3WjANBgkqhkiG9w0BAQEFAASCAQAECVDCHUWF/5EP6G0/ 1L8s9b22BMHVSUeTscc8dAzwyb6m6NZoI82RqLy25l93AoP1twM0vRbi2lVY2wUztk2muuN0 BoO+zJ6f02IyEx4Ik7LnmXxPKQUJSpuvh1VMhxzZht5GMrxvG7XM7tXK0IPFT8PkQCf8zdwe ncLAFfqn58VU3v4Z5vaDZ/bssVBKTQhy2FgdKb0NUYqfmVwhVBsFaY8AqaAmLhB7Fjp9qyAw /SHE1/L+xO1Jpn+71atJRYS1+tzNEXLxAc5bajVN9pCDQKMqLkYt8STchgsUU7N/YGn3X3Nj PZgL3xd/HPVECI6PeH1akaDIqCzyMW0UhjgY --B_3608641587_1561328940-- From nobody Tue May 8 16:42: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 F388312D7F2 for ; Tue, 8 May 2018 16:42:10 -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 (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzKcA7I3WFPk for ; Tue, 8 May 2018 16:42:08 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275C812D7F1 for ; Tue, 8 May 2018 16:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ITHGHMW4VRusXSb5LGKQ8LoNlvvNUHJV49N1jrAAoLE=; b=IiA2+LqYfPEfLQ5WnvN6bILFtuxvdleqq7SqAhmH2odyDzpigZ3K/DZDn7N892jCeQw52FLNpjo7JKnHppzJ1HFQF2IfQe5HhkxvSHcz3DUxfOL2dvqmVJq+Q2mv+3ZeTt7NNBG5aIhGdaWynSOxM9pa/Vz+8K1OEQnCBtiFJp0= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1901.namprd08.prod.outlook.com (10.169.39.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.18; Tue, 8 May 2018 23:42:04 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d%13]) with mapi id 15.20.0735.018; Tue, 8 May 2018 23:42:04 +0000 From: Mike Bishop To: Nick Sullivan , Sean Turner CC: TLS WG Thread-Topic: [TLS] WGLC for draft-ietf-tls-exported-authenticator Thread-Index: AQHT4xuYygdnSnGKCk238dI2fwicCqQmhfZw Date: Tue, 8 May 2018 23:42:04 +0000 Message-ID: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:5a28:5004:e201:a5af:9d41] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1901; 7:hGTdu8iKMBH6O6zsp7BPomFdFG038jMyYZOx5hNoMFOZUaU7+dFDY24xsZecMixPHsbA02e+lxS50prNaE9ZRFdPyg67jAO8BZ/Awt2okGQyvQLZyYGfA8O+58V3DEUnoIt+q8G/KOJy8iZCpqIPtPZ46+kclOA8eBXDRSIE2AmnDeAFAITm1JqHXsKu8VyWUfLv7KBGWH5EI+ftqVtyIYaBSQfp/9Q1+CHwkV3gO5WDoQL+QVAO0swyV0h6e4bv x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1901; x-ms-traffictypediagnostic: SN1PR08MB1901: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(2016111802025)(20161123558120)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1901; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1901; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(346002)(366004)(39830400003)(396003)(189003)(199004)(53434003)(46003)(3660700001)(2906002)(316002)(966005)(74482002)(5250100002)(86362001)(55016002)(5660300001)(2900100001)(106356001)(53546011)(7696005)(93886005)(99286004)(11346002)(110136005)(14454004)(105586002)(76176011)(446003)(59450400001)(19609705001)(6506007)(102836004)(6436002)(229853002)(186003)(7736002)(790700001)(236005)(81166006)(33656002)(4326008)(25786009)(486006)(8676002)(476003)(6116002)(68736007)(97736004)(606006)(54896002)(74316002)(3280700002)(6306002)(39060400002)(478600001)(81156014)(6246003)(53936002)(9686003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1901; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: WiJH2OhGq3ITBTNwNwMzgMHRRHm0ULtLVC3M9ee0NgTKO391fmYASTgdoFgNDkxVfKQzesiC2OgOOKcpDe3WDXAtjnmoj0p2vGOO8dSg2ni8oa5XFrhmDBgSbSSwUgGCEbV90kH+MwIWfeeTGrz9Gw3KyHfOd7DPbQAWVGc7nbuRtIpwe/sC82X5htj2KY67 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854029B15EDB0F0F1ADCC18DA9A0SN1PR08MB1854namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 34bb3375-9026-4482-3446-08d5b53d4df4 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 34bb3375-9026-4482-3446-08d5b53d4df4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 23:42:04.6556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1901 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: Tue, 08 May 2018 23:42:11 -0000 --_000_SN1PR08MB1854029B15EDB0F0F1ADCC18DA9A0SN1PR08MB1854namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVsYXRlZGx5LCBhcyBJ4oCZdmUgYmVlbiBvZmZsaW5lIGZvciB0aGUgcGFzdCB3ZWVrLCBidXQg SSBzdXBwb3J0IHRoaXMgZHJhZnQgbW92aW5nIGZvcndhcmQuDQoNCkZyb206IE5pY2sgU3VsbGl2 YW4gPG5pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMywg MjAxOCAxOjE2IFBNDQpUbzogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KQ2M6IFRMUyBX RyA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFdHTEMgZm9yIGRyYWZ0LWlldGYt dGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3INCg0KRG9lcyBhbnlvbmUgaGF2ZSBhbnkgY29tbWVu dHMgYWJvdXQgdGhlIGRyYWZ0LCBjcml0aWNpc21zLCBvciB2b3RlcyBvZiBzdXBwb3J0Pw0KDQpO aWNrDQpPbiBUaHUsIE1heSAzLCAyMDE4IGF0IDE6MTIgUE0gU2VhbiBUdXJuZXIgPHNlYW5Ac24z cmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0KDQoNCj4gT24gQXByIDIxLCAy MDE4LCBhdCAxMDoyNSwgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNu M3JkLmNvbT4+IHdyb3RlOg0KPg0KPg0KPj4gT24gQXByIDE5LCAyMDE4LCBhdCAxNjozMiwgU2Vh biBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0K Pj4NCj4+IEFsbCwNCj4+DQo+PiBUaGlzIGlzIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBm b3IgdGhlICJFeHBvcnRlZCBBdXRoZW50aWNhdG9ycyBpbiBUTFMiIGRyYWZ0IGF2YWlsYWJsZSBh dCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRscy1leHBvcnRl ZC1hdXRoZW50aWNhdG9yLy4gIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIHlv dXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgMjM1OSBVVEMgb24gNCBBcHJpbCAyMDE4Lg0KPg0K PiDigKYgNCBNYXkgMjAxOCAuLi4NCg0KSnVzdCBhIHJlbWluZGVyIHRoZSBXR0xDIGVuZHMgdG9t b3Jyb3cuDQoNCnNwdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --_000_SN1PR08MB1854029B15EDB0F0F1ADCC18DA9A0SN1PR08MB1854namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZWxhdGVkbHksIGFzIEnigJl2ZSBiZWVuIG9mZmxpbmUgZm9yIHRoZSBwYXN0IHdlZWssIGJ1dCBJ IHN1cHBvcnQgdGhpcyBkcmFmdCBtb3ZpbmcgZm9yd2FyZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IE5pY2sgU3VsbGl2YW4gJmx0O25pY2hvbGFzLnN1bGxpdmFuQGdtYWls LmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMywgMjAxOCAxOjE2IFBN PGJyPg0KPGI+VG86PC9iPiBTZWFuIFR1cm5lciAmbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBUTFMgV0cgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtUTFNdIFdHTEMgZm9yIGRyYWZ0LWlldGYtdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0 b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIGFueW9uZSBoYXZl IGFueSBjb21tZW50cyBhYm91dCB0aGUgZHJhZnQsIGNyaXRpY2lzbXMsIG9yIHZvdGVzIG9mIHN1 cHBvcnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5OaWNrPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWF5IDMsIDIwMTggYXQgMToxMiBQTSBT ZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIj5zZWFuQHNuM3Jk LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KJmd0OyBPbiBBcHIgMjEsIDIwMTgsIGF0 IDEwOjI1LCBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+c2VhbkBzbjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyZndDsgT24gQXByIDE5LCAyMDE4LCBhdCAxNjozMiwgU2VhbiBU dXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnNlYW5Ac24zcmQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgQWxsLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoaXMgaXMgdGhlIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGZvciB0aGUgJnF1b3Q7RXhwb3J0ZWQgQXV0aGVudGljYXRvcnMgaW4g VExTJnF1b3Q7IGRyYWZ0IGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtZXhwb3J0ZWQtYXV0aGVudGljYXRvci8iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3IvPC9hPi4mbmJzcDsgUGxlYXNlIHJldmlldyB0 aGUgZG9jdW1lbnQgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSAyMzU5IFVU QyBvbiA0IEFwcmlsIDIwMTguPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IOKApiA0IE1heSAyMDE4IC4u Ljxicj4NCjxicj4NCkp1c3QgYSByZW1pbmRlciB0aGUgV0dMQyBlbmRzIHRvbW9ycm93Ljxicj4N Cjxicj4NCnNwdDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_SN1PR08MB1854029B15EDB0F0F1ADCC18DA9A0SN1PR08MB1854namp_-- From nobody Tue May 8 17:13: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 DFAE012D964 for ; Tue, 8 May 2018 17:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o_-_8eX4p8au for ; Tue, 8 May 2018 17:13:29 -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 4C5BD12D80F for ; Tue, 8 May 2018 17:13:29 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id n3-v6so1903760ota.5 for ; Tue, 08 May 2018 17:13:29 -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=QJlRh6al63Qm+ws/imG8LdQaXg6im3HRZxKQCR+y6t8=; b=mB++73mHzBCuwcAH7P++NX5SW59llwHoXhtrAsAyJjhU1rvwTfjh6gU5BEcS0Hifvl MIRmUdsEfoOakP0mHzEcfA0ulHGbj+k9oKNvqm2GCTWrfx1Sm9l1MkuyJejDfKTEJ6c1 Q744Xi1v5yznkXu47H12Jo8j+EkW8hn7/lNcye8GsL3Lkb9Kpfq9kSleq1Hgp2KnJNRr vGm6buM+63MIGrE+9gDDCSdFWCLctht5YNNdr/spci+BYEICRK/8Goc5sGkyTr+f9jUM E4FQn4qktstqpaOu/0tnVodS0MPiMv+VkiorAleZ+F0BLTS/z4yzHcp7bbHEim28FKal wWrQ== 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=QJlRh6al63Qm+ws/imG8LdQaXg6im3HRZxKQCR+y6t8=; b=eHldBJUyHjly1mAeztiO1d4f99hoJSqzQ++W1oNYqmPnrB1oZb0RJKloV/1cexH9VL FMOdD/c3edfdW0rzIGPm1d+F6J1ic9oFP22j2dUimMypH9VwlfJfUIptvnYizKfHcehO sPuW9NVINGSPgE0dM+PvqPE7AummpdHdoC5avHPTk8R6g/rDhLTRoXUQoVAfXo4Vwasr /VBIeMtcyGb2v659Mu2gtAmTqfn/KjeejBJiYxNimbpOiW7l11UGMohd2xLUuaN1ZtyX 5gzjmh3qB6bQ2j4HbgAZWLKJATdbRTKtOB4c7J1Pvt8tkQihtmulaN5glL4tKceGhyUz d/hQ== X-Gm-Message-State: ALQs6tAy4Mo7+2zU7J2TNtUOxHuJTAqtwrRR8LJiOkTTay1m0HE/nT5f DtXW9XAl8PO8kbA1EfZvZseBuboXAaTSPgQ0opw= X-Google-Smtp-Source: AB8JxZoTIQYGVlmaX5eLdS6bgr49NFYYv5Y60rcLMyvUd4Pa9KrHJVrlm0drL3w5MV2CnYZALBCPPhhrZNNBL11bALM= X-Received: by 2002:a9d:34f1:: with SMTP id t46-v6mr29613390otd.396.1525824808425; Tue, 08 May 2018 17:13:28 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> In-Reply-To: <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> From: Martin Thomson Date: Wed, 09 May 2018 00:13:18 +0000 Message-ID: To: r@nerd.ninja Cc: Eric Rescorla , "" Content-Type: text/plain; charset="UTF-8" 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: Wed, 09 May 2018 00:13:31 -0000 On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: > I understand that there is not really anything to negotiate per se, but would it not be prudent to add a TLS extension to negotiate support for exported-authenticator in the TLS layer prior to using it in the application layer? We don't signal the potential need for exporters. I see no reason to signal this either. Any signaling necessary really belongs at the higher layer. From nobody Tue May 8 17:31: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 567A3120727 for ; Tue, 8 May 2018 17:31:05 -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 j-IeTbQ-Yn9n for ; Tue, 8 May 2018 17:31:03 -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 A1CE41201FA for ; Tue, 8 May 2018 17:31:03 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id t27-v6so29997591oij.9 for ; Tue, 08 May 2018 17:31:03 -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=IhfNAjuitk4S0j+TkGWPYyMZjRSUcKQMZgotFXmeuz4=; b=ntHIQ5nSoosbjtoEZxcVoQzrBUGEabQ2X6bOi/JMru6pP80eKVwc1aWBnpVk0JMOXO xRajPn54Ao0RJvruhovzDl5Nx7OL6OdOrd9nnFumuXFtv13DHeQCZnmCWRJ7s7W1IiZb sQFT856gVqNrDF/aX8yM4hzIZ2wdugr1xKyozOCgHG75/f/rZNUuehSbUU14g80FGyZM TlrXg0OFCemI2i+ykkKVz1ZwWjOMmy0xHeoHD6TZBgOLql4Bv8SKuQcpJYbSo/8/vLi+ daayNsp2wUmDm1IZUkc347FFFsVJWFeBMy9TxynGH8ZO38ZsbaXtzJtqD3pkWzajssVH iDhg== 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=IhfNAjuitk4S0j+TkGWPYyMZjRSUcKQMZgotFXmeuz4=; b=Ry9nTt2J2hWQZjS9/N9yR40hLVp6hhYKPBVpt+/wyuJdZSBIB3FJwR10otleFgAjHg jMAEfthEKRLHfED1N1EDt/fYlMowhl6k15bxr81dVvqyHY9S+Poo0+Fb43AQoiVbf7KE IaZy0PukzY4txK8Drl8pfWGEkIdjYArC94IYgIuCiVwG9htg7fpAhuL9WvDpyl4GmsBE prQuUVT/6MrB7nCW0tH9aYDzphcfMeUzG9MqsiJ5BG0NPfw3foTzNrYRXuEThGniJxLa 6UtWsi/mIeSNBs78JkreawQ19AwI1b6e/rTjboQ21GlinusLUpQ/VmOz4iglA13LAwi7 pEgw== X-Gm-Message-State: ALQs6tAuoXohUI3yi6iEv7nqE4a+WiSaI7IIjPpAHOIfgkGIcXCbdp40 cc1xEwmJBjRjCOMwQwPRZsoQgyeYt+WNkMWenP1aRA== X-Google-Smtp-Source: AB8JxZoRIwz4h6PED0c6/Nr+KGfP1jl1U2eziElyp6/jITy/zEvUB6vI3uWpLkV01actifE2Atg9+PRAVJ1oYrNMnYw= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr25474001oib.295.1525825862941; Tue, 08 May 2018 17:31:02 -0700 (PDT) MIME-Version: 1.0 References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> In-Reply-To: <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> From: Martin Thomson Date: Wed, 09 May 2018 00:30:52 +0000 Message-ID: To: "Salz, Rich" Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 May 2018 00:31:05 -0000 On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: > I dislike standard, and am fine with Informational or BCP. Agree regarding standard. I don't understand why BCP would be used for this. Besides, we probably don't want to enshrine some of the choices we made in NSS as "best practice". I'm not saying that those choices aren't defensible, but that might be going too far. From nobody Tue May 8 18:25: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 AEDAD12D869 for ; Tue, 8 May 2018 18:25:07 -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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K6ekSRfKvjs for ; Tue, 8 May 2018 18:25:06 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F138412708C for ; Tue, 8 May 2018 18:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525829097; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=926; bh=vmYt4FHuQJuvjHicIxGp60W30aB3DGEeLQq9N2oHVP8=; b=Gbla8xEGoVoCWtrltsqF85RZESpxK3t/YX33q5GThXhVr09RSaH5jx70t8e01YJi 1HZyC8tMK8ydhATP8/ZZyK0f24FnNAGm2xaX/opU2LpUoKK0u57ZkmzKJJbAM4P3u34 RgZgmEba6S8iPPysYjHnBIeXTz32ZwFVRdc5GDfI= Received: from m2657400hhtdd.lan (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1525829097892388.2922804605031; Tue, 8 May 2018 18:24:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Roelof duToit In-Reply-To: Date: Tue, 8 May 2018 21:24:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> To: Martin Thomson , "" X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Wed, 09 May 2018 01:25:08 -0000 If the use of the mechanism is not negotiated on the TLS level then I = would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D = section of the draft could be amended to include a paragraph that warns = potential implementors that protocol-agnostic middleboxes will break the = mechanism without any clear failure indicators. > On May 8, 2018, at 8:13 PM, Martin Thomson = wrote: >=20 > On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: >=20 >> I understand that there is not really anything to negotiate per se, = but > would it not be prudent to add a TLS extension to negotiate support = for > exported-authenticator in the TLS layer prior to using it in the > application layer? >=20 > We don't signal the potential need for exporters. I see no reason to > signal this either. Any signaling necessary really belongs at the = higher > layer. From nobody Wed May 9 00:39: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 C691412EB50 for ; Wed, 9 May 2018 00:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDKhqzpnFyZV for ; Wed, 9 May 2018 00:39:20 -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 EDC0012EB59 for ; Wed, 9 May 2018 00:39:19 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id v2-v6so30679356oif.3 for ; Wed, 09 May 2018 00:39:19 -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:content-transfer-encoding; bh=q5QP7Eqm+1TijqnW0mjjCBuvDbb9YW8/gz6DOzhb6K8=; b=MAYwJb6fxUfizf/4hH1X6HO/o42j31UdQP78j9WV5B51LkbF86Uzk+IkMDppisaOoQ kOMue/Ht859+vUqTB3fiOmv/H3YJ42T0UvPWWD0Uoa7Vu8qt1MKgd9aWU2gJNCFsknzb IWDFP3c2c5j07X53/kCuViawxKv3WfS62BJ3TKfRypzK+5Jd8bTUhwxwGZVDYKDDvycB AXVT480eDTNIeOftQvnZx3Nc6vzv7bPR5wi5W1fT06Pq0citxRAez99Ie6T28KBaU3hR btNjxSrjRGiEwM9a/aC7G8Ev2EGLtdsHWvaw7Q+BIDOHcJwXZagCMabwy7PBHdhj7oUg dvZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q5QP7Eqm+1TijqnW0mjjCBuvDbb9YW8/gz6DOzhb6K8=; b=MSqUy7R1n05i4cGxDtb2uuI7AeP4jci16s7gH0Y4iSDLYaeBr6kcqyxhoUlA/jTti7 HTHs5KNQvIPCHt9vbMU7Kz5hwO9NcfUnK1tzcs772WHrLemiSontaDjKYTitvSuC/St8 a8dTQFEz4HLKdhbb1hsbefboAacg9dTFr6KeSaFNq34hNnbJUZJLCopwmNsyPN1wsQD2 ze9zgL9YD+t5kRgy25ICLCZxjJ4v7F9Tmx7WEW0iTpAE3lwywecxZqubykJG4Rl5uHQ1 geTLEszYNtzCIqC9J1jf76kdCL6eGxGgyh2SrSg/mhtMR2QcZJdUQzTrYK/25SpKLM1T 3ypQ== X-Gm-Message-State: ALQs6tAze8W6Bb2FEhJ2L4arQDKicOvtbgLSYc+CDOY+OPOg+DEYq2hQ VfQTdCX/vYLeJnlvjQkKnculHjER9dQX/DjlbrY= X-Google-Smtp-Source: AB8JxZpWvm/MM1QnK7YYbMYRYOy55BL7I0lNLKcjOh2TTm5ZXT11f8SOqwDfZgJGOMugl4KoFuFbEzAMOeGxXgSQVxs= X-Received: by 2002:aca:5bc5:: with SMTP id p188-v6mr25979895oib.295.1525851559104; Wed, 09 May 2018 00:39:19 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> In-Reply-To: From: Martin Thomson Date: Wed, 09 May 2018 07:39:07 +0000 Message-ID: To: r@nerd.ninja Cc: "" , Eric Rescorla Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 09 May 2018 07:39:22 -0000 This isn't really a security consideration though, it's a truism. A MitM can break things that depend on end-to-end integrity of the connection. On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote: > If the use of the mechanism is not negotiated on the TLS level then I would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D sectio= n of the draft could be amended to include a paragraph that warns potential implementors that protocol-agnostic middleboxes will break the mechanism without any clear failure indicators. > > On May 8, 2018, at 8:13 PM, Martin Thomson wrote: > > > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: > > > >> I understand that there is not really anything to negotiate per se, bu= t > > would it not be prudent to add a TLS extension to negotiate support for > > exported-authenticator in the TLS layer prior to using it in the > > application layer? > > > > We don't signal the potential need for exporters. I see no reason to > > signal this either. Any signaling necessary really belongs at the higher > > layer. From nobody Wed May 9 06:21: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 E9980124E15 for ; Wed, 9 May 2018 06:21:28 -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=[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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khEm27znIHu6 for ; Wed, 9 May 2018 06:21:27 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C7D124235 for ; Wed, 9 May 2018 06:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525872081; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1443; bh=TjtoGXkr0hHicYcIaMgHOfJnrHes9fgSdvSx1lz/wRQ=; b=khimi0NDoXAArOjM2+GNnwZLRqj153G0zN5YAzJ6ERZPUqMa6AQjWGCP8TtdRcoY NSMTh59bSsnpn0T/f/p5jEVqZGw+G2x9wUyecwup/HXl2J6j/28yyDpffiFhgOC82e7 gmiikZO6mCDMmXcpVBo9bb3toqZEE4u9TaPkuses= Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525872081242402.1305611796695; Wed, 9 May 2018 06:21:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Roelof duToit In-Reply-To: Date: Wed, 9 May 2018 09:20:43 -0400 Cc: "" , Eric Rescorla Content-Transfer-Encoding: quoted-printable Message-Id: <07F1E93C-82DC-4632-9843-95D813866768@nerd.ninja> References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> To: Martin Thomson X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External 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: Wed, 09 May 2018 13:21:29 -0000 Perhaps, but it still behooves us to warn implementors that a = significant percentage of enterprise traffic will break with this = mechanism. > On May 9, 2018, at 3:39 AM, Martin Thomson = wrote: >=20 > This isn't really a security consideration though, it's a truism. A = MitM > can break things that depend on end-to-end integrity of the = connection. > On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote: >=20 >> If the use of the mechanism is not negotiated on the TLS level then I > would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D = section of the draft > could be amended to include a paragraph that warns potential = implementors > that protocol-agnostic middleboxes will break the mechanism without = any > clear failure indicators. >=20 >>> On May 8, 2018, at 8:13 PM, Martin Thomson = > wrote: >>>=20 >>> On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: >>>=20 >>>> I understand that there is not really anything to negotiate per se, = but >>> would it not be prudent to add a TLS extension to negotiate support = for >>> exported-authenticator in the TLS layer prior to using it in the >>> application layer? >>>=20 >>> We don't signal the potential need for exporters. I see no reason = to >>> signal this either. Any signaling necessary really belongs at the > higher >>> layer. From nobody Wed May 9 06:25: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 1FF17124E15 for ; Wed, 9 May 2018 06:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[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 waN8q5cPO4dC for ; Wed, 9 May 2018 06:25:09 -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 4E91A124D6C for ; Wed, 9 May 2018 06:25:09 -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 w49DNuYM002799; Wed, 9 May 2018 14:25:08 +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=F7H85s6NWyr6+RVKhZuFbB1EirKNoFFiUBK/VvaI61o=; b=JHN6LtlU1sQr21/FkMXs/87fSc2q92bH7LQKRJH8KSUZXPB77X+up4YLQ5cFJPIiNhrl +JhRfiyZkUPvHtxPE8FjTFVJIzNj2HBne9lX3lUZbLmaYy9MtaWgu26kFxBkqri7XeHz OdcZmopKYfymyb6fq2cKkK2pn4gpG86gVSz/1FyvCoPPHCDS9c3tw1bMQW0DEZURcm43 6R2OU8w4w6W3Z/XjObCH6C/G3izSwgCMtECdJera4Lv1shrPOJ+kkcM/kTWT8i5wDOBT +6Ns8K+26ckv5atmuuqetCbaeINPxOU0u61jN79HA65FcPd5+FyuwHoHGKJWUaGF8r3w 9A== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2huyqt898q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 14:25:07 +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 w49DBdMw030922; Wed, 9 May 2018 09:25:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hs7xxf0mh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 09:25:06 -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; Wed, 9 May 2018 09:25:04 -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; Wed, 9 May 2018 09:25:04 -0400 From: "Salz, Rich" To: Roelof duToit , Martin Thomson CC: "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-exported-authenticator Thread-Index: AQHT2B2j0YRvfH++EU+2iO+8G2AW16QgCdCAgABsUICABEaPAIAAEMiAgAAC3wCAAZNfgIAAhC0AgAAUAICAAGiQgIAAX3GA//++HQA= Date: Wed, 9 May 2018 13:25:03 +0000 Message-ID: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> <07F1E93C-82DC-4632-9843-95D813866768@nerd.ninja> In-Reply-To: <07F1E93C-82DC-4632-9843-95D813866768@nerd.ninja> 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.40.74] Content-Type: text/plain; charset="utf-8" Content-ID: <7E081D6CF256464E8E2FC8EF35BA3068@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=615 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090125 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=538 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090127 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: Wed, 09 May 2018 13:25:10 -0000 PiAgICBQZXJoYXBzLCBidXQgaXQgc3RpbGwgYmVob292ZXMgdXMgdG8gd2FybiBpbXBsZW1lbnRv cnMgdGhhdCBhIHNpZ25pZmljYW50IHBlcmNlbnRhZ2Ugb2YgZW50ZXJwcmlzZSB0cmFmZmljIHdp bGwgYnJlYWsgd2l0aCB0aGlzIG1lY2hhbmlzbS4NCiAgDQpXaHkgZG8geW91IHRoaW5rIGEgc2ln bmlmaWNhbnQgcGVyY2VudGFnZSB3aWxsIGJyZWFrPyANCg0K From nobody Wed May 9 06:28: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 2AE271252BA for ; Wed, 9 May 2018 06:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[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 JR3lvfOmtCw3 for ; Wed, 9 May 2018 06:28:51 -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 87F72126BF3 for ; Wed, 9 May 2018 06:28:51 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id m11-v6so33934430otf.3 for ; Wed, 09 May 2018 06:28: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=ncVTuU7Fu2FF6KMKvtmkWacXvvSPvOdtQCJuvnhK6bY=; b=0rnkCZ4xWYjM4iffkGCCkOLga6Tq0MgGarO1jEsOUzc1IssamzV2IpFodCI1ZhKTiG H9Fj66zBbMs+7Z21NJpLygpXwzRv0gPTPCCIBqRPr8GEIEuKg2ee5iWVxKCkv/uBR5+M oOQZPvfmDHvHtDL++LsZzpmQgIVdkN/6u5IS26VTsmuUcpp7aAuRqRNFKt0QpPAamy25 NrGMcFRhGxPyI4U+H6CEcXryUQWqOTA52JQ0XyIbNrFr97at2nZj006XUFcZMwyogGIH 7C2BbAoTlpk/21OH7diCyB8Wp6L/SqCBtNe9JHEvESQNNOL8HaLmEy3FuTYfw9neqPAj mPuw== 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=ncVTuU7Fu2FF6KMKvtmkWacXvvSPvOdtQCJuvnhK6bY=; b=CkVNECkaA9Gldoyj9zW1z5i0F12Y0crArqpuD+eaTM6woXoOm12ZK9sOTIwVth8y7J VHmgLwKsKz1QGRhHaGndkb+brG5ixOmfj3+3l6JzMx+ddnhC01VOcBkIrVDufvzoRifj YcWI0qQRitw8z2l3tLfei1+5wMaVLeIauVnwYt5NUCsRkKeLi5FodMDOtNyWSCAlwdab GhTWKJSJzVqb0Twz07YwWYrjCm+ARRsHHWmgw9VnFvv4TVrbuPXtLe0bw/xuR9pl6/mE ZBOZJwHUZyS+GGGv6IIAWIUG+lIG9Zvuxxrg5Cz/nejlzNa94borMZkPP4Y/L0fQ600/ 7OZg== X-Gm-Message-State: ALQs6tCITvPZOVmL92G8ZPawL6d4bmSHhtFPX2dOn3kakqYkBB9Yixdg OM2GJqTJ6PAmbTSxtpEnYlDV1yZr+ZF35TSSLRlKfVfx X-Google-Smtp-Source: AB8JxZpG06zhYV98fJze41hKFqL6VuhSZPDaMsQNAh09SK+3SM4o9CWWV9xCUvpmZus1awjYh8bhWLn2jRdjJl95UeI= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr19131291otk.392.1525872530916; Wed, 09 May 2018 06:28:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Wed, 9 May 2018 06:28:10 -0700 (PDT) In-Reply-To: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> From: Eric Rescorla Date: Wed, 9 May 2018 06:28:10 -0700 Message-ID: To: Martin Thomson Cc: R du Toit , "" Content-Type: multipart/alternative; boundary="0000000000002d9a5e056bc5e280" 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: Wed, 09 May 2018 13:28:53 -0000 --0000000000002d9a5e056bc5e280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regardless of where it goes in the document, I think there's a real deployment consideration here: if you run this mechanism through a conventional MITM proxy, what will happen will be that the secondary cert auth will appear to just fail with a bogus signature. If clients respond to that by terminating the connection, then we're going to be in pretty bad shape [0]. So I think we either need: 1. To negotiate this with an extension 2. To tell people not to treat signature failures as a hard failure. 3. To have some way to indicate that there was a MITM on-path (e.g., have the application level mechanism include some separate value that's tied to the channel that lets the endpoints detect when its two separate channels). -Ekr [0] Note that this also applies to post-handshake authentication, but that's negotiated with an extension, so S 9.3 applies. On Wed, May 9, 2018 at 12:39 AM, Martin Thomson wrote: > This isn't really a security consideration though, it's a truism. A MitM > can break things that depend on end-to-end integrity of the connection. > On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote: > > > If the use of the mechanism is not negotiated on the TLS level then I > would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D sect= ion of the draft > could be amended to include a paragraph that warns potential implementors > that protocol-agnostic middleboxes will break the mechanism without any > clear failure indicators. > > > > On May 8, 2018, at 8:13 PM, Martin Thomson > wrote: > > > > > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: > > > > > >> I understand that there is not really anything to negotiate per se, > but > > > would it not be prudent to add a TLS extension to negotiate support f= or > > > exported-authenticator in the TLS layer prior to using it in the > > > application layer? > > > > > > We don't signal the potential need for exporters. I see no reason to > > > signal this either. Any signaling necessary really belongs at the > higher > > > layer. > --0000000000002d9a5e056bc5e280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regardless of where it goes in the document, I think = there's a real deployment
consideration here: if you run this= mechanism through a conventional MITM
proxy, what will happen wi= ll be that the secondary cert auth will appear to just
fail with = a bogus signature. If clients respond to that by terminating the connection= ,
then we're going to be in pretty bad shape [0]. So I think = we either need:

1. To negotiate this with an exten= sion
2. To tell people not to treat signature failures as a hard = failure.
3. To have some way to indicate that there was a MITM on= -path (e.g., have the
=C2=A0=C2=A0=C2=A0 application level mechan= ism include some separate value that's tied to
=C2=A0=C2=A0= =C2=A0 the channel that lets the endpoints detect when its two separate cha= nnels).

-Ekr


[0] Note that this also applies to post-handshake authentication, bu= t that's negotiated
with an extension, so S 9.3 applies.


On Wed, May 9, 2018 at 12:39 AM= , Martin Thomson <martin.thomson@gmail.com> wrote:
This isn't really a security considerat= ion though, it's a truism.=C2=A0 A MitM
can break things that depend on end-to-end integrity of the connection.
On Wed, May 9, 2018 at 11:25 AM Roe= lof duToit <r@nerd.ninja> wrote:

> If the use of the mechanism is not negotiated on the TLS level then I<= br> would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D sectio= n of the draft
could be amended to include a paragraph that warns potential implementors that protocol-agnostic middleboxes will break the mechanism without any
clear failure indicators.

> > On May 8, 2018, at 8:13 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
> >
> > On Wed, May 9, 2018 at 2:20 AM Roelof duToit <r@nerd.ninja>= wrote:
> >
> >> I understand that there is not really anything to negotiate p= er se, but
> > would it not be prudent to add a TLS extension to negotiate suppo= rt for
> > exported-authenticator in the TLS layer prior to using it in the<= br> > > application layer?
> >
> > We don't signal the potential need for exporters.=C2=A0 I see= no reason to
> > signal this either.=C2=A0 Any signaling necessary really belongs = at the
higher
> > layer.

--0000000000002d9a5e056bc5e280-- From nobody Wed May 9 09:17: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 49C10126C83 for ; Wed, 9 May 2018 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 hLzacgB8CFZU for ; Wed, 9 May 2018 09:17:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31169126C22 for ; Wed, 9 May 2018 09:17:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 139C2B80CB5; Wed, 9 May 2018 09:17:08 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, kaduk@mit.edu, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: loic.jonas.etienne@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180509161708.139C2B80CB5@rfc-editor.org> Date: Wed, 9 May 2018 09:17:08 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC5246 (5352) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 May 2018 16:17:10 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5352 -------------------------------------- Type: Technical Reported by: Loic Etienne Section: 6.2.3.3. Original Text ------------- struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCompressed.length]; }; } GenericAEADCipher; Corrected Text -------------- struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCiphertext.length]; }; } GenericAEADCipher; Notes ----- 6.2.3.3. says: "The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]". The definition is duplicated at A.1., and needs the same adjustment. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed May 9 10:14: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 A9D3412D955 for ; Wed, 9 May 2018 10:14:49 -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=[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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ6TvexbnR5b for ; Wed, 9 May 2018 10:14:48 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B6C12D94B for ; Wed, 9 May 2018 10:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525886083; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To; l=702; bh=qpoPm7NnkpnRpW9QFjEJTBkwgRLjLRLake+wohDan2k=; b=sMpnzT7Dx3Q8su+fQX37wkUras/Nj0VLIU6vDNTy84jGif0yVOXJs6no6vVGj/4o Q8xX8b58YGF+o1PacrzndZrWt/bsnMPNwLmztSdKgy/Vqnr2sO8lXb5QYFnOWM3ev3c oYlMH2MsxLnV8VbDlSx6OC46fRz4QxkqhCXM2iSw= Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525886083078361.94715216269753; Wed, 9 May 2018 10:14:43 -0700 (PDT) From: Roelof duToit Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 9 May 2018 13:14:38 -0400 To: "" X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 May 2018 17:14:50 -0000 In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning = alert before a TLS 1.3 (draft 26) ServerHello. Alert level is supposed = to be implicit in TLS 1.3, but in this case it is ambiguous. Should it = even be considered a =E2=80=9CTLS 1.3 alert=E2=80=9D given that it = arrives before the protocol version is confirmed?=20 TLS 1.3 draft section 6 states that "All the alerts listed in Section = 6.2 MUST be sent with AlertLevel=3Dfatal and MUST be treated as error = alerts regardless of the AlertLevel in the message=E2=80=9D. Is the = client supposed to remember that it received a warning level alert and = terminate after parsing the ServerHello? =E2=80=94Roelof From nobody Wed May 9 10:57: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 248D21270A3 for ; Wed, 9 May 2018 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[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 XPIvP6Bb13P7 for ; Wed, 9 May 2018 10:56:57 -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 2FC7B126E64 for ; Wed, 9 May 2018 10:56:57 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v2-v6so32295187oif.3 for ; Wed, 09 May 2018 10:56: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 :cc; bh=IyNqoVqZesvF0+w5QDM/QUGIsA0J2vQfTwHVhBnrIFw=; b=Ge3P3yuph+56+qxRQebhXf8VQSRNPHFOcJ6bhrdxtle26Xd0DJLVMOQBWOEjMustfi mUg/ksBnbCFUlXHG8iBlJkunSfbyRPYevjJV3Bdp0oNskj01hExH7Wmr01rlsUeT2wTx Oxf9iXXYECADuf1Wj/Tx/olvarTO3upg0uEwYp6OoZrkl8qtG+GPRV1PXKYPOGlRuHvN ppboNi9vJCNiZARw9ENHmAds4Zv0BxEa2qAQdhg3U6KHt1TTFj+u5KNCCVVLk4Bl7HdM AxDlxLydATmUPXX1I+mC6VU17UDg3a7TNJjb8SEBIwXgGNjJPVN5C5Gv/mMlefD4Q4JF YzPg== 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=IyNqoVqZesvF0+w5QDM/QUGIsA0J2vQfTwHVhBnrIFw=; b=kLiT1SxNrg6xXeRwPjusipwpjSPBVVFFJsp5Z5wXQGqXFUH/K3lE5Wvpzzxy8leQPu sbyZithriv45sqGiobBk8jTrN8gUgFkzBtV7bgwcUhZ1ljnyWuqDT22uIAGp1COGsIVy uHAOHrZey11mAgaiymS93o5gewtLKRX2C58MmVIgBbzISAwc8bM89vV9lfK8Xu9+/tLt khJtu0eP1ykuJl1dobYi68d5v9PnKwK+a7agiZOVLbByOBP5WTfEJzUt2Tibh0bYOEmn tBi0SUcbvO9iqC+p/n/yBX2wCW+WtQZQ82poNUy5E6z/GqM0ztPRh9bU1guoud65Td4n nGtA== X-Gm-Message-State: ALQs6tAi/VrzgfrpP6D91bHtBd/jB6oGPsmNOVVA8KDRzjg/l1GRZdt7 7+mQgZimoVC3ufmPNTOOEskxZ2HoiipeEIia5x5Jky/g X-Google-Smtp-Source: AB8JxZrcqSF0KW1jl6tENij0wkjrJZbFoQ8k/VT530AcXhGr4K+XD4M45MxlU34dw8lff+y19EVR2xx4nXh0ciU3hUE= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr29809959oin.108.1525888616415; Wed, 09 May 2018 10:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Wed, 9 May 2018 10:56:15 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 9 May 2018 10:56:15 -0700 Message-ID: To: Roelof duToit Cc: "" Content-Type: multipart/alternative; boundary="000000000000f2dadb056bc9a013" Archived-At: Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 May 2018 17:56:59 -0000 --000000000000f2dadb056bc9a013 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But it actually sends an SH? That seems odd and kind of an ambiguous point in the spec. -Ekr On Wed, May 9, 2018 at 10:14 AM, Roelof duToit wrote: > In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning > alert before a TLS 1.3 (draft 26) ServerHello. Alert level is supposed t= o > be implicit in TLS 1.3, but in this case it is ambiguous. Should it even > be considered a =E2=80=9CTLS 1.3 alert=E2=80=9D given that it arrives bef= ore the protocol > version is confirmed? > > TLS 1.3 draft section 6 states that "All the alerts listed in Section 6.2 > MUST be sent with AlertLevel=3Dfatal and MUST be treated as error alerts > regardless of the AlertLevel in the message=E2=80=9D. Is the client sup= posed to > remember that it received a warning level alert and terminate after parsi= ng > the ServerHello? > > =E2=80=94Roelof > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f2dadb056bc9a013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But it actually sends an SH? That seems odd and kind = of an ambiguous point in the spec.

-Ekr
<= div>

On Wed, May 9, 2018 at 10:14 AM, Roelof duToit <r@nerd.ninja> = wrote:
In one of our tests OpenSSL 1.1.1-= dev sends an unrecognized_name warning alert before a TLS 1.3 (draft 26) Se= rverHello.=C2=A0 Alert level is supposed to be implicit in TLS 1.3, but in = this case it is ambiguous.=C2=A0 Should it even be considered a =E2=80=9CTL= S 1.3 alert=E2=80=9D given that it arrives before the protocol version is c= onfirmed?

TLS 1.3 draft section 6 states that "All the alerts listed in Section = 6.2 MUST be sent with AlertLevel=3Dfatal and MUST be treated as error alert= s regardless of the AlertLevel in the message=E2=80=9D.=C2=A0 =C2=A0Is the = client supposed to remember that it received a warning level alert and term= inate after parsing the ServerHello?

=E2=80=94Roelof


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

--000000000000f2dadb056bc9a013-- From nobody Wed May 9 19:07: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 8D2241200C5 for ; Wed, 9 May 2018 19:07:51 -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 thEkr2gECL5H for ; Wed, 9 May 2018 19:07:49 -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 9F641129C70 for ; Wed, 9 May 2018 19:07:49 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id t1-v6so598128oth.8 for ; Wed, 09 May 2018 19:07:49 -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:content-transfer-encoding; bh=UnWmRwpZw3wsDIYvqfmEDMKZfjmx5mfPtfcVZK5exps=; b=q1xS97k2iTTH84Yl6IMKlMoMJlEgfipVkV2Xtmfg1FzWjBxlyFgRzy1R29pgqcimF+ pN4vIw3oCTUhA5KVpWQdYPn+3F1S2F7F15jUdeA1kQxJ6BnDulM4vQMa21oCIXZG7tRj BKQfv+Hjuc3Y+1539Z+nw3FpnoP/KWZawdpwOJkIaNwpSt8HuDxKuFFRHuN/mLuJNn+u R7FQpee/W2dPY7lL5EP/DtBOOM9FS8H3GE1Dq4S2reN9ImLbzA/oS7UFKEtS0dx3/ls2 Iq4vuat51+PT9pAqQ6QUCBFgjFPv+JiVpxMt2Nz246MU53VVoDkqcaXFCIs63tEAkCG9 0pHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UnWmRwpZw3wsDIYvqfmEDMKZfjmx5mfPtfcVZK5exps=; b=Ae0+gn65CJ9BIP7BIC49e7QLvGDdBGrPXKtMDfH0t9qvdew875x9XyQQtHkDin98gS tzFRaIzB3tFkLYoAMDC7FYaPHYOZCKudyeTLeCiIkdmMajmu4huaATv0y/efsxZEdYj+ 0aqs+tZASzgdk3tIuJAsS7zYckHP9NPb79TlY8kL+X5HulcLdR9eB1BpoSsxNC7PBakG DzR6BWgkofWqi7NajSY46pSwBjx4jOb1M4CUkQbkLdholZhytgkAGClMr0Qkl+k7gMhF eLeD80K4YAWGZI3C7DQM1YpP04+pTv3eP6eoWeyMsVftE+Ab3l008E+mOY9PvvTFlIsJ fleg== X-Gm-Message-State: ALQs6tCl1qxYWuZykhIp7va0PkGba1feKnG8OvEJJHgqNT3RnCYvEWn7 CO5yattYFs5nsTcb5d0fBdYpEoxu+RUnjGp6U8OWPA== X-Google-Smtp-Source: AB8JxZrPb1JMMP8+i1xJbDQiNygf0fLfi67ua9TBS7Vn5w4ixWdCq6ljyII26w82crNZ9uLPG/ZNgVsyutJUveQmzVA= X-Received: by 2002:a9d:3a65:: with SMTP id j92-v6mr36980610otc.352.1525918068396; Wed, 09 May 2018 19:07:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Thu, 10 May 2018 02:07:37 +0000 Message-ID: To: Eric Rescorla Cc: r@nerd.ninja, "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 02:07:51 -0000 This alert is actually fairly common (though I'm surprised to see OpenSSL still doing it) and clients need to handle it, unfortunately. Before the client has any confirmation that it is doing TLS 1.3, it has to assume that the server is any TLS version. Of course, if the client isn't prepared to negotiate earlier versions, it might choke on that alert based on the TLS 1.3 alert handling roles, so the server shouldn't really be sending it. If the spec is still available for changes, it's probably worth mentioning this issue. I forgot to check the spec when I made/reviewed the corresponding change in NSS. On Thu, May 10, 2018 at 3:57 AM Eric Rescorla wrote: > But it actually sends an SH? That seems odd and kind of an ambiguous point in the spec. > -Ekr > On Wed, May 9, 2018 at 10:14 AM, Roelof duToit wrote: >> In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning alert before a TLS 1.3 (draft 26) ServerHello. Alert level is supposed to be implicit in TLS 1.3, but in this case it is ambiguous. Should it even be considered a =E2=80=9CTLS 1.3 alert=E2=80=9D given that it arrives befor= e the protocol version is confirmed? >> TLS 1.3 draft section 6 states that "All the alerts listed in Section 6.2 MUST be sent with AlertLevel=3Dfatal and MUST be treated as error alert= s regardless of the AlertLevel in the message=E2=80=9D. Is the client suppo= sed to remember that it received a warning level alert and terminate after parsing the ServerHello? >> =E2=80=94Roelof >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 9 19:16: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 5C8D6129C70 for ; Wed, 9 May 2018 19:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DKuECBjwXYEy for ; Wed, 9 May 2018 19:16:01 -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 7B06512708C for ; Wed, 9 May 2018 19:16:01 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id g7-v6so610067otj.11 for ; Wed, 09 May 2018 19:16:01 -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:content-transfer-encoding; bh=jupn8MVKKhEn85mkCriEMNCWZj6nVZg+sv6GlaJ5Taw=; b=oqg5RzQEuKh7CrZOGg9D2AZPdbrq81/tHBi1CzMjBnSsWJnbspp8fZ4LaaYG5Qiihi gom2fBVwIoA8svik09V/KSfnrjzC3rzJ+Udgti80NmXa/7SuJSSoGM4yZy6BSzERAAQT VdTHJjDKaJLzB+rOmamrzk2hgbwIsKIOkpkuyNfbewByrqJ2AxfqqjnZrmvmRQD/8089 aJVoytyeAq6LxgmQvNMmNZcDoOIrdhvkneoxSrCS1mpFecHPusDnx1DxHFjgCcIu4cbw qP2UJn8TtUlMTPIGt8ygzgpUyTqZ50rRT5i58n5HRpYThhPYF59XFnHu3c1f8kLjvnOq Bi7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jupn8MVKKhEn85mkCriEMNCWZj6nVZg+sv6GlaJ5Taw=; b=mk6esDkhmKoE8bcvrQYTJ6Ip1yFKKxRVA+SiGvMxvJPv6UZMMHQ0AeNg2Uae3q7gQV C1M0+0PrNLsVr0qz5ZVoNVnKSgNNy3hxglNjNDPTiGEiWPmsyaJXzvDzAXuf9l8XPCbJ kMtu5ocubUapTnZh8+30KipLc7Px3M9z5JhhiJORdPmcldtqZGs5MkvtcOMmYN79h6tN ol9B6uv1CEAsF44YO1Y6fGrvaS34AcRVMGSDY2cElbCzieJzE059zzCJv+7bS1KeDyH7 KLSmxkQMv0XdehImwMoHtNGzzXrvkPk9cQTXFJoFC3Z3AqvGmHHNdf9oP8mFctVglp0k 17Ng== X-Gm-Message-State: ALQs6tC2nap3WKs05L13HWejPNFNITgnKNLZZBn1FMQTU+SQSC7nBn+F 8AFWxwwEszcLJlx8+BPSbRKrRVnvZxyOgNu0VcA= X-Google-Smtp-Source: AB8JxZqcGvXKB/8E0V2tjWVKlK9uD0HMlIF5G0h8Lye2YYREx3cRBOiK7okRg4n91YYd8U3Rv6EeNZxWhLiQNuZsEQA= X-Received: by 2002:a9d:354a:: with SMTP id l10-v6mr7741757ote.15.1525918560831; Wed, 09 May 2018 19:16:00 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> In-Reply-To: From: Martin Thomson Date: Thu, 10 May 2018 02:15:50 +0000 Message-ID: To: Eric Rescorla Cc: r@nerd.ninja, "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 10 May 2018 02:16:06 -0000 I'm not that concerned about this, though I will concede that it's worth pointing out. Failing to validate a secondary certificate for a server shouldn't be cause for terminating an otherwise usable connection. The same goes for clients that authenticate using this. As long as users of exported authenticators are aware of this, then they can design for it. If those users wanted confirmation, then we could provide a confirmation-of-mechanism-viability in the application layer. That could just be by including a value derived from the exporter in the negotiation. In h2, we could do as much as 4 octets of confirmation for cheap, and maybe we should. https://github.com/httpwg/http-extensions/issues/617 On Wed, May 9, 2018 at 11:28 PM Eric Rescorla wrote: > Regardless of where it goes in the document, I think there's a real deployment > consideration here: if you run this mechanism through a conventional MITM > proxy, what will happen will be that the secondary cert auth will appear to just > fail with a bogus signature. If clients respond to that by terminating the connection, > then we're going to be in pretty bad shape [0]. So I think we either need= : > 1. To negotiate this with an extension > 2. To tell people not to treat signature failures as a hard failure. > 3. To have some way to indicate that there was a MITM on-path (e.g., have the > application level mechanism include some separate value that's tied = to > the channel that lets the endpoints detect when its two separate channels). > -Ekr > [0] Note that this also applies to post-handshake authentication, but that's negotiated > with an extension, so S 9.3 applies. > On Wed, May 9, 2018 at 12:39 AM, Martin Thomson wrote: >> This isn't really a security consideration though, it's a truism. A Mit= M >> can break things that depend on end-to-end integrity of the connection. >> On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote: >> > If the use of the mechanism is not negotiated on the TLS level then I >> would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D sec= tion of the draft >> could be amended to include a paragraph that warns potential implementor= s >> that protocol-agnostic middleboxes will break the mechanism without any >> clear failure indicators. >> > > On May 8, 2018, at 8:13 PM, Martin Thomson >> wrote: >> > > >> > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: >> > > >> > >> I understand that there is not really anything to negotiate per se, but >> > > would it not be prudent to add a TLS extension to negotiate support for >> > > exported-authenticator in the TLS layer prior to using it in the >> > > application layer? >> > > >> > > We don't signal the potential need for exporters. I see no reason t= o >> > > signal this either. Any signaling necessary really belongs at the >> higher >> > > layer. From nobody Wed May 9 19:18: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 905DC129C70 for ; Wed, 9 May 2018 19:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cbuH4zOTJtj for ; Wed, 9 May 2018 19:17:57 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0303812708C for ; Wed, 9 May 2018 19:17:57 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id a6-v6so490569oia.2 for ; Wed, 09 May 2018 19:17:56 -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=GmtyrmKF8fSqE4q0KSOGqiQJxXZB5GCuYzMj+Job1pI=; b=uATMpdonD40d1JWWUdHjeiCr4VX4FDOWiV24FNt2pd+zewSnNz9b7Ar5iNBiclnVih ueK6ReWIi2+EdURzSCJ2tF7A7TvY5lCof521fbt9XU492Vacdr+VUJnZjhZIh0Kqo6Qh btuHSr/Hk9Ip1zgE18L2JAiejAhwVdQfQsdqzJefX69pX/zJ2P/01qBd+mrM1Kbz8sEa +Fgl3+7Nk7nxaNp6V4r+jjOURkePcfSvLe80DTZrp1cKMZWPgfEd07I5/61knOn3iiHX beUHlJIW65bbW23N7ekz9sgqq8HEYw92GSWRhIRDrzleQclQFLz2VD5wN+fiDjywV2bC vYAA== 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=GmtyrmKF8fSqE4q0KSOGqiQJxXZB5GCuYzMj+Job1pI=; b=jKcRdhNkig7D1H8wRrzgUT03moJKHqYln3YBqX38VzReI3oYY1PZ3j0eU/F1yOj555 Gk3X7Rj0MmT/ekvCVZnqC2M3DJnsiStE5FSS0shKIO0uIABHcjJTouWYuNw+wCy26O9y HanWvQO/eDq9/49X91sfnMf5KvmbM1SrHoTzq6QBDzDCQJhpfwkestDSIMO/i29EwHbp nGrRctBSI5oKALgoEe1HsoOtn1B5pqFdX7FcmCN9kVk3igSGiR2tWu/cX6Ihmhxc6Zd8 9pJ3vyY3MO/bnMaLA9eJkdiDKWpX8Zfn/uepciy8zTmN7r7jmjKnfHdWTR+H5ZRHGJOw JhmQ== X-Gm-Message-State: ALQs6tBEjRwyYe/bGshL4l0Uc/YRMSrMIupWqMRpLFkirw2cqmNogQpq 9MHn7iQzh4tdKbnKsIJ1mZMym5YKLAf7SnidEG8= X-Google-Smtp-Source: AB8JxZoFv5rddpVEc2wQ0lRPIHaTzOQbgaDVDghEzs/d1+ykPkp9lHrthtTTn51DgheCIuCZKT3jj9ZcY4n6qwiGS0k= X-Received: by 2002:aca:ab46:: with SMTP id u67-v6mr31122623oie.272.1525918676240; Wed, 09 May 2018 19:17:56 -0700 (PDT) MIME-Version: 1.0 References: <20180509161708.139C2B80CB5@rfc-editor.org> In-Reply-To: <20180509161708.139C2B80CB5@rfc-editor.org> From: Martin Thomson Date: Thu, 10 May 2018 02:17:45 +0000 Message-ID: To: RFC Errata System Cc: tim@dierks.org, Eric Rescorla , Benjamin Kaduk , Joseph Salowey , sean+ietf@sn3rd.com, "" , loic.jonas.etienne@gmail.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5352) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 02:17:59 -0000 Reject. The text refers to the output of the AEAD. The contents of the "aead-cipher struct" are the inputs. On Thu, May 10, 2018 at 2:17 AM RFC Errata System wrote: > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5352 > -------------------------------------- > Type: Technical > Reported by: Loic Etienne > Section: 6.2.3.3. > Original Text > ------------- > struct { > opaque nonce_explicit[SecurityParameters.record_iv_length]; > aead-ciphered struct { > opaque content[TLSCompressed.length]; > }; > } GenericAEADCipher; > Corrected Text > -------------- > struct { > opaque nonce_explicit[SecurityParameters.record_iv_length]; > aead-ciphered struct { > opaque content[TLSCiphertext.length]; > }; > } GenericAEADCipher; > Notes > ----- > 6.2.3.3. says: "The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]". > The definition is duplicated at A.1., and needs the same adjustment. > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 9 20:48: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 95C0812E8D4 for ; Wed, 9 May 2018 20:47: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 6U7nXdDIfDOL for ; Wed, 9 May 2018 20:47: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 D027D12E8B1 for ; Wed, 9 May 2018 20:47: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 9292E7A3309 for ; Thu, 10 May 2018 03:47: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, 9 May 2018 23:47:52 -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] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 03:47:59 -0000 > On May 9, 2018, at 10:07 PM, Martin Thomson = wrote: >=20 > This alert is actually fairly common (though I'm surprised to see = OpenSSL > still doing it) and clients need to handle it, unfortunately.=20 I may be misreading the code, but it sure looks like the alert is only sent if the application callback for the server name extension asks OpenSSL to do that. The application can just decline the extension and let the handshake continue with a default certificate... Is the surprise that the alert is sent, or that it is a warning, or something else? --=20 --=20 Viktor. From nobody Wed May 9 21:07: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 5E8CC12E8D4 for ; Wed, 9 May 2018 21:07:26 -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 bVzT_7VQiZXm for ; Wed, 9 May 2018 21:07:24 -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 07BF812E8D7 for ; Wed, 9 May 2018 21:07:24 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id y10-v6so821270otg.10 for ; Wed, 09 May 2018 21:07:24 -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=lq6Kq1mhe5leVWSNQ/uxMa/H8d0iC/iK+b64nNUEjBE=; b=kbGtbkgP38HhsOipISEdJ0plvO3yLGhZcDL6RRY7Du5xeJPpCb7Cc/O963s9Nruj0i nfR697lCFDDH2IOsInClj1KlDhfZz4/rMx6Nt/47Pi3XBaIHwfhrRrzL8M92y17QAyhs T9DZU3N3rv1G63tcoJHGVcgjDJDXmy2qcjupTyvGBeNxzUP4agiq1cNu1QupX9qTLtoO 3j4dCpKOf6jRXRsB1pgtcyJ9HnvZrGUlFhipivQptdru3BL/cOZLD8mCbXvdrxoOL4A9 tyNlVG2tmlpZyvO717b2yxBwHD1uQnOE+ggHbnZYzEUdNlPpIjACqWAaV7C0c763Gjkr P7EA== 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=lq6Kq1mhe5leVWSNQ/uxMa/H8d0iC/iK+b64nNUEjBE=; b=Dw2el+w4+2s2CtzqzdAief0GIWH+u/cqFC64oe6ae0AKHPYEcM5iIMFlBABbDjViIr u0LDlRJn8K83nykzEwxVeIfONyGdm9n7PxEIP2aofxOkSzuvUfH5Hu+sgAnrp928GVZj 7nH4J7y5j/eLJvJwCCEBNBlDqfqivfu0AvYnpWtnP31SNlrHhQ8ONoszGAflyTMkR7Xh MKC3woUMuYEQW+7rHDfhhsWs4QtFBFaX3DDagGLj+JZeFJYjeWsAgQjJJgQRuIqTGNPu CbLWxx2ySJ8qsSeAMpY9UwWZnA3xgeo3YAPlYZC9zYYFrziCknQQun73SxiWPlPBKUWe vK7g== X-Gm-Message-State: ALKqPwecgK8h8e/JDy16fB6QeIy1e2dPO15NRaGK2l3FOQ5Ic8NTXA2j bnupcFOtJkF2yx8o2zbSlWHjXCd1ZpkppZohbkU5VQ== X-Google-Smtp-Source: AB8JxZpfDvEur+OWW8c63HE44rd3+22SXV9HYZq6vfd+uyRD/+oYUR4T0qyaFT8qrozK700IFNJ5tMAoux3+6vw/c3w= X-Received: by 2002:a9d:3694:: with SMTP id h20-v6mr7577235otc.176.1525925243429; Wed, 09 May 2018 21:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Wed, 9 May 2018 21:06:42 -0700 (PDT) In-Reply-To: References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja> From: Eric Rescorla Date: Wed, 9 May 2018 21:06:42 -0700 Message-ID: To: Martin Thomson Cc: R du Toit , "" Content-Type: multipart/alternative; boundary="00000000000016b93e056bd228be" 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: Thu, 10 May 2018 04:07:26 -0000 --00000000000016b93e056bd228be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 9, 2018 at 7:15 PM, Martin Thomson wrote: > I'm not that concerned about this, though I will concede that it's worth > pointing out. > > Failing to validate a secondary certificate for a server shouldn't be cau= se > for terminating an otherwise usable connection. To be clear: it's not failing to validate the *certificate* it's that the CertificateVerify to validate. This should ordinarily never happen, so I definitely think we should call that out. -Ekr The same goes for clients > that authenticate using this. As long as users of exported authenticator= s > are aware of this, then they can design for it. > > If those users wanted confirmation, then we could provide a > confirmation-of-mechanism-viability in the application layer. That could > just be by including a value derived from the exporter in the negotiation= . > > In h2, we could do as much as 4 octets of confirmation for cheap, and may= be > we should. > https://github.com/httpwg/http-extensions/issues/617 > On Wed, May 9, 2018 at 11:28 PM Eric Rescorla wrote: > > > Regardless of where it goes in the document, I think there's a real > deployment > > consideration here: if you run this mechanism through a conventional MI= TM > > proxy, what will happen will be that the secondary cert auth will appea= r > to just > > fail with a bogus signature. If clients respond to that by terminating > the connection, > > then we're going to be in pretty bad shape [0]. So I think we either > need: > > > 1. To negotiate this with an extension > > 2. To tell people not to treat signature failures as a hard failure. > > 3. To have some way to indicate that there was a MITM on-path (e.g., ha= ve > the > > application level mechanism include some separate value that's tie= d > to > > the channel that lets the endpoints detect when its two separate > channels). > > > -Ekr > > > > [0] Note that this also applies to post-handshake authentication, but > that's negotiated > > with an extension, so S 9.3 applies. > > > > On Wed, May 9, 2018 at 12:39 AM, Martin Thomson < > martin.thomson@gmail.com> > wrote: > > >> This isn't really a security consideration though, it's a truism. A > MitM > >> can break things that depend on end-to-end integrity of the connection= . > >> On Wed, May 9, 2018 at 11:25 AM Roelof duToit wrote: > > >> > If the use of the mechanism is not negotiated on the TLS level then = I > >> would appreciate it if the =E2=80=9CSecurity Considerations=E2=80=9D s= ection of the > draft > >> could be amended to include a paragraph that warns potential > implementors > >> that protocol-agnostic middleboxes will break the mechanism without an= y > >> clear failure indicators. > > >> > > On May 8, 2018, at 8:13 PM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >> > > > >> > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit wrote: > >> > > > >> > >> I understand that there is not really anything to negotiate per s= e, > but > >> > > would it not be prudent to add a TLS extension to negotiate suppor= t > for > >> > > exported-authenticator in the TLS layer prior to using it in the > >> > > application layer? > >> > > > >> > > We don't signal the potential need for exporters. I see no reason > to > >> > > signal this either. Any signaling necessary really belongs at the > >> higher > >> > > layer. > --00000000000016b93e056bd228be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 9, 2018 at 7:15 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
I'm = not that concerned about this, though I will concede that it's worth pointing out.

Failing to validate a secondary certificate for a server shouldn't be c= ause
for terminating an otherwise usable connection.=C2=A0

=
To be clear: it's not failing to validate the *certificate* = it's that the CertificateVerify
to validate. This should = ordinarily never happen, so I definitely think we should
call tha= t out.

-Ekr

The same goes for clients
that authenticate using this.=C2=A0 As long as users of exported authentica= tors
are aware of this, then they can design for it.

If those users wanted confirmation, then we could provide a
confirmation-of-mechanism-viability in the application layer.=C2=A0 Th= at could
just be by including a value derived from the exporter in the negotiation.<= br>
In h2, we could do as much as 4 octets of confirmation for cheap, and maybe=
we should.
https://github.com/httpwg/http-extensions/i= ssues/617
On Wed, May 9, 2018 at 11:28 PM Eri= c Rescorla <ekr@rtfm.com> wrote:<= br>
> Regardless of where it goes in the document, I think there's a rea= l
deployment
> consideration here: if you run this mechanism through a conventional M= ITM
> proxy, what will happen will be that the secondary cert auth will appe= ar
to just
> fail with a bogus signature. If clients respond to that by terminating=
the connection,
> then we're going to be in pretty bad shape [0]. So I think we eith= er need:

> 1. To negotiate this with an extension
> 2. To tell people not to treat signature failures as a hard failure. > 3. To have some way to indicate that there was a MITM on-path (e.g., h= ave
the
>=C2=A0 =C2=A0 =C2=A0 application level mechanism include some separate = value that's tied to
>=C2=A0 =C2=A0 =C2=A0 the channel that lets the endpoints detect when it= s two separate
channels).

> -Ekr


> [0] Note that this also applies to post-handshake authentication, but<= br> that's negotiated
> with an extension, so S 9.3 applies.


> On Wed, May 9, 2018 at 12:39 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

>> This isn't really a security consideration though, it's a = truism.=C2=A0 A MitM
>> can break things that depend on end-to-end integrity of the connec= tion.
>> On Wed, May 9, 2018 at 11:25 AM Roelof duToit <r@nerd.ninja>= wrote:

>> > If the use of the mechanism is not negotiated on the TLS leve= l then I
>> would appreciate it if the =E2=80=9CSecurity Considerations=E2=80= =9D section of the draft
>> could be amended to include a paragraph that warns potential imple= mentors
>> that protocol-agnostic middleboxes will break the mechanism withou= t any
>> clear failure indicators.

>> > > On May 8, 2018, at 8:13 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>> > >
>> > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit <r@nerd.= ninja> wrote:
>> > >
>> > >> I understand that there is not really anything to ne= gotiate per se,
but
>> > > would it not be prudent to add a TLS extension to negoti= ate support
for
>> > > exported-authenticator in the TLS layer prior to using i= t in the
>> > > application layer?
>> > >
>> > > We don't signal the potential need for exporters.=C2= =A0 I see no reason to
>> > > signal this either.=C2=A0 Any signaling necessary really= belongs at the
>> higher
>> > > layer.

--00000000000016b93e056bd228be-- From nobody Wed May 9 21:10: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 27C4512E8D8 for ; Wed, 9 May 2018 21:10:51 -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 xgGm1gDgLhCs for ; Wed, 9 May 2018 21:10:50 -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 E51F612E8D4 for ; Wed, 9 May 2018 21:10:49 -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 2079F7A3309 for ; Thu, 10 May 2018 04:10:49 +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: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> Date: Thu, 10 May 2018 00:10:40 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 04:10:51 -0000 TLS 1.3 allows clients to send multiple PSK identities, with the server choosing one. When, if every, might it make sense for the client to send multiple session tickets to the server? If this is not expected, is it sufficiently odd for a server to ignore any tickets after the first (if that one is not usable)? -- Viktor. From nobody Wed May 9 23:05: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 BCF27127078 for ; Wed, 9 May 2018 23:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VP4wMg_bBKa for ; Wed, 9 May 2018 23:05:30 -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 2318D126CE8 for ; Wed, 9 May 2018 23:05:30 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id g7-v6so1048783otj.11 for ; Wed, 09 May 2018 23:05: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; bh=b8/Lm8FSL05vCm0nu6U3uTRZa62A+gcIoElDrJv9myI=; b=bJuB/Xy8rvHWyONg3KEl4F+8Pw+myEDQvS40aI2X86EbBlsR1IxEV5Rof2+5Mf5lcN sTOUE49BMzQAIgG9cuMRpVtle7W0M/d/TT83E8nTb1xY6DZwvhWqQC7i0yJcqFwNwIV6 wf9UJZSmL8WdZyU1Q4tX7qc39hHIQ6RhkSFDB4IPQeK3gkJL5XkFK8lydLyf8JFWn9lR Zgf60TgbwgIkADyUL7Bh7v5TgVaj/pPRSZHUtvsGKy6A3QrlOfit+MBUGd7l1W5tRrrx 0DFXd6sRTD3pioojFDsxyNIFFucmU5YmhLL4zcmrF9J6uHSAgyLLBzROQvz2wiNXiaY6 gL4w== 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=b8/Lm8FSL05vCm0nu6U3uTRZa62A+gcIoElDrJv9myI=; b=tLN6nBbPvIWzP/ylOGZerYq9QKmKT1DRXcjPIDHGAJyzdeZgDKHg0M0R/bR/OKJpYR vHVzmMhT68Ue74F//fqqQFS8f13g28k5XzxcDs/gW+YOqTSGYpX1OQkrajz1zNAKoKsb 6UoeK3K7xoe5KBLwOHWxI9wzsDaBDh4F36LJfeJvp1jflEqanjvY5mMaD+4ucH2k1fwg pY8mM0kuThj7/RaQrk2hRFN44Scq6/WWIDVwQeX6Iek7tpxUDgPVsX0REz0AJdAHBIKb 5dsKKlFhDmsvp4hms3vn48vgsIABb0nhyAMTGxKguG3+wUKhQiO267Zm489XWd6xKwbq 5wxA== X-Gm-Message-State: ALKqPwfGUherxD0DfRbYuxe8FQkBn+JftiveaAjAf6pOo0VSjAI04sTk MqpPikm67k2w4NzN4E6Sl547x+Pu3rZaSCInYW6nXg== X-Google-Smtp-Source: AB8JxZrQ0W5OXJcJKDLJkhziP1islJ/2RR3LksqxHxbwlevn/4+p1G3eY4uq96A7FaLszPzDXEOXs4c6KdWS0MIZqIE= X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr53645otg.241.1525932329094; Wed, 09 May 2018 23:05:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Thu, 10 May 2018 06:05:18 +0000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 06:05:32 -0000 On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni wrote: > I may be misreading the code, but it sure looks like the alert is only > sent if the application callback for the server name extension asks > OpenSSL to do that. The application can just decline the extension > and let the handshake continue with a default certificate... Is > the surprise that the alert is sent, or that it is a warning, or > something else? It's risking a failed connection. Though perhaps not that much more than providing the client with a certificate it might not like. From nobody Thu May 10 02:23: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 2CDD4127286 for ; Thu, 10 May 2018 02:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsDsKFfVQLF1 for ; Thu, 10 May 2018 02:23:26 -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 9963B127241 for ; Thu, 10 May 2018 02:23:26 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k17-v6so1190630oih.5 for ; Thu, 10 May 2018 02:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zREnu6AB8pLppGwSKd1twgxO1WkZYGnMJrSqggfYu88=; b=Q2pab1zPIOtQVx9Nlz+ThlqvSfQD3ZWEhPOQ/h90NTC8yaDJfo9N0BFJJKswoNvIRL EEIdjylQilMhiZz9H4DYPjP+NJCqmqjh40OoIvc/O5L1IFlkZIZHS4PZ7hXr4vxHkhq8 ZSRcYUAterjEG/kHfhHOznk/IAP1u3kEV8p+I6yRwx/RPN+QveO9rBtsZxUsyQsJu2X2 Ov7tHywX6T6b1ODGiHrVwKm0ZSzVhH/LhFKgYl7ghtj+1MaOe3gUEt1vDN2eVMYjEbGi Y/Va2Ntv5GKMohgN+JcRUpKya0q8dSpii2on7ytgdjIT+MUhjUl4idf83aM9r2/QxxY1 lq6Q== 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=zREnu6AB8pLppGwSKd1twgxO1WkZYGnMJrSqggfYu88=; b=BG7i6fMweimlm3QwwgIebUIvDkN5sHg5Oet8lKKbjJOtkw8bLQ4hCio6LCS6QrOmZd Xq5Eo725vnylyNFr3C8FLeHg3/wadLc+MG4ORjYT1vAPExJkwLADKSNFDw1mHMHRn4El cDtzCuMKnLd7wU9jE6k8iQaQ9H8AzxdihA4HjG4sTrs19cS0g3mHbCoHZEeraiSKJgeP UdY6kSG3TKkH+PmUy5fkjHtzARTaFu2769scw/GC3+hhwNu/hzqPaLpPFEOiRSXbtVJw QOwCa8Mm88/Hy8Wyhd0KSyFJ5AFa22aedkCF+d+jlU4O+6FmtVacwZ/Kx1RZa8iwCaUf 5N6g== X-Gm-Message-State: ALKqPwcOsrVWkBYG58YwpJsbfzpZJDrAsskcy7iQZGb8v7FKsP3rGe1d 14zzwrCaxnwc4HeZKHSyftEIbnhP1Xi7rXAFo/RRMikE X-Google-Smtp-Source: AB8JxZrC6ct+VzmlpJ57HS6akKgxlvD5KDdvNOapcpAMkfCcrMJ6aYscnhIjQtHG7D4LyD09vnMpTkBglQCp4kpqju8= X-Received: by 2002:aca:3905:: with SMTP id g5-v6mr319037oia.215.1525944205653; Thu, 10 May 2018 02:23:25 -0700 (PDT) MIME-Version: 1.0 References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> In-Reply-To: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> From: Martin Thomson Date: Thu, 10 May 2018 09:23:14 +0000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 09:23:28 -0000 On Thu, May 10, 2018 at 2:11 PM Viktor Dukhovni wrote: > TLS 1.3 allows clients to send multiple PSK identities, with the server > choosing one. When, if every, might it make sense for the client to > send multiple session tickets to the server? If this is not expected, > is it sufficiently odd for a server to ignore any tickets after the > first (if that one is not usable)? NSS only looks at the first PSK offered by clients. That is because we primarily use PSK for session resumption. I think that others do the same. I don't think that it makes a whole lot of sense to attempt to use multiple PSKs in the context of resumption. The option for multiple PSKs is something that is used in pure PSK modes, but I confess to not fully understanding the reasons you might use multiple PSKs. I suspect that they are most useful during a key rollover. From nobody Thu May 10 04:49: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 EA764124BE8 for ; Thu, 10 May 2018 04:49: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=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 b3vHJCB1Ru34 for ; Thu, 10 May 2018 04:49:08 -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 2C57B124D37 for ; Thu, 10 May 2018 04:49:08 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id h8-v6so1961413otb.2 for ; Thu, 10 May 2018 04:49:08 -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=tWWUN8o3ojwydEhd9Wbay85K3IkCKV7qFsyliBaQG9o=; b=AN0foqu4kN6scwMN2k/g945cZLiBqDTp/jZR+jufh0dW1KV5idiX8ukjLXtNsovWPo SttDiYvUHMM8KiP02brW335/EGNBMyfXSSc5T63FPkQz9bnkvM/qoo9AP1LeYbDyjy5r b50aLOFeuo1dDx0Nz1+Nsfg9OLTo6TJY71HkZmk6OlalLIcYzLV6fiPGW+TxZMrOzkt6 dniQpl/ipq4qo8UuDjx9PpQH3MO+TMcZPewaum1yYfRAzJvgLtXFuRvSiLr1SRNo5gDe /4ZhK2Obl+afOar08zqyubpM9Yerp+xNKwgbWHESOq91v7TUBunGCD6GW8ZsnPqazXn9 YuPw== 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=tWWUN8o3ojwydEhd9Wbay85K3IkCKV7qFsyliBaQG9o=; b=eGTxhbG792uYC7y5F/EDQKVzgO4UopBeR/koc5kwzl21vHYLmck2XiXnKwPHFXoMlM hanZ7XmeiydjsDOWrvtYVN0KQxz5Waeqci56h/mJC9OLb/V3OVuzl9kpd1OW8tX++Y+t vtFwU3tYvfF3bCUQFu3FBG3P/yBq5iMivklemvpxekH9nX3Eg20A0mr0SzJysvi3fPjV zdWMaD1XsfP317Qy9ggvV2MIYssFhufmy4PUl0PxEqD674dGX5yfIVBNaa63YhpKqBvH lv/ywVCIe8rQPcwcGlSybNDJKPzqxkrfWYgYK10oJcJIs514hyjZzpEZBBRsUuW8NYAi z78A== X-Gm-Message-State: ALKqPweZjEtBfuocCCe8mJaypHL3pW524E7OVgTcXqeaSMy3theHleIf H2hQ8SuwnJXOZhZEpWggaT3PXhR8m7qRbsHlbgE2sg== X-Google-Smtp-Source: AB8JxZr/kUXMr+7LKsYofgBUR3RI1rCt57DBR30kPSfKicN/BNFXO2NztG0j0gZFH1Qa6py5HCsDsW4yCeuFLVRBKYw= X-Received: by 2002:a9d:5917:: with SMTP id t23-v6mr704116oth.217.1525952947521; Thu, 10 May 2018 04:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 10 May 2018 04:48:26 -0700 (PDT) In-Reply-To: References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> From: Eric Rescorla Date: Thu, 10 May 2018 04:48:26 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000619bcd056bd89bd7" Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 11:49:10 -0000 --000000000000619bcd056bd89bd7 Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 2:23 AM, Martin Thomson wrote: > On Thu, May 10, 2018 at 2:11 PM Viktor Dukhovni > wrote: > > TLS 1.3 allows clients to send multiple PSK identities, with the server > > choosing one. When, if every, might it make sense for the client to > > send multiple session tickets to the server? If this is not expected, > > is it sufficiently odd for a server to ignore any tickets after the > > first (if that one is not usable)? > > NSS only looks at the first PSK offered by clients. That is because we > primarily use PSK for session resumption. I think that others do the > same. I don't think that it makes a whole lot of sense to attempt to use > multiple PSKs in the context of resumption. > > The option for multiple PSKs is something that is used in pure PSK modes, > but I confess to not fully understanding the reasons you might use multiple > PSKs. I suspect that they are most useful during a key rollover. > Also, resumption of sessions created with PSKs -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000619bcd056bd89bd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 10, 2018 at 2:23 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On Thu, = May 10, 2018 at 2:11 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:
> TLS 1.3 allows clients to send multiple PSK identitie= s, with the server
> choosing one.=C2=A0 When, if every, might it make sense for the client= to
> send multiple session tickets to the server?=C2=A0 If this is not expe= cted,
> is it sufficiently odd for a server to ignore any tickets after the > first (if that one is not usable)?

NSS only looks at the first PSK offered by clients.=C2=A0 That is be= cause we
primarily use PSK for session resumption.=C2=A0 I think that others do the<= br> same.=C2=A0 I don't think that it makes a whole lot of sense to attempt= to use
multiple PSKs in the context of resumption.

The option for multiple PSKs is something that is used in pure PSK modes, but I confess to not fully understanding the reasons you might use multiple=
PSKs.=C2=A0 I suspect that they are most useful during a key rollover.
<= /blockquote>

Also, resumption of sessions created with P= SKs

-Ekr


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

--000000000000619bcd056bd89bd7-- From nobody Thu May 10 06:46: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 37A95124217 for ; Thu, 10 May 2018 06:46: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 4p-n_7lu1ZMP for ; Thu, 10 May 2018 06:46: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 7F93C12EAD4 for ; Thu, 10 May 2018 06:46:46 -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 586A57A3309 for ; Thu, 10 May 2018 13:46: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: Date: Thu, 10 May 2018 09:46:44 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 13:46:49 -0000 > On May 10, 2018, at 7:48 AM, Eric Rescorla wrote: > > The option for multiple PSKs is something that is used in pure PSK modes, > but I confess to not fully understanding the reasons you might use multiple > PSKs. I suspect that they are most useful during a key rollover. > > Also, resumption of sessions created with PSKs So I am not hearing any intent to support multiple resumption PSKs (session tickets) in the same handshake. How are TLS 1.3 server implementations approaching distinguishing between external PSK identities and (RFC5077) resumption PSKs, so that one does not end up looking for RFC5077 key names to decrypt an external PSK, or pass resumption PSKs to the code that implements external PSKs? Do you prepend some new "magic" to the (RFC5077 or similar) session tickets? Or just look for a matching STEK key name and let that be the "magic"? -- Viktor. From nobody Thu May 10 07:18: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 A9B0212DA14 for ; Thu, 10 May 2018 07:18:38 -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 YyKglmKzQZcG for ; Thu, 10 May 2018 07:18:37 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EE8124E15 for ; Thu, 10 May 2018 07:18:37 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id 11-v6so1884665ois.8 for ; Thu, 10 May 2018 07:18:37 -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=SZDTWZ5VKJg6qNhmFcHTGVPe+KrN/Vy0cxicSLuh0Ys=; b=XAYfH/bV4xDDUDb0e2BLC0Nf9GxPKG3NfMmvyfQJkrUH4+UWyHtY1QnLfor1Tqmk+b vYPpXd/sZ20EkNdzG3vBLa8r+J81YlQR6UJRsND4hr99K7DZtCh6Mgv3wF7uqkYUzhKy 65KLUbIaABw8R67i7+Qc4/6oaUV+7M4b7N43Z+YI5fTWVjb4ZfGn+CUKYCj3yY2Cagzy J94lc7KjkPBEgOBdDG/mqRxtDYH1w1Cb+ztya59NJDr5JyPy9yG0cxGTRErzWRl6AJlL iIL3fXJ04ROkPrd2T0bKmA19zingGxCKSqtKR3s+oBegM3fb+ENABkRrTEYD2KxWvOs0 zkyA== 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=SZDTWZ5VKJg6qNhmFcHTGVPe+KrN/Vy0cxicSLuh0Ys=; b=aRz/9EACxfjmm5NC0FhHYZCniX3tYCHg/Uha0l/79UpQmkAKtXnnJyhhRyrONgiRJs peeSKKLxtLbpfPPkg1VnMjwdvCmkadGf02zh6nnTYgjfiML9as7v/Z2Rrxxw5FZflcdS VO9QZakQhOw0r7khbkvevAEyMBOwM3t0J9mJlO3kX7fZRuMi3WKoChtHBrww0N1LAEYa YUYu7TIpw476TobWcqZjphNxvPXIj0grN1THf9Hbv0czCyapF6lUGpTcCCxe08jqOn/H bZMT9jiO8KFYfso1bkIyI6zmT98SqEORYG+RwjTd18CeluxRTZhyB4WAeisGElUud6o3 3kng== X-Gm-Message-State: ALKqPwdH7Jq72OdD3ndT7V6y4dqA7ODATDuOeM0LHEHLPNgIWKJZihKe kF4i5x3dEWTAURVdAi1L0cbrGRvvphixaR2bAucIa1V/ X-Google-Smtp-Source: AB8JxZq1BRgJ5Wbnw1JlBp4yHNn3wkoAPxK4FCPIlNKjhz7hFv9lD/mYGnxD5bt9VKNVBO3ssA31K00pH70grRTouyI= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr913085oin.108.1525961916510; Thu, 10 May 2018 07:18:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 10 May 2018 07:17:56 -0700 (PDT) In-Reply-To: <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> From: Eric Rescorla Date: Thu, 10 May 2018 07:17:56 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000f98dc7056bdab12f" Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:18:38 -0000 --000000000000f98dc7056bdab12f Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 6:46 AM, Viktor Dukhovni wrote: > > > > On May 10, 2018, at 7:48 AM, Eric Rescorla wrote: > > > > The option for multiple PSKs is something that is used in pure PSK modes, > > but I confess to not fully understanding the reasons you might use > multiple > > PSKs. I suspect that they are most useful during a key rollover. > > > > Also, resumption of sessions created with PSKs > > So I am not hearing any intent to support multiple resumption PSKs > (session tickets) in the same handshake. > > How are TLS 1.3 server implementations approaching distinguishing > between external PSK identities and (RFC5077) resumption PSKs, so > that one does not end up looking for RFC5077 key names to decrypt > an external PSK, or pass resumption PSKs to the code that implements > external PSKs? > > Do you prepend some new "magic" to the (RFC5077 or similar) session > tickets? Or just look for a matching STEK key name and let that be > the "magic"? > I would imagine, but NSS, at least, doesn't support external PSKs. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f98dc7056bdab12f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 10, 2018 at 6:46 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On May 10, 2018, at 7:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The option for multiple PSKs is something that is used in pure PSK mod= es,
> but I confess to not fully understanding the reasons you might use mul= tiple
> PSKs.=C2=A0 I suspect that they are most useful during a key rollover.=
>
> Also, resumption of sessions created with PSKs

So I am not hearing any intent to support multiple resumption PSKs (session tickets) in the same handshake.

How are TLS 1.3 server implementations approaching distinguishing
between external PSK identities and (RFC5077) resumption PSKs, so
that one does not end up looking for RFC5077 key names to decrypt
an external PSK, or pass resumption PSKs to the code that implements
external PSKs?

Do you prepend some new "magic" to the (RFC5077 or similar) sessi= on
tickets?=C2=A0 Or just look for a matching STEK key name and let that be the "magic"?

I would imagine,= but NSS, at least, doesn't support external PSKs.

-Ekr


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

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

--000000000000f98dc7056bdab12f-- From nobody Thu May 10 07:59: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 41F971243FE for ; Thu, 10 May 2018 07:59: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76lg0L4nIryT for ; Thu, 10 May 2018 07:59:39 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DF91241FC for ; Thu, 10 May 2018 07:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525964375; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=3988; bh=GCbV98XohYe7HvirVYR3p0h2W6hiJRkyA4pCV/J21x0=; b=yrZ1deLI17DLL0uwUYhvZ/VnV5OBZCpEvuLtSIlff+Q9glLrB3JGs2qK1O2EEjUU TVX+YksDTv9a3ysvdsSoBfNhh9Np+/H15pEOCSbKkwUQkN21XSBASX5nheM7TlbYrl4 dikkppRKwpETJJqkZE0TUsACPArA/Rx3aPdzv1Lo= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525964375179174.29971095914402; Thu, 10 May 2018 07:59:35 -0700 (PDT) Date: Thu, 10 May 2018 10:59:35 -0400 From: R duToit To: Martin Thomson Cc: "" Message-Id: <1634a908489.1177ed3d735485.6019683877747033038@nerd.ninja> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_86147_1485997327.1525964375177" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:59:40 -0000 ------=_Part_86147_1485997327.1525964375177 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit The server sending the alert at warning level while knowing that it is about to negotiate TLS 1.3 seems to be in violation of the statement that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," - that is probably more of an implementation issue. The client's reaction to the warning alert is what is ambiguous. Some TLS 1.3 client implementations will ignore the alert, while others will choke. ---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson <martin.thomson@gmail.com> wrote ---- On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote: > I may be misreading the code, but it sure looks like the alert is only > sent if the application callback for the server name extension asks > OpenSSL to do that. The application can just decline the extension > and let the handshake continue with a default certificate... Is > the surprise that the alert is sent, or that it is a warning, or > something else? It's risking a failed connection. Though perhaps not that much more than providing the client with a certificate it might not like. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_Part_86147_1485997327.1525964375177 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
The server sending the alert at warning = level while knowing that it is a= bout to negotiate TLS 1.3 seems to be in violation of the state= ment that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=3D= fatal," - that is probably more of an implementation issue.

The client's reaction to the warning alert is what is = ambiguous.  Some TLS 1.3 client implementations will ignore the alert,= while others will choke.

---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson <= martin.thomson@gmail.com> wrote ----
O= n Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrot= e:
> I may be misreading the code, but it sure looks like the alert = is only
> sent if the application callback for the server name exten= sion asks
> OpenSSL to do that. The application can just decline t= he extension
> and let the handshake continue with a default certifi= cate... Is
> the surprise that the alert is sent, or that it is a w= arning, or
> something else?

It's risking a failed connecti= on. Though perhaps not that much more than
providing the client with a= certificate it might not like.

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



------=_Part_86147_1485997327.1525964375177-- From nobody Thu May 10 08: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 CDED112EB3C for ; Thu, 10 May 2018 08:46:43 -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 sJiVUWmPeLo9 for ; Thu, 10 May 2018 08:46: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 765F612EB3E for ; Thu, 10 May 2018 08:46:42 -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 930147A3309 for ; Thu, 10 May 2018 15:46: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 In-Reply-To: Date: Thu, 10 May 2018 11:46:40 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 15:46:44 -0000 > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > >> Do you prepend some new "magic" to the (RFC5077 or similar) session >> tickets? Or just look for a matching STEK key name and let that be >> the "magic"? > > I would imagine, but NSS, at least, doesn't support external PSKs. Good to know. Does any implementation other than OpenSSL support external PSKs? How do you distinguish between external PSKs and resumption PSKs? -- Viktor. From nobody Thu May 10 08:53: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 E080612D93F for ; Thu, 10 May 2018 08:53:44 -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 HMnhJKeVhRLb for ; Thu, 10 May 2018 08:53:43 -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 0777F12751F for ; Thu, 10 May 2018 08:53:43 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b130-v6so2158311oif.12 for ; Thu, 10 May 2018 08:53:43 -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=3xFKTbXITgfKgQZhFtyw2kxnH5mGg8Nebyd9md2kT6g=; b=13wFeAGjY2hf1V3WQRQsi1E4PODgULfzpZF8muLjw9sJYQ8QvjLJq/dbK0NnVbghZW 20P9SAtY4t/Ip4Aq9yW19ZeSc7b36DY93LgleQVltt0byDiwIcIQSnRiNsEABuYxJOz6 0zd0MPhS77EDm1lX2j6k62b4EAS6LrYH+Gm6YCfn9nncI4E5XdmLVn1caLAbbuVT9Ab1 EzCpUtFq9RsEZbKPnxa4Y1yJpAUjQ/7Xb27WVAsoa5fj/jJTmZ8HFI0wYLin1y5IAm4h XnQBp4EDhwGq4Gdm6J81OT0F1OiCGfj71okVY/N+nedERU267wHr3f/gjK5gX9LnhnQk 8N8A== 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=3xFKTbXITgfKgQZhFtyw2kxnH5mGg8Nebyd9md2kT6g=; b=bVDQ8D5BF0jeUQkIhuoHCKwucjwrXZWMw0AuNcYEDg7ahi9v6utB8pCWpZhq0z9Ttz RLcXQg3B5RL2UNNoy7wKtnw/dQfjJIkJcOyNj+58zJ9RBAwn2+tCFez1nPT2N+QJM7Sp 52BCJ6SotLJHXNyiolUyvng0lFv2fs0ZmKgWGV7vnNNGZs3bqiX0oHhmqlTyWdSjxH9f nOoeVFHAn/od7g7+mN7Fwrwmx5P9DMS3WR/Dhnn5ZFVMN5F/tlSfFWhEVgRjzY9zpCA2 sW1KSfSKEqLfxViVa9d6E6CeslpSczHhbDC91PeHXyvGJF1Sx1vsKg/h64J+2Yy28a9n UuLA== X-Gm-Message-State: ALKqPwfvgTERMxazx4QsrvWfvmgE1djsrhhNxm7jTiidiRIOMM+kjB0g GTFj87TCdPjssD6/5T2EdG1KjeNbbCsmnCiyU9hw8t3I X-Google-Smtp-Source: AB8JxZrTSsrHsWi/Nutvs573LIkfTqBtDh8rusvPI+07E9Wprqcmgdut64qN8u+Aek97HMWpTwAlsAkZI/SdvN5MW2c= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr1148397oin.108.1525967622126; Thu, 10 May 2018 08:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 10 May 2018 08:53:01 -0700 (PDT) In-Reply-To: References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> From: Eric Rescorla Date: Thu, 10 May 2018 08:53:01 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000000e53ca056bdc067a" Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 15:53:45 -0000 --0000000000000e53ca056bdc067a Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 8:46 AM, Viktor Dukhovni wrote: > > > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > >> Do you prepend some new "magic" to the (RFC5077 or similar) session > >> tickets? Or just look for a matching STEK key name and let that be > >> the "magic"? > > > > I would imagine, but NSS, at least, doesn't support external PSKs. > > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? > Mint does, but it doesn't implement session tickets, so they're just in one giant database. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000e53ca056bdc067a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 10, 2018 at 8:46 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:


> On May 10, 2018, at 10:17 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Do you prepend some new "magic" to the (RFC5077 or simil= ar) session
>> tickets?=C2=A0 Or just look for a matching STEK key name and let t= hat be
>> the "magic"?
>
> I would imagine, but NSS, at least, doesn't support external PSKs.=

Good to know.=C2=A0 Does any implementation other than OpenSSL suppo= rt
external PSKs?=C2=A0 How do you distinguish between external PSKs and
resumption PSKs?

Mint does, but it does= n't implement session tickets, so they're just in one giant databas= e.

-Ekr


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

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

--0000000000000e53ca056bdc067a-- From nobody Thu May 10 10:15: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 AF63212D88D; Thu, 10 May 2018 10:14:59 -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 IDvdeL_RgZuz; Thu, 10 May 2018 10:14:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DE6124B17; Thu, 10 May 2018 10:14:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 16A05B811AC; Thu, 10 May 2018 10:14:57 -0700 (PDT) To: loic.jonas.etienne@gmail.com, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ekr@rtfm.com, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180510171457.16A05B811AC@rfc-editor.org> Date: Thu, 10 May 2018 10:14:57 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Rejected] RFC5246 (5352) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:15:00 -0000 The following errata report has been rejected for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5352 -------------------------------------- Status: Rejected Type: Technical Reported by: Loic Etienne Date Reported: 2018-05-09 Rejected by: Eric Rescorla (IESG) Section: 6.2.3.3. Original Text ------------- struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCompressed.length]; }; } GenericAEADCipher; Corrected Text -------------- struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSCiphertext.length]; }; } GenericAEADCipher; Notes ----- 6.2.3.3. says: "The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]". The definition is duplicated at A.1., and needs the same adjustment. --VERIFIER NOTES-- aead-ciphered is an operator that takes content as the input. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 10 10:28: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 58BD612DA25 for ; Thu, 10 May 2018 10:28: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 cWGxo4nCd0hT for ; Thu, 10 May 2018 10:28: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 C96A812D95E for ; Thu, 10 May 2018 10:28:46 -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 0E2B57A3309 for ; Thu, 10 May 2018 17:28: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, 10 May 2018 13:28:45 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:28:48 -0000 > On May 10, 2018, at 11:46 AM, Viktor Dukhovni = wrote: >=20 >> I would imagine, but NSS, at least, doesn't support external PSKs. >=20 > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? So no need to distinguish in either NSS or Mint. Anyone else? On a related note, should a client sending both a resumption and an external PSK place the resumption PSK first in the list of PSK identities? My concern is that server implementations might otherwise recognize the external PSK first, and then not even look at the resumption PSK. Is that a valid concern? Should server implementations first see if any of the PSKs are resumption PSKs before considering the rest? --=20 Viktor.= From nobody Thu May 10 15:57: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 4EB1B12EB97 for ; Thu, 10 May 2018 15:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 I9uWy53Lyp8p for ; Thu, 10 May 2018 15:57:12 -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 D23E912E8C7 for ; Thu, 10 May 2018 15:57:11 -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, 10 May 2018 15:54:31 -0700 From: Jim Schaad To: 'TLS WG' References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> In-Reply-To: Date: Thu, 10 May 2018 15:57:01 -0700 Message-ID: <010901d3e8b2$368e3b30$a3aab190$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGTDf2ca+/EaVn+aDsMX+CPKYACLwJuW5tWASYjITgBgYDeggIqYyu6AWWoof6kZhfusA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 22:57:14 -0000 > -----Original Message----- > From: TLS On Behalf Of Viktor Dukhovni > Sent: Thursday, May 10, 2018 8:47 AM > To: TLS WG > Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? > > > > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > >> Do you prepend some new "magic" to the (RFC5077 or similar) session > >> tickets? Or just look for a matching STEK key name and let that be > >> the "magic"? > > > > I would imagine, but NSS, at least, doesn't support external PSKs. > > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? This is going to be a lot more common with DTLS implementations. I am not sure how much resumption is going to be used for those cases. Jim > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 10 16: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 538C612DB72 for ; Thu, 10 May 2018 16:08:17 -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 B21Q4wQSJIc7 for ; Thu, 10 May 2018 16:08: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 319F912EC3A for ; Thu, 10 May 2018 16:08:15 -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 B7FBC7A3309 for ; Thu, 10 May 2018 23:08: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: <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> Date: Thu, 10 May 2018 19:08:11 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <45BA18DD-AD60-4D15-B757-3DB4C35C3B3D@dukhovni.org> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 23:08:17 -0000 > On May 10, 2018, at 1:28 PM, Viktor Dukhovni = wrote: >=20 > On a related note, should a client sending both a resumption and > an external PSK place the resumption PSK first in the list of > PSK identities? My concern is that server implementations might > otherwise recognize the external PSK first, and then not even > look at the resumption PSK. Is that a valid concern? >=20 > Should server implementations first see if any of the PSKs > are resumption PSKs before considering the rest? Perhaps a better question is: Should servers issue resumption tickets after an initial PSK handshake? And if so, should resumption be preferred for any reason when the = client sends both a resumption ticket and the external PSK? --=20 Viktor. From nobody Thu May 10 17:15: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 2738F12DA1A for ; Thu, 10 May 2018 17:15:03 -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 MGws4eY8CJX9 for ; Thu, 10 May 2018 17:15:01 -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 7CD8512D7E6 for ; Thu, 10 May 2018 17:15:01 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id g7-v6so4325209otj.11 for ; Thu, 10 May 2018 17:15:01 -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=/vKTYVtnm/4BsgoX15ZpE/ZQZA3cTYWR7llgWa0ce6Y=; b=LN+h+8eG7TR+mk66tdD9Kz+0TQ9GDSviyKsPr/Wk92KBT31DS48ISr47+0nRjTclNj M5v0v2esFsBf/WDltREmb+CyuI1TDZgTDzQa6/I8aaeHnkLtpWzLGjRVWpCYIDTi5oEP fjzGCDeq6r1qfazcHfLGKEZJTGSV62tBxmhB95yDKeiTBCE6kMB9wnV1cG7y+DtmMJjn 8a5dCLJP0DDJTijmrJSLVNSGbfuRxzNK7YAzVb/ENrJhhV4zhgjKGf9TOWP8S8RUNTmS ZKYo551bevD2Q+Urqm2c6/iZGpRedLEB+AnfGGZC/MEmSahIfJvXdMlyfv2+3pS2fpbs Uw5g== 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=/vKTYVtnm/4BsgoX15ZpE/ZQZA3cTYWR7llgWa0ce6Y=; b=jyOIuep8um4w0mXoq0V6L838Xxe29nZDMQMxRSenhX9tkSqkiULNJgxrJGHiFaJMuq ARxvrZ9yTmd0BJVHZhP0zBTaR0bnd3OWmYCDm0qVbkQHqX9huxdaG9b6/s0+3dJFtBH9 L1nRfNTEuyuP5VlQvdXzGxmJcGn/YjHg0k7TNwQLPnMKZKNvSU7XV1iABbY1xzGGKf4D JwoBMnhiIqpSykYzfHr7Jql03RYTpqVnR+FYrjcNjcgxxc1oy6RLCi/zPmFJfCEPeojO K+PpFpYfZJJ6MwtQH0bj4iZIB4pp2n/7WcwYDAno2vstGaATf5ugDUqz41eg+/AjXsfV CvnQ== X-Gm-Message-State: ALKqPweUIBD5Tl7XOIxnO5Hg6N0pPrGpCNps5oDgQ612F5Xoi7JuU2jG E4P7FTcwp7kYLaovIG5dsJyADtQdodoyKcN8Dachig== X-Google-Smtp-Source: AB8JxZrVoJebtlhXkHH2zrZG+uxEW920vhpCHisHl3vaUG8SsHT38dHqCWKF/i24fSOLtQ+hR/WZ4uWrxDtPIPYZcBQ= X-Received: by 2002:a9d:3a65:: with SMTP id j92-v6mr2580884otc.352.1525997700740; Thu, 10 May 2018 17:15:00 -0700 (PDT) MIME-Version: 1.0 References: <1634a908489.1177ed3d735485.6019683877747033038@nerd.ninja> In-Reply-To: <1634a908489.1177ed3d735485.6019683877747033038@nerd.ninja> From: Martin Thomson Date: Fri, 11 May 2018 10:14:53 +1000 Message-ID: To: r@nerd.ninja Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Warning alert before TLS 1.3 ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 00:15:03 -0000 Yep. More so in DTLS when the alert might arrive after the client has seen the ServerHello. On Fri, May 11, 2018 at 12:59 AM R duToit wrote: > The server sending the alert at warning level while knowing that it is about to negotiate TLS 1.3 seems to be in violation of the statement that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," - that is probably more of an implementation issue. > The client's reaction to the warning alert is what is ambiguous. Some TLS 1.3 client implementations will ignore the alert, while others will choke. > ---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson < martin.thomson@gmail.com> wrote ---- > On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni > wrote: > > I may be misreading the code, but it sure looks like the alert is only > > sent if the application callback for the server name extension asks > > OpenSSL to do that. The application can just decline the extension > > and let the handshake continue with a default certificate... Is > > the surprise that the alert is sent, or that it is a warning, or > > something else? > It's risking a failed connection. Though perhaps not that much more than > providing the client with a certificate it might not like. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 10 17:31: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 28D1212EBAF for ; Thu, 10 May 2018 17:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RzUMoxxQcx9P for ; Thu, 10 May 2018 17:31:19 -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 BFA7812E8C7 for ; Thu, 10 May 2018 17:31:19 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id m11-v6so4358900otf.3 for ; Thu, 10 May 2018 17:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RzVEowdJAfHWIqB7rfD1gP3cqvcGrbMOAYKNxjFkDTU=; b=msRNEwZvcEfqznfeSpRWbUM6WKJjjAcvW4pClZ22ucDPi6ljqI6McZ9yKgw8jk0f7Z Cc4EXfMhh9JtiIoewm3XZMlLcGTkl2Y1F5J1Gp7gF7pvoqVFjpa9/qYK/RhcDI3kt247 ufl+C+q65pBGo1/5BBtioIEClLMkR8XJ+nOSavaOWIZtcgFAjHLEeO+LeBX91/ZIv1AR IOvFOmIBGDPu7l+YVgkIoMurBpeIeCE730oNv4fqeuI3WJmlJsy00P41R4md6z43ZAKL 4c+f7g8yHfFe2aS7MzbO/U/nLYCLKCgNXXtT3cZAnICnExZjg/Uvoo+zvjvjHME1eb12 XHBQ== 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=RzVEowdJAfHWIqB7rfD1gP3cqvcGrbMOAYKNxjFkDTU=; b=htBJR64cfjtTwxvausoA6RwgYxcpsMCha/kf8IjU+ZMzVd8EEZwGQ4sNn4nbhEUu0k 9w98NSffyUu2kzWNMDWjL8pWU6hRF75PAzecCW91h26LAogviErL3jYcy+2ogcbiq5eu sDYR48WACX5zzJnQadsTco5ZGk2cvJawA6DPvkT0vwF5oa3opDzPFnjivYZuNyGtZPfP T0uFEkc5wAbEh9pGYZAl7OQeof6p7wjFCQwrYuH4wBpvzlqPbEOs7/I0ZLHp2JmcmcYn wJuTIPDsBnxH4N8QQKwFUq3QZHBcKUqJwC/I8mjLAkNj1udEoh7OtCAnAYBBVc3f3Xyc d1Sw== X-Gm-Message-State: ALKqPwfHTwZe945FpVyEG9MqpALN3UyqO657qFm6Zxl33chqZ4L52acm hs5WOPsofe/jfU7PtV6CDdP3lr10Xkarn3XpQ8o0CQ== X-Google-Smtp-Source: AB8JxZobJCoV30Y3PN+MaqQJiNrmGtgsMXAx9oz5wki0nbjjeYtpuFS7x/2bFrkULehHnq3XlLqCuSx7I/bknUm6Bu0= X-Received: by 2002:a9d:3a65:: with SMTP id j92-v6mr2608962otc.352.1525998678715; Thu, 10 May 2018 17:31:18 -0700 (PDT) MIME-Version: 1.0 References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> <45BA18DD-AD60-4D15-B757-3DB4C35C3B3D@dukhovni.org> In-Reply-To: <45BA18DD-AD60-4D15-B757-3DB4C35C3B3D@dukhovni.org> From: Martin Thomson Date: Fri, 11 May 2018 10:31:11 +1000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 00:31:21 -0000 On Fri, May 11, 2018 at 9:08 AM Viktor Dukhovni wrote: > Should servers issue resumption tickets after an initial PSK handshake? > And if so, should resumption be preferred for any reason when the client > sends both a resumption ticket and the external PSK? I don't think that we can codify anything here, but the angle I approach this from is in terms of what safeguards are placed on keys. Ticket keys are typically stored in volatile or temporary storage with their relatively brief validity interval being the primary safeguard against theft. That makes them easy to use, but they are consequently unusable over long periods of time. If an external PSK has a need to be viable over longer periods, then perhaps you want to use it less often. That might be to avoid having to load it into memory and risk it being readable, or it might be because the controls on its use are more onerous. For instance, some might require user input (for a PIN or the like), or have a performance cost involved in access. All speculation, but there you go. From nobody Thu May 10 18:32: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 7180812E85B for ; Thu, 10 May 2018 18:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 I_BMt4Gvspb7 for ; Thu, 10 May 2018 18:31:58 -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 58B6012D7F0 for ; Thu, 10 May 2018 18:31:58 -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, 10 May 2018 18:29:17 -0700 From: Jim Schaad To: 'Martin Thomson' , References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> <45BA18DD-AD60-4D15-B757-3DB4C35C3B3D@dukhovni.org> In-Reply-To: Date: Thu, 10 May 2018 18:31:47 -0700 Message-ID: <011201d3e8c7$d54b63a0$7fe22ae0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGTDf2ca+/EaVn+aDsMX+CPKYACLwJuW5tWASYjITgBgYDeggIqYyu6AWWoof4CFWKn0gJzK4rhAXRBdJqkNlyGUA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 01:32:00 -0000 After thinking about this for a while, I would expect that sending an external PSK w/ a ticket should be rare for those systems that are going to want to do privacy protection. Sending the external PSK would allow for association of sessions that should not happen with just the ticket. Jim > -----Original Message----- > From: TLS On Behalf Of Martin Thomson > Sent: Thursday, May 10, 2018 5:31 PM > To: > Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? > > On Fri, May 11, 2018 at 9:08 AM Viktor Dukhovni > wrote: > > Should servers issue resumption tickets after an initial PSK handshake? > > And if so, should resumption be preferred for any reason when the client > > sends both a resumption ticket and the external PSK? > > I don't think that we can codify anything here, but the angle I approach this > from is in terms of what safeguards are placed on keys. > > Ticket keys are typically stored in volatile or temporary storage with their > relatively brief validity interval being the primary safeguard against theft. > That makes them easy to use, but they are consequently unusable over long > periods of time. > > If an external PSK has a need to be viable over longer periods, then perhaps > you want to use it less often. That might be to avoid having to load it into > memory and risk it being readable, or it might be because the controls on its > use are more onerous. For instance, some might require user input (for a > PIN or the like), or have a performance cost involved in access. > > All speculation, but there you go. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 11 00:05: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 84F1412E76A for ; Fri, 11 May 2018 00:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pUS8kpZcwP8 for ; Fri, 11 May 2018 00:05:54 -0700 (PDT) Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCB812D94F for ; Fri, 11 May 2018 00:05:54 -0700 (PDT) Received: by mail-wm0-f43.google.com with SMTP id a137-v6so1694142wme.1 for ; Fri, 11 May 2018 00:05:54 -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=+4QoRORPvWbNVuo2S9cQ/4r92nEDMa4NCYvDFcfYjso=; b=J8WqU37+IU54daIHDBit6USp3ZkpNs+8F1RGo8VRAM4ejGbbBLqOZW4YOJrW43nTYz ER15c9QCiV+4MlLvralAqLEJjizXvEnyIcspwPLWG2dBnfIJhbJ4ZdTb6IRMfoT3CmBF +g1/KZeOlY9NB563Qe/yVV4RKPplpPhAi4SGJhAJOPPsPVQ1phKXrAzVyJvOxnmSg3cu y/WsGvA7rTMtofEKEwoOLYq3voL0DMKa40FqJRsk6qp4m0GfSEh6QYqgLPtfeH8yWzF8 k83VzBcbcNUAgH9eHUsvsreGG5sgrK2BgfLQC9/LioeZ6eVYPoNCtyAwvQn+eIXGJbR6 6ikw== X-Gm-Message-State: ALKqPwctgAg2f++8wIbVefJkYEiyNos6+F0QOOhH/9ogTL7zOAKyyCVE IvY6Q9+kI/OhgLzLgf6TQe982E03wgs= X-Google-Smtp-Source: AB8JxZr9fjRl07lFBixl/DwBEBqNOaBLN874q0shK59eNkxxM/0L2hFUsIWR37GcwFYERo9WoGwAVg== X-Received: by 2002:a1c:e704:: with SMTP id e4-v6mr1030897wmh.119.1526022352728; Fri, 11 May 2018 00:05:52 -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 l69-v6sm968111wmb.6.2018.05.11.00.05.51 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 11 May 2018 00:05:51 -0700 (PDT) Message-ID: <8ae36587211182108801d686475474d2d34c9084.camel@redhat.com> From: Nikos Mavrogiannopoulos To: TLS WG Date: Fri, 11 May 2018 09:05:51 +0200 In-Reply-To: References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 (3.28.1-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 07:05:57 -0000 On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > > > Do you prepend some new "magic" to the (RFC5077 or similar) > > > session > > > tickets? Or just look for a matching STEK key name and let that > > > be > > > the "magic"? > > > > I would imagine, but NSS, at least, doesn't support external PSKs. > > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? gnutls does. For external PSKs It checks for ticket age being zero and the username/identity within acceptable bounds. regards, Nikos From nobody Fri May 11 04:14: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 20FCB12E873 for ; Fri, 11 May 2018 04:14:32 -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 tdeTq1gTxXXz for ; Fri, 11 May 2018 04:14:29 -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 0557812E036 for ; Fri, 11 May 2018 04:14:28 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B392D4075742; Fri, 11 May 2018 11:14:27 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 488AB2166BAD; Fri, 11 May 2018 11:14:27 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 11 May 2018 13:14:26 +0200 Message-ID: <2145589.NFDilWQh0X@pintsize.usersys.redhat.com> In-Reply-To: References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1546736.U1ppZGW3bh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 11 May 2018 11:14:27 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 11 May 2018 11:14:27 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 11:14:32 -0000 --nextPart1546736.U1ppZGW3bh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 10 May 2018 17:46:40 CEST Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > >> Do you prepend some new "magic" to the (RFC5077 or similar) session > >> tickets? Or just look for a matching STEK key name and let that be > >> the "magic"? > >=20 > > I would imagine, but NSS, at least, doesn't support external PSKs. >=20 > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and > resumption PSKs? tlslite-ng does, but it is vulnerable to the enumeration attacks =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 --nextPart1546736.U1ppZGW3bh 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+dkqjRuAHS9fUFAlr1exIACgkQkqjRuAHS 9fUFOA//e+DoZNO/l7GVBxJbAsf5MQVqM6UqbZ/SRIPIg5cvH9YIpA0sdxnZ9QDq 0FNrdTLTwV+2sp6v/VYT0fC0/O7tel5b9bOafF8oV5JPKh6VZyuzNtMgHB+s4u43 Ge3oDXCD2YwPyPlbwWwWhTa3gmSNoKr+HXhtuuvVnjnR7f8CYEHGxRvKeQs5TFwf OxVpOSBAZ9msSI9NngXh0JTDM8um3SxHzD47o/5ebpPOVc4JU2Z4ty/nbCe1beWL 8ZyrNjzK8l7wMd2HkZfbXRd9amFsdabpaJhsfPWnqjdhet/U9jZ6VCzbQdZvWujc 9TzIgCVE68GAuflZRNvh71c5n9Fb184R00hKq/wmqf00ckr9Myfj8/hG7rZUmfhn K5luVPRTSWjQds+P2NlU+mMlb2xarl6rgG/yLsKTvcUd3H8A+QFd5wu0xj6V8G7z g7n5xI/4BJy3th6QkEIK6Qb+OdyHDQs5L8VeFtKTI2Blpk56TurvJeNPtq+sEGi/ NuRq/k5d+IXyVDkpODduPpWhFh3iMUE9p904lRnHqcSFQpgQsr+kOOcXgw2vX5mm 054OwrjFlXTdqd6Vm3/xNEU6MTQVZd2BxE9pofnjPwOL/Y0WWJzWSOqqz9DSNVOH LGr4NiWa/FalXzHTiIDXicBX0qwysRN88ieEBkD3Lg40PgQOrQE= =f4Ab -----END PGP SIGNATURE----- --nextPart1546736.U1ppZGW3bh-- From nobody Fri May 11 04:22: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 74D0E12E88B for ; Fri, 11 May 2018 04:22:51 -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 99tL86uJkFi7 for ; Fri, 11 May 2018 04:22:50 -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 EB04B124C27 for ; Fri, 11 May 2018 04:22:49 -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 53E1F7D664; Fri, 11 May 2018 11:22:49 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id E889185779; Fri, 11 May 2018 11:22:48 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 11 May 2018 13:22:43 +0200 Message-ID: <1532850.sSZ8P2j6eL@pintsize.usersys.redhat.com> In-Reply-To: <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <2AF454E0-48F4-4C98-855D-B4BB342E4C47@dukhovni.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3388960.Sa08eK659I"; 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.2]); Fri, 11 May 2018 11:22:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 11 May 2018 11:22:49 +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] TLS 1.3 multiple PSKs (was session tickets) from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 May 2018 11:22:51 -0000 --nextPart3388960.Sa08eK659I Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 10 May 2018 19:28:45 CEST Viktor Dukhovni wrote: > > On May 10, 2018, at 11:46 AM, Viktor Dukhovni = =20 wrote: > >> I would imagine, but NSS, at least, doesn't support external PSKs. > >=20 > > Good to know. Does any implementation other than OpenSSL support > > external PSKs? How do you distinguish between external PSKs and > > resumption PSKs? >=20 > So no need to distinguish in either NSS or Mint. Anyone else? >=20 > On a related note, should a client sending both a resumption and > an external PSK place the resumption PSK first in the list of > PSK identities? My concern is that server implementations might > otherwise recognize the external PSK first, and then not even > look at the resumption PSK. Is that a valid concern? I'd say so, the server should use the first identity for which the binder=20 validates. =20 > Should server implementations first see if any of the PSKs > are resumption PSKs before considering the rest? all the value lists sent by client are supposed to be sorted by willingness= to=20 use by client, most wanted first I don't see why PSK's shouldn't be like this too. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3388960.Sa08eK659I 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+dkqjRuAHS9fUFAlr1fQMACgkQkqjRuAHS 9fVuFA/+PT5eih1PVRV0nz05g0paSvJvJ9P72bcr1FGhXYqMLB+UgcEIwWBRN802 2wKu4HBo5ngOmJGZ3h14F9ISeYnsi1WLbXAQhF74+h13XxA5+ts3aGuESvViuG5N 7euKyioxS03kMwLeq5akhNPJZ/mpVFfyGyW9su16XM7svh5saiPEx1UTQ//WdHBa GDjKk4wSdXiuQ+1Q4mWv5mV813EYwMN/hRvKg7cc9mf/hK8jFl+nklxVjeycdH97 SRZxoJqzayuuB70CG2VUluFUn+BaoRUAXFYCUNLAedbpgeAWLCdJFzn7k5B00zNk Ziosm4vWQXQn+vaAD+bebkzPNFcifBTlcdMkmJx1rqJOOtglJHayMzG09HOoKQw4 EEpPcNUQeV0ONCu9IdImS3wPXDnSuXmtzg1B1Lk3tHhgkQslSIKFKXCEVwAyq5zq 9rNeAYladokUKdrHiE6Dltjtyqsbi/F6kbABWrh50wXqthj1bNyAPsfAUCo13hoy fNzicmNJhY4cWCeiGr5rh1yPCgS71Ioe8Rl822cuC13J24JH1QqdsfYiow7jsomn K3apFA/TFu/B86BtNSSXIn/YQ5QdBYRc2AqQamj/K7cOfbXFr10OmM5k1WrSqxQF BgOhJzALTEjc6zXKHzFAM5BBrpM5ybIb2V2Ykf4FBKXjfaV5qd8= =q/OQ -----END PGP SIGNATURE----- --nextPart3388960.Sa08eK659I-- From nobody Fri May 11 16:58: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 7778F12D7E2 for ; Fri, 11 May 2018 16:58:56 -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 KYjgHCPm2rmD for ; Fri, 11 May 2018 16:58:54 -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 A9118129C5D for ; Fri, 11 May 2018 16:58:53 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id q3-v6so6807435wrj.6 for ; Fri, 11 May 2018 16:58:53 -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=PHsP/fveUIR/LhP/zlsOAuMiVe6Lg0Z6oLkEZymAdZA=; b=nRArqhUMzuZNTHRxKruMbFGCTMgFE4hgZTDujq8DwK7OIrjB67z1t7qDwXv4WLV1Cr CStlxKczKV32BqAgZH8AfJktyTnGy9zpoCLWzqcD1u0PPQnbzFbbCFKyX2tbcQoR82D2 IB8ABFpgI7EPj8akQVvoyz3d6zqocl6s7HMKBO7jtuaJGDpmfqL5zNO29jBuLe0m+4RE d5ENMApsbM9fzM9A28LWTw5qnZDDmhfv9rv9wTkZPgwAMh6QmPMKZ6drqiKX7DDuFCDe LJOJsGOHdJH76R9J7vXVGDE1O3mBJ9KKOR21ycw2PeM3LptGkrDgSaiWqxMwA9HKtmm8 LmPQ== 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=PHsP/fveUIR/LhP/zlsOAuMiVe6Lg0Z6oLkEZymAdZA=; b=i1+wyBQ4N+2ZX04vw6dk1H1sokLXWpUTv6ObgzhhokZI9sm62qAI6A3EfgVWpbACVy bnIdt8Mld7wzAeZaC0oejoYterdIu/b0xQYVtzwuFKorcrNgwVhgOuVD5E/tWpFtFVEB 4Xn5QmRCUPo6/YABzul5FoJIULg+gtwPkwHHpUTCNrJ8CRlNMsADf90wbNU3c1lxjnYJ +zTmpO59bZn4irMiIvKSmdm8gZZ4j9XCoi0Vt/LgwBM3oRil/TGX+vi6kn76LSgWm4bc A2jBuXcsJMf2TGYWsDY+NbQ/OTT3MPS9mQJINJNJkA94YY/nPvE/6fg0H7e1XAPISHzw PT3w== X-Gm-Message-State: ALKqPwfvzZrV9XNRXtlOSa5ENkdKW7Rq4muUqOWq/qVBzxFrxulUSkjd 9nR8aCcaaAWrsKPtAUs9Cr3xHtpNcDpwQr0uznY= X-Google-Smtp-Source: AB8JxZrHh14ewHzTIxO8loi9HWyBrvhXcxQ3HjSzwhV9woyio4+4Yb83niuO1aOY7XasKQS0uGtgExEpltfqydmXG3U= X-Received: by 2002:adf:b00f:: with SMTP id f15-v6mr723078wra.254.1526083132090; Fri, 11 May 2018 16:58:52 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Nick Sullivan Date: Fri, 11 May 2018 16:58:35 -0700 Message-ID: To: Sean Turner Cc: TLS WG Content-Type: multipart/alternative; boundary="000000000000fc6ceb056bf6ea2f" 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: Fri, 11 May 2018 23:58:56 -0000 --000000000000fc6ceb056bf6ea2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks all for the comments on the draft. Let me try to summarize the comments and propose next steps. Tim Hollebeek had a comment about 0 as the separator. I generally don=E2=80= =99t think this is a big issue, and prefer 0 because it is a natural way to terminate a string. If anyone strongly disagrees, please reply to the list. Roelof duToit raised a question about middlebox interoperability, specifically that the exporters will not match if the TLS connection is not end-to-end. There was a subsequent discussion about where to signal this property. Martin Thomson suggested a signaling mechanism at the application layer (https://github.com/httpwg/http-extensions/issues/617) and Eric Rescorla suggested that the fact that this could cause CertificateVerify failures should be called out in the document. I'll put a PR together to add some helpful text around debugging CertificateVerify failures to address Eric's suggestion. Ben Kaduk had three points: - The certificate_request_context is prone to collisions with post-handshake authentication and there are different spaces for the server and client context values. He suggested some text in Section 3 and maybe more explanation in Section 5.2 as well. I=E2=80=99ll put together a PR for= this. - Section 4.1 talks of the length of the exporter value in terms of the length of the TLS PRF hash, adding that cipher suites not using TLS PRF have to define a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2=80=99l= l put together a PR to clarify the text around this clarifying that for TLS 1.3 cipher suites, the HDKF hash is what is meant. - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not incorpo= rated into the draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorp= orate this extension. I'll have the proposed changes for the above comments ready next week. There were also some uncontroversial suggestions that I propose merging: https://github.com/tlswg/tls-exported-authenticator/pull/21 https://github.com/tlswg/tls-exported-authenticator/pull/22 https://github.com/tlswg/tls-exported-authenticator/pull/23 https://github.com/tlswg/tls-exported-authenticator/pull/24 Nick On Thu, May 3, 2018 at 1:16 PM Nick Sullivan wrote: > Does anyone have any comments about the draft, criticisms, or votes of > support? > > Nick > > > On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: > >> >> >> > On Apr 21, 2018, at 10:25, Sean Turner wrote: >> > >> > >> >> On Apr 19, 2018, at 16:32, Sean Turner wrote: >> >> >> >> 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 UT= C >> on 4 April 2018. >> > >> > =E2=80=A6 4 May 2018 ... >> >> Just a reminder the WGLC ends tomorrow. >> >> spt >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000fc6ceb056bf6ea2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks all for the comments on the draft. Let me try = to summarize the comments and propose next steps.

Tim Hollebeek had = a comment about 0 as the separator. I generally don=E2=80=99t think this is= a big issue, and prefer 0 because it is a natural way to terminate a strin= g. If anyone strongly disagrees, please reply to the list.

Roelof du= Toit raised a question about middlebox interoperability, specifically that = the exporters will not match if the TLS connection is not end-to-end. There= was a subsequent discussion about where to signal this property. Martin Th= omson suggested a signaling mechanism at the application layer (https://github.com/ht= tpwg/http-extensions/issues/617) and Eric Rescorla suggested that the f= act that this could cause CertificateVerify failures should be called out i= n the document. I'll put a PR together to add some helpful text around = debugging CertificateVerify failures to address Eric's suggestion.
<= br>Ben Kaduk had three points:
- The certificate_request_context is pron= e to collisions with post-handshake authentication and there are different = spaces for the server and client context values. He suggested some text in = Section 3 and maybe more explanation in Section 5.2 as well. I=E2=80=99ll p= ut together a PR for this.
- Section 4.1 talks of the length of the expo= rter value in terms of the length of the
TLS PRF hash, adding that ciphe= r suites not using TLS PRF have to define a hash function, but TLS 1.3 ciph= ersuites do not use the TLS PRF. I=E2=80=99ll put together a PR to clarify = the text around this clarifying that for TLS 1.3 cipher suites, the HDKF ha= sh is what is meant.
- The =E2=80=9Csignature_algorithms_cert=E2=80=9D e= xtension was not incorporated into the draft. I=E2=80=99ll put together a P= R for 4.2.1., 4.2.2. and 5.1. to incorporate this extension.

I'l= l have the proposed changes for the above comments ready next week.

= There were also some uncontroversial suggestions that I propose merging:ht= tps://github.com/tlswg/tls-exported-authenticator/pull/21
https://githu= b.com/tlswg/tls-exported-authenticator/pull/22
https://github.com/tlswg= /tls-exported-authenticator/pull/23
https://github.com/tlswg/tls-export= ed-authenticator/pull/24


Nick


On Thu, May 3, 2018 at 1:16 PM Nic= k Sullivan <nicholas.sull= ivan@gmail.com> wrote:
Does anyone have any comments about the draft, criticisms,= or votes of support?

Nick


On= Thu, May 3, 2018 at 1:12 PM Sean Turner <sean@sn3rd.com> wrote:


> On Apr 21, 2018, at 10:25, Sean Turner <sean@sn3rd.com> wrote:
>
>
>> On Apr 19, 2018, at 16:32, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> This is the working group last call for the "Exported Authent= icators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authen= ticator/.=C2=A0 Please review the document and send your comments to th= e list by 2359 UTC on 4 April 2018.
>
> =E2=80=A6 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

spt
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000fc6ceb056bf6ea2f-- From nobody Tue May 15 16:34: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 087A912E8E4 for ; Tue, 15 May 2018 16:34: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, URIBL_BLOCKED=0.001] 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 8kxIdXjkg5mT for ; Tue, 15 May 2018 16:34:22 -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 3D49A12E042 for ; Tue, 15 May 2018 16:34:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40lv6L4xhmz26t; Wed, 16 May 2018 01:34:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1526427258; bh=PeKlzWyIh0rg/SVcoYg/M5wpCBufba3t9bC9+XMWhIc=; h=Date:From:To:Subject:In-Reply-To:References; b=ScldkTdb8j5UDtZ1CiPb/D8NKwOHWOPKioDTqzSCJxtg1Iv0SnD79qECRjxw61tyP 7of65EJhFnBc9BUCn8V6q1OSjEi3HNFeza2PbwUXUiTEF4hbtYpAPVYxen21BEDacq VnBrcGMJ0+QwVPRiU1maSrtLmyHz5y/GmmNFuVSo= 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 LMqk5Zi3IEhd; Wed, 16 May 2018 01:34:14 +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, 16 May 2018 01:34:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C89E249ED68; Tue, 15 May 2018 19:34:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C89E249ED68 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BD453412EC5F; Tue, 15 May 2018 19:34:12 -0400 (EDT) Date: Tue, 15 May 2018 19:34:12 -0400 (EDT) From: Paul Wouters To: Eric Rescorla , tls@ietf.org In-Reply-To: Message-ID: References: <20180504202710.GO23530@kduck.kaduk.org> <20180509180551.GN84491@kduck.kaduk.org> <20180511204920.GK84491@kduck.kaduk.org> <47BE42BD-7645-467D-B862-48D19E205D9F@dukhovni.org> <82517472-128D-4940-B566-927C5A101857@dukhovni.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: [TLS] Redirecting draft-ietf-tls-dnssec-chain-extension discussion back to the TLS 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: Tue, 15 May 2018 23:34:26 -0000 On Tue, 15 May 2018, Eric Rescorla wrote: [ On advise of Eric, replaced the large CC: list with the TLS WG list ] > I think I've been pretty clear about my position, but in case it's not clear: > > - I'm not sure pinning is a great idea for the reasons I've already mentioned >   in the thread (i.e., I think it has a high risk of causing the same problems >   we saw with HPKP. Written on May 5th in one of our large group CC: messages: Viktor: 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.' EKR: Thanks. This is a good point that I agree does not apply to HPKP. So I believe we had reached consensus on this alleged "high risk" not being an issue. Furthermore, other then the transport, this is basically how RFC 6698 just works. > - If pinning is a good idea, That's not the real question. The question is "Is having a full downgrade attack within a security protocol a good idea". Do you have an alternative solution to prevent the downgrade attack? > - I suspect that any pinning design is going to need to be more complicated >   than just a lifetime. And as explained before as well, due to this being DNSSEC based TLSA records or their Denial of Existence, there is nothing more complicated involved. DNSSEC provides you with extension pinning updates within the TTL of your own choosing. If you think pinning the TLS extension to commit to feeding up to date DNSSEC data is a problem, you should file an errata against RFC 6698. The only difference here is the transport protocol (port 53 DNS versus the TLS extension body of the same signed data) Furthermore, if you have a different method to weighing in the risk of deploying this TLS extension, our proposal allows you to set the pin to 0 as long as you want. That is, our solution does not prevent you from doing what you want. However, your solution is preventing us to do what we want (and which is a security issue on top of that) > For these reasons,  don't think a lifetime placeholder in TLS is a good idea. Again, I feel none of these stand up to scrutiny based on my above answers. You are rejecting a solution to a security problem, but are not addressing the actual security issue. A downgrade attack is a serious attack rendering the entire TLS extension useless. So far your motivation for not solving it is "it might be a hard problem", which I think would be insufficient to proceed with publication of this document as is with a security hole in it. The only arguments left are "we are too far in the process" and "it is ugly". Viktor and I proposed a solution for "too far in the process" that ensures this extension moves forward now with the pinning details postponed to a new document updating this document. I have also shown that "it is ugly" prevents an even uglier draft that is required to solve the downgrade attack left in this document if we suggest what you do and leave the downgrade attack in this document without any scaffolding for pinning: https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 > At this time, there's clearly not consensus to make the change you > want. Therefore, if you want to make that change, you need to persuade > the WG. Ok, I CC:ed the WG back into this discussion. This still leaves my question unanswerd: Do you believe that consensus may outweight an undisputed security problem that voids the entire use case of the document? Let me clarify that I would like to hear your answer in your role as Security Area Director. Paul From nobody Tue May 15 20:14: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 6DE12127136 for ; Tue, 15 May 2018 20:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 kCk8Kv-NlomX for ; Tue, 15 May 2018 20:14: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 35D59124B18 for ; Tue, 15 May 2018 20:14: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 657757A3309; Wed, 16 May 2018 03:14:38 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni 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\)) Date: Tue, 15 May 2018 23:14:37 -0400 Cc: Sam Hartman To: TLS WG Message-Id: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 03:14:42 -0000 The present DNSSEC chain draft is subject to a downgrade attack that strips the extension when the attacker is able to compromise the WebPKI (obtain a fraudulent certificate from a WebPKI CA). This limits the extension to just the use-cases (de novo applications) in which DANE is the only supported authentication mechanism. While we want to see this document advance as expeditiously as possible to address the needs of its first adopters, without pausing to fully specify the downgrade protection that will be needed to meet its stated objectives, and to that end accept the lack of effective downgrade protection in the present draft (which is being revised to remove the original unilateral pinning described in Section 8), there is more than one way to "remove pinning". We can omit all mention of expecting ongoing extension support, or we can plan ahead and reserve a short (two octets would be enough) field in the extension that initially must be zero and proscribes pinning when seen. This places no burden on servers or clients that have no need for downgrade protection beyond respectively zeroing or ignoring the new field. The new field is sufficient to then retain the application scope promised in its 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. 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]. It may not be relevant for many other applications. There is no role here for bells/whistles like "testing" modes, because there's no way to authenticate a "testing" mode, that'd be just another downgrade vector. If testing were to be a feature of DANE, the = directive would have to be in DNS (as a new DANE TLSA certificate usage for = example) and not in this extension. Nor is there any need to cover sub-domains, since the scope if explicitly not even a single logical host, but rather = a specific service port at that host. It is not difficult to see that = none of the extra features beyond policy lifetime of the somewhat related = "STS" protocols apply here. And this protocol is definitely nothing like = HPKP. All the downgrade protection needed for this extension is just an = optional commitment to operate servers which can for the agreed time, respond = with either TLSA records or denial of existence thereof, or proof that the domain is no longer DNSSEC signed. Once the software capability to = proxy whatever happens to be in DNS is there, it imposes no further = constraints on the domain's use or non-use of DNSSEC or DANE. With the two bytes in the extension now, it becomes much easier later to publish a document that describes their use for downgrade protection. And such a document would not require a new extension or new library code to support such a new extension. I therefore appeal to the readers who've so far stayed silent on this issue, to lend support to paving the way for a more broadly applicable downgrade-resistant protocol, by supporting the inclusion of a two byte field for that purpose. The proposed text is at: = https://github.com/letoams/dnssec-chain-extension/commit/11192cfbb723832c4= b624f9118fc6d08393fa6da --=20 Viktor. From nobody Tue May 15 21:08: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 25C3D120724 for ; Tue, 15 May 2018 21:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 p4X4bELwIUsb for ; Tue, 15 May 2018 21:08:50 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B981241F5 for ; Tue, 15 May 2018 21:08:50 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id e1-v6so986469pga.6 for ; Tue, 15 May 2018 21:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MAV54btbH+RIQk/nHAhVvDotYEPgYUvMjB8nf/9csck=; b=XV0k5R3aa2QQ9Z+YTl0Lnwb34z8VzgJ+VWYBgtR1aJ7IH0zmpA5BN0wuvrVHOrbFtl og80qq82XuQ4lVbO4hH+q4eLGAltMrRNuq5/O6uzBfIHMHbLeKPnnkBosPgbVeqpi3OI bF/ktbjv9L1HFSYYt5txyA4JZAlLa4N11XLq0Y0I7kmHZM5OHFqIFafJ0N8T1DUydNID 6KzTW+5wlUb0L3sUg3M/rVgnNrsyWkRKkbwvb2kluu8mLqP4b/h9iHOF0G6U5uPlCHhP VuSuynggcgDEyNL7Ib1EMLOYETQuzWsELzGK0p2+Ds9lLJdhdosx+aPmF3TTUXZH+twy IKSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MAV54btbH+RIQk/nHAhVvDotYEPgYUvMjB8nf/9csck=; b=jZevIlBceqrVMkehcOpZCRRHvjqLYBBWYskGSkTic9nJxB0gfCk1TD97JzEex7pF5/ fpIit1jjySBU7Ju5ARKyiIxM5dl1Pls+QMAueVLFZjgt6WYl8t6LcsgdYsXm7sr2DGg3 ZfGPR31PBBgj8+bP6X3lJ0xIkPZl4hire6D5tBDi+3QoDUxP8kuryvqncCp7xqwsWlDb JLEEr21nfVQdhvjYR12J8WjZMyaT1WugebwDq0dboTcgZ1fLm8k/OCefX+quPMCms3f+ 4fe4b2bC8Ok0axw047a6nKliQRWvMWpE9U4Gbj/hds2Q/eKReN8uPwXaM/30X8+rCJfp UCrA== X-Gm-Message-State: ALKqPwe26FBrXJw1LOf9LHl8ZG1Lr+B4H0B1ikeQIc8zRgEgNTguSc9r 3fb4+8G9iQpebIXG3fGmD+lB7oE= X-Google-Smtp-Source: AB8JxZof72M/xSTEQxW+Q2MLd61i3mCQa55f2r+dURHQJQKrhr3ypepe+70xckrhGQqK2S1VT6bSlQ== X-Received: by 2002:a65:4549:: with SMTP id x9-v6mr12808622pgr.158.1526443729155; Tue, 15 May 2018 21:08:49 -0700 (PDT) Received: from aspen.local (63-140-93-6-radius.dynamic.acsalaska.net. [63.140.93.6]) by smtp.gmail.com with ESMTPSA id u10-v6sm1410941pgp.32.2018.05.15.21.08.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 21:08:48 -0700 (PDT) To: tls@ietf.org References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> From: Melinda Shore Message-ID: <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> Date: Tue, 15 May 2018 20:08:46 -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: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 04:08:53 -0000 We've had this discussion already, at terrific length. To my knowledge it's still the case that nobody intends to implement the proposed changes, and it's still the case that should there be interest in implementing the new functionality there's the option of a new extension. At any rate this is starting to feel like abuse of process. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Tue May 15 21:22: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 4E256127871 for ; Tue, 15 May 2018 21:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 EWCQT0myPzS6 for ; Tue, 15 May 2018 21:22:43 -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 3498D127869 for ; Tue, 15 May 2018 21:22:43 -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 4F8E57A3309 for ; Wed, 16 May 2018 04:22:42 +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: <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> Date: Wed, 16 May 2018 00:22:41 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <86E426FA-9F05-4B5C-A51A-44723C46AB26@dukhovni.org> References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 04:22:44 -0000 > On May 16, 2018, at 12:08 AM, Melinda Shore = wrote: >=20 > At any rate this is starting to feel like abuse of process. I was simply following a security AD's suggestion from today's earlier thread with the AD's authors and chairs: > Therefore, if you want to make that change, you need to persuade the = WG. I still think that the WG has not had a chance to fully consider the specific issue of reserving the two bytes as part of the present remediation to remove the unwanted (by anyone of us) unilateral client-side pinning. The proposal is conservative, and does not contradict the consensus to remove pinning for now. It just leaves the door open going forward, at negligible cost (two bytes on the wire in bandwidth, and zero in implementation). Therefore, based on the above advice, I am giving the WG the benefit of the doubt. --=20 Viktor. From nobody Tue May 15 22:18: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 A0687126C19 for ; Tue, 15 May 2018 22:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 7guQnT-OoKy2 for ; Tue, 15 May 2018 22:18:40 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::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 331EF124234 for ; Tue, 15 May 2018 22:18:40 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id u6-v6so1412421pls.9 for ; Tue, 15 May 2018 22:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5ksYwzYF9HVGRHFh1Q/kjNspmqT+GRuul4YYOMIat54=; b=00MK9pwoHyoXRrhYJsmFqtDY/dd/37ha4KeCmKTfbGpzRcrr3EAJBGl+qN53LlDDAV ahPZtg0RoaDUTsk7gGIaw5XA8OzPWMf5z1BUBByw5OMShsh25VsF1ickV0aLlWC7Hwwy Di1BfmeVeqP9vz1BSLrSnrcL7QK+Ud08Pv2MxpikkAZHxYxo8KJeJ8MKJlFW6hzNXunl T0ebEbYg2bJLJgbrI2/I7oNmj4K8nvb7E2RXR1uE11s8Gj54EifVP9C9SqjZVPPEMGUe ekTUIFF+AHLCVp42IhXFDFOfBxf/+6CvoVRBaKWNlue4qQe6SDsgQFmaJz343WuMDf72 tSGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5ksYwzYF9HVGRHFh1Q/kjNspmqT+GRuul4YYOMIat54=; b=gFutF2K2DW7Jw7siaQR0ltAfpH37NS+prBa75zkli+g8Ft3fGKR5kL6eFWpbEUNEQI s8/l5BpkpPLDbu6LlZ5MBM1AsbDHvXj9Hah2VqSYhlY8MdXJb7/q454M1CaZbQCsRRpd HgGykcjr0YS/OopVrSnUia40MpAGTOJQwmAB42u5CZZ+GSrKxS37D8xmpBLfQq9FsFH9 YUt4nwDJQxPCDvXtSxBzLQSIjpX9ny1DizzAjUsWdvey/5AvzFR0pBSOutZOUKI8z3GA jaYnyVxJfQ2H6RIlVzVvjURmE8ReooguaMHry+i58M50Zq+NDvLzophLWLjw+KAG1l6l RU3w== X-Gm-Message-State: ALKqPwfCHSHZogTBEDjSr1FSraX7tP2lAhJptqWqBh1TDzovMtMHYcdK cAPdr5cPuCVjKGfwRcBshfEI64U= X-Google-Smtp-Source: AB8JxZodUCDSRXDqaJ1L/y9qS0JiF3zxZTYwzkSuZ3DP6TBsaYIy54WM6qdgNzUOTw1xP2tRSDHH8w== X-Received: by 2002:a17:902:74c9:: with SMTP id f9-v6mr17859455plt.385.1526447919295; Tue, 15 May 2018 22:18:39 -0700 (PDT) Received: from aspen.local (63-140-93-6-radius.dynamic.acsalaska.net. [63.140.93.6]) by smtp.gmail.com with ESMTPSA id m22-v6sm2359951pfg.20.2018.05.15.22.18.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 22:18:38 -0700 (PDT) To: tls@ietf.org References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> <86E426FA-9F05-4B5C-A51A-44723C46AB26@dukhovni.org> From: Melinda Shore Message-ID: <0f489d9f-ef61-90fe-36fa-da0016fc03d3@nomountain.net> Date: Tue, 15 May 2018 21:18:36 -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: <86E426FA-9F05-4B5C-A51A-44723C46AB26@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 05:18:42 -0000 On 5/15/18 8:22 PM, Viktor Dukhovni wrote: > It just leaves > the door open going forward, at negligible cost (two bytes on the > wire in bandwidth, and zero in implementation). I would be grateful if you would have a consistent story on this. Clearly, it's not just two bytes, or there wouldn't be a perceived need for them. It's two bytes plus the associated semantics and processing algorithms. In the event that anybody has an interest in implementing something along these lines the offer to work on an extension to support it still stands. At any rate, this horse is long-since dead, and you're veering into abuse-of-process territory. Your proposal has been discussed at length on the list, it's been discussed at length off the list, and there is still no consensus to modify the extension to support your use case. And as a reminder, "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated." Melinda -- Software longa, hardware brevis From nobody Tue May 15 22:34: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 1AE2F127867 for ; Tue, 15 May 2018 22:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 ql_k_Jcj5GLf for ; Tue, 15 May 2018 22: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 B353A124234 for ; Tue, 15 May 2018 22: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 AF3A67A3309 for ; Wed, 16 May 2018 05:34:02 +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: <0f489d9f-ef61-90fe-36fa-da0016fc03d3@nomountain.net> Date: Wed, 16 May 2018 01:34:01 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> <86E426FA-9F05-4B5C-A51A-44723C46AB26@dukhovni.org> <0f489d9f-ef61-90fe-36fa-da0016fc03d3@nomountain.net> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 05:34:06 -0000 > On May 16, 2018, at 1:18 AM, Melinda Shore = wrote: >=20 > Your proposal has been discussed > at length on the list, it's been discussed at length off the list, > and there is still no consensus to modify the extension to support > your use case. You say that, but there are ~5 people on each side woh've expressed an opinion on pinning one way or the other. And the original consensus call did not even esk the question at hand. Rather it was whether to specify pinning or not. Not whether to reserve space to do so later. Subsequent discussion has been the same echo chamber of Eric, Rirhard and you on the one hand, and Paul, Nico and I on the other. Perhaps at this point we might actually hear from some others. > And as a reminder, "Rough consensus is achieved > when all issues are addressed, but not necessarily accommodated." Here I agree, but things like unaddressed downgrade attacks are also a factor that is supposed to tilt the scales. > On 5/15/18 8:22 PM, Viktor Dukhovni wrote: >> It just leaves >> the door open going forward, at negligible cost (two bytes on the >> wire in bandwidth, and zero in implementation). >=20 > I would be grateful if you would have a consistent story on this. > Clearly, it's not just two bytes, or there wouldn't be a perceived > need for them. It's two bytes plus the associated semantics and > processing algorithms. In the event that anybody has an interest > in implementing something along these lines the offer to work on > an extension to support it still stands. The story is quite consistent. Applications that have no need for pinning pay no cost as claimed. Applications that need it, can't use the present specification at all, but would be able to at the cost of storing the pins, and requiring the extension when pinned. Nobody pays an extra cost they could otherwise avoid. --=20 Viktor. From nobody Wed May 16 02:30: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 C32DF129C6D for ; Wed, 16 May 2018 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, 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 2rz75ysGXd-a for ; Wed, 16 May 2018 02:30:48 -0700 (PDT) Received: from fnsib-smtp01.srv.cat (fnsib-smtp01.srv.cat [46.16.60.187]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB9E1200E5 for ; Wed, 16 May 2018 02:30:47 -0700 (PDT) Received: from webmail.juaristi.eus (vxmah-40.srv.cat [134.0.13.71]) by fnsib-smtp01.srv.cat (Postfix) with ESMTPA id 0F02480BA; Wed, 16 May 2018 11:30:45 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 16 May 2018 11:30:45 +0200 From: Ander Juaristi To: tls@ietf.org Reply-To: a@juaristi.eus Mail-Reply-To: a@juaristi.eus In-Reply-To: <8ae36587211182108801d686475474d2d34c9084.camel@redhat.com> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> <8ae36587211182108801d686475474d2d34c9084.camel@redhat.com> Message-ID: <6ce06cc0b8e699aba0578b75618d30a0@juaristi.eus> X-Sender: a@juaristi.eus User-Agent: Roundcube Webmail/1.1.4 Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 09:30:52 -0000 El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: >> >> Good to know. Does any implementation other than OpenSSL support >> external PSKs? How do you distinguish between external PSKs and >> resumption PSKs? > > gnutls does. For external PSKs It checks for ticket age being zero and > the username/identity within acceptable bounds. Hey Nikos, I remember we had this discussion, but wanted to transfer it to the list as even though I believe that approach will work almost always, by reading the current draft my understanding is that being the ticket age zero is no more than a hint that it *might* be a PSK. What's wrong with trying to decrypt it first and then if decryption fails treat it as an external PSK and look up its identity in the database? GnuTLS encrypts the tickets with EtA so with "decrypt" I mean checking the MAC first, and then decrypting. Isn't this a stronger check? These and all the other mentioned checks are not mutually exclusive. You could check the ticket key name first before even trying to verify the MAC to discard malformed tickets very early in the game. Another option to remove some ambiguity out of here would just be to change the draft to say that externally set PSKs MUST have a ticket age of zero (rather than SHOULD). This way a server can instantly recognize an external PSK. A real ticket can never have an obfuscated ticket age of zero, right? Or it can? I'm curious to hear what folks here think is wrong with either approach. From nobody Wed May 16 04:32: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 8886812E87B for ; Wed, 16 May 2018 04:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8J0mKvioBh9F for ; Wed, 16 May 2018 04:32:26 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2332012E8D1 for ; Wed, 16 May 2018 04:32:26 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id j20-v6so200807pff.10 for ; Wed, 16 May 2018 04:32:26 -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=RL3Kes9K3wq0T+VbY5LgR6wmx8SpVeTSNSPiCgT791Y=; b=XvJV2JHDZZTqgqQGwkQY3i095mD4mjyofyuEb7f2I3Fz0NIGR4OjUqUOZNUoEXwWUl BGeEAPW3b3bTdbhmedBNxaCqmKtNebe4XunB6whTwVg/HB23eGuL0IcE/oopmmDgzczq fupwV0btQUYA6n41j58JEQuiEL88JTgP06bNW0tFzymb51xuYsLO1v3hsWYgfJFcXgAM /mS8lTJuOOepElLj7byZbBHKHp5StpZEKvAwi1xVPv5hRoVcRoIZCHkCeiPVQzpC5RC4 1zebutdyeW/lLIUSOFouHamQavmf6Ec2o4L1lfE42bD32WQPMCAH8vSwU47UpdLCxqqS Gotg== 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=RL3Kes9K3wq0T+VbY5LgR6wmx8SpVeTSNSPiCgT791Y=; b=a9C1CGO7jmH6gaoO8/KZ2yzigHHH7K+kzeQD+5WmMd2IZd4oDGbI5DdxTiLpz+bzse Yw5nKlbDv89mti7NWy8GqhLp8kgc/SHHrvG7hlY43/JzR5qWVG1BGFA6AqUHfR5LOla9 dzdudzy/hEapy0FA2Lq800N42kqBUaT8Fel3bBKRMca0Ppydc92L6CNTeV1m6NhBGEO2 Cv0VHinrxVcX0qW1qrISigry/6h8Vyu/g5ENQ4Kq66YZuhMAzbIm1fM4AY4WbIFdFnEG ab+vLFnlMhN5ywo1n56J+S45/VZfwkHIZIgkJl2zEUHwdoEeLgMLKOMz/oNxwFraWUIW lJLg== X-Gm-Message-State: ALKqPwduOsVZMWnEMrhP0xWNlNuGeVzqgYm3xKOEc9jRPyhJcIx+ZJcP u7hNlSNe7Ms3iM4Sq07qMpZUNgj8n7FHQic2mpVhULZu X-Google-Smtp-Source: AB8JxZpK7r7gpHlfNig/M1C1zarhyKoKHoYX9Te+VtOEIC0qh9KaZDjldKbvK69rtuz8oEZXPeACG+WvgLTXBViXC4o= X-Received: by 2002:a62:e0cf:: with SMTP id d76-v6mr588695pfm.52.1526470345301; Wed, 16 May 2018 04:32:25 -0700 (PDT) MIME-Version: 1.0 From: Thomas Lund Date: Wed, 16 May 2018 13:32:14 +0200 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 11:32:28 -0000 FWIW: I support the changes proposed by Viktor and others. In particular, I support reserving 2 bytes for which the semantics will be defined in a separate draft. For me, the advantages of this proposal outweighs the disadvantage of having to reserve 2 bytes that might, in worst case, never get used. From nobody Wed May 16 08:02: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 0179012EAC1 for ; Wed, 16 May 2018 08:02:03 -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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvjM5b09ng2f for ; Wed, 16 May 2018 08:02:00 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 404D812D95E for ; Wed, 16 May 2018 08:01:59 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id q4-v6so2722319ite.3 for ; Wed, 16 May 2018 08:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JXge/VC4irtCInoJa4wHM8JjYXe/RpFjhW2YmUt6W+Y=; b=WY1jWSUrv7Xu+W5id/tFyx6Cin4oLrqDitC2mvDx7f7jcwLd1WfUrtHUhGH5PGyPlu BPH4Kpx2swlsTHotFXiTPrxZhJ09FZloitSM6M4G52jIWd+QLWuO4gKtcEBgS8VadogS +wexwGtEtI93yTWFnSuVwmim0rfKE8kFblqIvxCBt+VPdUYNOaUD54lSC7RipR6E580Q boRPxTuQqQoAXNGyBoA4rJMr86q4+vK9a1z4mspEDCdQHwJ2sXpjgu0R2lPgYHYyhMc9 tvysxe+3dNxTviARyTh6x6A0kbVTQPlXiklLurZL51d7TecsHxZRR9mbGyXvGlweeIdN TlNg== 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=JXge/VC4irtCInoJa4wHM8JjYXe/RpFjhW2YmUt6W+Y=; b=q+qMbiq6Scc9CA2XQw4M2okTOwuDfGqcNu5XJVXlpGsNFyd2Scvzh6OOYTkRzKlHkG eMDObaELQgpkiwXQT8DEwWSPp7RpujtiCRxGVqVPkRqceyHM0OdVB5xHYAndlmYx66yN tPdzCLmoV0cukFWoDlCJVtZlRICaUgVq8RWEiOj0GERpW7NC1MwSTbTf61YRiS7fZUZE vS6DboBVo1IqF9C+LvA5YpmLXD420LfL+ttI3ahbe7ylPSNpYhqe4c+orvqMegQgN7S4 Dx7rNJOjlFFmlmqIF2U/K85/GzgaW7jBZdPtC6damDwXo7dNIXIuJ6STdDag7ByaFnnm 6amw== X-Gm-Message-State: ALKqPwdMIBnlvr63fWD9MpD0RGWS4cPeyh86FaF69ZdKAGPfZPx2Rd6P /NCoQC9y+XDOGiT8w1A9XufLL2BHZ88ApHXXIXI4Pg== X-Google-Smtp-Source: AB8JxZoiyD73MD+2kh0t6kcICBqEfmkkDxG28d+5YEIHzVbjUvBTIGg353cJ5bzIRHmL6vWNOtKmden87br392QeUD4= X-Received: by 2002:a6b:9704:: with SMTP id z4-v6mr1555945iod.120.1526482918537; Wed, 16 May 2018 08:01:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:8cd8:0:0:0:0:0 with HTTP; Wed, 16 May 2018 08:01:18 -0700 (PDT) In-Reply-To: References: From: Ted Lemon Date: Wed, 16 May 2018 11:01:18 -0400 Message-ID: To: Thomas Lund Cc: "" Content-Type: multipart/alternative; boundary="0000000000001d8f5d056c540088" Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 15:02:07 -0000 --0000000000001d8f5d056c540088 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no pony in this race, but FWIW ~5 people on each side represents a lack of consensus. A lack of consensus means that the work doesn't happen in the working group. Thomas, your response (sorry to pick on you!) illustrates another consensus issue: consensus exists when all technical objections have been addressed. Melinda made a pretty serious technical objection. Your response is not responsive to her objection. She explicitly said that her objection was not the two bytes. So from the perspective of consensus, it's as if you hadn't sent an email message=E2=80=94an accurate evaluation of consensus wo= uld not take what you said into account at all. On Wed, May 16, 2018 at 7:32 AM, Thomas Lund wrote: > FWIW: I support the changes proposed by Viktor and others. In particular,= I > support reserving 2 bytes for which the semantics will be defined in a > separate draft. > For me, the advantages of this proposal outweighs the disadvantage of > having to reserve 2 bytes that might, in worst case, never get used. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001d8f5d056c540088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no pony in this race, but FWIW ~5 people on each si= de represents a lack of consensus. =C2=A0 A lack of consensus means that th= e work doesn't happen in the working group.

Thomas, = your response (sorry to pick on you!) illustrates another consensus issue: = consensus exists when all technical objections have been addressed. =C2=A0 = Melinda made a pretty serious technical objection.=C2=A0 Your response is n= ot responsive to her objection. =C2=A0 She explicitly said that her objecti= on was not the two bytes. =C2=A0 So from the perspective of consensus, it&#= 39;s as if you hadn't sent an email message=E2=80=94an accurate evaluat= ion of consensus would not take what you said into account at all.

On Wed, May 16= , 2018 at 7:32 AM, Thomas Lund <thomas.lund+tlsietf@gmail.com<= /a>> wrote:
FWIW: I support the= changes proposed by Viktor and others. In particular, I
support reserving 2 bytes for which the semantics will be defined in a
separate draft.
For me, the advantages of this proposal outweighs the disadvantage of
having to reserve 2 bytes that might, in worst case, never get used.

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

--0000000000001d8f5d056c540088-- From nobody Wed May 16 09:01: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 C43D812AAB6 for ; Wed, 16 May 2018 09:01:01 -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 kwLC-HatQOUP for ; Wed, 16 May 2018 09:01:00 -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 F18BB1200FC for ; Wed, 16 May 2018 09:00:59 -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 CF38F7A3309 for ; Wed, 16 May 2018 16:00:58 +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, 16 May 2018 12:00:57 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <7B17CD16-F299-4C5F-8F25-348F9131158A@dukhovni.org> References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <795f96a1-e2b2-6a89-555c-c856d07838cf@nomountain.net> <86E426FA-9F05-4B5C-A51A-44723C46AB26@dukhovni.org> <0f489d9f-ef61-90fe-36fa-da0016fc03d3@nomountain.net> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 16:01:02 -0000 > On May 16, 2018, at 1:34 AM, Viktor Dukhovni = wrote: >=20 >> I would be grateful if you would have a consistent story on this. >> Clearly, it's not just two bytes, or there wouldn't be a perceived >> need for them. It's two bytes plus the associated semantics and >> processing algorithms. In the event that anybody has an interest >> in implementing something along these lines the offer to work on >> an extension to support it still stands. >=20 > The story is quite consistent. Applications that have no need > for pinning pay no cost as claimed. Applications that need it, > can't use the present specification at all, but would be able > to at the cost of storing the pins, and requiring the extension > when pinned. Nobody pays an extra cost they could otherwise > avoid. Melinda, I'd like to hear whether the above addresses your concern, or whether there's a remaining issue along these lines that we've failed to cover. If so, it would be great to spell it out. As it stands, I think that the issue of additional semantics, costs, etc. is addressed. The only cost is the two bytes, and there is no semantic burden in applications that don't already need pinning to make meaningful use of the extension. --=20 Viktor. From nobody Wed May 16 09:20: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 CA07B127286 for ; Wed, 16 May 2018 09:20:57 -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=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALlWYaBFVGrw for ; Wed, 16 May 2018 09:20:55 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B04120227 for ; Wed, 16 May 2018 09:20:55 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id e185-v6so1489682ita.0 for ; Wed, 16 May 2018 09:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ibNQ+81rs4IVWfW6e3FJPo4x5SF0i7RMxrJaV+IQPYY=; b=IwX0E7Yicv05UaevTLHgDxYX5KDGsTveQqMS2IvQ7sJ5/JR1y+DgQuOGiyQz9CqySv ywG0Vy7FEnPEL7WrgBOtWwFZYVmAGJvwWOrkayHtYELi6RO6ifulr2cY1U1R9m/nKYpj pG+ZkCF9K9SLG+poZRujIPRoA/fI3tGTRWtBQ= 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=ibNQ+81rs4IVWfW6e3FJPo4x5SF0i7RMxrJaV+IQPYY=; b=hWTpE9ek4oAgQW8vqNaaAmM8SwFG9qTZouhJcFjw7QQWYrh0kd17eVuwQjKdUKl8Sz TtaktluPA4+MgmrxCRhwC5XPefx+YcE0oPb9W8vNY2M3fJEDzVBWAfjLmJRwH8QVYhcJ 3lfJjxVXkBgoOJsX3DGO1po4x6yQkaiBNqxeA1Rqdi8TC8oj6eOBh2GuYYJFs0XyA3ET fl8NVuqcA/ZaKwfxuE0PIj+rHUYknlxGaWN4AIfjrWKtQbJc1l6RDR/GkFLXAgCf6gH6 gn5ulPk4YuSchWwBlCbJjew3TG6+b9bL8Us20BZOjSTmaMpYjyg2Ncv0L2LHhHJjFF5R H3Fg== X-Gm-Message-State: ALKqPwcD0dCgTDOQ+/OT0NzbjbgECawmpsRAdwbA+1n+AuYoPpZO4Ege ZePt0dHV+AKACxEe6TWanZj/ibecMtapyfSo7rKMlw== X-Google-Smtp-Source: AB8JxZqTTjOi/ps0lc0L2xSr3syECfG5jg2lKXvug1HpYGFDJfC/3lADODM4+ehxwUMWVxy4/rlyioX1tXbrKGu0BnA= X-Received: by 2002:a6b:b04e:: with SMTP id z75-v6mr1678600ioe.222.1526487654806; Wed, 16 May 2018 09:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6c46:0:0:0:0:0 with HTTP; Wed, 16 May 2018 09:20:34 -0700 (PDT) In-Reply-To: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> From: Tom Ritter Date: Wed, 16 May 2018 11:20:34 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , Sam Hartman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 16:20:58 -0000 On 15 May 2018 at 22:14, Viktor Dukhovni wrote: > I therefore appeal to the readers who've so far stayed silent on this > issue, to lend support to paving the way for a more broadly applicable > downgrade-resistant protocol, by supporting the inclusion of a two byte > field for that purpose. Sorry; but it's disingenuous to ask people who have stayed silent to only speak up if they support you. I have not followed this draft due to lack of time. I've tried to read up on the pinning issue. As I understand it: i) A server can send a Trust-Anchor-less cert with this extension, and a supporting client can validate the DNSSEC chain and accept the certificate. ii) A server can send a chain of certs with a Trust Anchor, and since this is how TLS on the Web works today, clients will accept the certificate. iii) An attacker can get a fraudulently issued certificate from a Trust Anchor, and use that to impersonate a server who implements (i), even though they tried to ignore the WebPKI. To prevent the attack, Viktor and others propose allowing a server to pin the extension for a period of time; so that clients will not accept such an attack. They argue for allocating two bytes to specify pinning; and say they will have a later draft that explains what they mean. There's a lot of emails on this topic; but I haven't seen how you would fit the supported lifetime into a uint16. Can't be seconds (only 18 hours)... Minutes? (45 Days limit?) I would not care for anything more complicated like some sort of double-like reduced-precision-as-your-magnitude-increased. I find ekr's characterization of the usage of this draft apt: > 1. Assertive: To avoid having to engage with the WebPKI > 2. Restrictive: To protect yourself from compromise of the WebPKI. The objections to the uint16 solution to the concern seem to be: a) no one's said they're going to implement that feature b) it's more complicated for people to implement the draft c) we can add a new extension to do pinning d) generally pinning specifies a lot of additional fields that are not present here (report-only mode, report-uri, includeSubDomains) e) it's easy to brick oneself f) it's possible for attackers to brick you g) This draft is intended to address Use Case 1; not 2. I am very sympathetic to the concern raised. I agree the attack is real and considerable and it should be protected against. I am entirely unswayed by arguments (a), (b), and (g). Bricking (e) and (f) is a real concern. While web browsers have a mechanism to automatically resolve bricked sites in significant situations (it's not a pleasent one, it's a whole browser update) non-browsers do not. Presumably forward-thinking developers would make it realtively easy for admins to do so ('run this command' or delete the line from this .txt file') - it still requires administrative action and there's a long tail where that won't happen. I am most swayed by (d). I think any pinning mechanism needs a report only mode and a reporting mechanism. The comment > There is no role here for bells/whistles like "testing" modes, because > there's no way to authenticate a "testing" mode, that'd be just another > downgrade vector. Seems to miss the point of a testing mode: it's not for when you're attacked; it's so you can confirm your deployment isn't messed up in some unanticipated way. I only partially agree that a testing mode in DANE makes sense - in the same way that a testing mode for HTTPS makes sense. When deploying HTTPS (no HSTS, no HPKP) we rely on tools like SSL Labs to tell us that our cipher configuration doesn't brick Java 6 and we're sending the right intermediates. A Report Mode for clients might be able to tell us the same information. I don't fault DANE for not doing this any more than I fault HTTPS. HSTS' failure to do was covered up by CSP. But we should repeat the mistake because we made it before and things eventually seemed to work out. Painfully, there is no effort for pinning in this WG. There's draft-sheffer-tls-pinning-ticket which looks quite clever to me; but it looks like it was last discussed in early 2017 and no clear support for it emerged. An argument could be made that if we're going to have a pinning extension, it should work for all forms of key agreement in TLS: Certificate, DNSSEC, Raw Public Key, PSK (maybe? that might not make sense.) That argument would effectively make the work of such an extension a few orders of magnitude as great and probably kill the effort. On the balance, I support adding the two bytes. I would argue that the top-most or bottom-most bit should be used as a testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a second draft) specifying the policy should add a generic problem-reporting extension that allows one to post a description of errors encountered. But these arguments do not hinge my support of two bytes. I have no expectation or opinion about how this should affect WG proceedings. There was a Last Call, I don't know IETF process where there's disagreement like this, people are arguing about what constitutes consensus, I don't know if this email 'counts'. -tom From nobody Wed May 16 09:34: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 1F95712D940 for ; Wed, 16 May 2018 09:34:32 -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 wIDk2AVp5oll for ; Wed, 16 May 2018 09:34:30 -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 0558212D88A for ; Wed, 16 May 2018 09:34:29 -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 AE1927A3309 for ; Wed, 16 May 2018 16:34:28 +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, 16 May 2018 12:34:27 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 16:34:32 -0000 > On May 16, 2018, at 12:20 PM, Tom Ritter wrote: > > On the balance, I support adding the two bytes. Thanks for responding, and sorry to frame the request as "please support", I've previously tried to careful and ask people to respond with their comments whatever they might be, and should have done so this time too. > I would argue that the top-most or bottom-most bit should be used as a > testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a > second draft) specifying the policy should add a generic > problem-reporting extension that allows one to post a description of > errors encountered. But these arguments do not hinge my support of two > bytes. For the record, the reason that we're confident that two bytes are enough is that DNS TTLs already take care of sub-hour continuity for any provided TLSA records. So units of hours are natural, and make 16 bits quite sufficient. We've given the need for other pinning properties from other STS-like protocols some thought, and it turns out that none apply. IN particular a testing mode is not possible with this extension. Such a testing mode would itself be a downgrade attack. Any testing mode for DANE would have to be specified as a new element type for the TLSA RRset to be authenticated via DNSSEC, not as a WebPKI-authenticated element of this extension. The extension is a channel to deliver security-relevant data from DNS, and the pin when specified, would just pin support to continue to provide the channel. The STS-analogy is the closest available but it is not a faithful one, the requirements here are much simpler. -- Viktor. From nobody Wed May 16 10:59: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 3346D12D942 for ; Wed, 16 May 2018 10:59:41 -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 kb0kaE0amiF2 for ; Wed, 16 May 2018 10:59:39 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DD212025C for ; Wed, 16 May 2018 10:59:39 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fJ0i7-0008Sv-Ls for tls@ietf.org; Wed, 16 May 2018 19:59:36 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fJ0i4-0000NM-3z for tls@ietf.org; Wed, 16 May 2018 13:59:32 -0400 Received: (qmail 30165 invoked from network); 16 May 2018 17:59:30 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 May 2018 17:59:30 -0000 To: tls@ietf.org References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 16 May 2018 18:59:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hcOWX8SG2Gc6GLVDTikGWN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxKglXRzceas2n8EVfBEjSHEh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2yu59OQA2zKnT1Yg5KX9v7/vRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7riSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaK23UAv7GcwTBBtwX3De/ZnQspW6PWtFljIeoG6OsM9IZR9Ue3lpE69 Pu4f8GvJnjZgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6NV+QBQRtMmDe05Nd2KjhCWh+wlfAS2SbL4bvnSO/22UljVXJvA/UYvwB FtKNH4GuovqkeNXjbckt44+3VT5KSZRins15oKFWvUk5C9olBXB1qSIEae5DZ9cZ02JHi6IQw6nI oDr0sXUZ7YZoZ/GZ+gNl/9zCFdWYNKOuzgS95TNz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 17:59:41 -0000 On 5/16/2018 5:34 PM, Viktor Dukhovni wrote: > For the record, the reason that we're confident that two bytes are > enough is that DNS TTLs already take care of sub-hour continuity > for any provided TLSA records. So units of hours are natural, and > make 16 bits quite sufficient. The way I understand it, your proposal is not so much to "reserve 16 bits" but rather to "include a 16 bit field defined as the pinning time in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored on receive" in the current TLS DNSSEC draft, let it be published as RFC, and publish very soon a draft that defines the 16 bit field as the pinning time in hours, and presumably explains how to avoid the usual pitfalls of pinning. Do I understand correctly? -- Christian Huitema From nobody Wed May 16 11:14: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 9EAB412025C for ; Wed, 16 May 2018 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bn-bkdgqR49X for ; Wed, 16 May 2018 11:14: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 0C8421243F3 for ; Wed, 16 May 2018 11:14:04 -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 376227A3309 for ; Wed, 16 May 2018 18:14: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: Wed, 16 May 2018 14:14:03 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 18:14:07 -0000 > On May 16, 2018, at 1:59 PM, Christian Huitema wrote: > > The way I understand it, your proposal is not so much to "reserve 16 > bits" but rather to "include a 16 bit field defined as the pinning time > in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored > on receive" in the current TLS DNSSEC draft, let it be published as RFC, > and publish very soon a draft that defines the 16 bit field as the > pinning time in hours, and presumably explains how to avoid the usual > pitfalls of pinning. Do I understand correctly? Yes, with the slightly more precise semantics you mention of "set to zero on send and ignored on receive" and zero means "do not pin". This is we expect better then just reserving an undefined field. -- Viktor. From nobody Wed May 16 11:38: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 B5C2312E035 for ; Wed, 16 May 2018 11:38:37 -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 Q7M5BOvp1_Yz for ; Wed, 16 May 2018 11:38:36 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951591242EA for ; Wed, 16 May 2018 11:38:33 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fJ1Jl-0008NO-SF for tls@ietf.org; Wed, 16 May 2018 20:38:30 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fJ1JF-0002Di-Ro for tls@ietf.org; Wed, 16 May 2018 14:38:28 -0400 Received: (qmail 22593 invoked from network); 16 May 2018 18:37:56 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 May 2018 18:37:56 -0000 To: TLS WG , Viktor Dukhovni References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 16 May 2018 11:38:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vxT5TvvYWs0kITZMaRGGq1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxzK/2YutQ0/1rDqiZKKDanUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2sYjO05mTPID+/6Aj9ZzRI/vRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7riSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaI92oKPQLqz48CICfl7iTSLr3fzl8H3R5eKHDxrOpN1QMt/npZtaoS2 JdlS9rVuaXqU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwR5w5EnMvejU8iZPQY1HEgdeggKW28pboyZCmKkHUYXamuQK1+bsb0cORH 6aKYcpJOnXjBtq9Nz6QfirzlAbTufXtB4/4Pbrz2QtFuyl+Sh6cuQdsqiiRsJv50Ux/Ji6ukfqb5 R4VemuUI6bcEARsm0OMSEKczB5TPn6HsnyXl5C+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 18:38:42 -0000 On 5/16/2018 11:14 AM, Viktor Dukhovni wrote: > >> On May 16, 2018, at 1:59 PM, Christian Huitema wrote: >> >> The way I understand it, your proposal is not so much to "reserve 16 >> bits" but rather to "include a 16 bit field defined as the pinning time >> in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored >> on receive" in the current TLS DNSSEC draft, let it be published as RFC, >> and publish very soon a draft that defines the 16 bit field as the >> pinning time in hours, and presumably explains how to avoid the usual >> pitfalls of pinning. Do I understand correctly? > Yes, with the slightly more precise semantics you mention of > "set to zero on send and ignored on receive" and zero means "do > not pin". This is we expect better then just reserving an undefined > field. Did you publish the proposed pinning draft already? That would certainly help clarifying the issue. -- Christian Huitema From nobody Wed May 16 12:05: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 1ADDA12E89B for ; Wed, 16 May 2018 12:05:08 -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 WdG9jqazWds8 for ; Wed, 16 May 2018 12:05: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 E394A12DB72 for ; Wed, 16 May 2018 12:04:59 -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 1631C7A3309 for ; Wed, 16 May 2018 19:04:59 +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, 16 May 2018 15:04:58 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <1B0B7427-8669-41A2-855B-1F17BB83F4D7@dukhovni.org> References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 19:05:12 -0000 > On May 16, 2018, at 2:38 PM, Christian Huitema wrote: > > Did you publish the proposed pinning draft already? That would certainly > help clarifying the issue. Only the proposed text defining the interim 16-bit field. The follow-on specification has not yet been written. It has not to date been clear that this would be helpful. A downgrade-protection extension could be written now, but it'd a rather different document if the two bytes are not present in this extension, so we're been waiting for the dust to settle. Is there sufficient interest in seeing such a write-up at this time? If that's what we're really doing, we could just bite the bullet and produce the final document now, with the downgrade protection built-in, revisiting the previous consensus around deferring that work. So I'm reluctant to bring the details of the follow-on work into this discussion, if that's not what we're doing. -- Viktor. From nobody Wed May 16 14:43: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 43A2712D9FF for ; Wed, 16 May 2018 14:43:54 -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 mx_XTlxOY8az for ; Wed, 16 May 2018 14:43:52 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C466A12D96D for ; Wed, 16 May 2018 14:43:52 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id k2-v6so869498pgc.1 for ; Wed, 16 May 2018 14:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Q3w1N9oTFYDPgRWZbFMEfBHNVs6doXCFSQH7OZwwv1Y=; b=c3MhDMKS05d9tS3eynof1+zLpFbW3y5u/tpObFCIpfpb5+w51RwTiUXtOKG/rLwq/2 1nw37Tg6AF7InW1xT99xhtoB2RMSYStBMVj4dDTvSAOqD2mxQi2np/rhtmtZdeXol6aq i8pjfmIp5ngIVxi8RchIcYbFRzRzaQdr0Gj23H4G5WQcWoMMADwIDTHVABV2TiNXN9S8 2xUzx/f6xraAcYoED55+L+nOkBs3PQ101aHMIzTBeXGzSjq1XFGPMsqatBodfnz9VTd0 9FW2M45sWmnKYZgQjiNf0z2J0aJs0hlJ9xiMjSRAU/xlGK8e0bqkgt+w3yy7O581/jMl 7QyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q3w1N9oTFYDPgRWZbFMEfBHNVs6doXCFSQH7OZwwv1Y=; b=HZ+AyTfOnZ7a+GUAhoKsJSLVSD7QX7tVc0PUNUNpgWY07h25ig4swdrHIHFoi0d3up ujn41taYBJxi99/+l2ezrzewVfyfEk4u2aPuM08XFu9cgSI33iZ1V4q0WEeDtW3u/j/u Rjfr9c8BsL9kTbIBzmNSFAle4QweXS4Jfmokj+eopiPrCou3HAAd8vHFJ5HN/g06BQBb 0ghLUj8O9CLuE50zMXMEDtOrKzCP4ScgFlfwoDLodUTor2XTruataM6EL4PYsvbatH7N cFJ0RIzQ6g4Mqdcz7buMlp9p5X+A26BnboAuPmNjkCcWhBat8BgfpoDlPkIrhIf8kerL MLig== X-Gm-Message-State: ALKqPwc3+g0Icpwy57HwP5M2eAKrYuDTLKq1oaxC6TbH1KI9kArcFanH grTLrBZVPmLUJvJbLPX8azMm9hs= X-Google-Smtp-Source: AB8JxZqoQy452CiypY312PKugS2WEzCFlHOc/s1tC0C/+y7pxlCW+5FH6qKjrKMbeFIO88ujG+Qang== X-Received: by 2002:a63:8f43:: with SMTP id r3-v6mr2066308pgn.10.1526507032087; Wed, 16 May 2018 14:43:52 -0700 (PDT) Received: from aspen.local (63-140-93-6-radius.dynamic.acsalaska.net. [63.140.93.6]) by smtp.gmail.com with ESMTPSA id x3-v6sm7518243pff.87.2018.05.16.14.43.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 14:43:51 -0700 (PDT) To: tls@ietf.org References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> <1B0B7427-8669-41A2-855B-1F17BB83F4D7@dukhovni.org> From: Melinda Shore Message-ID: <6ded6ddc-7a1a-c7ec-a021-177fadd6c325@nomountain.net> Date: Wed, 16 May 2018 13:43:50 -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: <1B0B7427-8669-41A2-855B-1F17BB83F4D7@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 21:43:54 -0000 We really need to get this published, and in the interest of making progress I will not block the addition of two bytes to the extension. I am highly reassured by Viktor's suggestion that they will never be used, as unused fields with murky semantics have never been shown to be a problem in IETF protocols. (<- I don't actually believe that, but hey). I disagree with adding these bytes but I can learn to live with it. Something that actually is a concern is that we now have a working demonstration that refusal to compromise is an effective strategy and that DOSing a document is a good option if you can't otherwise convince other working group participants. This, however, is a problem for the chairs and the IESG. So, onward. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Wed May 16 15: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 B96E912DA44 for ; Wed, 16 May 2018 15:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ceWQr3fmpddc for ; Wed, 16 May 2018 15:20:27 -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 BF1D3126D05 for ; Wed, 16 May 2018 15:20:27 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B4D431E70F; Wed, 16 May 2018 22:20:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1526509225; bh=r0F9E3PJfJp8tW+lWOBl1RbGJZuzWQ6QDWV+I2a8OP8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CcV2CrfTF/rC5w1WbbZ/rcNzISx/m1Na+ROUyJ/CmkX/uQV7HEwmF9A0/+tim8GMa L+LykWbB9qdczibpMRn4dv6v9ap7caQAXF/bPpr6SzdKqjiqCms4IJROl3DoiA6kQP x2+5iPnk4cBs9c5wROd4DdJ70Ukdo5AvEQSc2XswTfmJhe4GNHyuJbJQxhuN+bdDTu ltRy0K3IyE/n7GoGIDBEzHq9QaHiuLMhGYQIg19TOcwTBhr6lZv2n6zVGGOmF4N6EK pDvyhjI8ZgfxpGvo+HVf/bkWPWDm/st0y2wDPRlN5ruC1sH6s0cGhJMtTtyWzcmy2h zfXHxraRh8/mg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2F2B110F7377B; Wed, 16 May 2018 22:20:19 +0000 (UTC) From: James Cloos To: Ted Lemon Cc: Thomas Lund , "\" In-Reply-To: (Ted Lemon's message of "Wed, 16 May 2018 11:01:18 -0400") References: 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: Wed, 16 May 2018 18:20:19 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 22:20:30 -0000 >>>>> "TL" == Ted Lemon writes: TL> Melinda made a pretty serious technical objection. Your response is not TL> responsive to her objection. She explicitly said that her objection was TL> not the two bytes. I don't see anything in her note today which is a technical objection. And I've seen no useful or reasonable objections to Viktor's suggestion. The sixteen bit field harms no one, and when defined and used provides significant benefit to many. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed May 16 15:27: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 19A0612D882 for ; Wed, 16 May 2018 15:27:32 -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 iN8l3Q7cGm5F for ; Wed, 16 May 2018 15:27:30 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCDD126D05 for ; Wed, 16 May 2018 15:27:30 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id n9-v6so893331pgq.5 for ; Wed, 16 May 2018 15:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UOor6iClYGHGtgZNNMgiJ7C+Xkp/dBvgnpOBehfC8fM=; b=zA7FAFWDcF28pYQMgL4iTgebgmedZpO7+Y6cCmdA7bl0f2WebkAhzOJBQsg0hSKBiT HMhHp9XuvDy7HCNHhW2iS0We9Z+IpFZsLxeKUIdbZi3za+89gCtwsOcNK/yz2PLJapcZ 0+tiN8lAdOWH3GoyhZpxaegX0fvs9WWJ3euj293h8Yn6vhrrwT+bjipzY8fj4h25qN1k UvkPxPBYxWqZ+QOMggu0QBqC0tVcSWhDf3dZVkDcknVNMuGmTqhNm49ajlNLXsljz54X MrzQ2fuDxQlmO6LF/1lwWMJfX17ZwL3H1f7TF82TpT15LIpLZBmHqkgNg1Qwu1ZhNs89 QWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UOor6iClYGHGtgZNNMgiJ7C+Xkp/dBvgnpOBehfC8fM=; b=sHi3Lm7IVZpkyb/Fxv8QuD80+c79Omrtt6uQLb0DmWWWnK8KisosgfLe5odX4TX7X1 6bOmPO4xziKN+45ZnYLDKpyzn98swGrlxBbh0YakMZwJJzX36T4ZO9iQDiOQGqRfCOEG Mqgyr5VkCzIB0kdgjOY+pvGlkCJcWbs5Wy/KepA+7qLIBoCtGx25xtoHFTsLM4QUMpQM 5qlqU7XsO5uxkXdQ9Fjr7hniP1d9aByHUFf8JrbtwYB1dZYuiMByDJxFl2L/y4XLwNB2 kUHXCS6+rbnS41ZZM3WCI0amtNCdOBzYsY12cDoKJy3Wwip/N4WIRRELc5Qi/xWcB0bv ZFWw== X-Gm-Message-State: ALKqPwdLG0QNpVeMQUv4l80txjpAbeNMrF4fP78a4PPkhTyd86DA0z/+ sbLrbI0D2YHZNfXELDUCGn6moYM= X-Google-Smtp-Source: AB8JxZqoZGO7oh4b74khxrF3UzJQwFeErJDxGFjxIu4U/wyvUMs7zRtNhlOiU6vF75TpJGaBEP5UNQ== X-Received: by 2002:a65:6151:: with SMTP id o17-v6mr2213317pgv.120.1526509650122; Wed, 16 May 2018 15:27:30 -0700 (PDT) Received: from aspen.local (63-140-93-6-radius.dynamic.acsalaska.net. [63.140.93.6]) by smtp.gmail.com with ESMTPSA id c83-v6sm6536583pfc.111.2018.05.16.15.27.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 15:27:29 -0700 (PDT) To: tls@ietf.org References: From: Melinda Shore Message-ID: Date: Wed, 16 May 2018 14:27: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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 May 2018 22:27:32 -0000 On 5/16/18 2:20 PM, James Cloos wrote: > The sixteen bit field harms no one, and when defined and used provides > significant benefit to many. It is one of the peculiarities of the IETF (and engineers in general, I guess) that when we sit down to design a protocol most people will start talking about data formats, etc. rather than protocol semantics. Allow me to suggest that that's a mistake, and that data formats are secondary to the behavior we expect from a protocol and to the data needed to support that behavior. Don't make that mistake here. And again, nobody has said that they intend to implement the proposed mechanism - indeed, when asked, people have said that they won't. So I'm not really clear on the benefit. I'm compromising as a process matter (this needs to get done) and because it's clear that nobody else will. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Wed May 16 22:32: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 A0EB912E8D0 for ; Wed, 16 May 2018 22:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 gHJgG981lNAY for ; Wed, 16 May 2018 22:31:58 -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 BB9F712E8CE for ; Wed, 16 May 2018 22:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1526535117; x=1558071117; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0sxRG1YOjWmSx10ceJjxsp07Ru94WqIN+xpavkWV+9A=; b=kqpmIYC1hBJoLkez5xnSGlVE2RebHr23cCs7PbSM2ukOKD0UJLeHPP2w U1LjN8fHBqEGhujrjSpaslTNnJE4EinqpuXEvqtebvs0eT7TwNFGc1Nn4 /AP8zuq/JckF8b8MuXBdEvPUQntQLWrD5BNQNcrF7Q23TM6Km0TAHkZyq 0l4G4n6Tr26fDfEssPM1zQ7GXXo6Qh3Mcgp6KhoVXbTmEO2mCPposRSFg PyGSAL+o41iRSpsshq4QN9BEqS25klCQGBt127TnbgvWpyk0qTXt5FsRD P9tCExyj8GpLNxnVe9XSLCcy8qAD/823tAEBkw9QKePsbir3csfzKcApg g==; X-IronPort-AV: E=Sophos;i="5.49,409,1520852400"; d="scan'208";a="11633691" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 May 2018 17:31:54 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 17 May 2018 17:31:53 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Thu, 17 May 2018 17:31:53 +1200 From: Peter Gutmann To: Melinda Shore , "tls@ietf.org" Thread-Topic: [TLS] TLS DNSSEC chain consensus text, please speak up... Thread-Index: AQHT7QmJ5pwEX58AHEq2b2dh7XH0EKQxqj4AgAFEADL//zipAIABP1kU Date: Thu, 17 May 2018 05:31:52 +0000 Message-ID: <1526535112699.78173@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 05:32:01 -0000 Melinda Shore writes:=0A= =0A= >And again, nobody has said that they intend to implement the proposed =0A= >mechanism - indeed, when asked, people have said that they won't. =0A= =0A= Doesn't that resolve the issue then? If no-one's going to implement it =0A= then it doesn't matter how many bits you use. Make it one bit, 128 bits,= =0A= -1 bits, e^i{pi} bits, it won't matter.=0A= =0A= In fact, you could leave the whole RFC blank except for the title, to save= =0A= anyone having to sit down and write it. Like this paper:=0A= =0A= https://arxiv.org/abs/1603.09526=0A= =0A= Peter.=0A= From nobody Wed May 16 22:51: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 66A0812E8D0 for ; Wed, 16 May 2018 22:51: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 gg_7z9LuplyW for ; Wed, 16 May 2018 22:51: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 8177812E8C7 for ; Wed, 16 May 2018 22:51: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 B14327A3309 for ; Thu, 17 May 2018 05:51: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: <1526535112699.78173@cs.auckland.ac.nz> Date: Thu, 17 May 2018 01:51:45 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <6A79D33D-B7AD-49FA-960F-CA5F844DD218@dukhovni.org> References: <1526535112699.78173@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 05:51:50 -0000 > On May 17, 2018, at 1:31 AM, Peter Gutmann = wrote: >=20 >> And again, nobody has said that they intend to implement the proposed=20= >> mechanism - indeed, when asked, people have said that they won't.=20 >=20 > Doesn't that resolve the issue then? If no-one's going to implement = it=20 > then it doesn't matter how many bits you use. Make it one bit, 128 = bits, > -1 bits, e^i{pi} bits, it won't matter. The claim that nobody's going to implement is an expression of = frustration, undoubtedly earned, but not a statement of fact. While no major browser = is champing at the bit to adopt this extension we will be making a more = modest start in other areas in the not too distant future. DANE for MTA-to-MTA did not happen until until ~2 years after the ink = was dry on RFC6698. And yet today we have 209k domains and growing with = DANE TLSA records for their mail server, support for spec in Postfix, Exim, Halon, MailChannels, Cisco ESA (formerly Ironport) has DANE support in = beta, ... Some things take time. Here, the objective is to not close the door on the original scope of = the document by limiting the design to just the use-case of the its initial application. --=20 Viktor. From nobody Thu May 17 07:09: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 8EF81126D45 for ; Thu, 17 May 2018 07:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhW72fA-r2OD for ; Thu, 17 May 2018 07:08:59 -0700 (PDT) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8554D124BFA for ; Thu, 17 May 2018 07:08:59 -0700 (PDT) Received: by mail-wm0-f41.google.com with SMTP id n10-v6so9340253wmc.1 for ; Thu, 17 May 2018 07:08:59 -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=MeBB3599I6W2gZN8gXynHRDpcgzzfAOyQCWnnSpgkKg=; b=NjayNcEtmvl031qzOMvqFgdeVQ3rbWJW5897qJxw2oJDLZHjn2j08jpcypIqPxq8ah Pfkq7uPtisfmCZQr5PdOvJlKcRNdhljAojeuivVQuKpTEa2b8lgc8tsYQNFk9PpzNkF1 SfHIQi0xd0pD7EpswUGBYf3HfYOoiBzT6TTVEYG8/2v0yUHmtgugkmiYP65inFSS2MKR F2nkZ8CU1FbfMTlxazgHDh7tQBA20DaQbzAA5JwJd1Bn6/iBZvpz7ALNz1E3e/Eg7J7F StBjaNPwEMW99P7uik2xHATJikZCpQtQspvB3qisqEoHPKlsNfkDdbQSd43AeHGyza0T ODMg== X-Gm-Message-State: ALKqPwey+xHS97yYz4fV3CH1XbGPKZFuqVadYY7U7ODnHCLDuJ+993e9 oI3lakkQJxk0L4EawTSMXT5b5Fc+bzc= X-Google-Smtp-Source: AB8JxZoI4VKTDUEGMtZvXf1g9ckLJmBewPuIakkr8uBJKy1Hoz4qOXFvVUstN/uOc7gbF63Tt4mQwA== X-Received: by 2002:a1c:6b57:: with SMTP id g84-v6mr1804894wmc.127.1526566137956; Thu, 17 May 2018 07:08:57 -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 z10-v6sm6312119wre.43.2018.05.17.07.08.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 May 2018 07:08:57 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: a@juaristi.eus, tls@ietf.org Date: Thu, 17 May 2018 16:08:56 +0200 In-Reply-To: <6ce06cc0b8e699aba0578b75618d30a0@juaristi.eus> References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org> <8ae36587211182108801d686475474d2d34c9084.camel@redhat.com> <6ce06cc0b8e699aba0578b75618d30a0@juaristi.eus> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:09:04 -0000 On Wed, 2018-05-16 at 11:30 +0200, Ander Juaristi wrote: > El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > > > > > Good to know. Does any implementation other than OpenSSL support > > > external PSKs? How do you distinguish between external PSKs and > > > resumption PSKs? > > > > gnutls does. For external PSKs It checks for ticket age being zero > > and > > the username/identity within acceptable bounds. > > Hey Nikos, > > I remember we had this discussion, but wanted to transfer it to the > list > as even though I believe that approach > will work almost always, by reading the current draft my > understanding > is that being the ticket age zero is no more than a hint > that it *might* be a PSK. > > What's wrong with trying to decrypt it first and then if decryption > fails treat it as an external PSK and look up > its identity in the database? GnuTLS encrypts the tickets with EtA > so > with "decrypt" I mean checking the MAC first, > and then decrypting. Isn't this a stronger check? Decrypting a ticket may not always be possible. For example, server keys may get rotated, or a server may receive key which were destined for another server in the pool. > Another option to remove some ambiguity out of here would just be to > change the draft to say that externally set PSKs > MUST have a ticket age of zero (rather than SHOULD). This way a > server > can instantly recognize an external PSK. A real > ticket can never have an obfuscated ticket age of zero, right? Or it > can? I think that ticket age could be zero even for non-preshared keys (not very likely though). A field which could potentially be used to distinguish tickets is the key_name of an rfc5077 formatted ticket. regards, Nikos From nobody Thu May 17 16:44: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 E493112420B for ; Thu, 17 May 2018 16:44:45 -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, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, 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=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 PfifTngehQl9 for ; Thu, 17 May 2018 16:44:43 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.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 4B1FD120454 for ; Thu, 17 May 2018 16:44:43 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-10.bemta-12.messagelabs.com id FC/94-21411-AE31EFA5; Thu, 17 May 2018 23:44:42 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTbUhTYRTH99x7d3cNF7c7zdNyWavodeaiQJG o/GBGCAV9SbS66nUbbXPtzjI/lFQWvpW4WSmZhi/UqAgrtOzFLHsv07Iow1AHZSVaBmHRpd09 0+rb75z/Oc//PA/nYUjuDa1lhFyX4LTzVj09heqMrttkGNJIKTGFB+fEdlWfpGO/nLtLxH7rL EJryKT9zxtVSfX140RSd90V5UYyRWmxp2fnbleaG8s6aMfhNbnSJR+Zj3pWFaEpDMWWkHB/rI uWA44tI+CqNKbCwXsEpVUDVBEKYWg2Bl7duE/IHMauhQ8PnillJtm54JbeqWTWsIlw9NZBCte sg7slx1WYE6C3dz8tM8XOh6GK4cA5ajYVRgqaSWzWiuBZVQ+ShRC/WcNYX4AROx1+PDpHYLMI eOurCTCwYdDf9ZjGHA5Dg5IS16dC9Vh7MK+HJ735FGYddNcUI9kM2MsEeEZOKbFggNGKChILb Qhevv8Y7FgMPa/cQbcdcOheYZDj4cCLF0GeBd7Sfgo33yDB97sGYSESTjQWBh1KaXB7jDJzbC Z4vO00bhhE8GH8GCpDS6r+uR7mGgRNgwlVgXeaBg8rfRTOG+DazTYScxQ0D58Mcjyc+Hmbxjw HPMX9Kswr4XPHV1SLGC9aKArOXYLTsDwuOt1pMZldNt5iNRiNy6NtgijyJsHKp4vRGdm2JuRf s30KBWpB0vfkdjSDIfTh6iPSrxRuanp25h4zL5q3OXOsgtiOIhlGD+oWTkrhpjkFk5CbZbH6d 3VCBiZUH6beJctq0cHbRIsJS4+QgXl3ubyE5Ch7tl3QRqhH5SJWLjLn2CePmNj4bqTTatRIoV BwoQ7BabO4/tc/oQgG6TXqpf6PwYVa7K5Jp0/+IQj/EKjtlzyEi/8rafPRluchC98sSmaJvfX nvRma6zpTZVxWs6q2o29Dw+a+O5Ur1l5wRy4Th9JM4YnzB2aenr3bHLp1M5/c7f18sWCpvcHj G/+WlHimV6VrLSxvPN8zMq94rnbA2/Y076Fxp6HAQabti3q82rc6T6LjDkSNvq4jOxccTTxLZ kWkaiq8pev1lGjmjYtJp8j/AQ/ghmnsAwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1526600680!185285239!1 X-Originating-IP: [207.46.163.81] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26975 invoked from network); 17 May 2018 23:44:41 -0000 Received: from mail-bl2nam02lp0081.outbound.protection.outlook.com (HELO NAM02-BL2-obe.outbound.protection.outlook.com) (207.46.163.81) by server-7.tower-219.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 17 May 2018 23:44:41 -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:X-MS-Exchange-SenderADCheck; bh=UNgg6440FdcI2mfkv1EEZrUNV6wYkatW+66LSQ4yZ6M=; b=bNX0Xn4gDF/Y+jmRas2vIv+d59ncx+aCEZKVFT138ztkO3FGFDpfmJeKjO9UICtYbs0nfrM04a/qkF1rpwnM/xpVxkDWpdXfdL+ncBzShP0brZGNrc1IE4c0+TGM9MX/vbY0ZtPYxEu55FA9MNIL5BqY+kgdzUTWbpbR5yuUSNk= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1169.namprd14.prod.outlook.com (10.173.161.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Thu, 17 May 2018 23:44:39 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0776.010; Thu, 17 May 2018 23:44:39 +0000 From: Tim Hollebeek To: James Cloos , Ted Lemon CC: "" Thread-Topic: [TLS] TLS DNSSEC chain consensus text, please speak up... Thread-Index: AQHT7QmbIQKQEvxNFUCQ6qh7cVr1J6Qyc2kAgAB6y8uAAamNkA== Date: Thu, 17 May 2018 23:44:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1169; 7:FCUgGdEiVEFn9yAH5A8Gb3LN4TH9wNDddvnRu4ZbCH3z89XQsWPx9fcrKPCqwCHuQsB0pyaiV48ZLQkQ2FWSIwHibpiXkRKccYfFtFzNsAo+XamhK2CQPortZCFJJkcuGJfQvsXVGhdGd1pgSxEuVI66N1Lo0jx/vhbzeVZJGws5Lb9kEig07kZYXLRMQUNT/r6f/DYDvCrrhOoBv80GZRUDFHoa7X5K5PmYpBOzBfOMa+iUBjSlUNQ5ec+nImGj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1169; x-ms-traffictypediagnostic: BN6PR14MB1169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1169; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1169; x-forefront-prvs: 067553F396 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(376002)(366004)(199004)(189003)(13464003)(3280700002)(476003)(81166006)(81156014)(9686003)(966005)(33656002)(486006)(99936001)(6246003)(97736004)(114624004)(14454004)(55016002)(5250100002)(86362001)(26005)(3660700001)(44832011)(99286004)(8676002)(478600001)(2906002)(2900100001)(8936002)(53936002)(106356001)(105586002)(25786009)(110136005)(446003)(6306002)(11346002)(186003)(5660300001)(74316002)(6436002)(7736002)(305945005)(4326008)(68736007)(7696005)(3846002)(316002)(66066001)(76176011)(102836004)(53546011)(6116002)(229853002)(6506007)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1169; H:BN6PR14MB1106.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: M2YM7RliVMWrfDomDzq4K3hcy1JIEIMxtM2SF+XcmD9m8GyNRE/l9298Z1PICRGR9uI7V/jIwB7f+LeCeEPssFxKgU8AYwCKt0fsZAFX0Mh70ZYuV8n3Jul/4z2f5SAEXt5mEMgKaxadLuDZ6zUp+L3PsZGexPSv1r/jY6yizh8SxvTdIb4T2Jb71Sj4Maqz 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_0B97_01D3EE17.7CEF6A80" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ee2e593d-898c-4be2-d8a4-08d5bc5027a0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee2e593d-898c-4be2-d8a4-08d5bc5027a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 23:44:38.9500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1169 Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 23:44:46 -0000 ------=_NextPart_000_0B97_01D3EE17.7CEF6A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Making things more complicated with no obvious benefit just makes things more complicated. I oppose adding two bytes for some nebulous future purpose. -Tim > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of James Cloos > Sent: Wednesday, May 16, 2018 6:20 PM > To: Ted Lemon > Cc: > Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... > > >>>>> "TL" == Ted Lemon writes: > > TL> Melinda made a pretty serious technical objection. Your response is not > TL> responsive to her objection. She explicitly said that her objection was > TL> not the two bytes. > > I don't see anything in her note today which is a technical objection. > > And I've seen no useful or reasonable objections to Viktor's suggestion. > > The sixteen bit field harms no one, and when defined and used provides > significant benefit to many. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0B97_01D3EE17.7CEF6A80 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 CQUxDxcNMTgwNTE3MjM0NDM3WjAvBgkqhkiG9w0BCQQxIgQg9W/PzJnuldxlzI0fpjmBg127agbM q3a4s3pRddFZZXYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAAuKr0u/Chl3EM7t9wEWB080YRjNARdxf8tPZRfa3aDwcwhMuG+GiqruYy8/tF80T0DmM6hr w0X41pYXvc3K2Hi9QpXKSqEeVducitkmZ9ff2j9qdGpJPRJmsh0yLCM1DRi9HsgOm2C3MYSOaiCa x+6R++rC72B2mWQWiy7i3n1yvyIIXWz95mKKVtVdkxgrFKLu4bO+0f3XyMKKSyNZgU0Y/7g4rI8T 8TnbQgUafiCfQ/lkvX3UK9yxIgr0OYmczqX8lMRMimfpzxgjxyyTkyh0YT6hHW7Dv3FyT9vrT+ab ToBjS2zcgO6+GY1hCcaRBr+YqMzElAUHjVJakr+oSR8AAAAAAAA= ------=_NextPart_000_0B97_01D3EE17.7CEF6A80-- From nobody Thu May 17 17:17: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 10C64124F57 for ; Thu, 17 May 2018 17:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 9BXCiuNVPgCt for ; Thu, 17 May 2018 17:17: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 081FD124C27 for ; Thu, 17 May 2018 17:17:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40n7zc3H2Tz1rR; Fri, 18 May 2018 02:17:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1526602668; bh=6sZB/gLx/v/IsyrsMHm11U8JgmvAhyNElcOAkq80cbs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Xm5mX3eswSkY8b0YHIWqNMi7dcy59qfFFX8kubaQ4rRIllDMhOe9ORgpo/CmzdIZn hklB1ZrCTAbH/HzbQfSNw6JPUx+XV7CXaJS6leA0prfDzwK9koPRbBBjoaQz1k2DPq b9kAbeJiy7hiDJ5bs4gHOkBqVlalp+vZ8dc+lJcA= 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 M4K3Eo5opIte; Fri, 18 May 2018 02:17:44 +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; Fri, 18 May 2018 02:17:43 +0200 (CEST) Received: from [10.157.183.229] (unknown [199.119.233.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id BFF9E49ED68; Thu, 17 May 2018 20:17:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BFF9E49ED68 Content-Type: multipart/alternative; boundary=Apple-Mail-646F9178-7616-4FA4-AF45-5D5AA1B90267 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Thu, 17 May 2018 20:17:41 -0400 Cc: James Cloos , Ted Lemon , "" Content-Transfer-Encoding: 7bit Message-Id: References: To: Tim Hollebeek Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 00:17:54 -0000 --Apple-Mail-646F9178-7616-4FA4-AF45-5D5AA1B90267 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On May 17, 2018, at 19:44, Tim Hollebeek wrot= e: >=20 > Making things more complicated with no obvious benefit just makes things > more complicated. >=20 > I oppose adding two bytes for some nebulous future purpose. The consequence of this opinion would be this: https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 Which is a lot of complexity for one TLS extension to define the behaviour o= f another TLS extension. And it still adds two bytes in the 2nd extension. So if you believe more simplicity is better, then you made the wrong choice.= Paul --Apple-Mail-646F9178-7616-4FA4-AF45-5D5AA1B90267 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On May 17, 2018, at 19:44, Tim Hol= lebeek <tim.hollebeek@digic= ert.com> wrote:

Mak= ing things more complicated with no obvious benefit just makes things=
more complicated.

I oppose adding= two bytes for some nebulous future purpose.

The consequence of this opinion would be this:
<= br>

Which is a lot of complexity for one TLS e= xtension to define the behaviour of another TLS extension. And it still adds= two bytes in the 2nd extension.

So if you believe m= ore simplicity is better, then you made the wrong choice.


Paul
= --Apple-Mail-646F9178-7616-4FA4-AF45-5D5AA1B90267-- From nobody Thu May 17 17:20: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 2D9521252BA for ; Thu, 17 May 2018 17:20: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, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, 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=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 gbb2vkk41iUI for ; Thu, 17 May 2018 17:20:30 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (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 59F97124C27 for ; Thu, 17 May 2018 17:20:30 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-11.bemta-8.messagelabs.com id FB/90-30468-D4C1EFA5; Fri, 18 May 2018 00:20:29 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUgTYRzH99zd5mVOrqn5a1rhWWSWokI06YW gN6Go/opYRd70csO92G7GoqAxQkotS2Yvoi1RS6ZSlFlZMZuptaSlq+hNypaRFpSGWQrW3W69 /fPweX7f7+/lee45ElccD1OSrNXCmo2MnpaFE77UWlPKxvgpdZr9cKSqt7pKpvrUdBdTfX7Rh 6lGfcVoFZFlf3Q+LKuu7geW1Vd7VZo1fhbbQqilOqPGZM2Wak9fayQKxnKt/pJYG/LvKkbhJE GV4vCt3i0VNgqqDIOfRW2oGE3jN68RVN/bL7CMSoOnt7sxgaOpBCjveUsUI5LEqRw4cTVJCEd R66DMfYgQLevhbumpMJE3QVvVM6nABDUfWoueBD1yagdUtz4mxL5uDI401gaFadQKcF55HmRE zYRxb1OwL07Fwot3ziADFQ0DvQ9kIsfAUGBKKvr5ol89oTgNPS9thMizoc9ZgoRmQLVg4HVW4 6KQAl8qKnBRaEfw0HUnlJEMvb2lIVM+OL6PSkXeDt2njoU6zAHX0QFCTL6NQ2vHrVBCPLSX2U NV62Tg6xqViXeaCw6XMJ8gBBD0Oz3oOFpU+c/5KnkNp5wIbrodeGXwpmbA/TPvCNGkBtuN/jC Rk6GieTgUXwTnaz7yfuGjLIQuP/1/WOBlcHrijkzkBHCUDITKLIGPnSPoHJruQkkca97LmlPS M1M1Zl2e1mJgdPqU9DRVqoHlOCaP1TMaLjXHZLiM+Bd5UCJB19HJm+s9aBaJ0THyY1OTakWkx pS7T8tw2l3mQj3LeVA8SdIgN8VNqRUzzGwea92t0/PP+rcMZAQdLV8gyHKugDFwujxR8qJM8l VLeSlOej47+PWhsCoIo8nIKmPlB4QESkjQFhr/lPv9o/Sh2cooOZJIJIqIAtZs0Fn+14dRLIn oKPluoUqEzmj503WYHwjjB0Ltk8JAFuavpLShosXewsH8nf3dr2tGMiKz3V5NTEdVnT+AxW9z rduzocGDg8K+pvxa4oXBzaY3ga7Vk371F0l054kIX9HahtEjgXkTVOJwW+W8D1tpe1xGe2dPv i1bOnemciJh6ELzjZXLP9FL7Un3L733LXzwdOxiVfdja2PcznqXPY6pn26raaEJTsukJ+Nmjv kFljSPNSMEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-220.messagelabs.com!1526602827!196526756!1 X-Originating-IP: [207.46.163.111] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7479 invoked from network); 18 May 2018 00:20:28 -0000 Received: from mail-sn1nam01lp0111.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (207.46.163.111) by server-8.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 May 2018 00:20:28 -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:X-MS-Exchange-SenderADCheck; bh=dQ0K0J6Em/vhpruKzUlFDHQUKZ668b19sArHQj1XVj0=; b=hNZq4rdwbBDIhEvUab1/qIfIEm1L/n+OjxalSn1aVN/PoOgL1HXDzhEBkfpLKZZUV2Os9pzo3+Xajoxb0VLyaa5WNtSxZmRcsAIjdo2Sl0SWV6MWQLvVtfo87qf055RPnBgD8tGKa990BpydUJR39ObN4S+1uNFaDaIaq9NVYAo= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1315.namprd14.prod.outlook.com (10.173.163.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Fri, 18 May 2018 00:20:26 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0776.010; Fri, 18 May 2018 00:20:26 +0000 From: Tim Hollebeek To: Paul Wouters CC: James Cloos , Ted Lemon , "" Thread-Topic: [TLS] TLS DNSSEC chain consensus text, please speak up... Thread-Index: AQHT7QmbIQKQEvxNFUCQ6qh7cVr1J6Qyc2kAgAB6y8uAAamNkIAACXCAgAAAiyA= Date: Fri, 18 May 2018 00:20:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1315; 7:e+aioo8CuJrsKWV7djqTrCEjdbFFzTXoB22jWo7CvHYk2EkfxPgFIxB/gUgd3ptDbuXPw9I+MrueMI/gxVI3ruslRcxSi2uP62i41EaWEjQT/dQsn7TueTP0eVQ/A8exSYZydJsaO4oN3ySlPYIzp1a3JAMXjVoj2mpPppncUP/mFNYRf8FMdKGG8l5UaglReUc7kkdz/iW/5+VEWRngh7TxhgiX1jSJDqRY1bknJ/7eAbVoB3aj20FoOFwvFEKU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1315; x-ms-traffictypediagnostic: BN6PR14MB1315: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1315; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1315; x-forefront-prvs: 0676F530A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(376002)(346002)(366004)(199004)(189003)(44832011)(81166006)(229853002)(186003)(74316002)(76176011)(26005)(5250100002)(8936002)(486006)(53546011)(11346002)(6506007)(99286004)(606006)(8676002)(14454004)(476003)(102836004)(478600001)(66066001)(7696005)(7736002)(446003)(966005)(81156014)(6436002)(3846002)(6916009)(790700001)(6116002)(2906002)(6306002)(99936001)(316002)(3660700001)(93886005)(3280700002)(53936002)(4326008)(55016002)(105586002)(33656002)(54896002)(25786009)(9686003)(6246003)(54906003)(68736007)(236005)(5660300001)(86362001)(2900100001)(97736004)(106356001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1315; H:BN6PR14MB1106.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: usOpsV9o5L1TNZMPhpVvdXG/gTau/trOlHT7cmeq9MaaZ8hgsDOBNqYHLfubpeS9KLnhVo1zjJvePNg8Y6KQM4MIso0oNi4CTiom7PmhzNsRBpA8PUcuePDAlREyBI/j0FNj4Yo8F4P6j7cV4TVqakUqUKDQrJOu1rjsmTztwYcMleu4+5FDMEFeF3r/kpL0 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_0BC3_01D3EE1C.7CFDA910" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c00dcab9-56e9-4870-769d-08d5bc552799 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: c00dcab9-56e9-4870-769d-08d5bc552799 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2018 00:20:26.4032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1315 Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 00:20:36 -0000 ------=_NextPart_000_0BC3_01D3EE1C.7CFDA910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0BC4_01D3EE1C.7CFDA910" ------=_NextPart_001_0BC4_01D3EE1C.7CFDA910 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m actually fine with that. You have to consider P_{extension = implemented and used}. =20 Different people will disagree about the value of P. =20 -Tim =20 From: Paul Wouters [mailto:paul@nohats.ca]=20 Sent: Thursday, May 17, 2018 8:18 PM To: Tim Hollebeek Cc: James Cloos ; Ted Lemon ; = Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... =20 =20 On May 17, 2018, at 19:44, Tim Hollebeek > wrote: Making things more complicated with no obvious benefit just makes things more complicated. I oppose adding two bytes for some nebulous future purpose. =20 The consequence of this opinion would be this: =20 https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 =20 Which is a lot of complexity for one TLS extension to define the = behaviour of another TLS extension. And it still adds two bytes in the = 2nd extension. =20 So if you believe more simplicity is better, then you made the wrong = choice. =20 =20 Paul ------=_NextPart_001_0BC4_01D3EE1C.7CFDA910 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99m actually fine with that.=C2=A0 You have to = consider P_{extension implemented and used}.

 

Different = people will disagree about the value of P.

 

-Tim

 

From: Paul = Wouters [mailto:paul@nohats.ca]
Sent: Thursday, May 17, 2018 = 8:18 PM
To: Tim Hollebeek = <tim.hollebeek@digicert.com>
Cc: James Cloos = <cloos@jhcloos.com>; Ted Lemon <mellon@fugue.com>; = <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] = TLS DNSSEC chain consensus text, please speak = up...

 

 

On May 17, 2018, at 19:44, Tim Hollebeek = <tim.hollebeek@digicert.com= > wrote:

Making things more complicated with no obvious benefit = just makes things
more complicated.

I oppose adding two bytes = for some nebulous future = purpose.

 

The consequence of this opinion would be = this:

 

 

Which is a lot of complexity for one TLS extension to = define the behaviour of another TLS extension. And it still adds two = bytes in the 2nd extension.

 

So if you believe more simplicity is better, then you = made the wrong choice.

 

 

Paul

------=_NextPart_001_0BC4_01D3EE1C.7CFDA910-- ------=_NextPart_000_0BC3_01D3EE1C.7CFDA910 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 CQUxDxcNMTgwNTE4MDAyMDI0WjAvBgkqhkiG9w0BCQQxIgQgfofrIR8S4cun0z3n5CT3HnrvLsgL 0u8hq+dSjHEIQ3QwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAAJYdXgcsWcS8YQa1+HmnrwY6JYBamosRzf1FdExC6HfVr/3bWqCRbrNDwaKE8DlsmKOBV0B ugHMAmTE/+sLIUhUjnVHu/9n50o82shL08mjVMXO0gf3avnQc9gMTDWgCS6lIk/WgMNgvvaciUOQ I9tQkXl+5xzLX3yUcMO/51MHCzrVK8hnGi/1j2jFbQaRy13r95OLxtD+nbXAOqOAun6RBW8C9UAR pqIV8K5lXSbHBcS25D4qDnIDeHk005D+fMy+hqvK6T942vjPlKqIdKK/As7BIN1xsUc3VVpA7toS 4tDpjKi46FmDlzmAd6m6IdK0jIbdg2sgdHEp0uigox4AAAAAAAA= ------=_NextPart_000_0BC3_01D3EE1C.7CFDA910-- From nobody Thu May 17 17:58:26 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 575D4126B6E; Thu, 17 May 2018 17:58:24 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152660510431.1578.6142326601215814695@ietfa.amsl.com> Date: Thu, 17 May 2018 17:58:24 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-record-limit-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: Fri, 18 May 2018 00:58:25 -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 : Record Size Limit Extension for Transport Layer Security (TLS) Author : Martin Thomson Filename : draft-ietf-tls-record-limit-03.txt Pages : 8 Date : 2018-05-17 Abstract: An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-record-limit-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-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 Thu May 17 18:00: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 0F01D126BF6 for ; Thu, 17 May 2018 18:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6jpVOS0ERxwH for ; Thu, 17 May 2018 18:00:06 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D549C126BF0 for ; Thu, 17 May 2018 18:00:05 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id w123-v6so5701711oia.4 for ; Thu, 17 May 2018 18:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ll+D6MaBfLricTj4G6jr0Tm6mkb4N2QHLNXDCNKvSI0=; b=FLo57CP9B6DUfjwSEIpbmnmcaTGIzncpwLkkmj8PldvN/uTSEGiDgu8OoFM6qkUrCU wzzJxN8Myp544lphor+dPYpxT3HLGwWbwWDUZfhSH83kLO+s+vDbbBBVVXDqdHcSTeRq zgPVRZvTOq/NoqE1OB9oQaANhM39YVGfiOZmOxSTgGoC2dYPj7eZoJoSrpwLDNoyjueT 799jL2xyQ9ymzLtHmnZ4/3IIK4KTdNRVTljMaJDp93uZ9y4MfVfhzL52OJ6GZ22RABje bUSqcPQ79nlGyW7+RF+1XdWvnYtxIaw8oAKBxNN/HWiZldK6FsLeQRVBKJNWVFi/S13N MUsw== 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=ll+D6MaBfLricTj4G6jr0Tm6mkb4N2QHLNXDCNKvSI0=; b=A85IbIKP6gKrBzj9E3WsSm+q9zUaQb8Q+8lPBnp6a2CcNKrN/HWuyEvhy5512DqCIO lw5oWrXyzU+KbIPZMtNh4JTHvthZArrHe8bEAdhPvF+n8hM7tx3pO3x6izvshFANdFPP ZxJaqj+XMkOtsMlrLU+oapywt9SIV2XwWekoE3Nq2Yb7v2axit1hjd+Xsu8RLXlti+ak GzkqVPu9pQx+KkHBcWoRgu7wa4ayqLeQrvW2VkkIyuxtLTshJfZzR+7qtAvLvlXMLs13 VNdqebv7jBqLplbwjc6DgYnhiwMLeukJVA/MFaY8gsjSooRPo3lTR06S5nWZ1PV0h8aT AOkQ== X-Gm-Message-State: ALKqPwfYkaW9iFrFl4LC1rz9AINNnn3jsL38jURfpfNo9DIfZHHA84ax 8HX86sHnJR1mZL5+qjoUoMRSOw4zpzi7or/sZJ4dSw== X-Google-Smtp-Source: AB8JxZqz2xTO/FFOXEtHQV6bhEzKuJ2HFSWurnJbeArrv4Xpz5joNIoq/p5HbawTsrs52pGBhpP7q2c3liQBuBWJ/Ak= X-Received: by 2002:aca:d593:: with SMTP id m141-v6mr4743784oig.346.1526605204999; Thu, 17 May 2018 18:00:04 -0700 (PDT) MIME-Version: 1.0 References: <152660510431.1578.6142326601215814695@ietfa.amsl.com> In-Reply-To: <152660510431.1578.6142326601215814695@ietfa.amsl.com> From: Martin Thomson Date: Fri, 18 May 2018 10:59:53 +1000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-record-limit-03.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, 18 May 2018 01:00:08 -0000 Just rolling up all the changes discussed in final reviews. On Fri, May 18, 2018 at 10:58 AM wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > Title : Record Size Limit Extension for Transport Layer Security (TLS) > Author : Martin Thomson > Filename : draft-ietf-tls-record-limit-03.txt > Pages : 8 > Date : 2018-05-17 > Abstract: > An extension to Transport Layer Security (TLS) is defined that allows > endpoints to negotiate the maximum size of protected records that > each will send the other. > This replaces the maximum fragment length extension defined in RFC > 6066. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-record-limit-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-03 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-03 > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 17 18:21: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 D47D8126BF3 for ; Thu, 17 May 2018 18:21:08 -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=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 68h69OMGB3Jh for ; Thu, 17 May 2018 18:21:06 -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 9947B126BF0 for ; Thu, 17 May 2018 18:21:06 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 131-v6so3868584vkf.8 for ; Thu, 17 May 2018 18:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XKXBhJWX/AqjRhfMKeez+yIRvHZieapfoAtBnfKgsqc=; b=CbQ4MqhjF2lfwX6JbMnR5C7CcCp6rLCMt2QDs40aSD4HeYQTG/+fC/QkPtWYDfy2W5 GYk+j/YGsJMXfBfIXyWm52qyTyOMwQ/RSzSM1J5TAXEcnOncjlVgx3CuIHHA6TNuaUgh G8fX1wWMCIQKIDOCfbX5zLXVeu6tvdy2UkOuUIZldNEyp6/mxp1anpbRrw5mebEpQkr5 eknjWiJVmj9sD25MPXnk+48BrlA8NQZ4YkdSf73lbkT0fphdNs63Vx2O49T52KNLFihI txoMNTKK4PFjD/4fCwJLy1/M4vwXs4t3Np+hMla/Ehzdv4luP5jTgsO+U5wG6JI5Jrft GpGA== 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=XKXBhJWX/AqjRhfMKeez+yIRvHZieapfoAtBnfKgsqc=; b=ZZlY6+dC9Rsc8CKsvV7LnaePRSd1Bb/FdmdmdTkz0CwBRKfioKZlIwu3oqrq/zACV/ egp3x0Wu95UlHN8wKO/B52WivQmSN/8BPf4X8L0VEuhIX+XJKai7HB88S2Po/D8J0F1l VWv+HyhT//PwW+zmPbRjYJkQlxPMhG06D72Z0vDLGgRucO6ghUUVD/93k6I1XfveUJ7P MbyvKy2CdgMMWBFBPc2llAM1KmmKFX+fNmL8XlJT8OBCbSQbVK3CAqMq6OzLrv2NJu0U 43vVlK+Ff+Ez+tDM250w2bRaHaAcywcznAK/CO8Do8ocNInIjZLLaBoNVWsrop9kLVqG cfZA== X-Gm-Message-State: ALKqPwdk9/ML5ISI/Slpmg9qYPVQtP/V08dB38bNgO6uz4gRc1e3708h PSbL7c8pC3dEH+VewQxOTzVlhk35n0160jWs+pfx X-Google-Smtp-Source: AB8JxZrJfayvTMPLquLtJa1+iM9tQUaBXFkFcoYVeRwwJHm4PLHJdr/DFwdo0Ae/c0ZD+k3WhiMJMifFURk7CCMkM2k= X-Received: by 2002:a1f:5581:: with SMTP id j123-v6mr5601186vkb.170.1526606465373; Thu, 17 May 2018 18:21:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melinda Shore Date: Thu, 17 May 2018 17:20:53 -0800 Message-ID: To: Tim Hollebeek Cc: Paul Wouters , "" Content-Type: multipart/alternative; boundary="00000000000014ab0e056c70c4b2" Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 01:21:09 -0000 --00000000000014ab0e056c70c4b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And to be clear, it's not that nobody is going to implement the extension (it's already been done in an IETF hackathon and elsewhere), the work on the extension was funded by Mozilla, and there's been an outstanding request for this in Bugzilla. What's not being implemented is the proposed changes. But, it's clear that those guys don't intend to compromise and we're going to be deadlocked pretty much forever unless someone does something. That's not going to be Viktor and it's not going to be the chairs, so I guess it's me. Melinda On Thu, May 17, 2018, 16:20 Tim Hollebeek wrote: > I=E2=80=99m actually fine with that. You have to consider P_{extension > implemented and used}. > > > > Different people will disagree about the value of P. > > > > -Tim > > > > *From:* Paul Wouters [mailto:paul@nohats.ca] > *Sent:* Thursday, May 17, 2018 8:18 PM > *To:* Tim Hollebeek > *Cc:* James Cloos ; Ted Lemon ; < > tls@ietf.org> > *Subject:* Re: [TLS] TLS DNSSEC chain consensus text, please speak up... > > > > > > On May 17, 2018, at 19:44, Tim Hollebeek > wrote: > > Making things more complicated with no obvious benefit just makes things > more complicated. > > I oppose adding two bytes for some nebulous future purpose. > > > > The consequence of this opinion would be this: > > > > https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 > > > > Which is a lot of complexity for one TLS extension to define the behaviou= r > of another TLS extension. And it still adds two bytes in the 2nd extensio= n. > > > > So if you believe more simplicity is better, then you made the wrong > choice. > > > > > > Paul > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000014ab0e056c70c4b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And to be clear, it's not that nobody is going to imp= lement the extension (it's already been done in an IETF hackathon and e= lsewhere), the work on the extension was funded by Mozilla, and there's= been an outstanding request for this in Bugzilla.=C2=A0 What's not bei= ng implemented is the proposed changes.

But, it's clear that those guys don't intend to compromis= e and we're going to be deadlocked pretty much forever unless someone d= oes something.=C2=A0 That's not going to be Viktor and it's not goi= ng to be the chairs, so I guess it's me.=C2=A0=C2=A0

Melinda

On Thu, May 17, 2018, 16:20 Tim Hollebeek <tim.hollebeek@digicert.com>= ; wrote:

I=E2=80=99m actually fine with that.=C2=A0 You have= to consider P_{extension implemented and used}.

=C2=A0

Different peo= ple will disagree about the value of P.

=C2=A0

-Tim

<= p class=3D"MsoNormal">=C2=A0

From: Paul Wouters [mailto:paul@nohats.ca]
Sen= t: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: James Cloos <cloos@jh= cloos.com>; Ted Lemon <mellon@fugue.com>; <tls@ietf.org>= <t= ls@ietf.org>
Subject: Re: [TLS] TLS DNSSEC chain consensus= text, please speak up...

=C2=A0

=C2=A0

<= div>

On May 17, 2018, = at 19:44, Tim Hollebeek <tim.hollebeek@digicert.com> wrot= e:

Making things more complicated with n= o obvious benefit just makes things
more complicated.

I oppose ad= ding two bytes for some nebulous future purpose.

=C2=A0

The consequence of this opinion would be this:<= u>

=C2=A0

<= div>

https://= tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00=

=C2=A0

Which is a lot of complexity for one TLS extension to = define the behaviour of another TLS extension. And it still adds two bytes = in the 2nd extension.

=C2=A0

So if you believe m= ore simplicity is better, then you made the wrong choice.

=

=C2=A0

=C2=A0

= Paul

_____________________________= __________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000014ab0e056c70c4b2-- From nobody Thu May 17 18:25: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 1FB59126CD8 for ; Thu, 17 May 2018 18:25:12 -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, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, 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 TTQyOMMKYs5s for ; Thu, 17 May 2018 18:25:09 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.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 562DD126CD6 for ; Thu, 17 May 2018 18:25:09 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-14.bemta-12.messagelabs.com id 6D/75-07800-37B2EFA5; Fri, 18 May 2018 01:25:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0xbVRzAe+697b1D7rxcXn8JLNpoMiAQ8JF g/KJ+UDSZcYkLsWLcLdzRhj7w3g5rgpOBoimVV6gT4mBKAwFZcLWYbdkGKwxCR2iowSHzEQLE CFomDxnP2NtTpnw5+Z3/7/845+ZchuQ/oVMY0W4TJYtg0mpiqOlHvf1ZUuaeLmekKydv+Ws3y lueCRJ5KwEHep7Md7s3ifyNNiI/9KWLfp3UqY0WvdV+Um3wdDiJMm8jsrctjqsrUeOnyIFiGI pzkvDPlWW1suG5BgIaWq5p8OY3BOuOPsKBDjEaLgd+vD4a4YQwr8xX0w7EMCT3Ivgr31TC8dx LUD/wEYVTXoZh5zkasw5CQ8NqhSnuCfj+9wVSKWW5QghdOKWEee4OCWuTssKHuOPg/WWKVBhx SbDh741MJblkmJlvjzBwCTA7eVuDORH+mNtT4/xCOL/qi8a1MH63ksKcBsH22siFgfMS4OkdQ FhkwT2Xi8RiEEGVe5XGIgM+dv0VnVYKLRv31ZjfgtFzddEJR6Dns1kKF18noaV/OlqcCoP1Vd GulzRw3rNE43sWQ3OPT4PFHILenU26AWW2/u9+rWFHcu0I+iachCJYLg7GWuap1sjn1sHPk4U 4PwNcFxcpzJnQ+dUSiVPSYeQH7cGwws/BF1s3NZgfg+baWRrzM7B06290AT3Ug47KolQuSlm5 edl6yVhisJkFoykrN/fJbLMoy0KJaBL0cnaR1exB4Yf4oUqFLqOms6/60CMMoU1k6/a2dfxhv bX4fYMgG96RTptE2YdSGUYL7OGMPR0fJ4klov2U0RR+zfsamFhtAjuUHtasXCaYZWMJVn70LL PjbXKSjG+5ObxOKCtPWawWMSWZfVjpxykFhtOWB+32/48gSkuJZ5FKpeJjy0TJbLQd9IsomUH aePY9pUus0WJ7MHUxfCAifCA0uK0cyCb8p1Iqkd33xpnP+6p3S+srjgSOX52riUv/7tg3fvnP 1ad/mnjXySchc3HT2Fiw9spTyB2v3/V+sEB7riWudfXemxtYfyH0yvTFioJt/dTIzNKdopGYI e/bW9bumsAx/9FvZ+uaOwsSL2WeKe+gh9qqujtu/Ho3EDgZetwjnyidcKwGXxN4i5aSDUJuBi nJwr9MXMP0GgQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1526606706!188224588!1 X-Originating-IP: [216.32.180.181] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22212 invoked from network); 18 May 2018 01:25:06 -0000 Received: from mail-bn3nam01lp0181.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (216.32.180.181) by server-8.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 May 2018 01:25:06 -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:X-MS-Exchange-SenderADCheck; bh=shS3/5+ZPgh2NL/Qbuil87y2CjC2BQ0W9ytgiVd6zZs=; b=pbwZtEqieC2Klp/NyHieyGgFP24fftybaCokJiEbluaVQtiR1hUQrql7hswRSXDeDDd+ZP3sviowRNF02bye5Qj1IAWwD4VN0Ym9B2FCy/wv1IUKG554yCAs3S60xqONxLCMrcmsmI1T7LnDyJJKas3blwHeivXDSVUadr/eKuo= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1283.namprd14.prod.outlook.com (10.173.162.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Fri, 18 May 2018 01:25:05 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0776.010; Fri, 18 May 2018 01:25:04 +0000 From: Tim Hollebeek To: Melinda Shore CC: Paul Wouters , "" Thread-Topic: [TLS] TLS DNSSEC chain consensus text, please speak up... Thread-Index: AQHT7QmbIQKQEvxNFUCQ6qh7cVr1J6Qyc2kAgAB6y8uAAamNkIAACXCAgAAAiyCAABEegIAAAMYg Date: Fri, 18 May 2018 01:25:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1283; 7:pJvBdeqhUm6sYnKfdzdwEBxq0KeAE0j15+mw1rSRMjYHJXtF1gphJWkxZYw8Vo8z9p+obIWdrccWsi8hMBybKQa0IHv6s5jWorwF+mORsMXylr4+C7XIR9ukd2KjSYv0xbj8CPRhZISkOCOIxL0Y54xty0fpoflMivIMVd+ITV/KC6kUrUDcWGoc5Repz8qQvgaOa8byrxtm753GlAnsNYehRx7gOd6WXxexvZ1rmOEOZrR2ik/ccem48Lw9+iFL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1283; x-ms-traffictypediagnostic: BN6PR14MB1283: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1283; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1283; x-forefront-prvs: 0676F530A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(39380400002)(366004)(199004)(189003)(14454004)(66066001)(186003)(59450400001)(6506007)(99936001)(478600001)(54906003)(606006)(2900100001)(5660300001)(6246003)(6916009)(68736007)(74316002)(2906002)(9686003)(33656002)(97736004)(486006)(966005)(55016002)(316002)(76176011)(99286004)(3280700002)(3660700001)(3846002)(6306002)(7696005)(54896002)(102836004)(6116002)(236005)(790700001)(26005)(53936002)(53546011)(229853002)(7736002)(44832011)(446003)(6436002)(105586002)(25786009)(8936002)(93886005)(11346002)(86362001)(4326008)(5250100002)(8676002)(81166006)(106356001)(476003)(81156014)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1283; H:BN6PR14MB1106.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: ozbH2jkGZs82WnVfyYu+R4AExTZ9puTU4Yh010NE2qqh+i3rkXu0L3jFgVf08sDEYblrdy9pTBNtXvvxAo3m1afbLK3VEbjknN4f5LnL722gZjBhAqludQ/sWdlOWJJ7ydGJQcPGhQFr/Z6Y7k/9q20E2vZbLSlgllycJ7sO4HdwFFp+G+5qem2Am9L0pmMO 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_0BF2_01D3EE25.848585A0" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 3bb44c94-a4c2-4c00-9ec7-08d5bc5e2f50 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bb44c94-a4c2-4c00-9ec7-08d5bc5e2f50 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2018 01:25:04.7631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1283 Archived-At: Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 01:25:12 -0000 ------=_NextPart_000_0BF2_01D3EE25.848585A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0BF3_01D3EE25.848585A0" ------=_NextPart_001_0BF3_01D3EE25.848585A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think there=E2=80=99s room for two people in front of the steamroller. = And I have a towel. How many votes does that get me? =20 -Tim =20 From: Melinda Shore [mailto:melinda.shore@nomountain.net]=20 Sent: Thursday, May 17, 2018 9:21 PM To: Tim Hollebeek Cc: Paul Wouters ; Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... =20 And to be clear, it's not that nobody is going to implement the = extension (it's already been done in an IETF hackathon and elsewhere), = the work on the extension was funded by Mozilla, and there's been an = outstanding request for this in Bugzilla. What's not being implemented = is the proposed changes. =20 But, it's clear that those guys don't intend to compromise and we're = going to be deadlocked pretty much forever unless someone does = something. That's not going to be Viktor and it's not going to be the = chairs, so I guess it's me. =20 =20 Melinda =20 On Thu, May 17, 2018, 16:20 Tim Hollebeek > wrote: I=E2=80=99m actually fine with that. You have to consider P_{extension = implemented and used}. =20 Different people will disagree about the value of P. =20 -Tim =20 From: Paul Wouters [mailto:paul@nohats.ca ]=20 Sent: Thursday, May 17, 2018 8:18 PM To: Tim Hollebeek > Cc: James Cloos >; Ted = Lemon >; > > Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... =20 =20 On May 17, 2018, at 19:44, Tim Hollebeek > wrote: Making things more complicated with no obvious benefit just makes things more complicated. I oppose adding two bytes for some nebulous future purpose. =20 The consequence of this opinion would be this: =20 https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 =20 Which is a lot of complexity for one TLS extension to define the = behaviour of another TLS extension. And it still adds two bytes in the = 2nd extension. =20 So if you believe more simplicity is better, then you made the wrong = choice. =20 =20 Paul _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_001_0BF3_01D3EE25.848585A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think = there=E2=80=99s room for two people in front of the steamroller.=C2=A0 = And I have a towel.=C2=A0 How many votes does that get = me?

 

-Tim

 

From: = Melinda Shore [mailto:melinda.shore@nomountain.net]
Sent: = Thursday, May 17, 2018 9:21 PM
To: Tim Hollebeek = <tim.hollebeek@digicert.com>
Cc: Paul Wouters = <paul@nohats.ca>; <tls@ietf.org> = <tls@ietf.org>
Subject: Re: [TLS] TLS DNSSEC chain = consensus text, please speak up...

 

And to = be clear, it's not that nobody is going to implement the extension (it's = already been done in an IETF hackathon and elsewhere), the work on the = extension was funded by Mozilla, and there's been an outstanding request = for this in Bugzilla.  What's not being implemented is the proposed = changes.

 

But, it's clear that those guys don't intend to = compromise and we're going to be deadlocked pretty much forever unless = someone does something.  That's not going to be Viktor and it's not = going to be the chairs, so I guess it's = me.  

 

Melinda

 

On = Thu, May 17, 2018, 16:20 Tim Hollebeek <tim.hollebeek@digicert.com= > wrote:

I=E2=80=99m = actually fine with that.  You have to consider P_{extension = implemented and used}.

 <= /o:p>

Different = people will disagree about the value of P.

 <= /o:p>

-Tim

 <= /o:p>

From:= Paul Wouters [mailto:paul@nohats.ca]
Sent: Thursday, May 17, = 2018 8:18 PM
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: James = Cloos <cloos@jhcloos.com>; Ted Lemon <mellon@fugue.com>; <tls@ietf.org> = <tls@ietf.org>
Subject: Re: [TLS] TLS = DNSSEC chain consensus text, please speak = up...

 <= /o:p>

 <= /o:p>

On May 17, 2018, = at 19:44, Tim Hollebeek <tim.hollebeek@digicert.com> = wrote:

Making = things more complicated with no obvious benefit just makes = things
more complicated.

I oppose adding two bytes for some = nebulous future purpose.

 <= /o:p>

The = consequence of this opinion would be this:

 <= /o:p>

 <= /o:p>

Which is a = lot of complexity for one TLS extension to define the behaviour of = another TLS extension. And it still adds two bytes in the 2nd = extension.

 <= /o:p>

So if you = believe more simplicity is better, then you made the wrong = choice.

 <= /o:p>

 <= /o:p>

Paul

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

------=_NextPart_001_0BF3_01D3EE25.848585A0-- ------=_NextPart_000_0BF2_01D3EE25.848585A0 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 CQUxDxcNMTgwNTE4MDEyNTAyWjAvBgkqhkiG9w0BCQQxIgQgQyVBIKM98rgHcuGKHoFYgNrhydnh jfGG7M8EfgPDtZswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAGTh213lS5T0iwySPE25QfhzoJFHFQMja0zYRDhuIjTNH96msLaiudkZBMDaBrqccM66HCDe YmICXCNaKTtRfTiuSrrEqJoCiQ4udeA04d7dvwHk3+KQrHYvMyKYkWsDBN4SLjCp6428+2/IcALP wcBNo6mlFJNVU8iBwvnbBuOyzNTqoxjJxoT0iQZOv7ZNX/1BeTunEeJEBm7ubMKGLa+5Q4GPMJtE 0htnLlbatn42NGJcgPVsQx9TaRHP5kgnIER1rxkqGEg0PWNJbjjtVIobKHJx+WinbqIVeP85VplB dffNVGcaneHnWQCu1u9YGoRYgpvN/7h80Ji2R5W7Ld8AAAAAAAA= ------=_NextPart_000_0BF2_01D3EE25.848585A0-- From nobody Thu May 17 23:43: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 E8C73127241 for ; Thu, 17 May 2018 23:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SxTFGNvFkXs for ; Thu, 17 May 2018 23:43:04 -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 81E7012711A for ; Thu, 17 May 2018 23:43:04 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id e80-v6so6201216oig.11 for ; Thu, 17 May 2018 23:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7hukOtdTzp31Y590PsKnIAcxiecTv3iD6LkbU62S0qM=; b=D2N75lL/7ZlfXTjfLaHfiezq4PeghKyeTVcwF1/2vwFfhO5vGPPLnpOUBCMDl4VVla g8NDpRWdmyRa2wnbeNcUgR60CIczPONaDzerSbQjrCZd+x9bBnoujtEk3O1peqZItza9 3Rxc4DZHsmt0Q+Lk9q8fbq0cUC+f1KKPa1DlWfETfVLt1GAFN+V9pK2i/ynC95BuDK6i WDPof9Dt92W4fRAp1V0C8nbMV9tzShhD4VuAYMmFhcZq4W6dwR7MrhO8krPgkoAWOAYd G3Z3dpDzgh45uCS9HKSpe1eU4pz6w6uieZp6rGGjkIQHAQI6o+nDaCOsB9+uvmoImiSC hVKA== 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=7hukOtdTzp31Y590PsKnIAcxiecTv3iD6LkbU62S0qM=; b=LRVtokvqdyHLsTDvyEwawDpV+Jwv82n7VwUttQAKwASWvQBU+IPwGBsgsFETllNzW8 qr7pq64Z9mnDpey+w2EB9VfF/fYq8B7NPERMf0rlMXjO7xRTedZFrPe55GUSiy94ka9b xxYNWdbCTbBVXM7LnBvhp60VO8nqB3Nl0QVEV/61VZrrq7s8IuF0mF5/IlF8NwkdJkkI Rbjd+Jh9irdiHJZ8lY11u+EDL+qVfS6lRZFzcjLV1zzUZoe5SjHq6yODvftU1lI6QDfg yVItNmK4+Lg0OMfsiLf8+wRm9qwx7vFPMYCjp2CvOUX0Et5d9rnXkbDN6mA6yifZ0pjD E+SA== X-Gm-Message-State: ALKqPwcqr429FAcjj/Fg+AoLHEa8fiQ6AKbNDJd6MHhxjZMqh9moyshZ jJ3ExiM7+nLiAzche1D3qsAFMYYAdo1VnbpfK2N079Bm X-Google-Smtp-Source: AB8JxZpUVKsEefJydnCUchwKA4e0hHWsq5vq3m7hGu4wz8vhYJ7GWVgN6FoXQ0/OgYBRV5n1BszP0U8NzXvom65uBlk= X-Received: by 2002:aca:ebd4:: with SMTP id j203-v6mr5296986oih.110.1526625783426; Thu, 17 May 2018 23:43:03 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Fri, 18 May 2018 16:42:51 +1000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Review of draft-asmithee-tls-dnssec-downprot-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 06:43:06 -0000 Hi Alan and Alan, Thanks for writing this draft. Even though the intent here is abundantly clear and this email risks me being drawn into the toxic mess of the related discussion, I found this draft to provoke an interesting thought. Though the current design is for a two octet commitment that narrowly addresses one particular extension, it seems that - like the must-staple design - there is an opportunity here. We have potential downgrade attacks on a range of extensions, not just the identified one. For instance, failing to provide the extended master secret extension represents a fairly significant regression in capabilities that could be indicative of an attack. The same for renegotiation info, SCT, and others. I thought supported_versions might be a valid use, but I'm not 100% sure there. The extension could reference itself though. A commitment to continue to provide a particular feature - as identified via its extension - would be a potentially useful capability. Of course, this would need to squarely address the potential for a service to take itself out in the way that such commitments tend to. It also needs to address the scope of the commitment in more than just time. This isn't trivial when you consider that a server can be considered valid for multiple identities. The current draft doesn't really do either topic justice. Having this indicator expire when you get an authenticated denial of existence seems odd. Why not just update the lifetime when the connection is successful unconditionally? Finally, I don't see any value in the "if you use that then you must use this" text in the draft, but that's likely just a consequence of the other discussion. Cheers, Martin From nobody Fri May 18 06:45: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 148E712D95F for ; Fri, 18 May 2018 06:45: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 uKDRizrp2WHz for ; Fri, 18 May 2018 06:45: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 3C40312D7F8 for ; Fri, 18 May 2018 06:45: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 511287A3309 for ; Fri, 18 May 2018 13:45: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: Date: Fri, 18 May 2018 09:45:08 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <08EA6A2F-3E74-456D-BC8C-04C57312A214@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Review of draft-asmithee-tls-dnssec-downprot-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 18 May 2018 13:45:12 -0000 > On May 18, 2018, at 2:42 AM, Martin Thomson = wrote: >=20 > We have potential downgrade attacks on a range of extensions, not just = the > identified one. For instance, failing to provide the extended master > secret extension represents a fairly significant regression in = capabilities > that could be indicative of an attack. The same for renegotiation = info, > SCT, and others. I thought supported_versions might be a valid use, = but > I'm not 100% sure there. The extension could reference itself though. >=20 > A commitment to continue to provide a particular feature - as = identified > via its extension - would be a potentially useful capability. The same thought had already occurred to me, and I concluded that chain the extension is materially different in this respect from the others and the approach is not generally applicable. The difference is that the DNSSEC (DANE) chain introduces a new set of trust anchors, and so absent those trust anchors one might reach different conclusions about the authenticity of the peer. Presence or absence of such trust anchors for the server endpoint is authenticated via DNSSEC. The other extensions you mention operate within the same trust-anchor context whether present or absent. An attacker in possession of a forged certificate or a misappropriated private key is not thwarted by the requirement to present those extensions, can employ them at will, and can authenticate a reset of any previous "support lifetime". If the absence of a TLS extension makes it possible to impersonate the peer (without having suitable credentials), that extension should be mandatory in TLS. If the extension merely protects against chosen plaintext attacks (ala CRIME, BEAST, ...) then only the authentic server can downgrade itself, so we don't need a pin to require the extension. Which optional extensions militate server impersonation by an MiTM who does not have forged credentials or misappropriated keys? Does the above make sense? Am I missing a class of extensions that are needed to make sure the peer's authenticity is not compromised even in the absence of forged or stolen credentials? If such attacks are practical, why aren't the militating extensions mandatory? --=20 Viktor. From nobody Sat May 19 11:12: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 95F2212D874 for ; Sat, 19 May 2018 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 sO53-N5BX7G8 for ; Sat, 19 May 2018 11:12:32 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 5F2A6126BF3 for ; Sat, 19 May 2018 11:12:31 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.37 Received: from exmbxprd11.ad.ufl.edu ([10.36.133.37]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w4JICGCN018605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 19 May 2018 14:12:17 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd11.ad.ufl.edu (10.36.133.37) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 19 May 2018 14:12:29 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 19 May 2018 14:12:28 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (216.32.181.180) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Sat, 19 May 2018 14:12:29 -0400 Received: from BN6PR22MB0737.namprd22.prod.outlook.com (10.171.179.148) by BN6PR22MB0658.namprd22.prod.outlook.com (10.173.204.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Sat, 19 May 2018 18:12:26 +0000 Received: from BN6PR22MB0737.namprd22.prod.outlook.com ([fe80::3146:c6c:e7d8:b852]) by BN6PR22MB0737.namprd22.prod.outlook.com ([fe80::3146:c6c:e7d8:b852%5]) with mapi id 15.20.0776.010; Sat, 19 May 2018 18:12:25 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Editorial comments on draft-ietf-tls-subcerts Thread-Index: AQHT75zwy1rxvcT6vECLe4CbyMvvaw== Date: Sat, 19 May 2018 18:12:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.31.71.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR22MB0658; 7:m4HrGbdjw+LoFA7hPJ5Dcz6/aHf5UFyfVZBcBrQoQhcIOPUUf5aPgyA45jtF2SKVx9TypL/EWDXNGV3e6xdJ91WzpnIKQzeksNHmT4xxq/62j+Kkt6M5XDL1NXN2XuEmJYIiLf3ybGiXoANegEe8b1s+KvkX1LYcJ3K+RIl/rSfU7MP7L8or7jlfwk71IYIaCIhIm8lDDO2gJdoQbiUznwnnZc7+KPjBP9cQ3r6lcY5M24nNUGHPV0uF6NV2pVMF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:BN6PR22MB0658; x-ms-traffictypediagnostic: BN6PR22MB0658: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN6PR22MB0658; BCL:0; PCL:0; RULEID:; SRVR:BN6PR22MB0658; x-forefront-prvs: 0677FFABBF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39380400002)(366004)(39850400004)(53754006)(189003)(199004)(316002)(66066001)(25786009)(5640700003)(2351001)(99286004)(966005)(14454004)(6116002)(102836004)(3846002)(5660300001)(6506007)(186003)(82746002)(26005)(36756003)(33656002)(786003)(59450400001)(478600001)(54896002)(81166006)(2616005)(53936002)(236005)(8676002)(83716003)(1730700003)(7736002)(486006)(2900100001)(6306002)(81156014)(6512007)(8936002)(476003)(2501003)(68736007)(6916009)(75432002)(105586002)(3660700001)(106356001)(5250100002)(6436002)(86362001)(88552002)(3280700002)(6486002)(2906002)(606006)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR22MB0658; H:BN6PR22MB0737.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: V6t6SwFlMw6ocsw8McSQLPWWK2kK7ez4x61iK5vQGC9FuUeDeJ1gOlBgRGU3BVcD5L3xSOwBhoOaoZOMDUtMejXWLhHaNDnXExRH6PSV48hx2d8G08bcPhKfKJGcU6RpsA1+2sruPdgvSxFyUKrullbjFtGon3hW0N4dgaVbviSxld2QHGRUD6Xa/MRAkL48 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FA9E7FE114C54C768DF3C2CE7B3FA7DEufledu_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a6034541-f483-4208-7d7e-08d5bdb41351 X-MS-Exchange-CrossTenant-Network-Message-Id: a6034541-f483-4208-7d7e-08d5bdb41351 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2018 18:12:25.7282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR22MB0658 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-19_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-1805190187 X-UFL-Spam-Level: * Archived-At: Subject: [TLS] Editorial comments on draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 18:12:35 -0000 --_000_FA9E7FE114C54C768DF3C2CE7B3FA7DEufledu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGp1c3Qgb3BlbmVkIGEgUFIgZm9yIHRoZSBkZWxlZ2F0ZWQgY3JlZGVudGlh bHMgZXh0ZW5zaW9uIGRyYWZ0Og0KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3Rscy1zdWJjZXJ0 cy9wdWxsLzINCg0KTW9zdCBvZiB0aGVzZSBjaGFuZ2VzIGFyZSBtaW5vcjsgdGhlIG1vc3Qgc2ln bmlmaWNhbnQgY2hhbmdlIGlzIHRoZSBwcmVzZW50YXRpb24gb2YgdGhlIGNsaWVudCB2ZXJpZmlj YXRpb24gcHJvY2VkdXJlLg0KDQpGb3JnaXZlIG1lIGlmIHRoaXMgcXVlc3Rpb24gc2VlbXMgbml0 LXBpY2t5OiBJIG5vdGljZWQgdGhhdCwgdGhyb3VnaG91dCB0aGUgZHJhZnQsIOKAnGRlbGVnYXRl ZCBjcmVkZW50aWFs4oCdIGlzIHdyaXR0ZW4g4oCcRGVsZWdhdGVkIGNyZWRlbnRpYWzigJ0gZXZl biBpZiBpdOKAmXMgbm90IHByZWNlZGVkIGJ5IGEgcGVyaW9kLiBJcyB0aGVyZSBhIHJlYXNvbiBm b3IgdGhpcz8NCg0KVGhhbmtzDQpDaHJpc3RvcGhlciBQYXR0b24NCg== --_000_FA9E7FE114C54C768DF3C2CE7B3FA7DEufledu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkganVzdCBvcGVuZWQgYSBQUiBmb3IgdGhl IGRlbGVnYXRlZCBjcmVkZW50aWFscyBleHRlbnNpb24gZHJhZnQ6PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMtc3ViY2VydHMvcHVsbC8y IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzLXN1YmNlcnRzL3B1bGwvMjwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPk1vc3Qgb2YgdGhlc2UgY2hhbmdlcyBhcmUgbWlub3I7IHRoZSBtb3N0IHNpZ25pZmljYW50 IGNoYW5nZSBpcyB0aGUgcHJlc2VudGF0aW9uIG9mIHRoZSBjbGllbnQgdmVyaWZpY2F0aW9uIHBy b2NlZHVyZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkZvcmdpdmUgbWUgaWYgdGhpcyBxdWVzdGlvbiBzZWVtcyBuaXQtcGlja3k6IEkg bm90aWNlZCB0aGF0LCB0aHJvdWdob3V0IHRoZSBkcmFmdCwg4oCcZGVsZWdhdGVkIGNyZWRlbnRp YWzigJ0gaXMgd3JpdHRlbiDigJxEZWxlZ2F0ZWQgY3JlZGVudGlhbOKAnSBldmVuIGlmIGl04oCZ cyBub3QgcHJlY2VkZWQgYnkgYSBwZXJpb2QuIElzIHRoZXJlIGEgcmVhc29uIGZvciB0aGlzPzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhhbmtzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNocmlzdG9waGVyIFBhdHRvbjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_FA9E7FE114C54C768DF3C2CE7B3FA7DEufledu_-- From nobody Sun May 20 12:10: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 D1E7C12D877; Sun, 20 May 2018 12:10:27 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152684342781.2913.14066810928653071971@ietfa.amsl.com> Date: Sun, 20 May 2018 12:10:27 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-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: Sun, 20 May 2018 19:10:28 -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 : Issues and Requirements for SNI Encryption in TLS Authors : Christian Huitema Eric Rescorla Filename : draft-ietf-tls-sni-encryption-03.txt Pages : 14 Date : 2018-05-20 Abstract: This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-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 Sun May 20 12:14: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 B1CA212D86E for ; Sun, 20 May 2018 12:14:07 -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 NmN2NVEwPQxD for ; Sun, 20 May 2018 12:14:05 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6194512D810 for ; Sun, 20 May 2018 12:14:05 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fKTmM-000074-Bo for tls@ietf.org; Sun, 20 May 2018 21:14:03 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fKTmJ-0003N7-94 for tls@ietf.org; Sun, 20 May 2018 15:14:00 -0400 Received: (qmail 26943 invoked from network); 20 May 2018 19:13:57 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 May 2018 19:13:57 -0000 To: tls@ietf.org References: <152684342781.2913.14066810928653071971@ietfa.amsl.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Sun, 20 May 2018 12:13:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152684342781.2913.14066810928653071971@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5l0YMK/qJvg/y/GTmHjzWKR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6Bx/tE7itqOO1c4SfImizZeiUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2wQwuOVbOJlufBNa9jDYDifvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0Cn4p2u0cbdyGTcIliCOXEyKIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbwyPr6Ygmqufq1En6WLLn AIHlTa0FG0ij7AOlTYklM4LUKrVsT6M0PnVCLod/FBxl3KLO+p8cyRR6C/ualTIzChN7JHLxQFpJ YIEXtFhXCC6O98fck6astPPFccqiLCixm7xl+RQ3vIZqfBpLwZArl3I1g+tBSv0B+cgW7VoPEiDI +8QkA7WZKXURE/tHtZ/uv0lqRWmYZel4DctYKBjcJFhNqyux1yaQvYroLJ1yFFoyaNcmuJcXU9cu hT7Wx3AGQZs4iXA/pTuddAL2KCGOjKaoYeoLX/yEBEWAApw66TpQmfp9/h4Q9GQIjsA8xP6jZhUF HKbUZMv7c3cOU/0VEqn+er0zG7dqpwCE0+bWXAfbMcctPzMPLiqwr8e+aie3zxvdN0leIxaNIjs7 cbPZdZnckpWaLvahyBjmQxBKOztcoEJy5JI/WnEUTEvEJGtKRioNM4YdAO5dQww9T9HjAWtJl6pO HngTL5HKgxzCo5M= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 19:14:08 -0000 This new version of the SNI encryption draft implements the changes discussed in London. It removes the "solution" part of the draft, for which consensus was elusive, and keeps the "problem statement" part, for which we apparently have wide consensus. -- Christian Huitema On 5/20/2018 12:10 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Issues and Requirements for SNI Encryption in TLS > Authors : Christian Huitema > Eric Rescorla > Filename : draft-ietf-tls-sni-encryption-03.txt > Pages : 14 > Date : 2018-05-20 > > Abstract: > This draft describes the general problem of encryption of the Server > Name Identification (SNI) parameter. The proposed solutions hide a > Hidden Service behind a Fronting Service, only disclosing the SNI of > the Fronting Service to external observers. The draft lists known > attacks against SNI encryption, discusses the current "co-tenancy > fronting" solution, and presents requirements for future TLS layer > solutions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon May 21 05:09: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 C0990126E64 for ; Mon, 21 May 2018 05:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bPThhLlJpE2d for ; Mon, 21 May 2018 05:09:33 -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 7DBFE126E01 for ; Mon, 21 May 2018 05:09:31 -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=1526904572; x=1558440572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sa5f5tJCFhDCC7kK529Xvucs4SGimv8Tp6j1r6TDePA=; b=1maVYZkAtyWbk7FJF1UkR/PJ9uXcPkSinVaOx/23mw3WamfXN8+OXwjh 5XCF4NxdVhHR7Y1SuAZj7ud9EdaNArOkzfGBWF5ITsSVEx9lpclj2bQYR 4NgZFo/1MVtfwXkQglTrDgPmG5q1ChY3CQRsyb0x640aTtr2CIHa8QGsZ MLoUDBlXUf6UdxYP0SC8MAhaZTCYTsDs2zDZ6hiexjCKU/P6vN4oTEt47 TNwEl4jn25Mg2St6czbQOoASSjNBiuHuDNS4Xx5FjwPA4W9kNT87UZ0+P M1Zb1tacQHiE72QG4XvQfwaT9owOJbSByOwslRt9W2+OtA+IEJ7eNVCSS w==; X-IronPort-AV: E=Sophos;i="5.49,426,1520852400"; d="scan'208";a="12301046" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from exchangemx.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; 22 May 2018 00:09:29 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 22 May 2018 00:09:29 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Tue, 22 May 2018 00:09:28 +1200 From: Peter Gutmann To: Eric Rescorla CC: Kathleen Moriarty , Bill Frantz , Steve Fenter , "Dale R. Worley" , "" Thread-Topic: Expanded alert codes Thread-Index: AQHT8PxOiBfXisHgz0GQ8m34NZHo8g== Date: Mon, 21 May 2018 12:09:28 +0000 Message-ID: <1526904555196.87951@cs.auckland.ac.nz> References: , <1522560535687.32559@cs.auckland.ac.nz> In-Reply-To: <1522560535687.32559@cs.auckland.ac.nz> 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 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 21 May 2018 12:09:35 -0000 Reviving this discussion, if I write up a draft for this what's going to=0A= happen to it? Will it get published, or shouted down? The reason I'm aski= ng=0A= is that I've just spent the past three days debugging a TLS issue that's=0A= pretty much a poster child for why extended alerts are needed, it was=0A= something that would have been resolved in a single handshake exchange with= =0A= extended alerts, but took three days to sort out without them. The sequenc= e=0A= was as follows:=0A= =0A= Client sends standard client hello.=0A= Server responds with handshake failed alert.=0A= =0A= The same client has been running for years, and connects fine to any number= of=0A= servers, and openssl and some web browsers connect fine to the server. The= =0A= only message exchanged was the hello, so there's zero security issues in=0A= providing extended alerts.=0A= =0A= Since some people have argued that extended alerts aren't necessary or usef= ul,=0A= I'll wait awhile for them to diagnose what was wrong using the information= =0A= above, which was all that was available.=0A= =0A= Peter.=0A= From nobody Mon May 21 06:47: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 A57E6127076 for ; Mon, 21 May 2018 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YYX2oY5OLsYG for ; Mon, 21 May 2018 06:47:42 -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 00CD01270AE for ; Mon, 21 May 2018 06:47:40 -0700 (PDT) From: Ion Larranaga Azcue To: Peter Gutmann , Eric Rescorla CC: "Dale R. Worley" , "" Thread-Topic: Expanded alert codes Thread-Index: AQHT8Py8qEYy0pHq3E+0uC3v1ZC86qQ6LlwQ Date: Mon, 21 May 2018 13:47:37 +0000 Message-ID: <5fd52b8b84f844b68b53a4e6e95513a6@LXDOMEXC01.ssidom.com> References: , <1522560535687.32559@cs.auckland.ac.nz> <1526904555196.87951@cs.auckland.ac.nz> In-Reply-To: <1526904555196.87951@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] Expanded alert codes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 21 May 2018 13:47:46 -0000 I would say it's unfair to expect other people to diagnose the problem by c= laiming "that information was all that was available" because you had acces= s to: - traffic dumps of the failing handshakes - traffic dumps of working handshakes - the possibility to try any number of modifications of the client hello to= go from a working handshake to a failing handshake in order to identify th= e offending option or parameter - as you are going to have to ask the server side to activate extended aler= ts, you can ask them for server logs, as well as traffic dumps of (at least= ) the failed connections on their side (if they receive any, which is addit= ional information) Besides, I also think it's not fair to claim that when someone disagrees, y= ou are being "shouted down". From what I remember, both sides expressed the= ir opinion, and if you manage to gather consensus your draft will get publi= shed. So, I think accusing others of shouting you down is an unfortunate ph= rase on your side... That being said... I encourage you to write your draft and look for consens= us within the group. Regards, Ion -----Mensaje original----- De: TLS [mailto:tls-bounces@ietf.org] En nombre de Peter Gutmann Enviado el: lunes, 21 de mayo de 2018 14:09 Para: Eric Rescorla CC: Dale R. Worley ; Asunto: Re: [TLS] Expanded alert codes Reviving this discussion, if I write up a draft for this what's going to ha= ppen to it? Will it get published, or shouted down? The reason I'm asking= is that I've just spent the past three days debugging a TLS issue that's p= retty much a poster child for why extended alerts are needed, it was someth= ing that would have been resolved in a single handshake exchange with exten= ded alerts, but took three days to sort out without them. The sequence was= as follows: Client sends standard client hello. Server responds with handshake failed alert. The same client has been running for years, and connects fine to any number= of servers, and openssl and some web browsers connect fine to the server. = The only message exchanged was the hello, so there's zero security issues = in providing extended alerts. Since some people have argued that extended alerts aren't necessary or usef= ul, I'll wait awhile for them to diagnose what was wrong using the informat= ion above, which was all that was available. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon May 21 19:17: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 52C6A12DA3F for ; Mon, 21 May 2018 19:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 96ZuGk7G_ARs for ; Mon, 21 May 2018 19:17:01 -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 DBFA2120721 for ; Mon, 21 May 2018 19:17:00 -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=1526955421; x=1558491421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/b6TvNeSEtx9lOEX+i2F2kezbZM103YG+NQJGl41s20=; b=elulPVsjotnG5Rgl7ijrhbwfGOJbI4EiMIL0JOB7Vcf7jkX1c71U1qFN tpiMbeB+X0j4NaN7CPg7lJpnzlj7H+m9yvwmiXRBrQCPrRRFK/9FqKmgw 4fJY85mfzim8llfBQzKCnrAatWMhEi8xkWzNmStfsHHIG5qipRZG78vL0 VVcRXHo795HzkMBOH1PUx7o6Oz6ONIgdggMRTb1Zmfn0dfpIzot4kAxZu QuRHMX9fMmXxYpyfrli8WeDGm+O6SQvDqzTDdUZ+uGEiPAZ9r0NCz6m57 4eC3vIFMNINK05ULalZJHio3dBbriRmo9Tbnao1siYiTeYOZ95d4AWxD9 w==; X-IronPort-AV: E=Sophos;i="5.49,428,1520852400"; d="scan'208";a="12418698" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 May 2018 14:16:53 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.28) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 22 May 2018 14:16:53 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Tue, 22 May 2018 14:16:53 +1200 From: Peter Gutmann To: Ion Larranaga Azcue , Eric Rescorla CC: "Dale R. Worley" , "" Thread-Topic: Expanded alert codes Thread-Index: AQHT8PxOiBfXisHgz0GQ8m34NZHo8qQ5aWuAgAGZ+L8= Date: Tue, 22 May 2018 02:16:53 +0000 Message-ID: <1526955398665.97588@cs.auckland.ac.nz> References: , <1522560535687.32559@cs.auckland.ac.nz> <1526904555196.87951@cs.auckland.ac.nz>, <5fd52b8b84f844b68b53a4e6e95513a6@LXDOMEXC01.ssidom.com> In-Reply-To: <5fd52b8b84f844b68b53a4e6e95513a6@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] Expanded alert codes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 May 2018 02:17:03 -0000 Ion Larranaga Azcue writes:=0A= =0A= >I would say it's unfair to expect other people to diagnose the problem by= =0A= >claiming "that information was all that was available" because you had acc= ess=0A= >to:=0A= >=0A= >- traffic dumps of the failing handshakes=0A= =0A= There was no access to this.=0A= =0A= >- traffic dumps of working handshakes=0A= =0A= There was no access to this.=0A= =0A= >- the possibility to try any number of modifications of the client hello t= o=0A= >go from a working handshake to a failing handshake in order to identify th= e=0A= >offending option or parameter=0A= =0A= That was only after the second day of negotiations, when I managed to get= =0A= indirect access to the server to use it as an oracle, resulting in trial-an= d-=0A= error modification of the client hello until the server didn't report a=0A= handshake failure any more.=0A= =0A= >- as you are going to have to ask the server side to activate extended=0A= >alerts, you can ask them for server logs, as well as traffic dumps of (at= =0A= >least) the failed connections on their side (if they receive any, which is= =0A= >additional information)=0A= =0A= Neither of those were available, and neither of them could be made availabl= e.=0A= As I said in my previous message, the only information I had was "Handshake= =0A= failed".=0A= =0A= >Besides, I also think it's not fair to claim that when someone disagrees, = you=0A= >are being "shouted down". =0A= =0A= What I meant was that as it's a non-zero amount of effort to write up a dra= ft,=0A= I wasn't terribly keen on putting in the effort only to have it bikeshedded= to=0A= death with "it's a security problem" (it isn't, unless you go out of your w= ay=0A= to make it one), "you can look at the server logs" (no, you can't), etc. S= o=0A= what I was trying to get is an idea of whether it's worth writing a draft o= r=0A= not.=0A= =0A= >That being said... I encourage you to write your draft and look for consen= sus=0A= >within the group.=0A= =0A= OK, I'll give it a go.=0A= =0A= Peter.=0A= From nobody Tue May 22 06:11: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 7B6D712EB3D for ; Tue, 22 May 2018 06:11: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 bWTHyWYd5vrg for ; Tue, 22 May 2018 06:11:54 -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 9393A12EB3A for ; Tue, 22 May 2018 06:11:54 -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 AFF717D83A; Tue, 22 May 2018 13:11:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.34.246.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2430C6B410; Tue, 22 May 2018 13:11:51 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Ion Larranaga Azcue , Peter Gutmann , Eric Rescorla , "Dale R. Worley" Date: Tue, 22 May 2018 15:11:43 +0200 Message-ID: <5924196.sQIzhslrlE@pintsize.usersys.redhat.com> In-Reply-To: <5fd52b8b84f844b68b53a4e6e95513a6@LXDOMEXC01.ssidom.com> References: <1526904555196.87951@cs.auckland.ac.nz> <5fd52b8b84f844b68b53a4e6e95513a6@LXDOMEXC01.ssidom.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15429800.jRxluuDhXp"; 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.2]); Tue, 22 May 2018 13:11:53 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 22 May 2018 13:11:53 +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] Expanded alert codes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 May 2018 13:11:58 -0000 --nextPart15429800.jRxluuDhXp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote: > I would say it's unfair to expect other people to diagnose the problem by > claiming "that information was all that was available" because you had > access to: >=20 > - traffic dumps of the failing handshakes > - traffic dumps of working handshakes > - the possibility to try any number of modifications of the client hello = to > go from a working handshake to a failing handshake in order to identify t= he > offending option or parameter - as you are going to have to ask the server > side to activate extended alerts, you can ask them for server logs, as we= ll > as traffic dumps of (at least) the failed connections on their side (if > they receive any, which is additional information) >=20 > Besides, I also think it's not fair to claim that when someone disagrees, > you are being "shouted down". From what I remember, both sides expressed > their opinion, and if you manage to gather consensus your draft will get > published. So, I think accusing others of shouting you down is an > unfortunate phrase on your side... you need consensus for Informational RFCs? that's news to me... =20 > That being said... I encourage you to write your draft and look for > consensus within the group. =46or what it's worth, and with all the downsides it would have (it would h= ave=20 to be an extension, so not every server would implement it; what about aler= ts=20 not allowed to be fragmented, and interaction with max_fragment_length?), I= 'm=20 in favour of more expressive errors (and more strict/detailed guidelines wh= ich=20 ones should be sent when). > -----Mensaje original----- > De: TLS [mailto:tls-bounces@ietf.org] En nombre de Peter Gutmann > Enviado el: lunes, 21 de mayo de 2018 14:09 > Para: Eric Rescorla > CC: Dale R. Worley ; > Asunto: Re: [TLS] Expanded alert codes >=20 > Reviving this discussion, if I write up a draft for this what's going to > happen to it? Will it get published, or shouted down? The reason I'm > asking is that I've just spent the past three days debugging a TLS issue > that's pretty much a poster child for why extended alerts are needed, it > was something that would have been resolved in a single handshake exchange > with extended alerts, but took three days to sort out without them. The > sequence was as follows: >=20 > Client sends standard client hello. > Server responds with handshake failed alert. >=20 > The same client has been running for years, and connects fine to any numb= er > of servers, and openssl and some web browsers connect fine to the server.= =20 > The only message exchanged was the hello, so there's zero security issues > in providing extended alerts. >=20 > Since some people have argued that extended alerts aren't necessary or > useful, I'll wait awhile for them to diagnose what was wrong using the > information above, which was all that was available. >=20 > Peter. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =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 --nextPart15429800.jRxluuDhXp 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+dkqjRuAHS9fUFAlsEFw8ACgkQkqjRuAHS 9fX0yhAAndptzfOc2K4ToWgTYFLHJcf1qgW8KmAXWxqw97LgXKoNfvobskNIVYO6 pwNT2FR/elx6U/G9rzwHWQQXWT+mNBiH3fxdFk92tH4PO8FrHDP+RBheJRXELHsW a3Ua3L214o06VWoCphTM0nNJEzme0OZbRkLf4If+ncT1Q+e+unc748XlHb4sWqBP 6vUNrXMkWkHQVC5aDZuccKCoTYkGZTi0F7oUPWzpiFzC6ps8fRDvILxx+QRe1vGv 7AJcUQ7Z7bfJKhOZi6KFN9seaEEAQIMuWOA1Ck5dcQJDsEmoz+NmsvOxKp7Be+EM Z3SqHmE9dqJXhtF7rY18Xt+nbMESPGWioAr7C7TC0GvG59qFphP+uvubJHqgudDq VzHi+SMyg8/jq+bPAYXNRPcLO6BsyoAiGqTLEZ3EHWHYX7crP0bD0R7rHRvvevhq +TfQJzLzTDi7w0A/qMqFWQEL11dtgj+lN3exT6AIjjOQFqfiV0VUBvup447i6hwg ns35JByoV4SB5FbOoXjXeQwUjw8Sizg5nJQg1URfsLdHwz36wsMvC9YoiY8zpebY W3OsF+CjRLr+qjsfTGWxznk/WY0MAMYDEk/vZWQK2N5dX9aXVVtqdFpiNSWbzECD Q/AVngqhV1D0t5oRd6zNkFjh1tbskKJPqFHJkBurmdDvdF+WOUk= =DprE -----END PGP SIGNATURE----- --nextPart15429800.jRxluuDhXp-- From nobody Tue May 22 06:22: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 151BD12704A for ; Tue, 22 May 2018 06:22: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 e-WT8ul_RA3u for ; Tue, 22 May 2018 06:22:51 -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 19346126E01 for ; Tue, 22 May 2018 06:22:51 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id t1-v6so20875380ott.13 for ; Tue, 22 May 2018 06:22: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=bYbfLlBaCJlPdHnUCQJZZ3yH0bA+Z89yuTRcdvpwTSM=; b=m7XCNDOpj44fopkh+AcGgT87FpuTKI4EjE1shmDeM/gBtmRQ5JWKJPfkpNn9bOTquB bAMS0t2mM4D11ZkJBYvy7k1B/jnKxkud7N+ddXz/R5piNDpE2mF5HuWJ1hXvImkg4rXK NU0P1vFY08fYAVFY0vie7LpibsHifI07YaDJqIvcyOPNfeDuIZ3hIUjomJA0vz/wjVD7 tSxnZD6vOvM9KPdqOsrl09AbfXnR3DBIEtaPA3sQYunpt1tYf7W48kJlD33RWYb+4DtT E5k5jd0C2uOdV8E8PzmUHzTm853HzZ/azOmzb3NvuPcsuZXVOa5kAkcVdoqXfEHM9IR7 5lPA== 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=bYbfLlBaCJlPdHnUCQJZZ3yH0bA+Z89yuTRcdvpwTSM=; b=EBsCktnhBskOauxGcZIWywZTWoi1V50hmvAULUgEip13BIVNjcqRVIIFLo5JAMNlZy L4aoJqsE6M1lX/DBOqu5/03eBOw+eQmQ5WcctbebVeTFyEweRlr1aseGpnbwXwXwBGKW F7wLg1MrYleaZZfTEu8X9goYQw5b4zfsG0WrvGFmuyDY+A7JPZ9SaY8Fx3LoMwBn4rg+ TqjllOGIXPV+ZVPoZ6wdXQBURiB3c3dY1e1C8UvRWV+LW/xF7p9kU9WVvENubZ88liH0 RPJ1/K3E565Gt0Pil8O9xU0ItMwXC0LrDr0ZJMur0dyHIWvbfEUdbNG5RWokZHXZ0bCt RUMg== X-Gm-Message-State: ALKqPwer7hVxDhO/R6FJj/aO9bGRflcNC+6SF+uC74jmfB+S55Syo7vo OyTqQNmCJGtSnzoUFoCSm+IIwYz33r/G/bR2F7tWMA== X-Google-Smtp-Source: AB8JxZr0fJqYU0TfGarfr8jLPo6PYZYtyaS3Vh+o86atz5++ZxpepHpVSzmPnHY6QM5KpxNLuHCPIQhdQc/ZvVw78R4= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr17144678oto.371.1526995370511; Tue, 22 May 2018 06:22:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Tue, 22 May 2018 06:22:10 -0700 (PDT) In-Reply-To: <5924196.sQIzhslrlE@pintsize.usersys.redhat.com> References: <1526904555196.87951@cs.auckland.ac.nz> <5fd52b8b84f844b68b53a4e6e95513a6@LXDOMEXC01.ssidom.com> <5924196.sQIzhslrlE@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 22 May 2018 06:22:10 -0700 Message-ID: To: Hubert Kario Cc: "" , Ion Larranaga Azcue , Peter Gutmann , "Dale R. Worley" Content-Type: multipart/alternative; boundary="000000000000a22d00056ccb50fd" Archived-At: Subject: Re: [TLS] Expanded alert codes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 May 2018 13:22:53 -0000 --000000000000a22d00056ccb50fd Content-Type: text/plain; charset="UTF-8" On Tue, May 22, 2018 at 6:11 AM, Hubert Kario wrote: > On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote: > > I would say it's unfair to expect other people to diagnose the problem by > > claiming "that information was all that was available" because you had > > access to: > > > > - traffic dumps of the failing handshakes > > - traffic dumps of working handshakes > > - the possibility to try any number of modifications of the client hello > to > > go from a working handshake to a failing handshake in order to identify > the > > offending option or parameter - as you are going to have to ask the > server > > side to activate extended alerts, you can ask them for server logs, as > well > > as traffic dumps of (at least) the failed connections on their side (if > > they receive any, which is additional information) > > > > Besides, I also think it's not fair to claim that when someone disagrees, > > you are being "shouted down". From what I remember, both sides expressed > > their opinion, and if you manage to gather consensus your draft will get > > published. So, I think accusing others of shouting you down is an > > unfortunate phrase on your side... > > you need consensus for Informational RFCs? that's news to me... > You need consensus for WG documents in general, though not necessarily for Informational RFCs through other channels. With that said, once https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ is published, it will not be necessary to have an RFC at all for a code point registration. -Ekr --000000000000a22d00056ccb50fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 22, 2018 at 6:11 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote:
> I would say it's unfair to expect other people to diagnose the pro= blem by
> claiming "that information was all that was available" becau= se you had
> access to:
>
> - traffic dumps of the failing handshakes
> - traffic dumps of working handshakes
> - the possibility to try any number of modifications of the client hel= lo to
> go from a working handshake to a failing handshake in order to identif= y the
> offending option or parameter - as you are going to have to ask the se= rver
> side to activate extended alerts, you can ask them for server logs, as= well
> as traffic dumps of (at least) the failed connections on their side (i= f
> they receive any, which is additional information)
>
> Besides, I also think it's not fair to claim that when someone dis= agrees,
> you are being "shouted down". From what I remember, both sid= es expressed
> their opinion, and if you manage to gather consensus your draft will g= et
> published. So, I think accusing others of shouting you down is an
> unfortunate phrase on your side...

you need consensus for Informational RFCs? that's news to me...<= br>

You need consensus for WG documents in = general, though not necessarily for Informational RFCs through other channe= ls.

With that said, once https://datat= racker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ is published,= it will not be necessary to have an RFC at all for a code point registrati= on.

-Ekr
=C2=A0

--000000000000a22d00056ccb50fd-- From nobody Tue May 22 17:13: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 7540B12D94F for ; Tue, 22 May 2018 17:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 WW-Qnnq15010 for ; Tue, 22 May 2018 17:13:12 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 AF56A12D777 for ; Tue, 22 May 2018 17:13:11 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f13-v6so25883370qtp.10 for ; Tue, 22 May 2018 17:13:11 -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=n0Cs3BAemuCIOVLgd8Lz5GQ2TgJ7nXTQslknTGo6Sgc=; b=jBMypqBVzbrBQSLMoufuO1h8Mp2ombTEX3UfNs1zCfqq0hCnfcTXSbeoQ/6aSyAgaM TJpX7cJQtB1WAwF9LFQurlOVWlEqReOh3Gnj3gRzTSbh2Eb+/B2f2r5IFoQno6JJwRvB ued+8k57eIJYahW9JosG4MVUGGjtjTxSVTAWE= 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=n0Cs3BAemuCIOVLgd8Lz5GQ2TgJ7nXTQslknTGo6Sgc=; b=J+PHpuWHqB3fBRe+2LctW4psFhzTY2nZMZgQrLr08vl/x4ZlWnV1H7ikxYLiZy649A OOuuXtZUl423t1uMH7t4Z8hUfU5W0hCIMhms1aYdQID2etMddNHBLzLftS6lRWezWUio DYcgLB42F8Tm4x4SHFdRKMZlW5N5hlaBuomn02CO8uC/PK0cwM6XRanDt8DNyrlgtfrg +ky8iMACdShIKdKGZPL9z00wLB+nIxxyTzRrZE7z9vaQp+0h96HPspc+1QdaV53PsUfc 2Ij3029hnyCTwRMPYkY3oEf4u8Uyu7vrNSKtF5tLwKZ8t6FmSUYvXYXxqMfBG5rCfAr9 I0Pw== X-Gm-Message-State: ALKqPwcWMETm3s5dMto6OC6XnIvntK63CJ2B+YwEU7nOApjDqW9WYan1 HEUoyy8usR2h+J+Bw2a2/wdJ7mBOyL4= X-Google-Smtp-Source: AB8JxZqSSDprEdrVxgJwfsbdTS70eit9L6TG0DqIUr3J3ChJx0FMqH1AGPwnjYVMtL5UJTPXtffstA== X-Received: by 2002:a0c:bfaa:: with SMTP id s39-v6mr551550qvj.185.1527034390704; Tue, 22 May 2018 17:13:10 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id j25-v6sm12299722qtn.29.2018.05.22.17.13.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 17:13:10 -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: <362431E5-0B10-4E8E-AFF1-4B8217D27C64@sn3rd.com> Date: Tue, 22 May 2018 20:13:07 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] TLS@IETF102: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 May 2018 00:13:14 -0000 The TLS WG will be meeting @ IETF 102 in Montreal. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to tls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. Cheers, J&S= From nobody Wed May 23 07:38: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 A207812E045 for ; Wed, 23 May 2018 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GKeOy1-sR4I for ; Wed, 23 May 2018 07:38:40 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EB912E03C for ; Wed, 23 May 2018 07:38:40 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f21-v6so23043684iob.13 for ; Wed, 23 May 2018 07:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PbQ89LhJxT/FHO0DegaYWy/NkQGt27pdi0z5kLf0PXE=; b=arQ9/YezidSaZSA+ExEv0/Z3QmAuxhU3SnBHoPBPkASjl/Tiv/UN+EvQKv3sJ3Lvwb amZ1pmQN32QyCF8IPNteeiKaxxpDcHIvmYPHptAFfOZ1dH5AiA92EBvozzbWufBGRv1p Esth3Wno4MMlVjMG2dQrwwHe3NLsoer9L1KruGFl+bJNcleTK3/rDEbVasP2OnM76FtY 4guGgoVOBjPJyf2XxbxHJ2Om/7hD75JCblsb7vlcAc9OcjKLBA8NI4Nig0ay3duZloFa E2M90N0nTZ94tpAWvksWrbqu+dv398Gj2z18nS3ehQ8dAwFvc2bMO7PHc6Nk/CNA3NcT diaQ== 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=PbQ89LhJxT/FHO0DegaYWy/NkQGt27pdi0z5kLf0PXE=; b=t8jIrCPLcA6BSob47LYbLZD5gv4x03PJH1GERy302aFDgItl8LPOqoEBydEqmRjP+l d3qNuGUrZGN04Mk1hwhS7ux7/eknMg1+AZsh6k4yR8IMpQwr9yf721+H7m8Kbzbmw64s NY5p46Kuwt03UoSejNZXOt9enz0sCyV1Ywdilb8cQKyis+Tjfn9hOJa/Zck1X6tBIan5 8S2s9d+hSRvRrxF49A4XRa/1Ugzo0rPpsom8gwn+ct/Q870Ese4euGRtOA5nTFSeHKY2 gwzcrcqNwd1pwgSszTMOhI46X5m9IVfl/6W9xLM6pqvEHmjTviEwEHbf3tDqKygascU3 T5XA== X-Gm-Message-State: ALKqPwd8ncC3hjaMWx4n0QttTTeVK1ZgrsRaIXrbywEeDSrYjTdqkbig ZbWc+Giib8soAuQSXYnGwFx6ydF6lw2JGjA4n+NI4Pun X-Google-Smtp-Source: ADUXVKIDEQvglTWvhZJuy/SSAbxeskPg1FfvTvRz7ojKS5vJHk6TqzvGZLh6vf130F95KBV9JHOqJ666JACyiXm8lAI= X-Received: by 2002:a6b:a50c:: with SMTP id o12-v6mr2748899ioe.16.1527086319165; Wed, 23 May 2018 07:38:39 -0700 (PDT) MIME-Version: 1.0 References: <152684342781.2913.14066810928653071971@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Wed, 23 May 2018 10:38:27 -0400 Message-ID: To: Christian Huitema Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a3da3a056ce07d3c" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.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, 23 May 2018 14:38:47 -0000 --000000000000a3da3a056ce07d3c Content-Type: multipart/alternative; boundary="000000000000990627056ce07db2" --000000000000990627056ce07db2 Content-Type: text/plain; charset="UTF-8" Thanks for this document, Christian. I think this is a very clear and cogent exposition of the SNI Encryption problem. There have been some questions about whether this SNI encryption work is in conflict with the Alt-Svc-SNI proposal in HTTPBIS. My view is that there is no conflict: that proposal is HTTP-specific and does not alter TLS, whereas this work is aimed toward TLS changes that may also conceal other ClientHello parameters, like ALPN. --000000000000990627056ce07db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this document, Christian.=C2=A0 I think this is= a very clear and cogent exposition of the SNI Encryption problem.

=
There have been some questions about whether this SNI encryption= work is in conflict with the Alt-Svc-SNI proposal in HTTPBIS.=C2=A0 My vie= w is that there is no conflict: that proposal is HTTP-specific and does not= alter TLS, whereas this work is aimed toward TLS changes that may also con= ceal other ClientHello parameters, like ALPN.
--000000000000990627056ce07db2-- --000000000000a3da3a056ce07d3c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAhM+MJC6B2nJGCK8B3/Qvj qeDSB9NkeYJwL4b+2Dp01jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MjMxNDM4MzlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAOwiAZ54LWesIiHrxvb1kQSqv0K0DcN0CnEQz1Mr8 C4qpLcu+/72/FjaFeGeAAw+Ytt3u0hABMmz68GRCbddXHmt2bbzAQ2OoTSpr02fRk9qXEpuqlMFE QfO4NiSTzKbsw3pI6OIOm77jl99e4A//1lQVBsnzocT7EAi+dYwuXx2juKQSoiTKJxt0tNq0TaRm eiwSINLQAM4ftgSRrLC57NWoVRzSVBwR7cMlmZ1RCkT7pS1YUCsV2L551jiXcBvBcfJqtN3T8M5C RtRryHirf+RdrRcCWU+aF3m7knQjywtXMytaKGZ7kvh8df+zuFh94BGK+dGq8QEeTSPXazNjOQ== --000000000000a3da3a056ce07d3c-- From nobody Wed May 23 07:49: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 DDB2B12E04B for ; Wed, 23 May 2018 07:49:37 -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 9J86M7kNphen for ; Wed, 23 May 2018 07:49:36 -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 ECA43127078 for ; Wed, 23 May 2018 07:49:35 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id g13-v6so28384672qth.8 for ; Wed, 23 May 2018 07:49:35 -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=OabntlveP7iXZ8UNHREikXZNjWt8BUEQGEHIzdkUBc0=; b=hc+iTI+Kl2gY6l6qApyjiU8krj0xqtEIMlRHRSWB9NOTROeWh/2q6Cp+x12S1+IodY pslZ33Rpi24PP81NFNG4I+DQMhjBI+/r6HEaYXBrCfAZ7DRE5Ly9FSXXgN6JSdpS3n46 834y+ptxDg7fJ4LRjg75IhS6Su6D+S1ZAmT5w= 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=OabntlveP7iXZ8UNHREikXZNjWt8BUEQGEHIzdkUBc0=; b=e4xTukDZx3+/UbJupfCQX2d3cmTRbtuEn6Uh0HlChC4oh5LkpDiS87ztxcwfRBie3Z ab3F42hDwdOfNRcjbkVaSh1H95m4OhpmjanTFGIWCaFwsY05y6Lk0YUiQtOGrJRx9Hhk ksBkkqsip++mpWEVv9GYSQgi7uOXOyqgY4EUvFyvdYFE1l0YSeoBL6rvUEysE/4EDCtl isV304cOqDGgyjWMng8PbwqxpD1olnXRc4hDcgxmds0pS2NfBJZ3q5LZIdpoe2f41o4P RN37KEuPzrAnzrnGBE8eqa8qTQ1oMvNc2RHr6u0lbvgOlGMexQ/ix875ezMV5bSCkNmz XXyQ== X-Gm-Message-State: ALKqPwc+2ijSjoPWvNoKSqpI6yv0U5fll9J0RgiD7d3BP+33sTNi+YLj 7K1mXARnWr0FhXnUP3xFzzkW+A== X-Google-Smtp-Source: AB8JxZpLTzGacn3UnZDxnMU0aIkNmvsKplxmGEK5yP6tc2OAGl83l5coMOfZmOt8lQDnD3Z/auKWqw== X-Received: by 2002:a0c:946c:: with SMTP id i41-v6mr2845384qvi.139.1527086975007; Wed, 23 May 2018 07:49:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id u25-v6sm865327qkl.25.2018.05.23.07.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 07:49:34 -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: Date: Wed, 23 May 2018 10:49:33 -0400 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <152684342781.2913.14066810928653071971@ietfa.amsl.com> To: Christian Huitema X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.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, 23 May 2018 14:49:38 -0000 > On May 23, 2018, at 10:38, Ben Schwartz = wrote: >=20 > Thanks for this document, Christian. +1 for keeping this going. spt= From nobody Wed May 23 11:11: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 6D63B1276AF for ; Wed, 23 May 2018 11:10: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, 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 cbBcpXHlG6-R for ; Wed, 23 May 2018 11:10:57 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6E81270A3 for ; Wed, 23 May 2018 11:10:57 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f21-v6so23877405iob.13 for ; Wed, 23 May 2018 11:10: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; bh=rRBbii2L0qwHm/D3T6+5LrmvLUgYlA6GcLvrvZDsScE=; b=FlELt0+Xd4r8RJicENyQXj1glbB9Uu+h5FalASHGXPu4c2QT5hpk4jE7xvnpCq5o0O Ri7WXQ0SuhxQE1fNPbcowbXf3IKyqgk2Eanrt+aQe7L+Yy5nZ6hlYkDj/IjavUJi8HXK qpY8erCyIvA1W7dRRLvShTdxHpUJKD+bzYecfAAQ4DH3KHXPGRx6wodgULWtEC3YXc1D XaLtG0l/Kott6sm0cZ+uk7AKqD0RXajEYgaP+ysmaL9xBLjqn1gbYlbZPQbJa5LvHfT8 IEY00YeVRrt9HF8Ck4z6rK5uhG5snMzmXLqeDwSXq3xtRP4pQc7p3u7b8zu41kn12rRk guIw== 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=rRBbii2L0qwHm/D3T6+5LrmvLUgYlA6GcLvrvZDsScE=; b=Rtnpn09EMkw0KukkwWrW24mnSdo3astFAlOi3Ek9nfCxnXYnLJCwxh77Kvy/aom1cY bepbukgKg4UjJureWNVKTJgM5R8qDFrBB3lk6xCv31XWTX8EvXeY4/5469FfQ5cyxhhS qY+DogATsjDfzjRkiThe1Invb9tOhQHmL4suoWEgLIzgyn87xsR3UUktV7Nz1pwyiyUu dQZaVvGhaC6dyDBIeMbLa43L5ZkuHaWCA6CW7zAhihtwbjUklvR6/yhaA05vUpkEe0p0 bZQ9/7Ayxjz6qKvhmcYnt3vxIb9iOgPV0JWrVs9Ggm5IHbKXuKyhCyrxGQeZTLSTGsXA zOwQ== X-Gm-Message-State: ALKqPweHku+L2VqCfEabst7V1SGiohYhesQfT3uGvxUoVNoC9dqzAY9Y bG3BeG9SsCwKrWKfg+Wy0B7lrrHvSToN7/jSd3c= X-Google-Smtp-Source: AB8JxZqmpiJ6kfbB/2pc3QepO2+u7q9E9XvuBQSjqqXiKoc3c3Yw4hXokhNUqMjBSj8tCODxS84Wh8qP9R3/Qz4dYNs= X-Received: by 2002:a6b:c006:: with SMTP id q6-v6mr3561729iof.61.1527099056877; Wed, 23 May 2018 11:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:bc01:0:0:0:0:0 with HTTP; Wed, 23 May 2018 11:10:16 -0700 (PDT) In-Reply-To: References: <152684342781.2913.14066810928653071971@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 23 May 2018 14:10:16 -0400 Message-ID: To: Sean Turner Cc: Christian Huitema , TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.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, 23 May 2018 18:11:00 -0000 Hi Christian, Thanks for including text on the known uses of SNI. Hopefully if there are other known uses, they will be contributed for evaluation of this problem space. In section 2.2, enterprises can still use proxy based or active interception solutions to enable inspection of traffic on their network. I suspect that will be the method of choice over the endpoint for some time to come. I also don't think it would be universally accepted that enterprise interception, where they have agreements from users to monitor (employment agreements - common in US and EU, with Germany being an exception here as apparently they have a law for users to have an expectation of privacy when doing personal business from the work place), should be classified as an 'attack'. I think rephrasing for that use case would be helpful for the neutrality of the document. Section 3.8.1 - TLSv1.3 already encrypts the ALPN response via EncryptedExtensions. Is this argument for TLSv1.2? The response is where the answer on the negotiated protocol is provided and it's already hidden, so I'm not clear on why this is here except if it is for earlier versions. This draft just says hide the ALPN, are you concerned about the request too with the list of possible protocols? Thanks, Kathleen On Wed, May 23, 2018 at 10:49 AM, Sean Turner wrote: > > >> On May 23, 2018, at 10:38, Ben Schwartz wrote: >> >> Thanks for this document, Christian. > > +1 for keeping this going. > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Wed May 23 12:44: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 9DBFB12E8DF for ; Wed, 23 May 2018 12:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tW_trKSTaLyU for ; Wed, 23 May 2018 12:44:18 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 B933B12E868 for ; Wed, 23 May 2018 12:44:18 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id i2-v6so15575450uah.0 for ; Wed, 23 May 2018 12:44:18 -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=63mErz1Z/3tyMpRNQ2GolVUSdZw3+/j75tkxo3/nATQ=; b=L3kmXpLrsfzzhEZJlpBLm3PZoVBDF9pBIQ0JFnDj6wZShmK+dkEUBxDe5lFXSrZtp6 dSYKZCcWMWffjJkt0knRE8ePd7ucnoTXn1f9dL5EtttHqeUDJ1ltFGhBYe5i+lEfQ97i Vq1/d+NOQyBt+fXyQRPfs+osCs5L/7hHA54lk2KCd7JlMjkzHWXFKCEOQaZ1yfw0Izmw xF04xrCfJQ8uM25wnaF54l3r3J9GooZLtGb2+WcmHKwFxdMP8stQy+DgXnlgKqUz5vWx BInqz4uOhyJOAy/B1HjU7LYPitn922IpWTyJLLZ4jy+5yPGexmxioIfbtaUb5Borppr3 jWhw== 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=63mErz1Z/3tyMpRNQ2GolVUSdZw3+/j75tkxo3/nATQ=; b=FUFWg2l9TMqR8iRLgNWFY/mA3EkebJCTdO4WKQ9oLpBUEUnUsKXZwyqzEco6+Ua8yH 2PnKyoQb3XRbTsV78qSg6YVzpEFrfoPkp2OVKpHS4DCcHUkYQvOUYPZYawYJZPHzIi4J wlCxgSa6ghpgExM0rnk6PH6uUYcScq6SVwq8RZe4YdUlN8JMCUFvFv2U81jFh+WpYlc8 DzbiA1pXouQ0SqA0/SXDvloRps7DA5W9S8jMoqdLW03rqXZz0Gubb0jSbE3T6Yr+/oCe CubZ0u3Fp8gc01L093zPYkSwyAmVrubeWlJpag//Y35mwdYS1adVL4ajDZnMPCd1JR9T OESw== X-Gm-Message-State: ALKqPwe4RSJpWjzmt/8KCo2tXxFv8yleDAuTP3v+btY6rMwgIgm1IsHC YGERtjRcIldMskEQ8hwHCJHAF85cdPIiMBo2zgc= X-Google-Smtp-Source: AB8JxZo/UFsY/7snwchco320B0g0cYUTu96KzYwFPMb4PhVv59UIVUnq7Dnsww6KvvI+q0b/nNJn2vvbAYQ5hWk+e3A= X-Received: by 2002:ab0:5a30:: with SMTP id l45-v6mr2872491uad.79.1527104657577; Wed, 23 May 2018 12:44:17 -0700 (PDT) MIME-Version: 1.0 References: <152684342781.2913.14066810928653071971@ietfa.amsl.com> In-Reply-To: From: Artyom Gavrichenkov Date: Wed, 23 May 2018 22:44:05 +0300 Message-ID: To: kathleen.moriarty.ietf@gmail.com Cc: Christian Huitema , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.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, 23 May 2018 19:44:28 -0000 Hello Kathleen, On Wed, May 23, 2018 at 9:11 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > In section 2.2, Do you mean 2.1? > enterprises can still use proxy based or active > interception solutions to enable inspection of traffic on their > network. Or, they can easily set up some group policy to inspect and/or block some specific resources. Or, in most cases they just had an unrestricted physical access to a user's machine before, so they could have installed an arbitrary inspection app onto it. In case of BYOD approach, an enterprise is not in any way different from just an arbitrary ISP. I support removal of this case, it's virtually impossible to protect against it. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From nobody Wed May 23 18:23: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 6232E128896 for ; Wed, 23 May 2018 18:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EkGmg-5b0c55 for ; Wed, 23 May 2018 18:23:15 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172B51289B0 for ; Wed, 23 May 2018 18:23:15 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id k86-v6so3472882qkh.13 for ; Wed, 23 May 2018 18:23:15 -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=jAl9qG8X0xk+jvmdJEFqX4DqaKlRU5koJ7yapA8BZ4Q=; b=QFOE7cHM0OPJolYKTTevNaswLEGc70jLBtsRZwnFNlbXHmq2+jpY67deWVlI7TlsJc tSk6uXaBWcaRexMegjkUOgubg1iR4kRDzFkbzgis8vcYxB0eXAU9eiH0IBYAvzAL3Vuc As8sNlhOu7wDfopY8iSN0lJp1CJEbk+N0nrEY= 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=jAl9qG8X0xk+jvmdJEFqX4DqaKlRU5koJ7yapA8BZ4Q=; b=fsFwbr7lK6hkIvexsfXQhs6MyHNcIpRD8YRe/oIWXmK6tFjixh5kG/ULZhPLRwD1yX DCoZ2PYUr5SULtgAfU+uh0lHtdpxmfaLFyHhmc2CtErhZGid65NldH/NHf/7Gtzns+CE 9jwQSOfHTSwcU1oe5BWwFTG1cPJ6qI5WqDOKYa3JrbkFiDasGUOgc6LGtbQcH2wPfBxu Th9a85s7WkAYODkRdyz6LSgjNKnE7ZAxmqnaEDMDvL0g5cX89tsI9zj3rOnVDo3mI/mu koDwTZu0Rng+sVrf4EkHffIkvXd4NDInD2k034cJmOueH3UyOLIdwRM9NQObXVdlfFez 0HEw== X-Gm-Message-State: ALKqPwcXY5Ptm1u7RdCmAydWyJMYrvuG/RkT4sRguFYeLgPh7wzlo1w8 yl9bDpubX0TEtyMveKMJlP4NotZCZT4= X-Google-Smtp-Source: ADUXVKJy7jo6NkMnqHi8vwBYnI41dtHh8gnBc7aGC/CUUvz6dH/+SfJ3prne2TRkR9dTu8G9vv2nPw== X-Received: by 2002:a37:1828:: with SMTP id j40-v6mr3570068qkh.11.1527124993949; Wed, 23 May 2018 18:23:13 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id q10-v6sm16365368qtk.7.2018.05.23.18.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 18:23:13 -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, 23 May 2018 21:23:10 -0400 Cc: draft-ietf-tls-certificate-compression@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 01:23:18 -0000 IANA has assigned the following values: 1) In the ExtensionType Values registry, the following entry was added: 26 compress_certificate (TEMPORARY - registered 2018-05-23, expires = 2019-05-23) [draft-ietf-tls-certificate-compression] Please see https://www.iana.org/assignments/tls-extensiontype-values 2) In the TLS HandshakeType Registry, the following entry was added: 25 compressed_certificate (TEMPORARY - registered 2018-05-23, = expires 2018-05-23) DTLS-OK: Y = [draft-ietf-tls-certificate-compression] Please see https://www.iana.org/assignments/tls-parameters NOTE: IANA can=E2=80=99t create the registry for the compression = algorithms until the document is approved by the IESG, but Ben (and the = chairs) figured we didn=E2=80=99t really need that to get this going. = If additional compression algorithms start to get used, let=E2=80=99s = make sure to note what they are. spt >> From: Sean Turner >> Subject: early code point assignment for = draft-ietf-tls-certificate-compression >> Date: April 23, 2018 at 12:33:08 EDT >> To: TLS WG >>=20 >> All, >>=20 >> 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. >>=20 >> 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: >>=20 >> Criteria A >>=20 >> 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. >>=20 >> 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. >>=20 >> Criteria B >>=20 >> 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. >>=20 >> 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. >>=20 >> Criteria C >>=20 >> 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. >>=20 >> 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. >>=20 >> Criteria D >>=20 >> 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. >>=20 >> 5 WG participants all from different organizations indicated their = interest in implementing this draft (even if it was just for = experimentation). >>=20 >>=20 >> There are also 6 steps identified in RFC 7120 for early assignment, = but only four involve the chairs: >>=20 >> 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. >>=20 >> An in-person request was made at IETF 101 for the early code point = assignments. There was also an earlier on-list request. >>=20 >> 2. The WG chairs determine whether the conditions for early >> allocations described in Section 2 are met, particularly >> conditions (c) and (d). >>=20 >> The chairs agree that the four conditions have been met. >>=20 >> 3. The WG chairs gauge whether there is consensus within the WG = that >> early allocation is appropriate for the given document. >>=20 >> The sense of the room at IETF 101 was that yes early allocation is = appropriate, but this email is verifying that. >>=20 >> 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. >>=20 >> Once the chairs have determined WG consensus, we=E2=80=99ll pass it = to Ben. >>=20 >> spt >=20 From nobody Wed May 23 20:23: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 93D3612778E; Wed, 23 May 2018 20:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 ZfGYAI88YE3n; Wed, 23 May 2018 20:23:43 -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 1B5EB127077; Wed, 23 May 2018 20:23:42 -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=1527132223; x=1558668223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BujBebbwxPoD+nmHgQI3lLD8gX6xhybbsmuCJZr4tzY=; b=NesBSmAcxNE3Mhkx/7voNq8h02zzWcQ4GAdzWUcZQ23u733CVh8t5Qjr tbj2Tx11vy7YITvJ7epM9OFCR8q+KqZmPu42owMviZPCjZT8bzdAHajPq +D+8QOoWkqn2Kk6+veX7CV2PRNw24CMsSu4Hk6aQLJ2JQOu/e4gjEb/x6 HYjH6H57lFZtQIL4FaXhgqy0vhB9SqwCdleFkCl7Azky7fYKxnZC6LQvd zW61mFGOB2hDCWxyPtRIrOjfrc51zv2H8QpP1btLp58r4X1ZpK8318r8M Ctftfx0QhnRs7SBvq7SwAGeTVGkHEbpIewbZH5tMgvvffSlFAR0Ngq+CZ g==; X-IronPort-AV: E=Sophos;i="5.49,435,1520852400"; d="scan'208";a="12798249" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 May 2018 15:23:37 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 24 May 2018 15:23:37 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Thu, 24 May 2018 15:23:36 +1200 From: Peter Gutmann To: Sean Turner , TLS WG CC: "draft-ietf-tls-certificate-compression@ietf.org" Thread-Topic: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression) Thread-Index: AQHT8v3hbDsaDyO3kkabStuq6PVmD6Q+Nujl Date: Thu, 24 May 2018 03:23:36 +0000 Message-ID: <1527132197784.15190@cs.auckland.ac.nz> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> , <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> In-Reply-To: <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.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] early code points assigned (was Re: 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: Thu, 24 May 2018 03:23:46 -0000 Sean Turner writes:=0A= =0A= >IANA has assigned the following values:=0A= >=0A= >1) In the ExtensionType Values registry, the following entry was added:=0A= >=0A= >26 compress_certificate (TEMPORARY - registered 2018-05-23, expires 2= 019-05-23) [draft-ietf-tls-certificate-compression]=0A= =0A= That's going to cause clashes with implementations that use that value for= =0A= TLS-LTS, it would be better to use a value other than 26 that isn't already= in=0A= use.=0A= =0A= Peter.=0A= From nobody Thu May 24 08:07:32 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 844E512EADC; Thu, 24 May 2018 08:07:23 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152717444344.30150.12952824495066746485@ietfa.amsl.com> Date: Thu, 24 May 2018 08:07:23 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-05.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: Thu, 24 May 2018 15:07:30 -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 : IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-05.txt Pages : 19 Date : 2018-05-24 Abstract: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 24 08:27: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 6C5FE12EA9F for ; Thu, 24 May 2018 08:26: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=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 vwzE2lEwstRi for ; Thu, 24 May 2018 08:26:57 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA6F12EA96 for ; Thu, 24 May 2018 08:26:57 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q13-v6so2544256qtp.4 for ; Thu, 24 May 2018 08:26:57 -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=cXB4iHJhf05abf/ZnbUtymhDkwhndErqTPFbpyW7mzs=; b=FQpjQkXfck3fZM/QE3OrcxV11KG3jzNfcm7N3K/u6FJhBpTXDtP59rrb6XVu/Yw6BB 2AX0Br7Lrpz5rLOc6qwzEcPcEivlYtGEpuNTDjyvrQh6qi5A+lzkwwOzQtDwDPAXtLvC xOmbuXyeLWGhwbu+6kz0gMRzuOkaL5HxVcOD8= 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=cXB4iHJhf05abf/ZnbUtymhDkwhndErqTPFbpyW7mzs=; b=FmtMn9r5m01GialJytb7rnD19hEPgZIulz2JqzmBRolt7/vgmNPMDIwUuAVWMdG+tM +fm1OXs419FPG0iTXmAZyenZ3XW2dyvnTxGqTeSQNTnH3QAFBtoBKacCkPNPyDMb1je6 x66Y5+WCikm2JxFkT45Hj+n2aFKdvgnYcHCNir6c031UOVv5ASnLJqfaaCIRtMWla3Ey bxzgONz3aMZl5yiLQ/JUQfDLx6JLz6H5g0r0XNSGOs2nsf2YvRz4F9Vr7hvGYip5CEje xN6Fejt3AL8MSlm2Z5+9XiaK0Q1CZE3hHEp3NFwUbgSe5JxSlXnuIuoXdaQlye2hcKUO DioA== X-Gm-Message-State: ALKqPwelkTT2c+xEqijzKp+bXN1TGX1Oo8ptqUt7wZOURwo+R1y03R+u vFtWUoXx7495AJk4sSn4IS3pTTCjpfY= X-Google-Smtp-Source: AB8JxZrOXqAOwPN7lQtbG6r8asZC1Gw12I1HPxPdyNm2D+mzBUU+tVLcyXVabFjGjAoHWxw/g9x9Iw== X-Received: by 2002:ac8:70d5:: with SMTP id g21-v6mr7501345qtp.393.1527175616354; Thu, 24 May 2018 08:26:56 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id g16-v6sm8979749qkm.67.2018.05.24.08.26.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 08:26:55 -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, 24 May 2018 11:26:54 -0400 References: <152717444344.30150.12952824495066746485@ietfa.amsl.com> To: TLS WG , The IESG In-Reply-To: <152717444344.30150.12952824495066746485@ietfa.amsl.com> Message-Id: <8412111B-DD96-4193-9A86-EED994F83BF3@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-05.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, 24 May 2018 15:26:59 -0000 Ben, This version addresses IESG-related comments as well as the one = outstanding issue we had (whether to close or reserve and point). I = believe it is ready to move to =E2=80=9CApproved". spt > On May 24, 2018, at 11:07, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : IANA Registry Updates for Transport Layer = Security (TLS) and Datagram Transport Layer Security (DTLS) > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-05.txt > Pages : 19 > Date : 2018-05-24 >=20 > Abstract: > This document describes a number of changes to (D)TLS IANA = registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. >=20 > This document updates the following RFCs: 3749, 5077, 4680, 5246, > 5705, 5878, 6520, 7301. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 5 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 24 09:31: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 52EF212DB70; Thu, 24 May 2018 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iXcegsi3LPu; Thu, 24 May 2018 09:31:11 -0700 (PDT) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com [209.85.160.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3E4127419; Thu, 24 May 2018 09:31:11 -0700 (PDT) Received: by mail-pl0-f54.google.com with SMTP id c41-v6so1371258plj.10; Thu, 24 May 2018 09:31:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0gZpJdphWqe4wdpKR4P9yFcJZh9IH7qe+OrUGnb1bX8=; b=rbQ7MLKXtZTg8fKMU9HJKvejniv+X8NNDqwRAGTWoJXCMajDH0NuZ10VaDvKsUKE/v vEv8/KhFMYoniNottQybDcUamXTVjnTnq6DgQN+02JZZMrIP4h3YU0NzW/jR6wILljbz ymyHmR+2B3Hht4dTDlDrMMZQ78c/CqAttX4jqw9B8uHNF6T95waS4EfIzw6NY2Nqold8 /f07QffJpJ2/pR2kS/uV8sdMrp/n/xlKoBlak/8Etyl+MtgxmXLwkE1e1mQQBeBEKFxK E77sZy6024WUhTljrc7wICfK1oDEs7jl/KgJUT70kc6namFBgyXS3hBsb/fIlg9ZRHGU qr3A== X-Gm-Message-State: ALKqPwcuHBfNar4oEtJRFAXQ4WE7vJ+VXXDuhvspNawJt6y9Jitv/qTb S90yb9CBnlSyHfm/ELKqgDmdph/WlxIkjlII9CuJZw== X-Google-Smtp-Source: AB8JxZoHMGl8RK6e7zLCLuQIiQBRkxjAl+8sjPLk4VDi3v7Tafybi4KWPSERGM+gyPQjjc/R7851W45k3sZlJfQLPJs= X-Received: by 2002:a17:902:43:: with SMTP id 61-v6mr8258783pla.112.1527179470298; Thu, 24 May 2018 09:31:10 -0700 (PDT) MIME-Version: 1.0 References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> In-Reply-To: <1527132197784.15190@cs.auckland.ac.nz> From: Adam Langley Date: Thu, 24 May 2018 09:30:59 -0700 Message-ID: To: Peter Gutmann Cc: Sean Turner , tls@ietf.org, draft-ietf-tls-certificate-compression@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 16:31:12 -0000 On Wed, May 23, 2018 at 8:23 PM Peter Gutmann wrote: > That's going to cause clashes with implementations that use that value for > TLS-LTS, it would be better to use a value other than 26 that isn't already in > use. Obviously I'm not adverse to using the occasional, non-IANA code point. But they need to be picked randomly and outside the dense, IANA area. Otherwise, this is certain to happen in short order. I think quite a lot of clients are going to be advertising compression using this code point in the coming months. They should only do so when offering TLS 1.3, which presumably LTS clients would not, so maybe there's something you could use there. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu May 24 09:48: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 EBAF612EAB7; Thu, 24 May 2018 09:48: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 C4qzzvEep7DH; Thu, 24 May 2018 09:48:15 -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 26F8F12E741; Thu, 24 May 2018 09:48:15 -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 2DDB8401EF00; Thu, 24 May 2018 16:48:14 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 178F39C044; Thu, 24 May 2018 16:48:12 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Adam Langley , Peter Gutmann , draft-ietf-tls-certificate-compression@ietf.org Date: Thu, 24 May 2018 18:48:07 +0200 Message-ID: <2572145.F28MCbCr1J@pintsize.usersys.redhat.com> In-Reply-To: References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9987027.QOQAxqWPa3"; 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.5]); Thu, 24 May 2018 16:48:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 24 May 2018 16:48:14 +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] early code points assigned (was Re: 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: Thu, 24 May 2018 16:48:17 -0000 --nextPart9987027.QOQAxqWPa3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 24 May 2018 18:30:59 CEST Adam Langley wrote: > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann >=20 > wrote: > > That's going to cause clashes with implementations that use that value = for > > TLS-LTS, it would be better to use a value other than 26 that isn't > > already in > > use. >=20 > Obviously I'm not adverse to using the occasional, non-IANA code point. B= ut > they need to be picked randomly and outside the dense, IANA area. > Otherwise, this is certain to happen in short order. >=20 > I think quite a lot of clients are going to be advertising compression > using this code point in the coming months. They should only do so when > offering TLS 1.3, which presumably LTS clients would not, so maybe there's > something you could use there. speaking of TLS-LTS, would reigniting that discussion be good idea now, or= =20 should we wait for the TLS 1.3 to be officially published? =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 --nextPart9987027.QOQAxqWPa3 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+dkqjRuAHS9fUFAlsG7McACgkQkqjRuAHS 9fU3jg/7BPEDm/OtAcAoJsjqzQw+saFAHBeIDw4qvPbJ5quIk8mbR36qQ/Pqjncp ACYP/VW8ybKnpKIVabi5A12pW0GZ/g2VSxhtOcaHbtHDS86ulholDRlo0shqmxcW qkE8qYR/w7isLoepPktDhMxd2RVT4oGhEro7tifQxw+vd+2Fwf9wopmLX23vaXhA KLaToGtmPK6tpviy8/yZ07fmzYAP/9CeIXbliInUHp6sVwV0Yfuakni6Bk79l34b aovCuhYy3d+cQ7cyCjPMTPfjPvXdaEk2D25WMpDmNq8bf4+fUMpf/ZRXXOejjyyF NzXjra9LnKrddv7jidPMziW232bXTifx+ZIgUlOp91JPntJWUn/DgWCAxAs2q/HP Wl0ADQdafihnS0pBs3tSGjByYrysbGTm8hnkcm96ZQd0K6N/zsuVyuakEFdb6Jl2 qwLQIoxsYqtieD7qfebu3MTiwd1Bw4EFYGz4hmpwxrIK13ajHg96fR76qsXrZV4h taW/ER83BXzJAEFQBAuksHoqPrBujWtwtlnSu34ccbJzDYI3YJcsuEKXFHdIJcIJ IkxdFSZIx3EBsvjbXEqEMySUJD0qpuaonohrKqLZRLB8Oyvx8Va+Lh/lEZSAu2cn GDPKOsaZtMaBIYosjuvBFvmNvMUJyI4V1CZpzi7DBoRCUqt/jxY= =AE3Q -----END PGP SIGNATURE----- --nextPart9987027.QOQAxqWPa3-- From nobody Thu May 24 09:51: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 DB6FE12EA8C for ; Thu, 24 May 2018 09:51:47 -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 PseT989SbRFf for ; Thu, 24 May 2018 09:51: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 CE8CA12E741 for ; Thu, 24 May 2018 09:51:45 -0700 (PDT) Received: from [10.89.198.218] (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 1DAAF7A3309 for ; Thu, 24 May 2018 16:51: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: Date: Thu, 24 May 2018 12:51:08 -0400 Content-Transfer-Encoding: 7bit Reply-To: TLS WG Message-Id: <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 16:51:48 -0000 > On May 24, 2018, at 12:30 PM, Adam Langley wrote: > > I think quite a lot of clients are going to be advertising compression > using this code point in the coming months. They should only do so when > offering TLS 1.3, which presumably LTS clients would not, so maybe there's > something you could use there. It might still be prudent to get the new code point re-assigned. I can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS preferred when using TLS 1.2. -- Viktor. From nobody Thu May 24 10:42: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 B72C712EACE for ; Thu, 24 May 2018 10:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, 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 Q_Kf5BhUeejF for ; Thu, 24 May 2018 10:42:20 -0700 (PDT) Received: from mail-pl0-f48.google.com (mail-pl0-f48.google.com [209.85.160.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C8B12EAD6 for ; Thu, 24 May 2018 10:42:20 -0700 (PDT) Received: by mail-pl0-f48.google.com with SMTP id bi12-v6so1480230plb.12 for ; Thu, 24 May 2018 10:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0KHz+GCWLP3BE5o/OVOMpX7j9BeJu+pckUBD1Y0DH+8=; b=bx62ciCY1kOwphdBcZsPtleK1FWh4sQbvZdbkzx+Ckz7qs9BeaH9FzujXRggwjt+KJ 3JqDjnPz39/0OavR4UFoS8pVsBYhB2oxt5lanvetGP+pTZY1+L7GQr4ILC+ewQ2BmweW Slrb2eMQtBjk9SaFWQdOdJxoRXMw3rjnmQ2wl569LEb5svpFOEOQGoM3ODm7LdOXRWsm ycHLgEQJNxKhh+A9+S/2qa6livdD8K/MiOeqYcVxOUXqbg9cMBcKG9+eQKkHlMoEqzVa hoxQRJhyOZEvoRGVVmv9N68BmEQRYFg9fA0zUHBZ7wX4FCKSSqTmWnV46eKFk4EGeUgT 3Cog== X-Gm-Message-State: ALKqPwdThNA7YMv49tBop+WsrigzEMIuL1s5qdM9lpj5e97+C6gjRyRU iMPSrn+5lHkThlKiZqqJYZiND1fTOBM1f8xGI9bs47kU X-Google-Smtp-Source: AB8JxZpZqo/yiAjEu5wBoH+0QQk+z+m8AXvLdzrrDqz5ZaVGFjjaM8xhDNeVcpQMoc8grjBWEwxbai3NPlqXL2aaW88= X-Received: by 2002:a17:902:43:: with SMTP id 61-v6mr8506809pla.112.1527183739706; Thu, 24 May 2018 10:42:19 -0700 (PDT) MIME-Version: 1.0 References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> In-Reply-To: <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> From: Adam Langley Date: Thu, 24 May 2018 10:42:07 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 17:42:23 -0000 On Thu, May 24, 2018 at 9:52 AM Viktor Dukhovni wrote: > It might still be prudent to get the new code point re-assigned. I > can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS > preferred when using TLS 1.2. It's also been pointed out that 26 collides with the value in https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by Sean :) So we have a triple collision on 26, albeit with one candidate being much more official. Sean: do you want to kick quic_transport_parameters off 26 then? Move it to a high, random value until assigned? -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu May 24 12:46: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 5833B12EB12; Thu, 24 May 2018 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 4lSAU0Rzf9aM; Thu, 24 May 2018 12:46:30 -0700 (PDT) Received: from homiemail-a73.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 D375412EB11; Thu, 24 May 2018 12:46:30 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 6DD1458000931; Thu, 24 May 2018 12:46: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=nO+M2XB4VpVJ0r tDTkEq7YpdLuY=; b=UIM09jOOi21b8THwegfBwFud3R2KCvNzBbzIIrMC9e05pd OwrgHzKZ4vV4tuL34EGCry4w6HPe51C4FvMJkEcYM10nncsoqw2AyCZjdll+7bYF gAtqFDJGT6JKN7sTo4+bq6Cjn09XwoMkfhQmCgeUnfDfr0rezXAirZxL8Dw4U= 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-a73.g.dreamhost.com (Postfix) with ESMTPSA id E804958000934; Thu, 24 May 2018 12:46:27 -0700 (PDT) Date: Thu, 24 May 2018 14:46:26 -0500 From: Nico Williams To: Adam Langley Cc: Peter Gutmann , draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org Message-ID: <20180524194624.GC14446@localhost> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@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] early code points assigned (was Re: 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: Thu, 24 May 2018 19:46:32 -0000 On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote: > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann > wrote: > > That's going to cause clashes with implementations that use that value for > > TLS-LTS, it would be better to use a value other than 26 that isn't > already in > > use. > > Obviously I'm not adverse to using the occasional, non-IANA code point. But > they need to be picked randomly and outside the dense, IANA area. > Otherwise, this is certain to happen in short order. Why can't we make it so IANA does early codepoint assignment? Nico -- From nobody Thu May 24 12:54: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 F3BF612EB11; Thu, 24 May 2018 12:54:50 -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 V9Pe9RnoTcmC; Thu, 24 May 2018 12:54: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 F19911275F4; Thu, 24 May 2018 12:54: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 w4OJrInU027325; Thu, 24 May 2018 20:54:47 +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=0M32ngXn4toQQKtiRjYna/8QyjlfejehZtsXDwN9E0o=; b=aqwHnnzPL4ijQmQylf5VRov+5G8qxFxfzlnNw0Ym1O9zfQxYFVvRqsmAXTcew2rxrGkw baVYMO3OBagLp2G0XkpaOaKUmNl9OHgLbWNwLDP5R27Oikvypp2NEAaM490Sq+7bfiFY bJmFrGKqgueIuJEdb6xMyVvkNx+OrzWbl2XtLkH4UFXsBUuxbD/+L9RYQVWu4p5meAhs ovU3MWEOpSqEjV0oie9cLPJvNZQxDrfxewmwbQxa7p3MZK3nSN15I2UtzazIVx3eaHzF HF2S/tksYoRw90DiulGo2R1wM0WivwMo5Bv2coTihEabWHY38hgqWmK+Ria+cVwjvVVz jA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2j5g0ebp47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 May 2018 20:54: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 w4OJqAVQ026391; Thu, 24 May 2018 15:54:46 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j2f8utf16-1; Thu, 24 May 2018 15:54:45 -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 B90D01FCD8; Thu, 24 May 2018 19:54:45 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fLwJw-0005l1-V9; Thu, 24 May 2018 14:54:45 -0500 Date: Thu, 24 May 2018 14:54:44 -0500 From: Benjamin Kaduk To: Nico Williams Cc: draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org Message-ID: <20180524195444.GS13834@akamai.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <20180524194624.GC14446@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180524194624.GC14446@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_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-1805240225 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_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=986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805240225 Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 19:54:51 -0000 On Thu, May 24, 2018 at 02:46:26PM -0500, Nico Williams wrote: > On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote: > > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann > > wrote: > > > That's going to cause clashes with implementations that use that value for > > > TLS-LTS, it would be better to use a value other than 26 that isn't > > already in > > > use. > > > > Obviously I'm not adverse to using the occasional, non-IANA code point. But > > they need to be picked randomly and outside the dense, IANA area. > > Otherwise, this is certain to happen in short order. > > Why can't we make it so IANA does early codepoint assignment? They already do, and we've got documents approved by the IESG that make the registration policy just "specification required" (as opposed to "IETF review"). While Peter did mention the value 26 on the list two years ago, there hasn't exactly been a lot of visible action with TLS-LTS in the intervening period... -Ben From nobody Thu May 24 13:15: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 775CD12EB2C for ; Thu, 24 May 2018 13:15:36 -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 zOBM9e_RehOw for ; Thu, 24 May 2018 13:15:33 -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 64CB512EB27 for ; Thu, 24 May 2018 13:15:33 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id g7-v6so3470628otj.11 for ; Thu, 24 May 2018 13:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z9ebVeKGLsB2wfr1PoQrTh1zo4tZI7tEci8M7Gp268A=; b=C4g3OxtwIKkCm28Ln8Lu+77y2U5SokcyPJlYg5H2G2beELb9J443KrbT+BO0mUx8La f7H9N7WI2E96gJmx5APzcV0gtLKwbc0fJkWgY9YnQKqYX39uA6F0xniXMhvbNI/E8C0B 5RMzFwSP+wummlchvcbieb21zavJjLdyry9ojjH3EbCCbiyi//yV6qUfRU4eA+vYISGv aL6iN7i97DaPrYQSsQBKnv+QZFNc9MqWwIP+1235AN62EneXMw6nCws4QrX0vU380nea 54IUOsijKIekQcN8o94NU1Rs+tIrJ/Bk4RirYEyDXfBrQ7K82GRx/cUn8gCWI0/08dqX C02w== 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=z9ebVeKGLsB2wfr1PoQrTh1zo4tZI7tEci8M7Gp268A=; b=M1ViQZFi8BFpLXxtr9jvk8OFbEp0uFgXzeMjEBE4tZoDNfELHAlKJmOJAAtN/9tAky qNao2nSy3qiPvgpaH6axEUZYUx5/30gZtbk2E/eWcfGMUyey8ON4n3v+20ceff+Sp3Ch lcFfFjm0PQNdQ14Fpw126wqRSFQh4+BWq8PMzCMM5ZAsrf7+i4lKuze7RR93FUGP99QD ogP66RyRvLjGn4Oyhhbj8+dVTVeg6vx5vM/fD6nV8mAsbHgOX1WehfzxN2mmzrPZtgEB xR4GMXBBZ3R1rHvjCgwZRjbqjn9F3AnF7JWgdhqmR9EGTzSznJO7QUQBUBQQeehAmzqT awJw== X-Gm-Message-State: ALKqPwc7VQ4JnsXyYdiI9/a1FBIkJ/r/4DTMI/L69Y4Z1asYqNxKDMC6 yXy1+zsSAhgRd3ObzRicJPfKBOPGeAXx/HGsXl0qtAU2 X-Google-Smtp-Source: AB8JxZpJElA1XAKmWI0y5lqlFr0AvHtCC6Imd/b1Xpnnex8WoHorYpPAkv2fWsu6jUVlsHVhOSxxVa+CFzN2g8icC1E= X-Received: by 2002:a9d:719a:: with SMTP id o26-v6mr6123977otj.44.1527192932806; Thu, 24 May 2018 13:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 24 May 2018 13:14:52 -0700 (PDT) In-Reply-To: References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> From: Eric Rescorla Date: Thu, 24 May 2018 13:14:52 -0700 Message-ID: To: Adam Langley Cc: "" Content-Type: multipart/alternative; boundary="000000000000438632056cf9509c" Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 20:15:37 -0000 --000000000000438632056cf9509c Content-Type: text/plain; charset="UTF-8" On Thu, May 24, 2018 at 10:42 AM, Adam Langley wrote: > On Thu, May 24, 2018 at 9:52 AM Viktor Dukhovni > wrote: > > It might still be prudent to get the new code point re-assigned. I > > can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS > > preferred when using TLS 1.2. > > It's also been pointed out that 26 collides with the value in > https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored > by > Sean :) > > So we have a triple collision on 26, albeit with one candidate being much > more official. > > Sean: do you want to kick quic_transport_parameters off 26 then? Move it to > a high, random value until assigned? > I don't think it's a problem if QUIC moves. Let's just do a fast early code point assignment for that..... -Ekr > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000438632056cf9509c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 24, 2018 at 10:42 AM, Adam Langley <agl@imperialviole= t.org> wrote:
On Thu, May 2= 4, 2018 at 9:52 AM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:
> It might still be prudent to get the new code point r= e-assigned.=C2=A0 I
> can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS
> preferred when using TLS 1.2.

It's also been pointed out that 26 collides with the value in https://tools.ietf.org/html/draft= -ietf-quic-tls-12#section-9.2, authored by
Sean :)

So we have a triple collision on 26, albeit with one candidate being much more official.

Sean: do you want to kick quic_transport_parameters off 26 then? Move it to=
a high, random value until assigned?

I = don't think it's a problem if QUIC moves. Let's just do a fast = early code point assignment for that.....

-Ekr


--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org

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

--000000000000438632056cf9509c-- From nobody Thu May 24 16:45: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 7BDB012D80F for ; Thu, 24 May 2018 16:45:56 -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 XDBBOxqfUtxU for ; Thu, 24 May 2018 16:45:55 -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 CF92C1275FD for ; Thu, 24 May 2018 16:45:54 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id n1-v6so4042382otf.7 for ; Thu, 24 May 2018 16:45:54 -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=eGnTVET2fbAFM+LaM3EtkVLlG9aQXD0CpwemJpMpQgY=; b=ZMCVgRbGN/2XefM7IO+QSq1r6NCZUywJ/fckpoHSETvK7xUF1Nol07NFO3aM1PXCLA Fu/VbyJ2+frK6dLnVf9XvSgOKoOAFOhV0g/f1j+yGXM+lLuvCE9CEAC9Vu20glTskjVA DtSfusaoZkrQMQE/exurqFGx7z9SONmyjLnNFJ8FZ6sEAnDU5RDrlLEuvdcrpLV4pQc5 xknLaUQ+CucP/ovC98Wnk+kcXWpeKun/bQUi06tgXBvkDJYuEm5CYOPD644dsjo8+j5q ojgBoqv3ukSjpg3PX7NOFj6sth5B1B/XqBjpXOwKYv6avrBdOk5hrmdgjAjpqZosg7ct y2Hg== 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=eGnTVET2fbAFM+LaM3EtkVLlG9aQXD0CpwemJpMpQgY=; b=jdSzE9HBRibixwCwfw1dMiMi3WhbCUb7RZuHoWcPx8v56B9tc9bGv4Xweijl8Clr1G IUMtTjClL+4Ub96qPkAITeKInFdV71y4Nwap0RxCblNlMONm0JpeOA8cHjH6HcP+7m4E /VtAmmuPzrClm4zI4MBf9onme1nxSVk+WRGEcrrgAp/v+Uhv6G6i1j55UG/UUQUwXzs+ XMHb1dliautldswHPz+w5nDnBkx4gjpITrSLV9cmlxDGtanIqt3cAtFhSR4QNCmQg0uY t//WYBHgsXbDxIwIgjZvKx5+PAm/uX9TcppE27F/ZnXgWmUVf9sgq7NZmDEMvrqtmdQR lU7g== X-Gm-Message-State: ALKqPweI5eIdvAQ959IkwxkLmieiXW05TZJOHdm1Jgo9zFF3eD8umcvj kjRSB52+eISx0Xhus9zVJ5UlDdnT0K7hRNjUNHg= X-Google-Smtp-Source: ADUXVKKKDa7+4RWWQl+U+j8IEUuNsXaQhtqq4lSkkexmGJHuAlS61BXrTDJIbSWWLFWohVG6jXdhgJXJ/FxswwYvFz0= X-Received: by 2002:a9d:34f1:: with SMTP id t46-v6mr48269otd.396.1527205554158; Thu, 24 May 2018 16:45:54 -0700 (PDT) MIME-Version: 1.0 References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> In-Reply-To: From: Martin Thomson Date: Fri, 25 May 2018 09:45:45 +1000 Message-ID: To: Eric Rescorla Cc: Adam Langley , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Thu, 24 May 2018 23:45:57 -0000 On Fri, May 25, 2018 at 6:16 AM Eric Rescorla wrote: >> Sean: do you want to kick quic_transport_parameters off 26 then? Move it to >> a high, random value until assigned? > I don't think it's a problem if QUIC moves. Let's just do a fast early code point assignment for that..... Yeah, on the scale of things that are about to change in QUIC, this is of marginal concern. From nobody Thu May 24 17:36: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 6836F12EA8E; Thu, 24 May 2018 17:36: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 PnHj1zIzI02m; Thu, 24 May 2018 17:36:11 -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 8B4CE12783A; Thu, 24 May 2018 17:36:09 -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=1527208570; x=1558744570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p1rrthVaf++mTxQmew4BuUOzgS4W88gqey4TTGg5Eo4=; b=GBlwEOWOj9EMg1AMsjgbHVnXGX5lpg/KoOdAhZ4NZ+KO2pLH+HdryNnI qUu8s1hq4DoDEk+vGG00iCBjaY13nfkMiz+SIjBXcuwME7lk+g6bDqkTv 1zLYq3B+ovuxfmJbT9wyPTMDy2rSYm5yLdEt3YxiOgESmjwGtrbnod3+A Dtwmi6BVBdFQv+ndDvAdBtBDlw/EAbkVOEusjwXqJKIwkhEG82zsUo6gx Ye/JyTk/comJq7XljAw0MBru/qg3ld0QPaLdZ6/LrJqgCJEwdf3ofGgML SnUjHXzlsxWJrIv0SyBf925u81pkb9Y0BSaNnLCzcboGU7nPo3bne4Djq Q==; X-IronPort-AV: E=Sophos;i="5.49,438,1520852400"; d="scan'208";a="12954916" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 May 2018 12:35:51 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 25 May 2018 12:35:51 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Fri, 25 May 2018 12:35:50 +1200 From: Peter Gutmann To: Adam Langley CC: Sean Turner , "tls@ietf.org" , "draft-ietf-tls-certificate-compression@ietf.org" Thread-Topic: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression) Thread-Index: AQHT8v3hbDsaDyO3kkabStuq6PVmD6Q+NujlgAATI4CAAVBifA== Date: Fri, 25 May 2018 00:35:50 +0000 Message-ID: <1527208530671.25744@cs.auckland.ac.nz> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 00:36:14 -0000 Adam Langley writes:=0A= =0A= >Obviously I'm not adverse to using the occasional, non-IANA code point. Bu= t=0A= >they need to be picked randomly and outside the dense, IANA area. Otherwis= e,=0A= >this is certain to happen in short order.=0A= =0A= The story behind this one was that I was asked to defer publication of -LTS= =0A= until the IANA registry draft got published (and I'm still waiting). In th= e=0A= meantime implementers needed to use some value for deployments, and 26 was = the=0A= next unused value so that got used under the assumption that if everything= =0A= else was also waiting for the registry draft to be published it wouldn't ge= t=0A= grabbed away suddenly. It's now been in use for about two years so there i= s=0A= quite a bit of precedent for its use by LTS.=0A= =0A= Peter.=0A= From nobody Thu May 24 17:38: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 6CF20128D2E; Thu, 24 May 2018 17:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 zjWxyEKEW2cK; Thu, 24 May 2018 17:38:55 -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 6AB5412783A; Thu, 24 May 2018 17:38:54 -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=1527208734; x=1558744734; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CmzA1IKMcgI9g2JhbuaS7lIS3XMpko8FHvfj8GTt+Pg=; b=EyrvRqUz1uxdCB2NJRbNQfgoGaXJ3MID5iMQtHOjqx1h1lBuR1NoU3nC K+tB+2QktGjo6KSJO8N9SVze2r6BZ/+NFEmgazEyGKxsBivrN1rjSTzss JsjYntqZcPaQAEWBmu/43pioLC2Xeyw8q1AFdGTNdvOtZWlV6iqt98vbj E+mn0dmYAg5upgHghc92muTqjSG6L20YwoqsEvpFwA+b4VUnoTDtyA/2S QvRkO329TQXJ+EHAmlybz8WC8V7w543+wVSanEBSDIrxRScgoMg/AyBKu +VOpzbpbcY1TUrrZvOJymbXK0gdJNkzoEruNv0G7tipn860+IVaWkVJ4X g==; X-IronPort-AV: E=Sophos;i="5.49,438,1520852400"; d="scan'208";a="12955387" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 May 2018 12:38:52 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 25 May 2018 12:38:52 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Fri, 25 May 2018 12:38:51 +1200 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" CC: Adam Langley , "draft-ietf-tls-certificate-compression@ietf.org" Thread-Topic: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression) Thread-Index: AQHT8v3hbDsaDyO3kkabStuq6PVmD6Q+NujlgAATI4CAAATKgIABS+/x Date: Fri, 25 May 2018 00:38:51 +0000 Message-ID: <1527208711797.85825@cs.auckland.ac.nz> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> , <2572145.F28MCbCr1J@pintsize.usersys.redhat.com> In-Reply-To: <2572145.F28MCbCr1J@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-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] early code points assigned (was Re: 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: Fri, 25 May 2018 00:38:57 -0000 Hubert Kario writes:=0A= =0A= >speaking of TLS-LTS, would reigniting that discussion be good idea now, or= =0A= >should we wait for the TLS 1.3 to be officially published?=0A= =0A= In the past I've been asked to (1) wait until 1.3 is published and (2) wait= =0A= till the registry update draft is published. Since both have dragged on an= d=0A= on, LTS has been sitting there forever, a bit like the SCEP draft, with=0A= deployments based on a perpetual draft. I'd be quite happy to get it final= ly=0A= published and resolve the status. SCEP took eighteen years, I don't quite= =0A= want to go to that level...=0A= =0A= Peter.=0A= From nobody Thu May 24 17: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 6877B128D2E for ; Thu, 24 May 2018 17:40:30 -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 rb16BQVL7YoL for ; Thu, 24 May 2018 17: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 97C1512783A for ; Thu, 24 May 2018 17:40:28 -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 D50917A3309 for ; Fri, 25 May 2018 00:40:27 +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: <1527208530671.25744@cs.auckland.ac.nz> Date: Thu, 24 May 2018 20:40:27 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <373C73B8-F9F5-423C-82AA-D0BC372815A5@dukhovni.org> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <1527208530671.25744@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 00:40:31 -0000 > On May 24, 2018, at 8:35 PM, Peter Gutmann = wrote: >=20 > The story behind this one was that I was asked to defer publication of = -LTS > until the IANA registry draft got published (and I'm still waiting). = In the > meantime implementers needed to use some value for deployments, and 26 = was the > next unused value so that got used under the assumption that if = everything > else was also waiting for the registry draft to be published it = wouldn't get > grabbed away suddenly. It's now been in use for about two years so = there is > quite a bit of precedent for its use by LTS. This is perhaps sufficient reason to change the compression assignment. It sure looks like Peter did the right thing in good faith, and at this time, the LTS use should I think be grandfathered in. Are there (m)any implementations shipped that already have 26 for compression? --=20 Viktor. From nobody Thu May 24 17: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 0C2D212D864 for ; Thu, 24 May 2018 17:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOnS6NkayCNZ for ; Thu, 24 May 2018 17:54:52 -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 80E0F128D2E for ; Thu, 24 May 2018 17:54:52 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id h8-v6so4205238otb.2 for ; Thu, 24 May 2018 17:54:52 -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:content-transfer-encoding; bh=i8oLr1R/ynxH6egOpaN6m5eVIrYprtZjxH2HGjmK6I4=; b=SI8s2zm5uX/JsSFtlbyGI8YCNLWFWKE2p0EIsamt/sIXHmzyvGKhgmhwckw75Gr3Jf scTWh3qVFkWlxBF3rcL6N2d2Ih/GQILU8lnTQT6oqiPa5qi5oiD//uwlS2n92CeflWVu /L2JAzgMRTYIvKJYvxVkBtFeFVBAij/gNeKrSPh5gLi3zh4wC3QXE0RZpkwlfbCNb+00 8o7ciru9x97DOaKDAr1wCaVuvKrkn1FgSa51TIdzYPPlOx2Ue3ocjaZZkx3qFNuakg+b jeUZuqA8pYv8M88+UgpWJ3JqtaZba+SRtl8R+klWzi8zRW+IkV0mlBuWrssiF3NjF88y 6/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i8oLr1R/ynxH6egOpaN6m5eVIrYprtZjxH2HGjmK6I4=; b=GQPZ/Bmh5x1gedqA+t9LOO1gCvL+UznZGsiF06zL5v6c7HaoJmJz3xHaEUR6KUN26F sw+sgFF6mw1q0DANMhbT7T+R9oygCUyYlqkDA8xxlzgej5IAmwmk95mRNo4+4f7/VAAH 28x+eDKMqpE6x9JjNxSjIKvnxsBFlW6z9kWBgyZZd23ICpoQ3s26wopGoa7sT9lYGkhb BAA1UOfLvSB6/gWKMaJzXOkjd0iF7rrCvp7yolLlJEFGkB6W7kYjQfV6aZss7uy7BxDn BCY8OLlPIyVQ3UCiUmoJGGTR03j2CryeueUWtTR71/yBu0HlulX7Xgwe6FMnlMVUWmYU IiDQ== X-Gm-Message-State: ALKqPweT01xbv1y8HNX5Z8QF7V4xQ32xlN7E3GEn7RottT7sP/wyoGiS wtrC1Q1jIawUFOIfmRabuvV/yy2BpLUC+W4MQmM= X-Google-Smtp-Source: ADUXVKKY2ijShWJr1aEnFKwRN8pkfUiyag2Tl1vRJDqgEVfNUpZllyOvyLw4JZSiyKB3UTyU6q3XLWHliZpWEgjcZGQ= X-Received: by 2002:a9d:3ea5:: with SMTP id b34-v6mr152037otc.283.1527209691793; Thu, 24 May 2018 17:54:51 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Martin Thomson Date: Fri, 25 May 2018 10:54:33 +1000 Message-ID: To: Nick Sullivan Cc: Sean Turner , "" , Mike Bishop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 25 May 2018 00:54:55 -0000 Mike just inadvertently (?) discovered a problem with exported authenticators. TLS post handshake authentication provides an authenticated refusal when a certificate can't be found. It turns out that the current design of the HTTP/2 CERTIFICATE frame might need to rely on the same capability here. The current draft doesn't really say anything about what happens. https://github.com/tlswg/tls-exported-authenticator/issues/25 On Sat, May 12, 2018 at 9:59 AM Nick Sullivan wrote: > Thanks all for the comments on the draft. Let me try to summarize the comments and propose next steps. > Tim Hollebeek had a comment about 0 as the separator. I generally don=E2= =80=99t think this is a big issue, and prefer 0 because it is a natural way to terminate a string. If anyone strongly disagrees, please reply to the list. > Roelof duToit raised a question about middlebox interoperability, specifically that the exporters will not match if the TLS connection is not end-to-end. There was a subsequent discussion about where to signal this property. Martin Thomson suggested a signaling mechanism at the application layer (https://github.com/httpwg/http-extensions/issues/617) and Eric Rescorla suggested that the fact that this could cause CertificateVerify failures should be called out in the document. I'll put a PR together to add some helpful text around debugging CertificateVerify failures to address Eric's suggestion. > Ben Kaduk had three points: > - The certificate_request_context is prone to collisions with post-handshake authentication and there are different spaces for the server and client context values. He suggested some text in Section 3 and maybe more explanation in Section 5.2 as well. I=E2=80=99ll put together a PR for= this. > - Section 4.1 talks of the length of the exporter value in terms of the length of the > TLS PRF hash, adding that cipher suites not using TLS PRF have to define a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2=80= =99ll put together a PR to clarify the text around this clarifying that for TLS 1.3 cipher suites, the HDKF hash is what is meant. > - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not incor= porated into the draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorp= orate this extension. > I'll have the proposed changes for the above comments ready next week. > There were also some uncontroversial suggestions that I propose merging: > https://github.com/tlswg/tls-exported-authenticator/pull/21 > https://github.com/tlswg/tls-exported-authenticator/pull/22 > https://github.com/tlswg/tls-exported-authenticator/pull/23 > https://github.com/tlswg/tls-exported-authenticator/pull/24 > Nick > On Thu, May 3, 2018 at 1:16 PM Nick Sullivan wrote: >> Does anyone have any comments about the draft, criticisms, or votes of support? >> Nick >> On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: >>> > On Apr 21, 2018, at 10:25, Sean Turner wrote: >>> > >>> > >>> >> On Apr 19, 2018, at 16:32, Sean Turner wrote: >>> >> >>> >> 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. >>> > >>> > =E2=80=A6 4 May 2018 ... >>> Just a reminder the WGLC ends tomorrow. >>> 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 From nobody Thu May 24 18:06: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 0D15612D7F1 for ; Thu, 24 May 2018 18:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 sftFKOCjbd_d for ; Thu, 24 May 2018 18:06:24 -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 1878B1273B1 for ; Thu, 24 May 2018 18:06:23 -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=1527210384; x=1558746384; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8TQRUbLcbBRfRmkhSe96UtD1Q0vYCA+NqumbyEwTrv0=; b=FWN4wgOQDWzlbcwaB95lyYCzt7YM3Z+mfPxhT5DYUmS46orVjCqEekvd HUAg5HJFvdbWPSmVNsvoZ9cJgedJ5hhFDEdOtqb/XvZuta17b4zvTJL1W YhpH5b7GAL4gfeAyXTxg6PsKtzbkU4od9DC3vRfEN33TFltzQhltlrRb8 NX8e/qCVOx4XdDrVBuYfBCc3o/QDkDxPCw+679eCTWngcaw9ehKz+rh+A HhUnzeWvxdbdtxqU3+2YJUJiG8E8DhCiqdpj9HSzMLEFXQMzSdf6TstOl ay0x5OmEx++I8dTOhmnHgQcYCPf8sxQFxm+0FEMdDmdWSR8TYicjQzOXU A==; X-IronPort-AV: E=Sophos;i="5.49,438,1520852400"; d="scan'208";a="12960279" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 May 2018 13:06:19 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 25 May 2018 13:06:19 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::9f5:baf3:43e7:a6e6%14]) with mapi id 15.00.1263.000; Fri, 25 May 2018 13:06:19 +1200 From: Peter Gutmann To: Adam Langley , "tls@ietf.org" Thread-Topic: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression) Thread-Index: AQHT8v3hbDsaDyO3kkabStuq6PVmD6Q+NujlgAATI4CAAAWhAIAADj+AgAFFNmg= Date: Fri, 25 May 2018 01:06:18 +0000 Message-ID: <1527210357810.95497@cs.auckland.ac.nz> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 01:06:26 -0000 Adam Langley writes:=0A= =0A= >It's also been pointed out that 26 collides with the value in=0A= >https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored b= y=0A= >Sean :)=0A= =0A= I think that registry draft really needs to get published... anyone else on= =0A= 26?=0A= =0A= Peter.=0A= From nobody Thu May 24 19:10: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 45AF512D777 for ; Thu, 24 May 2018 19:10:46 -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 YjWnKWPvOGn0 for ; Thu, 24 May 2018 19:10:44 -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 9D5DE1277BB for ; Thu, 24 May 2018 19:10:44 -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 w4P276EX003582; Fri, 25 May 2018 03:10:40 +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=fdPVSoOCMvd4xaU51QqBKHaBEPF85+AaBTaCTjxG06E=; b=nZnaZSRl+xpJTAyHLXZLa7eKjCnVRztQ2a8So/o9KJ8PsR6KnQQ40WOVXT4MrrE+UvSd xmdQLYSyG7aYCpVAbY78ISZA8HYeVu1mIG5a8+mImWzQFAD4M0XV+klgZpR/JTGv091M KxCao/YiKojpRqNSYgTvF7Cr8UjV/BbybgI8Lrhy0B0YLqzGIPg7xxSwugUG0jWRtHMi WI3bNpBL/nM/GhkyzchXiJVaPzKDT6rOuuexJFmXrtqjXc+CDn/6EYrq+1NK0cNvGLUk PQidhR+IyO1Mp4OJqzsgQIoeasIMYmcGnLUZ4XqqJmSLLV6M6BIkt3Uxu4zr1NusaTAc hg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2j5hd84nk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 May 2018 03:10:40 +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 w4P26AZX027658; Thu, 24 May 2018 22:10:39 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j2f8w0p3v-1; Thu, 24 May 2018 22:10:39 -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 6ADE6815D4; Fri, 25 May 2018 02:10:39 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fM2Bi-00072n-JJ; Thu, 24 May 2018 21:10:38 -0500 Date: Thu, 24 May 2018 21:10:38 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: "tls@ietf.org" Message-ID: <20180525021038.GA13834@akamai.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> <1527210357810.95497@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1527210357810.95497@cs.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_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=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805250024 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=843 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805250024 Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 02:10:46 -0000 On Fri, May 25, 2018 at 01:06:18AM +0000, Peter Gutmann wrote: > Adam Langley writes: > > >It's also been pointed out that 26 collides with the value in > >https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by > >Sean :) > > I think that registry draft really needs to get published... anyone else on > 26? (The authors just today published a new rev of the draft that is believed to have addressed all IESG comments and be ready for approval.) -Ben (with AD hat) From nobody Fri May 25 04:03: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 04599126C89; Fri, 25 May 2018 04:03:51 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6odSO4wtzIN; Fri, 25 May 2018 04:03:49 -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 05228124BAC; Fri, 25 May 2018 04:03:49 -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 26DFF407048B; Fri, 25 May 2018 11:03:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3136F2026DEF; Fri, 25 May 2018 11:03:46 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Benjamin Kaduk , Nico Williams , draft-ietf-tls-certificate-compression@ietf.org Date: Fri, 25 May 2018 13:03:45 +0200 Message-ID: <2461040.3k7Vz6cXRM@pintsize.usersys.redhat.com> In-Reply-To: <20180524195444.GS13834@akamai.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <20180524194624.GC14446@localhost> <20180524195444.GS13834@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2568154.s2QKoN3iYW"; micalg="pgp-sha512"; protocol="application/pgp-signature" 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.7]); Fri, 25 May 2018 11:03:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 25 May 2018 11:03:48 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 11:03:51 -0000 --nextPart2568154.s2QKoN3iYW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 24 May 2018 21:54:44 CEST Benjamin Kaduk wrote: > On Thu, May 24, 2018 at 02:46:26PM -0500, Nico Williams wrote: > > On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote: > > > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann > > > > > >=20 > > > wrote: > > > > That's going to cause clashes with implementations that use that va= lue > > > > for > > > > TLS-LTS, it would be better to use a value other than 26 that isn't > > >=20 > > > already in > > >=20 > > > > use. > > >=20 > > > Obviously I'm not adverse to using the occasional, non-IANA code poin= t. > > > But > > > they need to be picked randomly and outside the dense, IANA area. > > > Otherwise, this is certain to happen in short order. > >=20 > > Why can't we make it so IANA does early codepoint assignment? >=20 > They already do, and we've got documents approved by the IESG that make t= he > registration policy just "specification required" (as opposed to "IETF > review"). >=20 > While Peter did mention the value 26 on the list two years ago, there has= n't > exactly been a lot of visible action with TLS-LTS in the intervening > period... because the chair(s) position was that it would be detracting from TLS 1.3= =20 work, not because the problem went away =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 --nextPart2568154.s2QKoN3iYW 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+dkqjRuAHS9fUFAlsH7ZEACgkQkqjRuAHS 9fXZmg/+PArT0FnWaKV7xWUVeUlLn87YeUYR0iabxV5uf56k0h4xbcjEvFXTsEaF GaFhscESLdzOzBa17bVyulYoVXgdI+fB3gQtKBWH9VxAUIvCHduph0WWsapSD/3Z Pk0ZL79Kr5CfSy1UOD70PvAZyO1DbOvebz7/wQJZr38sBXNu6bm11VmTu5qt+FMC QXX9Kq7uiAkTxFlCujwo3vkKblqXc3c5xqYdXfYO5LOPCvmIpPH96VMRKq7r6wgb K5cW8Dcc4tDz6wc/NfD1NZeQlvh0anR5UOcYEfJ6qZ4/sworsl+AFq7kqI/4Yejf hBxZSWUAEjcFHXO4aDRgwkEhb0RENjKgpEw+FX48JSuw7YAOLw7pW03MPQ0WOhdf r8NcXuoZVw7T/d+WL1XTegGM2qarb9LrowN7HRpck3IK2hbLb3gMlCxrh6iZNM4E 3MsYDN4Vm3utvjGl+Rao8fsa5Sa1j+lR81cgOw9wuuBVXmuunaXQD4HNJv+/GYoW h1f7+v0ApckNO8iAU6H+uMF6AJugE/XWZxECgiQ+xKzgZ2OeJDqdNdvx4VeL0+r5 T6M/XbhVBoLDcT+E9TdyvwWRuyPTxWCu/iIouGCG4N+lgBLMSC0xf2h34K4YM+Nd 8PgA7ak4nDHCZCkB0zY0CUo2bVW2nRVaGBltz+Sa5zJzVeQ//54= =bTzp -----END PGP SIGNATURE----- --nextPart2568154.s2QKoN3iYW-- From nobody Fri May 25 04:16: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 CC4F6124D68 for ; Fri, 25 May 2018 04:16:01 -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 7RNcvWwLu958 for ; Fri, 25 May 2018 04:16:00 -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 6D5F71204DA for ; Fri, 25 May 2018 04:16:00 -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 CAEE9C12A7; Fri, 25 May 2018 11:15:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id 265822026DEF; Fri, 25 May 2018 11:15:58 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 25 May 2018 13:15:58 +0200 Message-ID: <4524143.fXZafBPONl@pintsize.usersys.redhat.com> In-Reply-To: <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7837696.dzKR4x4Zto"; micalg="pgp-sha512"; protocol="application/pgp-signature" 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.1]); Fri, 25 May 2018 11:15:59 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 25 May 2018 11:15:59 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 25 May 2018 11:16:02 -0000 --nextPart7837696.dzKR4x4Zto Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 24 May 2018 18:51:08 CEST Viktor Dukhovni wrote: > > On May 24, 2018, at 12:30 PM, Adam Langley wro= te: > >=20 > > I think quite a lot of clients are going to be advertising compression > > using this code point in the coming months. They should only do so when > > offering TLS 1.3, which presumably LTS clients would not, so maybe ther= e's > > something you could use there. >=20 > It might still be prudent to get the new code point re-assigned. I > can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS > preferred when using TLS 1.2. I personally would prefer a different approach to TLS-LTS than what was=20 proposed then, so what uses ext 26 now may very well not be compatible with= =20 the RFC'd version... don't know how much of a problem would it be to=20 implementations that Peter shipped and yes, IMNSHO the TLS-LTS makes sense only in case the modern stacks (i.e= =2E=20 ones that support TLS 1.3) also support it and prefer it over vanilla TLS 1= =2E2 =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 --nextPart7837696.dzKR4x4Zto 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+dkqjRuAHS9fUFAlsH8G4ACgkQkqjRuAHS 9fUSNw//fe/2GxOkY2XQI4fiqJojgX4yq0SUlDwbrVkpIIX6o9gj17MJ3hw85f5l ZIsJcN7LUBUNTrB/JHi2GAvCaASmAfueVOQLALv5o2xv3GOx4yvCapbWGdpQkAPs uWCCge0b9N/PtM8XfRTTcWxZ54DEMwFyZqQgDX0gVXKQHcTMgdBpwq2paPT8OaAL AlE+O8P30mXnWEh3XYeDXnqGmhgqvXbUQwnTx8WFPhbVzLHtjttDu0YbGh1qsdeD foEPc38nidxhFepCJYPpZEXewbD+Pk/Z9rL8fOTj/lxWCgNfjQiRQMtBIlRnsJjv zA6mxa0fL22JBlVX3KBsQjCv4lnJ7sIPOCtMTZSF7xGr53JK/NK6b1eqCCDR3LXi CljD7mrCTlYvJvRxL+3ozczuOeouRtRrV0Z3433QJetuMxiUF2ALn6GBM/TG7Ug8 7Ua/OYEV7zBAw9Tdn7qqIE9yk+ZaKv2ZKwDCcaS8u5CNfeBIyKAo4Pf08X+FJm6E KFy2351hYpy5EXsZUiY/Xq28ZcZf9Wc+WmdyJ8abt1At6rJw8Zyf7l38slnSHjb1 pm6env/bc2qzHpY8/dGbeUJPPeWwPYap4y3Fua9jZG4ERV2mAiG65P8tb/lPkt0f PNo6uvEVc4BDZxnO7q3w6w5zTZ03mBKI83/IyXxo7iZfawmtDms= =EVMx -----END PGP SIGNATURE----- --nextPart7837696.dzKR4x4Zto-- From nobody Fri May 25 12:56:24 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 B763E129502; Fri, 25 May 2018 12:56:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , kaduk@mit.edu, tls-chairs@ietf.org, tls@ietf.org, draft-ietf-tls-iana-registry-updates@ietf.org, rfc-editor@rfc-editor.org, Stephen Farrell , stephen.farrell@cs.tcd.ie MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> Date: Fri, 25 May 2018 12:56:11 -0700 Archived-At: Subject: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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: Fri, 25 May 2018 19:56:12 -0000 The IESG has approved the following document: - 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ Technical Summary This document is not very technical, it's about IANA registries: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Working Group Summary This draft has been discussed at multiple IETFs most recently at IETF100: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-iana-registry-updates/ There's not been a lot of review because most people consider this administrivia that others should do; most just want the rules relaxed. A couple of notable reviews have been provided as noted below. The most important change - to loosen registrations while at the same time adding a "recommended" column to key registries requiring standards action for a "yes" value, had clear WG consensus. Various other WG documents depend on these changes being made and more will in the near future. Document Quality This document is essentially administrative, so the important considerations are to ensure consistency amongst it, the TLS 1.3 spec, and the existing registry contents, as well as internal consistency about the handling for various attributes, such as the "Recommended" column, warning notes to be added to registries, and review policies. Martin Thomson and Eric Rescorla have reviewed previous versions of the document. Personnel Stephen Farrell is the Document Shepherd. Benjamin Kaduk is the Responsible Area Director. The IANA Expert(s) for the registries in this document are: Yoav Nir , Rich Salz , and Nick Sullivan . The named experts have been approved previously on the March 8, 2018 Formal telechat. RFC Editor Note Section 15 mentions "values with the first byte in the range" (twice), but there is only a single byte, so these should just be "values in the range". Please also note that the traditional "IANA shall do/has done" constructions to be resolved to the past tense appear throughout the document, not just in an IANA considerations section. From nobody Sun May 27 05:50: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 7991312EB31; Sun, 27 May 2018 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 R_rrEO2tf4a4; Sun, 27 May 2018 05:49:59 -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 824B812EB33; Sun, 27 May 2018 05:49:57 -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=1527425398; x=1558961398; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=crYXoNEIrhvzijp80q15mI7qyEVV3UeXHBYJIrM3Y6Y=; b=WKvBSXcu2yhaQ7fUBvEIb89mndjVMzL1710o5YZvR6u+STbKdcSasF3G wTkpzRodcnWEHHTIO2EVTJqx/hUr4lTP5MtWmI8auORzCswEqJnW91d0w CR/tA9EzWwhv3E+o5s+iPcL9o8lSIEeEV2PpZ5F0IkYOKneMcqzFFoL0J PMIgkBgdXW+s8tl8VvHFEBXhvVK07iJ1gRHk574CsSdWq3G6w30er7tmg 5nzJtCzccRcbhJ9FrW1B8N+TXJtWfkDt8c/DxMP7SDYpkfObmgGuUpSco 9T7I4QvZ4aihwXa/uVcUHHXyOx2n5DCvTW0MlXNY6JfFkqYXMmaGaeSiV A==; X-IronPort-AV: E=Sophos;i="5.49,448,1520852400"; d="scan'208";a="13274346" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from uxcn13-tdc-b.uoa.auckland.ac.nz ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 May 2018 00:49:52 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 May 2018 00:49:52 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Mon, 28 May 2018 00:49:52 +1200 From: Peter Gutmann To: "tls@ietf.org" CC: "tls-chairs@ietf.org" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq Date: Sun, 27 May 2018 12:49:51 +0000 Message-ID: <1527425365931.63162@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> In-Reply-To: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.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] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 12:50:02 -0000 The IESG writes:=0A= =0A= >The IESG has approved the following document:=0A= >- 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram= =0A= > Transport Layer Security (DTLS)'=0A= > (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard=0A= =0A= Now that it's been published, I'd like to request assignment of an extensio= n=0A= ID for tls_lts under the Specification Required terms.=0A= =0A= In terms of the conflict between the existing use of 26 =3D tls_lts and the= new=0A= 26 =3D compress_certificate, this can probably be managed by noting that=0A= compress_certificate will only be sent by TLS 1.3 implementations and tls_l= ts=0A= will only be sent by TLS 1.0-1.2 implementations. In addition=0A= compress_certificate has a nonzero size (a list of algorithms is sent) whil= e=0A= tls_lts has a zero size (it's an indicator flag). This means that the two= =0A= different uses are unlikely to occur in the same implementation, and even i= f=0A= they do can be distinguished by looking at the extension data size.=0A= =0A= Having compress_certificate moved to 27 would be a better solution in terms= of=0A= existing use, but I can add a note to the LTS draft mentioning the change. = The=0A= certificate compression draft should probably also be updated to indicate t= hat=0A= a zero-size compress_certificate, if encountered, isn't a compress_certific= ate=0A= but a tls_lts.=0A= =0A= Peter.=0A= From nobody Sun May 27 09:57: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 02FE312ECC2 for ; Sun, 27 May 2018 09:57:14 -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 fU-nVpiWR-Qp for ; Sun, 27 May 2018 09:57:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84ED126D0C for ; Sun, 27 May 2018 09:57:11 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id t133-v6so4933126oif.10 for ; Sun, 27 May 2018 09:57:11 -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=IR1Jah8S8opBwi60B6jpCjrLX1QfH4f66+FBijisd/s=; b=jtc8JfLxwu6odZr3Zv/2euO+QbCWe7gPimVeFb8rIObLDb3xWuL0QsJO6cfLTnkYgE QBSRGh4zemZ1DdhOCb+QLUpkHJRnfy4AUNyg1aA/5JwjvAn2tRMZkwkhSckbfuUJtaJ9 jWSA0/WS0GbyCcJ+k6Z8UNomCuMoHVhEPjzOllfRD2bLUMyBBWz/OhNTQqEzIn058ut+ U8opcC20v71AhQJ1SEBD+Evdsa9TSm2z3xnwfM/eM96k7CCtB1BHqeR96Db764PhreBP PGwpKrInrQPI0CEFen323Tas1M7yT3MqM4KDxne6WXsQjcMmQkdigy+JP2oxbKfjeUEH 1deQ== 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=IR1Jah8S8opBwi60B6jpCjrLX1QfH4f66+FBijisd/s=; b=g5TDSL9N78738SiXBRlqN5QMNJk6bH0qedYTjgqQ7ERiEIeeQtR49mVembUq9euaBr UbjShtGwSgghtgH2HU0ExzxjylVuQbeKHLc9F2/rOlOjAcrZI1T5N/cpI2kAUjxTK+6w OrgbRrik+IujlTsuYfEjenOCFluZK5Y0ZdPf76TXiSV30nqYbckJ4FvXT7LN2lFHbnGM gte5ve7suS4jYe/LpJYQAE9JjyYdM7TDVE3UA1Jmn2H6HogVTNaNaHVwuPT/yM+8Gwmi 6uAJ3zkEjtI3FOw1XXe+KbW3smIh9k4sYqKyVh+9I3xBbGPuHCE99+0xa3DcAymn0v+b j2vg== X-Gm-Message-State: ALKqPwfhfL4fHdxT5mvX0/ASbh5StCwJSpKmCb4FK35GNJCGdAkdMzQR I6krIliuiG9q8466WW1BqXNnV8yC3otoplv/LlGIQQ== X-Google-Smtp-Source: ADUXVKIPAz9x1OrlJ9Sy59F0QkFBgHjPWIbJNKCLr6RlVJ3bH+k8IkCIk1/Ag/bz/lSN5PWVFY91qORB3kMhx4oOtOQ= X-Received: by 2002:aca:1c3:: with SMTP id 186-v6mr1041862oib.174.1527440231158; Sun, 27 May 2018 09:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Sun, 27 May 2018 09:56:30 -0700 (PDT) In-Reply-To: <1527425365931.63162@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> From: Eric Rescorla Date: Sun, 27 May 2018 09:56:30 -0700 Message-ID: To: Peter Gutmann Cc: "tls@ietf.org" , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000064e7ef056d32e402" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 16:57:14 -0000 --00000000000064e7ef056d32e402 Content-Type: text/plain; charset="UTF-8" Well, this is a bit premature because the document hasn't actually been published, just approved. In any case, I don't think we should assign code point 26 to this extension. I recognize that you have existing implementations that happen to use it, but that's a result of the unfortunate decision to squat on a code point which was right in the way of near future assignments, and those implementations can change to the new code point. Of course, it might be useful to add a note to implementations of the compression draft as well. -Ekr On Sun, May 27, 2018 at 5:49 AM, Peter Gutmann wrote: > The IESG writes: > > >The IESG has approved the following document: > >- 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram > > Transport Layer Security (DTLS)' > > (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard > > Now that it's been published, I'd like to request assignment of an > extension > ID for tls_lts under the Specification Required terms. > > In terms of the conflict between the existing use of 26 = tls_lts and the > new > 26 = compress_certificate, this can probably be managed by noting that > compress_certificate will only be sent by TLS 1.3 implementations and > tls_lts > will only be sent by TLS 1.0-1.2 implementations. In addition > compress_certificate has a nonzero size (a list of algorithms is sent) > while > tls_lts has a zero size (it's an indicator flag). This means that the two > different uses are unlikely to occur in the same implementation, and even > if > they do can be distinguished by looking at the extension data size. > > Having compress_certificate moved to 27 would be a better solution in > terms of > existing use, but I can add a note to the LTS draft mentioning the change. > The > certificate compression draft should probably also be updated to indicate > that > a zero-size compress_certificate, if encountered, isn't a > compress_certificate > but a tls_lts. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000064e7ef056d32e402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, this is a bit premature because the document ha= sn't actually been published, just approved.

In any case, I don't think we should assign code point 26 to this ex= tension. I recognize that you have existing implementations that happen to = use it, but that's a result of the unfortunate decision to squat on a c= ode point which was right in the way of near future assignments, and those = implementations can change to the new code point. Of course, it might be us= eful to add a note to implementations of the compression draft as well.

-Ekr


On Sun, Ma= y 27, 2018 at 5:49 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
The = IESG <iesg-secretary@ietf.org= > writes:

>The IESG has approved the following document:
>- 'IANA Registry Updates for Transport Layer Security (TLS) and Dat= agram
>=C2=A0 =C2=A0Transport Layer Security (DTLS)'
>=C2=A0 (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed S= tandard

Now that it's been published, I'd like to request assignment= of an extension
ID for tls_lts under the Specification Required terms.

In terms of the conflict between the existing use of 26 =3D tls_lts and the= new
26 =3D compress_certificate, this can probably be managed by noting that compress_certificate will only be sent by TLS 1.3 implementations and tls_l= ts
will only be sent by TLS 1.0-1.2 implementations.=C2=A0 In addition
compress_certificate has a nonzero size (a list of algorithms is sent) whil= e
tls_lts has a zero size (it's an indicator flag).=C2=A0 This means that= the two
different uses are unlikely to occur in the same implementation, and even i= f
they do can be distinguished by looking at the extension data size.

Having compress_certificate moved to 27 would be a better solution in terms= of
existing use, but I can add a note to the LTS draft mentioning the change. = The
certificate compression draft should probably also be updated to indicate t= hat
a zero-size compress_certificate, if encountered, isn't a compress_cert= ificate
but a tls_lts.

Peter.

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

--00000000000064e7ef056d32e402-- From nobody Sun May 27 10:58: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 E03FB12EBD3; Sun, 27 May 2018 10:58:12 -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 I6_oahgkM0CE; Sun, 27 May 2018 10:58:10 -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 B808F1270AE; Sun, 27 May 2018 10:58:10 -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 w4RHvE0Y018218; Sun, 27 May 2018 18:57:57 +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=mGXT6Ix+w/RA13EnCEW33CvL1sKFsJph2Nsfyy00d8E=; b=hle7Bc8QUwhaQHPDchKQlkui2VgXpdognHZf74YdxYW9nOnwHVvmw9nR7K2iQYaa734l RGl1eBwgfSvSCsEtWyBZ89su9BT9BonRwmgiU5n3dXLAWyu/8J8KYPjndYJY2p0+NIWY 8j0uPkJvucQxShrovVWbuKloOuQi2KfRy6LuwaJKxa6vmozQQElnRxQAy72dP8Q23Wy/ WnSSpxsBGhKrWt0FxjUD3wScw/rk/Tij/fgCWrQtcXA5IoRD8CTtZP5hQXsJIKKhT64j ztqU67m7ToYrUVvTx8/GOaww891thYybRCd2dtZjVtMXn7dgqXaLxpdWFS7TiUBY5WDx WA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2j6y42mjam-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 May 2018 18:57:57 +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 w4RHtseC031973; Sun, 27 May 2018 13:57:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j72wuvnda-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 27 May 2018 13:57:56 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 27 May 2018 12:57:55 -0500 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; Sun, 27 May 2018 12:57:55 -0500 From: "Salz, Rich" To: Eric Rescorla , Peter Gutmann CC: "tls@ietf.org" , "tls-chairs@ietf.org" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GKOPdENEVRzmUygZ9iMRn5YJ6RD3XSAgABE6QD//84aAA== Date: Sun, 27 May 2018 17:57:54 +0000 Message-ID: References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.152] Content-Type: multipart/alternative; boundary="_000_FE1F16CCC11542F0B76F22AFAB3951E5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-27_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-1805270223 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-27_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=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805270224 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 17:58:13 -0000 --_000_FE1F16CCC11542F0B76F22AFAB3951E5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkluIGFueSBjYXNlLCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBhc3NpZ24gY29kZSBwb2ludCAy NiB0byB0aGlzIGV4dGVuc2lvbi4gSSByZWNvZ25pemUgdGhhdCB5b3UgaGF2ZSBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMgdGhhdCBoYXBwZW4gdG8gdXNlIGl0LCBidXQgdGhhdCdzIGEgcmVzdWx0 IG9mIHRoZSB1bmZvcnR1bmF0ZSBkZWNpc2lvbiB0byBzcXVhdCBvbiBhIGNvZGUgcG9pbnQgd2hp Y2ggd2FzIHJpZ2h0IGluIHRoZSB3YXkgb2YgbmVhciBmdXR1cmUgYXNzaWdubWVudHMsIGFuZCB0 aG9zZSBpbXBsZW1lbnRhdGlvbnMgY2FuIGNoYW5nZSB0byB0aGUgbmV3IGNvZGUgcG9pbnQuIE9m IGNvdXJzZSwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGFkZCBhIG5vdGUgdG8gaW1wbGVtZW50YXRp b25zIG9mIHRoZSBjb21wcmVzc2lvbiBkcmFmdCBhcyB3ZWxsLg0KDQpJIHRoaW5rLCBpbiB0aGUg c3Bpcml0IG9mIGNvbWl0eSwgd2UgbGV0IDI2IGdvIHRvIFBldGVy4oCZcyBkcmFmdC4NCg0KICAg ICAgICAgICAgICAgIC9yJA0KDQo= --_000_FE1F16CCC11542F0B76F22AFAB3951E5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2F7D7BB84775EB42943A9897E98CA164@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5JbiBhbnkgY2FzZSwgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgYXNzaWduIGNvZGUgcG9pbnQg MjYgdG8gdGhpcyBleHRlbnNpb24uIEkgcmVjb2duaXplIHRoYXQgeW91IGhhdmUgZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIHRoYXQgaGFwcGVuIHRvIHVzZSBpdCwgYnV0IHRoYXQncyBhIHJlc3Vs dCBvZiB0aGUgdW5mb3J0dW5hdGUNCiBkZWNpc2lvbiB0byBzcXVhdCBvbiBhIGNvZGUgcG9pbnQg d2hpY2ggd2FzIHJpZ2h0IGluIHRoZSB3YXkgb2YgbmVhciBmdXR1cmUgYXNzaWdubWVudHMsIGFu ZCB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgY2FuIGNoYW5nZSB0byB0aGUgbmV3IGNvZGUgcG9pbnQu IE9mIGNvdXJzZSwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGFkZCBhIG5vdGUgdG8gaW1wbGVtZW50 YXRpb25zIG9mIHRoZSBjb21wcmVzc2lvbiBkcmFmdCBhcyB3ZWxsLg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHRoaW5rLCBpbiB0aGUgc3Bpcml0IG9mIGNvbWl0eSwgd2UgbGV0IDI2IGdvIHRvIFBldGVy 4oCZcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC9yJDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FE1F16CCC11542F0B76F22AFAB3951E5akamaicom_-- From nobody Sun May 27 21:38: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 2F86C12E868; Sun, 27 May 2018 21:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 wnAoEXAmy3pU; Sun, 27 May 2018 21:38:48 -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 378E61273E2; Sun, 27 May 2018 21:38:47 -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=1527482328; x=1559018328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GqA3dBCyD2quUWT6Ttd+CW8YabCNgadP7YzBRM1XUWo=; b=zVzSMhffiTDYDGSMt0N9s8b6WAZzgDOHJ7q7S6NtrUyfLonyVQtwh49z 1QWv9EGjZVri7nhuN52XGdlW7EOz3KXaqPCBzkovVc0uD5H6f2vSUJTjs 4e8YmMN7ZdqeLJEF/ij1EzXtF/J7NRKNB//QuA+YRGSSBMMXG4ysu3F7j jvEcmWr7vVHWWkIOQFCgfb73oP6rVF3FuBRowiOeFBMNqyvM6nMlZ3Z3i i5s0KEmcs6xPctwKHwcauCFRe2QtdEgSXw3VD6BTjSGEPiOwi6LUTbdHe Wt1o1tUu/BrYWg69lajNSiwBpWoMwPzCocfmoqPV+bdTIn+XVXJFJzqye Q==; X-IronPort-AV: E=Sophos;i="5.49,450,1520852400"; d="scan'208";a="13419681" 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; 28 May 2018 16:38:44 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 May 2018 16:38:44 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Mon, 28 May 2018 16:38:44 +1200 From: Peter Gutmann To: Eric Rescorla CC: "tls@ietf.org" , "tls-chairs@ietf.org" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq//98VACAAY0qOw== Date: Mon, 28 May 2018 04:38:44 +0000 Message-ID: <1527482297076.75302@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 28 May 2018 04:38:51 -0000 Eric Rescorla writes:=0A= =0A= >In any case, I don't think we should assign code point 26 to this extensio= n.=0A= >I recognize that you have existing implementations that happen to use it, = but=0A= >that's a result of the unfortunate decision to squat on a code point which= =0A= >was right in the way of near future assignments, and those implementations= =0A= >can change to the new code point. Of course, it might be useful to add a n= ote=0A= >to implementations of the compression draft as well.=0A= =0A= See my previous comment on why it was used, it was only because implementer= s=0A= needed something to put in their code while I waited for the registry draft= to=0A= be published... =0A= =0A= In any case I'm not overly fussed, as long as something gets assigned, just= =0A= wanted to point out that -LTS continuing with 26 would avoid having to=0A= document the problem in two different drafts and adding hacks to code to de= al=0A= with it. Given that one use is for SCADA/embedded TLS 1.0-1.2 and the othe= r=0A= is public web TLS 1.3 it's (hopefully) unlikely they'll ever run into each= =0A= other, but it'd be less messy if it was done properly rather than through= =0A= workarounds.=0A= =0A= Peter.=0A= From nobody Sun May 27 21: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 5036D1273E2 for ; Sun, 27 May 2018 21: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q38WYwFIQr5 for ; Sun, 27 May 2018 21:43: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 AD3C812D7F1 for ; Sun, 27 May 2018 21:43: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 E86187A3309 for ; Mon, 28 May 2018 04:43: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: <1527482297076.75302@cs.auckland.ac.nz> Date: Mon, 28 May 2018 00:43:34 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <9796F141-C352-4FA4-907C-4A92E1BAC873@dukhovni.org> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <1527482297076.75302@cs.auckland.ac.nz> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 28 May 2018 04:43:37 -0000 > On May 28, 2018, at 12:38 AM, Peter Gutmann = wrote: >=20 > See my previous comment on why it was used, it was only because = implementers > needed something to put in their code while I waited for the registry = draft to > be published...=20 I am curious whether (given the rather recent assignment) there are any = shipping implementations of compression with 26 already baked in. If = not, then perhaps TLS-LTS should get precedence. --=20 Viktor. From nobody Tue May 29 05:37: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 CA72A126CF6 for ; Tue, 29 May 2018 05:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GAnk1K_llmoN for ; Tue, 29 May 2018 05:37:20 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74AD1273E2 for ; Tue, 29 May 2018 05:37:19 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id f1-v6so18365949qtj.6 for ; Tue, 29 May 2018 05:37:19 -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=n/vck2sLfS2jRhVwLlxNMJyQg6IoYv8Mf9AzwsyqKyY=; b=MUBzVY5OAGnarq+AnK5t+2fOkYRYkV0n90XKeISbPOUi3HXtDW6PuKYgHhFFrjRoUh fKcox4fZIjLMNMxSLpgj3ZiRtQW2HVoG6zVrPaaRijzToKVJby4nMZOq0M/s5lRG+AgE qxNFrDqDH4mxwlXtJA03x242MLimGStPQ9w+U= 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=n/vck2sLfS2jRhVwLlxNMJyQg6IoYv8Mf9AzwsyqKyY=; b=tm4hnCvNcFW/TSBDd6OKKUwzw5QRWj3u+rlauFU+HZnafnmzZ9YvJqtCqGbd5n90Lv R9a2un3aDLJ4o6mmperymuJZm/TKTpKMbdS5UT07+yXCe03KZeSY1tUoLNsKFXKu/QDx flht9Y2fX2EuXHBdL/ruqBMykNCLfbS04ctZErBX4B3FpVzeUORuBqXDgpvl7vgfEVx2 af1dZWctN0Rhr1JlwrlDEIRzt5IhsRaFEoVmrL6tErkCZGBIeCe14qqIstbCVXBnc61K amgVo4lfLhv5dWr62ys1WCS5rPZr3PuIxLXZxSf790e2ZTcqsXctEBfXW6aXHtoKbYKF WFNg== X-Gm-Message-State: ALKqPwf6Yk61fYX4pG+mnQ4fWWNyQMZnXSUx8JLmrqIQfdshV+6LSar9 E674s5PteIarnfBmo0NneNTWXxAixdU= X-Google-Smtp-Source: ADUXVKJNDBPs533vI8AN47WT7o4cpUkiyEUny3FKsTLy6qrv9YetGVwaHh8uGUX8gD67fxrmewaMkA== X-Received: by 2002:a0c:cd13:: with SMTP id b19-v6mr8185819qvm.83.1527597438921; Tue, 29 May 2018 05:37:18 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id a191-v6sm9297524qkc.31.2018.05.29.05.37.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 05:37:18 -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: Date: Tue, 29 May 2018 08:37:17 -0400 Cc: tls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <944B20C8-64C7-47F7-B80E-F2EC37C3E1C6@dukhovni.org> To: Adam Langley X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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, 29 May 2018 12:37:22 -0000 > On May 24, 2018, at 13:42, Adam Langley wrote: > > It's also been pointed out that 26 collides with the value in > https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by > Sean :) f2p (face to plam). spt From nobody Tue May 29 07:20: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 DB56A12EAE7 for ; Tue, 29 May 2018 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0KsMXHVE0_47 for ; Tue, 29 May 2018 07:20:19 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CF512EB14 for ; Tue, 29 May 2018 07:20:18 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id d3-v6so18797857qtp.11 for ; Tue, 29 May 2018 07:20:18 -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=Y85tNCKd06c/e7fZK1SmebG4ytk9qzG77ztbpO6jyBo=; b=IPTXr/DzijIkAQnRm9CCVdET/VvVdHa1OzQNxcQdpvEscFFNNoYfvqjqE4+q5P30lR viPmcnbDOxao/GSSKUBTjws+Gg6QYwP6ecKbE38qIUlk0UCswIrdnpavzFf3Y7IzNUPG gB4okoVLcZdxjuDOttLkGPLQa4j126coctqbA= 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=Y85tNCKd06c/e7fZK1SmebG4ytk9qzG77ztbpO6jyBo=; b=gSEPCEdTIHKK6g6SUaBLGGLv32GH6DTUkufPA53QrI6PnfHRhHan8Gt/wOgwwFAX4u mWZSlBJ5pVedQ2iJazFUThKYwg3twiLhpNd+432D9LLsu7k0Js2tw3G7mCCC52b5Othv rLdz8DssVc6I4h02mD1+FYSyN5T86X4MqpsZXQAjufhCAKaK6qZSx7n2St85fJCmVYXZ V1XYNJSRmMtI3OoN339Q+3si2OAd/ubKhaFStmg1/fXRTbbc7+FTKOR3JHYkk8zv6tjT kQEsMem/H2S8IptYXaF+2ve9WBtz3AMcdLTuKE6jC6v9D4k6kp275vOFV3n9SOOVeqOJ u6/g== X-Gm-Message-State: ALKqPwe/ct1dN6LTCTUmySvYVtDmw8vmbfL38FtLkdrLXcuu/FEF0m/9 vJE62i7D26kE7D7cl12ZkyxJjsF6OEM= X-Google-Smtp-Source: ADUXVKJTQEig1/cAKRB+mllNc8puVLIJKxsSbWXDT4G9uy+TDw7B66yBpyo2aOp+xRl+dTuebjS2IA== X-Received: by 2002:ac8:4245:: with SMTP id r5-v6mr16467108qtm.262.1527603617733; Tue, 29 May 2018 07:20:17 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id m70-v6sm5028011qkl.72.2018.05.29.07.20.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 07:20:16 -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: Tue, 29 May 2018 10:20:15 -0400 References: <362431E5-0B10-4E8E-AFF1-4B8217D27C64@sn3rd.com> To: TLS WG In-Reply-To: <362431E5-0B10-4E8E-AFF1-4B8217D27C64@sn3rd.com> Message-Id: <87129D7B-FABF-4E8A-B46B-B64D28753E49@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] TLS@IETF102: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 May 2018 14:20:27 -0000 Just a reminder we=E2=80=99re going to submit our agenda request this = week so get your agenda time request in soon. spt > On May 22, 2018, at 20:13, Sean Turner wrote: >=20 > The TLS WG will be meeting @ IETF 102 in Montreal. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to tls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. >=20 > Cheers, >=20 > J&S From nobody Tue May 29 07:35: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 E5DF112E9D9 for ; Tue, 29 May 2018 07:35:32 -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 8anaK36c8r3V for ; Tue, 29 May 2018 07:35:31 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9412E957 for ; Tue, 29 May 2018 07:35:31 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id h2-v6so18883287qtp.7 for ; Tue, 29 May 2018 07:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BZ5+xriHSvropTMJICVxlfPS7KWEjGFvDvORrp/JmO0=; b=bH8VZW/q2Fjqwsxr0Uh2zLdANqzPcvp+is4aPgjcQkbjOGkWQlY3u6n9NbHehBexgI vbwKgkN1EuNJNE05wH0aSMtlqQg99WmGKAu1Nf/zjslDcvGt1+qfRiekGcMpqE6cVJDL UtBZ6ycjrBzehz2pJQ7nUdJFSjFJQ9/kjQbbc= 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=BZ5+xriHSvropTMJICVxlfPS7KWEjGFvDvORrp/JmO0=; b=nmv+YYPB7Cjb5fWWZDQrhPZfG8lWTNS2tWsoOiHZJP52yC0UW7kcuJb6psJCIF8rKi 4AFYbPLP0o/wlj56Vu9orrFra9kKBkRHqPa09OIhQ6Qb/jnBjaxkQFZzpO/qsQ8smJ8O T0jaAkJMjRWTsrmIND/EKNqT8QvkGY4vaYF+679tLXKesgEEAW6noimvYu+DHFgFAakm 1Rldorn7+QN/oqSGok84qXfpgy7Z/gnzF/Rrs9dJJpaOy3RltXsb10Muhlp94FdU0Zff /vzQc9/Wt6ki8bRD0GiVxvPZTbeZV+m6KfIigwJNFseUdewhrX9dl75KHqWkccw5B/S0 D7pg== X-Gm-Message-State: ALKqPwelkFylTCF+HbHCJbuIiPjln6RO00wLzzhc7EkxTW6ReVaQpHmb fImumDA+xjYIHxbtdnInk17dYFqHLT4= X-Google-Smtp-Source: ADUXVKJx0XZrIDlj53tTqo9twSi/55DTQynSsIWvSfl8PcTvacPFsJaFXxrXvU+I/2VJo4d/AQRNlg== X-Received: by 2002:a0c:8d4b:: with SMTP id s11-v6mr16103507qvb.163.1527604530022; Tue, 29 May 2018 07:35:30 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id g56-v6sm4076895qta.83.2018.05.29.07.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 07:35:29 -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: Tue, 29 May 2018 10:35:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <742B3DCC-6AF4-48DB-82F9-760DEF7E52F4@sn3rd.com> References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 May 2018 14:35:33 -0000 > On May 8, 2018, at 20:30, Martin Thomson = wrote: >=20 > On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: >> I dislike standard, and am fine with Informational or BCP. >=20 > Agree regarding standard. >=20 > I don't understand why BCP would be used for this. Besides, we = probably > don't want to enshrine some of the choices we made in NSS as "best > practice". I'm not saying that those choices aren't defensible, but = that > might be going too far. Since this draft is really about =E2=80=9Cexamples=E2=80=9D (i.e., = it=E2=80=99s just for illustration), I=E2=80=99m going to suggest that = Martin go ahead and merge the following PR that I submitted changing the = intended status: https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6 Once a new version is spun, I=E2=80=99ll push the draft toward Ben. spt= From nobody Tue May 29 08:13: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 4B662124234 for ; Tue, 29 May 2018 08:12: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=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 cDE4I5o4uuUq for ; Tue, 29 May 2018 08:12:49 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C852612D949 for ; Tue, 29 May 2018 08:12:48 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id q6-v6so19068949qtn.3 for ; Tue, 29 May 2018 08:12:48 -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=AINIA6mDJhqk0eTyQrSn6mgwhL1EWcr47h6Kqg5E7Q4=; b=nFSoCTI/JnVmyUqnR/VfYjHnmt0qnUN9NC1YgRDTDpdw6oSxMRvXpE2SpHBgXG50op tALPOLrSmnMljhF9gRVFgvjggSaSV1FX9YM4vOeM2b7puuaqznSCsKtcqUzg/tiyB2j2 XLNLqYbVQF1meZLH7IpBNeKIeKXNcHj2cKHm0= 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=AINIA6mDJhqk0eTyQrSn6mgwhL1EWcr47h6Kqg5E7Q4=; b=Kuj0Cf4D6w0+lIWDa1JH2WqJL7vXfDCyUMp5ZoQw2VjEEssxhXMLo1oPZ1UvArpori nnIshTbnSaouqSHfI6ZngO2shyiDObj4sg+5S5olhi3opmxWfhPd/y//s28+fwRcbKw7 JZ5zQm0/TzLcIFSOJOMtKOg9Xu4VXvvo+wvEL+QyDuNHyb3UTTJi53IsxlshOprRDQ0T utPeR6aYTHGw1BVjatahEvOKtpYipo1uE6v3rR2Tc3dyG3XnxGRSxvXYkqJqXwGoq1E3 SCVUfjKAhBj31slJKiurVtZJaxXQP489BvmWX41ss7+g5EVq2HWhoDJiNnpv3JTZlUaS Ug4A== X-Gm-Message-State: ALKqPwd+JpcwVbNjhwCO084gkhhDq94gjOZr4+s5uP7+Dt+BxmR83Ju/ WBdC/OgjsUTFfq55K04/xtVEnrOKvww= X-Google-Smtp-Source: ADUXVKIrxbtypmHe6gYa2ERcX/ZWV8Hem7/uYcDRuOh+lqbLocZXAq38KDgJ0srKCfHdKCUhjhXWlA== X-Received: by 2002:a0c:e401:: with SMTP id o1-v6mr9140714qvl.66.1527606767939; Tue, 29 May 2018 08:12:47 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id i52-v6sm11597638qtc.26.2018.05.29.08.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 08:12:47 -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\)) Date: Tue, 29 May 2018 11:12:45 -0400 References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> To: Chris Wood , TLS WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] 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: Tue, 29 May 2018 15:13:00 -0000 As Martin noted, this seems to be a pretty simple idea, but am curious = if others feel that way. Curious about the choice on the limit of 255 identifiers versus = something smaller. If the max ticket age is one week that could = theoretically be almost 5 years of tickets right? spt PS - Thanks for not code squatting ;) > On Apr 12, 2018, at 23:15, Chris Wood wrote: >=20 > Hi everyone, >=20 > 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.=20 >=20 > We would very much appreciate feedback on the mechanism utility and = design. >=20 > Best, > Chris=20 >=20 > Begin forwarded message: >=20 >> 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 >>=20 >>=20 >> 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. >>=20 >> 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 >>=20 >>=20 >> 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. >>=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 Tue May 29 10:20: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 5B7B712EB20 for ; Tue, 29 May 2018 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 mlCW2wCpDBNW for ; Tue, 29 May 2018 10:20:44 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D339012E8A7 for ; Tue, 29 May 2018 10:20:43 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id v190-v6so2693413ywa.12 for ; Tue, 29 May 2018 10:20:43 -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=/rdCjl33MZBf3HSI8zwq19xqqxcOJNFHwwiNZeZBkFc=; b=ojVdwilr7dElw0G4Hs58jMZ2ifJUdUicv2fdsuTPvP34zH5d6yuFxCRnNBac0fG9cZ TMzRSY7ooaPlDI+6pBjkQh5o7ZRt7aX7GUmarRKWxxwks+8ptRettdScNo/VxNEW531H Lv3fLrOmhR6R5B+3kjdiV/LlV+leyrYgBsAZcax1OR1ZGy7HsYiFCFv7D13TibxIzjVf vd7tevzkhmfdZBhJsJs9spk6N8N+naP2pvJxx4UfmndJHQpb1bl9OIKSk1lCs3/7tPiF KWZIiAx6GuTX4SRxM0NranKDWcg5fhg2yphAdon3gUV2UeeYSWnMGgtvEcvSlb53u6M9 6RSg== 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=/rdCjl33MZBf3HSI8zwq19xqqxcOJNFHwwiNZeZBkFc=; b=gsiqQs/X+9MaCpVFfSf4VzYHJKUuQJAxRTrg4t8mFJR2G9fx1803ZxR07B5RLAUkmL ORpY3V6J90tQr2OMmWA9JESdZXMCCxPEw+FWyV6oJrU1Ijo9xKQbjwyCPg4TYHlAJWPz Tf/EKbWwYhqewxFUiwrYCHWGsip17zWyf4kACN3Wecupz9xGj4bsncuaKDdGCwm4FEL6 KteO8Q/7Y8obivpIc5Sa6KSFkLr3QHQIuPqEmSHDeWWnSQLN7yu7uWykeBnTMSGbjHM6 +KDjit21NruazKkeLkYWb8uuh1IWvsEsfDwLkyd8504suDFISLfSHRX3tUmrbSQArvCm I+tA== X-Gm-Message-State: ALKqPwc0DxMUqtl3rhvn+I+V6EiP0kakg7efzWxie4ZnTU0mkX9yUAHY d+u9zPo8cjeIDZsvg/CZtbgxhPHljjL70mWBOV+7hfLs X-Google-Smtp-Source: AB8JxZrPlng4ibZjzCWmKcFDdG2KcB/iIjwMMMIfbtKpkTtdiJ0/TyigtToSvZA2VcPsWonaTjfCrmT0gl3qJdpxc4c= X-Received: by 2002:a81:ad03:: with SMTP id l3-v6mr9446521ywh.57.1527614442774; Tue, 29 May 2018 10:20:42 -0700 (PDT) MIME-Version: 1.0 References: <152358885591.26305.6650636859312248765.idtracker@ietfa.amsl.com> In-Reply-To: From: Christopher Wood Date: Tue, 29 May 2018 10:20:31 -0700 Message-ID: To: Sean Turner Cc: Christopher Wood , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] 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: Tue, 29 May 2018 17:20:46 -0000 On Tue, May 29, 2018 at 8:25 AM Sean Turner wrote: > > As Martin noted, this seems to be a pretty simple idea, but am curious if others feel that way. > > Curious about the choice on the limit of 255 identifiers versus something smaller. If the max ticket age is one week that could theoretically be almost 5 years of tickets right? We went with 255 since we did not want anything larger. If others think the limit should be lowered, we can certainly do so. That said, the server is free to bound the number of tickets it vends, so this may not be needed. Best, Chris From nobody Tue May 29 11:57: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 E21B7124234 for ; Tue, 29 May 2018 11:57:43 -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 xY8j_RF4jkqF for ; Tue, 29 May 2018 11:57:41 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7438012EAB7 for ; Tue, 29 May 2018 11:57:41 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-08v.sys.comcast.net with ESMTP id NgjzfFeENuPXCNjoSfC7sS; Tue, 29 May 2018 18:57:40 +0000 Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-20v.sys.comcast.net with ESMTPSA id NjoRf2Qv9fXTANjoRfG8xE; Tue, 29 May 2018 18:57:40 +0000 To: "tls@ietf.org" From: Andrey Jivsov Openpgp: preference=signencrypt Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= xsBNBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAHNH0FuZHJleSBKaXZzb3YgPGEuaml2c292QGY1LmNvbT7CwHgEEwECACIFAlbFIFYCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELgEWn228sNLaVAH/2kv4jXHYn6mP8yTWeD5 5BmBK4eu/vAiNLZVXBhUJxv3oZLBbowZGYgnQ1BwOYZn53hbC7TGIg5QIhEAgfxvyR73R7jO DqV8Uc/jRhyl2L8eB5MkKcxBpcT0Y8g2bm7bPlCF4YX7HEks+qu9c7bAbCdYJiaqjA3WgMFm 9yh3zthsOzzC/WWq+SeXeSQ6NTK3+2TH4zlDkuwt189cTKi8KG1yyLtd6FXWGDg+Zizv40p5 OM67KdTEOmn52gGWPlLZzPzpLlrR8zVTFoxKmZW/Xhp4IEsamk+lmF5OJXQysoYEIjdEcBFE CK4czNJC3tnqOOf/+hgNlo5CwhrkSzeZL7vOwE0EVsUgOQEIAOVkchUqBCxNVAm7qn8rSIZA D5iloxoaqnf4EKtJxbauyBq4XxkskTm1gzprjZsnWQirv4+1ebi2rgTtg5wyhV2WfrF61r7c trjIpmfe2fqK3xhhUrresbXNAv16mc08UR+ZYflBaCwumjYTBD4Rq57cS+kL1AoiZta+0Idy llOjJiIUuYq6yL+eNVFQ+Sv31MIV0ydWskjsSM9Hq/JyuUmcjPSi+g6xSbSP1lFJ1rGKRQp3 UX+H5ExJekLPHzLpGNHwHy/fOtf2VJzKCafWfDDnggm3PahxMgN8tFqpJ1WJiL9T+xQRhBCh bYXHnCv0dmjzyQlVMH7awPqXLRmp8CMAEQEAAcLAXwQYAQIACQUCVsUgOQIbDAAKCRC4BFp9 tvLDS9zHB/wMZBXPQVTj9kmTs8+wecG1HSgv08wt88HJAYNOlgWRcygGHvlinwRCnon9kxEF PAKlu35qYl5qFHcglJZRaiZVwfOhVmqXg+SmFKKmnhrrFHQCHqq2mW2+K/dloATKy8j8m9Rz /zCLD2xDAb0bIJDF4f7iemymBdDaFiNok5+XgXg/QXNndz3FO/S2IF+t2oHM1e7hBj+NEfER nNTE9gG8KkQGPVvyPZmVgSwsQ7dGnxuvdak6EaWG4M6Rbcwq0vu2lzvj1I3xaqJHhhwmsHAo qL9t8B/g6QwXr7hkHZ+zHKtFaY1zp3aKjj6xayfIUXY19VvAHodzCPjq8Sa7RJi8 Message-ID: Date: Tue, 29 May 2018 11:57:39 -0700 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 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-CMAE-Envelope: MS4wfEulnnsWg0Z/C0IXruXzS2OcZVv2oDOp31hyc4urYUSX20RERCfV6eAX1wtcwcPcqUSOCTOERI1HRrqGScAeugLRdRgrS1ogvYJ/HpV8EDGO77QcbMp+ REzPMOf3hyWs+vpwnUHZv98Z6cgLxUtA09ogiWxL99bqv0Qoca8erKRt Archived-At: Subject: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:57:44 -0000 Greetings. TLS 1.3 draft in sec 4.2.3.=C2=A0 Signature Algorithms tells that if a cl= ient wants to negotiate TLS 1.3, it must support an upgraded (and incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. You might recall that the possibility to negotiate between PSS and RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509 signatures, was discussed on the mailing list. The WG decision then was to hard-wire PSS in the TLS 1.3 handshake. I don't recall any discussion on going further than this, all the way to changing the 10-year old TLS 1.2. Unfortunately, our products have issues with PSS beyond our control. The only solution left to avoid receiving PSS with TLS 1.2 is to never negotiate TLS 1.3 as a client. Another solution is insecure fallback, but we presently don't do this. Is my reading of the situation correct? Thank you. =C2=A0 From nobody Tue May 29 12:13: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 0AFF412E957 for ; Tue, 29 May 2018 12:13:26 -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 XrMIVH7h8OnN for ; Tue, 29 May 2018 12:13:24 -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 2DAE11275FD for ; Tue, 29 May 2018 12:13:24 -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 w4TJCA4O002048; Tue, 29 May 2018 20:13:21 +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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=U/RJnCq4CAu9tzZlNQIEl+JqLqjKfaYDZqo4BcfiVyg=; b=Hv2aOd7i7lxhciKklFOsxltzro1kqg4bth9qtoj1envkI+gVFPJodgS/z5ug0YxHnhAp JFu4UMv2jTWNZyOz9FAfbiPOuQ0X6MRIhxI+l6kpwQ+imqsP2djengtxUaKaOL6KBzTJ xze8lI+nKT+4Frvz160zSayjcrDsWY/DLyHGk4JcM2LaU+A40GB2j3p/AHddOQBZGgzr rCChzZ/w8EYx99za43kRDqLxpxAzDSuz9YXho1z9JGAbyPanPKDCeDgUQVFDTi3F0OVj p/eQiGwNSju2n1TACqxK0hCguULfWqdLNJu4U/wxrKuhY4ABLpNigvFReyWEvWNkEdP8 VA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2j93uf1ka7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 20:13:21 +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 w4TJAnXL005043; Tue, 29 May 2018 15:13:20 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j72xbw0xr-1; Tue, 29 May 2018 15:13:20 -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 9B489217AE; Tue, 29 May 2018 19:13:20 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fNk3b-0004yu-Sc; Tue, 29 May 2018 14:13:19 -0500 Date: Tue, 29 May 2018 14:13:19 -0500 From: Benjamin Kaduk To: Andrey Jivsov Cc: "tls@ietf.org" Message-ID: <20180529191319.GJ13834@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805290204 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805290204 Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:13:26 -0000 On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > Greetings. > > TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client > wants to negotiate TLS 1.3, it must support an upgraded (and > incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow > RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > > You might recall that the possibility to negotiate between PSS and > RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509 > signatures, was discussed on the mailing list. The WG decision then was > to hard-wire PSS in the TLS 1.3 handshake. > > I don't recall any discussion on going further than this, all the way to > changing the 10-year old TLS 1.2. > > Unfortunately, our products have issues with PSS beyond our control. The > only solution left to avoid receiving PSS with TLS 1.2 is to never > negotiate TLS 1.3 as a client. Another solution is insecure fallback, > but we presently don't do this. > > Is my reading of the situation correct? Thank you. Sounds like it: RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined in [SHS]. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2, -Ben From nobody Tue May 29 12:35: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 131F812EC1A for ; Tue, 29 May 2018 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=brainhub-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmuHKDH98g_x for ; Tue, 29 May 2018 12:35:22 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C690512EBD7 for ; Tue, 29 May 2018 12:35:22 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id a14-v6so7770210pfi.1 for ; Tue, 29 May 2018 12:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainhub-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I1BA6D5YVLejCu1VkNBNhsIrupY6Q/F/suv/f//NUYY=; b=Nd/XM/QeDafVdbG3CAO78PmXZEo09pB7pnCKQ5nAAYSo+u3slpBCcWydto1TqJ33ax ejcYXZmK/KvMEpQLp+hmnPwlbp7bsVmoLvxIrKwG03C6zT5RFBLlJXUgVl9ElmZfLYqI lsZ8l/F9XOM7Lhd7o6t6e9oHY8nKxq0cf9DSRxZASRIASRj2Ar0IfqE3HEtxVbEGyG/r rzbcD4VHrWAGsFUEhQd+r17G7nr9qklU0f4Mdx1KBst6+LbNqsFRyYw224fi/6MNpUuD 8bRNpSFfHiZQkK9Oh0nsPmQVClt/Mf3QA+HLm9MUIi89jVuhbxZCsHcsuFVu7Fb/y1xw ysQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I1BA6D5YVLejCu1VkNBNhsIrupY6Q/F/suv/f//NUYY=; b=WN7K4X0mQnUsp49elKiN2uBwwZ68ftLLuc0SqEK3NV9uJaX2cU5XbqpD2rDbAfg84v 0xYej+W/W7Mn7G51NAW9+tgCsg30GeCYZGH/PVvrvBNzn1y+3wn3eGIhQluwcgZyXHpA 1AJ1S6XNV4GtzYAEDc4rlYQuzlh6IUEv9fjAM9X0ICeCGDcK8587xukn6YZePdRcm6tr BMP5Fcj1kxTmJFcP/GcQBWVxyBVbGFYRwwP8XXpXWDxpfiaJ24hUik58Ex/jSSLhDdWv EA6U6FI5OyHuj4Ya8GX0XiDmykElZVNsclRvORzqEg+W6qYPuiwUVsj5Pu2BAQA1nu0n 6Iig== X-Gm-Message-State: ALKqPwf6pW7iM35Bqiq9yw/ZYlYlsKoIIyBeyonKRpH1vltWRcCf0+2r bZFefwc17A3F+lffPECzuWT3vpaX X-Google-Smtp-Source: ADUXVKKE6Kw1UM0OhOO2gueIPwxxnDMS+ZdA+fp9gzzGUv6JcgEdHn80qpSIaEslqFTRntl3kdt6kQ== X-Received: by 2002:a62:a054:: with SMTP id r81-v6mr13752001pfe.10.1527622521913; Tue, 29 May 2018 12:35:21 -0700 (PDT) Received: from [192.168.86.104] ([104.219.107.83]) by smtp.googlemail.com with ESMTPSA id r68-v6sm71475313pfi.174.2018.05.29.12.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 12:35:21 -0700 (PDT) Sender: Andrey To: Benjamin Kaduk Cc: "tls@ietf.org" References: <20180529191319.GJ13834@akamai.com> From: Andrey Jivsov Message-ID: <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> Date: Tue, 29 May 2018 12:35:20 -0700 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: <20180529191319.GJ13834@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:35:25 -0000 On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: >> Greetings. >> >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client >> wants to negotiate TLS 1.3, it must support an upgraded (and >> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow >> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. >> >> You might recall that the possibility to negotiate between PSS and >> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509 >> signatures, was discussed on the mailing list. The WG decision then was >> to hard-wire PSS in the TLS 1.3 handshake. >> >> I don't recall any discussion on going further than this, all the way to >> changing the 10-year old TLS 1.2. >> >> Unfortunately, our products have issues with PSS beyond our control. The >> only solution left to avoid receiving PSS with TLS 1.2 is to never >> negotiate TLS 1.3 as a client. Another solution is insecure fallback, >> but we presently don't do this. >> >> Is my reading of the situation correct? Thank you. > > Sounds like it: > > RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using > RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm > as defined in [SHS]. These values refer solely to signatures > which appear in certificates (see Section 4.4.2.2) and are not > defined for use in signed TLS handshake messages, although they > MAY appear in "signature_algorithms" and > "signature_algorithms_cert" for backward compatibility with TLS > 1.2, > > -Ben > I was referring to > > - Implementations that advertise support for RSASSA-PSS (which is > mandatory in TLS 1.3), MUST be prepared to accept a signature > using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, > RSASSA-PSS is used with RSA cipher suites. I am OK with what you quoted. What I just quoted represents a significant change in behavior in TLS 1.2 and there is no way to opt out of this change to TLS 1.2. I will add that I've seen this behavior by servers already, even when client doesn't advertise TLS 1.3. Just the fact of including some 08 xx IDs in signature_algorithms in ClientHello, without protocol_version extension, gets the TLS 1.2 upgraded to RSA-PSS. IMO this paragraph should be removed. Those that want PSS in the handshake should negotiate TLS 1.3. Preservation of current behavior of TLS 1.2 is important, at least as an option. From nobody Tue May 29 12:43: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 E1C4E127137 for ; Tue, 29 May 2018 12:42:58 -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 oWyb9ScXEZPz for ; Tue, 29 May 2018 12:42:56 -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 14FFC12EBCF for ; Tue, 29 May 2018 12:42:56 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TJbAcn002122; Tue, 29 May 2018 20:42:53 +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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=1aJlvgRpTdL5jcv9UOo7J6VFPllUR/IBNm3w6VYerlQ=; b=kWol9Emqmo9dac/Em9yzYaaAWB19H6X5iYpKUN+Ojl3MvzYXkHdH1B+XQGZYNV+cu1HL yaSTUXvaaiGcbb3KbQmyLpZrZB3gmzT5g2LgbDRolbKLGvggrmhaSNIdvO9N/psMONGG w/K6DGKIKyPae+DR136zje9mk4n4WM/mwuq8yY394et3UaSoaGXTdp1HohLOlYlHoB2f bZXbGuE8d/wQC3NvX7Szb/mC57wRtjw10aWNC4V+s3w/AX5js6PdyuXq22jkza3ry3HM +IRbAxPRkZaY+TiTwt8fViy8S/BrKmLeEKfAjvD47eckEWruRZod8pLPTgFWlJ0vTGAn nQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2j9cw501yp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 20:42:53 +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 w4TJZn03007999; Tue, 29 May 2018 15:42:52 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2j9cw982k8-1; Tue, 29 May 2018 15:42:52 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 3E3E31FC11; Tue, 29 May 2018 19:42:52 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fNkWB-00053u-KF; Tue, 29 May 2018 14:42:51 -0500 Date: Tue, 29 May 2018 14:42:51 -0500 From: Benjamin Kaduk To: Andrey Jivsov Cc: "tls@ietf.org" Message-ID: <20180529194251.GK13834@akamai.com> References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290209 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290209 Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:42:59 -0000 On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > >> Greetings. > >> > >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client > >> wants to negotiate TLS 1.3, it must support an upgraded (and > >> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow > >> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > >> > >> You might recall that the possibility to negotiate between PSS and > >> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509 > >> signatures, was discussed on the mailing list. The WG decision then was > >> to hard-wire PSS in the TLS 1.3 handshake. > >> > >> I don't recall any discussion on going further than this, all the way to > >> changing the 10-year old TLS 1.2. > >> > >> Unfortunately, our products have issues with PSS beyond our control. The > >> only solution left to avoid receiving PSS with TLS 1.2 is to never > >> negotiate TLS 1.3 as a client. Another solution is insecure fallback, > >> but we presently don't do this. > >> > >> Is my reading of the situation correct? Thank you. > > > > Sounds like it: > > > > RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using > > RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm > > as defined in [SHS]. These values refer solely to signatures > > which appear in certificates (see Section 4.4.2.2) and are not > > defined for use in signed TLS handshake messages, although they > > MAY appear in "signature_algorithms" and > > "signature_algorithms_cert" for backward compatibility with TLS > > 1.2, > > > > -Ben > > > > I was referring to > > > > - Implementations that advertise support for RSASSA-PSS (which is > > mandatory in TLS 1.3), MUST be prepared to accept a signature > > using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, > > RSASSA-PSS is used with RSA cipher suites. > > I am OK with what you quoted. What I just quoted represents a > significant change in behavior in TLS 1.2 and there is no way to opt out > of this change to TLS 1.2. Ah, I misread your original message, but all is clear now. > I will add that I've seen this behavior by servers already, even when > client doesn't advertise TLS 1.3. Just the fact of including some 08 xx > IDs in signature_algorithms in ClientHello, without protocol_version > extension, gets the TLS 1.2 upgraded to RSA-PSS. > > IMO this paragraph should be removed. Those that want PSS in the > handshake should negotiate TLS 1.3. Preservation of current behavior of > TLS 1.2 is important, at least as an option. First off, it's basically too late to make substantive changes like that; the bar to meet is something like "a huge outcry from deployments" or "a critical security flaw". Second, what's going on here is that TLS 1.3 is defining some new signature algorithms for TLS messages, and making them mandatory to support for TLS 1.3. But negotiation of TLS signature algorithms has *always* been independent of protocol version. If you support TLS 1.3, you also support the new signature algorithms; if you support TLS 1.3 and TLS 1.2, you support the new signature algorithms and you support TLS 1.2, therefore by the longstanding negotiation rules you are obligated to support the combination. You are in effect proposing that we make a break in the signature (and hash) algorithm space with individual algorithms supported either in <=1.2 or >=1.3, but not both -- we did this for ciphersuites since we fundamentally changed the meaning of what a ciphersuite is. But the signature scheme does not seem to have undergone such a fundamental change, so it seems hard to justify introducing this sort of split. -Ben From nobody Tue May 29 13:02: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 CE23912FACB for ; Tue, 29 May 2018 13:02:03 -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 4KyyVH1tcE6F for ; Tue, 29 May 2018 13:01:53 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 6A38B12FACD for ; Tue, 29 May 2018 13:01:53 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-06v.sys.comcast.net with ESMTP id Nk9TfphvhRNLYNkoafSKAL; Tue, 29 May 2018 20:01:52 +0000 Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-09v.sys.comcast.net with ESMTPSA id NkoZfgiQNwLQoNkoZfKXCB; Tue, 29 May 2018 20:01:52 +0000 To: Benjamin Kaduk Cc: "tls@ietf.org" References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> From: Andrey Jivsov Openpgp: preference=signencrypt Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= xsBNBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAHNH0FuZHJleSBKaXZzb3YgPGEuaml2c292QGY1LmNvbT7CwHgEEwECACIFAlbFIFYCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELgEWn228sNLaVAH/2kv4jXHYn6mP8yTWeD5 5BmBK4eu/vAiNLZVXBhUJxv3oZLBbowZGYgnQ1BwOYZn53hbC7TGIg5QIhEAgfxvyR73R7jO DqV8Uc/jRhyl2L8eB5MkKcxBpcT0Y8g2bm7bPlCF4YX7HEks+qu9c7bAbCdYJiaqjA3WgMFm 9yh3zthsOzzC/WWq+SeXeSQ6NTK3+2TH4zlDkuwt189cTKi8KG1yyLtd6FXWGDg+Zizv40p5 OM67KdTEOmn52gGWPlLZzPzpLlrR8zVTFoxKmZW/Xhp4IEsamk+lmF5OJXQysoYEIjdEcBFE CK4czNJC3tnqOOf/+hgNlo5CwhrkSzeZL7vOwE0EVsUgOQEIAOVkchUqBCxNVAm7qn8rSIZA D5iloxoaqnf4EKtJxbauyBq4XxkskTm1gzprjZsnWQirv4+1ebi2rgTtg5wyhV2WfrF61r7c trjIpmfe2fqK3xhhUrresbXNAv16mc08UR+ZYflBaCwumjYTBD4Rq57cS+kL1AoiZta+0Idy llOjJiIUuYq6yL+eNVFQ+Sv31MIV0ydWskjsSM9Hq/JyuUmcjPSi+g6xSbSP1lFJ1rGKRQp3 UX+H5ExJekLPHzLpGNHwHy/fOtf2VJzKCafWfDDnggm3PahxMgN8tFqpJ1WJiL9T+xQRhBCh bYXHnCv0dmjzyQlVMH7awPqXLRmp8CMAEQEAAcLAXwQYAQIACQUCVsUgOQIbDAAKCRC4BFp9 tvLDS9zHB/wMZBXPQVTj9kmTs8+wecG1HSgv08wt88HJAYNOlgWRcygGHvlinwRCnon9kxEF PAKlu35qYl5qFHcglJZRaiZVwfOhVmqXg+SmFKKmnhrrFHQCHqq2mW2+K/dloATKy8j8m9Rz /zCLD2xDAb0bIJDF4f7iemymBdDaFiNok5+XgXg/QXNndz3FO/S2IF+t2oHM1e7hBj+NEfER nNTE9gG8KkQGPVvyPZmVgSwsQ7dGnxuvdak6EaWG4M6Rbcwq0vu2lzvj1I3xaqJHhhwmsHAo qL9t8B/g6QwXr7hkHZ+zHKtFaY1zp3aKjj6xayfIUXY19VvAHodzCPjq8Sa7RJi8 Message-ID: <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> Date: Tue, 29 May 2018 13:01:51 -0700 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: <20180529194251.GK13834@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHkfNPwM54zJBpWzoz/zjVfdtxjEWkUQIf1/wV2DyIH4G+H0zJ0qo+OaWCprmk7lVeUaCBfZcTB7xW2yRJdHTU6Kx7omOyX75JcOmgz9g76OEvu/kgLc KsVR0PkoPGUVVQa3hbwfczkFGmOTKAZ2UyDGXricbMfvX/GQ7RqnDrFn7iaevVCU77psu/q0mTMqrg== Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:02:20 -0000 On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: >>>> Greetings. >>>> >>>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client >>>> wants to negotiate TLS 1.3, it must support an upgraded (and >>>> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. >>>> >>>> You might recall that the possibility to negotiate between PSS and >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509 >>>> signatures, was discussed on the mailing list. The WG decision then was >>>> to hard-wire PSS in the TLS 1.3 handshake. >>>> >>>> I don't recall any discussion on going further than this, all the way to >>>> changing the 10-year old TLS 1.2. >>>> >>>> Unfortunately, our products have issues with PSS beyond our control. The >>>> only solution left to avoid receiving PSS with TLS 1.2 is to never >>>> negotiate TLS 1.3 as a client. Another solution is insecure fallback, >>>> but we presently don't do this. >>>> >>>> Is my reading of the situation correct? Thank you. >>> >>> Sounds like it: >>> >>> RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using >>> RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm >>> as defined in [SHS]. These values refer solely to signatures >>> which appear in certificates (see Section 4.4.2.2) and are not >>> defined for use in signed TLS handshake messages, although they >>> MAY appear in "signature_algorithms" and >>> "signature_algorithms_cert" for backward compatibility with TLS >>> 1.2, >>> >>> -Ben >>> >> >> I was referring to >>> >>> - Implementations that advertise support for RSASSA-PSS (which is >>> mandatory in TLS 1.3), MUST be prepared to accept a signature >>> using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, >>> RSASSA-PSS is used with RSA cipher suites. >> >> I am OK with what you quoted. What I just quoted represents a >> significant change in behavior in TLS 1.2 and there is no way to opt out >> of this change to TLS 1.2. > > Ah, I misread your original message, but all is clear now. > >> I will add that I've seen this behavior by servers already, even when >> client doesn't advertise TLS 1.3. Just the fact of including some 08 xx >> IDs in signature_algorithms in ClientHello, without protocol_version >> extension, gets the TLS 1.2 upgraded to RSA-PSS. >> >> IMO this paragraph should be removed. Those that want PSS in the >> handshake should negotiate TLS 1.3. Preservation of current behavior of >> TLS 1.2 is important, at least as an option. > > First off, it's basically too late to make substantive changes like that; > the bar to meet is something like "a huge outcry from deployments" or > "a critical security flaw". > > Second, what's going on here is that TLS 1.3 is defining some new signature > algorithms for TLS messages, and making them mandatory to support for TLS 1.3. > But negotiation of TLS signature algorithms has *always* been independent of > protocol version. If you support TLS 1.3, you also support the new signature > algorithms; if you support TLS 1.3 and TLS 1.2, you support the new signature > algorithms and you support TLS 1.2, therefore by the longstanding negotiation > rules you are obligated to support the combination. You are in effect proposing > that we make a break in the signature (and hash) algorithm space with individual > algorithms supported either in <=1.2 or >=1.3, but not both -- we did this for > ciphersuites since we fundamentally changed the meaning of what a ciphersuite is. > But the signature scheme does not seem to have undergone such a fundamental change, > so it seems hard to justify introducing this sort of split. > > -Ben > We are talking about TLS 1.3-specific IDs: /* RSASSA-PSS algorithms with public key OID rsaEncryption */ rsa_pss_rsae_sha256(0x0804), rsa_pss_rsae_sha384(0x0805), rsa_pss_rsae_sha512(0x0806) In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus these IDs have no meaning to TLS 1.2. TLS 1.3 spec purposely "split" these IDs so that they have no meaning to TLS 1.2 servers. One needs the paragraph I quoted to force implementations to change the behavior of TLS 1.2. What's the harm of dropping this one paragraph I quoted and keeping TLS 1.2 behavior the same? From nobody Tue May 29 13:07: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 5918E124BFA for ; Tue, 29 May 2018 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 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.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KYnbaMMcPsUp for ; Tue, 29 May 2018 13:07:23 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E25126DFB for ; Tue, 29 May 2018 13:07:21 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id d125-v6so12524636qkb.8 for ; Tue, 29 May 2018 13:07:21 -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=8HtYJ0gP2yowR3blEDpGFWJeYDxln8WCBAz6RlrUHTY=; b=le0xOgY26AoSR4+3mMAUheWsPu1aqhhXDGFVLB0rGuCps5tac8nJj8dhoj5yBsVvNM 4bSs6EJXJHQZoydMiOp5Deznl7W7gcgpWILQUSxWfgQhM+EUFN2JGvbJlQAgZYYrQv/M J4ECIly9H4qQyRaHLIOzr3GxxOF5a3CrBKhAA= 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=8HtYJ0gP2yowR3blEDpGFWJeYDxln8WCBAz6RlrUHTY=; b=JUN87am9pi/5xdHhRWd6T2T6dhoF9OmXgtYzT5BSbWqEQpa2hmXGMabgsCc+JqaA6S d2ssUBFwJiAqkLKMWvnCmLbQVZP+w60ufIr9Skh7h7fzT1cE0MNPj8t0rUCdhc013gix h0avyf2pGkp8HvpV2Kho0f4XUBrowZzw5ordL4kHq0kn6zGFK6MShEcJWrVA4h7nz4QC HUwoLw6mpHaAr7JfXSr/KCSwsU4G+68TnUXfW04PdsniBsv2N64OTsJYibOO2T5bRGhc z9oOiZRk5K+KxaII85Pr4qbnph85+5WnwEHB5YWwX9ZfhS+YIjW4JBu24B10cTOCi/5k gioQ== X-Gm-Message-State: ALKqPwdOg4lSTge/6e2cjMzsADlXI3zn9T/TMw22WQYjcxtk/MdLoULR jT3gU6hwXqf4oF2WuhRPkFx2i5Q4Eslvs6As6sil X-Google-Smtp-Source: ADUXVKJcZ1JkfMFVTf5xyw9PV7vymuXnIeC1riXrwBglcwU9g1/aIFoij0Ld/WWItU+0J71LTti193Dq98MrW2qiZ+I= X-Received: by 2002:a37:9507:: with SMTP id x7-v6mr15991573qkd.232.1527624440096; Tue, 29 May 2018 13:07:20 -0700 (PDT) MIME-Version: 1.0 References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> In-Reply-To: <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> From: David Benjamin Date: Tue, 29 May 2018 16:07:08 -0400 Message-ID: To: Andrey Jivsov Cc: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001ae1d0056d5dc885" Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:07:36 -0000 --0000000000001ae1d0056d5dc885 Content-Type: text/plain; charset="UTF-8" I'm not sure I follow this. So, in this scenario, you are the client. You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and this is fine. You are able to verify RSA-PSS signatures from the server at TLS 1.3. At the same time, you still talk to some TLS 1.2 servers, so you may get a response from them. As TLS 1.2 and TLS 1.3 use the same signature algorithms negotiation, that same ClientHello obligates your client (newly updated to support TLS 1.3) to also verify RSA-PSS signatures from TLS 1.2. But this causes troubles somehow. I'm confused how a client would have an RSA-PSS function available at one version, but not the other. Or am I misunderstanding your situation? On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov wrote: > On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > >>>> Greetings. > >>>> > >>>> TLS 1.3 draft in sec 4.2.3. Signature Algorithms tells that if a > client > >>>> wants to negotiate TLS 1.3, it must support an upgraded (and > >>>> incompatible) version of TLS 1.2, the one that changes RFC 5246 to > allow > >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > >>>> > >>>> You might recall that the possibility to negotiate between PSS and > >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for > X.509 > >>>> signatures, was discussed on the mailing list. The WG decision then > was > >>>> to hard-wire PSS in the TLS 1.3 handshake. > >>>> > >>>> I don't recall any discussion on going further than this, all the way > to > >>>> changing the 10-year old TLS 1.2. > >>>> > >>>> Unfortunately, our products have issues with PSS beyond our control. > The > >>>> only solution left to avoid receiving PSS with TLS 1.2 is to never > >>>> negotiate TLS 1.3 as a client. Another solution is insecure fallback, > >>>> but we presently don't do this. > >>>> > >>>> Is my reading of the situation correct? Thank you. > >>> > >>> Sounds like it: > >>> > >>> RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using > >>> RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm > >>> as defined in [SHS]. These values refer solely to signatures > >>> which appear in certificates (see Section 4.4.2.2) and are not > >>> defined for use in signed TLS handshake messages, although they > >>> MAY appear in "signature_algorithms" and > >>> "signature_algorithms_cert" for backward compatibility with TLS > >>> 1.2, > >>> > >>> -Ben > >>> > >> > >> I was referring to > >>> > >>> - Implementations that advertise support for RSASSA-PSS (which is > >>> mandatory in TLS 1.3), MUST be prepared to accept a signature > >>> using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, > >>> RSASSA-PSS is used with RSA cipher suites. > >> > >> I am OK with what you quoted. What I just quoted represents a > >> significant change in behavior in TLS 1.2 and there is no way to opt out > >> of this change to TLS 1.2. > > > > Ah, I misread your original message, but all is clear now. > > > >> I will add that I've seen this behavior by servers already, even when > >> client doesn't advertise TLS 1.3. Just the fact of including some 08 xx > >> IDs in signature_algorithms in ClientHello, without protocol_version > >> extension, gets the TLS 1.2 upgraded to RSA-PSS. > >> > >> IMO this paragraph should be removed. Those that want PSS in the > >> handshake should negotiate TLS 1.3. Preservation of current behavior of > >> TLS 1.2 is important, at least as an option. > > > > First off, it's basically too late to make substantive changes like that; > > the bar to meet is something like "a huge outcry from deployments" or > > "a critical security flaw". > > > > Second, what's going on here is that TLS 1.3 is defining some new > signature > > algorithms for TLS messages, and making them mandatory to support for > TLS 1.3. > > But negotiation of TLS signature algorithms has *always* been > independent of > > protocol version. If you support TLS 1.3, you also support the new > signature > > algorithms; if you support TLS 1.3 and TLS 1.2, you support the new > signature > > algorithms and you support TLS 1.2, therefore by the longstanding > negotiation > > rules you are obligated to support the combination. You are in effect > proposing > > that we make a break in the signature (and hash) algorithm space with > individual > > algorithms supported either in <=1.2 or >=1.3, but not both -- we did > this for > > ciphersuites since we fundamentally changed the meaning of what a > ciphersuite is. > > But the signature scheme does not seem to have undergone such a > fundamental change, > > so it seems hard to justify introducing this sort of split. > > > > -Ben > > > > We are talking about TLS 1.3-specific IDs: > > /* RSASSA-PSS algorithms with public key OID rsaEncryption */ > rsa_pss_rsae_sha256(0x0804), > rsa_pss_rsae_sha384(0x0805), > rsa_pss_rsae_sha512(0x0806) > > In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus > these IDs have no meaning to TLS 1.2. > > TLS 1.3 spec purposely "split" these IDs so that they have no meaning to > TLS 1.2 servers. One needs the paragraph I quoted to force > implementations to change the behavior of TLS 1.2. > > What's the harm of dropping this one paragraph I quoted and keeping TLS > 1.2 behavior the same? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001ae1d0056d5dc885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure I follow this. So, in this scenario,= you are the client. You wish to support TLS 1.3, which requires supporting= RSA-PSS in TLS 1.3, and this is fine. You are able to verify RSA-PSS signa= tures from the server at TLS 1.3.

At the same time= , you still talk to some TLS 1.2 servers, so you may get a response from th= em. As TLS 1.2 and TLS 1.3 use the same signature algorithms negotiation, t= hat same ClientHello obligates your client (newly updated to support TLS 1.= 3) to also verify RSA-PSS signatures from TLS 1.2. But this causes troubles= somehow.

I'm confused how a client would have= an RSA-PSS function available at one version, but not the other. Or am I m= isunderstanding your situation?

On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov &l= t;crypto@brainhub.= org> wrote:
On 05/29/2018 12= :42 PM, Benjamin Kaduk wrote:
> On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
>> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
>>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:=
>>>> Greetings.
>>>>
>>>> TLS 1.3 draft in sec 4.2.3.=C2=A0 Signature Algorithms tel= ls that if a client
>>>> wants to negotiate TLS 1.3, it must support an upgraded (a= nd
>>>> incompatible) version of TLS 1.2, the one that changes RFC= 5246 to allow
>>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
>>>>
>>>> You might recall that the possibility to negotiate between= PSS and
>>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allo= wed for X.509
>>>> signatures, was discussed on the mailing list. The WG deci= sion then was
>>>> to hard-wire PSS in the TLS 1.3 handshake.
>>>>
>>>> I don't recall any discussion on going further than th= is, all the way to
>>>> changing the 10-year old TLS 1.2.
>>>>
>>>> Unfortunately, our products have issues with PSS beyond ou= r control. The
>>>> only solution left to avoid receiving PSS with TLS 1.2 is = to never
>>>> negotiate TLS 1.3 as a client. Another solution is insecur= e fallback,
>>>> but we presently don't do this.
>>>>
>>>> Is my reading of the situation correct? Thank you.
>>>
>>> Sounds like it:
>>>
>>>=C2=A0 =C2=A0 RSASSA-PKCS1-v1_5 algorithms=C2=A0 Indicates a si= gnature algorithm using
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0RSASSA-PKCS1-v1_5 [RFC8017] with the= corresponding hash algorithm
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0as defined in [SHS].=C2=A0 These val= ues refer solely to signatures
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0which appear in certificates (see Se= ction 4.4.2.2) and are not
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0defined for use in signed TLS handsh= ake messages, although they
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY appear in "signature_algori= thms" and
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"signature_algorithms_cert"= ; for backward compatibility with TLS
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A01.2,
>>>
>>> -Ben
>>>
>>
>> I was referring to
>>>
>>>=C2=A0 =C2=A0 -=C2=A0 Implementations that advertise support fo= r RSASSA-PSS (which is
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory in TLS 1.3), MUST be prepa= red to accept a signature
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0using that scheme even when TLS 1.2 = is negotiated.=C2=A0 In TLS 1.2,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0RSASSA-PSS is used with RSA cipher s= uites.
>>
>> I am OK with what you quoted. What I just quoted represents a
>> significant change in behavior in TLS 1.2 and there is no way to o= pt out
>> of this change to TLS 1.2.
>
> Ah, I misread your original message, but all is clear now.
>
>> I will add that I've seen this behavior by servers already, ev= en when
>> client doesn't advertise TLS 1.3. Just the fact of including s= ome 08 xx
>> IDs in signature_algorithms in ClientHello, without protocol_versi= on
>> extension, gets the TLS 1.2 upgraded to RSA-PSS.
>>
>> IMO this paragraph should be removed. Those that want PSS in the >> handshake should negotiate TLS 1.3. Preservation of current behavi= or of
>> TLS 1.2 is important, at least as an option.
>
> First off, it's basically too late to make substantive changes lik= e that;
> the bar to meet is something like "a huge outcry from deployments= " or
> "a critical security flaw".
>
> Second, what's going on here is that TLS 1.3 is defining some new = signature
> algorithms for TLS messages, and making them mandatory to support for = TLS 1.3.
> But negotiation of TLS signature algorithms has *always* been independ= ent of
> protocol version.=C2=A0 If you support TLS 1.3, you also support the n= ew signature
> algorithms; if you support TLS 1.3 and TLS 1.2, you support the new si= gnature
> algorithms and you support TLS 1.2, therefore by the longstanding nego= tiation
> rules you are obligated to support the combination.=C2=A0 You are in e= ffect proposing
> that we make a break in the signature (and hash) algorithm space with = individual
> algorithms supported either in <=3D1.2 or >=3D1.3, but not both = -- we did this for
> ciphersuites since we fundamentally changed the meaning of what a ciph= ersuite is.
> But the signature scheme does not seem to have undergone such a fundam= ental change,
> so it seems hard to justify introducing this sort of split.
>
> -Ben
>

We are talking about TLS 1.3-specific IDs:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* RSASSA-PSS algorithms with public key = OID rsaEncryption */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha256(0x0804),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha384(0x0805),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha512(0x0806)

In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus
these IDs have no meaning to TLS 1.2.

TLS 1.3 spec purposely "split" these IDs so that they have no mea= ning to
TLS 1.2 servers. One needs the paragraph I quoted to force
implementations to change the behavior of TLS 1.2.

What's the harm of dropping this one paragraph I quoted and keeping TLS=
1.2 behavior the same?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001ae1d0056d5dc885-- From nobody Tue May 29 13:14: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 4DFF312ECEC; Tue, 29 May 2018 13:14:29 -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 sgE8JJtH7qqT; Tue, 29 May 2018 13:14:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA31E12EC45; Tue, 29 May 2018 13:14:24 -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 w4TK7IeM013873; Tue, 29 May 2018 21:14:17 +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=lGhoQ1HbYNRt/8ZzsdT4YnXXnwm1mpYjQ5KiGNk4dgE=; b=IRm7XfBO1K+9Br0C/mTsVgQIo//bXzJ1xQcnigloywKgzNUcll+cSrbDJuR85hQeRS5c BfCnWy7WWiy3z7QlPA6KcwGkmdHHtHhdALpURm0XgZxO44FmzBJE4NZsWegPaZiUvHe5 /rORl/XOC/RvyxPtXyb/LLzyCzSkjq8v+iRuFMzBDudvW6W6euQCikDIAH/onEEjLSav UqiwhIo1mRIEKG7PltU8AtHvOtao2tUWyGcCsOwS53CTFcwG1RTlbUNysdRN+NI9x4e7 AWO1pd9OOR2h73HotfgHZFzsKx4o+0BGBdXNvw8mrptS13IK2REV4zxSbbtWdgIawn8s uw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2j9cw60545-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 21:14:17 +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 w4TKBKf5001854; Tue, 29 May 2018 16:14:16 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j9cvt07nb-1; Tue, 29 May 2018 16:14:15 -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 CE0481FCDC; Tue, 29 May 2018 20:14:15 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fNl0Z-0005Fn-5p; Tue, 29 May 2018 15:14:15 -0500 Date: Tue, 29 May 2018 15:14:14 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: "tls@ietf.org" , "tls-chairs@ietf.org" Message-ID: <20180529201414.GL13834@akamai.com> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@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) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290214 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290214 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:14:36 -0000 On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote: > Well, this is a bit premature because the document hasn't actually been > published, just approved. It's also not properly addressed -- regular allocations under the "specification required" policy go directly to IANA, whereas RFC 7120 early allocations it is the WG chairs and ADs that need to judge the level of interest in the community. > In any case, I don't think we should assign code point 26 to this > extension. I recognize that you have existing implementations that happen > to use it, but that's a result of the unfortunate decision to squat on a > code point which was right in the way of near future assignments, and those > implementations can change to the new code point. Of course, it might be > useful to add a note to implementations of the compression draft as well. There's a tradeoff between respecting the official allocation processes and avoiding real-world breakage. I think we can all make our own assessments on the former, but for the latter, all the evidence we have so far is a claim from Peter that there exists software that hardcodes this number, with no indication of scale of deployment or ease of updating such software. -Ben From nobody Tue May 29 13:22: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 29CF9126E64; Tue, 29 May 2018 13:22:01 -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 5ekAmuOLvzeU; Tue, 29 May 2018 13:22:00 -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 EFD6012E8D7; Tue, 29 May 2018 13:21:59 -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 w4TKGgNr012407; Tue, 29 May 2018 21:21:56 +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=fVXTp+p2DehtSomYfFbxtt8opFOYEU7QfMinwByHMCo=; b=ePEDHMPO9DCcYTtAPZzTIC8lZQ3afnlQx00GysDwuH1H1bVblOcGUaUlMTVA0tn+Gmrj KnmR4zdWzWBA7c77Y6nP9SiyXB46Jdb3EAJTskiAQqRNXUVzMebT8ww9uoYhuw5ER3ij h5mJBj14qcMRt3imCE7AFhjOtwnDog6IVbjGHKMQHD0zCtloHvYUNZPzv6x+ZJ70TlpI AtpEfvd7VGJHYYOSviVTDt0JOcUywvS8YasMBDISmohbewjxqZvVShUCgJXMpIXq40mI Il3MT1nNJ+Im+Y1nqTbdYvyfpLf/K3SsFy3nwgCocubNB9B5jakaOxPcLJQtRV2Mq7uR DQ== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2j9cw5g5am-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 21:21:55 +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 w4TKGRLt000662; Tue, 29 May 2018 16:21:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j9cvv07g8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 16:21:54 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 29 May 2018 15:21:54 -0500 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; Tue, 29 May 2018 15:21:54 -0500 From: "Salz, Rich" To: Benjamin Kaduk , Peter Gutmann CC: "tls@ietf.org" , "tls-chairs@ietf.org" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GKOPdENEVRzmUygZ9iMRn5YJ6RD3XSAgABE6QCAA1vpAP//vxWA Date: Tue, 29 May 2018 20:21:53 +0000 Message-ID: References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> In-Reply-To: <20180529201414.GL13834@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.144] Content-Type: text/plain; charset="utf-8" Content-ID: <0F4300727ABBE0448DED3F8EA61848A8@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290215 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290215 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:22:01 -0000 PiAgICBUaGVyZSdzIGEgdHJhZGVvZmYgYmV0d2VlbiByZXNwZWN0aW5nIHRoZSBvZmZpY2lhbCBh bGxvY2F0aW9uIHByb2Nlc3Nlcw0KICAgIGFuZCBhdm9pZGluZyByZWFsLXdvcmxkIGJyZWFrYWdl LiAgSSB0aGluayB3ZSBjYW4gYWxsIG1ha2Ugb3VyIG93biBhc3Nlc3NtZW50cw0KICAgIG9uIHRo ZSBmb3JtZXIsIGJ1dCBmb3IgdGhlIGxhdHRlciwgYWxsIHRoZSBldmlkZW5jZSB3ZSBoYXZlIHNv IGZhciBpcyBhIGNsYWltDQogICAgZnJvbSBQZXRlciB0aGF0IHRoZXJlIGV4aXN0cyBzb2Z0d2Fy ZSB0aGF0IGhhcmRjb2RlcyB0aGlzIG51bWJlciwgd2l0aCBubw0KICAgIGluZGljYXRpb24gb2Yg c2NhbGUgb2YgZGVwbG95bWVudCBvciBlYXNlIG9mIHVwZGF0aW5nIHN1Y2ggc29mdHdhcmUuDQog IA0KUGV0ZXIgdHJpZWQgdmVyeSBoYXJkIHRvIHBsYXkgYnkgYWxsIHRoZSBydWxlcywgd2hldGhl ciB0aGV5IHdlcmUgZW5zaHJpbmVkIGluIGZvcm1hbCBkb2N1bWVudHMsIG9yICJqdXN0IiBkZWNp c2lvbnMgYnkgV0cgY2hhaXJzLCBhbmQgZXZlcnl0aGluZyBpbi1iZXR3ZWVuLg0KDQpQZXRlciBz YXlzIHRoZSBudW1iZXIgaXMgaW4gdXNlLg0KDQpJIGJlbGlldmUgaGltLg0KDQpHaXZlIGhpbSB0 aGUgZGFtbiBudW1iZXIuDQoNCg0K From nobody Tue May 29 13:26: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 2509112FA86 for ; Tue, 29 May 2018 13:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDUAhLoD2SDA for ; Tue, 29 May 2018 13:26:30 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 36CAB12FA84 for ; Tue, 29 May 2018 13:26:30 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-04v.sys.comcast.net with ESMTP id NjenfaDVPN7zjNlCPf9iPv; Tue, 29 May 2018 20:26:29 +0000 Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-14v.sys.comcast.net with ESMTPSA id NlCNfaUq7dQERNlCOfzj2w; Tue, 29 May 2018 20:26:29 +0000 To: David Benjamin Cc: Benjamin Kaduk , "tls@ietf.org" References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> From: Andrey Jivsov Openpgp: preference=signencrypt Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= xsBNBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAHNH0FuZHJleSBKaXZzb3YgPGEuaml2c292QGY1LmNvbT7CwHgEEwECACIFAlbFIFYCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELgEWn228sNLaVAH/2kv4jXHYn6mP8yTWeD5 5BmBK4eu/vAiNLZVXBhUJxv3oZLBbowZGYgnQ1BwOYZn53hbC7TGIg5QIhEAgfxvyR73R7jO DqV8Uc/jRhyl2L8eB5MkKcxBpcT0Y8g2bm7bPlCF4YX7HEks+qu9c7bAbCdYJiaqjA3WgMFm 9yh3zthsOzzC/WWq+SeXeSQ6NTK3+2TH4zlDkuwt189cTKi8KG1yyLtd6FXWGDg+Zizv40p5 OM67KdTEOmn52gGWPlLZzPzpLlrR8zVTFoxKmZW/Xhp4IEsamk+lmF5OJXQysoYEIjdEcBFE CK4czNJC3tnqOOf/+hgNlo5CwhrkSzeZL7vOwE0EVsUgOQEIAOVkchUqBCxNVAm7qn8rSIZA D5iloxoaqnf4EKtJxbauyBq4XxkskTm1gzprjZsnWQirv4+1ebi2rgTtg5wyhV2WfrF61r7c trjIpmfe2fqK3xhhUrresbXNAv16mc08UR+ZYflBaCwumjYTBD4Rq57cS+kL1AoiZta+0Idy llOjJiIUuYq6yL+eNVFQ+Sv31MIV0ydWskjsSM9Hq/JyuUmcjPSi+g6xSbSP1lFJ1rGKRQp3 UX+H5ExJekLPHzLpGNHwHy/fOtf2VJzKCafWfDDnggm3PahxMgN8tFqpJ1WJiL9T+xQRhBCh bYXHnCv0dmjzyQlVMH7awPqXLRmp8CMAEQEAAcLAXwQYAQIACQUCVsUgOQIbDAAKCRC4BFp9 tvLDS9zHB/wMZBXPQVTj9kmTs8+wecG1HSgv08wt88HJAYNOlgWRcygGHvlinwRCnon9kxEF PAKlu35qYl5qFHcglJZRaiZVwfOhVmqXg+SmFKKmnhrrFHQCHqq2mW2+K/dloATKy8j8m9Rz /zCLD2xDAb0bIJDF4f7iemymBdDaFiNok5+XgXg/QXNndz3FO/S2IF+t2oHM1e7hBj+NEfER nNTE9gG8KkQGPVvyPZmVgSwsQ7dGnxuvdak6EaWG4M6Rbcwq0vu2lzvj1I3xaqJHhhwmsHAo qL9t8B/g6QwXr7hkHZ+zHKtFaY1zp3aKjj6xayfIUXY19VvAHodzCPjq8Sa7RJi8 Message-ID: Date: Tue, 29 May 2018 13:26:27 -0700 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 X-CMAE-Envelope: MS4wfGNjpbWorH7TYVNG2bpjgjvLvCJ4/3644SrG1DuJH80wrwZkGeznYqrHY6xqQY3Q5olSscH3Zff/KB7D1sz+Aqzwz/aUm593jGtEEahOySE/KxGo4jv5 e7br5xXBkCiRJYOcLDMM7iXOCVNaNKpWXnRvxrLzvQ+tuimbvT/eKKLbFc8b37Vphs0OtDooxTocPWZSwwQ6YlVxKvsUaSoDnzk= Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:26:33 -0000 On 05/29/2018 01:07 PM, David Benjamin wrote: > I'm not sure I follow this. So, in this scenario, you are the client. > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > 1.3, and this is fine. You are able to verify RSA-PSS signatures from > the server at TLS 1.3. > > At the same time, you still talk to some TLS 1.2 servers, so you may get > a response from them. As TLS 1.2 and TLS 1.3 use the same signature > algorithms negotiation, that same ClientHello obligates your client > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures > from TLS 1.2. But this causes troubles somehow. > > I'm confused how a client would have an RSA-PSS function available at > one version, but not the other. Or am I misunderstanding your situation? There is a need to upgrade TLS 1.2 stack, just because one can now negotiate TLS 1.3. Does this "upgrade" to TLS 1.2 extends to client authentication? Then this adds more work. There can be a performance penalty with RSA-PSS v.s. RSA legacy and more issues when private keys are used in client authentication (because e.g. they are HSM keys). > > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov > wrote: > > On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > >>>> Greetings. > >>>> > >>>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if > a client > >>>> wants to negotiate TLS 1.3, it must support an upgraded (and > >>>> incompatible) version of TLS 1.2, the one that changes RFC 5246 > to allow > >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > >>>> > >>>> You might recall that the possibility to negotiate between PSS and > >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed > for X.509 > >>>> signatures, was discussed on the mailing list. The WG decision > then was > >>>> to hard-wire PSS in the TLS 1.3 handshake. > >>>> > >>>> I don't recall any discussion on going further than this, all > the way to > >>>> changing the 10-year old TLS 1.2. > >>>> > >>>> Unfortunately, our products have issues with PSS beyond our > control. The > >>>> only solution left to avoid receiving PSS with TLS 1.2 is to never > >>>> negotiate TLS 1.3 as a client. Another solution is insecure > fallback, > >>>> but we presently don't do this. > >>>> > >>>> Is my reading of the situation correct? Thank you. > >>> > >>> Sounds like it: > >>> > >>>    RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm > using > >>>       RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash > algorithm > >>>       as defined in [SHS].  These values refer solely to signatures > >>>       which appear in certificates (see Section 4.4.2.2) and are not > >>>       defined for use in signed TLS handshake messages, although > they > >>>       MAY appear in "signature_algorithms" and > >>>       "signature_algorithms_cert" for backward compatibility > with TLS > >>>       1.2, > >>> > >>> -Ben > >>> > >> > >> I was referring to > >>> > >>>    -  Implementations that advertise support for RSASSA-PSS > (which is > >>>       mandatory in TLS 1.3), MUST be prepared to accept a signature > >>>       using that scheme even when TLS 1.2 is negotiated.  In TLS > 1.2, > >>>       RSASSA-PSS is used with RSA cipher suites. > >> > >> I am OK with what you quoted. What I just quoted represents a > >> significant change in behavior in TLS 1.2 and there is no way to > opt out > >> of this change to TLS 1.2. > > > > Ah, I misread your original message, but all is clear now. > > > >> I will add that I've seen this behavior by servers already, even when > >> client doesn't advertise TLS 1.3. Just the fact of including some > 08 xx > >> IDs in signature_algorithms in ClientHello, without protocol_version > >> extension, gets the TLS 1.2 upgraded to RSA-PSS. > >> > >> IMO this paragraph should be removed. Those that want PSS in the > >> handshake should negotiate TLS 1.3. Preservation of current > behavior of > >> TLS 1.2 is important, at least as an option. > > > > First off, it's basically too late to make substantive changes > like that; > > the bar to meet is something like "a huge outcry from deployments" or > > "a critical security flaw". > > > > Second, what's going on here is that TLS 1.3 is defining some new > signature > > algorithms for TLS messages, and making them mandatory to support > for TLS 1.3. > > But negotiation of TLS signature algorithms has *always* been > independent of > > protocol version.  If you support TLS 1.3, you also support the > new signature > > algorithms; if you support TLS 1.3 and TLS 1.2, you support the > new signature > > algorithms and you support TLS 1.2, therefore by the longstanding > negotiation > > rules you are obligated to support the combination.  You are in > effect proposing > > that we make a break in the signature (and hash) algorithm space > with individual > > algorithms supported either in <=1.2 or >=1.3, but not both -- we > did this for > > ciphersuites since we fundamentally changed the meaning of what a > ciphersuite is. > > But the signature scheme does not seem to have undergone such a > fundamental change, > > so it seems hard to justify introducing this sort of split. > > > > -Ben > > > > We are talking about TLS 1.3-specific IDs: > >          /* RSASSA-PSS algorithms with public key OID rsaEncryption */ >           rsa_pss_rsae_sha256(0x0804), >           rsa_pss_rsae_sha384(0x0805), >           rsa_pss_rsae_sha512(0x0806) > > In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus > these IDs have no meaning to TLS 1.2. > > TLS 1.3 spec purposely "split" these IDs so that they have no meaning to > TLS 1.2 servers. One needs the paragraph I quoted to force > implementations to change the behavior of TLS 1.2. > > What's the harm of dropping this one paragraph I quoted and keeping TLS > 1.2 behavior the same? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue May 29 13:59: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 AF7BA12F29A for ; Tue, 29 May 2018 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 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.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 B2p3EbFOO6rT for ; Tue, 29 May 2018 13:59:09 -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 5213212ECB1 for ; Tue, 29 May 2018 13:59:07 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id c198-v6so12679907qkg.12 for ; Tue, 29 May 2018 13:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZk8jnmgKddsecDN0WJTF91ELNrb9U65pq3YjjN9Wck=; b=k9rAGcO9KGdYsxk6ZneDIs3x9aLsw1OfI23pywspht574XaweqNundXIs1o1RY9BWa 6DjvDY3Osb3lmR7JoyaKmsSoCO8rCFmngtZtri/r8mm6DvinYvIkSJ0zNdJS55EneYYO 7W5fV/XLHb1lqQKKeWHw8onzXGLDiDC4uzB30= 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=nZk8jnmgKddsecDN0WJTF91ELNrb9U65pq3YjjN9Wck=; b=LC/zWM8RrAfoNt9vu/oLJfW31d4xTPrKZC7h01RoH1iz+BnIOBdt0fLoB/cma83kup sPgQQzIwCNFeNs4TZXsvYAmYM8192Kybk53Mh0TI8wg71sVY5xRn2GHp1x9Cs/QFNgnW WH6oydxn2WC7DwxS50jMwGoMX5vp7eqTXoncqtrjS8FaDOH17OxElPzwrctkI3EZGn3W jQV5mpUso70yjX8THjLIjn5qU1ftcNxDrkBB/Pv9DFlLmsi78vDGw4lNWMi0rJJwtQig jU63eFcG2LyiP1/HT3LXok/1yZXUG8W2pMlFzsiTwvckfspM4ME8Y/ZGarnHJrt+7F9T dPzA== X-Gm-Message-State: APt69E0l3RTw5pnkFYQB97TQx0p+HtXhr6fjngtbRNXdNZagn1w3rJrJ AcnTkAjJny1LcDkrK+1mNp5P8KoXwlAWVujEaCZC5S8= X-Google-Smtp-Source: ADUXVKK+vAx3JprFag1UOEjtmx+gN6GuNKep36no0xrCPvvqicDrRr6pTek57ApExSZ238mqWk2ICL+R30a91lmBf1g= X-Received: by 2002:ae9:dc81:: with SMTP id q123-v6mr18457qkf.318.1527627545968; Tue, 29 May 2018 13:59:05 -0700 (PDT) MIME-Version: 1.0 References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> In-Reply-To: From: David Benjamin Date: Tue, 29 May 2018 16:58:53 -0400 Message-ID: To: Andrey Jivsov Cc: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003ab2e2056d5e8114" Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:59:23 -0000 --0000000000003ab2e2056d5e8114 Content-Type: text/plain; charset="UTF-8" On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov wrote: > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and this is fine. You are able to verify RSA-PSS signatures from > > the server at TLS 1.3. > > > > At the same time, you still talk to some TLS 1.2 servers, so you may get > > a response from them. As TLS 1.2 and TLS 1.3 use the same signature > > algorithms negotiation, that same ClientHello obligates your client > > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures > > from TLS 1.2. But this causes troubles somehow. > > > > I'm confused how a client would have an RSA-PSS function available at > > one version, but not the other. Or am I misunderstanding your situation? > > There is a need to upgrade TLS 1.2 stack, just because one can now > negotiate TLS 1.3. > I think this came up on the list earlier which way to go here, and folks seemed to generally prefer this one. In our implementation, we unified the TLS 1.2 and TLS 1.3 signature logic which made things simpler overall. I think this was true for most folks. > Does this "upgrade" to TLS 1.2 extends to client authentication? Then > this adds more work. > There can be a performance penalty with RSA-PSS v.s. RSA legacy and more > issues when private keys are used in client authentication (because e.g. > they are HSM keys). > The client authentication scenario seems unrelated to me. In both TLS 1.2 and TLS 1.3, there is no relation between the client's advertised signature algorithm list (which is the algorithms it will *accept* from the server) and the client's signing preferences (which control the CertificateVerify it will *send*). The latter is never even sent over the wire. As a client, you get to choose which signature algorithm you use. Offering RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does not obligate you to select it in your TLS 1.2 CertificateVerify. You select out of what the server offered in CertificateRequest. This code point allocation means the server *may* offer RSA-PSS and you *may* select it if offered. But if that is difficult for whatever reason, you also can still select PKCS#1 if the server offers it. (Of course, the server may offer you only things you can't handle, but that's not a new concern.) Chrome does just that. Our verify preferences include RSA-PSS, but our signing preferences when configured for client certificates are separate, precisely because of issues with smartcards and the like. As for the performance penalty, I think it was clearly the WG's consensus that the benefits of migrating to PSS outweighed the entropy draw and hash operations that PSS takes. > > > > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov > > wrote: > > > > On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > > > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > > >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > > >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > > >>>> Greetings. > > >>>> > > >>>> TLS 1.3 draft in sec 4.2.3. Signature Algorithms tells that if > > a client > > >>>> wants to negotiate TLS 1.3, it must support an upgraded (and > > >>>> incompatible) version of TLS 1.2, the one that changes RFC 5246 > > to allow > > >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > > >>>> > > >>>> You might recall that the possibility to negotiate between PSS > and > > >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed > > for X.509 > > >>>> signatures, was discussed on the mailing list. The WG decision > > then was > > >>>> to hard-wire PSS in the TLS 1.3 handshake. > > >>>> > > >>>> I don't recall any discussion on going further than this, all > > the way to > > >>>> changing the 10-year old TLS 1.2. > > >>>> > > >>>> Unfortunately, our products have issues with PSS beyond our > > control. The > > >>>> only solution left to avoid receiving PSS with TLS 1.2 is to > never > > >>>> negotiate TLS 1.3 as a client. Another solution is insecure > > fallback, > > >>>> but we presently don't do this. > > >>>> > > >>>> Is my reading of the situation correct? Thank you. > > >>> > > >>> Sounds like it: > > >>> > > >>> RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm > > using > > >>> RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash > > algorithm > > >>> as defined in [SHS]. These values refer solely to > signatures > > >>> which appear in certificates (see Section 4.4.2.2) and are > not > > >>> defined for use in signed TLS handshake messages, although > > they > > >>> MAY appear in "signature_algorithms" and > > >>> "signature_algorithms_cert" for backward compatibility > > with TLS > > >>> 1.2, > > >>> > > >>> -Ben > > >>> > > >> > > >> I was referring to > > >>> > > >>> - Implementations that advertise support for RSASSA-PSS > > (which is > > >>> mandatory in TLS 1.3), MUST be prepared to accept a > signature > > >>> using that scheme even when TLS 1.2 is negotiated. In TLS > > 1.2, > > >>> RSASSA-PSS is used with RSA cipher suites. > > >> > > >> I am OK with what you quoted. What I just quoted represents a > > >> significant change in behavior in TLS 1.2 and there is no way to > > opt out > > >> of this change to TLS 1.2. > > > > > > Ah, I misread your original message, but all is clear now. > > > > > >> I will add that I've seen this behavior by servers already, even > when > > >> client doesn't advertise TLS 1.3. Just the fact of including some > > 08 xx > > >> IDs in signature_algorithms in ClientHello, without > protocol_version > > >> extension, gets the TLS 1.2 upgraded to RSA-PSS. > > >> > > >> IMO this paragraph should be removed. Those that want PSS in the > > >> handshake should negotiate TLS 1.3. Preservation of current > > behavior of > > >> TLS 1.2 is important, at least as an option. > > > > > > First off, it's basically too late to make substantive changes > > like that; > > > the bar to meet is something like "a huge outcry from deployments" > or > > > "a critical security flaw". > > > > > > Second, what's going on here is that TLS 1.3 is defining some new > > signature > > > algorithms for TLS messages, and making them mandatory to support > > for TLS 1.3. > > > But negotiation of TLS signature algorithms has *always* been > > independent of > > > protocol version. If you support TLS 1.3, you also support the > > new signature > > > algorithms; if you support TLS 1.3 and TLS 1.2, you support the > > new signature > > > algorithms and you support TLS 1.2, therefore by the longstanding > > negotiation > > > rules you are obligated to support the combination. You are in > > effect proposing > > > that we make a break in the signature (and hash) algorithm space > > with individual > > > algorithms supported either in <=1.2 or >=1.3, but not both -- we > > did this for > > > ciphersuites since we fundamentally changed the meaning of what a > > ciphersuite is. > > > But the signature scheme does not seem to have undergone such a > > fundamental change, > > > so it seems hard to justify introducing this sort of split. > > > > > > -Ben > > > > > > > We are talking about TLS 1.3-specific IDs: > > > > /* RSASSA-PSS algorithms with public key OID rsaEncryption > */ > > rsa_pss_rsae_sha256(0x0804), > > rsa_pss_rsae_sha384(0x0805), > > rsa_pss_rsae_sha512(0x0806) > > > > In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus > > these IDs have no meaning to TLS 1.2. > > > > TLS 1.3 spec purposely "split" these IDs so that they have no > meaning to > > TLS 1.2 servers. One needs the paragraph I quoted to force > > implementations to change the behavior of TLS 1.2. > > > > What's the harm of dropping this one paragraph I quoted and keeping > TLS > > 1.2 behavior the same? > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --0000000000003ab2e2056d5e8114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 29= , 2018 at 4:26 PM Andrey Jivsov <= crypto@brainhub.org> wrote:
= On 05/29/2018 01:07 PM, David Benjamin wrote:
> I'm not sure I follow this. So, in this scenario, you are the clie= nt.
> You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS<= br> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from<= br> > the server at TLS 1.3.
>
> At the same time, you still talk to some TLS 1.2 servers, so you may g= et
> a response from them. As TLS 1.2 and TLS 1.3 use the same signature > algorithms negotiation, that same ClientHello obligates your client > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures > from TLS 1.2. But this causes troubles somehow.
>
> I'm confused how a client would have an RSA-PSS function available= at
> one version, but not the other. Or am I misunderstanding your situatio= n?

There is a need to upgrade TLS 1.2 stack, just because one can now
negotiate TLS 1.3.

I think this came up= on the list earlier which way to go here, and folks seemed to generally pr= efer this one. In our implementation, we unified the TLS 1.2 and TLS 1.3 si= gnature logic which made things simpler overall. I think this was true for = most folks.
=C2=A0
Does this "upgrade" to TLS 1.2 extends to client authentication? = Then
this adds more work.

There can be a performance penalty with RSA-PSS v.s. RSA legacy and more issues when private keys are used in client authentication (because e.g. they are HSM keys).

The client authenti= cation scenario seems unrelated to me. In both TLS 1.2 and TLS 1.3, there i= s no relation between the client's advertised signature algorithm list = (which is the algorithms it will *accept* from the server) and the client&#= 39;s signing preferences (which control the CertificateVerify it will *send= *). The latter is never even sent over the wire.

A= s a client, you get to choose which signature algorithm you use. Offering R= SA-PSS to the server for its TLS 1.2 ServerKeyExchange does not obligate yo= u to select it in your TLS 1.2 CertificateVerify. You select out of what th= e server offered in CertificateRequest. This code point allocation means th= e server *may* offer RSA-PSS and you *may* select it if offered. But if tha= t is difficult for whatever reason, you also can still select PKCS#1 if the= server offers it. (Of course, the server may offer you only things you can= 't handle, but that's not a new concern.)

= Chrome does just that. Our verify preferences include RSA-PSS, but our sign= ing preferences when configured for client certificates are separate, preci= sely because of issues with smartcards and the like.

As for the performance penalty, I think it was clearly the WG's cons= ensus that the benefits of migrating to PSS outweighed the entropy draw and= hash operations that PSS takes.
=C2=A0
>
> On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov <crypto@brainhub.org
> <mailto:cr= ypto@brainhub.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
>=C2=A0 =C2=A0 =C2=A0> On Tue, May 29, 2018 at 12:35:20PM -0700, Andr= ey Jivsov wrote:
>=C2=A0 =C2=A0 =C2=A0>> On 05/29/2018 12:13 PM, Benjamin Kaduk wro= te:
>=C2=A0 =C2=A0 =C2=A0>>> On Tue, May 29, 2018 at 11:57:39AM -07= 00, Andrey Jivsov wrote:
>=C2=A0 =C2=A0 =C2=A0>>>> Greetings.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> TLS 1.3 draft in sec 4.2.3.=C2=A0 = Signature Algorithms tells that if
>=C2=A0 =C2=A0 =C2=A0a client
>=C2=A0 =C2=A0 =C2=A0>>>> wants to negotiate TLS 1.3, it mus= t support an upgraded (and
>=C2=A0 =C2=A0 =C2=A0>>>> incompatible) version of TLS 1.2, = the one that changes RFC 5246
>=C2=A0 =C2=A0 =C2=A0to allow
>=C2=A0 =C2=A0 =C2=A0>>>> RSA-PSS in sec. 7.4.1.4.1. Signatu= re Algorithms.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> You might recall that the possibil= ity to negotiate between PSS and
>=C2=A0 =C2=A0 =C2=A0>>>> RSASSA-PKCS1-v1_5 in TLS 1.3 hands= hake, just as it is allowed
>=C2=A0 =C2=A0 =C2=A0for X.509
>=C2=A0 =C2=A0 =C2=A0>>>> signatures, was discussed on the m= ailing list. The WG decision
>=C2=A0 =C2=A0 =C2=A0then was
>=C2=A0 =C2=A0 =C2=A0>>>> to hard-wire PSS in the TLS 1.3 ha= ndshake.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> I don't recall any discussion = on going further than this, all
>=C2=A0 =C2=A0 =C2=A0the way to
>=C2=A0 =C2=A0 =C2=A0>>>> changing the 10-year old TLS 1.2.<= br> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Unfortunately, our products have i= ssues with PSS beyond our
>=C2=A0 =C2=A0 =C2=A0control. The
>=C2=A0 =C2=A0 =C2=A0>>>> only solution left to avoid receiv= ing PSS with TLS 1.2 is to never
>=C2=A0 =C2=A0 =C2=A0>>>> negotiate TLS 1.3 as a client. Ano= ther solution is insecure
>=C2=A0 =C2=A0 =C2=A0fallback,
>=C2=A0 =C2=A0 =C2=A0>>>> but we presently don't do this= .
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Is my reading of the situation cor= rect? Thank you.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Sounds like it:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 RSASSA-PKCS1-v1_5 algorit= hms=C2=A0 Indicates a signature algorithm
>=C2=A0 =C2=A0 =C2=A0using
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0RSASSA-PKCS1= -v1_5 [RFC8017] with the corresponding hash
>=C2=A0 =C2=A0 =C2=A0algorithm
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0as defined i= n [SHS].=C2=A0 These values refer solely to signatures
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0which appear= in certificates (see Section 4.4.2.2) and are not
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0defined for = use in signed TLS handshake messages, although
>=C2=A0 =C2=A0 =C2=A0they
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY appear i= n "signature_algorithms" and
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"signat= ure_algorithms_cert" for backward compatibility
>=C2=A0 =C2=A0 =C2=A0with TLS
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A01.2,
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> -Ben
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I was referring to
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 -=C2=A0 Implementations t= hat advertise support for RSASSA-PSS
>=C2=A0 =C2=A0 =C2=A0(which is
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory in= TLS 1.3), MUST be prepared to accept a signature
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0using that s= cheme even when TLS 1.2 is negotiated.=C2=A0 In TLS
>=C2=A0 =C2=A0 =C2=A01.2,
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0RSASSA-PSS i= s used with RSA cipher suites.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I am OK with what you quoted. What I just = quoted represents a
>=C2=A0 =C2=A0 =C2=A0>> significant change in behavior in TLS 1.2 = and there is no way to
>=C2=A0 =C2=A0 =C2=A0opt out
>=C2=A0 =C2=A0 =C2=A0>> of this change to TLS 1.2.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Ah, I misread your original message, but all i= s clear now.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> I will add that I've seen this behavio= r by servers already, even when
>=C2=A0 =C2=A0 =C2=A0>> client doesn't advertise TLS 1.3. Just= the fact of including some
>=C2=A0 =C2=A0 =C2=A008 xx
>=C2=A0 =C2=A0 =C2=A0>> IDs in signature_algorithms in ClientHello= , without protocol_version
>=C2=A0 =C2=A0 =C2=A0>> extension, gets the TLS 1.2 upgraded to RS= A-PSS.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> IMO this paragraph should be removed. Thos= e that want PSS in the
>=C2=A0 =C2=A0 =C2=A0>> handshake should negotiate TLS 1.3. Preser= vation of current
>=C2=A0 =C2=A0 =C2=A0behavior of
>=C2=A0 =C2=A0 =C2=A0>> TLS 1.2 is important, at least as an optio= n.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> First off, it's basically too late to make= substantive changes
>=C2=A0 =C2=A0 =C2=A0like that;
>=C2=A0 =C2=A0 =C2=A0> the bar to meet is something like "a huge= outcry from deployments" or
>=C2=A0 =C2=A0 =C2=A0> "a critical security flaw".
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Second, what's going on here is that TLS 1= .3 is defining some new
>=C2=A0 =C2=A0 =C2=A0signature
>=C2=A0 =C2=A0 =C2=A0> algorithms for TLS messages, and making them m= andatory to support
>=C2=A0 =C2=A0 =C2=A0for TLS 1.3.
>=C2=A0 =C2=A0 =C2=A0> But negotiation of TLS signature algorithms ha= s *always* been
>=C2=A0 =C2=A0 =C2=A0independent of
>=C2=A0 =C2=A0 =C2=A0> protocol version.=C2=A0 If you support TLS 1.3= , you also support the
>=C2=A0 =C2=A0 =C2=A0new signature
>=C2=A0 =C2=A0 =C2=A0> algorithms; if you support TLS 1.3 and TLS 1.2= , you support the
>=C2=A0 =C2=A0 =C2=A0new signature
>=C2=A0 =C2=A0 =C2=A0> algorithms and you support TLS 1.2, therefore = by the longstanding
>=C2=A0 =C2=A0 =C2=A0negotiation
>=C2=A0 =C2=A0 =C2=A0> rules you are obligated to support the combina= tion.=C2=A0 You are in
>=C2=A0 =C2=A0 =C2=A0effect proposing
>=C2=A0 =C2=A0 =C2=A0> that we make a break in the signature (and has= h) algorithm space
>=C2=A0 =C2=A0 =C2=A0with individual
>=C2=A0 =C2=A0 =C2=A0> algorithms supported either in <=3D1.2 or &= gt;=3D1.3, but not both -- we
>=C2=A0 =C2=A0 =C2=A0did this for
>=C2=A0 =C2=A0 =C2=A0> ciphersuites since we fundamentally changed th= e meaning of what a
>=C2=A0 =C2=A0 =C2=A0ciphersuite is.
>=C2=A0 =C2=A0 =C2=A0> But the signature scheme does not seem to have= undergone such a
>=C2=A0 =C2=A0 =C2=A0fundamental change,
>=C2=A0 =C2=A0 =C2=A0> so it seems hard to justify introducing this s= ort of split.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> -Ben
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0We are talking about TLS 1.3-specific IDs:
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* RSASSA-PSS alg= orithms with public key OID rsaEncryption */
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha= 256(0x0804),
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha= 384(0x0805),
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha= 512(0x0806)
>
>=C2=A0 =C2=A0 =C2=A0In TLS 1.2 08 corresponds to the (undefined) hash a= lgorithm, and thus
>=C2=A0 =C2=A0 =C2=A0these IDs have no meaning to TLS 1.2.
>
>=C2=A0 =C2=A0 =C2=A0TLS 1.3 spec purposely "split" these IDs = so that they have no meaning to
>=C2=A0 =C2=A0 =C2=A0TLS 1.2 servers. One needs the paragraph I quoted t= o force
>=C2=A0 =C2=A0 =C2=A0implementations to change the behavior of TLS 1.2.<= br> >
>=C2=A0 =C2=A0 =C2=A0What's the harm of dropping this one paragraph = I quoted and keeping TLS
>=C2=A0 =C2=A0 =C2=A01.2 behavior the same?
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0T= LS@ietf.org <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/tls
>

--0000000000003ab2e2056d5e8114-- From nobody Tue May 29 14:00: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 2CCF012E885 for ; Tue, 29 May 2018 14:00:28 -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 nHUV1NrRdyxA for ; Tue, 29 May 2018 14:00:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599BD12F281 for ; Tue, 29 May 2018 14:00:26 -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 w4TKvNND001921; Tue, 29 May 2018 22:00:19 +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=LdAFCyMaC9b+zUmv2xdohsqkgRWqWS6Vrz0lxBn1YhE=; b=Qaacm2Oe/01YuFDsXT1Tn9PweEyewpoTQ8AF6QT2KavSZam2IRBFJQjxFTE4/hWKOY+P /Xy8eO6ytuLeyIepeJqFJ3KmHOQvlFQUNbJ5haVpq2uhUUecFUlJ1afxHpnJtZa3kLZs vv6pJTTaxDlQ9Lah2Z25fJqBL5DtfiwXvkdMWTPyCsfHdM/o4qydQf+GHTHsl5+FMi2n GHl8S6WXW7C0XWhaJqwuFvLW4zUXdybHEnnF85VwJ+VtOU9MTc5onEiJ2tKNyS7L6z5Q bCGs379j7VBNtjFBCaDsmaJ733fX5Oa0vRoV+tWmFJckltnkc1Ve9yKuNUQief7Jgej4 dg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2j9cw50948-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 22:00:19 +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 w4TKtUB8007062; Tue, 29 May 2018 17:00:18 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j9cvv0bjy-1; Tue, 29 May 2018 17:00:18 -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 52CCB20068; Tue, 29 May 2018 21:00:18 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fNlj7-0005M4-EJ; Tue, 29 May 2018 16:00:17 -0500 Date: Tue, 29 May 2018 16:00:17 -0500 From: Benjamin Kaduk To: Andrey Jivsov Cc: David Benjamin , "tls@ietf.org" Message-ID: <20180529210017.GM13834@akamai.com> References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.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) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290221 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_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-1805220000 definitions=main-1805290221 Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 21:00:36 -0000 On Tue, May 29, 2018 at 01:26:27PM -0700, Andrey Jivsov wrote: > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and this is fine. You are able to verify RSA-PSS signatures from > > the server at TLS 1.3. > > > > At the same time, you still talk to some TLS 1.2 servers, so you may get > > a response from them. As TLS 1.2 and TLS 1.3 use the same signature > > algorithms negotiation, that same ClientHello obligates your client > > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures > > from TLS 1.2. But this causes troubles somehow. > > > > I'm confused how a client would have an RSA-PSS function available at > > one version, but not the other. Or am I misunderstanding your situation? > > There is a need to upgrade TLS 1.2 stack, just because one can now > negotiate TLS 1.3. > > Does this "upgrade" to TLS 1.2 extends to client authentication? Then > this adds more work. In short: no. CertificateRequest/CertificateVerify have a separate signature+hash negotiation from the initial handshake, and the server is highly unlikely to only list the new signature schemes. (And I think you could decline the authentication in that case anyway, but didn't double-check.) The answer could also be "yes" in that if both sides *want* to, it can be done for client authentication, but in your case you don't want to and are not obligated to do so. -Ben > There can be a performance penalty with RSA-PSS v.s. RSA legacy and more > issues when private keys are used in client authentication (because e.g. > they are HSM keys). From nobody Tue May 29 14:19: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 9373412E054 for ; Tue, 29 May 2018 14:19:27 -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, 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=brainhub-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cw6mWaiWK9d for ; Tue, 29 May 2018 14:19:24 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 4ADE112DA6A for ; Tue, 29 May 2018 14:19:24 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id 30-v6so9674821pld.13 for ; Tue, 29 May 2018 14:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainhub-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GC5hq0Cqoer7K+6xwHxeJLE+QOosCfTP+EOv5nmMReY=; b=l2YEDMCWQHMwE6Z4XTEso2a7OOm2zEHZQdeYDyxaxMl9mECkxGmgQcQsctKjEJC/nS l4Z9WOdKF76QCgoIrg6wUzBhLzpO+dxLL1kUM0iw2z1Sxk9lVapWNt8npg77z9fK8DDE J5YfgEURdwWdJkBzrETh6o4UKsxzZLk4Df/GrYDonSLVJj1wZqV/BzppGoBFRpfxPTM3 8R/xGcL6zE5tBqZ63NFTz0awJaE8z9Dm9+/XfPyljQPbq99m4X8KbE3/u03yLx6MCq2D bnucT1+1EzuHdY8wa8MGoXlKc0NpdDiJgmM2qsGiRspk+5yqGcmF+mAA3F4gurTmA8+3 SxpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GC5hq0Cqoer7K+6xwHxeJLE+QOosCfTP+EOv5nmMReY=; b=Cbupgen4d4RUjflrRDuBzFNGmXI3oHufxGukqXFyunl4uEeHf/Cj13N1kKS5Zyx/Pw u2H5zxiKDZxGG4hPlOMVZwZ30CPuNPtGueS9SJ/wk77ktWv9/leY80ZcOLYBBfFPV0No SS+C5sV17S59lBVjzNqnS/5xR8yq1JFfd/RIGNGuh9z862qrJ5jctv3Zxyjkoypqubyl 35rWig1gtOs+44knukmK/rbuLDFhZW2y9oQQEHYj5XbbS7E8fu/CgUgnbhEegaUnUIa4 O9tjo30t3mEaXka/aIHEhJPeL2740K0waLSP1XjxfmplhaEV6Hv7he6SrhqFIjkl1UQ7 wdxQ== X-Gm-Message-State: ALKqPwchVsOMvpE7V0r6j5YNZ2RL/TmYUUcrVz2mQqTX75Yii083wlaC 868sFauMoe+czZuz9t2Y4LJe0s6F X-Google-Smtp-Source: ADUXVKKOU2E6r/dOPZ2pplu/3/0sVgfIi1gvw2EIdY1t9ZrFodYSuk9MA8B8wUSL1rLCYDZJNd5FpQ== X-Received: by 2002:a17:902:9a4c:: with SMTP id x12-v6mr55805plv.213.1527628763285; Tue, 29 May 2018 14:19:23 -0700 (PDT) Received: from [192.168.86.104] ([104.219.107.83]) by smtp.googlemail.com with ESMTPSA id q69-v6sm23013260pfl.16.2018.05.29.14.19.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 14:19:22 -0700 (PDT) Sender: Andrey To: David Benjamin Cc: Benjamin Kaduk , "tls@ietf.org" References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> From: Andrey Jivsov Message-ID: <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> Date: Tue, 29 May 2018 14:19:21 -0700 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] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 21:19:28 -0000 On 05/29/2018 01:58 PM, David Benjamin wrote: > On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov > wrote: > > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and this is fine. You are able to verify RSA-PSS signatures from > > the server at TLS 1.3. > > > > At the same time, you still talk to some TLS 1.2 servers, so you > may get > > a response from them. As TLS 1.2 and TLS 1.3 use the same signature > > algorithms negotiation, that same ClientHello obligates your client > > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures > > from TLS 1.2. But this causes troubles somehow. > > > > I'm confused how a client would have an RSA-PSS function available at > > one version, but not the other. Or am I misunderstanding your > situation? > > There is a need to upgrade TLS 1.2 stack, just because one can now > negotiate TLS 1.3. > > > I think this came up on the list earlier which way to go here, and folks > seemed to generally prefer this one. In our implementation, we unified > the TLS 1.2 and TLS 1.3 signature logic which made things simpler > overall. I think this was true for most folks. >   > > Does this "upgrade" to TLS 1.2 extends to client authentication? Then > this adds more work. > > > There can be a performance penalty with RSA-PSS v.s. RSA legacy and more > issues when private keys are used in client authentication (because e.g. > they are HSM keys). > > > The client authentication scenario seems unrelated to me. In both TLS > 1.2 and TLS 1.3, there is no relation between the client's advertised > signature algorithm list (which is the algorithms it will *accept* from > the server) and the client's signing preferences (which control the > CertificateVerify it will *send*). The latter is never even sent over > the wire. > > As a client, you get to choose which signature algorithm you use. > Offering RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does > not obligate you to select it in your TLS 1.2 CertificateVerify. You > select out of what the server offered in CertificateRequest. This code > point allocation means the server *may* offer RSA-PSS and you *may* > select it if offered. But if that is difficult for whatever reason, you > also can still select PKCS#1 if the server offers it. (Of course, the > server may offer you only things you can't handle, but that's not a new > concern.) OK. We don't know, though, what will happen in practice with TLS 1.2 CertificateRequest if the server upgraded TLS 1.2 ServerKeyExchange. Will it be more likely that the choices in CertificateRequest will be narrower? > > Chrome does just that. Our verify preferences include RSA-PSS, but our > signing preferences when configured for client certificates are > separate, precisely because of issues with smartcards and the like. > > As for the performance penalty, I think it was clearly the WG's > consensus that the benefits of migrating to PSS outweighed the entropy > draw and hash operations that PSS takes. The issue here is that some hardware devices don't implement RSA CRT method with PSS, because they hard-wide RSA, legacy padding, and CRT method in one operation. RSA PSS can still be done, but only via a general modexp operation, which will be ~2x shower. Therefore, in these scenarios PSS incurs 2x performance penalty. ( Maybe RSA verification should be done on CPU, but this will require changes to TLS 1.2 code. ) The limitations are similar to what you wrote about smartcards. There are some odd hardware limitations. That hardware was just fine years ago with TLS 1.2. Higher entropy consumption is negligible here. >   > > > > > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov > > >> wrote: > > > >     On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > >     > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: > >     >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > >     >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: > >     >>>> Greetings. > >     >>>> > >     >>>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells > that if > >     a client > >     >>>> wants to negotiate TLS 1.3, it must support an upgraded (and > >     >>>> incompatible) version of TLS 1.2, the one that changes > RFC 5246 > >     to allow > >     >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. > >     >>>> > >     >>>> You might recall that the possibility to negotiate > between PSS and > >     >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed > >     for X.509 > >     >>>> signatures, was discussed on the mailing list. The WG > decision > >     then was > >     >>>> to hard-wire PSS in the TLS 1.3 handshake. > >     >>>> > >     >>>> I don't recall any discussion on going further than this, all > >     the way to > >     >>>> changing the 10-year old TLS 1.2. > >     >>>> > >     >>>> Unfortunately, our products have issues with PSS beyond our > >     control. The > >     >>>> only solution left to avoid receiving PSS with TLS 1.2 is > to never > >     >>>> negotiate TLS 1.3 as a client. Another solution is insecure > >     fallback, > >     >>>> but we presently don't do this. > >     >>>> > >     >>>> Is my reading of the situation correct? Thank you. > >     >>> > >     >>> Sounds like it: > >     >>> > >     >>>    RSASSA-PKCS1-v1_5 algorithms  Indicates a signature > algorithm > >     using > >     >>>       RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash > >     algorithm > >     >>>       as defined in [SHS].  These values refer solely to > signatures > >     >>>       which appear in certificates (see Section 4.4.2.2) > and are not > >     >>>       defined for use in signed TLS handshake messages, > although > >     they > >     >>>       MAY appear in "signature_algorithms" and > >     >>>       "signature_algorithms_cert" for backward compatibility > >     with TLS > >     >>>       1.2, > >     >>> > >     >>> -Ben > >     >>> > >     >> > >     >> I was referring to > >     >>> > >     >>>    -  Implementations that advertise support for RSASSA-PSS > >     (which is > >     >>>       mandatory in TLS 1.3), MUST be prepared to accept a > signature > >     >>>       using that scheme even when TLS 1.2 is negotiated.  > In TLS > >     1.2, > >     >>>       RSASSA-PSS is used with RSA cipher suites. > >     >> > >     >> I am OK with what you quoted. What I just quoted represents a > >     >> significant change in behavior in TLS 1.2 and there is no > way to > >     opt out > >     >> of this change to TLS 1.2. > >     > > >     > Ah, I misread your original message, but all is clear now. > >     > > >     >> I will add that I've seen this behavior by servers already, > even when > >     >> client doesn't advertise TLS 1.3. Just the fact of > including some > >     08 xx > >     >> IDs in signature_algorithms in ClientHello, without > protocol_version > >     >> extension, gets the TLS 1.2 upgraded to RSA-PSS. > >     >> > >     >> IMO this paragraph should be removed. Those that want PSS > in the > >     >> handshake should negotiate TLS 1.3. Preservation of current > >     behavior of > >     >> TLS 1.2 is important, at least as an option. > >     > > >     > First off, it's basically too late to make substantive changes > >     like that; > >     > the bar to meet is something like "a huge outcry from > deployments" or > >     > "a critical security flaw". > >     > > >     > Second, what's going on here is that TLS 1.3 is defining > some new > >     signature > >     > algorithms for TLS messages, and making them mandatory to > support > >     for TLS 1.3. > >     > But negotiation of TLS signature algorithms has *always* been > >     independent of > >     > protocol version.  If you support TLS 1.3, you also support the > >     new signature > >     > algorithms; if you support TLS 1.3 and TLS 1.2, you support the > >     new signature > >     > algorithms and you support TLS 1.2, therefore by the > longstanding > >     negotiation > >     > rules you are obligated to support the combination.  You are in > >     effect proposing > >     > that we make a break in the signature (and hash) algorithm space > >     with individual > >     > algorithms supported either in <=1.2 or >=1.3, but not both > -- we > >     did this for > >     > ciphersuites since we fundamentally changed the meaning of > what a > >     ciphersuite is. > >     > But the signature scheme does not seem to have undergone such a > >     fundamental change, > >     > so it seems hard to justify introducing this sort of split. > >     > > >     > -Ben > >     > > > > >     We are talking about TLS 1.3-specific IDs: > > > >              /* RSASSA-PSS algorithms with public key OID > rsaEncryption */ > >               rsa_pss_rsae_sha256(0x0804), > >               rsa_pss_rsae_sha384(0x0805), > >               rsa_pss_rsae_sha512(0x0806) > > > >     In TLS 1.2 08 corresponds to the (undefined) hash algorithm, > and thus > >     these IDs have no meaning to TLS 1.2. > > > >     TLS 1.3 spec purposely "split" these IDs so that they have no > meaning to > >     TLS 1.2 servers. One needs the paragraph I quoted to force > >     implementations to change the behavior of TLS 1.2. > > > >     What's the harm of dropping this one paragraph I quoted and > keeping TLS > >     1.2 behavior the same? > > > >     _______________________________________________ > >     TLS mailing list > >     TLS@ietf.org > > >     https://www.ietf.org/mailman/listinfo/tls > > > From nobody Tue May 29 16:28:28 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 D189012ECAE; Tue, 29 May 2018 16:28:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-tls-record-limit@ietf.org, tls-chairs@ietf.org, Sean Turner , tls@ietf.org, rfc-editor@rfc-editor.org, sean@sn3rd.com, kaduk@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <152763649885.27992.13984208390274537372.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2018 16:28:18 -0700 Archived-At: Subject: [TLS] Protocol Action: 'Record Size Limit Extension for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-record-limit-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: Tue, 29 May 2018 23:28:19 -0000 The IESG has approved the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' (draft-ietf-tls-record-limit-03.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ Technical Summary This draft defines a TLS extension to negotiate the maximum size of protected records that each peers sends. This mechanism replaces the maximum fragment length extension defined in RFC 6066. It’s standards track because it updates RFC 6066, which is a Proposed Standard. Working Group Summary The draft was very well received by the WG, resulting in minimal, minor comments. Unlike other TLS-related topics, this WG settled on a solution quickly and consensus was very easily found. Document Quality This document received careful review from several participants, including pointing out some subtle edge cases and differences between TLS 1.2 and TLS 1.3 that got resolved in the document. Personnel Sean Turner is the document shepherd. Benjamin Kaduk is the responsible Area Director. RFC Editor Note Two late-breaking changes, both in Section 1: OLD Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] constrained devices can be challenging. However, NEW Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] for constrained devices can be challenging. However, OLD authenticated data until the entire record is present. Incremental processing of records could expose endpoints to the risk of forged data. NEW authenticated data until the entire record is present. Incremental processing of records exposes endpoints to the risk of forged data. From nobody Tue May 29 18:06: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 D042C12FB33 for ; Tue, 29 May 2018 18:06:00 -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 Vi37nAj8rorx for ; Tue, 29 May 2018 18:05:58 -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 9FBE512FB30 for ; Tue, 29 May 2018 18:05:58 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 77-v6so19218733otd.4 for ; Tue, 29 May 2018 18:05:58 -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:content-transfer-encoding; bh=wAGETtkbZo30XwuwGDHGSraXOA1RNITYvjRApmu3kXQ=; b=VGoy63QJphxGIt46yofg81P9O2DkKzh1Fx0m5rCSowlioQ88Qs0XI0U5R9raQDCuPo dAMC68Xp0x1qYF/QF3Z2dtcngouJIGaFyhhciF/g1JHkKkOcvzUZwp6CVISyncjjTdnb byn0Vg7u9mjyY+eWLM4tuDE8DNpaGyi0ullPAB4ldoPvwLx9u9+Bcu/LQHR5IEsb7XSq ryA/5DSDWlAMSO/zb8kRXzFKKvQZVYygPurh3urwHIFQPuUHgFbFY1lhGDvb7hPq7iiG dXRiOJspfvMQ9jzH5symw38jqykemJ1eLKuqnCmZRfARvSt1gvjd7l66C8tbBOTBgQBP UTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wAGETtkbZo30XwuwGDHGSraXOA1RNITYvjRApmu3kXQ=; b=kZX1ixzBssbZfN0SKZEcGYgQaHi38hQ5WA64RrmAWyhuCLZ+pPNK+H2F0uJwDO3bOn JnZATbgY764VLdpotvG4Z7D/6Rs8N5idrv8sgUxFGhWDBMMcXd6a2VjHKIQc/D1giqCI aBls4k7YwtRqbJ7hsVb6gw4NaohlKQr7x+EfUICIlKfUx2Ok0X65QY54gy/Q4PRRCrmm g4mNRTuXPmbisaF+zGZxUgS+DHnxfe/FhdDn8ixVCFXolIMrObQI5zE1FSQQ+RUpsIkW V9U1k+3WQVOU90kO6k/w0GRC4118AceNYfNCPR+r4+XVMHvpPkRtWjlC2ZqFlrOHuSpE LWow== X-Gm-Message-State: ALKqPwe3U1sU/WpxNerR1W+225Sg5SG8nuUx/UjT9rJgh1Gi1nVSxkUP nEzGvaQlK9ROZkn5WPn6h2i7GYDdNTQmXvPv6Og= X-Google-Smtp-Source: ADUXVKIvT3nL0lNMw72Qg0EgzB9YUcT/rQQxi/Ojbderl8Jptl2Qa3kWEzMlKclhz0ssPb3P6JNL+f3q9w4s4dCyltc= X-Received: by 2002:a9d:3637:: with SMTP id w52-v6mr420747otb.394.1527642357921; Tue, 29 May 2018 18:05:57 -0700 (PDT) MIME-Version: 1.0 References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> <742B3DCC-6AF4-48DB-82F9-760DEF7E52F4@sn3rd.com> In-Reply-To: <742B3DCC-6AF4-48DB-82F9-760DEF7E52F4@sn3rd.com> From: Martin Thomson Date: Wed, 30 May 2018 11:05:48 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 May 2018 01:06:01 -0000 The thought occurs, do you want a version with the final version number in it? I see that TLS 1.3 is in front of the RFC editor right now, so I don't anticipate any changes and changing the examples creates a lot of churn (check out the diffs on this draft to get an idea). On Wed, May 30, 2018 at 12:35 AM Sean Turner wrote: > > On May 8, 2018, at 20:30, Martin Thomson wrote: > > > > On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: > >> I dislike standard, and am fine with Informational or BCP. > > > > Agree regarding standard. > > > > I don't understand why BCP would be used for this. Besides, we probabl= y > > don't want to enshrine some of the choices we made in NSS as "best > > practice". I'm not saying that those choices aren't defensible, but that > > might be going too far. > Since this draft is really about =E2=80=9Cexamples=E2=80=9D (i.e., it=E2= =80=99s just for illustration), I=E2=80=99m going to suggest that Martin go ahead and merge = the following PR that I submitted changing the intended status: > https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6 > Once a new version is spun, I=E2=80=99ll push the draft toward Ben. > spt From nobody Tue May 29 18:15: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 33F2D12D94C; Tue, 29 May 2018 18:15:50 -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 2AYPjQi_Ldvk; Tue, 29 May 2018 18:15:48 -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 C510212EB26; Tue, 29 May 2018 18:15:48 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t133-v6so11248603oif.10; Tue, 29 May 2018 18:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tUpGfW/MU35WUCS9pbHINvgbK7nX9KHho+Uy+TQVzzs=; b=FcuNjFIOIbZhDubaoe7tYwymMdLg59n89YVxxzlNHNVtkFG3rxHxDwcxjKx6Q5qJQW 2sPnBIEW1yNbbgrybc0zsvAFJnNL31KCNTOP1ZNCsmfRklg7ON6sgSN8MuqH3tY2GioH 8fPitMowGL7OXkQvzRCQOcLixajnDPQ+FtbkytPr7iWPO30SSgaRk2LQeB6r1aWxpXk0 6abrm9AflfDSONgTrNlMibsF5aFNVzC72GBOLs0z8eGxEiDZjbeCoRgg6o4ZWEcEzY6H 7W5vS6JaAPCm7pDorE3hX4Q/ZTf1R7p98B05o2heBpGGQGB95KViBFZ7nqNxXgF/SYS6 92Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=tUpGfW/MU35WUCS9pbHINvgbK7nX9KHho+Uy+TQVzzs=; b=uKmM+yU7xtUxbkrhLJQun9FhjjHqA8iwGWwL94BmUgkHg8xY31OglZfNwb0LUwFDBM FiuZV4oTX0Wb+SorcAprVuKw8iRNN8Za1k3LyyYW6eyv2kZXDWIaK+/rPClNIFz0//L0 kcn/onRwPyXu+xlvTIWCNRng8gAW9zP4qe3ef3m0hjk+29sNOWt6a9wQjpxdlhmMnieo OC83XODB302YQLDgkndU1JemcIVkqQKwMqkmi69ni40qP76lPWR3YZWEuMZexePQxEqe F2GAHONDok6GJzTos7g96g3gma8qWJMOSSOApqY6dXBkFxrlSV2YLnyu2HS9CKV7zr65 qyHQ== X-Gm-Message-State: APt69E3jAItILLaRE3oZCA1y9QcxiWsloQKFriW/OmNinnSgsc2VxpdE C6/QfFyXGlyBlNn/5HxnuqVbgSpZmz3kMWOcgZs= X-Google-Smtp-Source: ADUXVKKbfRro9QlVmyOfOZNiwoVPvgrquEvKh4JUT4ECvfw/WXBu2JKCqTW+pEeFJe1NMfNM6QNeDHNrfr2oSG+70WI= X-Received: by 2002:aca:4dca:: with SMTP id a193-v6mr358567oib.259.1527642948276; Tue, 29 May 2018 18:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:901a:0:0:0:0:0 with HTTP; Tue, 29 May 2018 18:15:47 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> From: Jeffrey Walton Date: Tue, 29 May 2018 21:15:47 -0400 Message-ID: To: "Salz, Rich" Cc: Benjamin Kaduk , Peter Gutmann , "tls@ietf.org" , "tls-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 30 May 2018 01:15:50 -0000 On Tue, May 29, 2018 at 4:21 PM, Salz, Rich wrote: >> There's a tradeoff between respecting the official allocation processes > and avoiding real-world breakage. I think we can all make our own assessments > on the former, but for the latter, all the evidence we have so far is a claim > from Peter that there exists software that hardcodes this number, with no > indication of scale of deployment or ease of updating such software. > > Peter tried very hard to play by all the rules, whether they were enshrined in formal documents, or "just" decisions by WG chairs, and everything in-between. > > Peter says the number is in use. > > I believe him. > > Give him the damn number. +1. I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers working group for their smart locks last year. I have no idea how much of the code they are going to reuse (if any at all). Jeff From nobody Tue May 29 18: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 76DC912FAC9 for ; Tue, 29 May 2018 18:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvsQBn_zwrKc for ; Tue, 29 May 2018 18:17:32 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852E312EBA0 for ; Tue, 29 May 2018 18:17:32 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l22-v6so7118458oib.4 for ; Tue, 29 May 2018 18:17:32 -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=jQkj7DLGdaydjodcx9W3pGCZyajYM6L4YStlLneuM00=; b=sX98jayUtw5mZeQuXmJwtZb8OUSoEGPrpOqcy3px8OulvkWUBtgkR7O7pvnfKuDDyD zMPSeonlBUoCRIZzHCg7dn1oSmaf0n9NHAs3OWJrsRpwhWtCTqynpDCxRrlvRPVZjYzi syxToW8bAylpuC+Q1bhKUshQW4CRyflHQPTGmX5lH91nu0BuNgH8m3bkuCN1kbzuTQB+ NDuYcjHejfNCGGgm4pY+ZIN6ZgrYorvLIcN2QOjc3T0brOik5BRNkvWrfhT7JPvN2eSV dFBAWSXxdTXo56XjxRI07m5+SB1oHnuV/YUcsytOdgZsHvYBIRsXzJpzmXeJ4yPjVn8R Xzuw== 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=jQkj7DLGdaydjodcx9W3pGCZyajYM6L4YStlLneuM00=; b=QgDWc0rJTRD1YB5BSwFC2dQws33HoX+DzspNoBS+4ZY+oWnYBl+angzLVkz29f8qFe EzMNCPXq9/nOCy26iIiriHhE/O5u39qk2KZTQSY/32C48HeZWUn0/GFDJKg3uZgFSDws TmWqBnY8qRK74GWU20OAluZerlpyhyT71Al0wfsy1a5oPvMMsnZcYTpPyjRNx8Jgij4y S92KHh6q3ebbD8ZeGUg1njCC+H8OPMYVf4wN28F4WOlcWAHh4As6Xn4aZrRS99x/BumJ oaz5F6ySu/RFNN3zm6fMnb3zp1ArPSd/Uu4bxhgQmPKWJhUkitHTBTjF31v4088mHOnw VPtA== X-Gm-Message-State: ALKqPwcHM65LRKCBUsYoXkeBK/F9rA37fAGWhB7jWMH7VWWnzbTNXFOA +Y1HeUSRrWbFzCD3A3ShD90Z/lzPdEXdyHN7OOY= X-Google-Smtp-Source: ADUXVKK0zGxfb1ANr9lP3BTERtJ03jcWTcIZqd1O/e977z/wkZHE6yDttmkb3lBgDGBDmrafbLPJ998W7pI58sruzec= X-Received: by 2002:aca:3905:: with SMTP id g5-v6mr405685oia.215.1527643051746; Tue, 29 May 2018 18:17:31 -0700 (PDT) MIME-Version: 1.0 References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> In-Reply-To: <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> From: Martin Thomson Date: Wed, 30 May 2018 11:17:21 +1000 Message-ID: To: Andrey Jivsov Cc: David Benjamin , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:17:42 -0000 On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov wrote: > The issue here is that some hardware devices don't implement RSA CRT > method with PSS, because they hard-wide RSA, legacy padding, and CRT > method in one operation. RSA PSS can still be done, but only via a > general modexp operation, which will be ~2x shower. Therefore, in these > scenarios PSS incurs 2x performance penalty. I'm fairly certain that we've had this discussion before. What is new? From nobody Tue May 29 18:22: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 380DA12D7F2 for ; Tue, 29 May 2018 18:22:31 -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 w53duNwzarwt for ; Tue, 29 May 2018 18:22:28 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C43E12E04A for ; Tue, 29 May 2018 18:22:28 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f13-v6so21245386qtp.10 for ; Tue, 29 May 2018 18:22:28 -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=8MKQC+rlVvA6Nf8lFxC6kmZlSXz+KoWP9BH1PG0OKuU=; b=m2YEr6gk9PONBtVE7h2TVEqHjuSG3TNv7J8Tw+7Uq+mVDLhNwYj1xMnBkjAQhpWEb2 TgNQTK8mOfaW+j9X/wJvZRydT3LQJdFTXz0l188nOqITf4QufSmCBSzBTzAAkVfjxswc UbyC+MzqAqM2PxGxMVL8JNls/KNVn+k1+NXmc= 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=8MKQC+rlVvA6Nf8lFxC6kmZlSXz+KoWP9BH1PG0OKuU=; b=P4SG9OCoI2mMk24MXeby85XOwANgEUEwfWO1DWq2XS3aj73cO8v5yy8iQjvmSDPti5 I91lFH8oTyju/G2xqbSL6CyfYy8mnWMKFAOmtRGI47sr+RVi7lDLMwZaxt+wkpxSF3I2 Zmo62NmFcLph156KnwwdR3XdYtIrcLALWAJB9Bm3EyEvWIajtcVJf6mQ14T+3n1urMrW kSmWg0ew6vpI7fDrrWHDJhNPn6ru2gPV7gffOGCplr1Hef9qugdU6nMu/tv7FFAlz/1h BZqWqvqUD+I42eZwBIR6cda/b26OgeBJNLhgPSXQ4JDM7mg1LCUXroyiftUXZKtL5X+p FXtg== X-Gm-Message-State: APt69E3edY1YT9TZo/sbRMiYIV4nNncZ6i14DMr64a4o8ZWWBcx/rjRe +5GRRg72MRZjevc0oMGQWePCSw== X-Google-Smtp-Source: ADUXVKIkACwdjbpta3c2eQEvZPgN9QcY2N8JjE7g+5qinmGplBJWe9n23TNzqJCYPg+VIYTPOzs+5w== X-Received: by 2002:a0c:c924:: with SMTP id r33-v6mr680313qvj.79.1527643347789; Tue, 29 May 2018 18:22:27 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id t6-v6sm5241827qtn.86.2018.05.29.18.22.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 18:22:27 -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: Tue, 29 May 2018 21:22:26 -0400 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <72905ABB-0709-4AE7-86D3-5492177377B4@sn3rd.com> References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> <742B3DCC-6AF4-48DB-82F9-760DEF7E52F4@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 May 2018 01:22:31 -0000 I think changing the Intended Status is all we=E2=80=99re looking. spt > On May 29, 2018, at 21:05, Martin Thomson = wrote: >=20 > The thought occurs, do you want a version with the final version = number in > it? I see that TLS 1.3 is in front of the RFC editor right now, so I = don't > anticipate any changes and changing the examples creates a lot of = churn > (check out the diffs on this draft to get an idea). > On Wed, May 30, 2018 at 12:35 AM Sean Turner wrote: >=20 >=20 >=20 >>> On May 8, 2018, at 20:30, Martin Thomson > wrote: >>>=20 >>> On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: >>>> I dislike standard, and am fine with Informational or BCP. >>>=20 >>> Agree regarding standard. >>>=20 >>> I don't understand why BCP would be used for this. Besides, we = probably >>> don't want to enshrine some of the choices we made in NSS as "best >>> practice". I'm not saying that those choices aren't defensible, but > that >>> might be going too far. >=20 >> Since this draft is really about =E2=80=9Cexamples=E2=80=9D (i.e., = it=E2=80=99s just for > illustration), I=E2=80=99m going to suggest that Martin go ahead and = merge the > following PR that I submitted changing the intended status: >> https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6 >=20 >> Once a new version is spun, I=E2=80=99ll push the draft toward Ben. >=20 >> spt From nobody Tue May 29 18:27: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 A087512DA4A for ; Tue, 29 May 2018 18:27:04 -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 zLqg2ZVo_e0R for ; Tue, 29 May 2018 18:27:02 -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 6434C12DA27 for ; Tue, 29 May 2018 18:27:02 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i5-v6so19282084otf.1 for ; Tue, 29 May 2018 18:27:02 -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:content-transfer-encoding; bh=lXn3G6KFyG+wxI8lKU2/lXCmJRLese/7K7dBez/hyTc=; b=RXz1DBaDTaAt6ML3o5fliIVL4oBEjQJ0l/BKFNnI6go42T9z7K5QmbtviK2kB8iUJQ 3wQ326RaETvRAHeJ7Mo4I6up4oUttm8Nysvalk0O/ZsClaC2bohB91W31QgwsetY/7No 0Z0Y6GwvaUAT6kzliayq00dhUhHwjhSnHrQDb1w1Z29r4PeRfynGv3WpKgKJEnmpCxeD l4gxvCVwzDiv6C7uwhV7GULSCGAUXc2Bo2Wk5R1oKkm2YjJ5LveMLDs1zRMRjpZb3ez6 mt3z3swEaz0I1ioTJab6VcvGTyWxMoTNgdarNxyP8JSxyjcV6U184ZCMSw4ERZoc9m1G eUow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lXn3G6KFyG+wxI8lKU2/lXCmJRLese/7K7dBez/hyTc=; b=Zf+4PUPNlklEe8VNzW7eGnDGiQdCy7+fj1rjTUB5M1yxdieI2WAyBimOAALrdT5LTx VEGkVcp3C4pFX0Th9j8/JVqRJV2UizdkrYCLlT9D2V5DT1GUNk2uqs0Hy5QW0UYxX+1H u5JWd21fGKSuQWMhFSfaW9PNVHp+ZUeqs2XrNj1BOiF3KGaqFRH7EjyKEE/9IceDWYMr Jb1onPFvyZZQeRQ/2U1U3fH5hwo6vgJxf9VTVDUh88gBD7arC8dv/H0kwIWqwVznBVrl lT63DsNspqXjUAViGSd/cyWGjk6jVJ4NXaV6d3aNlUnqY/PeAgUyQc76RfXbsHvA+Ojl 1ohg== X-Gm-Message-State: ALKqPwfF/XWySfhM25nfwJDL9HqqKJMReJhpchfy6xKk9WF9c5m187in ZEY0WwXIzHOh4BnL7B3NDdelSQgz37ecCZFO+wSFFA== X-Google-Smtp-Source: ADUXVKKR4TugQSU2Qml72C6cyk98XBwnRCTI4LgomfU5ywQIfU5bWCJWsaZK0fLHLf3nNsORAJF8SBp62yhViwyr574= X-Received: by 2002:a9d:34f1:: with SMTP id t46-v6mr441189otd.396.1527643621701; Tue, 29 May 2018 18:27:01 -0700 (PDT) MIME-Version: 1.0 References: <5F30CC9E-EFFC-4A36-801F-A17B9DDF85E0@sn3rd.com> <1334EA4C-9432-49E4-9DC4-DEEDF1C3C0AF@akamai.com> <742B3DCC-6AF4-48DB-82F9-760DEF7E52F4@sn3rd.com> <72905ABB-0709-4AE7-86D3-5492177377B4@sn3rd.com> In-Reply-To: <72905ABB-0709-4AE7-86D3-5492177377B4@sn3rd.com> From: Martin Thomson Date: Wed, 30 May 2018 11:26:52 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 May 2018 01:27:05 -0000 Ack, that makes it easier for me :) On Wed, May 30, 2018 at 11:22 AM Sean Turner wrote: > I think changing the Intended Status is all we=E2=80=99re looking. > spt > > On May 29, 2018, at 21:05, Martin Thomson wrote: > > > > The thought occurs, do you want a version with the final version number in > > it? I see that TLS 1.3 is in front of the RFC editor right now, so I don't > > anticipate any changes and changing the examples creates a lot of churn > > (check out the diffs on this draft to get an idea). > > On Wed, May 30, 2018 at 12:35 AM Sean Turner wrote: > > > > > > > >>> On May 8, 2018, at 20:30, Martin Thomson > > wrote: > >>> > >>> On Wed, May 9, 2018 at 2:56 AM Salz, Rich wrote: > >>>> I dislike standard, and am fine with Informational or BCP. > >>> > >>> Agree regarding standard. > >>> > >>> I don't understand why BCP would be used for this. Besides, we probably > >>> don't want to enshrine some of the choices we made in NSS as "best > >>> practice". I'm not saying that those choices aren't defensible, but > > that > >>> might be going too far. > > > >> Since this draft is really about =E2=80=9Cexamples=E2=80=9D (i.e., it= =E2=80=99s just for > > illustration), I=E2=80=99m going to suggest that Martin go ahead and me= rge the > > following PR that I submitted changing the intended status: > >> https://github.com/tlswg/draft-ietf-tls-tls13-vectors/pull/6 > > > >> Once a new version is spun, I=E2=80=99ll push the draft toward Ben. > > > >> spt From nobody Tue May 29 18:52:08 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 4FAE312E058; Tue, 29 May 2018 18:52:06 -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.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152764512626.27870.15662518088113053700@ietfa.amsl.com> Date: Tue, 29 May 2018 18:52:06 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-05.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: Wed, 30 May 2018 01:52:07 -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 : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename : draft-ietf-tls-tls13-vectors-05.txt Pages : 60 Date : 2018-05-29 Abstract: Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and ivs are shown so that implementations might be checked incrementally against these values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 29 19:01:26 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 DFCAD12FAB1; Tue, 29 May 2018 19:01:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <152764568491.27703.7252786909680312817.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2018 19:01:24 -0700 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-tls13-vectors-05 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, 30 May 2018 02:01:25 -0000 Sean Turner has requested publication of draft-ietf-tls-tls13-vectors-05 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ From nobody Tue May 29 21: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 4FB7312DA3D for ; Tue, 29 May 2018 21:53:56 -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 Q6Tw92mrKtLE for ; Tue, 29 May 2018 21:53:54 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 070C61271FD for ; Tue, 29 May 2018 21:53:52 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with ESMTP id Nt64fqCdgRNLYNt7QfTExK; Wed, 30 May 2018 04:53:52 +0000 Received: from [192.168.0.10] ([73.222.32.57]) by resomta-po-20v.sys.comcast.net with ESMTPSA id Nt7Of4ihFfXTANt7PfGuht; Wed, 30 May 2018 04:53:52 +0000 To: Martin Thomson Cc: David Benjamin , "" References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> From: Andrey Jivsov Message-ID: <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org> Date: Tue, 29 May 2018 21:53:50 -0700 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: 7bit X-CMAE-Envelope: MS4wfO5WLQtb5z7INGWGKl+reS7UlEQhooVDVTaU2RLnUtXLZciLjpdv9u+X13smudKgjuJBFF31JKaJmoA/mIUEC2lGxKp1JTckuU3WOdUfjKLnYJjjZHBi U27a/MC/0zvA5HK1qdtipifOvEj4lhpJ3fJWx+iiF20P3Nt64ZwvtIQtL1Ihndr7GL4C/XTjnQYvu2a5lbJ/lBKxxEALsv3JYfBdL6BW4Tg524RNFkPs/C5q Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 04:53:56 -0000 On 05/29/2018 06:17 PM, Martin Thomson wrote: > On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov wrote: >> The issue here is that some hardware devices don't implement RSA CRT >> method with PSS, because they hard-wide RSA, legacy padding, and CRT >> method in one operation. RSA PSS can still be done, but only via a >> general modexp operation, which will be ~2x shower. Therefore, in these >> scenarios PSS incurs 2x performance penalty. > > I'm fairly certain that we've had this discussion before. What is new? > The quoted text quoted is old. The need to upgrade TLS 1.2 code if I support TLS 1.3 is new. I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS will take place? - This upgrade of TLS 1.2 can only be done by servers that support TLS 1.3. - TLS 1.2 clients won't advertise TLS 1.3 Signature Algorithm IDs; only TLS 1.3 clients will have e.g. rsa_pss_rsae_sha256 and others in signature_algorithms. Therefore, TLS 1.3 should get negotiated between these peers. The relevant paragraph from the TLS 1.3 draft seems to add uncertainty in unexplained cases when TLS 1.3 server decides to drop the negotiated version to TLS 1.2. What problem does this paragraph try to solve? From nobody Tue May 29 22:14: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 04B7B126E64 for ; Tue, 29 May 2018 22:13: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 MFbspvr1Yio2 for ; Tue, 29 May 2018 22:13:56 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705F9126FB3 for ; Tue, 29 May 2018 22:13:56 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 11-v6so15205484ois.8 for ; Tue, 29 May 2018 22:13:56 -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=oe6e4hVmFYVePFb+2eAgOB/8f+jnOwYendB/kW+dqQ4=; b=Nkt2X5lvN0+RHBW/bZFtNyEzGJzLgIj3pZVEl2dMxKDR9Z71ugSRn5FuwC9JsC/Q8u vpCa0iNBrCCqRdtelYd721L+wyJcMSXTmXws8pAGinWeauJumLWDMjro4ybq5V1cl/qa tgOPpZj79iiAjC4SZO13Eb+VX4lOmrOiUBmW6svrQMqm9qBqT29/a43eSEmHnEUpCTJr m1+lCnF5r4mEG4KhZj6a1hcRSkEFVmFZl+4Gfb9SzkxVKjCmzAzaTeuskeK9C2wlc6w0 tGKnJj3Na9IRoSGwq5KYOoLUtafArHTccRQ5Lt+snbxOb6dTM8qeIXCA1AH9E9eDEINS H6BQ== 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=oe6e4hVmFYVePFb+2eAgOB/8f+jnOwYendB/kW+dqQ4=; b=ZzPf9EYR+oNFrCnAu09beNgdEt4cmb26F2TbLahOO5E9s/riqjDozK6803Dy8SwZL6 rNdTo7Ne+xpvqpBNLmveM5CRO7VaCqEyQ6/ZsqXevalXD6e+shw1iJywcsCMlhcoFH4Z BAGhopOK+FDf8ObODiGtaV1J5J3RGPCc3bC0RFm2Zg7i9vmKJzM8q9faRTkBCptgj8nP ryj0Rl8BVVgVMqrQSQBi3Z8Ok2ig8R4bTzprH/F7ZqLLgS5MCuAv/j6ejNqQNXY1Yjjo dnC7lloj1WW1Wqc8xZF48wN/XCk1SMY3NfG2x3fzYZIErSCu9dey5nCFVM9A/4QsAY4w 2M+Q== X-Gm-Message-State: ALKqPwf1ORpMjgrsnUOQ8015t1SSf1lIsN7cI0rlZsQ1ne3XptXatFS0 c/zm8uhLdE2nfXNIBJMvrcmqARyagsU4dUmyShWjzA/O X-Google-Smtp-Source: ADUXVKIBd0GoY0+A4OWlj5ZOjXKIYy5Cd5Z5gkKLM4D5vmKCGej+IG/eBS1K/VcWyRayWVPQflwB3gUHJHsBMzlRm+w= X-Received: by 2002:aca:ab46:: with SMTP id u67-v6mr722866oie.272.1527657235750; Tue, 29 May 2018 22:13:55 -0700 (PDT) MIME-Version: 1.0 References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org> In-Reply-To: <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org> From: Martin Thomson Date: Wed, 30 May 2018 15:13:42 +1000 Message-ID: To: Andrey Jivsov Cc: David Benjamin , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 05:13:58 -0000 On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov wrote: > The quoted text quoted is old. The need to upgrade TLS 1.2 code if I > support TLS 1.3 is new. No, I'm certain we had that discussion too. > I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS > will take place? When people deploy TLS 1.3. Which is happening already. You can avoid the need as a server because a client willing to do TLS 1.2 will probably offer RSASSA PKCS#1 v1.5 and you can rely on that being there. But yeah, clients are going to have to suck it up. Here's the text, which I think is pretty clear: " Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3), MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. " From nobody Tue May 29 23:03: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 79CD9126DC2 for ; Tue, 29 May 2018 23:03:07 -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 P-U-eclYCcvP for ; Tue, 29 May 2018 23:03:05 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 2DBF512EC0C for ; Tue, 29 May 2018 23:03:04 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-11v.sys.comcast.net with ESMTP id NuCOfkntx4BJTNuCOfTKx5; Wed, 30 May 2018 06:03:04 +0000 Received: from [192.168.0.10] ([73.222.32.57]) by resomta-po-13v.sys.comcast.net with ESMTPSA id NuCNfRtsxqDpKNuCNfisoO; Wed, 30 May 2018 06:03:04 +0000 To: Martin Thomson Cc: David Benjamin , "" References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org> From: Andrey Jivsov Message-ID: <1b87cc44-2329-697d-59b7-829e87b67aef@brainhub.org> Date: Tue, 29 May 2018 23:03:03 -0700 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-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfDFcZ9Lj4YjBMiZa0kwlplAwfjoYcr2kYRo5TA+MVo4WPnzVYKr5buW/2BrlPtnC9bsdpY7eHKoa5SBThbMS5EtioDohwbXu8WxKdnl2aJLgBBCjLtEl t1bmXCtDAJAOtpQDi6Fa/bLgjEwIJNVe5bgMthI5fiWO4sZj8+jFua0zKKeqgJ4FV3hoooOx0tqzAOiLOER3qnz4pHH9/X/DXmo8703FxXy7fOn3Sh3DiTFf Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 06:03:07 -0000 On 05/29/2018 10:13 PM, Martin Thomson wrote: > On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov wrote: >> The quoted text quoted is old. The need to upgrade TLS 1.2 code if I >> support TLS 1.3 is new. > No, I'm certain we had that discussion too. > >> I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS >> will take place? > When people deploy TLS 1.3. Which is happening already. You can avoid the > need as a server because a client willing to do TLS 1.2 will probably offer > RSASSA PKCS#1 v1.5 and you can rely on that being there. But yeah, clients > are going to have to suck it up. Here's the text, which I think is pretty > clear: > " > Implementations that advertise support for RSASSA-PSS (which is mandatory > in TLS 1.3), MUST be prepared to accept a signature using that scheme even > when TLS 1.2 is negotiated. " Correct. That's the single paragraph that I think should not be there. As I asked in the previous message, what is a scenario when this paragraph helps? When will we see a fallback to TLS 1.2 AND upgrade of legacy PKCS#1.5 to PSS (within TLS 1.2)? Why such a server could not accept TLS 1.3 and use PSS there? From nobody Tue May 29 23:32: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 5485D12D964 for ; Tue, 29 May 2018 23:32:24 -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 05Uc0Kda8Iww for ; Tue, 29 May 2018 23:32:22 -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 9883C12D80E for ; Tue, 29 May 2018 23:32:22 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id y10-v6so19872737otg.10 for ; Tue, 29 May 2018 23:32:22 -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=dhHEaZAMtpmPqod0Tvg77kYZOEF8wjfk7vpdSNy5Ugc=; b=DtZd6yRNy7951DzgcNbfIbLoocVgxSE1cGkWDRCDAV6vZHu41DPDKL1ftQCBiO6oPu 20aEhbt2t15cihrdXrxHkrizOhDlQ6//rvlJ7CbSKAeyp5pbOcbo0wA8LXftCheXvSFh VoGmmqtgjz9TDje1bxTV7styAJC44bfYts4awaGF/wlv4CwjNTjqILt88Kb2wzfgGRB/ /T18WTCtpU/hnIHJpLpwILBWdrKNThqoYa2jMINHiyXvchxyJnLABUdL2eERxFso6tWN O59VSY+9+h2vmts1FHUVba5DLDJhkurJ5wjbbLQl24uAvsl2XVBTeOnCsBtwTAQsYlbh P9gw== 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=dhHEaZAMtpmPqod0Tvg77kYZOEF8wjfk7vpdSNy5Ugc=; b=Lu2+cTVHAC0T2mBAix4ulTeMrlylp+PHt9qdszWfxzxYF/dnVGc++kpIF7jqlhx/3k 0Xq+zVc3FZa7Q3w1XTsnSJhU4r9IiB4XaskT5VpwX2jjJGg2qeUKvP5DSqPUIVtrxSRh UWFrKFM7UQiLq8fjbh2Nq68vCphmUhEhwjWpw4Vo2iYSYmrevVMNYsVSzrLKcQ3dAFAR BBYlrctyLDBmZRePo1td901HX6DCqHaCNYgIkrBQaOgC0uYzoSecPxZscDCLp3dipvZu 2rrenCtY/Q+0eRBVkkLd4X0OKvjaSYkXWFnWdmWtBqRcmdFZPYk/3X7o7iV6EU72u6MN B5Jg== X-Gm-Message-State: ALKqPwfEjhYqPnuxx8gpKn7QFy654OMvztks9NR8DhMvUX+VFB3lHCDY j0Khr9CLXedSCSeHMkQl65wIxELsKCI1BU1nBN4= X-Google-Smtp-Source: ADUXVKJii7wZTLdCS65rOT9D7sQjEbxg90sxYZVKuUF6LrLFBWQO2XLi48rrlb3f0ZoOZuD5hOdm9P0VfpTCzkcnNeg= X-Received: by 2002:a9d:3637:: with SMTP id w52-v6mr859286otb.394.1527661941896; Tue, 29 May 2018 23:32:21 -0700 (PDT) MIME-Version: 1.0 References: <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org> <1b87cc44-2329-697d-59b7-829e87b67aef@brainhub.org> In-Reply-To: <1b87cc44-2329-697d-59b7-829e87b67aef@brainhub.org> From: Martin Thomson Date: Wed, 30 May 2018 16:32:05 +1000 Message-ID: To: Andrey Jivsov Cc: David Benjamin , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 06:32:25 -0000 On Wed, May 30, 2018 at 4:03 PM Andrey Jivsov wrote: > > Implementations that advertise support for RSASSA-PSS (which is mandatory > > in TLS 1.3), MUST be prepared to accept a signature using that scheme even > > when TLS 1.2 is negotiated. " > Correct. That's the single paragraph that I think should not be there. This has been discussed. The working group felt that it was worthwhile having support for PSS in TLS 1.2 and that they preferred not to add more codepoints to support that. The cost here is as you say: clients that offer 1.3 need to be able to handle PSS certs from a server. The cost for the alternative is to make the signature algorithm meaningful in TLS 1.3, which leaves us looking for a solution for 1.2 (yes, a new codepoint would achieve that). From nobody Wed May 30 13:42:49 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 E324C12DA08; Wed, 30 May 2018 13:42:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152771296685.27958.16842707433481973641.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2018 13:42:46 -0700 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 102 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, 30 May 2018 20:42:47 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: acme cfrg curdle dispatch httpbis mls perc quic rtcweb stir saag secdispatch suit teep tokbind uta Second Priority: dprive ace Third Priority: tcpinc lamps sidr sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Hannes Tschofenig Yoav Nir Martin Thomson Daniel Kahn Gillmor Benjamin Kaduk Nick Sullivan Subodh Iyengar David Benjamin Kyle Nekritz Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed May 30 18:23: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 70C19126CD6 for ; Wed, 30 May 2018 18:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAPJg58J6R-4 for ; Wed, 30 May 2018 18:23:39 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CFC12D947 for ; Wed, 30 May 2018 18:23:38 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id u4-v6so184174iof.2 for ; Wed, 30 May 2018 18:23:38 -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=lBr2shm9vwsyyL96WfyikxyFLtEMPnnRoavattrgQr4=; b=ZrL+h/0zLwphZrwQkgRZglIeUpQUBKLXWMue+Jp3XAcQRWgqiGZ99787eKZ3kRSTPS 7PjQUvGW5SRrn1zm5xUacfv7KX30ln3cryYRhI2DwymjbShMuo9uKLVv6tw3GpGMmeKn alq8KTSmRPWfdQMX5eB5VpJfB3QHeRuTDZrlxYrZXmSEvAju3DaSYGZjltyZNdp5DSS+ r3p7pkyiuiWp8yGU5jWMQZquF9MeeBKltbaxJYlLwq9WPPsIcfGCFcEVELcS2E1qOAw4 5RciE+lajbv7VZjI/MDiUzL6N+6iXpTNu65SmS4K7IN1XVAvmzLyZfDiVGxdN/PlNKOE DoPg== 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=lBr2shm9vwsyyL96WfyikxyFLtEMPnnRoavattrgQr4=; b=Chio4rR8MeA22mNdRJyPcuCCfw1Lp+6J/PXcUD36Vz7s4j6ngNNPjlwCVSqMQvPYF4 fwc7Cc4XHi5EJcGApoXw436GjVrT00lMyiO/igMf75U3LwNKL10KrXxwnQghS8TFmGBZ sNb9E30OZiqU8pPGSsw945KVxAgfttle061YAhEo+pT+hIZlMOeiPvSEhhFWzdk31a+n AAcfHmg6TLXMnKq9y17FBVI5m0BstjrP+6Obj9icYbJTdsot32NrKuB8wjLj4aOk6X5O BImJCmLVHYuingwuKgf960kywcjzt3SuCn/LGFPVFNvLDsxcMAXXtAVi7TosloDgA+CK Mgsg== X-Gm-Message-State: ALKqPwezCJh+ptu8WpjayrD3uzbt881lub3kLvprgPcXuOPIedaFoV+C PMZBFQMkrpzJYitdgLWKTF9jozohV63julyPaII= X-Google-Smtp-Source: ADUXVKJHjWy1Q9CbwgZFQ2NuEmMBwUSoZfj+i9Ft2oq0YqDLOraOsu8zWzQtv6fPyhTpilvZQfTMLW6qucnejZa3n3I= X-Received: by 2002:a6b:2b10:: with SMTP id r16-v6mr4346851ior.204.1527729818201; Wed, 30 May 2018 18:23:38 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Nick Sullivan Date: Wed, 30 May 2018 18:23:25 -0700 Message-ID: To: Martin Thomson Cc: Sean Turner , "" , Mike Bishop Content-Type: multipart/alternative; boundary="000000000000207575056d76515c" 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: Thu, 31 May 2018 01:23:43 -0000 --000000000000207575056d76515c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've put together some PRs to address the comments from last call. Comments welcome. Failing CertificateVerify due to MITM text: https://github.com/tlswg/tls-exported-authenticator/pull/28 Comments from Ben Kaduk: https://github.com/tlswg/tls-exported-authenticator/pull/26 Authenticated Denial: https://github.com/tlswg/tls-exported-authenticator/pull/27 Nick On Thu, May 24, 2018 at 5:54 PM Martin Thomson wrote: > Mike just inadvertently (?) discovered a problem with exported > authenticators. > > TLS post handshake authentication provides an authenticated refusal when = a > certificate can't be found. It turns out that the current design of the > HTTP/2 CERTIFICATE frame might need to rely on the same capability here. > > The current draft doesn't really say anything about what happens. > > https://github.com/tlswg/tls-exported-authenticator/issues/25 > > On Sat, May 12, 2018 at 9:59 AM Nick Sullivan > > wrote: > > > Thanks all for the comments on the draft. Let me try to summarize the > comments and propose next steps. > > > Tim Hollebeek had a comment about 0 as the separator. I generally don= =E2=80=99t > think this is a big issue, and prefer 0 because it is a natural way to > terminate a string. If anyone strongly disagrees, please reply to the lis= t. > > > Roelof duToit raised a question about middlebox interoperability, > specifically that the exporters will not match if the TLS connection is n= ot > end-to-end. There was a subsequent discussion about where to signal this > property. Martin Thomson suggested a signaling mechanism at the applicati= on > layer (https://github.com/httpwg/http-extensions/issues/617) and Eric > Rescorla suggested that the fact that this could cause CertificateVerify > failures should be called out in the document. I'll put a PR together to > add some helpful text around debugging CertificateVerify failures to > address Eric's suggestion. > > > Ben Kaduk had three points: > > - The certificate_request_context is prone to collisions with > post-handshake authentication and there are different spaces for the serv= er > and client context values. He suggested some text in Section 3 and maybe > more explanation in Section 5.2 as well. I=E2=80=99ll put together a PR f= or this. > > - Section 4.1 talks of the length of the exporter value in terms of the > length of the > > TLS PRF hash, adding that cipher suites not using TLS PRF have to defin= e > a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2=80= =99ll put > together a PR to clarify the text around this clarifying that for TLS 1.3 > cipher suites, the HDKF hash is what is meant. > > - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not inc= orporated into the > draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to inco= rporate > this extension. > > > I'll have the proposed changes for the above comments ready next week. > > > There were also some uncontroversial suggestions that I propose merging= : > > https://github.com/tlswg/tls-exported-authenticator/pull/21 > > https://github.com/tlswg/tls-exported-authenticator/pull/22 > > https://github.com/tlswg/tls-exported-authenticator/pull/23 > > https://github.com/tlswg/tls-exported-authenticator/pull/24 > > > > Nick > > > > On Thu, May 3, 2018 at 1:16 PM Nick Sullivan < > nicholas.sullivan@gmail.com> > wrote: > > >> Does anyone have any comments about the draft, criticisms, or votes of > support? > > >> Nick > > > >> On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: > > > > >>> > On Apr 21, 2018, at 10:25, Sean Turner wrote: > >>> > > >>> > > >>> >> On Apr 19, 2018, at 16:32, Sean Turner wrote: > >>> >> > >>> >> All, > >>> >> > >>> >> This is the working group last call for the "Exported Authenticato= rs > 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 ... > > >>> Just a reminder the WGLC ends tomorrow. > > >>> 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 > --000000000000207575056d76515c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've put together some PRs to address the comments fro= m last call. Comments welcome.

Failing CertificateVerify due to MITM= text:
https://github.com/tlswg/tls-exported-authenticato= r/pull/28

Comments from Ben Kaduk:
https://git= hub.com/tlswg/tls-exported-authenticator/pull/26

Authenticated D= enial:
https://github.com/tlswg/tls-exported-authenticato= r/pull/27


Nick

On Thu, May 24, 2018 at 5:54 PM Martin Thomson <martin.thomson@g= mail.com> wrote:
Mike just i= nadvertently (?) discovered a problem with exported
authenticators.

TLS post handshake authentication provides an authenticated refusal when a<= br> certificate can't be found.=C2=A0 It turns out that the current design = of the
HTTP/2 CERTIFICATE frame might need to rely on the same capability here.
The current draft doesn't really say anything about what happens.

https://github.com/tlswg/tls-exported-a= uthenticator/issues/25

On Sat, May 12, 2018 at 9:59 AM Nick Sullivan <nicholas.sullivan@gmail.com>=
wrote:

> Thanks all for the comments on the draft. Let me try to summarize the<= br> comments and propose next steps.

> Tim Hollebeek had a comment about 0 as the separator. I generally don= =E2=80=99t
think this is a big issue, and prefer 0 because it is a natural way to
terminate a string. If anyone strongly disagrees, please reply to the list.=

> Roelof duToit raised a question about middlebox interoperability,
specifically that the exporters will not match if the TLS connection is not=
end-to-end. There was a subsequent discussion about where to signal this property. Martin Thomson suggested a signaling mechanism at the application=
layer (https://github.com/httpwg/http-extensions= /issues/617) and Eric
Rescorla suggested that the fact that this could cause CertificateVerify failures should be called out in the document. I'll put a PR together t= o
add some helpful text around debugging CertificateVerify failures to
address Eric's suggestion.

> Ben Kaduk had three points:
> - The certificate_request_context is prone to collisions with
post-handshake authentication and there are different spaces for the server=
and client context values. He suggested some text in Section 3 and maybe more explanation in Section 5.2 as well. I=E2=80=99ll put together a PR for= this.
> - Section 4.1 talks of the length of the exporter value in terms of th= e
length of the
> TLS PRF hash, adding that cipher suites not using TLS PRF have to defi= ne
a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2=80= =99ll put
together a PR to clarify the text around this clarifying that for TLS 1.3 cipher suites, the HDKF hash is what is meant.
> - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not in= corporated into the
draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorp= orate
this extension.

> I'll have the proposed changes for the above comments ready next w= eek.

> There were also some uncontroversial suggestions that I propose mergin= g:
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/21
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/22
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/23
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/24


> Nick


> On Thu, May 3, 2018 at 1:16 PM Nick Sullivan <nicholas.sullivan@gmail.com= >
wrote:

>> Does anyone have any comments about the draft, criticisms, or vote= s of
support?

>> Nick


>> On Thu, May 3, 2018 at 1:12 PM Sean Turner <sean@sn3rd.com> wrote:



>>> > On Apr 21, 2018, at 10:25, Sean Turner <sean@sn3rd.com> wrote:
>>> >
>>> >
>>> >> On Apr 19, 2018, at 16:32, Sean Turner <sean@sn3rd.com> wrote:
>>> >>
>>> >> All,
>>> >>
>>> >> This is the working group last call for the "Exp= orted 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 ...

>>> Just a reminder the WGLC ends tomorrow.

>>> spt
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/tls<= br>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--000000000000207575056d76515c-- From nobody Wed May 30 18:48: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 4203812E059 for ; Wed, 30 May 2018 18:48: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, 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 brTETRjDbx3w for ; Wed, 30 May 2018 18:48:37 -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 3620D12DA01 for ; Wed, 30 May 2018 18:48:37 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id n3-v6so23499933ota.5 for ; Wed, 30 May 2018 18:48:37 -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:content-transfer-encoding; bh=uAYo1zHY/TeSPTx8+5K7rjtQjNmn3pMwaC9mVM+jssw=; b=gQW7F4/41IrK5iNkw5Pbo6VnNCtfyAuiKI3mpynVT+hqNr70UgI6XJfn/6CVF4aPC0 AhZFs01Y+8/vJbZ7L1J+WrHkhLNfJVFUdgO9WBie6daUyxr7wXpRbw1M98Z8nYASKZ5J tR30osQgR9n1EvbvgV1tkMNbR6TxqiANmDvcSHluVqwRIcb9DLF+t2p69qMhV4I8bsr8 tT5frFGUUYQLgwPzL9HEnFrud9oJ7An+mSbBhzdwkegGvU7RINjLUGNPVmp3J2j97CgZ vJx5TTzpvMsV3Cif0BrqdQ6ouPyy44reTSiCb5rkW/8jjBVAzgRjfNUVVyfNSjyi8xKI Rgeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uAYo1zHY/TeSPTx8+5K7rjtQjNmn3pMwaC9mVM+jssw=; b=plnjfdQD6Mrzg/d/F6gqP0NhIbobCPWVCr5mV1P/aLUMPjvXLJ6ZF3Kl3Q9P95m2Gs ddMrzoMd1bQ0P7iysk7Yo+m6hdkrawVPAnQpVGGmfVwpZFe0HLXdSaib+EPfbWSU7tpM IUqUIGRlfC7DPeaF2orq4n9aDhpkdUA/PfP1V7Stfmbw83d2twAIgvgaERuCS2/tBTkR FDpWvKQ+Z551DImg5FHdH5d5IuI0MQZgLQNbvyn+Y82yT2AjtPJs4wDL8fhZmiLOn/oW XP0BveWQcVHUIFOTtt0cbhm4Enw6CkcV5I/uLJSXxsZahNtNaadiF7P0sUYMObCY7naT vK7g== X-Gm-Message-State: ALKqPwdkyoHlrxpx4Ur+LLDMtEIrYriodCzQF6RLa0pVgWPYts08N3t6 Dlg1nowcywpYAbIkKfggjqdPNDvBUMVZMqytNA4= X-Google-Smtp-Source: ADUXVKLxmNCw0bId96A++yoOnP5SQEnv0eCgtIJOCofmkwD4ASF37xZT5SFrjiH66K7P3Us2XOWz2QKSUyx6BldleVo= X-Received: by 2002:a9d:3a65:: with SMTP id j92-v6mr3561619otc.352.1527731316438; Wed, 30 May 2018 18:48:36 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Martin Thomson Date: Thu, 31 May 2018 11:48:25 +1000 Message-ID: To: Nick Sullivan Cc: Sean Turner , "" , Mike Bishop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 31 May 2018 01:48:41 -0000 I've reviewed changes. Thanks for writing them up Nick. Two concerns: On #26, I think that there is a misunderstanding of how signature_algorithms and signature_algorithms_cert work. My understanding is that the former applies to the entire chain, unless the latter is present, in which case the latter applies to all signatures produced by certificates in the chain other than the end entity certificate. Thus, signature_algorithms entirely governs the choice of signature algorithm that is used in TLS itself, whereas signature_algorithms_cert (if present) governs the use of signatures that are used in building the certification path. #26 switches to signature_algorithms_cert exclusively. That's an error, I think. In #27, I think that dropping Certificate entirely isn't a good idea. TLS 1.3 sends it, but leaves it empty. There are a few reasons I mention in the PR comments. On Thu, May 31, 2018 at 11:23 AM Nick Sullivan wrote: > > I've put together some PRs to address the comments from last call. Commen= ts welcome. > > Failing CertificateVerify due to MITM text: > https://github.com/tlswg/tls-exported-authenticator/pull/28 > > Comments from Ben Kaduk: > https://github.com/tlswg/tls-exported-authenticator/pull/26 > > Authenticated Denial: > https://github.com/tlswg/tls-exported-authenticator/pull/27 > > > Nick > > On Thu, May 24, 2018 at 5:54 PM Martin Thomson = wrote: >> >> Mike just inadvertently (?) discovered a problem with exported >> authenticators. >> >> TLS post handshake authentication provides an authenticated refusal when= a >> certificate can't be found. It turns out that the current design of the >> HTTP/2 CERTIFICATE frame might need to rely on the same capability here. >> >> The current draft doesn't really say anything about what happens. >> >> https://github.com/tlswg/tls-exported-authenticator/issues/25 >> >> On Sat, May 12, 2018 at 9:59 AM Nick Sullivan >> wrote: >> >> > Thanks all for the comments on the draft. Let me try to summarize the >> comments and propose next steps. >> >> > Tim Hollebeek had a comment about 0 as the separator. I generally don= =E2=80=99t >> think this is a big issue, and prefer 0 because it is a natural way to >> terminate a string. If anyone strongly disagrees, please reply to the li= st. >> >> > Roelof duToit raised a question about middlebox interoperability, >> specifically that the exporters will not match if the TLS connection is = not >> end-to-end. There was a subsequent discussion about where to signal this >> property. Martin Thomson suggested a signaling mechanism at the applicat= ion >> layer (https://github.com/httpwg/http-extensions/issues/617) and Eric >> Rescorla suggested that the fact that this could cause CertificateVerify >> failures should be called out in the document. I'll put a PR together to >> add some helpful text around debugging CertificateVerify failures to >> address Eric's suggestion. >> >> > Ben Kaduk had three points: >> > - The certificate_request_context is prone to collisions with >> post-handshake authentication and there are different spaces for the ser= ver >> and client context values. He suggested some text in Section 3 and maybe >> more explanation in Section 5.2 as well. I=E2=80=99ll put together a PR = for this. >> > - Section 4.1 talks of the length of the exporter value in terms of th= e >> length of the >> > TLS PRF hash, adding that cipher suites not using TLS PRF have to defi= ne >> a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2= =80=99ll put >> together a PR to clarify the text around this clarifying that for TLS 1.= 3 >> cipher suites, the HDKF hash is what is meant. >> > - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not in= corporated into the >> draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to inc= orporate >> this extension. >> >> > I'll have the proposed changes for the above comments ready next week. >> >> > There were also some uncontroversial suggestions that I propose mergin= g: >> > https://github.com/tlswg/tls-exported-authenticator/pull/21 >> > https://github.com/tlswg/tls-exported-authenticator/pull/22 >> > https://github.com/tlswg/tls-exported-authenticator/pull/23 >> > https://github.com/tlswg/tls-exported-authenticator/pull/24 >> >> >> > Nick >> >> >> > On Thu, May 3, 2018 at 1:16 PM Nick Sullivan >> wrote: >> >> >> Does anyone have any comments about the draft, criticisms, or votes o= f >> support? >> >> >> Nick >> >> >> >> On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: >> >> >> >> >>> > On Apr 21, 2018, at 10:25, Sean Turner wrote: >> >>> > >> >>> > >> >>> >> On Apr 19, 2018, at 16:32, Sean Turner wrote: >> >>> >> >> >>> >> All, >> >>> >> >> >>> >> This is the working group last call for the "Exported Authenticat= ors >> 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 UT= C >> on 4 April 2018. >> >>> > >> >>> > =E2=80=A6 4 May 2018 ... >> >> >>> Just a reminder the WGLC ends tomorrow. >> >> >>> 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 From nobody Wed May 30 20:13: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 685C71316EC; Wed, 30 May 2018 20:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T4BAAiZ29qF; Wed, 30 May 2018 20:13:15 -0700 (PDT) Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D451316E9; Wed, 30 May 2018 20:13:14 -0700 (PDT) Received: by mail-pg0-f47.google.com with SMTP id p8-v6so9031557pgq.10; Wed, 30 May 2018 20:13:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MBvqe+6YklI2A7t0Bn+TjbbMEA38RTToGQlw2oKiyos=; b=k7xYIf/pHJg7x8x6RX9/ZCjRBUVnGvEdBo8hDmA80/E+JKDiA/TnQVVtgqp32wYV5R fX4aFVvcgqPlXyRQWSuK+vgBHWxAUppWQCJFc7obQzBqx2LOqJ0FYuW1qZHrJ81Dz/T8 fOn/6L/su00sdmNGf87U4IOjY8hpHaWYegJfTnfENFBa4meWiP6LB7lcnGDqSgSQz5BQ K+hXmLqXg9L745Z4drEiQq86vxIjfYGcy8ghQZ6svl86LbQYSQ2UBdqzCqeRVQENEOKX 3w7VkI6mwNaYkiVCYLo3BTdAs6exobwNKTAF8ofGOa7DlIuUvfJ8Daoe3aUMNNTpsVK5 yz2w== X-Gm-Message-State: ALKqPwd7zPmqnO3lK+mgmRzcUnoeqez37nbzyP0SqYpb6BlSRp5ZH6J5 riaL2ygxCqDp0NnWFDhPcFokrRl/Y7jGBM3UJ0IGZw== X-Google-Smtp-Source: ADUXVKLsKFPEO6ca8QaT+FnGQSpXRfLjw/IG/8XLxuS83a+iPlGeRgw/6fPl33T1P4Rv0KXMao7BdpNdUHMyJ0rUm4M= X-Received: by 2002:aa7:8084:: with SMTP id v4-v6mr5152146pff.105.1527736394307; Wed, 30 May 2018 20:13:14 -0700 (PDT) MIME-Version: 1.0 References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> In-Reply-To: From: Adam Langley Date: Wed, 30 May 2018 20:13:02 -0700 Message-ID: To: noloader@gmail.com Cc: rsalz=40akamai.com@dmarc.ietf.org, tls-chairs@ietf.org, tls@ietf.org, bkaduk=40akamai.com@dmarc.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 03:13:17 -0000 On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton wrote: > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > working group for their smart locks last year. I have no idea how much > of the code they are going to reuse (if any at all). Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we thus wait in anticipation for a replacement. (The extensions space is effectively infinite: if we get close to running out, we can assign an "extended extensions" code point, which would contain a nested extensions block with 32-bit numbers instead. Therefore effort and delays resulting from treating it as a scarce resource are saddening. Speaking in a personal capacity, it looks like 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them randomly to avoid issues with concurrent applications and I offer 0xbb31 as a high-quality, random number. Since we had a triple collision in this case, random-assignment's virtues are currently particularly clear.) -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed May 30 22:56: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 47F6512EB44 for ; Wed, 30 May 2018 22:56:29 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjreDiyw6p0w for ; Wed, 30 May 2018 22:56:26 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB7612EAED for ; Wed, 30 May 2018 22:56:24 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id h7-v6so9219652qkm.0 for ; Wed, 30 May 2018 22:56:24 -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=XKRiFGyEufVfIzdCCY7Kt5z73qOvsgndDsGKwFYWbac=; b=LVZjdiDAgN0mkZIyhliAtMIed1U264YGWDZ0vsc4abPLqAJC3dBFocjoP5sHTuJELG GW+UUs8D06R8XhxJ0Y4GYFhn+xmvAYH65izW2jHR34qfzUbO4l1oqzmSGvxLSI4d0b/V oDP46nx0IjQIQbIr0DHpVx4eD7tVkAZ+jiaVQ+ghqbyj8F9cIXfkpa9Q3BdWT6jEAC0x /mx4/plJ2FKXEJv0S6HtpRI+W73D+GQEqysnqSn6oWfd5oM9HrV6kIRdoWRoRjy1MOt8 JOxNNk+Kp92RNG5AIZA8b0jDMA+CQiwYVedayrQhZEmT7sC2MWhWvmnaSxYokU2JnN9u qH/g== 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=XKRiFGyEufVfIzdCCY7Kt5z73qOvsgndDsGKwFYWbac=; b=ZO3IEwnPbvg4Pl6ZWNaHcjoaBBIMgUOfGGf0igPyZWzUWHYHVvun855y/fQdKxR9Kz FtPptsIraRdn2QqNAlQX6PsBdWCi/WReZiapDqS8OPIIeHTA5LqzsclT81kzRZGVn+ue TBTK8/IpeCxbiavDFQzTfaSSzRVQWFOpkcIj4s9a1LnSoo2eCuy6pJGFAu4idLt2rMm7 p6n+JgquRrgB8/66jf/KYue3QLMHA4i0XzvgAnVHVLcryzb+pVQrsbzPNvz9nCeqjcDR zuj7NWKJ9XCzBu/ubjxdLM7aMjtmGK0Oh4s8YqloWio1TFaYG6auMXGeb1fnf4ZhlkPp VZfg== X-Gm-Message-State: APt69E3RCMv+g7nNgM8grIjpo/NtmnFguMbqpPSNqfIODtN5A/S/7syF Tn5gxycKasYG8H0a02FpNI7Fa72VQqshO2ln1E6A6w== X-Google-Smtp-Source: ADUXVKLW0JJo8LhyB6V6oG2QhVBgptAE3ERyx1L9GO110mf4QmCQSmF3VLGMFHCq8mwHGPxMPX6+AytdqthXsLQkDJE= X-Received: by 2002:a37:670c:: with SMTP id b12-v6mr1395210qkc.108.1527746183819; Wed, 30 May 2018 22:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:370e:0:0:0:0:0 with HTTP; Wed, 30 May 2018 22:56:03 -0700 (PDT) In-Reply-To: References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> From: Joseph Salowey Date: Wed, 30 May 2018 22:56:03 -0700 Message-ID: To: Adam Langley , tls-chairs , "" Content-Type: multipart/alternative; boundary="000000000000980e27056d7a2005" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 05:56:30 -0000 --000000000000980e27056d7a2005 Content-Type: text/plain; charset="UTF-8" I agree we should use a different number than 26 for certificate compression. I don't see a problem with assigning 27 and reserving 26 for now. On Wed, May 30, 2018 at 8:13 PM, Adam Langley wrote: > On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton wrote: > > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > > working group for their smart locks last year. I have no idea how much > > of the code they are going to reuse (if any at all). > > Chrome / Google is blocked on code-point assignment for deploying > certificate compression. It appears that 26 is not a good pick and we > thus wait in anticipation for a replacement. > > (The extensions space is effectively infinite: if we get close to > running out, we can assign an "extended extensions" code point, which > would contain a nested extensions block with 32-bit numbers instead. > Therefore effort and delays resulting from treating it as a scarce > resource are saddening. Speaking in a personal capacity, it looks like > 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them > randomly to avoid issues with concurrent applications and I offer > 0xbb31 as a high-quality, random number. Since we had a triple > collision in this case, random-assignment's virtues are currently > particularly clear.) > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > --000000000000980e27056d7a2005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree we should use a different number than 26 for certi= ficate compression.=C2=A0 I don't see a problem with assigning 27 and r= eserving 26 for now.=C2=A0=C2=A0

On Wed, May 30, 2018 at 8:13 PM, Adam Langley <a= gl@imperialviolet.org> wrote:
On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloader@gmail.com> wrote:
> I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> working group for their smart locks last year. I have no idea how much=
> of the code they are going to reuse (if any at all).

Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, w= hich
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org

--000000000000980e27056d7a2005-- From nobody Thu May 31 03:01: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 A233812EB6F for ; Thu, 31 May 2018 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ESZtpYM4; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Pcn1SlqW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBEUXsPJ3yD0 for ; Thu, 31 May 2018 03:00:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC26412EB51 for ; Thu, 31 May 2018 03:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527760837; 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=gcmi5q3T6iF+cXTY++yUfSBNjJ+ZCVPjOZqnnjmJE6A=; b=ESZtpYM4/v/uIfgovDfo0Gq8gFJ6fCa4dczi1xpLFC0mBh1/SuVNdFfXguJKLMJP wsPPKfM/1i12p+/6kNHgEXY2JLYV7KjMVZQYQlc/4eDgSikdWSjwdEuVNY4UpeMe op3SjrQF2Hm5qsquEEuQBBRl4ciYmxDXdfSxydhApNM=; X-AuditID: c1b4fb30-36b839c0000002c8-a9-5b0fc7c57185 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C1.2D.00712.5C7CF0B5; Thu, 31 May 2018 12:00:37 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC010.ericsson.se (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 12:00:17 +0200 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 May 2018 12:00:17 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 31 May 2018 12:00:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gcmi5q3T6iF+cXTY++yUfSBNjJ+ZCVPjOZqnnjmJE6A=; b=Pcn1SlqW5XexKvmd0FmXrvFJsvk1Y0Q3juuaqoe2NZzNEv58w4VVnCpqG3ITWVRAEI/xV7Jpb1nnibv626ZGuyLxihMJWC4LpGrfeIxLRa324sOGGO2IagKOepddMKtAJmtW5P6cFYlPVsyyGsC32y6kDLN3qiu3S7KGbYPYXs8= Received: from AM0PR07MB4388.eurprd07.prod.outlook.com (52.133.61.33) by AM0PR07MB4067.eurprd07.prod.outlook.com (52.134.83.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Thu, 31 May 2018 10:00:16 +0000 Received: from AM0PR07MB4388.eurprd07.prod.outlook.com ([fe80::90a8:de33:14cd:6e5b]) by AM0PR07MB4388.eurprd07.prod.outlook.com ([fe80::90a8:de33:14cd:6e5b%3]) with mapi id 15.20.0820.005; Thu, 31 May 2018 10:00:16 +0000 From: John Mattsson To: "TLS@ietf.org" , "uta@ietf.org" , "saag@ietf.org" Thread-Topic: TLS 1.3 mandatory to support in 3GPP 5G Thread-Index: AQHT+MYs13E+ckh9d0SHDSYi4Q3H6g== Date: Thu, 31 May 2018 10:00:16 +0000 Message-ID: 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-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4067; 7:RJW9kTTMMebVEuCVdzoTiKWCMpZwMp2mhAIiqPdFV5vPlQxIw2ZsPebiTjS0edqcgOfD8vwsklbJVPiLLSs3VxX3iw0WE7oIU4bFdb2UNgnBPIX5BeKIVYu7PIGX4POwt4Tv/vaknNubnkZUKPMp0ClI0o83EhVflWNGev9cRF9h7a3OlNPntuNNvkU7ZVktCPpErctK94vXnlSwSTM/Tq7TmEm2n2K194eWy9H5Lfa4+xs91sUtnO3gbW9rWjSV x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4067; x-ms-traffictypediagnostic: AM0PR07MB4067: authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4067; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4067; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(39380400002)(376002)(346002)(189003)(199004)(97736004)(3660700001)(5660300001)(99286004)(36756003)(966005)(6486002)(66066001)(86362001)(450100002)(7736002)(58126008)(305945005)(14454004)(6436002)(478600001)(110136005)(105586002)(102836004)(53936002)(8676002)(316002)(5250100002)(186003)(81156014)(81166006)(83716003)(26005)(106356001)(6512007)(2616005)(44832011)(2900100001)(82746002)(6506007)(6306002)(8558605004)(486006)(3846002)(6116002)(3280700002)(476003)(59450400001)(68736007)(2501003)(25786009)(33656002)(2201001)(2906002)(8936002)(583454002)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4067; H:AM0PR07MB4388.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FPiLj3Fd/mrggZUBTEPWbJIBIAB3TFzlXjqmGnAZFk0wOBRW5kaJRGpRrdKB7x6iLHzKnduyfuDmKac9bIiPa6nPEfg6HPCK4WuUyBMOtzNf6bZI8kUE/lt3HhYHE4X6fUSTSe/LusGzVoBRLzn6V/k4NwDtvNjvq+uYgWpO5zO5lUsSnE3ApvXjfmNUszh5 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7D1BC2D7043F194083B91D53B47EA84C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4251a61d-f3ef-4450-6d1a-08d5c6dd4f55 X-MS-Exchange-CrossTenant-Network-Message-Id: 4251a61d-f3ef-4450-6d1a-08d5c6dd4f55 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 10:00:16.2301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4067 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUiTURTHubvP5uN0+bhmHmxqDUIUnNMKFkQaFexTaRCI0svUhynqlG2O tIKBrHxJt0RRh7aBQr4spFwvhJXO6cpBZvYlaYHvqJFiWq4i27wKffud/7nnnP85XBoL67lR dIFax2rUyiIJj0+1Zj6TJY64w7JlDUaxvNFUzZGvj9cg+dhIJUrDis5OHycdZfFP5rFFBXpW k3TqGj/f09sTVGqgr2/c92EDmguqQcE0MMfA+muWV4P4tJBxIfjsbeaSwIFg7V4tJsEPBPaH 1YgEnRxwf3yEA/UUY8aw8imdJEwccPZPcQMJITODwLUYFmAeI4P2AQMvwCImFyZHq/3DaXq/ X2+xhRL5OExMvMaEpWBb6qdI/yMwvWxHARYwqVDv9u74RswB+Dlm5wQYM5EwNWflkH0Y6BwY x4QjYGn2LzcwKsLfs2FQR+RDMNrSTRGOhg/WWkTYwYHbpjjCibDW1LSzPDBPEYzaZ3cLEmB1 ax0TD5fBaGzmEr0QfNt1eO9Nlcuy6ycGeuqmd2tfYTCt6gmL4cm7Dp4ZJVv+W8Hit4qZeOh7 kURkBVRNLCDCh6GxdjrIsnOJcHjbOkfZELcHRWhZbU6xKiVFymoKcrXaErVUzeoeI/8vGXL8 lj1HS4unnYihkSRUkDkYli3kKvXa8mInAhpLRIJGvV8S5CnLK1hNyVVNWRGrdaKDNCWJFMjP 92cJGZVSxxaybCmr2cty6OAoA8rZ9yVV3O32Dp1NLD63sSrqst5irOwNxcupO5eGdAqblP66 femuLrkjJOO9Z4Eyhasi8cVha+y3FUt+Vk6mcV61HN2mWxFLFW9EvTjO4wppq5zU9G1daT3a Zd7cNLcXRnNPXEjzes6U+RwDMxWOxdA/pTE3tzMe8IZj5+O/SyhtvjI5AWu0yn+azrztIQMA AA== Archived-At: Subject: [TLS] TLS 1.3 mandatory to support in 3GPP 5G X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 10:00:51 -0000 SSBhbSBoYXBweSB0byBhbm5vdW5jZSB0aGF0IFRMUyAxLjMgaXMgYWxyZWFkeSBtYW5kYXRvcnkg dG8gc3VwcG9ydCBmb3IgYWxsIHVzZXMgb2YgVExTIGluIDNHUFAgNUcgKGFuZCBhbHNvIExURSwg M0cgc3lzdGVtcyB0aGF0IGFyZSB1cGRhdGVkIHRvIHRoZSBsYXRlc3QgcmVsZWFzZSkuIFJlbGVh c2UgMTUgbWFrZXMgVExTIDEuMyBtYW5kYXRvcnkgZm9yIG5ldHdvcmtzIGFuZCBSZWxlYXNlIDE2 IG1ha2VzIFRMUyAxLjMgbWFuZGF0b3J5IGFsc28gZm9yIE1FcyAoaS5lLiBtb2JpbGUgcGhvbmVz KSB3aGlsZSByZW1vdmluZyBzdXBwb3J0IGZvciBUTFMgMS4xLg0KDQpDaGVlcnMsDQpKb2huDQoN CjNHUFAgVGVjaG5pY2FsIFNwZWNpZmljYXRpb24gMzMuMzEwLCBsYXRlc3QgdmVyc2lvbg0KaHR0 cDovL3d3dy4zZ3BwLm9yZy9mdHAvL1NwZWNzL2FyY2hpdmUvMzNfc2VyaWVzLzMzLjMxMC8zMzMx MC1lMDAuemlwDQoNClMzLTE4MjA1NiAoRXJpY3Nzb24pIC0gQWdyZWVkIFJlbC0xNSBDaGFuZ2Ug UmVxdWVzdA0KaHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvdHNnX3NhL1dHM19TZWN1cml0eS9UU0dT M185MUJpc19MYUpvbGxhL2RvY3MvUzMtMTgyMDU2LnppcA0KDQpTMy0xODIwNTcgKEVyaWNzc29u KSAtIEFncmVlZCBSZWwtMTYgQ2hhbmdlIFJlcXVlc3QNCmh0dHA6Ly93d3cuM2dwcC5vcmcvZnRw L3RzZ19zYS9XRzNfU2VjdXJpdHkvVFNHUzNfOTFCaXNfTGFKb2xsYS9kb2NzL1MzLTE4MjA1Ny56 aXANCg0K From nobody Thu May 31 07:42: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 27E3F12DA17 for ; Thu, 31 May 2018 07:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 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.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-qmLh0bSnWX for ; Thu, 31 May 2018 07:42:38 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24B512E887 for ; Thu, 31 May 2018 07:42:38 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id e8-v6so28151382qth.0 for ; Thu, 31 May 2018 07:42:38 -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=sGY4LQExqBnrvusfzzu4XPryUMnKYmHSDNif4ibIu1I=; b=huGE+GqlJD8hbUbVHrSICmqdmR/1z/7wToGMSA0TdDWtFbZ2wIU1qJ1Vc0ql8Ln4jU 3tG87DE3JotQaMkBmM7rZEwGdyiY7sI3Nwr7nHklPZv5QxI54Q7aT3WW282Vs8JcFVVf od6YW3Bd9K+fq54bf6e64BaVvUHLBA6weG+30= 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=sGY4LQExqBnrvusfzzu4XPryUMnKYmHSDNif4ibIu1I=; b=tdSLYHV4mWdg84DdQPnPb78w2dvD6wxVJQgN0lyNcqNyCS4/DaBuXOZd2D4Y5ZJB/z mYYsKhDAHnloH/zHndt/uW/QdjL3fCUNOtCIIy9eYI/cdEVjYaV4yC9jj6QgBJP28t9Y qJYSa/lfQmynA+BkrBfxPQcji8TPWOZ5edg3fjLV2exNt1dRJU/rqrbdttcgvNSRRwlm 4VFFcgO1JnYkjTJ/4aI6iWG3FYFPN8wUn+hsp/CuK7IjMSeaxtjw5vhq0ScEXFbB2oBd I5L1GyrUGkcvlyN/sAcIG9Ly/2d9628LebvvjbAZsor4i0LCyqmnNdZKBx/UhgHgw7YG RgDg== X-Gm-Message-State: APt69E2LCcJZD4T1u/LXwzY7an8vLWHzyICPMlXwOOXk+cjjpsqjgaDn gbKOtpBvlsww8fWN6TSRzsEzibtBQyQsdvZAbjpw X-Google-Smtp-Source: ADUXVKIBvgBh22FWKyMdXDMYPgDfTmbNUQvJqs6gtmlCRMnQdrT+BtEpfsYX+pquoqwlg/yRdSJ+cbkdEPyaA/HxbTE= X-Received: by 2002:ac8:1704:: with SMTP id w4-v6mr1401936qtj.217.1527777757582; Thu, 31 May 2018 07:42:37 -0700 (PDT) MIME-Version: 1.0 References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> In-Reply-To: From: David Benjamin Date: Thu, 31 May 2018 10:42:24 -0400 Message-ID: To: Joseph Salowey Cc: Adam Langley , tls-chairs , "" Content-Type: multipart/alternative; boundary="00000000000089e426056d817a26" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 14:42:41 -0000 --00000000000089e426056d817a26 Content-Type: text/plain; charset="UTF-8" I probed a bunch of servers yesterday and found evidence of yet another collision at 26! It's possible these are TLS-LTS implementations, but a lot of them additionally only support RSA decryption ciphers, which makes this seem unlikely. These servers do not appear to do anything with the extension, as far as I could tell, including even echoing it back, but they send decode_error if the extension includes a non-empty body. (It's possible their TLS implementation supports TLS-LTS, unconditionally parses the extension, but does not actually enable it by default.) I didn't repeat the probe with 27, but playing with a couple of the servers showed they tolerate other numbers fine, including 27. It's just that they appear to have squatted on 26 for something. It's frustrating that allocating code points is complicated, but given the other deployment problems TLS has seen lately, were this the worst of our problems, I would be quite happy. On Thu, May 31, 2018 at 1:56 AM Joseph Salowey wrote: > I agree we should use a different number than 26 for certificate > compression. I don't see a problem with assigning 27 and reserving 26 for > now. > > On Wed, May 30, 2018 at 8:13 PM, Adam Langley > wrote: > >> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton >> wrote: >> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers >> > working group for their smart locks last year. I have no idea how much >> > of the code they are going to reuse (if any at all). >> >> Chrome / Google is blocked on code-point assignment for deploying >> certificate compression. It appears that 26 is not a good pick and we >> thus wait in anticipation for a replacement. >> >> (The extensions space is effectively infinite: if we get close to >> running out, we can assign an "extended extensions" code point, which >> would contain a nested extensions block with 32-bit numbers instead. >> Therefore effort and delays resulting from treating it as a scarce >> resource are saddening. Speaking in a personal capacity, it looks like >> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them >> randomly to avoid issues with concurrent applications and I offer >> 0xbb31 as a high-quality, random number. Since we had a triple >> collision in this case, random-assignment's virtues are currently >> particularly clear.) >> >> -- >> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000089e426056d817a26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I probed a bunch of servers yesterday and found evidence o= f yet another collision at 26! It's possible these are TLS-LTS implemen= tations, but a lot of them additionally only support RSA decryption ciphers= , which makes this seem unlikely. These servers do not appear to do anythin= g with the extension, as far as I could tell, including even echoing it bac= k, but they=C2=A0 send decode_error if the extension includes a non-empty b= ody. (It's possible their TLS implementation supports TLS-LTS, uncondit= ionally parses the extension, but does not actually enable it by default.)<= div>
I didn't repeat the probe with 27, but playing with = a couple of the servers showed they tolerate other numbers fine, including = 27. It's just that they appear to have squatted on 26 for something.

It's frustrating that allocating code point= s is complicated, but given the other deployment problems TLS has seen late= ly, were this the worst of our problems, I would be quite happy.

On Thu, May 31, 2018 at 1:56 AM Jo= seph Salowey <joe@salowey.net>= wrote:
I agree we= should use a different number than 26 for certificate compression.=C2=A0 I= don't see a problem with assigning 27 and reserving 26 for now.=C2=A0= =C2=A0

On We= d, May 30, 2018 at 8:13 PM, Adam Langley <agl@imperialviolet.org&= gt; wrote:
On Tue, May 29, 2= 018 at 6:16 PM Jeffrey Walton <noloader@gmail.com> wrote:
> I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> working group for their smart locks last year. I have no idea how much=
> of the code they are going to reuse (if any at all).

Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, w= hich
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000089e426056d817a26-- From nobody Thu May 31 07:51: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 86EBC12EC72 for ; Thu, 31 May 2018 07:51:30 -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 j5Vx0zI_U2m0 for ; Thu, 31 May 2018 07:51:28 -0700 (PDT) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5E012ECC2 for ; Thu, 31 May 2018 07:51:27 -0700 (PDT) Received: by mail-ot0-x241.google.com with SMTP id 101-v6so3111541oth.4 for ; Thu, 31 May 2018 07:51:27 -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=1b1D2A3Xor7+q/ST2vlPjJYN8jIyw2tXMsUdsC1m16I=; b=IJJAp938q5Hs+70n+an/cPh3BDEihHjDOHUfSsiIq13pv+seshIjys5+2tUuRfbxf+ lYpAX+YmbPbkVaMNAX/iFrTEoUO4jv4OlO1V0NdFcKhc9QqKtudKcYH5QKkzb93J92he nwxh+ObZkhNiSESEZdYZMfd7Cebsb8XnX/tpHoQjYOSCEB1gn76ekXPqdHv1V4+wG7RB Y6uIHluioKKtU6D7aTXQlMTWg+Qai/Jyd6KfdobBk61Fs8L/bD0RwblQFPZ8T2Rd2DCe OhcijRW+4KWnaT7BhV8Nko/BZWNBtzn7I/1pDhohlxVkvzwNj1KGMArHSZ1Zr+5TtDlE T8hQ== 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=1b1D2A3Xor7+q/ST2vlPjJYN8jIyw2tXMsUdsC1m16I=; b=T0tlM0uyESps6RUB8p4dz744jA+QbANlGPyEqdSuC0HAYwTQw2Ct+qMBVzZ0K5+Bf/ JHmhCXIQ7PNkoC6YLOIg0xeT2vYcPo8HkM+4ui8wEeMMGktLAQfh193f5Sk+gJWF6hqb mS26gDeKlymSPUwv4tgDhyXUdgxRVrqyQXs1QbZHzd/yOltOIUSJqizFp8e+C8UQbfe8 tTrCa2ciS/9BHpGr+yV8/nlWhTDvP9+wYWhSU79wOYmxyJpmZzFfAsd8aSDhiBiRBEw+ R6mEIKAv1x29Jk0Bz8guVH6ZeyuTJyYsi8le31s9ZQQUZYTvZ/NTGRRxCCZtn29idntE VXEA== X-Gm-Message-State: ALKqPwcbHCG0mx86CUnNJqm+YsbJ8vh+ZbMFQmZ95ovtBA6KJ3MePp7Z z4KniwvqHqHZLquvmIm2gTFz3Ugq1GIUxyJiUW1K8w== X-Google-Smtp-Source: ADUXVKKBSFIm0CVv1TZATU2Im1dBnZH+uuZIET1ABELbpRh77owyT7WA4zP6nE/v7coBWilbLf1j200QNPwG0mFvbWU= X-Received: by 2002:a9d:5917:: with SMTP id t23-v6mr4988276oth.217.1527778287344; Thu, 31 May 2018 07:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 31 May 2018 07:50:46 -0700 (PDT) In-Reply-To: References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> From: Eric Rescorla Date: Thu, 31 May 2018 07:50:46 -0700 Message-ID: To: David Benjamin Cc: Joseph Salowey , Adam Langley , tls-chairs , "" Content-Type: multipart/alternative; boundary="0000000000001cf0fd056d819ac0" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 14:51:36 -0000 --0000000000001cf0fd056d819ac0 Content-Type: text/plain; charset="UTF-8" Based on this, I propose that IANA allocates a new !26 Early Data code point for compressed certificates (that's mechanical). As noted earlier, it's premature for TLS-LTS to request a code point because the enabling document has not yet been published, so we can defer the question of its use of 26 for a bit. The QUIC TLS extension should also change to a new code point, but I'm not sure it meets the criteria for an early code point assignment. MT proposed just squatting on a random code point. Having a really unique code point is less important here because this extension will only appear inside of QUIC and not on ordinarily TLS connections, though of course it must have a unique code point from other extensions used with QUIC. So it's not entirely clear how best to handle this, -Ekr On Thu, May 31, 2018 at 7:42 AM, David Benjamin wrote: > I probed a bunch of servers yesterday and found evidence of yet another > collision at 26! It's possible these are TLS-LTS implementations, but a lot > of them additionally only support RSA decryption ciphers, which makes this > seem unlikely. These servers do not appear to do anything with the > extension, as far as I could tell, including even echoing it back, but > they send decode_error if the extension includes a non-empty body. (It's > possible their TLS implementation supports TLS-LTS, unconditionally parses > the extension, but does not actually enable it by default.) > > I didn't repeat the probe with 27, but playing with a couple of the > servers showed they tolerate other numbers fine, including 27. It's just > that they appear to have squatted on 26 for something. > > It's frustrating that allocating code points is complicated, but given the > other deployment problems TLS has seen lately, were this the worst of our > problems, I would be quite happy. > > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey wrote: > >> I agree we should use a different number than 26 for certificate >> compression. I don't see a problem with assigning 27 and reserving 26 for >> now. >> >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley >> wrote: >> >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton >>> wrote: >>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers >>> > working group for their smart locks last year. I have no idea how much >>> > of the code they are going to reuse (if any at all). >>> >>> Chrome / Google is blocked on code-point assignment for deploying >>> certificate compression. It appears that 26 is not a good pick and we >>> thus wait in anticipation for a replacement. >>> >>> (The extensions space is effectively infinite: if we get close to >>> running out, we can assign an "extended extensions" code point, which >>> would contain a nested extensions block with 32-bit numbers instead. >>> Therefore effort and delays resulting from treating it as a scarce >>> resource are saddening. Speaking in a personal capacity, it looks like >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them >>> randomly to avoid issues with concurrent applications and I offer >>> 0xbb31 as a high-quality, random number. Since we had a triple >>> collision in this case, random-assignment's virtues are currently >>> particularly clear.) >>> >>> -- >>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >>> >> >> _______________________________________________ >> 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 > > --0000000000001cf0fd056d819ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on this, I propose that IANA allocates a new !2= 6 Early Data code point for compressed certificates (that's mechanical)= .

As noted earlier, it's premature for TLS-LTS= to request a code point because the enabling document has not yet been pub= lished, so we can defer the question of its use of 26 for a bit.
=
The QUIC TLS extension should also change to a new code poin= t, but I'm not sure it meets the criteria for an early code point assig= nment. MT proposed just squatting on a random code point. Having a really u= nique code point is less important here because this extension will only ap= pear inside of QUIC and not on ordinarily TLS connections, though of course= it must have a unique code point from other extensions used with QUIC. So = it's not entirely clear how best to handle this,

-Ekr


On Thu, May 31, 2018 at 7:42 AM, David Benjamin <= davidben@chromium.org> wrote:
I probed a bunch of servers yesterday and found evidenc= e of yet another collision at 26! It's possible these are TLS-LTS imple= mentations, but a lot of them additionally only support RSA decryption ciph= ers, which makes this seem unlikely. These servers do not appear to do anyt= hing with the extension, as far as I could tell, including even echoing it = back, but they=C2=A0 send decode_error if the extension includes a non-empt= y body. (It's possible their TLS implementation supports TLS-LTS, uncon= ditionally parses the extension, but does not actually enable it by default= .)

I didn't repeat the probe with 27, but playing wi= th a couple of the servers showed they tolerate other numbers fine, includi= ng 27. It's just that they appear to have squatted on 26 for something.=

It's frustrating that allocating code po= ints is complicated, but given the other deployment problems TLS has seen l= ately, were this the worst of our problems, I would be quite happy.

=
On Thu, = May 31, 2018 at 1:56 AM Joseph Salowey <joe@salowey.net> wrote:
I agre= e we should use a different number than 26 for certificate compression.=C2= =A0 I don't see a problem with assigning 27 and reserving 26 for now.= =C2=A0=C2=A0

On Wed, May 30, 2018 at 8:13 PM, Adam Langley <agl@imperialviolet.or= g> wrote:
On Tue, May= 29, 2018 at 6:16 PM Jeffrey Walton <noloader@gmail.com> wrote:
> I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> working group for their smart locks last year. I have no idea how much=
> of the code they are going to reuse (if any at all).

Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, w= hich
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
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


--0000000000001cf0fd056d819ac0-- From nobody Thu May 31 08:00: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 5B59E12EAAA for ; Thu, 31 May 2018 08:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 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.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWlQJQhvQQRA for ; Thu, 31 May 2018 08:00:12 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EABD12D880 for ; Thu, 31 May 2018 08:00:08 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q13-v6so28212835qtp.4 for ; Thu, 31 May 2018 08:00:08 -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=sE1Evjjj7vbuZdV6xCpG9PmGWgCKrGCr/QiQsqL2Nbg=; b=Kb3T9t4L10tFKmUm6AlCmjlM+t8/4n3hxQG3mA12fOcUf/vB569Ky9lv9BLOJZADja yWyg7Bmy4vZDm8r0Tfpy0Ao2ICsmZGzzyrXXoO/JaAqKW7ac4V+yq7CkrTND9IWdbU+L P2Y7BS+KUQgrGFRDJDuH13TKZAoD0j+T+J/CM= 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=sE1Evjjj7vbuZdV6xCpG9PmGWgCKrGCr/QiQsqL2Nbg=; b=pSi2hdocQ0MQ+s3zl6hopso0sTgrAHvCbhkRbi/mZtzRWSY6N5WprLw7wo2TwSF382 q6uONXplorhKA/JjDB82LksSwZBiOpDoLrkWkUO2Zg+9K7eEiCqHmp9z3uUkXH3i10XA Oc/CYjTX2X5kS6eAR42F3mI1Mp56o/y5btj1mYGs939RnlTk7UP8ll1BxesVc2vn11GX zdKZu3OdPannYWHFDra/pw+csy7GEXIakAm/kDUfEE1vlLkQssjdTjlLm0cQNk7lttYd gW7Nzm8pR0UTHrkP7FWskPoWuqC2/tQdr/p5U8+fU8NeOcuJo8S9mmiZCcpO6LHxgB7f XwAg== X-Gm-Message-State: APt69E0Ru/LRU//w8FJ48uaNfnCSiXJdxOoXYIjhq2KgeaQ7ALW5bwMZ Hcyb+LhqWCCTV+9JeKT6o+ruz5DtWD6vO58Fv2jt X-Google-Smtp-Source: ADUXVKIQR2d/HLFKu7wWDUlyo+VClyJYf4GMlj162MXHpTp30Q9B4IssqpxqzdJk1Drqck/SUMp9InaLfqkQjC3PCqQ= X-Received: by 2002:aed:2f64:: with SMTP id l91-v6mr7229502qtd.216.1527778807406; Thu, 31 May 2018 08:00:07 -0700 (PDT) MIME-Version: 1.0 References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> In-Reply-To: From: David Benjamin Date: Thu, 31 May 2018 10:59:54 -0400 Message-ID: To: Eric Rescorla Cc: Joseph Salowey , Adam Langley , tls-chairs , "" Content-Type: multipart/alternative; boundary="0000000000001d2883056d81b981" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 15:00:27 -0000 --0000000000001d2883056d81b981 Content-Type: text/plain; charset="UTF-8" Just picking a random high number for QUIC seems reasonable for this stage. None of this still will escape outside of draft QUIC versions (which, themselves, will be short-lived) and a collision at high numbers isn't likely anyway. Our problems with 26 and 40 are because we like to make "official" allocations consecutively, and then "unofficial" allocations missed the obvious corollary: do not mimic this. On Thu, May 31, 2018 at 10:51 AM Eric Rescorla wrote: > Based on this, I propose that IANA allocates a new !26 Early Data code > point for compressed certificates (that's mechanical). > > As noted earlier, it's premature for TLS-LTS to request a code point > because the enabling document has not yet been published, so we can defer > the question of its use of 26 for a bit. > > The QUIC TLS extension should also change to a new code point, but I'm not > sure it meets the criteria for an early code point assignment. MT proposed > just squatting on a random code point. Having a really unique code point is > less important here because this extension will only appear inside of QUIC > and not on ordinarily TLS connections, though of course it must have a > unique code point from other extensions used with QUIC. So it's not > entirely clear how best to handle this, > > -Ekr > > > On Thu, May 31, 2018 at 7:42 AM, David Benjamin > wrote: > >> I probed a bunch of servers yesterday and found evidence of yet another >> collision at 26! It's possible these are TLS-LTS implementations, but a lot >> of them additionally only support RSA decryption ciphers, which makes this >> seem unlikely. These servers do not appear to do anything with the >> extension, as far as I could tell, including even echoing it back, but >> they send decode_error if the extension includes a non-empty body. (It's >> possible their TLS implementation supports TLS-LTS, unconditionally parses >> the extension, but does not actually enable it by default.) >> >> I didn't repeat the probe with 27, but playing with a couple of the >> servers showed they tolerate other numbers fine, including 27. It's just >> that they appear to have squatted on 26 for something. >> >> It's frustrating that allocating code points is complicated, but given >> the other deployment problems TLS has seen lately, were this the worst of >> our problems, I would be quite happy. >> >> On Thu, May 31, 2018 at 1:56 AM Joseph Salowey wrote: >> >>> I agree we should use a different number than 26 for certificate >>> compression. I don't see a problem with assigning 27 and reserving 26 for >>> now. >>> >>> On Wed, May 30, 2018 at 8:13 PM, Adam Langley >>> wrote: >>> >>>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton >>>> wrote: >>>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers >>>> > working group for their smart locks last year. I have no idea how much >>>> > of the code they are going to reuse (if any at all). >>>> >>>> Chrome / Google is blocked on code-point assignment for deploying >>>> certificate compression. It appears that 26 is not a good pick and we >>>> thus wait in anticipation for a replacement. >>>> >>>> (The extensions space is effectively infinite: if we get close to >>>> running out, we can assign an "extended extensions" code point, which >>>> would contain a nested extensions block with 32-bit numbers instead. >>>> Therefore effort and delays resulting from treating it as a scarce >>>> resource are saddening. Speaking in a personal capacity, it looks like >>>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them >>>> randomly to avoid issues with concurrent applications and I offer >>>> 0xbb31 as a high-quality, random number. Since we had a triple >>>> collision in this case, random-assignment's virtues are currently >>>> particularly clear.) >>>> >>>> -- >>>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >>>> >>> >>> _______________________________________________ >>> 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 >> >> > --0000000000001d2883056d81b981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just picking a random high number for QUIC seems reas= onable for this stage. None of this still will escape outside of draft QUIC= versions (which, themselves, will be short-lived) and a collision at high = numbers isn't likely anyway. Our problems with 26 and 40 are because we= like to make "official" allocations consecutively, and then &quo= t;unofficial" allocations missed the obvious corollary:=C2=A0do not mi= mic this.

On Thu, May = 31, 2018 at 10:51 AM Eric Rescorla <ekr@= rtfm.com> wrote:
Based on this, I propose that IANA allocates a new !26 Early Dat= a code point for compressed certificates (that's mechanical).

As noted earlier, it's premature for TLS-LTS to request= a code point because the enabling document has not yet been published, so = we can defer the question of its use of 26 for a bit.

<= div>The QUIC TLS extension should also change to a new code point, but I= 9;m not sure it meets the criteria for an early code point assignment. MT p= roposed just squatting on a random code point. Having a really unique code = point is less important here because this extension will only appear inside= of QUIC and not on ordinarily TLS connections, though of course it must ha= ve a unique code point from other extensions used with QUIC. So it's no= t entirely clear how best to handle this,

-Ekr=


On Thu, May 31, 2018 at 7:42 AM, David Benjamin <davidben@ch= romium.org> wrote:
I probed a bunch of servers yesterday and found evidence of yet an= other collision at 26! It's possible these are TLS-LTS implementations,= but a lot of them additionally only support RSA decryption ciphers, which = makes this seem unlikely. These servers do not appear to do anything with t= he extension, as far as I could tell, including even echoing it back, but t= hey=C2=A0 send decode_error if the extension includes a non-empty body. (It= 's possible their TLS implementation supports TLS-LTS, unconditionally = parses the extension, but does not actually enable it by default.)

=
I didn't repeat the probe with 27, but playing with a couple= of the servers showed they tolerate other numbers fine, including 27. It&#= 39;s just that they appear to have squatted on 26 for something.
=

It's frustrating that allocating code points is com= plicated, but given the other deployment problems TLS has seen lately, were= this the worst of our problems, I would be quite happy.

On Thu, May 31, 2018 at 1:56 AM Joseph Salowey <joe@salowey.net> wrote:
I agree we should use a different number than 26 = for certificate compression.=C2=A0 I don't see a problem with assigning= 27 and reserving 26 for now.=C2=A0=C2=A0
<= br>
On Wed, May 30, 2018 at 8:13 PM, Adam Langley= <agl@imperialviolet.org> wrote:
On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloader@gmail.com&= gt; wrote:
> I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> working group for their smart locks last year. I have no idea how much=
> of the code they are going to reuse (if any at all).

Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, w= hich
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
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


--0000000000001d2883056d81b981-- From nobody Thu May 31 08:10: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 920DE12DA24; Thu, 31 May 2018 08:10:41 -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 goKXj7cFbQ0p; Thu, 31 May 2018 08:10:39 -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 258B312EA24; Thu, 31 May 2018 08:10:39 -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 w4VF7ThX011176; Thu, 31 May 2018 16:10:36 +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=+FthIK6AHa/0XfbzhRm99wt4BWeZR1o4tCm2qJHntpU=; b=BfGN9CIej15FlSmCfSWNQcxaw0x7aQQyJGdQlUL5iYnxLTTpn2henhNvckqo4xNBuuxc DPSjhzkILuUBHh6rDF8FWqUl4Y7AAeZdkM0bb1yZVTcgnXZIWNxVTsvlb4E4n9lVR8dz bGXbBW/kePhnEhHNIo3n2qWM9imGg9hkdblQcc0k8XqnthDExphGvmjHQGTa7R+Vn+52 aZvSfrPOzAZfyeOJ2ZfAkRXKWDW2lVJH1kzevNYHkvu0HgvZyFKTQx41oJ5Eg+QmOsga PN0ysXwxrzY85EoYUMtvP/oos/xGJhRWWJhwQbLW76oJYGQWthNNUZjbdfdCsuAPK+a5 oQ== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ja8a5ad88-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 May 2018 16:10:36 +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 w4VF6AYL017385; Thu, 31 May 2018 11:10:35 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j9cvv9rb8-1; Thu, 31 May 2018 11:10:35 -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 E96F720068; Thu, 31 May 2018 15:10:34 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fOPDl-0004y5-RG; Thu, 31 May 2018 10:10:33 -0500 Date: Thu, 31 May 2018 10:10:33 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: David Benjamin , Adam Langley , tls-chairs , "" Message-ID: <20180531151033.GR13834@akamai.com> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@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-05-31_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-1805220000 definitions=main-1805310170 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805310170 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 15:10:42 -0000 I think there's also some room to just mark 26 as "Reserved - unauthorized use has rendered this value unsuitable for official allocation". -Ben On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote: > Based on this, I propose that IANA allocates a new !26 Early Data code > point for compressed certificates (that's mechanical). > > As noted earlier, it's premature for TLS-LTS to request a code point > because the enabling document has not yet been published, so we can defer > the question of its use of 26 for a bit. > > The QUIC TLS extension should also change to a new code point, but I'm not > sure it meets the criteria for an early code point assignment. MT proposed > just squatting on a random code point. Having a really unique code point is > less important here because this extension will only appear inside of QUIC > and not on ordinarily TLS connections, though of course it must have a > unique code point from other extensions used with QUIC. So it's not > entirely clear how best to handle this, > > -Ekr > > > On Thu, May 31, 2018 at 7:42 AM, David Benjamin > wrote: > > > I probed a bunch of servers yesterday and found evidence of yet another > > collision at 26! It's possible these are TLS-LTS implementations, but a lot > > of them additionally only support RSA decryption ciphers, which makes this > > seem unlikely. These servers do not appear to do anything with the > > extension, as far as I could tell, including even echoing it back, but > > they send decode_error if the extension includes a non-empty body. (It's > > possible their TLS implementation supports TLS-LTS, unconditionally parses > > the extension, but does not actually enable it by default.) > > > > I didn't repeat the probe with 27, but playing with a couple of the > > servers showed they tolerate other numbers fine, including 27. It's just > > that they appear to have squatted on 26 for something. > > > > It's frustrating that allocating code points is complicated, but given the > > other deployment problems TLS has seen lately, were this the worst of our > > problems, I would be quite happy. > > > > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey wrote: > > > >> I agree we should use a different number than 26 for certificate > >> compression. I don't see a problem with assigning 27 and reserving 26 for > >> now. > >> > >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley > >> wrote: > >> > >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton > >>> wrote: > >>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > >>> > working group for their smart locks last year. I have no idea how much > >>> > of the code they are going to reuse (if any at all). > >>> > >>> Chrome / Google is blocked on code-point assignment for deploying > >>> certificate compression. It appears that 26 is not a good pick and we > >>> thus wait in anticipation for a replacement. > >>> > >>> (The extensions space is effectively infinite: if we get close to > >>> running out, we can assign an "extended extensions" code point, which > >>> would contain a nested extensions block with 32-bit numbers instead. > >>> Therefore effort and delays resulting from treating it as a scarce > >>> resource are saddening. Speaking in a personal capacity, it looks like > >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them > >>> randomly to avoid issues with concurrent applications and I offer > >>> 0xbb31 as a high-quality, random number. Since we had a triple > >>> collision in this case, random-assignment's virtues are currently > >>> particularly clear.) > >>> > >>> -- > >>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > >>> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 31 08:15: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 B42EE12EB8F for ; Thu, 31 May 2018 08:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y11Boo3_Z_lv for ; Thu, 31 May 2018 08:15:05 -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 CF15012EBE9 for ; Thu, 31 May 2018 08:15:02 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id a10-v6so26171898ioc.9 for ; Thu, 31 May 2018 08:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s1ioevMSeek5ZNJGc0hRRQ2suCCOhnf0TN+0pFhdpoI=; b=kJ9QyTl/ctW1j+ZQAt4c5HNoLO0sh/i6+JyAEnT+UJOxhJFJI0P9g9PBI6A3tlMgTa YLvpn7OzOXZ3rrWXdW6BWhXHfpLrrsvc4hP/J9FWiqF7icSiacL+/pD6viBfxQA6fI0f qVv5zfTJePi5ery2tNNwkdnUEbMt0pxg5XtTPqr/plaIztP2BRS9SZKOzga13bJKenCH VwPkyRJRYTl4CeJyrcQSes3m1XPxYC+wPkUMKnqpbdvpdgs/n8E7cN/oeD2D6Yn4oixw adzR9cCD0SPg7WMHRHbphvkjVX6XNdnFQjr3TtZqVUNuFQgVxYi63MJ2+CoiXRw8JfPx BddA== 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=s1ioevMSeek5ZNJGc0hRRQ2suCCOhnf0TN+0pFhdpoI=; b=MYQrFhxm7/TjvViN6+d25jX+dDOuwOZB2Ye3m0106u+UmmmwIqdpaSrYskweiLvoLW mCP8NHSJEiQKm0KkhKKScZ6pyXFMKITLKsZxa/zDgRii7lGeeHX50/AI3udp9USvqQV0 OItoJAoILibPC2fz/2Xn2olQUT6Om3zijujMU63RzNMGsXb09q4qWpOSPzPPZ3LcmHhh 0wF+jNiJUaemGDq1HfRAlTculykdiBSJEfYJADPBSGf1m7EkYZu8lHgt6uMP4FGY5kYB vFepIcrbq7Tkym73p5NQObw86J50kK32E/WRKIDCDoPmaCCbUBvmwDX4dOs3rBJpeidi n3ug== X-Gm-Message-State: ALKqPwfCKk6AxebK/jo0yQ71V/fkgij131Cgk4UojIujaZNKfAX2Oo4T Kw4+kY3nomoogbFIHYEm9CeAWLjdoWFTPYIMfTXpjLz1 X-Google-Smtp-Source: ADUXVKKXYsx5+2WjK+x5nSleIVaiG3AveQWQnrLBUzlyjOcfjB9FJsjXqo7QwRq6Bs3D0OISWdUQfXzWrpNXJadhCZM= X-Received: by 2002:a6b:9dc1:: with SMTP id g184-v6mr6437755ioe.41.1527779701958; Thu, 31 May 2018 08:15:01 -0700 (PDT) MIME-Version: 1.0 References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> <20180531151033.GR13834@akamai.com> In-Reply-To: <20180531151033.GR13834@akamai.com> From: Steven Valdez Date: Thu, 31 May 2018 11:14:49 -0400 Message-ID: To: bkaduk=40akamai.com@dmarc.ietf.org Cc: Eric Rescorla , agl@imperialviolet.org, tls-chairs@ietf.org, "" Content-Type: multipart/alternative; boundary="0000000000006ece7a056d81ee47" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 31 May 2018 15:15:09 -0000 --0000000000006ece7a056d81ee47 Content-Type: text/plain; charset="UTF-8" We might also want to mark 40 similarly given the ExtendedRandom collision that caused issues with key_share. On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk wrote: > I think there's also some room to just mark 26 as "Reserved - unauthorized > use has rendered this value unsuitable for official allocation". > > -Ben > > On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote: > > Based on this, I propose that IANA allocates a new !26 Early Data code > > point for compressed certificates (that's mechanical). > > > > As noted earlier, it's premature for TLS-LTS to request a code point > > because the enabling document has not yet been published, so we can defer > > the question of its use of 26 for a bit. > > > > The QUIC TLS extension should also change to a new code point, but I'm > not > > sure it meets the criteria for an early code point assignment. MT > proposed > > just squatting on a random code point. Having a really unique code point > is > > less important here because this extension will only appear inside of > QUIC > > and not on ordinarily TLS connections, though of course it must have a > > unique code point from other extensions used with QUIC. So it's not > > entirely clear how best to handle this, > > > > -Ekr > > > > > > On Thu, May 31, 2018 at 7:42 AM, David Benjamin > > wrote: > > > > > I probed a bunch of servers yesterday and found evidence of yet another > > > collision at 26! It's possible these are TLS-LTS implementations, but > a lot > > > of them additionally only support RSA decryption ciphers, which makes > this > > > seem unlikely. These servers do not appear to do anything with the > > > extension, as far as I could tell, including even echoing it back, but > > > they send decode_error if the extension includes a non-empty body. > (It's > > > possible their TLS implementation supports TLS-LTS, unconditionally > parses > > > the extension, but does not actually enable it by default.) > > > > > > I didn't repeat the probe with 27, but playing with a couple of the > > > servers showed they tolerate other numbers fine, including 27. It's > just > > > that they appear to have squatted on 26 for something. > > > > > > It's frustrating that allocating code points is complicated, but given > the > > > other deployment problems TLS has seen lately, were this the worst of > our > > > problems, I would be quite happy. > > > > > > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey > wrote: > > > > > >> I agree we should use a different number than 26 for certificate > > >> compression. I don't see a problem with assigning 27 and reserving > 26 for > > >> now. > > >> > > >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley > > > >> wrote: > > >> > > >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton > > >>> wrote: > > >>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > > >>> > working group for their smart locks last year. I have no idea how > much > > >>> > of the code they are going to reuse (if any at all). > > >>> > > >>> Chrome / Google is blocked on code-point assignment for deploying > > >>> certificate compression. It appears that 26 is not a good pick and we > > >>> thus wait in anticipation for a replacement. > > >>> > > >>> (The extensions space is effectively infinite: if we get close to > > >>> running out, we can assign an "extended extensions" code point, which > > >>> would contain a nested extensions block with 32-bit numbers instead. > > >>> Therefore effort and delays resulting from treating it as a scarce > > >>> resource are saddening. Speaking in a personal capacity, it looks > like > > >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them > > >>> randomly to avoid issues with concurrent applications and I offer > > >>> 0xbb31 as a high-quality, random number. Since we had a triple > > >>> collision in this case, random-assignment's virtues are currently > > >>> particularly clear.) > > >>> > > >>> -- > > >>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > >>> > > >> > > >> _______________________________________________ > > >> TLS mailing list > > >> TLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tls > > >> > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Steven Valdez | Chrome Networking | svaldez@google.com | 210-692-4742 --0000000000006ece7a056d81ee47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We might also want to mark 40 similarly given the Extended= Random collision that caused issues with key_share.

On Thu, May 31, 2018 at 11:10 AM Benjamin Kad= uk <bkaduk=3D40akamai.com@dmarc.ietf.org> wrote:
I think there's also some room to just mark 26 as "R= eserved - unauthorized
use has rendered this value unsuitable for official allocation".

-Ben

On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote:
> Based on this, I propose that IANA allocates a new !26 Early Data code=
> point for compressed certificates (that's mechanical).
>
> As noted earlier, it's premature for TLS-LTS to request a code poi= nt
> because the enabling document has not yet been published, so we can de= fer
> the question of its use of 26 for a bit.
>
> The QUIC TLS extension should also change to a new code point, but I&#= 39;m not
> sure it meets the criteria for an early code point assignment. MT prop= osed
> just squatting on a random code point. Having a really unique code poi= nt is
> less important here because this extension will only appear inside of = QUIC
> and not on ordinarily TLS connections, though of course it must have a=
> unique code point from other extensions used with QUIC. So it's no= t
> entirely clear how best to handle this,
>
> -Ekr
>
>
> On Thu, May 31, 2018 at 7:42 AM, David Benjamin <davidben@chromium.org>
> wrote:
>
> > I probed a bunch of servers yesterday and found evidence of yet a= nother
> > collision at 26! It's possible these are TLS-LTS implementati= ons, but a lot
> > of them additionally only support RSA decryption ciphers, which m= akes this
> > seem unlikely. These servers do not appear to do anything with th= e
> > extension, as far as I could tell, including even echoing it back= , but
> > they=C2=A0 send decode_error if the extension includes a non-empt= y body. (It's
> > possible their TLS implementation supports TLS-LTS, unconditional= ly parses
> > the extension, but does not actually enable it by default.)
> >
> > I didn't repeat the probe with 27, but playing with a couple = of the
> > servers showed they tolerate other numbers fine, including 27. It= 's just
> > that they appear to have squatted on 26 for something.
> >
> > It's frustrating that allocating code points is complicated, = but given the
> > other deployment problems TLS has seen lately, were this the wors= t of our
> > problems, I would be quite happy.
> >
> > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey <joe@salowey.net> wrote:
> >
> >> I agree we should use a different number than 26 for certific= ate
> >> compression.=C2=A0 I don't see a problem with assigning 2= 7 and reserving 26 for
> >> now.
> >>
> >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley <agl@imperialviolet.org= >
> >> wrote:
> >>
> >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloader@gmail.com>= ;
> >>> wrote:
> >>> > I also delivered an OpenSSL-based TLS-LTS prototype = to a Hoteliers
> >>> > working group for their smart locks last year. I hav= e no idea how much
> >>> > of the code they are going to reuse (if any at all).=
> >>>
> >>> Chrome / Google is blocked on code-point assignment for d= eploying
> >>> certificate compression. It appears that 26 is not a good= pick and we
> >>> thus wait in anticipation for a replacement.
> >>>
> >>> (The extensions space is effectively infinite: if we get = close to
> >>> running out, we can assign an "extended extensions&q= uot; code point, which
> >>> would contain a nested extensions block with 32-bit numbe= rs instead.
> >>> Therefore effort and delays resulting from treating it as= a scarce
> >>> resource are saddening. Speaking in a personal capacity, = it looks like
> >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could= assign them
> >>> randomly to avoid issues with concurrent applications and= I offer
> >>> 0xbb31 as a high-quality, random number. Since we had a t= riple
> >>> collision in this case, random-assignment's virtues a= re currently
> >>> particularly clear.)
> >>>
> >>> --
> >>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.= org
> >>>
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/tls=
> >>
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >

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

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


--

<= tr style=3D"color:rgb(85,85,85);font-family:sans-serif;font-size:small">Steven Valdez=C2=A0|
=C2=A0Chrome Networkin= g |=C2=A0svaldez@google.com=C2=A0|=C2=A0210-692-47= 42
--0000000000006ece7a056d81ee47-- From nobody Thu May 31 11:44: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 5538D126BF3 for ; Thu, 31 May 2018 11:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiLNZ9h94Mx4 for ; Thu, 31 May 2018 11:44:45 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CDA12EAFC for ; Thu, 31 May 2018 11:44:34 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id c3-v6so29293273itj.4 for ; Thu, 31 May 2018 11:44:34 -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=+cxGiuDpAJsrC2YB6i8y8PNKpA3c+myNYs7XMt6w7vo=; b=aauoMI4s12iySpuFCYTlYJfuP5TikXZMyGlAi33yXnu7DtKeGbreGUZkagbd+1dObO 7HLbR2chHdQ7bOXfXtry6ChVVlSeXUcsffu1TuCSEvxZRC7deUf+AoGqvnmb2lDuct3z BLmGxK1pcq1CTOzOcnMlRFZGDAjaC+n6VE4sCupm5RHWJe8SssV8RbrnvBs9Y64G7/nS r7jxYBUkT3dLo9/RqI2IpkDbZfTWGK4GYdb6DSOKMnJAFKDZqoIuWy5zXWiasDVzs6zk HKrj1jEHcvqXbeUWy7Bynsgv1l2uNtmom7i5ARB6e9XSR8OEX6fFJ9/4Z3hIYvATXnH3 X1Gw== 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=+cxGiuDpAJsrC2YB6i8y8PNKpA3c+myNYs7XMt6w7vo=; b=AQIokBZ8tE93zRGNFwhFuPoA/1+2ARMjMUV5ALxyLx0k9yzndPKK/WTnBS/r8apUbY m2ZtH85NpLBYZhnPLdmNv1541fbI3WMFxVdkYfBoEBUk3sF2HCnJybb0xg/H2vX1854H cAnvE2999emH5xMhfmq/2ZboBZ+ByUPt0VvpU052rbOE9EC2FqtcGWI6wiFUAO7to23m q9PSYwla9HDJFid4C1nP7+F5GCjYcTi4XR2f9YmPwBqHkpKekBmbSOBa0OxeeAFkiIg8 2EAY26cZ9gta7CVR6Z5NX8ZofCrn44dBlIinn/yTFhtGyK3CdunMPihW1+lm89SU3XJr MdXA== X-Gm-Message-State: ALKqPwf6I3aoCWxSWbSoI5WKFut34mA/ikzggYRuWjQzKe5p6gwK80/q GNAc8MzdYTeJ+PU2mCvysj1gJfLeAGmrkDdoG+Q= X-Google-Smtp-Source: ADUXVKL3E7o7DbvLL4+Z5E0suBwN7OaHrPQclJoLEoGg+rqmdVkTk1PZaRt/Is3v7povl1cehgdWgAHYN1Zqa51uWjw= X-Received: by 2002:a24:b510:: with SMTP id v16-v6mr1178170ite.87.1527792274025; Thu, 31 May 2018 11:44:34 -0700 (PDT) MIME-Version: 1.0 References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <1CBA2C18-DAB8-4751-B765-3BF76C7F170B@sn3rd.com> <19A28612-65CA-4667-9E4E-D47717AC9009@sn3rd.com> In-Reply-To: From: Nick Sullivan Date: Thu, 31 May 2018 11:44:21 -0700 Message-ID: To: Martin Thomson Cc: Sean Turner , "" , Mike Bishop Content-Type: multipart/alternative; boundary="000000000000c8bd8f056d84db8c" 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: Thu, 31 May 2018 18:44:49 -0000 --000000000000c8bd8f056d84db8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin, Thanks for the corrections, and thank you others who have reviewed the patches. I've updated the PRs appropriately. Nick On Wed, May 30, 2018 at 6:48 PM Martin Thomson wrote: > I've reviewed changes. Thanks for writing them up Nick. > > Two concerns: > > On #26, I think that there is a misunderstanding of how > signature_algorithms and signature_algorithms_cert work. My > understanding is that the former applies to the entire chain, unless > the latter is present, in which case the latter applies to all > signatures produced by certificates in the chain other than the end > entity certificate. Thus, signature_algorithms entirely governs the > choice of signature algorithm that is used in TLS itself, whereas > signature_algorithms_cert (if present) governs the use of signatures > that are used in building the certification path. > > #26 switches to signature_algorithms_cert exclusively. That's an > error, I think. > > In #27, I think that dropping Certificate entirely isn't a good idea. > TLS 1.3 sends it, but leaves it empty. There are a few reasons I > mention in the PR comments. > On Thu, May 31, 2018 at 11:23 AM Nick Sullivan > wrote: > > > > I've put together some PRs to address the comments from last call. > Comments welcome. > > > > Failing CertificateVerify due to MITM text: > > https://github.com/tlswg/tls-exported-authenticator/pull/28 > > > > Comments from Ben Kaduk: > > https://github.com/tlswg/tls-exported-authenticator/pull/26 > > > > Authenticated Denial: > > https://github.com/tlswg/tls-exported-authenticator/pull/27 > > > > > > Nick > > > > On Thu, May 24, 2018 at 5:54 PM Martin Thomson > wrote: > >> > >> Mike just inadvertently (?) discovered a problem with exported > >> authenticators. > >> > >> TLS post handshake authentication provides an authenticated refusal > when a > >> certificate can't be found. It turns out that the current design of t= he > >> HTTP/2 CERTIFICATE frame might need to rely on the same capability her= e. > >> > >> The current draft doesn't really say anything about what happens. > >> > >> https://github.com/tlswg/tls-exported-authenticator/issues/25 > >> > >> On Sat, May 12, 2018 at 9:59 AM Nick Sullivan < > nicholas.sullivan@gmail.com> > >> wrote: > >> > >> > Thanks all for the comments on the draft. Let me try to summarize th= e > >> comments and propose next steps. > >> > >> > Tim Hollebeek had a comment about 0 as the separator. I generally > don=E2=80=99t > >> think this is a big issue, and prefer 0 because it is a natural way to > >> terminate a string. If anyone strongly disagrees, please reply to the > list. > >> > >> > Roelof duToit raised a question about middlebox interoperability, > >> specifically that the exporters will not match if the TLS connection i= s > not > >> end-to-end. There was a subsequent discussion about where to signal th= is > >> property. Martin Thomson suggested a signaling mechanism at the > application > >> layer (https://github.com/httpwg/http-extensions/issues/617) and Eric > >> Rescorla suggested that the fact that this could cause CertificateVeri= fy > >> failures should be called out in the document. I'll put a PR together = to > >> add some helpful text around debugging CertificateVerify failures to > >> address Eric's suggestion. > >> > >> > Ben Kaduk had three points: > >> > - The certificate_request_context is prone to collisions with > >> post-handshake authentication and there are different spaces for the > server > >> and client context values. He suggested some text in Section 3 and may= be > >> more explanation in Section 5.2 as well. I=E2=80=99ll put together a P= R for > this. > >> > - Section 4.1 talks of the length of the exporter value in terms of > the > >> length of the > >> > TLS PRF hash, adding that cipher suites not using TLS PRF have to > define > >> a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I=E2= =80=99ll > put > >> together a PR to clarify the text around this clarifying that for TLS > 1.3 > >> cipher suites, the HDKF hash is what is meant. > >> > - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension was not = incorporated into > the > >> draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. to i= ncorporate > >> this extension. > >> > >> > I'll have the proposed changes for the above comments ready next wee= k. > >> > >> > There were also some uncontroversial suggestions that I propose > merging: > >> > https://github.com/tlswg/tls-exported-authenticator/pull/21 > >> > https://github.com/tlswg/tls-exported-authenticator/pull/22 > >> > https://github.com/tlswg/tls-exported-authenticator/pull/23 > >> > https://github.com/tlswg/tls-exported-authenticator/pull/24 > >> > >> > >> > Nick > >> > >> > >> > On Thu, May 3, 2018 at 1:16 PM Nick Sullivan < > nicholas.sullivan@gmail.com> > >> wrote: > >> > >> >> Does anyone have any comments about the draft, criticisms, or votes > of > >> support? > >> > >> >> Nick > >> > >> > >> >> On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: > >> > >> > >> > >> >>> > On Apr 21, 2018, at 10:25, Sean Turner wrote: > >> >>> > > >> >>> > > >> >>> >> On Apr 19, 2018, at 16:32, Sean Turner wrote: > >> >>> >> > >> >>> >> 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. > >> >>> > > >> >>> > =E2=80=A6 4 May 2018 ... > >> > >> >>> Just a reminder the WGLC ends tomorrow. > >> > >> >>> 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 > --000000000000c8bd8f056d84db8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin,

Thanks for the corre= ctions, and thank you others who have reviewed the patches. I've update= d the PRs appropriately.

Nick
On Wed, May 30, 2018 at 6:48 = PM Martin Thomson <martin.th= omson@gmail.com> wrote:
I= 9;ve reviewed changes.=C2=A0 Thanks for writing them up Nick.

Two concerns:

On #26, I think that there is a misunderstanding of how
signature_algorithms and signature_algorithms_cert work.=C2=A0 My
understanding is that the former applies to the entire chain, unless
the latter is present, in which case the latter applies to all
signatures produced by certificates in the chain other than the end
entity certificate.=C2=A0 Thus, signature_algorithms entirely governs the choice of signature algorithm that is used in TLS itself, whereas
signature_algorithms_cert (if present) governs the use of signatures
that are used in building the certification path.

#26 switches to signature_algorithms_cert exclusively.=C2=A0 That's an<= br> error, I think.

In #27, I think that dropping Certificate entirely isn't a good idea. TLS 1.3 sends it, but leaves it empty.=C2=A0 There are a few reasons I
mention in the PR comments.
On Thu, May 31, 2018 at 11:23 AM Nick Sullivan
<nichol= as.sullivan@gmail.com> wrote:
>
> I've put together some PRs to address the comments from last call.= Comments welcome.
>
> Failing CertificateVerify due to MITM text:
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/28
>
> Comments from Ben Kaduk:
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/26
>
> Authenticated Denial:
> https://github.com/tlswg/tls-exporte= d-authenticator/pull/27
>
>
> Nick
>
> On Thu, May 24, 2018 at 5:54 PM Martin Thomson <martin.thomson@gmail.com>= wrote:
>>
>> Mike just inadvertently (?) discovered a problem with exported
>> authenticators.
>>
>> TLS post handshake authentication provides an authenticated refusa= l when a
>> certificate can't be found.=C2=A0 It turns out that the curren= t design of the
>> HTTP/2 CERTIFICATE frame might need to rely on the same capability= here.
>>
>> The current draft doesn't really say anything about what happe= ns.
>>
>> https://github.com/tlswg/tls-e= xported-authenticator/issues/25
>>
>> On Sat, May 12, 2018 at 9:59 AM Nick Sullivan <nicholas.sullivan@gmail.co= m>
>> wrote:
>>
>> > Thanks all for the comments on the draft. Let me try to summa= rize the
>> comments and propose next steps.
>>
>> > Tim Hollebeek had a comment about 0 as the separator. I gener= ally don=E2=80=99t
>> think this is a big issue, and prefer 0 because it is a natural wa= y to
>> terminate a string. If anyone strongly disagrees, please reply to = the list.
>>
>> > Roelof duToit raised a question about middlebox interoperabil= ity,
>> specifically that the exporters will not match if the TLS connecti= on is not
>> end-to-end. There was a subsequent discussion about where to signa= l this
>> property. Martin Thomson suggested a signaling mechanism at the ap= plication
>> layer (https://github.com/httpwg/http-e= xtensions/issues/617) and Eric
>> Rescorla suggested that the fact that this could cause Certificate= Verify
>> failures should be called out in the document. I'll put a PR t= ogether to
>> add some helpful text around debugging CertificateVerify failures = to
>> address Eric's suggestion.
>>
>> > Ben Kaduk had three points:
>> > - The certificate_request_context is prone to collisions with=
>> post-handshake authentication and there are different spaces for t= he server
>> and client context values. He suggested some text in Section 3 and= maybe
>> more explanation in Section 5.2 as well. I=E2=80=99ll put together= a PR for this.
>> > - Section 4.1 talks of the length of the exporter value in te= rms of the
>> length of the
>> > TLS PRF hash, adding that cipher suites not using TLS PRF hav= e to define
>> a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. = I=E2=80=99ll put
>> together a PR to clarify the text around this clarifying that for = TLS 1.3
>> cipher suites, the HDKF hash is what is meant.
>> > - The =E2=80=9Csignature_algorithms_cert=E2=80=9D extension w= as not incorporated into the
>> draft. I=E2=80=99ll put together a PR for 4.2.1., 4.2.2. and 5.1. = to incorporate
>> this extension.
>>
>> > I'll have the proposed changes for the above comments rea= dy next week.
>>
>> > There were also some uncontroversial suggestions that I propo= se merging:
>> > https://github.com/tlswg/tl= s-exported-authenticator/pull/21
>> > https://github.com/tlswg/tl= s-exported-authenticator/pull/22
>> > https://github.com/tlswg/tl= s-exported-authenticator/pull/23
>> > https://github.com/tlswg/tl= s-exported-authenticator/pull/24
>>
>>
>> > Nick
>>
>>
>> > On Thu, May 3, 2018 at 1:16 PM Nick Sullivan <nicholas.sullivan@gmai= l.com>
>> wrote:
>>
>> >> Does anyone have any comments about the draft, criticisms= , or votes of
>> support?
>>
>> >> Nick
>>
>>
>> >> On Thu, May 3, 2018 at 1:12 PM Sean Turner <sean@sn3rd.com> wrote:
>>
>>
>>
>> >>> > On Apr 21, 2018, at 10:25, Sean Turner <sean@sn3rd.com> wrote= :
>> >>> >
>> >>> >
>> >>> >> On Apr 19, 2018, at 16:32, Sean Turner <<= a href=3D"mailto:sean@sn3rd.com" target=3D"_blank">sean@sn3rd.com> w= rote:
>> >>> >>
>> >>> >> 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 2= 359 UTC
>> on 4 April 2018.
>> >>> >
>> >>> > =E2=80=A6 4 May 2018 ...
>>
>> >>> Just a reminder the WGLC ends tomorrow.
>>
>> >>> spt
>> >>> _______________________________________________
>> >>> TLS mailing list
>> >>> TLS= @ietf.org
>> >>> https://www.ietf.org/mailman/listinfo= /tls
>>
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/tls=
--000000000000c8bd8f056d84db8c-- From nobody Thu May 31 19:06: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 B0011124B0A; Thu, 31 May 2018 19:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 izbbKVPCoIF9; Thu, 31 May 2018 19:05:58 -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 70BF612426E; Thu, 31 May 2018 19:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1527818758; x=1559354758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6FKFqfRvXBw2Vr0qhknUO2E7hMEZ72piDU9uE+TOGZA=; b=w+bgsL9wMG1oGnqvCJVE47ja+K1KkWaoyHZ/ZvKHnnBdhZcYM+ra7LsJ h4xJNfU1N71PscThrfwLdNYgXQ7qOUDcVBwj6NW2CL5jICA8CNlNwoHTi KPSzF6UdpYH8yE1AHs7u8b3USSCtUeJdoGydDZzyEoTwij+xZcDJGT4eI kIk3fpdkwtTDVYUeaRhY8GmsEyFRzbk5ExSin29z3VP9H2qJorSMDEzPd AMzLQZKC/Bzm0aE4ggYqyIeuqqKz5+VngAVG0C+cqgdbWcZvbKm8WukZ1 tEC6N0xR6OI0FZLy3GBimg6+J0WciS5iAMLABZwHZJd02Mrblk571+FmB g==; X-IronPort-AV: E=Sophos;i="5.49,464,1520852400"; d="scan'208";a="14139530" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Jun 2018 14:05:51 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Jun 2018 14:05:50 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Fri, 1 Jun 2018 14:05:50 +1200 From: Peter Gutmann To: David Benjamin , Joseph Salowey CC: Adam Langley , tls-chairs , "" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq//98VACAA1vpAIAAAiOAgABSHYCAAbMYAIAALYuAgACTEACAAYfXew== Date: Fri, 1 Jun 2018 02:05:50 +0000 Message-ID: <1527818744373.4281@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 01 Jun 2018 02:06:01 -0000 4oCLRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz4gd3JpdGVzOgoKPkkgcHJv YmVkIGEgYnVuY2ggb2Ygc2VydmVycyB5ZXN0ZXJkYXkgYW5kIGZvdW5kIGV2aWRlbmNlIG9mIHll dCBhbm90aGVyCj5jb2xsaXNpb24gYXQgMjYhIEl0J3MgcG9zc2libGUgdGhlc2UgYXJlIFRMUy1M VFMgaW1wbGVtZW50YXRpb25zLCBidXQgYSBsb3QKPm9mIHRoZW0gYWRkaXRpb25hbGx5IG9ubHkg c3VwcG9ydCBSU0EgZGVjcnlwdGlvbiBjaXBoZXJzLCB3aGljaCBtYWtlcyB0aGlzCj5zZWVtIHVu bGlrZWx5LiAKCkFub3RoZXIgcmVhc29uIHdoeSBpdCBzaG91bGQgYmUgdW5saWtlbHkgKGVtcGhh c2lzIG9uICJzaG91bGQiKSBpcyB0aGF0IHRoZQp1c2UgaXMgaW4gU0NBREEvZW1iZWRkZWQsIHNv IG5vdCBhbnl0aGluZyB0aGF0IHNob3VsZCBiZSB2aXNpYmxlIG9uIHRoZSBwdWJsaWMKaW50ZXJu ZXQuCgpIYXZpbmcgc2FpZCB0aGF0LCBzb21lb25lIHNlbnQgbWUgYSBsaW5rIHRvIGEgU2hvZGFu IHNjYW4gZWFybGllciB0b2RheSB3aXRoCm92ZXIgYSB0aG91c2FuZCBkZXZpY2VzIHRoYXQgZGVm aW5pdGVseSBzaG91bGRuJ3QgYmUgb24gdGhlIEludGVybmV0LCBzbyB3aG8Ka25vd3Mgd2hhdCdz IGJlaW5nIHB1dCBvbmxpbmUgdGhlcmUuCgo+VGhlc2Ugc2VydmVycyBkbyBub3QgYXBwZWFyIHRv IGRvIGFueXRoaW5nIHdpdGggdGhlIGV4dGVuc2lvbiwgYXMgZmFyIGFzIEkKPmNvdWxkIHRlbGws IGluY2x1ZGluZyBldmVuIGVjaG9pbmcgaXQgYmFjaywgYnV0IHRoZXkgIHNlbmQgZGVjb2RlX2Vy cm9yIGlmCj50aGUgZXh0ZW5zaW9uIGluY2x1ZGVzIGEgbm9uLWVtcHR5IGJvZHkuCgpIbW0sIHRo YXQgZG9lcyBzb3VuZHMgbGlrZSAtTFRTLCBzaW5jZSBpdCBoYXMgYW4gZW1wdHkgYm9keS4uLiBu byBpZGVhIHdob3NlCmltcGxlbWVudGF0aW9uIHRoYXQgd291bGQgYmUgdGhvdWdoLgoKUGV0ZXIu Cg== From nobody Thu May 31 19:10: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 BB13D124B0A; Thu, 31 May 2018 19:10: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 5SoHTcegtX1O; Thu, 31 May 2018 19:10:56 -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 C309512426E; Thu, 31 May 2018 19:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1527819056; x=1559355056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zKFSqj2nvrlP8IVRO7xwyKN21usrY/NN0Eknbk+WJ78=; b=g/lABvEioHGOWdifDK3CQRchXoTymSG97hnzrYPiBIi/VNeJTW2f4Is8 BchVYtNUmEr4CPw9UQFbSVr4JSmCZoQRSTUDCtN+hF+6PkKa51BtdW3oH geXDE6OdiSAdp/HKyEBtfxEk++s9UqHVppIFBROwvuHquVC2QPL948qOy DQ5F8sPHG0bhzTtf+SVxAGXtcdq+s38N1IbI8zWtm+xYxPSFp5uOE6BlT TGxqGTVuhcCDsyFqb6o2ZCTHdCl6ZBf/VVrks020QxPMYt95ANljixyQe BSxMu3OYmPhxtDCksIx7x+bry1Mp8tgr7SBvoB+/P0sxCY88QGfId2gNw w==; X-IronPort-AV: E=Sophos;i="5.49,464,1520852400"; d="scan'208";a="14140363" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Jun 2018 14:10:54 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Jun 2018 14:10:53 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Fri, 1 Jun 2018 14:10:53 +1200 From: Peter Gutmann To: Eric Rescorla , David Benjamin CC: Adam Langley , tls-chairs , "" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq//98VACAA1vpAIAAAiOAgABSHYCAAbMYAIAALYuAgACTEACAAAJWAIABho0f Date: Fri, 1 Jun 2018 02:10:52 +0000 Message-ID: <1527819047006.22657@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 01 Jun 2018 02:10:58 -0000 Eric Rescorla writes:=0A= =0A= >As noted earlier, it's premature for TLS-LTS to request a code point becau= se=0A= >the enabling document has not yet been published, =0A= =0A= And yet -compression was allocated a codepoint without this. This whole me= ss=0A= was created because I asked for early allocation and was told to wait, whic= h I=0A= did [0], while -compression wasn't subject to the same requirements.=0A= =0A= Peter.=0A= =0A= [0] Meaning I didn't push the issue any further, however people were rollin= g=0A= out deployments and we had to use some value, see my previous comments = =0A= on why 26 was used.=0A= From nobody Thu May 31 19:13: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 CF686124BE8; Thu, 31 May 2018 19:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 faMHXP2aBGRB; Thu, 31 May 2018 19:13:31 -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 D41E912426E; Thu, 31 May 2018 19:13:30 -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=1527819211; x=1559355211; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7uAaF3kwTX1Mqd+e4WVn5enyVC6kk3AeAt2GdUx3i78=; b=3c8CbPGAoTxKFXhjntVqw0TsRrDSPHkv/G5iPuVUx5+KbrBUbYM7KPGm mqqZo5NuhTVp5Zmgm1f7EF+WrsFe256xZz6zNzReA61SBLGh9D7+CUZY3 VCQb1j20V0HLtyL0einPfqEXQ5hIU8XTpthrzgwmJR1OBbYfForIUv5XV 4aObunoEsCwQUsMkE9wlmGr+VP1Z+BocwWlUP/lqTj3+ujCapzGlJoonV S3BmYfdUZtF2r64xyG5m7FHl/Z4XnDNlIXAhzsER7ouMuxTmn5xWZV8jm toGRhVDSYkyDU7yAYsWWMD51SeVrRohyOkEwWuMzOWSo/L8J319iEPUhK w==; X-IronPort-AV: E=Sophos;i="5.49,464,1520852400"; d="scan'208";a="14140773" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Jun 2018 14:13:29 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Jun 2018 14:13:28 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::b0d7:2dae:1a32:6ff4%14]) with mapi id 15.00.1263.000; Fri, 1 Jun 2018 14:13:28 +1200 From: Peter Gutmann To: David Benjamin , Eric Rescorla CC: Adam Langley , tls-chairs , "" Thread-Topic: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt) Thread-Index: AQHT9GMg6inI/yD6CECnWE0tqGUgU6RDiQxq//98VACAA1vpAIAAAiOAgABSHYCAAbMYAIAALYuAgACTEACAAAJWAIAAAo4AgAGFOIY= Date: Fri, 1 Jun 2018 02:13:28 +0000 Message-ID: <1527819202509.15711@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 01 Jun 2018 02:13:33 -0000 David Benjamin writes:=0A= =0A= >Our problems with 26 and 40 are because we like to make "official"=0A= >allocations consecutively, and then "unofficial" allocations missed the=0A= >obvious corollary: do not mimic this.=0A= =0A= Yeah, based on being asked to wait for the registry draft I assumed nothing= =0A= would be issued until the registry draft was published. If I'd known that= =0A= there'd be allocations made despite the draft not being published, I'd have= =0A= chosen a random value or something.=0A= =0A= Peter.=0A= From nobody Thu May 31 19:17: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 6F6EF124D68 for ; Thu, 31 May 2018 19:17:53 -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 TVkjIfCXyfgC for ; Thu, 31 May 2018 19:17:51 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D81124BE8 for ; Thu, 31 May 2018 19:17:51 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id 11-v6so21243328ois.8 for ; Thu, 31 May 2018 19:17: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=wh2WfAY45klFL5aMypKMMYTHks2U5OvecrQMrE3/Bos=; b=f+JWuTj1Z0lYThhcuM/OLQS3MHqnkaFFWvr41OhZNQs8yv1xB9LzMPIe3RJ0t9iPAG 14l8qubu+WmZTtlIXWLTG753alErZOstscK44Bwv2uPDWuPA8oV3uZnjf+7/Cs6QOWrb RJUQRloJHs5yZwF78InZs5XkjAnXwErgmk9Fp3pMzKp1zsyrLtbzVVsFlDmRFN4ADa0X vnA6AkfHjmhTO3XWILOUkqMUPZAblxA31t250acmRstWxAqizWizRTByj3IleBkzzZNu KkkLP9g7TiYxUmqeULSKXGcZ96lhjmdomanMKRJI2g13gR4mS+QjeezKoLqZ/24hbuD3 VQ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wh2WfAY45klFL5aMypKMMYTHks2U5OvecrQMrE3/Bos=; b=hJs3VrzNb59YUqaAa1FuvpB53g1OV2V23rF1R6wBo1rkjpEWdLy/Yn6MW7D7x/Wqk6 72p6ZrIIHxDQUP1862hDiSih1aqnMjcHlafOkQ4sG8wgL8EBm8o/nbwHasf95EZqcm0D gkXUKxH8dc74Ka/u61ci3LlIo64JCY31Wq/DBfNgC327JdKcbk3KbCT0ULP7rkZ9XXJB sye6mjJf/XnYmEVR2OBkPfBMYFy15+uzXjCdv8uVBa/s6ElxRYDF5cQ6Kepp0TaRr0Iz VfAKLI/NohMBl4x9KIkUpI0ZrAmvI870hcfTeqQkcpiQxCWmV8ZV+ky/b7uChJEB91fa 9TXA== X-Gm-Message-State: APt69E14HiKPStfTaeTWgYqIeUt2wynlJh6ri8irhhOle7f2l1YSRjqA l8xPjlR0djnWQO4jgw9rOhIljk+gnIlG2OnyCfWhVA== X-Google-Smtp-Source: ADUXVKIPbkhzI+Ok6YpyocxUwB/xJMf4FehhqB59HfrniX3yISknl2H52Zyez+PuErmanI0ERy67ce5CrnA5LMKh2iU= X-Received: by 2002:aca:1c3:: with SMTP id 186-v6mr5377873oib.174.1527819471146; Thu, 31 May 2018 19:17:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Thu, 31 May 2018 19:17:10 -0700 (PDT) In-Reply-To: <1527819047006.22657@cs.auckland.ac.nz> References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <20180529201414.GL13834@akamai.com> <1527819047006.22657@cs.auckland.ac.nz> From: Eric Rescorla Date: Thu, 31 May 2018 19:17:10 -0700 Message-ID: To: Peter Gutmann Cc: David Benjamin , Adam Langley , tls-chairs , "" Content-Type: multipart/alternative; boundary="000000000000dbe297056d8b3016" Archived-At: Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.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, 01 Jun 2018 02:17:54 -0000 --000000000000dbe297056d8b3016 Content-Type: text/plain; charset="UTF-8" On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann wrote: > Eric Rescorla writes: > > >As noted earlier, it's premature for TLS-LTS to request a code point > because > >the enabling document has not yet been published, > > And yet -compression was allocated a codepoint without this. Compression is a WG draft which met the standards for early allocation. This is not a WG draft, but will meet the new standard for regular allocation when the IANA document is published. This whole mess > was created because I asked for early allocation and was told to wait, > which I > did [0], while -compression wasn't subject to the same requirements. > I would say rather that this mess was created by your choosing to squat on a code point right in the middle of future allocations. -Ekr --000000000000dbe297056d8b3016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann <pgut001@cs.auc= kland.ac.nz> wrote:
E= ric Rescorla <ekr@rtfm= .com> writes:

>As noted earlier, it's premature for TLS-LTS to request a code poin= t because
>the enabling document has not yet been published,

And yet -compression was allocated a codepoint without this.=C2=A0

Compression is a WG draft which met the stan= dards for early allocation. This is not
a WG draft, but will meet= the new standard for regular allocation when the IANA
document i= s published.


This whole mess
was created because I asked for early allocation and was told to wait, whic= h I
did [0], while -compression wasn't subject to the same requirements.

I would say rather that this mess was cre= ated by your choosing to squat on a code
point right in the middl= e of future allocations.

-Ekr


--000000000000dbe297056d8b3016-- From nobody Thu May 31 19:38: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 18AAD124BE8 for ; Thu, 31 May 2018 19:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnUm6_BC3yOT for ; Thu, 31 May 2018 19:38:14 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633971200E5 for ; Thu, 31 May 2018 19:38:14 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id m5-v6so30472145qti.1 for ; Thu, 31 May 2018 19:38:14 -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=WBNDLPYde89ZNG7JooOu/u7wOTx4KpRFfiZWPgW+zig=; b=qI6NwE8AJjSuqANbHVC2eGNrYaZnj31RspsRS1D9FE9q1/R2zePkGaS1Z+LkbvZ+/o bL61llrMFlt/y2EvkOfxeM3N9MDk5CVnTLZblg45w4eJ2OHwh4nQGYpgMJpsIVwYQdSG X+rsPbZvbnEGg6YB1Hr4Uodw1lkHvCTpl6Wj71OvreuZts9UFkOJSIEkEtdBy8nID7BN Ll/QHTa2rtKWyOlKb1x9+NjL7Zwc7Q7z7qXR2d9boUoh3ZcppjsjsS/4EuGe2a6/6tCf tg+VmVNXdPCeoKdcuwpaXkRAfUbeyo6XtUUpcZbQbapcia0GT5Lk/ZCtktcYuEZnxNp0 RpDQ== 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=WBNDLPYde89ZNG7JooOu/u7wOTx4KpRFfiZWPgW+zig=; b=IzjxynGyv9gD456a+XSrk8TpExQMZQYCGesyGSDvkRwuLWjPpuVtFf7/0i3iTqtQsD I5dbwh+Bsco2EOibIHH19hskJHZRdVsqupqUD2Rk8dR80p6gcPOTDQK6Tj3pTIyC/nsy WaAgMyNHmshgx+nQyiD8z0yOBpwoe7/wsId5xxLlYtwWkDQooZM6ySLDQzPrzHmQxYlw CeE5riF+3D+KUweAbI0HCnehIW9AljQZlAEZwYWFGc3xsoeaSGXyFb92MUMLp39tIc3h UCAV5VSSKr7Sae7ZzCbzNB/iQ3a/gz3RydHpDy+CIsolhjAJQIhFaA1fuHl4gNYib4ON rbGA== X-Gm-Message-State: APt69E2mNMhsArcjynuA31y1HRDNcQttOugYbRHRg70VtKNYj0JF5J0M ham650Q//Ns8vFzaglwsUrdVoU3dcB3hKdr3A8WUUw== X-Google-Smtp-Source: ADUXVKKIlToTcEkjdZNmIIV+JGX5mFtjrk7BVFrTbdFpfXDeJdhK/cnlq8cTYTC2Nw4Rrfr7KFCokgrJEx3YPpP7v88= X-Received: by 2002:ac8:1105:: with SMTP id c5-v6mr9031044qtj.307.1527820693394; Thu, 31 May 2018 19:38:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:370e:0:0:0:0:0 with HTTP; Thu, 31 May 2018 19:37:52 -0700 (PDT) In-Reply-To: <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> From: Joseph Salowey Date: Thu, 31 May 2018 19:37:52 -0700 Message-ID: To: Sean Turner Cc: TLS WG , draft-ietf-tls-certificate-compression@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5eb66056d8b79a6" Archived-At: Subject: Re: [TLS] early code points assigned (was Re: 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: Fri, 01 Jun 2018 02:38:18 -0000 --000000000000b5eb66056d8b79a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since there is a conflict with deployments with extension code point 26 IANA has now assigned the compress_certificate extension code point 27 from the TLS extensionType values registry. On Wed, May 23, 2018 at 6:23 PM, Sean Turner wrote: > IANA has assigned the following values: > > 1) In the ExtensionType Values registry, the following entry was added: > > 26 compress_certificate (TEMPORARY - registered 2018-05-23, expires > 2019-05-23) [draft-ietf-tls-certificate-compression] > > Please see > https://www.iana.org/assignments/tls-extensiontype-values > > 2) In the TLS HandshakeType Registry, the following entry was added: > > 25 compressed_certificate (TEMPORARY - registered 2018-05-23, expire= s > 2018-05-23) DTLS-OK: Y [draft-ietf-tls-certificate-compression] > > Please see > https://www.iana.org/assignments/tls-parameters > > > > NOTE: IANA can=E2=80=99t create the registry for the compression algorith= ms until > the document is approved by the IESG, but Ben (and the chairs) figured we > didn=E2=80=99t really need that to get this going. If additional compres= sion > algorithms start to get used, let=E2=80=99s make sure to note what they a= re. > > spt > > >> From: Sean Turner > >> Subject: early code point assignment for draft-ietf-tls-certificate- > compression > >> Date: April 23, 2018 at 12:33:08 EDT > >> To: TLS WG > >> > >> 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 cod= e > 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 describe= d > >> in an Internet-Draft. > >> > >> When asked at IETF101 what other outstanding comments there were on th= e > 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 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=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, bu= t > 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 > --000000000000b5eb66056d8b79a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since there is a conflict with deployments with extension = code point 26 IANA has now assigned the=C2=A0com= press_certificate extension code point 27 from the TLS extensionType values= registry.=C2=A0=C2=A0

On Wed, May 23, 2018 at 6:23 PM, Sean Turner <sean@sn3rd.co= m> wrote:
IANA has assigned= the following values:

1) In the ExtensionType Values registry, the following entry was added:

26=C2=A0 =C2=A0 =C2=A0 compress_certificate (TEMPORARY - registered 2018-05= -23, expires 2019-05-23)=C2=A0 =C2=A0 [draft-ietf-tls-certificate-comp= ression]

Please see
https://www.iana.org/assignments/tls= -extensiontype-values

2) In the TLS HandshakeType Registry, the following entry was added:

25=C2=A0 =C2=A0 =C2=A0 compressed_certificate (TEMPORARY - registered 2018-= 05-23, expires 2018-05-23)=C2=A0 DTLS-OK: Y=C2=A0 =C2=A0 =C2=A0 [draft-ietf= -tls-certificate-compression]

Please see
https://www.iana.org/assignments/tls-parameters<= /a>



NOTE: IANA can=E2=80=99t create the registry for the compression algorithms= until the document is approved by the IESG, but Ben (and the chairs) figur= ed we didn=E2=80=99t really need that to get this going.=C2=A0 If additiona= l compression algorithms start to get used, let=E2=80=99s make sure to note= what they are.

spt

>> From: Sean Turner <sean@sn3rd= .com>
>> Subject: early code point assignment for draft-ietf-tls-certificat= e-compression
>> Date: April 23, 2018 at 12:33:08 EDT
>> To: TLS WG <tls@ietf.org>= ;
>>
>> 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) c= ompressed_certificate in the TLS HandshakeType Registry, then please let th= e list know why by 2359UTC on 10 May 2018.=C2=A0 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-certific= ate-compression.=C2=A0 The one technical comments raised at the meetin= g was extending 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 r= epo and once they submit a new version of the draft the process for an earl= y 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 assignment are:
>>
>> Criteria A
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The code points must be from a space des= ignated as "RFC
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review",= or "Standards Action".=C2=A0 Additionally,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code po= ints from a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" regis= try are allowed if the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RF= C.
>>
>> The Transport Layer Security (TLS) Extensions and TLS HandshakeTyp= e Registry registries are both RFC Required.=C2=A0 While we=E2=80=99re chan= ging that registry=E2=80=99s rules with draft-ietf-tls-iana-registry-u= pdates, there=E2=80=99s still every intention to publish draft-ietf-tls-cer= tificate-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 o= ther rules related to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0handling the protocol entities defined b= y the code points
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(henceforth called "specifications&= quot;) must be adequately described
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0in an Internet-Draft.
>>
>> When asked at IETF101 what other outstanding comments there were o= n the draft the only one identified was increasing the code point size for = the compression 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 intero= perable.
>>
>> At IETF101, it was noted that this specification was stable enough= .=C2=A0 Implementation issues might be identifier later, but, well, that=E2= =80=99s the point.
>>
>> Criteria D
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The Working Group chairs and Area Direct= ors (ADs) judge that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0there is sufficient interest in the comm= unity for early (pre-RFC)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementation and deployment, or that f= ailure to 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 experimentati= on).
>>
>>
>> There are also 6 steps identified in RFC 7120 for early assignment= , but only four involve the chairs:
>>
>>=C2=A0 1.=C2=A0 The authors (editors) of the document submit a requ= est for early
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0allocation to the Working Group chairs, = specifying which code
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0points require early allocation and to w= hich document 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= assignments.=C2=A0 There was also an earlier on-list request.
>>
>>=C2=A0 =C2=A02.=C2=A0 The WG chairs determine whether the condition= s for early
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0allocations described in Section 2 are m= et, particularly
>>=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 consensu= s within the WG that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0early 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.
>>
>>=C2=A0 =C2=A04.=C2=A0 If steps 2) and 3) are satisfied, the WG chai= rs request approval
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0from the Area Director(s).=C2=A0 The Are= a Director(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 i= t to Ben.
>>
>> spt
>

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

--000000000000b5eb66056d8b79a6--