From nobody Mon Sep 4 09:41:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB1126C19 for ; Mon, 4 Sep 2017 09:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rldh6en3VF2b for ; Mon, 4 Sep 2017 09:41:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0025712422F for ; Mon, 4 Sep 2017 09:41:11 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 51CEDC01CB6D; Mon, 4 Sep 2017 16:41:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 51CEDC01CB6D Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CDA3781520; Mon, 4 Sep 2017 16:41:10 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Hannes Tschofenig , Ilari Liusvaara , Noah Robbin Date: Mon, 04 Sep 2017 18:41:00 +0200 Message-ID: <15201865.l3BCi0DyzW@pintsize.usersys.redhat.com> In-Reply-To: <0d245ef4-78c7-3050-0d52-0a185180476e@gmx.net> References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <0d245ef4-78c7-3050-0d52-0a185180476e@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2541631.HF9LKySmaK"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 04 Sep 2017 16:41:11 +0000 (UTC) Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Sep 2017 16:41:14 -0000 --nextPart2541631.HF9LKySmaK Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 29 August 2017 13:20:33 CEST Hannes Tschofenig wrote: > Hi Noah, Todd, Ilari, >=20 > the HRR is used for two purposes, namely > * to report an error (with the key shares), and > * for DoS protection. >=20 > In both cases it feels excessive to require that the two ClientHellos > are the same (with some minor exceptions). I see this as particularly > problematic for the use with DTLS since with connectionless transport > protocols the use of the HRR is obviously common and we are essentially > wasting bytes on the wire for no good reason(with every handshake). >=20 > For the return-routability check there will be a cookie in the HRR and > the RR check is useful primarily for connectionless transports. > Re-transmitting the same information twice in this case is of doubtful > value since (a) either the cookie contains the necessary info already or > (b) the second ClientHello carries the relevant information. >=20 > Does this make sense? Yes, though different Client Hello's can make the server select different s= et=20 of algorithms (for example see Google selecting Chacha20 and AES-128-GCM ov= er=20 any else, but allowing the client to dictate which is actually negotiated i= f=20 both are advertised). The second hello after modifications can cause the=20 algorithm to select different values, despite HRR committing to specific se= t.=20 Obviously that would be bad Second thing is that if the second Client Hello is supposed to be identical= to=20 first one with few exceptions, the server does not need to parse or verify = it=20 fully before responding with Server Hello.=20 =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 --nextPart2541631.HF9LKySmaK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZrYIcAAoJEJKo0bgB0vX1SXgQAI8lzK3DhMV5LqOqIFfLTVFd wiPxYphx92/ujE/DQbgoamk8n6EoHy7DqFhsDTAI70bM5vyaQvFXG6L4tbYfzwdj sZPT48opmZAR8mIYDnmPv07/tXKRq4p8sJgSqYqVCsSPO8tx3NmAgd8jZATuR723 ugli291588GdPqmxMAy4Z2DlzHxwyDFIICzsZsiURUEW990bbJdY5yt36Dt636VT ZWJjBxodUc4He7j+CtvCZQUE5iVyfvTS1O3ZZ3Ve3K0EwdUp8UU4deQdDy1brg05 pZBhhCrbo7ROOU63PaoNfbRnhVXAsDulcJ2gh2PGgz2UdTOyqwg1DZW+IvsxWY56 ZOdPwDsc650WtK4LeVI9Sp9BPwtv3EOA2p9kVGgmM8MUm6oWu9q5Q9IYwyHCA5DI KMarJrHAsj0xVwGAjsjIKDKwtbD5kkA8+x6MeBFBLuR02XMs5U5l1LLfHF/bUAPm qFuPWduvBUP9WLAnx6emZm8G+cIM9XntNGQk2dhZpsKgpXLsvXa4st/ErYeUzSoQ jyUTifQ3gpl7JeiNT1X2+n1U/n7F2C7KPETNXK6OXM5sBJhAZ1hzIc/8hhEtVVei tJWmykjpKlFwRUh3SkcJ2XSsZ8al/P/dNi1ckJciS/eMR9m30Q8No9AOxyWOXyRi GGyjS67KSHOTxMoq7iw+ =kAtk -----END PGP SIGNATURE----- --nextPart2541631.HF9LKySmaK-- From nobody Mon Sep 4 13:59:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B121320B5 for ; Mon, 4 Sep 2017 13:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyWtRP7XZDoK for ; Mon, 4 Sep 2017 13:59:46 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D4AC212426E for ; Mon, 4 Sep 2017 13:59:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 148925DE5C; Mon, 4 Sep 2017 23:59:43 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id r05nDLtMg0x3; Mon, 4 Sep 2017 23:59:42 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2B2DE28A; Mon, 4 Sep 2017 23:59:38 +0300 (EEST) Date: Mon, 4 Sep 2017 23:59:37 +0300 From: Ilari Liusvaara To: Martin Thomson Cc: Benjamin Kaduk , Noah Robbin , "tls@ietf.org" Message-ID: <20170904205937.xvm6bt2wvowjgwpq@LK-Perkele-VII> References: <89458B97-EEB1-4F3C-8624-796447B21CC2@symantec.com> <20170822201354.ojkuap7simes4g4v@LK-Perkele-VII> <1ca03f97-2a16-0eea-ea2c-38e36b303bbf@akamai.com> <20170830125734.6gcnuwez4fprsajo@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] What counts as the same ClientHello? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Sep 2017 20:59:48 -0000 On Thu, Aug 31, 2017 at 09:50:07AM +1000, Martin Thomson wrote: > On 30 August 2017 at 22:57, Ilari Liusvaara wrote: > > However, I identified a new category of extensions that I didn't notice > > before: Dependent on altered extensions. There are no such standardized > > extensions, but there is at least one proposal (in WG draft stage). > > Is it possible that you could help us by sharing which one? early_token_binding from draft-ietf-tokbind-tls13-0rtt However, looks like in this case, the server advertises support for this in an NST extension, so at least it doesn't get thrown to random servers. Thinking about this more, it seems that any field or extension that could be different across retry falls into one of three categories: 1) Something related to 0-RTT. 2) Something "feral": These things basically do not play by the normal rules[1]. 3) Something that does not actually negotiate state[2]. Altering anything else will probably provoke Undefined Behavior due to unknown state commitments. [1] E.g., anything that goes into HelloRetryRequest or ServerHello, and supported_versions. [2] E.g. (Random), Padding. -Ilari From nobody Thu Sep 7 22:53:13 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD605132355; Thu, 7 Sep 2017 22:53: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.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150484998666.7954.16560416520844307625@ietfa.amsl.com> Date: Thu, 07 Sep 2017 22:53:06 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-record-limit-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 05:53: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 : Record Size Limit Extension for Transport Layer Security (TLS) Author : Martin Thomson Filename : draft-ietf-tls-record-limit-01.txt Pages : 7 Date : 2017-09-07 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 7 22:55:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACEE1330C3 for ; Thu, 7 Sep 2017 22:55:01 -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 k4fLJAzBrSf2 for ; Thu, 7 Sep 2017 22:55:00 -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 005521330D2 for ; Thu, 7 Sep 2017 22:54:59 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id z73so6315311oia.2 for ; Thu, 07 Sep 2017 22:54:59 -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=kADVihNX+RUUXRqFeLNDdqHcGt6CJDPRiIlie2NWmtc=; b=uWyiYjkaK8SPrua1nPsHbM4Xecxmaowc78F6GqIdMWndyWcJv/Y7apHfFl/eTc4ZSo BokU6VnS3gDUcn7Q/IDlu5NRfFRPBJ+W6s7rgbgP8hueJqyxZpzb7hzF8JzD92dEXhOK NOH4A+yFl5G0GK42YXz+hwx/IwY5sRxgIt4x5jXeWHZBYdC/DPb6Aj5R1PiFEy9Zp5JN /QcZLSbSB99X2E3KX3HSdKKo2KzUK1XkVEjTpRUXUUS2iq6YRZOHgXRFBHZwIbVWrBCb IcMdC0AYzLqcPHVszIfowq14JnsQT0FpQZPgKI0Gaoh7GW3wmqPvtgB+J3Udy3gdML7Y GFZQ== 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=kADVihNX+RUUXRqFeLNDdqHcGt6CJDPRiIlie2NWmtc=; b=AoLBYjQ61NIJbae8ivLI72eDipRJQS5DpTachAl39cmwMVf8kqQBQ3GDqtnbELqGvj 8p95IXdpsF2DRG+rjWBfOh8nzT1Zxyn28YOeudrJZGtFwhBYZSOTmCMguWvGP9tMTqI9 yEqxOQkyOuAdxe0HdNwesdUO3YARNuJlc8MXw37k9NKOWyNu9JXgTxalUEWkbKdLQU9F Ttmm/8uStk5mTpTicLM5rt/LmzFWabl0QYFwTMDl2nWqkrFig92+A/jtl7Km8Zimnnth qF8mUwyH1x1WY0y2r6C5WYPp6wNEkod5beiLx7OUt7aM2pfCr+G0EYsfdoobETWAqa8M EzCw== X-Gm-Message-State: AHPjjUgBFSIagj97IqrRkN0b/ZYo4iuc7CBGOL/oDsvJeXW6wF2a00R6 6FlH7cBZfS7gxpqhlU5uRwHu8KXbHGYz4rQ= X-Google-Smtp-Source: AOwi7QC5jYMPn3jNmnt2spi/ACBNZqHfPvj6Lm8Jr+N90JwxiWwzN2HFn66SJRjXv15Cuz4b7K0gIYvp8s7uGP1UBxY= X-Received: by 10.202.86.132 with SMTP id k126mr1658186oib.277.1504850099145; Thu, 07 Sep 2017 22:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Thu, 7 Sep 2017 22:54:58 -0700 (PDT) From: Martin Thomson Date: Fri, 8 Sep 2017 15:54:58 +1000 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] New version of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Sep 2017 05:55:01 -0000 I just posted draft-ietf-tls-record-limit-01. The changes here are relatively small, but of note: * endpoints are required to generate a record_overflow alert if the other side exceeds a negotiated limit * the size limit calculation is better defined in a few ways (this includes PR#1 that we discussed during adoption, but the draft also defines the limit as it applies to TLS 1.2 and earlier) * there is a new paragraph describing what to do with renegotiation This now has no open issues. I'd like to see whether anyone implements (and whether we can interoperate), but I consider this to be basically done until reviews tell me otherwise. From nobody Fri Sep 8 15:59:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96688129A89 for ; Fri, 8 Sep 2017 15:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65tLlTs4xikn for ; Fri, 8 Sep 2017 15:59:44 -0700 (PDT) Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FE1124F57 for ; Fri, 8 Sep 2017 15:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=FzgwSfw0xa/jHw6GJe3gL2IubZ1+kEp+/Mi8euyNQRk=; b=opweNk05Sk4CyAL/rbL7quJ3W9oREFRsLXCt5xLGuPgwtavs4el9VF40xzO4CokTQrk6sYQzK9DP2Dz2MGEU1u+jqrri8MSgGBIt4yIYCRMuUrFhAb0EW3bt7bTwFp+BSw9GATk2yPB4tct1pFiTvEiSuvCRpOFBLDnZkjgnA1tM3pEXSn+1Q1KfHontX92O7n1rKJU3qEmAO9/ZsGBQg2c0isXXy3xU3CiAOtOUXPCY+gkA9HPhQpClJccDGxhbCq+UmntK84Pq13fGCDnL0+iFAkSr9JCCzUPWM8slcYpT5bQogOYEjY+L+LPxp8mAptyPVQz20c1im5dv3vVa5Q==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dqSFN-0000UJ-Ra for tls@ietf.org; Sat, 09 Sep 2017 00:59:41 +0200 Date: Fri, 8 Sep 2017 23:59:48 +0100 From: Peter Wu To: tls@ietf.org Message-ID: <20170908225948.GC31695@al> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 22:59:47 -0000 Hi! While working on adding RSASSA-PSS support to Go's crypto/tls library (TLS 1.2), I have noticed something that may cause interop problems later. The current draft says the following about Server Certificate Selection (https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2): - The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's "signature_algorithms" extension. In TLS 1.2, the cipher suite was responsible for selecting the hash function and signature algorithm (e.g. for ServerKeyExchange) while "signature_algorithms" directed what certificate signatures are accepted. But in TLS 1.3, this also influences what algorithms can be used for signing handshake messages (CertificateVerify). This results in possible interop problem: while implementations advertise RSASSA-PSS support in "supported_algorithms" because they can indeed sign/verify handshake messages with said algorithm, they might not be able to accept certificates with a RSASSA-PSS signature (because the PKI library does not implement it for example). And because PSS certificates are non-existent now, it will only be discovered later. Some implementations I have checked wrt RSASSA-PSS support: - Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet. - tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates. - BoringSSL - failed, "bssl server" rejects cert. - OpenSSL - failed, s_server rejects cert. Related: https://github.com/openssl/openssl/issues/2878 - NSS - not checked, but I think it has the same problem as tls-tris. Related: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 These implementations will require fixing, but at the moment it is just broken. Is this the expected behavior/intention? While RSASSA-PSS is quite well understood for handshake messages, its restrictions for certificates are not explicit. Currently the draft limits the salt length for handshake messages, but what about certs? What is needed for a TLS implementation to claim support for RSASSA-PSS? In particular, for certificates: - Limitations on salt length? - What AlgorithmIdentifier OID to use? - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash algorithm, trailerField)? -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Sat Sep 9 04:37:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA4F132716 for ; Sat, 9 Sep 2017 04:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ55Pmsm2CDc for ; Sat, 9 Sep 2017 04:37:37 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD15126C19 for ; Sat, 9 Sep 2017 04:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id CD3E25DE3F; Sat, 9 Sep 2017 14:37:34 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id FXPrY-W3SgVr; Sat, 9 Sep 2017 14:37:34 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 464DBC4; Sat, 9 Sep 2017 14:37:32 +0300 (EEST) Date: Sat, 9 Sep 2017 14:37:31 +0300 From: Ilari Liusvaara To: Peter Wu Cc: tls@ietf.org Message-ID: <20170909113731.dxiu65q5wsfgj6qn@LK-Perkele-VII> References: <20170908225948.GC31695@al> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170908225948.GC31695@al> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 11:37:40 -0000 On Fri, Sep 08, 2017 at 11:59:48PM +0100, Peter Wu wrote: > Hi! > > While RSASSA-PSS is quite well understood for handshake messages, its > restrictions for certificates are not explicit. Currently the draft > limits the salt length for handshake messages, but what about certs? > What is needed for a TLS implementation to claim support for RSASSA-PSS? > > In particular, for certificates: In the implementation I wrote: > - Limitations on salt length? Salt must be the same length as hash output. > - What AlgorithmIdentifier OID to use? The following are used: 1.2.840.113549.1.1.10 RSA-PSS 1.2.840.113549.1.1.8 MGF1 2.16.840.1.101.3.4.2.1 SHA-256 (NULL optional) 2.16.840.1.101.3.4.2.2 SHA-384 (NULL optional) 2.16.840.1.101.3.4.2.3 SHA-512 (NULL optional) 2.16.840.1.101.3.4.2.8 SHA3-256 (Parameters absent) 2.16.840.1.101.3.4.2.9 SHA3-384 (Parameters absent) 2.16.840.1.101.3.4.2.10 SHA3-512 (Parameters absent) > - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash > algorithm, trailerField)? The other constraints: - Only MGF1 is supported. - The MGF hash must be the same as the data hash. - TrailerField must be absent (indicating default). Basically, that implementation supports exact matches (and variants with SHA-2 substituted by SHA-3) of the TLS schemes. -Ilari From nobody Sun Sep 10 07:38:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB21326FE for ; Sun, 10 Sep 2017 07:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqlv5E5u8QZF for ; Sun, 10 Sep 2017 07:38:39 -0700 (PDT) Received: from claranet-outbound-smtp09.uk.clara.net (claranet-outbound-smtp09.uk.clara.net [195.8.89.42]) by ietfa.amsl.com (Postfix) with ESMTP id D4806132403 for ; Sun, 10 Sep 2017 07:38:38 -0700 (PDT) Received: from host86-132-183-251.range86-132.btcentralplus.com ([86.132.183.251]:40632 helo=[192.168.1.78]) by relay09.mail.eu.clara.net (relay.clara.net [81.171.239.39]:10465) with esmtpa (authdaemon_plain:drh) id 1dr3NZ-00011S-TZ for tls@ietf.org (return-path ); Sun, 10 Sep 2017 14:38:35 +0000 To: tls@ietf.org References: <20170908225948.GC31695@al> From: Dr Stephen Henson Message-ID: Date: Sun, 10 Sep 2017 15:38:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170908225948.GC31695@al> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 14:38:42 -0000 On 08/09/2017 23:59, Peter Wu wrote: > > In particular, for certificates: > > - Limitations on salt length? > - What AlgorithmIdentifier OID to use? > - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash > algorithm, trailerField)? > Note that you have to check any PSS restrictions in the certificates themselves too. For signatures on certificates this should be handled as part of the normal chain validation process. For restrictions on the EE key this would add additional complications on the digests the key can sign with in the handshake. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ From nobody Mon Sep 11 03:57:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CDA133034 for ; Mon, 11 Sep 2017 03:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlS-JGOxRhKi for ; Mon, 11 Sep 2017 03:57:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652C71241F3 for ; Mon, 11 Sep 2017 03:57:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D933FC004771; Mon, 11 Sep 2017 10:57:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D933FC004771 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (ovpn-200-27.brq.redhat.com [10.40.200.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 76095649D4; Mon, 11 Sep 2017 10:57:30 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 11 Sep 2017 12:57:22 +0200 Message-ID: <1767684.kJgKWaMCIt@pintsize.usersys.redhat.com> In-Reply-To: References: <20170908225948.GC31695@al> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2413443.Y3fWUEiyh1"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 11 Sep 2017 10:57:31 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 10:57:33 -0000 --nextPart2413443.Y3fWUEiyh1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Sunday, 10 September 2017 16:38:32 CEST Dr Stephen Henson wrote: > On 08/09/2017 23:59, Peter Wu wrote: > > In particular, for certificates: > > - Limitations on salt length? > > - What AlgorithmIdentifier OID to use? > > - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash > > =20 > > algorithm, trailerField)? >=20 > Note that you have to check any PSS restrictions in the certificates > themselves too. For signatures on certificates this should be handled as > part of the normal chain validation process. For restrictions on the EE k= ey > this would add additional complications on the digests the key can sign > with in the handshake. That being said, the RFC specifying RSA-PSS recommends that EE certificates= =20 should not have limitations. But yes, if you want to support all valid certificates, you need to check=20 limitations of the EE certificate before you select signing algorithm. But that is also the case if you are using HSM for signing and it doesn't=20 support necessary algorithms (in extreme case, it may even require disablin= g=20 TLS 1.3 support completely). =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 --nextPart2413443.Y3fWUEiyh1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZtmwSAAoJEJKo0bgB0vX1lOIP/j9Wl8yMLWe3DF/jqJJggPFa Tvs6JxFrI3KjupM3RAo81WjuFDqSY+WHpEK6w++NolUE3hAoVoR+kEbh/84WyqyM +uF/POeTc+PKh62oa5DECtZJr1zlrRyDuQSHQBlbfcVxvQRZkk+vP077JZkW6fbd N6FOOxEtFM4v/mv357IiuFvy7Vb/7+RhLFj+7cr6xafs5a95egpBCt4FpRKmsfTr q0quEqlTRdiM7wEiDKLFiqvU6CcuGT7Pan6tI0Xl4khkbsL0WipsliRkN/yqxxKO wvzRp2kSWsl9hp6Wk4nsdKyuzn/4ImcxAuJghS0j2sHI69YpI6ziuRVt33SGemB8 vE9+9VCpHBfBhEUDvZgRmRw9wG2JoH3FdrAU+3GT61fVDy4qOcLA+oyH90RtnToU WtH2FbkF8MPChul4dcVFQMbGUNvnKFfj5QU5iP3RtMKodPZTzngpgIAixPv3ARNE NhLgPgWIfl9rgEjHJGb2VDZMGVQsAz65HUkNwNiG3LPj/yHVxyzVog8/Aj8oS5a5 8cHxCCLIjdGeKndsDSHxYPWsZnk6VkXERx/RuZ/7fNn57ojh7KufrY5KUqixN99C YKc3/xR3/UZMK5XQOLGU0mwJcWMWD8IyEcCBPto6v92/SzICM6f3CHRj9XfIuNuV WhOghs8Npba7Ios/hWbV =u6YO -----END PGP SIGNATURE----- --nextPart2413443.Y3fWUEiyh1-- From nobody Mon Sep 11 04:00:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CCE133031 for ; Mon, 11 Sep 2017 03:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDCF9Zj6Y4QS for ; Mon, 11 Sep 2017 03:59:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52EB132D17 for ; Mon, 11 Sep 2017 03:59:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 71E30CD678; Mon, 11 Sep 2017 10:59:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 71E30CD678 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (ovpn-200-27.brq.redhat.com [10.40.200.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 29FFA67561; Mon, 11 Sep 2017 10:59:57 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 11 Sep 2017 12:59:55 +0200 Message-ID: <3402819.qtnCg0jKDh@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1847501.TeJxxhPyfe"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 11 Sep 2017 10:59:57 +0000 (UTC) Archived-At: Subject: Re: [TLS] New version of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Sep 2017 10:59:59 -0000 --nextPart1847501.TeJxxhPyfe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 8 September 2017 07:54:58 CEST Martin Thomson wrote: > I just posted draft-ietf-tls-record-limit-01. >=20 > The changes here are relatively small, but of note: >=20 > * endpoints are required to generate a record_overflow alert if the > other side exceeds a negotiated limit >=20 > * the size limit calculation is better defined in a few ways (this > includes PR#1 that we discussed during adoption, but the draft also > defines the limit as it applies to TLS 1.2 and earlier) >=20 > * there is a new paragraph describing what to do with renegotiation what about session resumption? =20 > This now has no open issues. I'd like to see whether anyone > implements (and whether we can interoperate), but I consider this to > be basically done until reviews tell me otherwise. >=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 --nextPart1847501.TeJxxhPyfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZtmyrAAoJEJKo0bgB0vX1VSoP/0Vg2qEVWGvaxNyeX15Ocnwl ZXvWDf3j87mw0LX3Lmhk1S4rToOiByYb0oQnlt9BQJGY5gr5yTA7VeW4BCnA2hMG zzLNSEeinTrXvNUBa6rPFszShOQWrARjr2sRPScxsRf7ilA5LYs6gpjcJIOW55bp 15GVUgWjxznTpltE8nIPB0UOzXDI5v7UT47LPvamCIoXLuYuljgbUJ+4mrqwNcYg vYn9+uLKzvdezXMVAekUv2L7zWZa6iKNajIq10oZVzgtoGC/LaaOi4M7UKM6fzUm JYzISa5fpOtLTh8+BPpFHk7lWgq5I2lRY2ztxVecEu6iG9+3hyTQPWVMQgZkUiJf x43cRTqyQb9S3iiciJ2yCivcHPCNRwcr0T52VEkIQ++jCjaBXUZOs2CJ8TwR3URL CvwmTkIEUQt7F9ybqvPwyS4NTYwpB6L+GHkK+o/A5jB7/3JTBhtn434xSvvkcasz EhHx7O9ciu+lYqBpnlLTu6JkGi2YX1MEK8Jtn6xhzdqEUh96p0URsippIyASY22+ mmy1lNI6DVhGR1vPIr64WTA6U3x4fYHXDP9wh15mSwxZcgF7BMXmLQaR4ZHrUnYd 9CTD6ndxz5Veb62/4/svYTUr8UWLmbEpzR1Ltte+zrq6ImJpSo4hHMyCAHaMxdjc 0J4rGwKC7maOWQJTo/7Q =9j8G -----END PGP SIGNATURE----- --nextPart1847501.TeJxxhPyfe-- From nobody Mon Sep 11 11:42:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB000132ECE for ; Mon, 11 Sep 2017 11:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1_BjqSrYvW5 for ; Mon, 11 Sep 2017 11:42:46 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2867D132697 for ; Mon, 11 Sep 2017 11:42:46 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g32so14590252ioj.2 for ; Mon, 11 Sep 2017 11:42:46 -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=rl+CsamRW9M6OcwSCNhOegsLRqHhooqNDKxuTAm7JGI=; b=AysWzip8V3lukuJq3J3IMyqKIL2rtklNrMo4+xeoW/ItzHg5E/I1dLQOWRls7L8dwC Zpd0v2RN9LCkVY72Odl/1m6m7kDTbrmk9Iy9/VcVnYjadh0w+Y/yyqph7120lHU746o6 i5+ebMhzcZtYP0fk7M97y2K74vPlV2TdL+JpAb1Mjf2ph1xW9pMoR5fSZmomXxpNq6Se L5qLe0isragO6LAVhOV/xmMyKmCTBWzjw+JFm2yMVDGqij0TEuwVMX6B31bAqIr0T5u/ J08E6cWxMR8K22cCZaG6kjzHyXYn6+HtBLRbzT4k5iLOGc7nmuil8fH6P5fYsU8zyksF L7og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=rl+CsamRW9M6OcwSCNhOegsLRqHhooqNDKxuTAm7JGI=; b=h8KcoH3waSLQ7XBltOk8t7mTBDJrDoOrHR7zt4519mo8hhk71+8XuPltuLlCdaJaZh qUDEUD1zgUcNdXb1YB0e2KZYDKN3NFg7yJFf5i/Z8cY3wM8stc9z2PES4v9CkesqzDC/ zurjZ2GLkJ5oL4uv6vz+pc37o5ky401h9NJqtxr7J1un9ni5y5tY8x4l56tpKXjOK1OV gZJCd/6IiS7ZZA4Z1/mTTZvDLGHhQSPPR0LisU+OnzpOEMFiPtZsMA3YR47HDElBIkz3 jG+20kCxUYDPIJiwDbdF90eIbkkDnuVY8SBZriJNIlf51DcDR6XqDU+QNHOvrG0OUcqb ec7Q== X-Gm-Message-State: AHPjjUg/2Se9WlZ9d/QYschJmsDf+scM/UEx0wVakjkXvMTiqk8xPEqX MD68vc4yJsw7h/zysz5My2S6WXQ9mc/spyA= X-Google-Smtp-Source: AOwi7QA6a0djtp0wXDe1nBpncLHCczYIg9mZAUKNYWj+IpsUqsi3JJ+qcf4a4rVoy6nrIvfk7nmgnUJh++YN4jVKeLE= X-Received: by 10.202.224.130 with SMTP id x124mr11139731oig.100.1505155365409; Mon, 11 Sep 2017 11:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.10.71 with HTTP; Mon, 11 Sep 2017 11:42:03 -0700 (PDT) In-Reply-To: <20170908225948.GC31695@al> References: <20170908225948.GC31695@al> From: Eric Rescorla Date: Mon, 11 Sep 2017 11:42:03 -0700 Message-ID: To: Peter Wu Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113d376ae333570558ee4ab0" Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:42:49 -0000 --001a113d376ae333570558ee4ab0 Content-Type: text/plain; charset="UTF-8" Ugh. Generally, the idea with signature schemes is that they are supposed to reflect both the capabilities of your TLS stack and the capabilities of your PKI verifier [0]. So, yes, if you advertise this it is supposed to work. So, ideally we would just say that it's as Ilari says in his followup. It seems like there are really two choices: 1. Only advertise algorithm X if you support algorithm X in both places 2. Invent a new extension whose semantics are "if present, this tells you what the PKI validator accepts, otherwise look at signature schemes" I hate to be suggesting #2 at this stage in the process, but maybe it's right anyway... -Ekr [0] I recognize that there are people who think that TLS shouldn't say anything about the PKI verifier, but I don't think that this is viable, for exactly the reason shown here: it's possibly to have an algorithm which is widely supported in TLS stacks but not in PKI verifiers. On Fri, Sep 8, 2017 at 3:59 PM, Peter Wu wrote: > Hi! > > While working on adding RSASSA-PSS support to Go's crypto/tls library > (TLS 1.2), I have noticed something that may cause interop problems > later. > > > The current draft says the following about Server Certificate Selection > (https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2): > > - The certificate MUST allow the key to be used for signing (i.e., > the digitalSignature bit MUST be set if the Key Usage extension is > present) with a signature scheme indicated in the client's > "signature_algorithms" extension. > > In TLS 1.2, the cipher suite was responsible for selecting the hash > function and signature algorithm (e.g. for ServerKeyExchange) while > "signature_algorithms" directed what certificate signatures are > accepted. But in TLS 1.3, this also influences what algorithms can be > used for signing handshake messages (CertificateVerify). > > This results in possible interop problem: while implementations > advertise RSASSA-PSS support in "supported_algorithms" because they can > indeed sign/verify handshake messages with said algorithm, they might > not be able to accept certificates with a RSASSA-PSS signature (because > the PKI library does not implement it for example). And because PSS > certificates are non-existent now, it will only be discovered later. > > Some implementations I have checked wrt RSASSA-PSS support: > - Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet. > - tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates. > - BoringSSL - failed, "bssl server" rejects cert. > - OpenSSL - failed, s_server rejects cert. Related: > https://github.com/openssl/openssl/issues/2878 > - NSS - not checked, but I think it has the same problem as tls-tris. > Related: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 > > These implementations will require fixing, but at the moment it is just > broken. Is this the expected behavior/intention? > > > While RSASSA-PSS is quite well understood for handshake messages, its > restrictions for certificates are not explicit. Currently the draft > limits the salt length for handshake messages, but what about certs? > What is needed for a TLS implementation to claim support for RSASSA-PSS? > > In particular, for certificates: > > - Limitations on salt length? > - What AlgorithmIdentifier OID to use? > - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash > algorithm, trailerField)? > -- > Kind regards, > Peter Wu > https://lekensteyn.nl > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d376ae333570558ee4ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ugh.

Generally, the idea with signature= schemes is that they are supposed to reflect both the capabilities of your= TLS stack and the capabilities of your PKI verifier [0]. So, yes, if you a= dvertise this it is supposed to work. So, ideally we would just say that it= 's as Ilari says in his followup.

It seems lik= e there are really two choices:

1. Only advertise = algorithm X if you support algorithm X in both places
2. Invent a= new extension whose semantics are "if present, this tells you what th= e PKI validator accepts, otherwise look at signature schemes"

I hate to be suggesting #2 at this stage in the process, b= ut maybe it's right anyway...

-Ekr
<= div>
[0] I recognize that there are people who think th= at TLS shouldn't say anything about the PKI verifier,
but I d= on't think that this is viable, for exactly the reason shown here: it&#= 39;s possibly to have an algorithm which is widely supported in TLS stacks = but not in PKI verifiers.



On Fri, Sep 8,= 2017 at 3:59 PM, Peter Wu <peter@lekensteyn.nl> wrote:
Hi!

While working on adding RSASSA-PSS support to Go's crypto/tls library (TLS 1.2), I have noticed something that may cause interop problems
later.


The current draft says the following about Server Certificate Selection
(https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2):

=C2=A0 =C2=A0-=C2=A0 The certificate MUST allow the key to be used for sign= ing (i.e.,
=C2=A0 =C2=A0 =C2=A0 the digitalSignature bit MUST be set if the Key Usage = extension is
=C2=A0 =C2=A0 =C2=A0 present) with a signature scheme indicated in the clie= nt's
=C2=A0 =C2=A0 =C2=A0 "signature_algorithms" extension.

In TLS 1.2, the cipher suite was responsible for selecting the hash
function and signature algorithm (e.g. for ServerKeyExchange) while
"signature_algorithms" directed what certificate signatures are accepted.=C2=A0 But in TLS 1.3, this also influences what algorithms can be=
used for signing handshake messages (CertificateVerify).

This results in possible interop problem: while implementations
advertise RSASSA-PSS support in "supported_algorithms" because th= ey can
indeed sign/verify handshake messages with said algorithm, they might
not be able to accept certificates with a RSASSA-PSS signature (because
the PKI library does not implement it for example). And because PSS
certificates are non-existent now, it will only be discovered later.

Some implementations I have checked wrt RSASSA-PSS support:
=C2=A0- Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet.
=C2=A0- tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates.
=C2=A0- BoringSSL - failed, "bssl server" rejects cert.
=C2=A0- OpenSSL - failed, s_server rejects cert. Related:
=C2=A0 =C2=A0https://github.com/openssl/openssl/i= ssues/2878
=C2=A0- NSS - not checked, but I think it has the same problem as tls-tris.=
=C2=A0 =C2=A0Related: https://bugzilla.mozilla.= org/show_bug.cgi?id=3D158750

These implementations will require fixing, but at the moment it is just
broken. Is this the expected behavior/intention?


While RSASSA-PSS is quite well understood for handshake messages, its
restrictions for certificates are not explicit. Currently the draft
limits the salt length for handshake messages, but what about certs?
What is needed for a TLS implementation to claim support for RSASSA-PSS?
In particular, for certificates:

=C2=A0- Limitations on salt length?
=C2=A0- What AlgorithmIdentifier OID to use?
=C2=A0- Whether to constrain other AlgorithmIdentifier Params? (MGF, hash =C2=A0 =C2=A0algorithm, trailerField)?
--
Kind regards,
Peter Wu
http= s://lekensteyn.nl

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

--001a113d376ae333570558ee4ab0-- From nobody Mon Sep 11 16:52:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AECC132EBF for ; Mon, 11 Sep 2017 16:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AemNIzaJTAz for ; Mon, 11 Sep 2017 16:52:29 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 0A01213202D for ; Mon, 11 Sep 2017 16:52:29 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id j141so36785893ioj.4 for ; Mon, 11 Sep 2017 16:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2HG+C/zX5w3t9XDN88YJGLcBbvFIz8mZuqVJRol0ic=; b=Bh+qbCbufW9ZWy1Z+spiyPoM27v8h8gV1rphGm0KB6zwQzfFJxXKeW8s7DBf1N6rWZ trviNNiIfZSUZ/U8WnL77y7nEnhrI4L61rBe0z+5+vLiwC0soRIhrJdUe0/dEDfcPcSf yybJ9v7NrtjqQB1x8G6jNXm0yYbp3hlB4rVD3Z3cUavB9BIwI2tGUyHi1Xeg+hrawyjm LGpOkzzPIlXZuU9shHKA4AcGqTIM0bvXQUf/naGf9yhv/O9vjFSBN5wXzRGl3IDrFLp1 yHNRoDHbw3fuZil4eWT8dGvhVHTGbTfOUPZmmnDIeFAz3d+CuX5F6f36yqg1bw7RzdLd Gw4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=k2HG+C/zX5w3t9XDN88YJGLcBbvFIz8mZuqVJRol0ic=; b=MeVOfV+e7OWolWpjFoEmUHz3GRQp3FBoBUeFAvEZgbiT4K6svg1OhCk9saPLo1XmwT S/3jupG70HWP6I36ABkGpqNyM8DoxrgbjTMVYmmU/B83c/98/tdEeVLdBp+4Moxyqldr y95vnDy8xZf73P1Vh/uvph5thUU/RzvFezn9i57iWtWTwjSErXbvsv6He+TIyWsaT/KR fhziHRz97m2aA+/cJH2vd9T1jw75YcxwQBj8HODhCWsGsbGqkLc5XaAYMTQBlymD8yZu WiimEFxk+UVUx1hwOM6IWQyeEBDomCUjjtvhf+nbrIpa5T8HnBpxKYTYF8quamVOna17 qTpw== X-Gm-Message-State: AHPjjUi4dopvK+rivHvz6J2dtQnOgCnxdQMM/JZ5jzVF5noiXcH0Q7kr 3eVYt2g1A9n5u0hnKV0axpnmSgS19w== X-Google-Smtp-Source: AOwi7QB1tfqee+IRAUn9lPpR96/HYt8qJsu/9eZCLTJ5Ez6+8YMM9GAbdftwFqzhk1YS2fEWYtZ/qDOw4nxMbqYuq+w= X-Received: by 10.202.87.213 with SMTP id l204mr13237539oib.38.1505173948341; Mon, 11 Sep 2017 16:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.77 with HTTP; Mon, 11 Sep 2017 16:52:27 -0700 (PDT) In-Reply-To: <3402819.qtnCg0jKDh@pintsize.usersys.redhat.com> References: <3402819.qtnCg0jKDh@pintsize.usersys.redhat.com> From: Martin Thomson Date: Tue, 12 Sep 2017 09:52:27 +1000 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] New version of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Sep 2017 23:52:30 -0000 On Mon, Sep 11, 2017 at 8:59 PM, Hubert Kario wrote: >> * there is a new paragraph describing what to do with renegotiation > > what about session resumption? Fixed on the editor's copy. Renegotiation and resumption can be the same. From nobody Mon Sep 11 17:39:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFD133069 for ; Mon, 11 Sep 2017 17:39:19 -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 ZlHQiKoxUaIx for ; Mon, 11 Sep 2017 17:39:15 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722C4132EBF for ; Mon, 11 Sep 2017 17:39:15 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f199so50838919wme.0 for ; Mon, 11 Sep 2017 17:39: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=O3+GnPB9UyLOMdYhpGmFUhCCX+G3LVVwFFyrSq+cLAY=; b=FIsm6OauaYu12lWd0FAH1pBX8VvqSfGZpsojhKw8XEDeIJVsUosDzeD7jaQtc/ootd JTS+K6R1PMtj6c+fD5RmdBp77Hq9sj6jQ4wtPvsZHBTQVSc0dtpT6yNVP4L4la3oxPZX TAgISTEF3x1RXGRFVC5lWZHjvsXrHNsRxkBv0HSvzmdv//dWBU8DIYyYv33h9e2HFoiv 989VlLVcE26gIPWwF0P8g/ILtmQ/LBac9BJPHBF5hxy7ls45wrmFsycMhSaLFOoFytSc XsYnFyZ8/uH0zqAOy3EBr/42VFWL+365JRMx3dmQY2PGQD0VYChlXAb+KptCsUjtD/dh EGgw== 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=O3+GnPB9UyLOMdYhpGmFUhCCX+G3LVVwFFyrSq+cLAY=; b=AAbl9LuHQHLE/YKE9+/q0pTrUsYOjzCDHcpL5T4KgPjPakyOPTHJRuFfmdRZIqeCdh FLTp5btzBSI2188ceLxn8QBJayG2oMtcNu3WgoIbq+o9924lYp+rB/55GJsnfY1UZ6OE ez7CoNIuqPGThIqsxSw2etEUUffLhDS5RO4DKN7pA17+zEtezGyCNqz1c1BDyOqZbCfP nUwuGK95LQf3CFAjiLTFOnDdf68ZeplHoYuvqpre91rjrNaFVlOvakXo0rdtYN3jbhUh Zx9X8NShuGpnwijQAhAZz2l14EdyRpLhQxtrKaBof55Whm3qLCc9mS1HME47Q0ygSbAJ sT1g== X-Gm-Message-State: AHPjjUjOvjA+48b39fW6ujwg9T+TeOjuTgfVEn5Mcy6Ucx7/cOS6eVeM IlP+cagHKcPQ0th1xsFpn3c8EZycnUG/4nXNGo0= X-Google-Smtp-Source: AOwi7QDh8bVm71jmyFMF3NZ1M3+vXtcpbRrYAYNWjw5xRof2Wdlirhk1Zw6BCTSiMIBROa3MqYWWx5TVFu+gzuVMYTc= X-Received: by 10.28.70.133 with SMTP id t127mr1399121wma.42.1505176753806; Mon, 11 Sep 2017 17:39:13 -0700 (PDT) MIME-Version: 1.0 References: <20170908225948.GC31695@al> In-Reply-To: From: Nick Sullivan Date: Tue, 12 Sep 2017 00:39:02 +0000 Message-ID: To: Eric Rescorla , Peter Wu Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d4b5ebc21220558f3452e" Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 00:39:19 -0000 --94eb2c0d4b5ebc21220558f3452e Content-Type: text/plain; charset="UTF-8" This situation is likely to arise every time a new signature algorithm is introduced. Suppose a TLS client library is updated to support Ed25519 certificates, but that the PKIX library only supports validating Ed25519 certificates signed by RSA or ECDSA, which signature schemes should the client present? This is similar to the 2014 issue with ECDSA and Chrome on XP (https://bugs.chromium.org/p/chromium/issues/detail?id=409901), in which the PKIX library didn't support ECDSA, but the TLS stack did. As long as TLS and PKIX libraries are decoupled, the dual meaning of the signature scheme makes the addition of a new algorithm to one or the other a bit messy. For example: In the current situation, it is mandatory to support rsa_pss_sha256, but how many of these clients support certificates signed with PSS? Not many -- including OpenSSL ( https://github.com/openssl/openssl/issues/2878#issuecomment-328576616). Without PSS certificate support, if we chose EKR's option 1, these clients would not be able to support TLS 1.3 according to the spec. This seems like an unnecessary dependency. An easy fix would be to use a different extension for PSS certificates, but this makes the naming and code point definitions more troublesome. Will all new signature schemes get two codepoints, one for the handshake and one for the certificate? The other option, EKR's option 2, seems more promising. This option could be implemented as follows: - keep the old hash and signature algorithm extension from TLS 1.2 to indicate certificate signature support - add a new extension for handshake signature scheme support This would have the additional advantage of allowing us to clean up some of the issues that have been raised before on this list around the numbering of new TLS 1.3 signatureSchemes, specifically the fact that the byte order is backwards for RSA-PSS relative to existing TLS 1.2 values. Nick On Mon, Sep 11, 2017 at 11:43 AM Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed to > reflect both the capabilities of your TLS stack and the capabilities of > your PKI verifier [0]. So, yes, if you advertise this it is supposed to > work. So, ideally we would just say that it's as Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both places > 2. Invent a new extension whose semantics are "if present, this tells you > what the PKI validator accepts, otherwise look at signature schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe it's > right anyway... > > -Ekr > > [0] I recognize that there are people who think that TLS shouldn't say > anything about the PKI verifier, > but I don't think that this is viable, for exactly the reason shown here: > it's possibly to have an algorithm which is widely supported in TLS stacks > but not in PKI verifiers. > > > > On Fri, Sep 8, 2017 at 3:59 PM, Peter Wu wrote: > >> Hi! >> >> While working on adding RSASSA-PSS support to Go's crypto/tls library >> (TLS 1.2), I have noticed something that may cause interop problems >> later. >> >> >> The current draft says the following about Server Certificate Selection >> (https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2): >> >> - The certificate MUST allow the key to be used for signing (i.e., >> the digitalSignature bit MUST be set if the Key Usage extension is >> present) with a signature scheme indicated in the client's >> "signature_algorithms" extension. >> >> In TLS 1.2, the cipher suite was responsible for selecting the hash >> function and signature algorithm (e.g. for ServerKeyExchange) while >> "signature_algorithms" directed what certificate signatures are >> accepted. But in TLS 1.3, this also influences what algorithms can be >> used for signing handshake messages (CertificateVerify). >> >> This results in possible interop problem: while implementations >> advertise RSASSA-PSS support in "supported_algorithms" because they can >> indeed sign/verify handshake messages with said algorithm, they might >> not be able to accept certificates with a RSASSA-PSS signature (because >> the PKI library does not implement it for example). And because PSS >> certificates are non-existent now, it will only be discovered later. >> >> Some implementations I have checked wrt RSASSA-PSS support: >> - Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet. >> - tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates. >> - BoringSSL - failed, "bssl server" rejects cert. >> - OpenSSL - failed, s_server rejects cert. Related: >> https://github.com/openssl/openssl/issues/2878 >> - NSS - not checked, but I think it has the same problem as tls-tris. >> Related: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 >> >> These implementations will require fixing, but at the moment it is just >> broken. Is this the expected behavior/intention? >> >> >> While RSASSA-PSS is quite well understood for handshake messages, its >> restrictions for certificates are not explicit. Currently the draft >> limits the salt length for handshake messages, but what about certs? >> What is needed for a TLS implementation to claim support for RSASSA-PSS? >> >> In particular, for certificates: >> >> - Limitations on salt length? >> - What AlgorithmIdentifier OID to use? >> - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash >> algorithm, trailerField)? >> -- >> Kind regards, >> Peter Wu >> https://lekensteyn.nl >> >> _______________________________________________ >> 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 > --94eb2c0d4b5ebc21220558f3452e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This situation is likely to arise every time a new signatu= re algorithm is introduced. Suppose a TLS client library is updated to supp= ort Ed25519 certificates, but that the PKIX library only supports validatin= g Ed25519 certificates signed by RSA or ECDSA, which signature schemes shou= ld the client present? This is similar to the 2014 issue with ECDSA and Chr= ome on XP (https://bugs.chromium.org/p/chromium/issues/detail?id=3D409901), in which the PKIX library didn't support ECDSA, but the TLS stack = did. As long as TLS and PKIX libraries are decoupled, the dual meaning of t= he signature scheme makes the addition of a new algorithm to one or the oth= er a bit messy.

For example: In the current situation, it is mandato= ry to support rsa_pss_sha256, but how many of these clients support certifi= cates signed with PSS? Not many -- including OpenSSL (https://github= .com/openssl/openssl/issues/2878#issuecomment-328576616). Without PSS c= ertificate support, if we chose EKR's option 1, these clients would not= be able to support TLS 1.3 according to the spec. This seems like an unnec= essary dependency.

An easy fix would be to use = a different extension for PSS certificates, but this makes the naming and c= ode point definitions more troublesome. Will all new signature schemes get = two codepoints, one for the handshake and one for the certificate? The othe= r option, EKR's option 2, seems more promising.

This option could be implemented as follows:
- keep the old= hash and signature algorithm extension from TLS 1.2 to indicate certificat= e signature support
- add a new extension for handshake signa= ture scheme support

This would have the additi= onal advantage of allowing us to clean up some of the issues that have been= raised before on this list around the numbering of new TLS 1.3 signatureSc= hemes, specifically the fact that the byte order is backwards for RSA-PSS r= elative to existing TLS 1.2 values.

Nick

On Mon, Sep= 11, 2017 at 11:43 AM Eric Rescorla <ekr= @rtfm.com> wrote:
Ugh.

Generally, the idea with signature schemes= is that they are supposed to reflect both the capabilities of your TLS sta= ck and the capabilities of your PKI verifier [0]. So, yes, if you advertise= this it is supposed to work. So, ideally we would just say that it's a= s Ilari says in his followup.

It seems like there = are really two choices:

1. Only advertise algorith= m X if you support algorithm X in both places
2. Invent a new ext= ension whose semantics are "if present, this tells you what the PKI va= lidator accepts, otherwise look at signature schemes"

I hate to be suggesting #2 at this stage in the process, but maybe= it's right anyway...

-Ekr

=
[0] I recognize that there are people who think that TLS s= houldn't say anything about the PKI verifier,
but I don't= think that this is viable, for exactly the reason shown here: it's pos= sibly to have an algorithm which is widely supported in TLS stacks but not = in PKI verifiers.



On Fri, Sep 8, 2017 at= 3:59 PM, Peter Wu <peter@lekensteyn.nl> wrote:
Hi!

While working on adding RSASSA-PSS support to Go's crypto/tls library (TLS 1.2), I have noticed something that may cause interop problems
later.


The current draft says the following about Server Certificate Selection
(https://tools.ietf.org/html/draf= t-ietf-tls-tls13-21#section-4.4.2.2):

=C2=A0 =C2=A0-=C2=A0 The certificate MUST allow the key to be used for sign= ing (i.e.,
=C2=A0 =C2=A0 =C2=A0 the digitalSignature bit MUST be set if the Key Usage = extension is
=C2=A0 =C2=A0 =C2=A0 present) with a signature scheme indicated in the clie= nt's
=C2=A0 =C2=A0 =C2=A0 "signature_algorithms" extension.

In TLS 1.2, the cipher suite was responsible for selecting the hash
function and signature algorithm (e.g. for ServerKeyExchange) while
"signature_algorithms" directed what certificate signatures are accepted.=C2=A0 But in TLS 1.3, this also influences what algorithms can be=
used for signing handshake messages (CertificateVerify).

This results in possible interop problem: while implementations
advertise RSASSA-PSS support in "supported_algorithms" because th= ey can
indeed sign/verify handshake messages with said algorithm, they might
not be able to accept certificates with a RSASSA-PSS signature (because
the PKI library does not implement it for example). And because PSS
certificates are non-existent now, it will only be discovered later.

Some implementations I have checked wrt RSASSA-PSS support:
=C2=A0- Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet.
=C2=A0- tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates.
=C2=A0- BoringSSL - failed, "bssl server" rejects cert.
=C2=A0- OpenSSL - failed, s_server rejects cert. Related:
=C2=A0 =C2=A0https://github.com/openssl/openssl/issues= /2878
=C2=A0- NSS - not checked, but I think it has the same problem as tls-tris.=
=C2=A0 =C2=A0Related: https://bugzilla.mozilla.= org/show_bug.cgi?id=3D158750

These implementations will require fixing, but at the moment it is just
broken. Is this the expected behavior/intention?


While RSASSA-PSS is quite well understood for handshake messages, its
restrictions for certificates are not explicit. Currently the draft
limits the salt length for handshake messages, but what about certs?
What is needed for a TLS implementation to claim support for RSASSA-PSS?
In particular, for certificates:

=C2=A0- Limitations on salt length?
=C2=A0- What AlgorithmIdentifier OID to use?
=C2=A0- Whether to constrain other AlgorithmIdentifier Params? (MGF, hash =C2=A0 =C2=A0algorithm, trailerField)?
--
Kind regards,
Peter Wu
http= s://lekensteyn.nl

_______________________________________________
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
--94eb2c0d4b5ebc21220558f3452e-- From nobody Mon Sep 11 22:46:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC60132143 for ; Mon, 11 Sep 2017 22:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39QeRw5XqSBZ for ; Mon, 11 Sep 2017 22:46:12 -0700 (PDT) Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D7C1241FC for ; Mon, 11 Sep 2017 22:46:12 -0700 (PDT) Received: by mail-wr0-f178.google.com with SMTP id o42so18238385wrb.3 for ; Mon, 11 Sep 2017 22:46:12 -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:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=SH/VRQ9oWv0Xy2LUov+EgB99SilqzP5C8SCBhwW5sAw=; b=AVoP3zoi1kkyw7GYN5TalX8gT7FNlEEb+oC0z3XzAdFiIIAOOnO5zDG2RGGQ/wyzbV 5zU23wlcLTBcJZ91l9dmR2n9ljAVXluJMVw8G5eaqhMh4j3tnxDEvLbFgHFw6B1IXC/z ToT9YiUsA2BIHf7FkJEALP0+al25425LKZGE1e4krvNQ9zJ3Tqgx5aKjYczRJFI2cuLq 9BxcabwcDlIvnS5r8Lcqk+ZXPeQPkBkESZh8lKxUQz9tGokrVx6U1nnCtOS0P29uoZsP QihfwCPUHRnM6u8wG+RfgIcgIp3UDFkmIuYNFRz+V+Ae23FGBxhgsuyCvB1fr2uFiJDK gduw== X-Gm-Message-State: AHPjjUiXAIyhroK4xPtg/urtywqSABOGYlB00bHpQMXhZhOjo2wXZiqr fexTVW5hWyEIgCZytLiP/w== X-Google-Smtp-Source: ADKCNb4/yBNVQXNW336xgWKZR3/ZmbbAWjnm7Vhj0IM3YolJHBSTwH9GjFwpX6f3Le6KAEz97D8Crg== X-Received: by 10.223.156.199 with SMTP id h7mr7635892wre.170.1505195170479; Mon, 11 Sep 2017 22:46:10 -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 6sm7077543wrg.66.2017.09.11.22.46.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Sep 2017 22:46:09 -0700 (PDT) Message-ID: <1505195169.4161.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , Peter Wu Cc: "tls@ietf.org" Date: Tue, 12 Sep 2017 07:46:09 +0200 In-Reply-To: References: <20170908225948.GC31695@al> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 (3.24.5-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 05:46:14 -0000 On Mon, 2017-09-11 at 11:42 -0700, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed > to reflect both the capabilities of your TLS stack and the > capabilities of your PKI verifier [0]. So, yes, if you advertise this > it is supposed to work. So, ideally we would just say that it's as > Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both > places > 2. Invent a new extension whose semantics are "if present, this tells > you what the PKI validator accepts, otherwise look at signature > schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe > it's right anyway... > > -Ekr > > [0] I recognize that there are people who think that TLS shouldn't > say anything about the PKI verifier, > but I don't think that this is viable, for exactly the reason shown > here: it's possibly to have an algorithm which is widely supported in > TLS stacks but not in PKI verifiers. In practice, I find it perfectly reasonable for stacks which do not support that algorithm in both PKI and TLS not to advertise it. The option (1) brings simplicity to a rather complex protocol, while (2) bloats the protocol for the benefit of helping not up-to-date stacks claim TLS 1.3 compliance. In theory, the only reason for having RSA-PSS is its security proof. Mixing RSA (certificates) and RSA-PSS (handshake) in a protocol may hardly bring any benefit; it looks like it will make a convoluted protocol without particular goal or focus. regards, Nikos From nobody Tue Sep 12 00:49:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE7132E24 for ; Tue, 12 Sep 2017 00:49:28 -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 gZjkSWnQv4lQ for ; Tue, 12 Sep 2017 00:49:26 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA92124B18 for ; Tue, 12 Sep 2017 00:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 88BA5B5261; Tue, 12 Sep 2017 10:49:22 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id MXL2oRI3iGz1; Tue, 12 Sep 2017 10:49:22 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8F12F289; Tue, 12 Sep 2017 10:49:17 +0300 (EEST) Date: Tue, 12 Sep 2017 10:49:17 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Cc: Eric Rescorla , Peter Wu , "tls@ietf.org" Message-ID: <20170912074917.n4gjvz3zrz7s4rnf@LK-Perkele-VII> References: <20170908225948.GC31695@al> <1505195169.4161.4.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1505195169.4161.4.camel@redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 07:49:28 -0000 On Tue, Sep 12, 2017 at 07:46:09AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-09-11 at 11:42 -0700, Eric Rescorla wrote: > > Ugh. > > > > Generally, the idea with signature schemes is that they are supposed > > to reflect both the capabilities of your TLS stack and the > > capabilities of your PKI verifier [0]. So, yes, if you advertise this > > it is supposed to work. So, ideally we would just say that it's as > > Ilari says in his followup. > > > > It seems like there are really two choices: > > > > 1. Only advertise algorithm X if you support algorithm X in both > > places > > 2. Invent a new extension whose semantics are "if present, this tells > > you what the PKI validator accepts, otherwise look at signature > > schemes" > > > > I hate to be suggesting #2 at this stage in the process, but maybe > > it's right anyway... > > > > -Ekr > > > > [0] I recognize that there are people who think that TLS shouldn't > > say anything about the PKI verifier, > > but I don't think that this is viable, for exactly the reason shown > > here: it's possibly to have an algorithm which is widely supported in > > TLS stacks but not in PKI verifiers. > > In practice, I find it perfectly reasonable for stacks which do not > support that algorithm in both PKI and TLS not to advertise it. The > option (1) brings simplicity to a rather complex protocol, while (2) > bloats the protocol for the benefit of helping not up-to-date stacks > claim TLS 1.3 compliance. Unfortunately, I have seen behavior like the following (this is modified client and one of the test servers (the mod_nss @draft-20 one) in the wiki): [State ClientHello] Sending client_hello: ┌─────┬──────────────┨ Payload ┠──────────────┬────────────────┐ │ 0│0303 CBD9 FD89 B99E 292A E0F4 791D 0C29│........)*..y..)│ │ 1│07F2 0C62 7D94 6ED6 7C93 59EA BD6F 72F6│...b}.n.|.Y..or.│ │ 2│0CF9 0000 12CC A9C0 2BC0 2CCC A8C0 2FC0│........+.,.../.│ │ 3│3013 0313 0113 0201 0000 9900 2B00 0D0C│0...........+...│ │ 4│7F15 7F14 7F13 7F12 7F11 0303 000A 000C│................│ │ 5│000A 001D 0017 001E 0018 0019 0028 0026│.............(.&│ │ 6│0024 001D 0020 C02A 8D3E 32F4 ED55 9F6B│.$... .*.>2..U.k│ │ 7│9ADF 772C 1F8C 39FE D6D3 D03A 179A 14A1│..w,..9....:....│ │ 8│8180 F41A 8C58 0000 0018 0016 0000 1366│.....X.........f│ │ 9│7261 6E7A 6973 6B75 736B 6965 6665 722E│ranziskuskiefer.│ │ A│6465 0005 0005 0100 0000 0000 1200 0000│de..............│ │ B│0D00 1200 1008 0708 0804 0305 0306 0306│................│ │ C│0105 0104 0100 1700 00FF 0100 0100 1053│...............S│ │ D│0002 4000 │..@. │ └─────┴─────────────┨ 212 bytes ┠─────────────┴────────────────┘ ... snip ... Chosen configuration: Version: TLS 1.3-draft20, Protection:Aes128Gcm, Hash: Sha256, Exchange group: X25519, Extended Master Secret: N/A [State Tls13CertificateVerify] Received (borrowed) certificate_verify: ┌─────┬──────────────┨ Payload ┠──────────────┬────────────────┐ │ 00│0401 0100 2716 5FF4 5A0B 9F05 5B42 8609│....'._.Z...[B..│ ...snip... │ 10│BACC 04E5 │.... │ └─────┴─────────────┨ 260 bytes ┠─────────────┴────────────────┘ do_local_abort: #42:CertificateVerify contains bad signature That is Client Hello that does not advertise RSA-PSS, but does advertise RSA-PKCS#1. The server responds with TLS 1.3 and signature scheme 0x0401, which is RSA-PKCS#1 with SHA-256. And then client aborts because it does not like that scheme. -Ilari From nobody Tue Sep 12 04:02:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E43133453 for ; Tue, 12 Sep 2017 04:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t5ktaqfGkBC for ; Tue, 12 Sep 2017 04:02:28 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D911333DB for ; Tue, 12 Sep 2017 04:02:22 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3xs21m21L6z25P4; Tue, 12 Sep 2017 13:02:20 +0200 (CEST) X-purgate-ID: 152705::1505214140-000040CA-ED7F9DB3/0/0 X-purgate-size: 3604 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3xs21l2zb6zGnwB; Tue, 12 Sep 2017 13:02:19 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 61B741A6F4; Tue, 12 Sep 2017 13:02:19 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Tue, 12 Sep 2017 13:02:19 +0200 (CEST) CC: Peter Wu , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170912110219.61B741A6F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 11:02:35 -0000 Eric Rescorla wrote: > > Generally, the idea with signature schemes is that they are supposed to > reflect both the capabilities of your TLS stack and the capabilities of > your PKI verifier [0]. So, yes, if you advertise this it is supposed to > work. So, ideally we would just say that it's as Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both places > 2. Invent a new extension whose semantics are "if present, this tells you > what the PKI validator accepts, otherwise look at signature schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe it's > right anyway... > > -Ekr > > [0] I recognize that there are people who think that TLS shouldn't say > anything about the PKI verifier, > but I don't think that this is viable, for exactly the reason shown here: > it's possibly to have an algorithm which is widely supported in TLS stacks > but not in PKI verifiers. I believe you got it backwards. A new TLS extension to convey acceptable signatures on certs would be needed, and for this, it would be preferable to pass along ASN.1 OIDs from AlgIds (not full AlgIds, this would be too messy with RSA-PSS). The text in rfc5246 which suggests that contents of the "signature_algorithm" extension should be applied to certificates is a defect of rfc5246, and only a small fraction of implementors seems to have gotten this wrong, and created implementations that erroneously abort by making flawed assumptions on what the peer might support (or not). The signature_algorithms extensions must only be applied to transforms used within the TLS protocol itself (digitally_signed), because only this transform can be negotiated and produced at will by communication peers. Certificates will, in most real-world usage cases, be created out-of-band by third party entities (CAs), and can typically not be created by the TLS communication endpoints. It is OK to use "signature_algorithms" as a selection hint. It is a dumb idea for a TLS communication peer to abort a TLS handshake by making flawed assumptions about whether a communication peer does or does not support a particular signature scheme on certificates. TLS handshake failures based on flawed assumptions are unconditionally BAD. If the peer has a certain policy, it is up to that peer to apply this policy during _verification_. TLS handshake failures are unprotected, they can not be recovered from at the TLS level (transparently), but require app-level acrobatics, and may require repeated proxy traversals. And they create downgrade vulnerabilities, such as the silly "downgrade dance" implemented by a number of browsers, which creates the POODLE vulnerability. btw. some PKIs are currently switching to using RSA-PSS signatures on certificate chains. But they do use rsaEncryption for the key in the endEntity certificate. Because they want to use end-entity certs for both, PKCS#7/CMS (and maybe SOAP) signatures as well as SSL/TLS client certificates. For use with TLSv1.2 as client certs, they're hardwired to RSA PKCS#1 v1.5 signatures, which precludes tagging the keys in client end-entity certs as RSA-PSS. TLSv1.3 needs to avoid more "MUST" mistakes around algorithms that work just fine with earlier version of TLS. It is perfectly OK to created RSA-PSS signatures with keys that are tagged as rsaEncryption, and adding words or semantics to TLSv1.3 that suggests this is not OK, would be terribly bad. -Martin From nobody Tue Sep 12 05:25:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA321133431 for ; Tue, 12 Sep 2017 05:25:16 -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 Fl2lxI11a1LK for ; Tue, 12 Sep 2017 05:25:14 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E356E13304A for ; Tue, 12 Sep 2017 05:25:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EF1B29FB30; Tue, 12 Sep 2017 15:25:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id tMbvztlWkYCx; Tue, 12 Sep 2017 15:25:10 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1F94827F; Tue, 12 Sep 2017 15:25:06 +0300 (EEST) Date: Tue, 12 Sep 2017 15:25:06 +0300 From: Ilari Liusvaara To: Martin Rex Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170912122506.qa56yifturgbxadw@LK-Perkele-VII> References: <20170912110219.61B741A6F4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170912110219.61B741A6F4@ld9781.wdf.sap.corp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 12:25:17 -0000 On Tue, Sep 12, 2017 at 01:02:19PM +0200, Martin Rex wrote: > Eric Rescorla wrote: > > > > Generally, the idea with signature schemes is that they are supposed to > > reflect both the capabilities of your TLS stack and the capabilities of > > your PKI verifier [0]. So, yes, if you advertise this it is supposed to > > work. So, ideally we would just say that it's as Ilari says in his followup. > > > > It seems like there are really two choices: > > > > 1. Only advertise algorithm X if you support algorithm X in both places > > 2. Invent a new extension whose semantics are "if present, this tells you > > what the PKI validator accepts, otherwise look at signature schemes" > > > > I hate to be suggesting #2 at this stage in the process, but maybe it's > > right anyway... > > > > -Ekr > > > > [0] I recognize that there are people who think that TLS shouldn't say > > anything about the PKI verifier, > > but I don't think that this is viable, for exactly the reason shown here: > > it's possibly to have an algorithm which is widely supported in TLS stacks > > but not in PKI verifiers. > > I believe you got it backwards. > > A new TLS extension to convey acceptable signatures on certs would be > needed, and for this, it would be preferable to pass along ASN.1 > OIDs from AlgIds (not full AlgIds, this would be too messy with RSA-PSS). With RSA-PSS, there is also the parametrization signature by hashes. The implementation I have supports the following six sets of parameters for RSA-PSS: - hash=SHA-256, mgf=MGF1[SHA-256], salt=256, trailer=1 - hash=SHA-384, mgf=MGF1[SHA-384], salt=384, trailer=1 - hash=SHA-512, mgf=MGF1[SHA-512], salt=512, trailer=1 - hash=SHA3-256, mgf=MGF1[SHA3-256], salt=256, trailer=1 - hash=SHA3-384, mgf=MGF1[SHA3-384], salt=384, trailer=1 - hash=SHA3-512, mgf=MGF1[SHA3-512], salt=512, trailer=1 The first three are the TLS 1.3 RSA-PSS schemes. The last three are the same, except with SHA-2 hash replaced by correspoding SHA-3 hash. (I mostly implemented those SHA-3 algorithms as to test of the architecture.) > The text in rfc5246 which suggests that contents of the "signature_algorithm" > extension should be applied to certificates is a defect of rfc5246, and > only a small fraction of implementors seems to have gotten this wrong, > and created implementations that erroneously abort by making flawed > assumptions on what the peer might support (or not). This is mostly not about peers aborting on bad assumptions. It is peers making bad assumptions and then sending something that the peer does not support. The TLS server I wrote does abort on some certificates (e.g., all signature algorithms must be recognized). However, all checks except ones on exchange signatures are independent of the capabilities advertised by peer. The TLS 1.3 has SHOULD on that signature algorithm selection. I wrote my implementation to outright immediately abort, since I do not see that there is any way things can work if that SHOULD is broken. The default (can be overridden) certificate selection code prefers certificates signed by algorithms appearing in signature_algorithms, but if no suitable certificate is found, expands the search to all algorithms. Unlike in previous point, there is a chance things will work even if unadvertised algorithm is chosen (e.g., ECDSA-P256-SHA3-256 certificate being sent to the corresponding client implementation... Those are in fact supported). > The signature_algorithms extensions must only be applied to transforms > used within the TLS protocol itself (digitally_signed), because only this > transform can be negotiated and produced at will by communication peers. There are restrictions from end-entity certificates the server has. E.g. 0x804 and 0x403 require different end-entity certificates. > Certificates will, in most real-world usage cases, be created out-of-band > by third party entities (CAs), and can typically not be created by the > TLS communication endpoints. It is OK to use "signature_algorithms" > as a selection hint. It is a dumb idea for a TLS communication peer > to abort a TLS handshake by making flawed assumptions about whether > a communication peer does or does not support a particular signature > scheme on certificates. Yes, most of the time, the server only has one or two certificate chains available. > TLS handshake failures based on flawed assumptions are unconditionally BAD. > If the peer has a certain policy, it is up to that peer to apply this > policy during _verification_. TLS handshake failures are unprotected, > they can not be recovered from at the TLS level (transparently), but require > app-level acrobatics, and may require repeated proxy traversals. And > they create downgrade vulnerabilities, such as the silly "downgrade dance" > implemented by a number of browsers, which creates the POODLE vulnerability. As far as I understand this issue, this is not _server_ aborting because it can't select a chain, it is _client_ aborting because it can not deal with what the server sent (because the server had no idea that the client could not deal with what it sent). -Ilari From nobody Tue Sep 12 05:30:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0508313304A for ; Tue, 12 Sep 2017 05:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu7GV5zZFgNw for ; Tue, 12 Sep 2017 05:30:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6F513208E for ; Tue, 12 Sep 2017 05:30:50 -0700 (PDT) Received: from [192.168.91.203] ([131.111.5.141]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6RiN-1dWuA73p4l-00yNIZ for ; Tue, 12 Sep 2017 14:30:49 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 12 Sep 2017 14:30:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cXjqwy2jnvRstAQt/56+Mqxz8QMq1sbGVn81JXZg8L2qfYf2IFm NaS1EwLX5cp5um3p/PLaR02k7kFYVQfdkYzvyAptBntELTjhJUuMPz8qCFsb3Uv2QFKv9s1 Zxxa8Pb40NAUndktcBKcyHvaql9/VI2Acav8P8ccyZscmTZkPPA0d/I5eb2myxhBABy0NuI voASOyfZmcCuOlYQYa3mA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zbpyfzT1338=:Mu/KdAshu2A1Agsv6ezpR2 aXDF/gkuMBo3fDYM4U8PexcrBAueGAhQeiuHTTf6OoVq1MymTVMUnX9q/nlPeIpTNqSZHH/IU 8pdhe34eVwyLVhYp+Eu65aRaGYnE2AK6CMspP4+ymFzzzUkPue+JCg3xNlhXQd50+haZPL4FJ +N4pnxiZEQ/vA5x+RQ/j/NcuEKmW+vu8QCrK2mTuzB2dZysLQN/ECxXI9gp4DC59iTcWODYWm XqScF0xlQWyw8e9BetqxFmdXxM3szeEZwggSZe+ivgg9MHGJ2nuo2HcNi7V/F/drbmU62R8WE JHZm4k8zGzXLXSgLXjL6ZPGOTUWwVCWlZIvsjMJNyMPkrl+GN+pFnse98CE3CAlNSy9+yHr4C Ct4kknEeHBrPUp7Jy5zBJPhDHaGn49Z++gSVY1lLVY92k5IIgtlIonvUXxI02DcnTSH0EdF+3 SVx5UfIUPJeYG5a/EdagIM4b0nqhaE71jMs4NMFK1FFtDJNsN0tt1F5znu9vlaQNC2hAReesS NpnfL+8ch8g/iiD55qfGKCX4cH5iGZ7tol+7qqu/6mfkk8sPfgOalZgTUEtk1DOxQLSPhGkme x8fBR11ct8r+GBNvSxZm6ESmaydUibjG2gj7RKsTqNB28wFsZqBdKohnTry3G2YkDVU9yIvWA S8vwBku/griGWN4GX8S4KeffgrM9DDZDoVxsdGrdmEyf4XgiogMm4LKv032yo0WydK7NoeXSn dQwhbU2UKUXjbgXBTOiIRbR0g4bAkuPYPV2rLgZJ6zYeLWZvm/V+t77QAoYtkyRcOYl4RT3L3 tdzD33P1Qe/uofAvr2AOkgpHR7FhVb0HWmbZGWxz05snmxFRz8= Archived-At: Subject: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 12:30:53 -0000 Hi Martin, I have implemented the record size extension into mbed TLS. It can be found at https://github.com/ARMmbed/mbedtls/pull/1088 There is only one problem that remains to be addressed IMHO. This extension was developed to address the problem of devices with small RAM. Application developers have to configure their embedded TLS stack in such a way that the parameters configured with this TLS extensions match the available hardware. The record_size_limit helps a lot already but does not quite to the final goal since it uses an artificial metric for deciding when to fragment records. Currently, a developer has to understand various security concepts to get this right, namely * Ciphersuite negotiated (and the overhead associated with it, such as tag length), * DTLS vs. TLS record layer header differences, * potential compression being applied. Additionally, there is, of course, other header information that needs to be considered in the overall buffer size calculation, such as TCP or UDP, IP and potentially any lower layer headers. I just think that this is too much to ask for from an ordinary developer. Hence, I would suggest to use a different metric so that the developer can be certain that at least from a DTLS/TLS layer there are not records being sent that exceed the indicated threshold. If you think that this idea is worthwhile to entertain then I will make a proposal. Ciao Hannes From nobody Tue Sep 12 06:16:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0A133049 for ; Tue, 12 Sep 2017 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It_cymnI439b for ; Tue, 12 Sep 2017 06:16:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924C81321C7 for ; Tue, 12 Sep 2017 06:16:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A45A5F7AC; Tue, 12 Sep 2017 13:16:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2A45A5F7AC Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AEC9C77DCA; Tue, 12 Sep 2017 13:16:51 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 12 Sep 2017 15:16:45 +0200 Message-ID: <3748802.M0zyvroJV0@pintsize.usersys.redhat.com> In-Reply-To: References: <20170908225948.GC31695@al> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2668579.n5XmM3cZX8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 12 Sep 2017 13:16:52 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:16:55 -0000 --nextPart2668579.n5XmM3cZX8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 12 September 2017 02:39:02 CEST Nick Sullivan wrote: > This situation is likely to arise every time a new signature algorithm is > introduced. Suppose a TLS client library is updated to support Ed25519 > certificates, but that the PKIX library only supports validating Ed25519 > certificates signed by RSA or ECDSA, which signature schemes should the > client present? This is similar to the 2014 issue with ECDSA and Chrome on > XP (https://bugs.chromium.org/p/chromium/issues/detail?id=3D409901), in w= hich > the PKIX library didn't support ECDSA, but the TLS stack did. As long as > TLS and PKIX libraries are decoupled, the dual meaning of the signature > scheme makes the addition of a new algorithm to one or the other a bit > messy. >=20 > For example: In the current situation, it is mandatory to support > rsa_pss_sha256, but how many of these clients support certificates signed > with PSS? Not many -- including OpenSSL ( > https://github.com/openssl/openssl/issues/2878#issuecomment-328576616). Actually OpenSSL does support certificates signed with RSA-PSS, it doesn't= =20 support RSA-PSS keys in certificates. > Without PSS certificate support, if we chose EKR's option 1, these clients > would not be able to support TLS 1.3 according to the spec. This seems li= ke > an unnecessary dependency. With RSA-PSS the situation is even more complex, as you have it in two plac= es,=20 in the signature and in the public key id. So the possibilities are as follows: - CA key: rsa; EE signature: rsa; EE key: rsa - that certificate can be used with any version of TLS and can make both= =20 rsa-pss and rsa signatures - CA key: rsa; EE signature: rsa; EE key: rsa-pss - that certificate can be used only with TLS 1.3 or TLS 1.2 that was=20 updated to support TLS 1.3 signatures, does not require support for RSA-PSS in PKIX (with the assumption that the library allows the TLS library to extract the RSA-PSS parameters from the certificate) - CA key: rsa; EE signature: rsa-pss; EE key: rsa - that certificate can be used again only with TLS 1.3 or TLS 1.2 but that's because RFC compliant peer can send only certificates that have signatures listed in SignatureAlgorithms. Can sign using both rsa and rsa-pss but it DOES require RSA-PSS support in PKIX - CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss - similarly to the above, but does limit the usage of certificate to=20 TLS 1.2 with rsa-pss or TLS 1.3, cannot be used to make RSA-PKCS#1 v1.= 5=20 signatures in TLS 1.2 - CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa - exactly as with CA key: rsa; EE signature: rsa-pss; EE key: rsa - CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss - similarly to the above, but cannot be used to make RSA-PKCS#1 v1.5=20 signatures in TLS 1.2, thus requires RSA-PSS support in TLS 1.2 from the TLS part of the library Now, if a client sends only rsa_pss_sha256, I'd say, that all of the follow= ing=20 need to work: - CA key: rsa; EE signature: rsa-pss; EE key: rsa - CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss - CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa - CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss If both rsa_pss_sha256 and rsa_pkcs1_sha256 are sent, then all 6 combinatio= ns=20 should be supported by client. =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 --nextPart2668579.n5XmM3cZX8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZt949AAoJEJKo0bgB0vX1I4QP/2jLzaNxcLWWT8JYgerStgz6 H48xXQbqjI77so75KUlK3BoTVhQMxe8uGdF2NrcoFrtNy6DTMV6qjv8VpSlspcrX 42YeMGGETKVAtJROnd4NjTzA8z6VQWYXflgs7pVfH4OI9d8I4/EIyIvGTz7e06U+ 0oox4WINN6HVYo/aE7nhF6sLA6xFCHILbuP/2WmQ9y3k74LF2lJaX1ieTpyZd9w0 5i0RNkX5kLLX3V4FB7i6lbZno1ATYJx7SwiVirYQDHuwJxmTDdB8YCTpwNqQf0qp Ro09YXXXkKGTUdem0gRqU3cpe1wdsNfHQbbgrxmpPsrNlC+HmEQsZcyWe3Xggxoq xHObabgI6f43x7SdzRh6Li2dA8HIWt2JuGgG6YSqXSWkR49dnjwi4Zc7BTntjeC6 fzG8rh3zxPZTTbIORJNbK/Fpekf5/s8S7FTBmsDcd4E+g8INbiRwzFOEuQzUNDEL C9XkK7UIJqMZ+nU9QeoCsUcTOIXGK6jser/tkmODnv1DMSOtEE4Nkyv+qtSkUka8 Xs7P6tMNZN5yg6rcgI5BZGVSrYnWjqInqLSE8k7g6QbsoDE0zVuWlIxla9YhmFh7 Nhufl4mUmu5iKrmtCx1sIGY9Jata7gMvTusBhZZjGTrDNFz9ID45FA0R4fuj0o+J cS1oS0Eq91IAi1vPbYVc =shDx -----END PGP SIGNATURE----- --nextPart2668579.n5XmM3cZX8-- From nobody Tue Sep 12 06:21:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048CC133049 for ; Tue, 12 Sep 2017 06:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHxj9ye91pPG for ; Tue, 12 Sep 2017 06:21:32 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1217513304C for ; Tue, 12 Sep 2017 06:21:32 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3xs56K6p7nz1HW3; Tue, 12 Sep 2017 15:21:29 +0200 (CEST) X-purgate-ID: 152705::1505222489-000014F4-D0725BDC/0/0 X-purgate-size: 1185 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3xs56K5LhpzGpR2; Tue, 12 Sep 2017 15:21:29 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AB29E1A6F4; Tue, 12 Sep 2017 15:21:29 +0200 (CEST) In-Reply-To: <20170912122506.qa56yifturgbxadw@LK-Perkele-VII> To: Ilari Liusvaara Date: Tue, 12 Sep 2017 15:21:29 +0200 (CEST) CC: Martin Rex , Eric Rescorla , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170912132129.AB29E1A6F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:21:36 -0000 Ilari Liusvaara wrote: > On Tue, Sep 12, 2017 at 01:02:19PM +0200, Martin Rex wrote: >> >> A new TLS extension to convey acceptable signatures on certs would be >> needed, and for this, it would be preferable to pass along ASN.1 >> OIDs from AlgIds (not full AlgIds, this would be too messy with RSA-PSS). > > With RSA-PSS, there is also the parametrization signature by hashes. > > The implementation I have supports the following six sets of parameters > for RSA-PSS: > > - hash=SHA-256, mgf=MGF1[SHA-256], salt=256, trailer=1 > - hash=SHA-384, mgf=MGF1[SHA-384], salt=384, trailer=1 > - hash=SHA-512, mgf=MGF1[SHA-512], salt=512, trailer=1 > - hash=SHA3-256, mgf=MGF1[SHA3-256], salt=256, trailer=1 > - hash=SHA3-384, mgf=MGF1[SHA3-384], salt=384, trailer=1 > - hash=SHA3-512, mgf=MGF1[SHA3-512], salt=512, trailer=1 The salt length is supposed to be in bytes, not bits, and for SHA-1 defaults to 20. The salt length suggested in the standard is the output size of the underlying hash length in bytes. But it seems that some existing implementations use weird/unusual salt values for RSA-PSS signature with hash algs other than SHA-1. -Martin From nobody Tue Sep 12 06:41:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A34132D22 for ; Tue, 12 Sep 2017 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myc2_vOlmLzj for ; Tue, 12 Sep 2017 06:41:20 -0700 (PDT) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by ietfa.amsl.com (Postfix) with ESMTP id 277C91321C7 for ; Tue, 12 Sep 2017 06:41:19 -0700 (PDT) Received: from host86-132-183-251.range86-132.btcentralplus.com ([86.132.183.251]:14786 helo=[192.168.1.78]) by relay04.mail.eu.clara.net (relay.clara.net [81.171.239.34]:10465) with esmtpa (authdaemon_plain:drh) id 1drlRF-0000mP-Dh for tls@ietf.org (return-path ); Tue, 12 Sep 2017 13:41:18 +0000 To: tls@ietf.org References: <20170908225948.GC31695@al> From: Dr Stephen Henson Message-ID: Date: Tue, 12 Sep 2017 14:41:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:41:22 -0000 On 11/09/2017 19:42, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed to reflect > both the capabilities of your TLS stack and the capabilities of your PKI > verifier [0]. So, yes, if you advertise this it is supposed to work. So, ideally > we would just say that it's as Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both places > 2. Invent a new extension whose semantics are "if present, this tells you what > the PKI validator accepts, otherwise look at signature schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe it's right > anyway... > It's rather more than just certificate signatures. The problem here is that there is no way to indicate an implementation supports rsaEncryption keys but not RSASSA-PSS keys and the current draft requires that implementations support both AFAICS. RSASSA-PSS keys are pretty rare at the moment. There are some complications involved with supporting them not present with other key types: more complex parameter sets and key restrictions for example. Implementors might feel (despite what the draft says) that the added complexity is not justified because no one will ever want to use RSASSA-PSS keys. At the same time if important implementations abort the handshake when they see an RSASSA-PSS key then this is a strong reason for a server to not deploy RSASSA-PSS keys: it will cause interoperability issues. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ From nobody Tue Sep 12 07:10:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF00132716 for ; Tue, 12 Sep 2017 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM1OAwjf2JFU for ; Tue, 12 Sep 2017 07:10:48 -0700 (PDT) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF22F1326DF for ; Tue, 12 Sep 2017 07:10:47 -0700 (PDT) Received: by mail-wr0-f169.google.com with SMTP id k20so22932214wre.4 for ; Tue, 12 Sep 2017 07:10:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=rNWzF2hpMG7uQYcz469wR7YhhlxWfp53YQ1tp0Hsoas=; b=sMpSwDatwP7yGAbM7hfL5XrRdq11Zy8FuUm6C13b+u48LFVxA9p8Abk48BIu0zzWVC f6oSGn9Fh2RbgueR/Dlnns8tV5nR7Lfqmg5rrc+4EuhVCYBP4c3EUzaaV8doJiBBFnEc fKKVOYyEMqNIH1xdOZ2HpSCqO/uFDsPvwZd40LZc/448TnrLnuKLH3bUbyEnAipkTLH6 2MIod56ruCxHt0Rx3Z3QcS7mxss88G7lXYUsvYwuIZUdSQmwIIxS25UucxcaKp0rIdIF yzlI1rTKdm8B6yBT6QPO+zcI2JMSwXr7Tw+m23wZtSkYTP9aDxVMb8a7HDTTi/LGvf7U wiCA== X-Gm-Message-State: AHPjjUjkx83NTH9TR2QlnVT0jrL/1nawrhPG5VNQsvvXssmIWxsZTJnp xT18Gt+S5cijBTbRglz6qQ== X-Google-Smtp-Source: ADKCNb5EqDQVvD4zsC6gYgdKpkS8pSvT2E1lhq10VnWu8pkoN9pvDmAkW9QY6jlYWdC6dCTknNkp1w== X-Received: by 10.223.166.138 with SMTP id t10mr13772602wrc.64.1505225446142; Tue, 12 Sep 2017 07:10:46 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id v78sm7773146wmv.48.2017.09.12.07.10.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Sep 2017 07:10:45 -0700 (PDT) Message-ID: <1505225444.4161.35.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Dr Stephen Henson , tls@ietf.org Date: Tue, 12 Sep 2017 16:10:44 +0200 In-Reply-To: References: <20170908225948.GC31695@al> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 (3.24.5-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:10:55 -0000 On Tue, 2017-09-12 at 14:41 +0100, Dr Stephen Henson wrote: > On 11/09/2017 19:42, Eric Rescorla wrote: > > Ugh. > > > > Generally, the idea with signature schemes is that they are > > supposed to reflect > > both the capabilities of your TLS stack and the capabilities of > > your PKI > > verifier [0]. So, yes, if you advertise this it is supposed to > > work. So, ideally > > we would just say that it's as Ilari says in his followup. > > > > It seems like there are really two choices: > > > > 1. Only advertise algorithm X if you support algorithm X in both > > places > > 2. Invent a new extension whose semantics are "if present, this > > tells you what > > the PKI validator accepts, otherwise look at signature schemes" > > > > I hate to be suggesting #2 at this stage in the process, but maybe > > it's right > > anyway... > > > > It's rather more than just certificate signatures. > > The problem here is that there is no way to indicate an > implementation supports > rsaEncryption keys but not RSASSA-PSS keys and the current draft > requires that > implementations support both AFAICS. > > RSASSA-PSS keys are pretty rare at the moment. There are some > complications > involved with supporting them not present with other key types: more > complex parameter sets and key restrictions for example. Right, that is indeed a significant complexity, and unfortunately the RSASSA-PSS parameters in certificates/keys are quite uniquely in PKIX. However, these are optional parameters, and one could support RSA-PSS keys without such parameters/restrictions relatively easily. Moreover, keys without paramters, are the keys which are typically expected to be used by TLS. That is, because a TLS server would typically sign with whatever algorithm the client supports and would very rarely be interested to utilize the security advantages of including the parameters (which, advantages, are quite unclear even to a crypto expert). Otherwise, a certificate restricted to SHA-384 and 48-bytes of salt, will not be able to serve a client which only supports RSASSA-PSS with SHA-256. As such, it would make sense for TLS 1.3 to recommend no parameters for such RSASSA-PSS certificates, to ease their deployment. > Implementors might feel > (despite what the draft says) that the added complexity is not > justified because no one will ever want to use RSASSA-PSS keys. If an implementation does not support RSASSA-PSS-only keys, it means it will (as a server) not be able to use separate keys for RSASSA-PSS and RSA PKCS#1 v1.5 operations, right? That's quite a fundamental limitation and if it exists in popular implementations it makes the TLS 1.3 move to RSASSA-PSS quite questionable. It may be better to support RSA PKCS#1 v1.5 in TLS1.3 alongside RSASSA-PSS (for the implementations that chose to opt-in), rather than forcing a move to RSASSA-PSS without providing any of the benefits of using it. regards, Nikos From nobody Tue Sep 12 08:42:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E085132D7B for ; Tue, 12 Sep 2017 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG0LiPH3g2b3 for ; Tue, 12 Sep 2017 08:42:39 -0700 (PDT) Received: from claranet-outbound-smtp07.uk.clara.net (claranet-outbound-smtp07.uk.clara.net [195.8.89.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8371320D9 for ; Tue, 12 Sep 2017 08:42:39 -0700 (PDT) Received: from host86-132-183-251.range86-132.btcentralplus.com ([86.132.183.251]:6737 helo=[192.168.1.78]) by relay07.mail.eu.clara.net (relay.clara.net [81.171.239.37]:10465) with esmtpa (authdaemon_plain:drh) id 1drnKa-00023d-Pi (return-path ); Tue, 12 Sep 2017 15:42:33 +0000 To: Nikos Mavrogiannopoulos , tls@ietf.org References: <20170908225948.GC31695@al> <1505225444.4161.35.camel@redhat.com> From: Dr Stephen Henson Message-ID: <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> Date: Tue, 12 Sep 2017 16:42:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505225444.4161.35.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 15:42:42 -0000 On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote: > > That is, because a TLS server would typically sign with whatever > algorithm the client supports and would very rarely be interested to > utilize the security advantages of including the parameters (which, > advantages, are quite unclear even to a crypto expert). Otherwise, a > certificate restricted to SHA-384 and 48-bytes of salt, will not be > able to serve a client which only supports RSASSA-PSS with SHA-256. > > As such, it would make sense for TLS 1.3 to recommend no parameters for > such RSASSA-PSS certificates, to ease their deployment. > Well restrictions in CA keys would be handled by the PKI verifier: if there is a violation the chain should be rejected and it's a problem with the chain itself and an error by the CA that issued it. A different case is where the restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, though again it's a CA error issuing such a chain for TLS 1.3 use. A restriction on the EE key isn't quite the same. There are two cases. One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 digest doesn't match signing digest or minimum salt length exceeds digest length). In this case a server should never present the chain or if it does a client would justifiably reject it and abort the handshake. Again this is an error by the issuing authority which should be corrected. The second case is that the parameter restriction is permitted by TLS 1.3 and this limits the digest which the key can sign with. Say the restriction is SHA384 and the client only supports rsa_pss_sha256. The server might then use to a different PSS key (and certificate chain) that supports rsa_pss_sha256 or fall back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS message signed with parameters that violate the restrictions it could (with some justification) abort the handshake. This could get pretty messy: it requires a logic not used in any other algorithm. I'd be more than happy to have an outright prohibition on EE PSS key parameter restrictions in TLS 1.3 so implementers don't have to bother with this. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ From nobody Tue Sep 12 09:03:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F386A133075 for ; Tue, 12 Sep 2017 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0eKocjIIesM for ; Tue, 12 Sep 2017 09:03:09 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0BA133076 for ; Tue, 12 Sep 2017 09:03:08 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id j141so50003545ioj.4 for ; Tue, 12 Sep 2017 09:03: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=Ozm1MGam5aglHcUOcYD7NfL9blcJX+FYkT4Dna3xUmQ=; b=he3Wx1WajCXMaYR1ctgUJcz4ddnK8Td3q3TmtZJel/+dVunrT/6YAqS91qrtTDq7xB d9ODbWNRww42tJgunPG7BVlrQWlpbykg0FaKoQHTVaXIvKiH8A4t97hioTORr/uZWfBb NxDkK9AQHy0kn+XUBJDgoCG2lqWQJcp0ZTtoeDrCjvAHaG6nZu/lUMyRmmG+vYDl6Fg8 estPZm3Mk5GohE0EFzSB9eGbFKObCYjlzWJZySnKoAF72zvMXpgKWkloxU+Kk8sCU9iy S/8HTSBd3mmJZfkpJSV0415mex2nrIMmp22kFOWnkZz/zdAkKkWV6diTXgB7wP2PhT4j qMCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=Ozm1MGam5aglHcUOcYD7NfL9blcJX+FYkT4Dna3xUmQ=; b=MpSqK7Z6cI6gXtsNT6t24dx1oXAzbyaGYW9hUrS8xVZAj8XrLZDk31c7/icn6kxH+P wq+naeEE1nbWoEm11JcO64SdVbbuSZGo3oRh8JlUasHZbIMXGjmIPys0mwRm2e0IC/0Y N8+2+CA7DmsmHFCRM7kZfyetjPlVOBg0NtFSvoLzBm/8G41ZKm0XYncGPtNwbV74qSwD ZQrnfNbnTWR4JIbhsvoTwBXwU4yNef9TB5jKtPtGG2fpCr79j8g37hQ6L9mQEECw/1NA EOj4Q/UTbL43z0yOXdUgSBk0tcYwc8vLTBu5xB1KGUSt0NfFcxfQ5zoJZagqkxIqTLsJ +fwA== X-Gm-Message-State: AHPjjUhtFO9UUvaxstTTsPkckHkxBAZqeFRySiJLSwd8JE9EK9r14tsZ n6jnSh4ligyi/8emd0t8GCMsoZDfGLC7 X-Google-Smtp-Source: AOwi7QBRb6B2Oe0abIIsAZ3du4E06/m2bb7VwD6A3YwJiruIBL6CUl4kXAvNp64kYXuUtCLWX7yO+KrMrRD59p442DY= X-Received: by 10.202.224.130 with SMTP id x124mr14089428oig.100.1505232188069; Tue, 12 Sep 2017 09:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.10.71 with HTTP; Tue, 12 Sep 2017 09:02:27 -0700 (PDT) In-Reply-To: <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> References: <20170908225948.GC31695@al> <1505225444.4161.35.camel@redhat.com> <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> From: Eric Rescorla Date: Tue, 12 Sep 2017 09:02:27 -0700 Message-ID: To: Dr Stephen Henson Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113d376adfeedf0559002dd9" Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 16:03:11 -0000 --001a113d376adfeedf0559002dd9 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 8:42 AM, Dr Stephen Henson < lists@drh-consultancy.co.uk> wrote: > On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote: > > > > That is, because a TLS server would typically sign with whatever > > algorithm the client supports and would very rarely be interested to > > utilize the security advantages of including the parameters (which, > > advantages, are quite unclear even to a crypto expert). Otherwise, a > > certificate restricted to SHA-384 and 48-bytes of salt, will not be > > able to serve a client which only supports RSASSA-PSS with SHA-256. > > > > As such, it would make sense for TLS 1.3 to recommend no parameters for > > such RSASSA-PSS certificates, to ease their deployment. > > > > Well restrictions in CA keys would be handled by the PKI verifier: if > there is a > violation the chain should be rejected and it's a problem with the chain > itself > and an error by the CA that issued it. A different case is where the > restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, > though > again it's a CA error issuing such a chain for TLS 1.3 use. > > A restriction on the EE key isn't quite the same. There are two cases. > > One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 > digest > doesn't match signing digest or minimum salt length exceeds digest > length). In > this case a server should never present the chain or if it does a client > would > justifiably reject it and abort the handshake. Again this is an error by > the > issuing authority which should be corrected. > > The second case is that the parameter restriction is permitted by TLS 1.3 > and > this limits the digest which the key can sign with. Say the restriction is > SHA384 and the client only supports rsa_pss_sha256. The server might then > use to > a different PSS key (and certificate chain) that supports rsa_pss_sha256 > or fall > back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS > message > signed with parameters that violate the restrictions it could (with some > justification) abort the handshake. > > This could get pretty messy: it requires a logic not used in any other > algorithm. I'd be more than happy to have an outright prohibition on EE > PSS key > parameter restrictions in TLS 1.3 so implementers don't have to bother > with this. This sounds plausible to me. Would you be willing to send a PR? -Ekr > > Steve. > -- > Dr Stephen N. Henson. > Founder member of the OpenSSL project: http://www.openssl.org/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d376adfeedf0559002dd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 12, 2017 at 8:42 AM, Dr Stephen Henson <lists@drh-co= nsultancy.co.uk> wrote:
On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote:
>
> That is, because a TLS server would typically sign with whatever
> algorithm the client supports and would very rarely be interested to > utilize the security advantages of including the parameters (which, > advantages, are quite unclear even to a crypto expert). Otherwise, a > certificate restricted to SHA-384 and 48-bytes of salt, will not be > able to serve a client which only supports RSASSA-PSS with SHA-256. >
> As such, it would make sense for TLS 1.3 to recommend no parameters fo= r
> such RSASSA-PSS certificates, to ease their deployment.
>

Well restrictions in CA keys would be handled by the PKI verifier: i= f there is a
violation the chain should be rejected and it's a problem with the chai= n itself
and an error by the CA that issued it. A different case is where the
restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, t= hough
again it's a CA error issuing such a chain for TLS 1.3 use.

A restriction on the EE key isn't quite the same. There are two cases.<= br>
One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 d= igest
doesn't match signing digest or minimum salt length exceeds digest leng= th). In
this case a server should never present the chain or if it does a client wo= uld
justifiably reject it and abort the handshake. Again this is an error by th= e
issuing authority which should be corrected.

The second case is that the parameter restriction is permitted by TLS 1.3 a= nd
this limits the digest which the key can sign with. Say the restriction is<= br> SHA384 and the client only supports rsa_pss_sha256. The server might then u= se to
a different PSS key (and certificate chain) that supports rsa_pss_sha256 or= fall
back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS mess= age
signed with parameters that violate the restrictions it could (with some justification) abort the handshake.

This could get pretty messy: it requires a logic not used in any other
algorithm. I'd be more than happy to have an outright prohibition on EE= PSS key
parameter restrictions in TLS 1.3 so implementers don't have to bother = with this.

This sounds plausible to me. Wou= ld you be willing to send a PR?

-Ekr
=C2= =A0
=C2=A0

Steve.
--
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

--001a113d376adfeedf0559002dd9-- From nobody Tue Sep 12 10:30:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B791132EC4 for ; Tue, 12 Sep 2017 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPOSPDF26Yd4 for ; Tue, 12 Sep 2017 10:30:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9341E1200F3 for ; Tue, 12 Sep 2017 10:30:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B0F3C0587FE; Tue, 12 Sep 2017 17:30:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3B0F3C0587FE Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C81377DE0; Tue, 12 Sep 2017 17:30:32 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 12 Sep 2017 19:30:30 +0200 Message-ID: <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com> In-Reply-To: <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> References: <20170908225948.GC31695@al> <1505225444.4161.35.camel@redhat.com> <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2257818.DIBmMet8D4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 12 Sep 2017 17:30:35 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:30:36 -0000 --nextPart2257818.DIBmMet8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 12 September 2017 17:42:31 CEST Dr Stephen Henson wrote: > On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote: > > That is, because a TLS server would typically sign with whatever > > algorithm the client supports and would very rarely be interested to > > utilize the security advantages of including the parameters (which, > > advantages, are quite unclear even to a crypto expert). Otherwise, a > > certificate restricted to SHA-384 and 48-bytes of salt, will not be > > able to serve a client which only supports RSASSA-PSS with SHA-256. > >=20 > > As such, it would make sense for TLS 1.3 to recommend no parameters for > > such RSASSA-PSS certificates, to ease their deployment. >=20 > Well restrictions in CA keys would be handled by the PKI verifier: if the= re > is a violation the chain should be rejected and it's a problem with the > chain itself and an error by the CA that issued it. A different case is > where the restrictions are legal from a PKIX standpoint but not allowed by > TLS 1.3, though again it's a CA error issuing such a chain for TLS 1.3 us= e. >=20 > A restriction on the EE key isn't quite the same. There are two cases. >=20 > One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 > digest doesn't match signing digest or minimum salt length exceeds digest > length). In this case a server should never present the chain or if it do= es > a client would justifiably reject it and abort the handshake. Again this = is > an error by the issuing authority which should be corrected. >=20 > The second case is that the parameter restriction is permitted by TLS 1.3 > and this limits the digest which the key can sign with. Say the restricti= on > is SHA384 and the client only supports rsa_pss_sha256. The server might > then use to a different PSS key (and certificate chain) that supports > rsa_pss_sha256 or fall back to an RSA key to use rsa_pss_sha256. Again if= a > client sees a TLS message signed with parameters that violate the > restrictions it could (with some justification) abort the handshake. >=20 > This could get pretty messy: it requires a logic not used in any other > algorithm. I'd be more than happy to have an outright prohibition on EE P= SS > key parameter restrictions in TLS 1.3 so implementers don't have to bother > with this. what about hardware tokens that support only specific hashes or signatures? (I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA-384= or=20 SHA-512) Isn't it basically the same code path (though the limitation does= =20 come from slightly different place). =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 --nextPart2257818.DIBmMet8D4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZuBm2AAoJEJKo0bgB0vX1nHsQAIjxgMIfZVwmsSMI2Qi2C8zP d4Ctqy1vjkaQhGwO1mHzDVlTPdtZ+tAtW8/0oHOfuwrUBnRC6wn4zNTwXueDTF2A l8kWeCzp/TvaEZFc52DaHQUhXR5wTGpdUn8TAkGFrh/yw0F36FoH8cTNGC420gFF L/0cxryQ23Y4B4P8gPaI+DN80lopdHfjspNVvS3DHwta0ml6baKOXNw9yBKnJV1h rBnfoOtEl/p3IsMZBnOkLYngqX1UK0E5rYB+7/AfjxScLT5CqSIMFRfXfu/2OlOv PlSr+9hjdO3yd8mwYPpGyXQ9tufPHg+zJt+5sRzhAVpfL8yhczvSf1vruuQZ8rog CHHQ0LoAGmvlHNIiCtTE97nDgNIprHKM4FjeSPMXecUmc2zP/e5BtLmPa07W47RW QnIa0VDdXXO5arhxy/zAZ0h+9ff9K1unl6hI0ZctA2N/zreS/w7/q8Mw3zCdEibp Zvs+mTIvv3gUszXHUxqucMOf8knjlynsx4HaCGqgF8a0EmrJ7LTh68+DzIwn6WAU 9Z6LUKiqIfKCKDhgy2XG6EJXY9ZGBuNTqW2g1id57xvZu62/HpUeH1NeWN5EN2bF +bno9IkcA55QmoMCprZMOEY+PQokNMXFvBdOSpEuRrXDvmB9P4NMYQ6qDJt4s9ix E8zBa/xWoipSofNDV+lB =0mpk -----END PGP SIGNATURE----- --nextPart2257818.DIBmMet8D4-- From nobody Tue Sep 12 10:36:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28691132EC4 for ; Tue, 12 Sep 2017 10:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWU3dAcqj_98 for ; Tue, 12 Sep 2017 10:36:08 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2316E132EA7 for ; Tue, 12 Sep 2017 10:36:07 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v8CHa57o025139; Tue, 12 Sep 2017 13:36:05 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] RSASSA-PSS in certificates and "signature_algorithms" Thread-Index: AQHTKPY4UhEi4+aSakGFOcW9qXdI/qKwTHOAgAE+SwCAAAg8AIAAGaSAgAAeLAD//76AAA== Date: Tue, 12 Sep 2017 17:36:04 +0000 Message-ID: <21C4A934-8B10-40A8-950F-0E7B61F08613@ll.mit.edu> References: <20170908225948.GC31695@al> <1505225444.4161.35.camel@redhat.com> <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com> In-Reply-To: <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [172.25.177.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3588068164_1539450125" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709120245 Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:36:10 -0000 --B_3588068164_1539450125 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > . . .=20 > This could get pretty messy: it requires a logic not used in any othe= r > algorithm. I'd be more than happy to have an outright prohibition on = EE PSS > key parameter restrictions in TLS 1.3 so implementers don't have to b= other > with this. =20 what about hardware tokens that support only specific hashes or signatu= res? (I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA= -384 or=20 SHA-512) Isn't it basically the same code path (though the limitation d= oes=20 come from slightly different place). =20 I think that the requirement of having the same hash everywhere in this cer= tificate takes care of this problem.=20 If I=E2=80=99m missing the actual problem you=E2=80=99re pointing at =E2=80=93 please outline= the use case where it might manifest, and let=E2=80=99s take it from there. --B_3588068164_1539450125 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+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQge3z000jlis707CL8 3f2Ap2aoe0Bu0T74Gtnpqq9dqnwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwOTEyMTczNjA0WjANBgkqhkiG9w0BAQEFAASCAQAxYNb+IOeJ2ddzKfkA oWKgoP/6ULu+c15nLKSu1EvgDmrR7QGsCYgffDXnoMJa/Jyt6HTopp0LKSykvdn5l4OEjipN NXU1EInqqewcBRAkLt6dWFijQiqVNhvKslZIqzqWKu9z1yfbDZFGinT4lsKMypOYNMOwDhbZ +t3VuIsFz79K/aE6bULl8Oe+Q5qw5tA4p+TSal3solmP4hJFZoxJPFP5Kr4ltYHRzU81VELZ PPR0ynNfI/KejJu+py9IakX3jR7R7YbUtxG3Wb6hRB6msDiEzU4KOjSG2QRTM5F0J1az3+Er osvH0nn+XUp/i/S4jZkwF3+YmGjeS4RCjpRD --B_3588068164_1539450125-- From nobody Tue Sep 12 11:07:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10A5132EBB for ; Tue, 12 Sep 2017 11:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnk-wNl0rH0i for ; Tue, 12 Sep 2017 11:06:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2430132D6D for ; Tue, 12 Sep 2017 11:06:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 40D3A2F14A5; Tue, 12 Sep 2017 18:06:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 40D3A2F14A5 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0AC9D5D6A9; Tue, 12 Sep 2017 18:06:57 +0000 (UTC) From: Hubert Kario To: "Blumenthal, Uri - 0553 - MITLL" Cc: "tls@ietf.org" Date: Tue, 12 Sep 2017 20:06:55 +0200 Message-ID: <10457521.MfgfQs1Zne@pintsize.usersys.redhat.com> In-Reply-To: <21C4A934-8B10-40A8-950F-0E7B61F08613@ll.mit.edu> References: <20170908225948.GC31695@al> <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com> <21C4A934-8B10-40A8-950F-0E7B61F08613@ll.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13688465.g3UpIy5l7T"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 12 Sep 2017 18:06:57 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:06:59 -0000 --nextPart13688465.g3UpIy5l7T Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 12 September 2017 19:36:04 CEST Blumenthal, Uri - 0553 - MITLL= =20 wrote: > > > . . . > > >=20 > > > This could get pretty messy: it requires a logic not used in any > > > other > > > algorithm. I'd be more than happy to have an outright prohibition= on > > > EE PSS > > > key parameter restrictions in TLS 1.3 so implementers don't have = to > > > bother > > > with this. > > what about hardware tokens that support only specific hashes or > > signatures? (I've seen ones that can do only RSA with SHA256 and SHA-1, > > but > > not SHA-384 or SHA-512) Isn't it basically the same code path (though t= he > > limitation does come from slightly different place). >=20 > I think that the requirement of having the same hash everywhere in this > certificate takes care of this problem. >=20 > If I=E2=80=99m missing the actual problem you=E2=80=99re pointing at =E2= =80=93 please outline the > use case where it might manifest, and let=E2=80=99s take it from there. What Stephen is pointing at, is a server certificate (End Entity certificat= e)=20 when using RSA-PSS public key id in the X.509 certificate can have RSA-PSS= =20 parameters in the public key id or can have them omitted. When the paramete= rs=20 are omitted, it means that that key can be used for signing with any hash=20 (SHA-1, SHA-256, SHA-384, SHA3-256, etc.) but must be used with rsa-pss=20 padding scheme. When the parameters are present the hash is set in stone an= d=20 that key can then be used to sign with one hash and one hash only - the has= h=20 that is specified in certificate (and rsa-pss padding). Now, if the certificate specifies in parameters SHA384 hash and client=20 advertises support only for SHA256 with RSA-PSS, the server should switch t= o=20 (e.g.) ECDSA certificate that does not have that limitation and continue=20 connection instead of aborting the connection (very bad) or sending=20 certificate which most likely will be rejected by client as not=20 understandable/unverifiable (bad). What I've added is that that limitation may not come from the certificate b= ut=20 may come from the cryptographic module (software or hardware) that implemen= ts=20 rsa-pss with just one or two hashes, irrespective of rsa-pss parameters in = the=20 certificate public key id. So, I'm not sure what hash you are suggesting should be "the same everywher= e". I'm quite sure you're not suggesting that we should limit TLS 1.3 to SHA256= =20 only (no SHA384 or SHA512), are you? =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 --nextPart13688465.g3UpIy5l7T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZuCI/AAoJEJKo0bgB0vX11yIP/iNETOIHQpl6jh6u5SvurMu7 a7IQAn0RvUSKu60I0XBK5FD2mz29+6IyAcBSV+bzc2sEUYoFU5Aden5RTpfDDsgQ 2PqVJlmsOH+A6PBtusOGlK/QPCwbIZJyMVf6TEvr4PSauBRMhmOCVW7VdPsqavaU /PjYFVuof56J/RNuHiuRS9s/hzm4SPM4XcTF1tPRzQNINTh/6okmZi4l5ET6F0kB TwRQXJt0gAXK4Eg9e1bx0QYR72eQM1ACFCilGxdNtC2//eUrVdCJXa4HWQRNU3EM F6hUvLpFsNXjlrvSMXAZin1390waGMzmgjVEGGmewX/ckAlZ9/N4cKKgg7fOnVU0 uK3W1Np72tUscSbJuVLanLdgPJEesMDGTBgjM8QKb4XxIdBwEk/Tof+AF3bE+jhZ JYYIvAemOhtuvuOZc6m+niJlOlFi6FvZQd61OzSIC7w+dkPs+uI5gJ87VXTIHO+5 SGMgC/PzFPOK+MPoPK14w3LNM+layklK1ALKLMGgt9J13n6uWgluMe/HFzpfpH81 jlR/Z5aeof9/Z1aOwUBMphGSB5RhpOK/Jbey7vZ6LpeY4BY4GtrjWRIFuq62JZp7 HeeP5/nBUpd4m4fIPNGcH2V2ArZAOQAkIQeQy4jWZdjT3U2ndLPVOSnn8U80R/ak 0W0LLbXwC93yQZkJ7nW+ =DtIt -----END PGP SIGNATURE----- --nextPart13688465.g3UpIy5l7T-- From nobody Tue Sep 12 11:11:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1801A132D6D for ; Tue, 12 Sep 2017 11:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBspjI5_F3Zl for ; Tue, 12 Sep 2017 11:11:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E99126B6D for ; Tue, 12 Sep 2017 11:11:11 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4CDF2800A4; Tue, 12 Sep 2017 18:11:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4CDF2800A4 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A66D6062A; Tue, 12 Sep 2017 18:11:11 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 12 Sep 2017 20:11:09 +0200 Message-ID: <2127515.TzRoSAlNJ7@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart43011322.ZmSroSPDY6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 12 Sep 2017 18:11:11 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:11:13 -0000 --nextPart43011322.ZmSroSPDY6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote: > Hi Martin, >=20 > I have implemented the record size extension into mbed TLS. It can be > found at https://github.com/ARMmbed/mbedtls/pull/1088 >=20 > There is only one problem that remains to be addressed IMHO. This > extension was developed to address the problem of devices with small > RAM. Application developers have to configure their embedded TLS stack > in such a way that the parameters configured with this TLS extensions > match the available hardware. >=20 > The record_size_limit helps a lot already but does not quite to the > final goal since it uses an artificial metric for deciding when to > fragment records. >=20 > Currently, a developer has to understand various security concepts to > get this right, namely > * Ciphersuite negotiated (and the overhead associated with it, such as > tag length), > * DTLS vs. TLS record layer header differences, > * potential compression being applied. >=20 > Additionally, there is, of course, other header information that needs > to be considered in the overall buffer size calculation, such as TCP or > UDP, IP and potentially any lower layer headers. >=20 > I just think that this is too much to ask for from an ordinary developer. >=20 > Hence, I would suggest to use a different metric so that the developer > can be certain that at least from a DTLS/TLS layer there are not records > being sent that exceed the indicated threshold. >=20 > If you think that this idea is worthwhile to entertain then I will make > a proposal. yes, I too found the necessary calculation rather complex and thus hard to = get=20 right that being said, if you are ok with "good enough" solutions (for memory=20 allocation, for verifying correctness of packets it should be exact), the=20 actual receive buffer for encrypted TLS records has to be only 85 bytes lon= ger=20 than the value you send to server: - max MAC size - 48 bytes - max IV size - 16 bytes - header size - 5 bytes - max block size for CBC ciphers - 16 bytes - max padding - 16 bytes since MAC size is the exact multiple of block size, the padding starts in=20 worst possible place if the MAC size is arranged on block boundary. Thus th= e=20 worst case scenario padding length is 16 bytes. Same in case of EtM. =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 --nextPart43011322.ZmSroSPDY6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZuCM9AAoJEJKo0bgB0vX1k80QAKJ1q2nQEubK1NnCgMQbFmVB GgSsAZg01Wnv8I1o0ep6YfDiUSMEnqtbGZ3+YsOLNqVe/F5hgsyytXtJGzW5V5IX ZeFzF1VhDQY5AGxPR12wuoiNjji+qGv7q4j5AEv1//ty5itLkQMy5XVnFceXU918 ibR32a+BqRSPBESaPcu+rKOv1bpFyXzbvMD9WMav6KCAB8UbZ8jwXJP/NSlrvkqg +3VXeWC6yzESYKxGziqWvNS513jTUF9zXCTdx7mz+rTdu6Jl23GIA1uLjHk2wNzb hmKSZwGNf5TWm6W95/x0CzxHX9ph/kJsDC9vmnWODpKl4FenMvIlDtfLV6gdFBfQ E1OQqY/dEPPJSPVIUZPHi+MoiLA7XcH+yzabMuxht3e27BfxDGJPLNOZMS1CHwfe XXKhiZ690sIgNBVaqAMf5u9TWweoMI9mxxIHcSeDGDY5jmLAJ7A/PktbfBbDlkcc ehtNkZMsq7uNQ97+pnE/Q0mESWAeZtEdCSYA/SYOJlPSNoL8qvO5sTuHfG8gqr/R 3L9FPo8PFXOKRlT6RPfDGJ2uEtN9OYk/w9Pl2BWhaKvo41GkVur3LuJHFOKxRwXZ vcOszLOxiJVbQuTMne1raeTj/Ig6VV4pL08NlErR7B0DshFidQC4n8mb3KmYcIxS 0ePMrNlSwYBy6NG+GCn6 =fzAX -----END PGP SIGNATURE----- --nextPart43011322.ZmSroSPDY6-- From nobody Tue Sep 12 11:33:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39426132EC0 for ; Tue, 12 Sep 2017 11:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgv1qObUMdhm for ; Tue, 12 Sep 2017 11:33:27 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 09A6A126B6D for ; Tue, 12 Sep 2017 11:33:25 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v8CIXMTC013876; Tue, 12 Sep 2017 14:33:22 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] RSASSA-PSS in certificates and "signature_algorithms" Thread-Index: AQHTKPY4UhEi4+aSakGFOcW9qXdI/qKwTHOAgAE+SwCAAAg8AIAAGaSAgAAeLAD//76AAIAAS62A///EVIA= Date: Tue, 12 Sep 2017 18:33:21 +0000 Message-ID: References: <20170908225948.GC31695@al> <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com> <21C4A934-8B10-40A8-950F-0E7B61F08613@ll.mit.edu> <10457521.MfgfQs1Zne@pintsize.usersys.redhat.com> In-Reply-To: <10457521.MfgfQs1Zne@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [172.25.177.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3588071601_482689662" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709120258 Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:33:31 -0000 --B_3588071601_482689662 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable What Stephen is pointing at, is a server certificate (End Entity certif= icate)=20 when using RSA-PSS public key id in the X.509 certificate can have RSA-= PSS=20 parameters in the public key id or can have them omitted. Yes. And I concur with him that it is better to omit them, enforcing the de= fault. The default being: - Hash algorithm the same as specified in Signature Algorithm - MGF1 hash is the same as above - Salt length same as digest length above When the parameters=20 are omitted, it means that that key can be used for signing with any ha= sh=20 (SHA-1, SHA-256, SHA-384, SHA3-256, etc.) but must be used with rsa-pss= =20 padding scheme. Not quite. Since this key is a part of the given certificate =E2=80=93 RSA-PSS pa= dding scheme should be used with the same hash as =E2=80=9CSignature Algorithm=E2=80=9D = specifies. When the parameters are present the hash is set in stone and=20 that key can then be used to sign with one hash and one hash only - the= hash=20 that is specified in certificate (and rsa-pss padding). I think the point Stephen was making is that Signature Algorithm specifies = a hash =E2=80=93 and there=E2=80=99s no reason to use a different one for MGF1. =20 Now, if the certificate specifies in parameters SHA384 hash and client=20 advertises support only for SHA256 with RSA-PSS, the server should swit= ch to=20 (e.g.) ECDSA certificate that does not have that limitation and continu= e=20 connection instead of aborting the connection (very bad) or sending=20 certificate which most likely will be rejected by client as not=20 understandable/unverifiable (bad). This is a different question. The point being addressed here is that each c= ertificate is internally consistent, using the same hash for all the purpose= s within that certificate. If the server=E2=80=99s certificate is signed with SHA384, so be it. There=E2=80=99s no= reason for a client to not support SHA384 *for signature verification*, as = hardware token restrictions shouldn=E2=80=99t apply here =E2=80=93 it=E2=80=99s software-based= validation. =20 What I've added is that that limitation may not come from the certifica= te but=20 may come from the cryptographic module (software or hardware) that impl= ements=20 rsa-pss with just one or two hashes, irrespective of rsa-pss parameters= in the=20 certificate public key id. The cryptographic module would perform RSA-PSS *signature* with whatever ha= shes it can. It won=E2=80=99t bother with *validation*, so this module=E2=80=99s limitat= ions shouldn=E2=80=99t matter. =20 So, I'm not sure what hash you are suggesting should be "the same every= where". Within one certificate =E2=80=93 one hash. I.e., *no* SHA512 in Signature Algorit= hm, SHA384 for message hash in SHA384-RSA-PKCS-PSS, SHA256 for MGF1. I'm quite sure you're not suggesting that we should limit TLS 1.3 to SH= A256=20 only (no SHA384 or SHA512), are you? Oh no =E2=80=93 I=E2=80=99m eccentric but not quite insane yet. ;-) --B_3588071601_482689662 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+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgq/ZUazzv5R7dcyjS Lm83jHrRDtKpbka22+asAWCoD/QwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwOTEyMTgzMzIxWjANBgkqhkiG9w0BAQEFAASCAQBcN54ySe8yAR6xo+dN hdBP1/YhocDQ0mwGG5xGY9D+sGAGDC5Kj/2mW7ZmEPEmSaHHVMkOkBcQ91osDqUvgTjE3v4Q wGH3gp1+MdAajcWBVh7tES8hy2OwJLpivhytdPschSkCW5RJkwCM1R0FPePO82/UMrQ+efDI DsoV+MhlNe/UL+HXb9eTysludTow9FSQBHAzxGCFNR4McHK2xwHICmDy29HPd6HitVqh+7o6 pGU0qoi6gD07kPBeLSDwO+22ZEPR3OjjRjfxAVxbgUUvm/ZPDGGB4U/KAUyT2lbjR+U1gTJy Ire6LQcYPnP9mpuJ3FoPhhsyL4Wp90c4UoH3 --B_3588071601_482689662-- From nobody Tue Sep 12 17:14:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE0D132F82 for ; Tue, 12 Sep 2017 17:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXLlx4vGaybz for ; Tue, 12 Sep 2017 17:13:56 -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 4639D132707 for ; Tue, 12 Sep 2017 17:13:56 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r20so37337248oie.0 for ; Tue, 12 Sep 2017 17:13:56 -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=PrksipCp4G4huSR7fMihycQDSg429/On6lvscUvVHM4=; b=W4icOhHkF3qUETi5+b00PLGzGSpY8mNMv2byJkewDvYV16br8WpyoaOzmAMupEcrdw vD0/RJa9Uq1FUX+CnqpaU4NkMXpCSTRDGuWh9c33wtqa66CnyeP9rDWz1e1aVn6s86x3 X71zx5rJbjKRp0iSkbi/WJn7lNiqYEHs278t6p85Q2BYVVR9gwcTkYttFjD+j9RJ6mWg 3zEIjlTPcZ0SqS8CpAxL28Qy9qxOnA7z0aoVcn9OECxEbwqHoOUgvJDQMRtVA/6Zt0a/ ebCFw6Mt8Z/SVgq7TNkuoN2nDCLojV9UKDgcCSMFdEP51z9GFcfobh5KYMtCb6GIdyz+ CZhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=PrksipCp4G4huSR7fMihycQDSg429/On6lvscUvVHM4=; b=pwR+gc8Xt97WmtVbZNpIt0kilzRwTOL39Q3gfBchMaDj7in+tG3ng5k0XKbnSvMOdx SPIen4g9+n0WmG3VnK67ZjlssaepVBc5dMLVlSTgvUnY9Tk97X4URpjpDhEZGhbowrpr hHC5sy7KIdUDq/lqvI66Pb/ha5E4Lvw+MToOJkfkRp+9Q0ThnmzR10MqEChqiIXpA1uF O6ypyrZSsox5Z7wdeSHtl1uZub8DcOv/rGZ/Hr3IsicCzhVxtgvnoC41faF4Oed5i82N pPvIzZIPfx1+EAtLvPp5vj3Dz39aDFoHelKaHsNXIDIH4y0lK3hiqT59iOYW5RUYbtE8 AzKw== X-Gm-Message-State: AHPjjUgDPIJfjULfgv/d2MWHSO3zufmgOlE0JvDBMPPKORPrNNctcbz4 zlPJHJ60OB+KaFeYUM5gsfA0B+zFHbwzwM3JLA== X-Google-Smtp-Source: AOwi7QC7ubkbA4hIvnk6Myef4yOSWiqJlOzgICI+utuO9zfNUP5NoEXywZ/WW1K2mRuEZ8mvX5rrAimjXRMkHvs56/s= X-Received: by 10.202.171.201 with SMTP id u192mr19022489oie.58.1505261635614; Tue, 12 Sep 2017 17:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.69.11 with HTTP; Tue, 12 Sep 2017 17:13:14 -0700 (PDT) In-Reply-To: References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> From: Eric Rescorla Date: Tue, 12 Sep 2017 17:13:14 -0700 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113ceb8e15d29c0559070920" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 00:13:58 -0000 --001a113ceb8e15d29c0559070920 Content-Type: text/plain; charset="UTF-8" Thanks to Victor and Benjamin we now have a proposal for addressing this that I think is acceptable to all (most) and had consensus in Prague: https://github.com/tlswg/tls13-spec/pull/1059/files Absent significant objection, I will merge this on Friday. -Ekr On Thu, Jul 6, 2017 at 12:10 PM, Benjamin Kaduk wrote: > On 06/30/2017 11:32 AM, Benjamin Kaduk wrote: > > On 06/29/2017 03:53 PM, Eric Rescorla wrote: > > I have updated the PR to match people's comments. I would like to merge > this soon, so please get any final comments in. > > > I made a couple comments on the PR that are more appropriate for the list, > so I'll repeat them here and hopefully get replies from the broader > audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't quite > seem realistic to require "MUST use either [single-use tickets] or > [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST limit > replays to at most the number of endpoints capable of accepting connections > for a given identity, and SHOULD provide even stronger replay protections, > such as [single-use tickets] or [ClientHello recording]." I think we have > general agreement that strong anti-replay as described in the document is > feasible for a single-server deployment, and this last formulation is > achievable in multi-server environments by just giving each server its own > local per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here for > everyone's consideration. > > > Or are there no such arguments? > The only one I remember is the implementation complexity for distributed > systems, but if you can implement for a single-node system my compromise > proposal is trivially implementable. > > -Ben > --001a113ceb8e15d29c0559070920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to Victor and Benjamin we now have a proposal for a= ddressing this that
I think is acceptable to all (most) and had consens= us in Prague:


Absent significant objection, I will = merge this on Friday.

-Ekr


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

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


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

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

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

-Ben

--001a113ceb8e15d29c0559070920-- From nobody Tue Sep 12 17:32:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554BA1331C1 for ; Tue, 12 Sep 2017 17:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDvvbfGmk5zZ for ; Tue, 12 Sep 2017 17:32:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 C3AB1132707 for ; Tue, 12 Sep 2017 17:32:53 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8D0WqKM012638; Wed, 13 Sep 2017 01:32:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=xEJNTEvlTLzZzzpRXOp0oBdTrQE3K5mYNfDg8Bk8oy0=; b=ivsyxl1DKMSikOllZrebCfb30qbCjo5VZyI2o9kNX5oC492GmiXQ1J3zH9IpVpuwVCRf spst1N1aBjdcFejNyZD/WUZw3i7/2FIrAK0+y9RwyRa2egM9XqB5Vz/lCTN7OZAN5Y0j yhFnPL3z9qgKdOY5eHVcxY4o/YX0bwq0BYoNwf0cGlhc9nP+IbJo75nNu7FW1eszO6qO sWx+CUj3gR8UvQcWICvPxF0+yPNc0qfp353zkbFEnV096nUW+CucvKLcnQHlOQpw3x5f YkZ8R4M8PBaEMfZ7ZX+j4p7/EJkH/5WxqD4scU4lV8XQWMCnXzLbNZk0f0ioOdWgvBUX jg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2cxfxy2ykd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 01:32:51 +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 v8D0UdQl004478; Tue, 12 Sep 2017 20:32:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2cww9wj758-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Sep 2017 20:32:50 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag3mb5.msg.corp.akamai.com (172.27.27.27) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 20:32:49 -0400 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.1263.000; Tue, 12 Sep 2017 19:32:49 -0500 From: "Salz, Rich" To: Eric Rescorla , "Kaduk, Ben" CC: "tls@ietf.org" Thread-Topic: [TLS] Closing on 0-RTT Thread-Index: AQHS4sYMYZjiI3AtlUaLYB0HLNHkW6KyhOOugAAV+gA= Date: Wed, 13 Sep 2017 00:32:48 +0000 Message-ID: <14E4D63A-6CD1-467A-ABD4-DC7C517BB060@akamai.com> References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.25] Content-Type: multipart/alternative; boundary="_000_14E4D63A6CD1467AABD4DC7C517BB060akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-12_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130006 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-12_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130007 Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 00:32:55 -0000 --_000_14E4D63A6CD1467AABD4DC7C517BB060akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMTA1OS9maWxlczxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1 Yi5jb21fdGxzd2dfdGxzMTMtMkRzcGVjX3B1bGxfMTA1OV9maWxlcyZkPUR3TUZhUSZjPTk2WmJa WmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09ODJmU3FKbUNiVTF0 b2J0UVFBWVhuemVlU01Pa1ZRaDNyVm9FNDktQzVfOCZzPWItV3V6cmhHRDFHcVg0YzZoOGgyS3BX d3NmQWV3bnc5OW02SzhSNG1HZDAmZT0+DQoNCk5pY2Ugd29yayENCg== --_000_14E4D63A6CD1467AABD4DC7C517BB060akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <862E9E489842724988E5663B88D24607@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCglt YXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjUwODk2NjQ1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDU0NzM5OTU0IC0yMDkyNTIwOTI2IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJv bGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fdGxzd2dfdGxzMTMt MkRzcGVjX3B1bGxfMTA1OV9maWxlcyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPTgyZlNxSm1DYlUxdG9i dFFRQVlYbnplZVNNT2tWUWgzclZvRTQ5LUM1XzgmYW1wO3M9Yi1XdXpyaEdEMUdxWDRjNmg4aDJL cFd3c2ZBZXdudzk5bTZLOFI0bUdkMCZhbXA7ZT0iPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90 bHMxMy1zcGVjL3B1bGwvMTA1OS9maWxlczwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5pY2Ugd29yayE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_14E4D63A6CD1467AABD4DC7C517BB060akamaicom_-- From nobody Wed Sep 13 03:55:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713BC134210 for ; Wed, 13 Sep 2017 03:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnJnqyuwt7vb for ; Wed, 13 Sep 2017 03:55:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90EF133011 for ; Wed, 13 Sep 2017 03:55:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63E1C80F94; Wed, 13 Sep 2017 10:55:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 63E1C80F94 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0D7E65FCA9; Wed, 13 Sep 2017 10:55:48 +0000 (UTC) From: Hubert Kario To: "Blumenthal, Uri - 0553 - MITLL" Cc: "tls@ietf.org" Date: Wed, 13 Sep 2017 12:55:42 +0200 Message-ID: <11673774.J8OL2FLGDl@pintsize.usersys.redhat.com> In-Reply-To: References: <20170908225948.GC31695@al> <10457521.MfgfQs1Zne@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2173801.fldrGBKkiC"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Sep 2017 10:55:49 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:55:51 -0000 --nextPart2173801.fldrGBKkiC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 12 September 2017 20:33:21 CEST Blumenthal, Uri - 0553 - MITLL= =20 wrote: > > What Stephen is pointing at, is a server certificate (End Entity > >=20 > > certificate) when using RSA-PSS public key id in the X.509 certificate = can > > have RSA-PSS parameters in the public key id or can have them omitted. >=20 > Yes. And I concur with him that it is better to omit them,=20 and I'm saying that such limitation on EE certificate won't help much if yo= u=20 also support hardware tokens as they can limit supported signature schemes = too > enforcing the > default. The default being:=20 > - Hash algorithm the same as specified in Signature Algorithm > - MGF1 hash is the same as above > - Salt length same as digest length above No problem with that being recommendation, but I've seen people claiming th= at=20 some applications don't follow that salt length requirement, so I'd say it= =20 would cause unnecessary problems if it was set too strict =20 > > When the parameters are present the hash is set in stone and > > that key can then be used to sign with one hash and one hash only - > > the > >=20 > > hash that is specified in certificate (and rsa-pss padding). >=20 > I think the point Stephen was making is that Signature Algorithm specifie= s a > hash =E2=80=93 and there=E2=80=99s no reason to use a different one for M= GF1. this is not a problem we're talking about, I don't have any kind of problem= =20 with MGF1 requirement to be the same as the signature hash > > Now, if the certificate specifies in parameters SHA384 hash and cli= ent > > advertises support only for SHA256 with RSA-PSS, the server should > >=20 > > switch to (e.g.) ECDSA certificate that does not have that limitation a= nd > > continue connection instead of aborting the connection (very bad) or > > sending certificate which most likely will be rejected by client as not > > understandable/unverifiable (bad). >=20 > This is a different question. The point being addressed here is that each > certificate is internally consistent, using the same hash for all the > purposes within that certificate. and what you're talking about is a non-issue. Binding MGF1 hash with signat= ure=20 hash is sensible and unlikely to cause problems. =20 > If the server=E2=80=99s certificate is signed with SHA384, so be it. Ther= e=E2=80=99s no > reason for a client to not support SHA384 *for signature verification*, as > hardware token restrictions shouldn=E2=80=99t apply here =E2=80=93 it=E2= =80=99s software-based > validation. I'm talking about subjectPublicKeyInfo field, *not* about signatureAlgorith= m=20 field from RFC 3280 and there are clients that advertise only a subset of hashes: https://www.ssllabs.com/ssltest/viewClient.html? name=3DSafari&version=3D6&platform=3DiOS%206.0.1&key=3D33 =20 > > What I've added is that that limitation may not come from the > >=20 > > certificate but may come from the cryptographic module (software or > > hardware) that implements rsa-pss with just one or two hashes, > > irrespective > > of rsa-pss parameters in the certificate public key id. >=20 > The cryptographic module would perform RSA-PSS *signature* with whatever > hashes it can. It won=E2=80=99t bother with *validation*, so this module= =E2=80=99s > limitations shouldn=E2=80=99t matter. but it can't perform that signature using hash=20 *that the client didn't advertise* > > So, I'm not sure what hash you are suggesting should be "the same > > everywhere". >=20 > Within one certificate =E2=80=93 one hash. I.e., *no* SHA512 in Signature= Algorithm, > SHA384 for message hash in SHA384-RSA-PKCS-PSS, SHA256 for MGF1. There are four places in which different hashes can be in a certificate: subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm subjectPublicKeyInfo.algorithm.parameters.maskGenAlgorithm signatureAlgorithm.algorithm.parameters.hashAlgorithm signatureAlgorithm.algorithm.parameters.maskGenAlgorithm Now, because the subjectPublicKeyInfo is chosen by the person generating th= e=20 key (user) and signatureAlgorithm is chosen by the CA, and it is quite comm= on=20 already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA that= =20 then signs EE with a SHA-256. I really don't think that *all* hashes should= be=20 the same. How exactly using more secure parameters for longer lived keys is a bad ide= a? > > I'm quite sure you're not suggesting that we should limit TLS 1.3 to > > SHA256 only (no SHA384 or SHA512), are you? >=20 > Oh no =E2=80=93 I=E2=80=99m eccentric but not quite insane yet. ;-) well, we do work on ASN.1 stuff... ;) =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 --nextPart2173801.fldrGBKkiC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZuQ6uAAoJEJKo0bgB0vX1Sv4P/3fOiZrtzu/WEQaoqCC6fk5/ n7VOBN+n9n8CbgxIYi94llIm4dlwOXPUuL29SnT4FmGoGD4gXXa3iXBrbWLzLGi8 brGTuqqmMISC5BbHFYfMl/ayqnW21dm7FXm2jWhScRrUg/NIjzfcnrg0gjLrd2KJ ySpGWOrEc2FhlqL+TVmgdH9yhxuybRwioXnlcTklntSLaBJHus3UYQGXGog62gp/ oyVlysgXkbvp5y6KSoXyRyw0IIZHyGI5RH3AXo9/31BYi5wjB+NpRKAF6czOrDy7 /uwZXqIMw5o+M0+XqxnEiJebn+QtWPedj0qUfi1Y7Snn48V1fMxtlrdfKKcHaLbg u6tr1oHvJhr/OJFYMy02jw5ZmKcUeZ6RsqitFEnRaspc+BloAAhj/nEZUla48aLx UuqsSFDSFyIH/hFFLTHXE9TFlMGpyG+MVt5OvxowpNcTt+7CRYQVtQ3+C+LI43H3 xGK6OR1+GunSspNsN6cyPcXMdN7/sN0BnAS2UCsCBBSd6E0h64gFU2qiwAXadTD+ eXntcGb3a+keJ9L/N3bktw4UJZYvU5JSS+tQkmudLbMN0sYuKUSBbC6Y8oEYme0v y8QooDnZaBCeselGHiKOiOOujdZ7i65TXyf1Ct0MUTaBpP8RJ277etc3ZeMW9Fm5 /U+IPpPXLIeEpETzDKI5 =bawv -----END PGP SIGNATURE----- --nextPart2173801.fldrGBKkiC-- From nobody Wed Sep 13 07:18:17 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD65133048 for ; Wed, 13 Sep 2017 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 NRSblKgnUFWc for ; Wed, 13 Sep 2017 07:18:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D09133039 for ; Wed, 13 Sep 2017 07:18:07 -0700 (PDT) Received: from [192.168.91.203] ([131.111.5.143]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFuC6-1dgWqD0aF4-00Et5k; Wed, 13 Sep 2017 16:17:55 +0200 To: Hubert Kario , tls@ietf.org References: <2127515.TzRoSAlNJ7@pintsize.usersys.redhat.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <591ffde5-6ca6-e9a1-e99e-2ee8bc61708b@gmx.net> Date: Wed, 13 Sep 2017 16:17:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2127515.TzRoSAlNJ7@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TJ0IKDtAQVbuGCT8rkvHqgBBBmVNyXscpCP9pan/NJkEbueQ5ZV uxqI+fXAe96X2mmHbnEno113yTCloZ30PSTpPGMWgEKhMxatAExfsBb3FrGpqiJvNaHzIjH 08orGz/IAdKSY4aBZx89P8KmdFwmmIuw7Qwexr7JgYzJhgtpEneUkNRfclyCsMFdWXmriy8 3GCCTJGJUjT5IYxNwpvCQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:HN6zokdPtDA=:G5ft0xEtUlxtSxmObIIgNB P/+HVMBHqsQI/62PQH/aLs42gFjhAfPLZW/mD5fam5y6p2Zq+zg6UyNrvxn4uTObXZaHoYU5w bd1FbllgNsR/C9B4ZTeWfBFpw3sjioLQ8icy6+3nOnG0b6lkwQ/XZK4PBUl2Mtr7BjjY5GwKA miW4BcM3QZip+3sQc8e4+suOWN3C4ArI5voC0wyFQqapW91eqrqALUeC3LN33eJrriD6Z+Y1K vRzYp+MJK+q9Kl6C/jgT8V6gIsToCICNZLCeEddzTk1iyWxHAHRSfW8UBKL68vuJh9xywH4oH FEz2Y+jhbBRVlqtd4wCS1LVzjjA8yVB/UjG+rlPuPz4a9kJAdBlT2ihCoxOFCpe7lH3En9z89 /maOeVrNZVBVIlz0lOvUgTloDMdNs+jIz+d0m3y/+S/ndB1QnNyzjp3cU8aI6YSRThmctbZDU 1VLPr0IOmO7LFhwRrNckpQ0Rn7qDRsBmAi48NhPKJmqDyHO6CPIhsB7jBiJYbqapk3h43zkNM B91eIkLbjo+/NAAnDNZa3QotBEWy7V/LA49oKKPFoLMWDQnPKv+WEHCQVmwJFkrRxzj2s6rT4 Mr75Y9BicCex/hY4O1DyUIDIGNfTbk9sdoVZFG48eQKRNIATTyUM07t5bHcZj4vakOv/+DegT XLpFYSX+xixmr2m1b80qmiICZPUz3CRbrmUrWNAiKrXh/RwVR3iXtro04Ow+NquXmfPBrS74b LybZogSKvcO1011ccCraNitlu0PfnMEDPdQKBUhbgXwheWUlAxJP7G0dH8aOTawCzz6oQB99t GCSNYnaEXDtB+HdQASRwVSk8NFpmlLNVh3U1lNSmQt1EA4L8MQ= Archived-At: Subject: Re: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:18:16 -0000 Hi Hubert, your proposal to include the worst case calculations are indeed another possibility. It provides more information for the developer than the current version of the document. A few additional remarks: On 09/12/2017 08:11 PM, Hubert Kario wrote: > On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote: >> Hi Martin, >> >> I have implemented the record size extension into mbed TLS. It can be >> found at https://github.com/ARMmbed/mbedtls/pull/1088 >> >> There is only one problem that remains to be addressed IMHO. This >> extension was developed to address the problem of devices with small >> RAM. Application developers have to configure their embedded TLS stack >> in such a way that the parameters configured with this TLS extensions >> match the available hardware. >> >> The record_size_limit helps a lot already but does not quite to the >> final goal since it uses an artificial metric for deciding when to >> fragment records. >> >> Currently, a developer has to understand various security concepts to >> get this right, namely >> * Ciphersuite negotiated (and the overhead associated with it, such as >> tag length), >> * DTLS vs. TLS record layer header differences, >> * potential compression being applied. >> >> Additionally, there is, of course, other header information that needs >> to be considered in the overall buffer size calculation, such as TCP or >> UDP, IP and potentially any lower layer headers. >> >> I just think that this is too much to ask for from an ordinary developer. >> >> Hence, I would suggest to use a different metric so that the developer >> can be certain that at least from a DTLS/TLS layer there are not records >> being sent that exceed the indicated threshold. >> >> If you think that this idea is worthwhile to entertain then I will make >> a proposal. > > yes, I too found the necessary calculation rather complex and thus hard to get > right > > that being said, if you are ok with "good enough" solutions (for memory > allocation, for verifying correctness of packets it should be exact), the > actual receive buffer for encrypted TLS records has to be only 85 bytes longer > than the value you send to server: > - max MAC size - 48 bytes > - max IV size - 16 bytes > - header size - 5 bytes ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most likely different since we are trying to optimize the record layer format. > - max block size for CBC ciphers - 16 bytes > - max padding - 16 bytes ... unless TLS/DTLS 1.3 is used where padding is a different meaning. > since MAC size is the exact multiple of block size, the padding starts in > worst possible place if the MAC size is arranged on block boundary. Thus the > worst case scenario padding length is 16 bytes. Same in case of EtM. Ciao Hannes From nobody Wed Sep 13 07:35:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF479133039 for ; Wed, 13 Sep 2017 07:35:29 -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 rBPYofGRK3-O for ; Wed, 13 Sep 2017 07:35:27 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9971C1321C7 for ; Wed, 13 Sep 2017 07:35:27 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v8DEZQ4R003212; Wed, 13 Sep 2017 10:35:26 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] RSASSA-PSS in certificates and "signature_algorithms" Thread-Index: AQHTKPY4UhEi4+aSakGFOcW9qXdI/qKwTHOAgAE+SwCAAAg8AIAAGaSAgAAeLAD//76AAIAAS62A///EVICAAVWGAP//+lWA Date: Wed, 13 Sep 2017 14:35:25 +0000 Message-ID: References: <20170908225948.GC31695@al> <10457521.MfgfQs1Zne@pintsize.usersys.redhat.com> <11673774.J8OL2FLGDl@pintsize.usersys.redhat.com> In-Reply-To: <11673774.J8OL2FLGDl@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [172.25.177.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3588143725_833612516" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130226 Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:35:30 -0000 --B_3588143725_833612516 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > enforcing the default. The default being:=20 > - Hash algorithm the same as specified in Signature Algorithm > - MGF1 hash is the same as above > - Salt length same as digest length above =20 No problem with that being recommendation, but I've seen people claimin= g that=20 some applications don't follow that salt length requirement, so I'd say= it=20 would cause unnecessary problems if it was set too strict I=E2=80=99m sure some apps follow, and some don=E2=80=99t. I=E2=80=99m simply saying that it = makes sense for TLS to pick a sensible default (like the above) and stick wi= th it. Other apps may do what they think is best. =20 As for above, in view of the following discussion I think it would be bette= r to replace =E2=80=9CSignature Algorithm=E2=80=9D above with =E2=80=9CsubjectPublicKeyInfo.al= gorithm.parameters.hashAlgorithm=E2=80=9D. I still think that only the necessary minimum of parameters should be passe= d explicitly. I'm talking about subjectPublicKeyInfo field, *not* about signatureAlgo= rithm=20 field from RFC 3280 =20 OK, point taken. Thanks for clarifying. and there are clients that advertise only a subset of hashes: https://www.ssllabs.com/ssltest/viewClient.html? name=3DSafari&version=3D6&platform=3DiOS%206.0.1&key=3D33 =20 Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device = somewhere. ;-) > The cryptographic module would perform RSA-PSS *signature* with whate= ver > hashes it can. It won=E2=80=99t bother with *validation*, so this module=E2=80=99= s > limitations shouldn=E2=80=99t matter. =20 but it can't perform that signature using hash=20 *that the client didn't advertise* =20 You=E2=80=99re probably right. But for my benefit, could you please outline the s= cenario how this would/could be used? To make sure I completely understand t= he use case? Now, because the subjectPublicKeyInfo is chosen by the person generatin= g the=20 key (user) and signatureAlgorithm is chosen by the CA, and it is quite = common=20 already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA = that=20 then signs EE with a SHA-256. I really don't think that *all* hashes sh= ould be=20 the same. =20 OK, you convinced me here. I missed that. :-( > Oh no =E2=80=93 I=E2=80=99m eccentric but not quite insane yet. ;-) =20 well, we do work on ASN.1 stuff... ;) And I start developing liking of ASN.1. Does it mean it=E2=80=99s time to get my = head examined? ;-) --B_3588143725_833612516 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+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgjZkxalI8pQiBTi77 +Z6G/V844RBnL5LqneakINQfiKIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwOTEzMTQzNTI1WjANBgkqhkiG9w0BAQEFAASCAQAUKrYAeHQH/xmgS376 GuBWeu/exfYCnCxq52vUypTRMJLiNsZ9u89FRobFs7vOJlx076sY2xHz7YZ5eldf7l8T4Ra4 EVQiNkVAw0iYJ7p24IVUP8MaOYigtvLAS0U6i5gkkw+FMJ6tCuBcR7bOMSeVCgy405X6sUmF LlK0bX7uiUVTqhqJ9sZBUyGYQMUApkDV683wOIh4oJrfuu9W8WYXRgtamC+Rp387t/CggsjL IN2trKwmoqvdPvLJD+yWvVXqpZA6CHRqkyzEju+t1AtnXDJ0EIO5u+Kc6dP+ygssFSPHg35d K/BaHa/Nb8Z8bR5v5qDn/idPIUjwypSh5hBV --B_3588143725_833612516-- From nobody Wed Sep 13 07:53:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4FC132949 for ; Wed, 13 Sep 2017 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIwjsgU2XrN5 for ; Wed, 13 Sep 2017 07:53:50 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28B6132DFB for ; Wed, 13 Sep 2017 07:53:50 -0700 (PDT) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 0E1D35A8 for ; Wed, 13 Sep 2017 15:53:48 +0100 (BST) Received: by mail-it0-f41.google.com with SMTP id 6so2977275itl.1 for ; Wed, 13 Sep 2017 07:53:48 -0700 (PDT) X-Gm-Message-State: AHPjjUjgNPnKbE+sl2/4wOgokl6llXnKFabCERGMrk9IStPoc62n6+q2 oQVzeMsD3XARdpYd2Zfy8DGtE/Al9N2tgESEiiI= X-Google-Smtp-Source: AOwi7QCxiBKQHi5SFlWPsKSVyIbQB1Wo2qESG+ynukiZVrkclIKvam6gPB/lidNZTvZofnyUOlztK30G7mHld22QhhM= X-Received: by 10.36.23.88 with SMTP id 85mr4462946ith.86.1505314427424; Wed, 13 Sep 2017 07:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 07:53:46 -0700 (PDT) From: Matt Caswell Date: Wed, 13 Sep 2017 15:53:46 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:53:52 -0000 I am looking at trying to implement the TLSv1.3 stateless cookie mechanism (in order to be able to support QUIC stateless retries). I am not clear how cookies are supposed to interact with early_data. Consider the scenario where a server is operating statelessly. Because there is no state each ClientHello looks like the first one it ever saw. The server only knows that a particular ClientHello is actually a ClientHello2 following an HRR because of the state held in the cookie. What happens when a client attempts to send early data to such a server? The server will process the ClientHello and determine that there is no cookie, sends back an HRR and then forgets all of its state and waits for the next ClientHello. However what it actually gets next is early_data. It does not know that that early data followed an earlier ClientHello (because it is stateless) so it does not know to skip the records. It just looks like illegal records so, presumably, it will respond with an alert. Should a stateless server silently drop any records that it doesn't understand? I am also unclear what protects against cookies being replayed. If an attacker wishes to perform an amplification attack on a particular IP it awaits a legitimate ClientHello with a cookie coming from that IP and records it. It then replays that ClientHello with cookie to the server many times. The cookie looks valid to the server and it responds with its ServerHello, full Certificate chain etc back to the original IP. What have I missed here? Thanks Matt From nobody Wed Sep 13 08:09:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA9133055 for ; Wed, 13 Sep 2017 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glPDn20qs17s for ; Wed, 13 Sep 2017 08:09:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652861321C7 for ; Wed, 13 Sep 2017 08:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id C68945DE77; Wed, 13 Sep 2017 18:09:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id JLjRB3QCDJzI; Wed, 13 Sep 2017 18:09:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3831E21C; Wed, 13 Sep 2017 18:09:30 +0300 (EEST) Date: Wed, 13 Sep 2017 18:09:29 +0300 From: Ilari Liusvaara To: Matt Caswell Cc: "tls@ietf.org" Message-ID: <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:09:38 -0000 On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote: > I am looking at trying to implement the TLSv1.3 stateless cookie > mechanism (in order to be able to support QUIC stateless retries). > > I am not clear how cookies are supposed to interact with early_data. > Consider the scenario where a server is operating statelessly. Because > there is no state each ClientHello looks like the first one it ever > saw. The server only knows that a particular ClientHello is actually a > ClientHello2 following an HRR because of the state held in the cookie. Looking at the definitions of Cookie and EarlyData extensions, those two are mutually exclusive. That is, there can be three kinds of ClientHello messages: 1) Contains neither Cookie nor EarlyData. 2) Contains an EarlyData, but not Cookie. 3) Contains a Cookie, but not EarlyData. (This exclusivity arises because Cookie can only be present in a retry, but EarlyData is stripped out for retry). > What happens when a client attempts to send early data to such a > server? The server will process the ClientHello and determine that > there is no cookie, sends back an HRR and then forgets all of its > state and waits for the next ClientHello. However what it actually > gets next is early_data. It does not know that that early data > followed an earlier ClientHello (because it is stateless) so it does > not know to skip the records. It just looks like illegal records so, > presumably, it will respond with an alert. Yes, if one receives a ClientHello with both Cookie and EarlyData, one can reply with a fatal alert, because that is not supposed to happen. There is worse edge case with client key share tho: If a ClientHello that contains a Cookie does not contain suitable key share, that is an irrecoverable error, and the only thing server can do is to send a fatal alert (and hope the client somehow retries the connection setup). > Should a stateless server silently drop any records that it doesn't understand? No, records should not be dropped for non-transistent problems, as doing this causes difficult-to-debug timeouts (the client will retry, and the retry will be dropped again, repeat until client gives up). In stateless operation, errors are sent back only once, not retransmitted if lost. > I am also unclear what protects against cookies being replayed. If an > attacker wishes to perform an amplification attack on a particular IP > it awaits a legitimate ClientHello with a cookie coming from that IP > and records it. It then replays that ClientHello with cookie to the > server many times. The cookie looks valid to the server and it > responds with its ServerHello, full Certificate chain etc back to the > original IP. What have I missed here? The attacker is likely able to inject packets, but not capture packets (the usual "no BCP38 compliance" case). -Ilari From nobody Wed Sep 13 08:11:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98539132DFB for ; Wed, 13 Sep 2017 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjsGIaRj6QnN for ; Wed, 13 Sep 2017 08:11: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 87998132949 for ; Wed, 13 Sep 2017 08:11:37 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8DF2WOA016758; Wed, 13 Sep 2017 16:11:33 +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=vibaGZPvmGYKvRyrF9fGNDn5rLDqQFTIY5t0rmXnRcE=; b=SlkglG/lLLOuHEQFZ6bKX9DshAPXBwIw3j24o4O3sbAmvobzlbJjOrQ2nj8opTwqRTwm hgq3drEShb5zrcS6mwS4f8OzUcDEPGySK6B/3eM5fFB44nYf3fG+vU3lctRamNzbACDI cx+eH0JvGjd2Ozfe5W27RnVENhOIavFOvv9Mv35GldxfC8Spv9P0521EmKXnfiG0Kdo/ GeYm1TzBYXmDbxpaDgPAFu/8Q17ZNZ2sjH8m2rh9nwJs8Y73/tbrKTCGNrowvEE7fGAR pSS0SZNmmCIokmI+B2FvmQxnG834lTiIPzXMZv15HMs8B+3lzWOgWiCj8vm91jealFCB Xg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2cxfy7xj8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 16:11:33 +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 v8DFB06V019447; Wed, 13 Sep 2017 11:11:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqk89a7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 11:11:31 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 10:11:30 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 10:11:30 -0500 From: "Short, Todd" To: Matt Caswell CC: "tls@ietf.org" Thread-Topic: [TLS] TLSv1.3 Cookies Thread-Index: AQHTLKAh101Rz2qXXkCbj/g9m1ELb6KzP7YA Date: Wed, 13 Sep 2017 15:11:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.69] Content-Type: multipart/alternative; boundary="_000_C27E03E9195748E2B9BB9CFC1B0CA621akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130238 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130235 Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:11:39 -0000 --_000_C27E03E9195748E2B9BB9CFC1B0CA621akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One comment below. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 13, 2017, at 10:53 AM, Matt Caswell > wrote: I am looking at trying to implement the TLSv1.3 stateless cookie mechanism (in order to be able to support QUIC stateless retries). I am not clear how cookies are supposed to interact with early_data. Consider the scenario where a server is operating statelessly. Because there is no state each ClientHello looks like the first one it ever saw. The server only knows that a particular ClientHello is actually a ClientHello2 following an HRR because of the state held in the cookie. What happens when a client attempts to send early data to such a server? The server will process the ClientHello and determine that there is no cookie, sends back an HRR and then forgets all of its state and waits for the next ClientHello. However what it actually gets next is early_data. It does not know that that early data followed an earlier ClientHello (because it is stateless) so it does not know to skip the records. It just looks like illegal records so, presumably, it will respond with an alert. In this case, the client must have previously connected to the server, so i= t knows what parameters the server supports, and should only use those, pre= venting an HRR from being generated. If the client were to send a ClientHello with unsupported server parameters= and early data, I would consider this a client error, and an alert should = be generated. Should a stateless server silently drop any records that it doesn't underst= and? I am also unclear what protects against cookies being replayed. If an attacker wishes to perform an amplification attack on a particular IP it awaits a legitimate ClientHello with a cookie coming from that IP and records it. It then replays that ClientHello with cookie to the server many times. The cookie looks valid to the server and it responds with its ServerHello, full Certificate chain etc back to the original IP. What have I missed here? Thanks Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_C27E03E9195748E2B9BB9CFC1B0CA621akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: <614EB8E5C86DB047BAEA2F37CA5AB7CE@akamai.com> Content-Transfer-Encoding: quoted-printable One comment below.
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Sep 13, 2017, at 10:53 AM, Matt Caswell <frodo@baggins.org> wrote:

I am looking at trying to implement the TLSv1.3 stateless c= ookie
mechanism (in order to be able to support QUIC stateless retries).

I am not clear how cookies are supposed to interact with early_data.
Consider the scenario where a server is operating statelessly. Because
there is no state each ClientHello looks like the first one it ever
saw. The server only knows that a particular ClientHello is actually a
ClientHello2 following an HRR because of the state held in the cookie.

What happens when a client attempts to send early data to such a
server? The server will process the ClientHello and determine that
there is no cookie, sends back an HRR and then forgets all of its
state and waits for the next ClientHello. However what it actually
gets next is early_data. It does not know that that early data
followed an earlier ClientHello (because it is stateless) so it does
not know to skip the records. It just looks like illegal records so,
presumably, it will respond with an alert.

In this case, the client must have previously connected to the server,= so it knows what parameters the server supports, and should only use those= , preventing an HRR from being generated.

If the client were to send a ClientHello with unsupported server param= eters and early data, I would consider this a client error, and an alert sh= ould be generated.


Should a stateless server silently drop any records that it doesn't underst= and?

I am also unclear what protects against cookies being replayed. If an
attacker wishes to perform an amplification attack on a particular IP
it awaits a legitimate ClientHello with a cookie coming from that IP
and records it. It then replays that ClientHello with cookie to the
server many times. The cookie looks valid to the server and it
responds with its ServerHello, full Certificate chain etc back to the
original IP. What have I missed here?

Thanks

Matt

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

--_000_C27E03E9195748E2B9BB9CFC1B0CA621akamaicom_-- From nobody Wed Sep 13 08:13:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ABE133055 for ; Wed, 13 Sep 2017 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzx6iGU6e9DW for ; Wed, 13 Sep 2017 08:13:38 -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 D9C29132DFB for ; Wed, 13 Sep 2017 08:13:37 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id l74so3410077oih.1 for ; Wed, 13 Sep 2017 08:13: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 :cc; bh=dqBOdC6W0mVOESI3KqDztZcAXT0psFnhNCkA0B/N+8g=; b=BmiUTa0E0hj8RYSWnpq6gZ9lIPfcpkEqdjYDNnQ7sX85rZ6xJvKjv2djbtwo4LDSba H9qJ75wwjGSrcusRnA9HBG3rUX0+fd90507WvNMZbPtjhchXlYww6Y8K5/ltMj/gRCJf LOaH8HI3qqqqsbK9vNu2w6Sr8GUG6DXjiW3CHSkhwZC0r5hhxYg2HoHCvXhy7p9nBbu1 6h2NA3DKZUYjWakr/rrwsMJs+8bapqbJE7Qe9smAGApwWvGMDR/o6RfR321wWEVxwja7 goagGch5AFWWA8J2/lxZVwf1BksOhwJEmrLDXKuqq8xvD6kV6xvC6u1C8HTWa21nkpuG NFAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=dqBOdC6W0mVOESI3KqDztZcAXT0psFnhNCkA0B/N+8g=; b=btsitFJMxKk0NKyeJK8N1g4cnFHtOYllcBi3v31sdGlz3LALGJLcdNyo0br39TddxA qCCBB+BULak5lBzZPrlNZVxd43bKoUZcX+LbswQyFaKSfFF95478RPNpbsZISYWRf6Kd aCGGFhV/UEgitceFC7t8ZPJm3V9n55eTchpGSC3dNdIOP6ULyyjBDrXg6QHz6DoQSpfv LzDWSy3TusS2AXlVzVtcZD6VfwlVkZ/NMMCi2RfMYBDTQ2J0M0rsfiFGRiNUyZXQWYS5 heEiGUbFwTrXLTKmYkELd+7BUu6mUurAvWehIcDt7T4Sk3lFixrLqYxJglZzZJunY1NF qIcA== X-Gm-Message-State: AHPjjUiZa3mNzJyd4P+GeR7lipcIKAYl2gjsauBE/+Bh7R+3zkB4OMEf 0Z/CCDfwiT2Se8sJQJmj1SALdt8b8gKIQMimQC0v+UmA X-Google-Smtp-Source: AOwi7QCc2C7uWHzullSLwlP+xRMjaK4OUNPI7DB750gEGhjxLLGKvKbH+zgMCRQDtIqSoP1IHhbw92dTnwWE5BFA3lU= X-Received: by 10.202.117.215 with SMTP id q206mr4275032oic.36.1505315617174; Wed, 13 Sep 2017 08:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Wed, 13 Sep 2017 08:12:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 13 Sep 2017 08:12:56 -0700 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113e9a68a313770559139a6f" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:13:40 -0000 --001a113e9a68a313770559139a6f Content-Type: text/plain; charset="UTF-8" On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell wrote: > I am looking at trying to implement the TLSv1.3 stateless cookie > mechanism (in order to be able to support QUIC stateless retries). > > I am not clear how cookies are supposed to interact with early_data. > Consider the scenario where a server is operating statelessly. Because > there is no state each ClientHello looks like the first one it ever > saw. The server only knows that a particular ClientHello is actually a > ClientHello2 following an HRR because of the state held in the cookie. > > What happens when a client attempts to send early data to such a > server? The server will process the ClientHello and determine that > there is no cookie, sends back an HRR and then forgets all of its > state and waits for the next ClientHello. However what it actually > gets next is early_data. It does not know that that early data > followed an earlier ClientHello (because it is stateless) so it does > not know to skip the records. It just looks like illegal records so, > presumably, it will respond with an alert. > It seems like there are three cases here: 1. TLS over TCP -- you won't do this statelessly, and so you can know to dump early data. 2. DTLS -- you can be stateless, but you don't terminate connections on decrypt error, so you just discard the packets as you would any other bogus packet. 3. QUIC -- the data looks like an unknown connection (you have dumped the conn_id) so you silently discard. > I am also unclear what protects against cookies being replayed. If an > attacker wishes to perform an amplification attack on a particular IP > it awaits a legitimate ClientHello with a cookie coming from that IP > and records it. It then replays that ClientHello with cookie to the > server many times. The cookie looks valid to the server and it > responds with its ServerHello, full Certificate chain etc back to the > original IP. What have I missed here? > Yes. Cookies aren't generally intended to stop that kind of amplification, they're just designed to prevent blind attacks on IPs you're not on-path for. Note that QUIC has an additional defense here of requiring that that ClientInitial be a certain minimum size. Note that if you are on-path you can still get a lot of amplification even with TCP at the cost of sending SYN, ACK, ClientHello... -Ekr > Thanks > > Matt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113e9a68a313770559139a6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 13, 2017 at 7:53 AM, Matt Caswell <frodo@baggins.org> wrote:
I am looking at trying to implem= ent the TLSv1.3 stateless cookie
mechanism (in order to be able to support QUIC stateless retries).

I am not clear how cookies are supposed to interact with early_data.
Consider the scenario where a server is operating statelessly. Because
there is no state each ClientHello looks like the first one it ever
saw. The server only knows that a particular ClientHello is actually a
ClientHello2 following an HRR because of the state held in the cookie.

What happens when a client attempts to send early data to such a
server? The server will process the ClientHello and determine that
there is no cookie, sends back an HRR and then forgets all of its
state and waits for the next ClientHello. However what it actually
gets next is early_data. It does not know that that early data
followed an earlier ClientHello (because it is stateless) so it does
not know to skip the records. It just looks like illegal records so,
presumably, it will respond with an alert.

<= div>It seems like there are three cases here:

1. T= LS over TCP -- you won't do this statelessly, and so you can know to du= mp
early data.
2. DTLS -- you can be stateless, but you= don't terminate connections on decrypt
error, so you just di= scard the packets as you would any other bogus packet.
3. QUIC --= the data looks like an unknown connection (you have dumped the conn_id)
so you silently discard.

=C2=A0
I am also unclear what protects against cookies being replayed. If an
attacker wishes to perform an amplification attack on a particular IP
it awaits a legitimate ClientHello with a cookie coming from that IP
and records it. It then replays that ClientHello with cookie to the
server many times. The cookie looks valid to the server and it
responds with its ServerHello, full Certificate chain etc back to the
original IP. What have I missed here?

Y= es. Cookies aren't generally intended to stop that kind of amplificatio= n,
they're just designed to prevent blind attacks on IPs you&= #39;re not on-path
for. Note that QUIC has an additional defense = here of requiring that
that ClientInitial be a certain minimum si= ze. Note that if you are on-path
you can still get a lot of ampli= fication even with TCP at the cost of
sending SYN, ACK, ClientHel= lo...

-Ekr


Thanks

Matt

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

--001a113e9a68a313770559139a6f-- From nobody Wed Sep 13 08:24:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42BF132332 for ; Wed, 13 Sep 2017 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXFeNvdfgY_S for ; Wed, 13 Sep 2017 08:24:52 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [217.160.92.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078AD127517 for ; Wed, 13 Sep 2017 08:24:51 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 0FCD0DA7 for ; Wed, 13 Sep 2017 16:24:48 +0100 (BST) Received: by mail-io0-f178.google.com with SMTP id n69so2830369ioi.5 for ; Wed, 13 Sep 2017 08:24:48 -0700 (PDT) X-Gm-Message-State: AHPjjUiistshRN5qiiHLPYFV4maDTWyKkhIYhCJ+n6HfZFKl6ltA8qbl t8CXQX1YWGs1bvCXEsXT9+9g9EVuj68d4W/Popg= X-Google-Smtp-Source: AOwi7QCEmrBYPB7NL9DPfnHvJYGQgEdrZU0N94IRBOGbtYTEyln95fSAdBsnd7GU5Mh1Pg/oHZXT2/Z3b5fnlZ8aK/U= X-Received: by 10.107.29.149 with SMTP id d143mr26805588iod.201.1505316278154; Wed, 13 Sep 2017 08:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 08:24:37 -0700 (PDT) In-Reply-To: <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> References: <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> From: Matt Caswell Date: Wed, 13 Sep 2017 16:24:37 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:24:54 -0000 On 13 September 2017 at 16:09, Ilari Liusvaara wrote: > On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote: >> I am looking at trying to implement the TLSv1.3 stateless cookie >> mechanism (in order to be able to support QUIC stateless retries). >> >> I am not clear how cookies are supposed to interact with early_data. >> Consider the scenario where a server is operating statelessly. Because >> there is no state each ClientHello looks like the first one it ever >> saw. The server only knows that a particular ClientHello is actually a >> ClientHello2 following an HRR because of the state held in the cookie. > > Looking at the definitions of Cookie and EarlyData extensions, those > two are mutually exclusive. That is, there can be three kinds of > ClientHello messages: > > 1) Contains neither Cookie nor EarlyData. > 2) Contains an EarlyData, but not Cookie. > 3) Contains a Cookie, but not EarlyData. > > (This exclusivity arises because Cookie can only be present in a retry, > but EarlyData is stripped out for retry). > >> What happens when a client attempts to send early data to such a >> server? The server will process the ClientHello and determine that >> there is no cookie, sends back an HRR and then forgets all of its >> state and waits for the next ClientHello. However what it actually >> gets next is early_data. It does not know that that early data >> followed an earlier ClientHello (because it is stateless) so it does >> not know to skip the records. It just looks like illegal records so, >> presumably, it will respond with an alert. > > Yes, if one receives a ClientHello with both Cookie and EarlyData, one > can reply with a fatal alert, because that is not supposed to happen. That isn't quite the scenario I was talking about. Rather your case (2) above in a server which is operating statelessly, i.e. the client has attempted to send early_data but has not provided a valid cookie yet. The early_data when it arrives will look like bad packets, even though (from the client perspective) it was valid to send them. It kind of suggests that stateless operation is incompatible with early_data, i.e. a server should not advertise early_data support in its tickets if it is going to operate statelessly (because stateless operation implies an HRR which implies no early_data). There is still an edge case where a server's configuration has changed (i.e. it used to operate statefully but now operates statelessly) - in that case a client might have a valid ticket advertising early_data support which the server will choke on when it actually receives that early_data. > > There is worse edge case with client key share tho: If a ClientHello > that contains a Cookie does not contain suitable key share, that is an > irrecoverable error, and the only thing server can do is to send a > fatal alert (and hope the client somehow retries the connection setup). Well, yes - if it contains a cookie then there must have been an HRR - so this is a legitimate fatal error. Matt From nobody Wed Sep 13 08:32:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8D133055 for ; Wed, 13 Sep 2017 08:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIszt2DGUurH for ; Wed, 13 Sep 2017 08:32:28 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D945132949 for ; Wed, 13 Sep 2017 08:32:28 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id F0D3E5E4 for ; Wed, 13 Sep 2017 16:32:26 +0100 (BST) Received: by mail-io0-f173.google.com with SMTP id v36so2943927ioi.1 for ; Wed, 13 Sep 2017 08:32:26 -0700 (PDT) X-Gm-Message-State: AHPjjUjCakOccLRPSyJwbY4GFgtK1dSm+usHLFUvNc65ncyshbeoo6Zi o+lYktit7mJ68JToZ2sJb456sJGxeU1wgccl1IQ= X-Google-Smtp-Source: AOwi7QBDoFqRqmgwcZztpQxP8ca1xcPRHpYJpR2vZDUFdbxpiNeFXjeTt49smWPkcjChh4vlV/3i/d0SVL4tVovkbTo= X-Received: by 10.107.197.198 with SMTP id v189mr7183535iof.94.1505316745264; Wed, 13 Sep 2017 08:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 08:32:24 -0700 (PDT) In-Reply-To: References: From: Matt Caswell Date: Wed, 13 Sep 2017 16:32:24 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Short, Todd" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:32:30 -0000 On 13 September 2017 at 16:11, Short, Todd wrote: > One comment below. > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Sep 13, 2017, at 10:53 AM, Matt Caswell wrote: > > I am looking at trying to implement the TLSv1.3 stateless cookie > mechanism (in order to be able to support QUIC stateless retries). > > I am not clear how cookies are supposed to interact with early_data. > Consider the scenario where a server is operating statelessly. Because > there is no state each ClientHello looks like the first one it ever > saw. The server only knows that a particular ClientHello is actually a > ClientHello2 following an HRR because of the state held in the cookie. > > What happens when a client attempts to send early data to such a > server? The server will process the ClientHello and determine that > there is no cookie, sends back an HRR and then forgets all of its > state and waits for the next ClientHello. However what it actually > gets next is early_data. It does not know that that early data > followed an earlier ClientHello (because it is stateless) so it does > not know to skip the records. It just looks like illegal records so, > presumably, it will respond with an alert. > > > In this case, the client must have previously connected to the server, so it > knows what parameters the server supports, and should only use those, > preventing an HRR from being generated. Well, that's not the case with a cookie. The server may choose to request a cookie even though all the rest of the parameters are ok can't it? Also what is acceptable to the server may change over time. The ticket may now be invalid because the configuration has changed etc. A client may also not know what groups are acceptable to a server even though it has a ticket, e.g. in the first handshake client sends an X25519 key_share, server responds with an HRR requesting P-256 and then the handshake continues to completion. The server is not obligated to provide supported_groups in its EE message - and even if it did the client is not obligated to remember it. Therefore it is perfectly valid in the second handshake for the client to send an X25519 key_share again along with early_data. Matt From nobody Wed Sep 13 08:40:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902FF132D3F for ; Wed, 13 Sep 2017 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CbXF7mQ6mbK for ; Wed, 13 Sep 2017 08:40:13 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C689D127517 for ; Wed, 13 Sep 2017 08:40:12 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 1C7C0BA2 for ; Wed, 13 Sep 2017 16:40:10 +0100 (BST) Received: by mail-io0-f172.google.com with SMTP id g32so2980035ioj.2 for ; Wed, 13 Sep 2017 08:40:10 -0700 (PDT) X-Gm-Message-State: AHPjjUj9bYNzYNf5FjZ7HltnP8K++irabbNfswlxEFZplLItCyE5Z75f kyGVUNeHBtYkPgCfJl1RffhVHkhlfJry6NACjho= X-Google-Smtp-Source: AOwi7QCoB5YE2H+ltMr46xtteSvPglSbLz7RuTuJg9fOGDyznfDB2CqjIwhisPq3t+sygXFvvlseWH5+7KJW1R0/nPQ= X-Received: by 10.107.197.198 with SMTP id v189mr7224928iof.94.1505317209461; Wed, 13 Sep 2017 08:40:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 08:40:08 -0700 (PDT) In-Reply-To: References: From: Matt Caswell Date: Wed, 13 Sep 2017 16:40:08 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:40:14 -0000 On 13 September 2017 at 16:12, Eric Rescorla wrote: > On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell wrote: >> >> I am looking at trying to implement the TLSv1.3 stateless cookie >> mechanism (in order to be able to support QUIC stateless retries). >> >> I am not clear how cookies are supposed to interact with early_data. >> Consider the scenario where a server is operating statelessly. Because >> there is no state each ClientHello looks like the first one it ever >> saw. The server only knows that a particular ClientHello is actually a >> ClientHello2 following an HRR because of the state held in the cookie. >> >> What happens when a client attempts to send early data to such a >> server? The server will process the ClientHello and determine that >> there is no cookie, sends back an HRR and then forgets all of its >> state and waits for the next ClientHello. However what it actually >> gets next is early_data. It does not know that that early data >> followed an earlier ClientHello (because it is stateless) so it does >> not know to skip the records. It just looks like illegal records so, >> presumably, it will respond with an alert. > > > It seems like there are three cases here: > > 1. TLS over TCP -- you won't do this statelessly, and so you can know to > dump > early data. > 2. DTLS -- you can be stateless, but you don't terminate connections on > decrypt > error, so you just discard the packets as you would any other bogus packet. > 3. QUIC -- the data looks like an unknown connection (you have dumped the > conn_id) > so you silently discard. Right - well that's the case right now - I guess we don't know how this feature might be used for in the future? So in case (3) should this be documented somewhere - either in the TLSv1.3 spec or the QUIC spec? Perhaps the TLSv1.3 spec should just state that protocols using the cookie feature should specify how early_data is to be handled - and then leave it up to QUIC/DTLS to define the behaviour in each of their cases. > > >> >> I am also unclear what protects against cookies being replayed. If an >> attacker wishes to perform an amplification attack on a particular IP >> it awaits a legitimate ClientHello with a cookie coming from that IP >> and records it. It then replays that ClientHello with cookie to the >> server many times. The cookie looks valid to the server and it >> responds with its ServerHello, full Certificate chain etc back to the >> original IP. What have I missed here? > > > Yes. Cookies aren't generally intended to stop that kind of amplification, > they're just designed to prevent blind attacks on IPs you're not on-path > for. Note that QUIC has an additional defense here of requiring that > that ClientInitial be a certain minimum size. Note that if you are on-path > you can still get a lot of amplification even with TCP at the cost of > sending SYN, ACK, ClientHello... Ok - that makes sense. Perhaps this is worth a note somewhere (not sure where it would fit). Matt From nobody Wed Sep 13 08:57:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A715513304F for ; Wed, 13 Sep 2017 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyn7jxLp1wZP for ; Wed, 13 Sep 2017 08:57:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0F0132A89 for ; Wed, 13 Sep 2017 08:57:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3B8068807; Wed, 13 Sep 2017 15:57:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E3B8068807 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 859D377BF7; Wed, 13 Sep 2017 15:57:19 +0000 (UTC) From: Hubert Kario To: "Blumenthal, Uri - 0553 - MITLL" Cc: "tls@ietf.org" , "Andrei.Popov@microsoft.com" Date: Wed, 13 Sep 2017 17:57:17 +0200 Message-ID: <2444518.Frf4kAzPhz@pintsize.usersys.redhat.com> In-Reply-To: References: <20170908225948.GC31695@al> <11673774.J8OL2FLGDl@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2167594.lUJ2564bjr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 13 Sep 2017 15:57:20 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:57:23 -0000 --nextPart2167594.lUJ2564bjr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 13 September 2017 16:35:25 CEST Blumenthal, Uri - 0553 - MITL= L=20 wrote: > > > enforcing the default. The default being: > > > - Hash algorithm the same as specified in Signature Algorithm > > > - MGF1 hash is the same as above > > > - Salt length same as digest length above > > =20 > > No problem with that being recommendation, but I've seen people > > claiming > >=20 > > that some applications don't follow that salt length requirement, so I'd > > say it would cause unnecessary problems if it was set too strict >=20 > I=E2=80=99m sure some apps follow, and some don=E2=80=99t. I=E2=80=99m si= mply saying that it makes > sense for TLS to pick a sensible default (like the above) and stick with > it. Other apps may do what they think is best. hmm, thing is, that while certificates with subjectPublicKeyInfo of rsa-pss= =20 are still pink unicorns in production deployments, certificates with=20 signatureAlgorithm of rsa-pss are fairly common in Microsoft shops - it is = the=20 default signature method for MS AD for good few years now. I do not know what hashes, how consistent with MGF1 and what salts sizes do= MS=20 CAs select for those signatures. I'm quite sure that people will want to use those existing CA certificates = and=20 intermediate CA certificates on new servers that will be deploying TLS 1.3.= =2E. > As for above, in view of the following discussion I think it would be bet= ter > to replace =E2=80=9CSignature Algorithm=E2=80=9D above with > =E2=80=9CsubjectPublicKeyInfo.algorithm.parameters.hashAlgorithm=E2=80=9D= =2E I still think > that only the necessary minimum of parameters should be passed explicitly. And I would agree, if we didn't have PKCS#11 tokens. If you work on pure- software implementation it will be much easier to have EE that cannot have= =20 limitations specified in subjectPublicKeyInfo. But as soon as you have to w= ork=20 with any kind of hardware implementations of RSA, that assumption goes out = the=20 window. Because even if your HSM does do all combinations, different one ma= y=20 not. > > and there are clients that advertise only a subset of hashes: > > https://www.ssllabs.com/ssltest/viewClient.html? > > name=3DSafari&version=3D6&platform=3DiOS%206.0.1&key=3D33 > Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device > somewhere. ;-) my point is that if a client from a major technological company, largely=20 focused on security, can make such decisions, I don't see why other develop= ers=20 couldn't follow the same logic that makes them do what Apple did. > > > The cryptographic module would perform RSA-PSS *signature* with > > > whatever > > > hashes it can. It won=E2=80=99t bother with *validation*, so this= module=E2=80=99s > > > limitations shouldn=E2=80=99t matter. > > =20 > > but it can't perform that signature using hash > > *that the client didn't advertise* >=20 > You=E2=80=99re probably right. But for my benefit, could you please outli= ne the > scenario how this would/could be used? To make sure I completely understa= nd > the use case? The use case may be of a limited client that implements only one hash=20 algorithm and because it's low power, doesn't have a software fallback -=20 allowing SHA256 only, everywhere (both on TLS level and on certificate=20 signature level). That client can then, exactly as the standard prescribes, advertise support= =20 only for signature schemes that support sha256:=20 * rsa_pkcs1_sha256 * rsa_pss_sha256 * ecdsa_secp256r1_sha256 Server side can be limited by policy, to have just sha384 signing in rsa wi= th=20 big key sizes (e.g. because some part of the web site is considered 'Top=20 secret' and need to use keys more resistant to quantum computers) but also= =20 have P-256 ECDSA certificate for the public part of the web site as a=20 fallback. That server policy can be encoded in the subjectPublicKeyInfo. In such situation we want the server to sign Certificate Verify with the EC= DSA=20 key - ecdsa_secp256r1_sha256 - even if the client advertises preference for= =20 RSA and server wants to respect it. Situation with two RSA keys with different limitations is not much differen= t. We still want to pick a certificate that can be used to make a signature th= at=20 client claims it will be able to verify - rsa_pss_sha256. =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 --nextPart2167594.lUJ2564bjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZuVVdAAoJEJKo0bgB0vX1D9wQAJo7o9DhNbSWbjc1gWjDB6Ta pxA+KganLgSBfKJbxpMjcxEyxConUm5bHKcDGPIgij1mou23ZLZbvvvzHWjwidzm Qgi/+tyRvkpO9U7Y2onBZaAQl+NHlwxDKHc2QgMKwfBWMnlRb/OwdCQ2YcpHAO5n YoB2Xqhu+IREKBW+pXw/j72B4k7X/e0naN9AzDJv8KOTtm1/95Gpo2LtmBgF9UDB keBF7V5WXZf7+9TC4LJzWYN1ehkEKP3GqYA589hds0/OlgcUWisweUkkZeqO7wD6 t6PB21vCwBXmiHyymq24vop9ItEZ8/BZ6DAsNz6TGA15W2DhDViZZR16p5eUtZq8 CO1fQ0JpbL6ni8VBOwZx9s5zTNyNmptgI8h9Vv613Jhs9z0oPKqCGSegVmvGQ7UJ FPs4HpRbX25f3zPGVIaRCmDz9sj6dSJAzTrDHgDjUztGu298DY8O3SqlZb1Sd7W1 CZbUQTVPKq1M9Ko5Tyuyixm7gvHTagmM2PO4bfaxcjugKEeurxtfheKh8mKGgc4x Q/mKlCTgGZUBBrdGch/lghh7MgqKRwzx5iYu1qCBKPYiM/Z14yj5jSpGd+XblS9J HrG5g4ZxGwTQ4gYVx/ruO5oP4aWwAfaOJpkbWOjB8rP9J8VvGlay2FYDI8fpOTMc GFXnukV059/bYPell2j0 =wlCI -----END PGP SIGNATURE----- --nextPart2167594.lUJ2564bjr-- From nobody Wed Sep 13 08:59:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E89132949 for ; Wed, 13 Sep 2017 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1RFlwEx-HyI for ; Wed, 13 Sep 2017 08:59:05 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 E31A9132A89 for ; Wed, 13 Sep 2017 08:59:04 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id k101so3358530iod.0 for ; Wed, 13 Sep 2017 08:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wd4Q8Lp9oAz6FmY+qPCqTQ+WulXjMIEFWqtsMRQSgrY=; b=P5g5m4PTi5UwGp1KxCi4yFPDC+uAE9QjEtW0rhMds3eAJZUoC/vMSYUk/WlwoUphRo nSzCOj7m4NugXAQCkYE3SYR1yF4JhsXDi/VI55gYhFn73w5fzl4EkJHabjmvGL2Cedu2 QkncM43KK3zx+ZQNn15AJWrpN4DulLSPOPTXt+6vuETsIYQ5Mgn4ZI83mNH3RCrNrwHm ZPU49x5dET+3g6kLW5WAlPWVVDjsAlrOtcRFxDwe2o6o0PRoISwzvYcT1nV++Mlj0FVM F2ftNks+uUUQOT0BZKiUwP+s6Rv3OjssALWu67Kb62OKzdz562r4aCqvEA7VgpmLMr/j TnYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=wd4Q8Lp9oAz6FmY+qPCqTQ+WulXjMIEFWqtsMRQSgrY=; b=Am8royRCYJwJDl0WDNGB9iijbHbRVF1SbwinVEyntXM1BluKSMl8VjihYTIeChKUjm jYAfiWlYNceJ8Kr0IzBaw/P72Z38H7zw4fHjxFIO5twRZHMmzt4zfJX1IC/t4BYd6TSs cirjdnOoFxKdgOi3C4BtRRZX4yGHabENU8oUGtB95a2dDyUNkiWC+SBLh5smB90kzbqT 4GJxYvuJNg3S+Ubuc4CTMTDmGc9mGEKQgyh75Yvr92gthmQ+NK3/Qrz1vZZQGtA0PvRa uWmAWuQzhm3sSyiXC1SY1F4dyI3wy4K1W6RLGsDak0GhtSdaR4Ql0CrQKtmzs2rjPeuK LaYA== X-Gm-Message-State: AHPjjUisZrqS+Q/8bofpuPr5X81s5pzjG31Q8XppZMQCeZrBRsI5jotA Nw1dCMiOdmLcV4MeOLaQoxU27q8YIZDcQ9uC9vhblg== X-Google-Smtp-Source: AOwi7QAD5mimPF1Gpqt6dLwVb4Gc8idFvc08LNeH884pmqMygunVLefuhIvf+0vbUL+OwhxTbmJ6x4DEFPcPPbhHY2Y= X-Received: by 10.202.117.215 with SMTP id q206mr4414374oic.36.1505318344191; Wed, 13 Sep 2017 08:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.74.197 with HTTP; Wed, 13 Sep 2017 08:58:23 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 13 Sep 2017 08:58:23 -0700 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113e9a682e1c370559143d58" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:59:07 -0000 --001a113e9a682e1c370559143d58 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 13, 2017 at 8:40 AM, Matt Caswell wrote: > On 13 September 2017 at 16:12, Eric Rescorla wrote: > > On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell wrote: > >> > >> I am looking at trying to implement the TLSv1.3 stateless cookie > >> mechanism (in order to be able to support QUIC stateless retries). > >> > >> I am not clear how cookies are supposed to interact with early_data. > >> Consider the scenario where a server is operating statelessly. Because > >> there is no state each ClientHello looks like the first one it ever > >> saw. The server only knows that a particular ClientHello is actually a > >> ClientHello2 following an HRR because of the state held in the cookie. > >> > >> What happens when a client attempts to send early data to such a > >> server? The server will process the ClientHello and determine that > >> there is no cookie, sends back an HRR and then forgets all of its > >> state and waits for the next ClientHello. However what it actually > >> gets next is early_data. It does not know that that early data > >> followed an earlier ClientHello (because it is stateless) so it does > >> not know to skip the records. It just looks like illegal records so, > >> presumably, it will respond with an alert. > > > > > > It seems like there are three cases here: > > > > 1. TLS over TCP -- you won't do this statelessly, and so you can know to > > dump > > early data. > > 2. DTLS -- you can be stateless, but you don't terminate connections on > > decrypt > > error, so you just discard the packets as you would any other bogus > packet. > > 3. QUIC -- the data looks like an unknown connection (you have dumped the > > conn_id) > > so you silently discard. > > Right - well that's the case right now - I guess we don't know how > this feature might be used for in the future? > True... So in case (3) should this be documented somewhere - either in the > TLSv1.3 spec or the QUIC spec? I think it should go in the QUIC spec, because it's QUIC's responsibility to provide the transport abstraction to TLS. > Perhaps the TLSv1.3 spec should just > state that protocols using the cookie feature should specify how > early_data is to be handled - and then leave it up to QUIC/DTLS to > define the behaviour in each of their cases. > Generally, I'd prefer to keep this in the other specs, because these are issues that arise principally when TLS is embedded in other specs.... If someone has a PR, I can take a look, though. >> I am also unclear what protects against cookies being replayed. If an > >> attacker wishes to perform an amplification attack on a particular IP > >> it awaits a legitimate ClientHello with a cookie coming from that IP > >> and records it. It then replays that ClientHello with cookie to the > >> server many times. The cookie looks valid to the server and it > >> responds with its ServerHello, full Certificate chain etc back to the > >> original IP. What have I missed here? > > > > > > Yes. Cookies aren't generally intended to stop that kind of > amplification, > > they're just designed to prevent blind attacks on IPs you're not on-path > > for. Note that QUIC has an additional defense here of requiring that > > that ClientInitial be a certain minimum size. Note that if you are > on-path > > you can still get a lot of amplification even with TCP at the cost of > > sending SYN, ACK, ClientHello... > > Ok - that makes sense. Perhaps this is worth a note somewhere (not > sure where it would fit). > I filed: https://github.com/tlswg/tls13-spec/issues/1079 > > Matt > --001a113e9a682e1c370559143d58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 13, 2017 at 8:40 AM, Matt Caswell <frodo@baggins.org&g= t; wrote:
On 13 September 2017 at 16:1= 2, Eric Rescorla <ekr@rtfm.com> w= rote:
> On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <frodo@baggins.org> wrote:
>>
>> I am looking at trying to implement the TLSv1.3 stateless cookie >> mechanism (in order to be able to support QUIC stateless retries).=
>>
>> I am not clear how cookies are supposed to interact with early_dat= a.
>> Consider the scenario where a server is operating statelessly. Bec= ause
>> there is no state each ClientHello looks like the first one it eve= r
>> saw. The server only knows that a particular ClientHello is actual= ly a
>> ClientHello2 following an HRR because of the state held in the coo= kie.
>>
>> What happens when a client attempts to send early data to such a >> server? The server will process the ClientHello and determine that=
>> there is no cookie, sends back an HRR and then forgets all of its<= br> >> state and waits for the next ClientHello. However what it actually=
>> gets next is early_data. It does not know that that early data
>> followed an earlier ClientHello (because it is stateless) so it do= es
>> not know to skip the records. It just looks like illegal records s= o,
>> presumably, it will respond with an alert.
>
>
> It seems like there are three cases here:
>
> 1. TLS over TCP -- you won't do this statelessly, and so you can k= now to
> dump
> early data.
> 2. DTLS -- you can be stateless, but you don't terminate connectio= ns on
> decrypt
> error, so you just discard the packets as you would any other bogus pa= cket.
> 3. QUIC -- the data looks like an unknown connection (you have dumped = the
> conn_id)
> so you silently discard.

Right - well that's the case right now - I guess we don'= ;t know how
this feature might be used for in the future?

True...=C2=A0


So in case (3) should this be documented somewhere - either in the
TLSv1.3 spec or the QUIC spec?

I think it s= hould go in the QUIC spec, because it's QUIC's responsibility to pr= ovide
the transport abstraction to TLS.

<= div>
=C2=A0
Perhaps the TLSv1.3 spec should just
state that protocols using the cookie feature should specify how
early_data is to be handled - and then leave it up to QUIC/DTLS to
define the behaviour in each of their cases.

Generally, I'd prefer to keep this in the other specs, because th= ese are issues
that arise principally when TLS is embedded in= other specs.... If someone has
a PR, I can take a look, though.<= /div>


>> I am also unclear what protects = against cookies being replayed. If an
>> attacker wishes to perform an amplification attack on a particular= IP
>> it awaits a legitimate ClientHello with a cookie coming from that = IP
>> and records it. It then replays that ClientHello with cookie to th= e
>> server many times. The cookie looks valid to the server and it
>> responds with its ServerHello, full Certificate chain etc back to = the
>> original IP. What have I missed here?
>
>
> Yes. Cookies aren't generally intended to stop that kind of amplif= ication,
> they're just designed to prevent blind attacks on IPs you're n= ot on-path
> for. Note that QUIC has an additional defense here of requiring that > that ClientInitial be a certain minimum size. Note that if you are on-= path
> you can still get a lot of amplification even with TCP at the cost of<= br> > sending SYN, ACK, ClientHello...

Ok - that makes sense. Perhaps this is worth a note somewhere (not sure where it would fit).


--001a113e9a682e1c370559143d58-- From nobody Wed Sep 13 09:08:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414E133064 for ; Wed, 13 Sep 2017 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OzeuB1t4FoYW for ; Wed, 13 Sep 2017 09:08:51 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293CC132C32 for ; Wed, 13 Sep 2017 09:08:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7BE60B5261; Wed, 13 Sep 2017 19:08:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id cZo21ThUlxbD; Wed, 13 Sep 2017 19:08:48 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E50FC2313; Wed, 13 Sep 2017 19:08:45 +0300 (EEST) Date: Wed, 13 Sep 2017 19:08:45 +0300 From: Ilari Liusvaara To: Matt Caswell Cc: "tls@ietf.org" Message-ID: <20170913160845.khjf5odas3ns5u5z@LK-Perkele-VII> References: <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:08:53 -0000 On Wed, Sep 13, 2017 at 04:24:37PM +0100, Matt Caswell wrote: > On 13 September 2017 at 16:09, Ilari Liusvaara wrote: > > On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote: > >> I am looking at trying to implement the TLSv1.3 stateless cookie > >> mechanism (in order to be able to support QUIC stateless retries). > >> > >> I am not clear how cookies are supposed to interact with early_data. > >> Consider the scenario where a server is operating statelessly. Because > >> there is no state each ClientHello looks like the first one it ever > >> saw. The server only knows that a particular ClientHello is actually a > >> ClientHello2 following an HRR because of the state held in the cookie. > > > > Looking at the definitions of Cookie and EarlyData extensions, those > > two are mutually exclusive. That is, there can be three kinds of > > ClientHello messages: > > > > 1) Contains neither Cookie nor EarlyData. > > 2) Contains an EarlyData, but not Cookie. > > 3) Contains a Cookie, but not EarlyData. > > > > (This exclusivity arises because Cookie can only be present in a retry, > > but EarlyData is stripped out for retry). > > > >> What happens when a client attempts to send early data to such a > >> server? The server will process the ClientHello and determine that > >> there is no cookie, sends back an HRR and then forgets all of its > >> state and waits for the next ClientHello. However what it actually > >> gets next is early_data. It does not know that that early data > >> followed an earlier ClientHello (because it is stateless) so it does > >> not know to skip the records. It just looks like illegal records so, > >> presumably, it will respond with an alert. > > > > Yes, if one receives a ClientHello with both Cookie and EarlyData, one > > can reply with a fatal alert, because that is not supposed to happen. > > That isn't quite the scenario I was talking about. Rather your case > (2) above in a server which is operating statelessly, i.e. the client > has attempted to send early_data but has not provided a valid cookie > yet. The early_data when it arrives will look like bad packets, even > though (from the client perspective) it was valid to send them. If you really got some transport that uses TLS on something where stateless operation makes sense (so not TCP) that transports the 0-RTT TLS data in-band (so not QUIC), just throw any initial records starting with 0x17 into trash. AFAIK, QUIC does not use TLS 0-RTT data, it uses 0-RTT exporters to derive encryption keys for data, that is sent outside TLS. So in that case, TLS would see two consequtive ClientHello messages if the first gets rejected. -Ilari From nobody Wed Sep 13 09:19:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9391321AC for ; Wed, 13 Sep 2017 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4LQoLbLJysW for ; Wed, 13 Sep 2017 09:19:51 -0700 (PDT) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D361252BA for ; Wed, 13 Sep 2017 09:19:51 -0700 (PDT) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id B84CC1AC for ; Wed, 13 Sep 2017 17:19:49 +0100 (BST) Received: by mail-it0-f53.google.com with SMTP id 6so3741299itl.1 for ; Wed, 13 Sep 2017 09:19:49 -0700 (PDT) X-Gm-Message-State: AHPjjUhi1vnPx14qUZDceFLK8Ovcu/2+tIYvyVqPsugJvkChCQzqoGYa VmdN/kiblBl9jkslxaxtcPTITuf8FUdWlj1YZ2E= X-Google-Smtp-Source: AOwi7QDr/VCNSdNY8Ri0NOpoYQ86p096kixJYhaVYmPbUtDrT2l+EsO0Tkf3z7yXcuf3FS1tqDlZBZVvlXhFGwZKKhw= X-Received: by 10.36.61.15 with SMTP id n15mr4993926itn.117.1505319586919; Wed, 13 Sep 2017 09:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.165.25 with HTTP; Wed, 13 Sep 2017 09:19:45 -0700 (PDT) In-Reply-To: <20170913160845.khjf5odas3ns5u5z@LK-Perkele-VII> References: <20170913150929.nupe6fq5rqtroflp@LK-Perkele-VII> <20170913160845.khjf5odas3ns5u5z@LK-Perkele-VII> From: Matt Caswell Date: Wed, 13 Sep 2017 17:19:45 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLSv1.3 Cookies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:19:54 -0000 On 13 September 2017 at 17:08, Ilari Liusvaara wrote: >> > Yes, if one receives a ClientHello with both Cookie and EarlyData, one >> > can reply with a fatal alert, because that is not supposed to happen. >> >> That isn't quite the scenario I was talking about. Rather your case >> (2) above in a server which is operating statelessly, i.e. the client >> has attempted to send early_data but has not provided a valid cookie >> yet. The early_data when it arrives will look like bad packets, even >> though (from the client perspective) it was valid to send them. > > If you really got some transport that uses TLS on something where > stateless operation makes sense (so not TCP) that transports the 0-RTT > TLS data in-band (so not QUIC), just throw any initial records starting > with 0x17 into trash. > > AFAIK, QUIC does not use TLS 0-RTT data, it uses 0-RTT exporters to > derive encryption keys for data, that is sent outside TLS. So in > that case, TLS would see two consequtive ClientHello messages if the > first gets rejected. Ah! Right - yes that is a good point. I was looking at this from the perspective of the need to support QUIC. I had missed that subtlety - thanks. There is still a theoretical issue if something other than TLS/TCP or TLS/QUIC wants to do this. But given there is no actual known use case for that then I guess we can cross that bridge when we come to it. Matt From nobody Wed Sep 13 14:57:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA5913219F for ; Wed, 13 Sep 2017 14:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 uge6NKzO1uIz for ; Wed, 13 Sep 2017 14:57:27 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 D4803126DD9 for ; Wed, 13 Sep 2017 14:57:23 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id a43so3089858wrc.0 for ; Wed, 13 Sep 2017 14:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RJ7cEdX3R+X4n38Ks6aeE0p1Yi+RNqvwFJUqsZGYx58=; b=gPzPb1h0tVRaqwMRAj1XpPgNLANLpp8U60PiXkxa5HAuoePOtulfLGBKlBWUNVUgd3 ikjG+YPz+89IG7XR0pO/tZan7Df+oWTfkUd5Xae7dO44S2oXOEBm/iqTBULYpRVEiSoF tWSHuh7y7AaA/epNANe06rVNCejCGdR9qqqQ/jIrsOyY1pG8JG3RmpuWylIbGu9xVgUi QESIc4/hl3U8RDV4e9PL0VOGM0gcg78r9D9zgq0EhH8EMkCQ3GrVIx6Nbao6a/otfAnd UfdKAIacgSlbSeLvFGXJ8FP0n2gfzdRkh5p8An+L6zenwHvv1LcOPCktDVXGY7F7nH4X O2Ug== 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=RJ7cEdX3R+X4n38Ks6aeE0p1Yi+RNqvwFJUqsZGYx58=; b=a/vkh9+nhVWchT4oKoIzqXGvvwCWXJk/Kicx8On1P1ewzJGW97P7h6P/onXfZ8PiKF /EGpg7j6PHv82pbTYJ6jKYVHm3J6VnpnIVOlt7u4G1Id/TeakNGiF9ixINVLM/+FkrHs Ddl20O6yG0YXuRBNHxmWmZpWfhmmJLGulZk5EHpVrhh5a4EbPiek3qu7RY1MpnwDE7g7 NIpFosNzikuSY82fnOJyPq0Kexty/W+qPbLxwdIRCnjSIW0KixgP2s52GE+AyGM5Gv90 m3SgxZ51rilWp+34MXvJbnDpLgGTcJpqHAtInT1knnkfkVlUiPLB7pef4U9fzAjefZ0U PkwQ== X-Gm-Message-State: AHPjjUiqfBhc2/C/bGE9WHpdMNQ0NKnshwzrrLEEG8hTiZ4pnljNIgnP WOP0gv3H/6ttrribgoJtioHV1yhcnanjSdBtEfeznSxBWTo= X-Google-Smtp-Source: AOwi7QCjAsRRohRKU41Ufe62ej3/OrPseAOSknk1y91OfGMfpekQ/MEYfz5cJ1yKuxw2T1xJ7ooigqRtLnuhB6OpjQM= X-Received: by 10.223.139.27 with SMTP id n27mr7516295wra.250.1505339841847; Wed, 13 Sep 2017 14:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.144.236 with HTTP; Wed, 13 Sep 2017 14:57:21 -0700 (PDT) From: Victor Vasiliev Date: Wed, 13 Sep 2017 17:57:21 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e9d5c8ad3d80559193e5e" Archived-At: Subject: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 21:57:29 -0000 --f403045e9d5c8ad3d80559193e5e Content-Type: text/plain; charset="UTF-8" Currently, TLS 1.3 specification forbids resuming the session if SNI values do not match. This is inefficient in multiple cases, for example, if you have a wildcard domain cert, and the user is likely to visit multiple subdomains over a longer timespan, so there is no existing connection to pool on (or it's impossible to pool because of different IP addresses). Last time we discussed this, https://www.ietf.org/mail-archive/web/tls/current/msg21655.html no one has pointed out a good security reason why this should be forbidden. Also, the requirement as stated requires the server to enforce it, while in reality, most implementations I am familiar with offload the burden to the clients. I wrote the following PR to remove the requirement: https://github.com/tlswg/tls13-spec/pull/1080 The PR still discourages clients to resume across domains by default (due to likelihood of wasting a ticket which could have came in handy later), so I'm currently writing a draft for an extension to inform clients that it's okay to do that (it will be in spirit of PR #777 ). -- Victor. --f403045e9d5c8ad3d80559193e5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently, TLS 1.3 specification forbids resuming the sess= ion if SNI values do not match.=C2=A0 This is inefficient in multiple cases= , for example, if you have a wildcard domain cert, and the user is likely t= o visit multiple subdomains over a longer timespan, so there is no existing= connection to pool on (or it's impossible to pool because of different= IP addresses).

Last time we discussed this,
no one has pointed out a good security reason why this shou= ld be forbidden.=C2=A0 Also, the requirement as stated requires the server = to enforce it, while in reality, most implementations I am familiar with of= fload the burden to the clients.

I wrote the follo= wing PR to remove the requirement:
The PR still discourages clients to resume across = domains by default (due to likelihood of wasting a ticket which could have = came in handy later), so I'm currently writing a draft for an extension= to inform clients that it's okay to do that (it will be in spirit of <= a href=3D"https://github.com/tlswg/tls13-spec/pull/777">PR #777).
=

=C2=A0 -- Victor.
--f403045e9d5c8ad3d80559193e5e-- From nobody Thu Sep 14 15:10:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BE01321A7 for ; Thu, 14 Sep 2017 15:10: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, 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=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 PhKW9oQIvJhi for ; Thu, 14 Sep 2017 15:10:30 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F22132026 for ; Thu, 14 Sep 2017 15:10:30 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id u96so479442wrb.6 for ; Thu, 14 Sep 2017 15:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5kjK566S0RCtnR5j+OLR7DcyKLw4+cOlvqyJ2se4dGo=; b=Fyn0tXF2BZGLnYRwUL0R+RS3IVrJDQY3gzpjVkKPCt9As3XiFNywKJC4vZbRXWxtNY sQ2MTfvgZBetf0+3iFbvOyDdsLh2v0TN8O7XXsFWa1ScehPL7JXygr6uIxfa6yiScHhS i7Rcn2fGXFclXZ1KgO3PUHytAoqj4Dyb+WDUtgvAn+T3FW0x4w0ya+6vuw5l8GKRb8cz xAO8Xd3+j/r5SStGpM2nEXsVxT6v7ikKNQbDinsvr12qgxYLfGYBFsIo2wsdwtxW4f8I ZM5qcfMAjbgOwYMLVCoz78ifqpJnnEtuSpSR0aqNPAVi26cxkmWxxnOaOeV06u3ArDBN Bsow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=5kjK566S0RCtnR5j+OLR7DcyKLw4+cOlvqyJ2se4dGo=; b=mzWF/Kv0Ksb/34mWfMIeeseKhOgQ1AQzJDH6mnqz8WL9XZL0/r20J86nYHB3SPpxZA hkSZqaQVY8/UNDs6b7F51D1l/eIqjx2KoyvhgHjQrgJM9D1WWrJY2yjOJxX7C6aOvAVa ein2gJEC1O+H7kUvLide9pemj2/eYNg8WDKjM2PkUQyt53rS+u9J3Dj/H51OkK2l6Dty quVNs3y5jR/+Y73vLjvoeSOEorHP199qfi6aGnWIE8BRdXB7xC+58P7pRYWz5Oim8Zzh rbn80WBhPorDV+7lFM9F0xstIawBfqhfFIVCyayVJ0IeTm/4qfbjsFv3TdYczHzK6soV 8LtQ== X-Gm-Message-State: AHPjjUidFSbM1kGDPNDFQnlvN3vmF5A/xUoaNrfHyjOpRzioI1UcN+0P DpBl+X13jVUh9lwVYu8144hhrIa6FoofhCFmGRY32+oT X-Google-Smtp-Source: ADKCNb6Im4H1T+glZpmpTGUiTH2CuGGyFMsLiB6HFJOLx1cWuIAd6APFqRJPmYZl4ATVOKL/FEfJ+rTFg2bnRtLSet4= X-Received: by 10.223.136.170 with SMTP id f39mr19286381wrf.164.1505427028377; Thu, 14 Sep 2017 15:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.193 with HTTP; Thu, 14 Sep 2017 15:10:27 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 14 Sep 2017 15:10:27 -0700 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11460aac43642e05592d8b0e" Archived-At: Subject: Re: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 22:10:33 -0000 --001a11460aac43642e05592d8b0e Content-Type: text/plain; charset="UTF-8" We something like this today with QUIC's custom crypto handshake and it has proven to be extremely useful. I can't wait to do this with TLS! On Wed, Sep 13, 2017 at 2:57 PM, Victor Vasiliev wrote: > Currently, TLS 1.3 specification forbids resuming the session if SNI > values do not match. This is inefficient in multiple cases, for example, > if you have a wildcard domain cert, and the user is likely to visit > multiple subdomains over a longer timespan, so there is no existing > connection to pool on (or it's impossible to pool because of different IP > addresses). > > Last time we discussed this, > https://www.ietf.org/mail-archive/web/tls/current/msg21655.html > no one has pointed out a good security reason why this should be > forbidden. Also, the requirement as stated requires the server to enforce > it, while in reality, most implementations I am familiar with offload the > burden to the clients. > > I wrote the following PR to remove the requirement: > https://github.com/tlswg/tls13-spec/pull/1080 > The PR still discourages clients to resume across domains by default (due > to likelihood of wasting a ticket which could have came in handy later), so > I'm currently writing a draft for an extension to inform clients that it's > okay to do that (it will be in spirit of PR #777 > ). > > -- Victor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11460aac43642e05592d8b0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We something like this today with QUIC's custom crypto= handshake and it has proven to be extremely useful. I can't wait to do= this with TLS!

On Wed, Sep 13, 2017 at 2:57 PM, Victor Vasiliev <vasilvv@googl= e.com> wrote:
Currently, TLS 1.3 specification forbids resuming the session if SNI va= lues do not match.=C2=A0 This is inefficient in multiple cases, for example= , if you have a wildcard domain cert, and the user is likely to visit multi= ple subdomains over a longer timespan, so there is no existing connection t= o pool on (or it's impossible to pool because of different IP addresses= ).

Last time we discussed this,
=C2=A0=C2=A0https://www.ietf.org/mail-archive/web/tls/current/msg21655.html
no one has pointed out a good security reason= why this should be forbidden.=C2=A0 Also, the requirement as stated requir= es the server to enforce it, while in reality, most implementations I am fa= miliar with offload the burden to the clients.

I w= rote the following PR to remove the requirement:
The PR still = discourages clients to resume across domains by default (due to likelihood = of wasting a ticket which could have came in handy later), so I'm curre= ntly writing a draft for an extension to inform clients that it's okay = to do that (it will be in spirit of PR #777).

=C2=A0 -- Victor.

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


--001a11460aac43642e05592d8b0e-- From nobody Thu Sep 14 15:42:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE01321B6 for ; Thu, 14 Sep 2017 15:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1l3CZHjGBxhT for ; Thu, 14 Sep 2017 15:42:34 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4591286C7 for ; Thu, 14 Sep 2017 15:42:34 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l15so4252744iol.8 for ; Thu, 14 Sep 2017 15:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1fh2CKh/4N2cQ5ImJ/nM5DmiYDacy7XY5BnjvWPARoM=; b=ra7VAQOQJuhaXumv6Z0/l0+RguW+eG/jhxBBYrYIIyj1gktJeqYFAs0oGQL4rhOjgb knjnv5A7uO4JS/DLUQqDf69agGqqp4ZNY6+lW+oqIYPJxRXeldB2EQQaL3QCzdDgXLf/ 4l3r1PVsgUBnugZb8qpNyhayVKkvouOTpEU+7QcHLh9abEyVUWaVJSgaMSBDtFmJD4G4 soRfxCQPHZXCepz57l2KmNDeyy9HdnT2TzFAusEDL5X0WoVeWWj8SGKzd9QU3ZI9NRA3 i+OT4KSLw7q5h1pAb3Czj6flYdMRebBZRDwent21gd6RTCJaQfNrS5D/IaynRQvOyJE2 HQMA== 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=1fh2CKh/4N2cQ5ImJ/nM5DmiYDacy7XY5BnjvWPARoM=; b=goTb6Jqz6+Mm2LykMVUxVW7IfQTojc7P0l6/Ed3gF1zMxy8uMBF+pnXd5bEXKN07gu lTHAdXCABPAChCxZHC4HSSMPgVPl46h4xeRJmCVmA8ZxgzFx+galNoh2gx1rAi9pO9yj hPr30FB+PwSsVVC3JaOS1tB4uePQZVKj8QMJm36Pzc+8/+LJwfmcZ2yr0YTaPRGnECqc rRGbAjHx96rtKzuC2VMsuDTTmI5twFclmh/BJSJvp/VwTUP+7Js29wdxG3cfBbx/B+Ah YjjNsbUEouzLo03IDvfLS3byOVBclfP+JkadMzhKNaHt65UxZ7+VW3/wj/kTbI6uwdMN Fxcw== X-Gm-Message-State: AHPjjUhjPC5hRiGaPi4rGZorSQeoZzwWZZTUSKwju1tfF43T7nh2RDJN tJ615rCqS7qSXe49et8dTH562oHcTltPiVGsuGg= X-Google-Smtp-Source: AOwi7QDyzJb4r8K0Xu0TvQxy+YrqK5j/Mv39S+2pSNCHIR8W435SV1MFgEtmb7aoMIJCy1C+ACm0MFLoSN3MgpeiLeg= X-Received: by 10.202.206.71 with SMTP id e68mr22602497oig.101.1505428954237; Thu, 14 Sep 2017 15:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.19.199 with HTTP; Thu, 14 Sep 2017 15:42:33 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: From: Jeffrey Walton Date: Thu, 14 Sep 2017 18:42:33 -0400 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 22:42:37 -0000 On Wed, Sep 13, 2017 at 5:57 PM, Victor Vasiliev wrote: > Currently, TLS 1.3 specification forbids resuming the session if SNI values > do not match. This is inefficient in multiple cases, for example, if you > have a wildcard domain cert, and the user is likely to visit multiple > subdomains over a longer timespan, so there is no existing connection to > pool on (or it's impossible to pool because of different IP addresses). > > Last time we discussed this, > https://www.ietf.org/mail-archive/web/tls/current/msg21655.html > no one has pointed out a good security reason why this should be forbidden. The current models uses origins as a boundary, so they are different security contexts. A related twist is, the boundary is established at layer 7, but layer 3/4 has no knowledge of it. The DBOUND working group was not able to produce a deliverable. There is no general purpose way to establish those boundaries. To play devil's advocate, will the TLS stack need to keep a copy of the certificate or authorized origins (an origin group?) for future connections? Jeff From nobody Thu Sep 14 16:04:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DED1321EB for ; Thu, 14 Sep 2017 16:04:12 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 raN5H2AmKFRK for ; Thu, 14 Sep 2017 16:04:08 -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 ADC381321B6 for ; Thu, 14 Sep 2017 16:04:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q11so4343790ioe.10 for ; Thu, 14 Sep 2017 16:04: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=8QCzQXFLeVu6TI+dRpo9YBij4lgvPMU+3p4BBIrvAyM=; b=YIAAQLBj9iYY6iwFHYRTZcBttEWKnTBxjfnFD103OJPsUuICn87PfllxILYbuD1312 RiEhvwT1KtCY0ew5oACDhYUuF+P0P3AjWckGZu8GUe0VuDs3FfSSM0SIESFfm6aIQN+4 aZ/0SuyR97HMmJuZNqwYmNMgVvNTg2Y8krePM= 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=8QCzQXFLeVu6TI+dRpo9YBij4lgvPMU+3p4BBIrvAyM=; b=sdQoWk4lpADJMJ9SqCqUhLpR2QcgsNtmcQdoYt1eD2XMEsNIMfoQ7VxF/Eg+ZbeK8R 3/THryuUyboC9kO30jTqYfUuKLaWK8UpdnBnkVwIAcFVGir7dTMmgECq+Fskr5FrkJ12 NU2/5TcXbta9NXc85ETJljmgejrCcn4Uk4HkRWuWdhPQ8G6oFyvC4m0zzjNfkvZfjI6t kg3RMRkzCXZB4AdqjC2CJOVo+81pnEr14KHqILnGKkmaN8khpVsTVsEHyX8LOPEJy5qZ ijj+ayXDq/dLVrFU59huAXp1dWqaKHaViGixwj+AAfX2SLxmj8Ux7ErXBgiszJMK4Yti c4oQ== X-Gm-Message-State: AHPjjUgOL5rlOwz/RlQKNyVbu2FR9+Vw6hA1oo1q9h4NBjWK1/Ai04HK 8Cju+WA7IzfKLG1OFxT0Vaxm+UOb1wM1KxCaUyjU X-Google-Smtp-Source: AOwi7QCdi9CtlgAQfbhNIFxVz5VOyW5Ry2VKBEGbpSJqBpZGvAtxjoWsT8aWDeWiC3uwmZ0nt7GPJ8B+E4fKKjvldRI= X-Received: by 10.107.162.145 with SMTP id l139mr655271ioe.193.1505430247820; Thu, 14 Sep 2017 16:04:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 14 Sep 2017 23:03:57 +0000 Message-ID: To: noloader@gmail.com, Victor Vasiliev Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1140feaa287c3b05592e4b3f" Archived-At: Subject: Re: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 23:04:12 -0000 --001a1140feaa287c3b05592e4b3f Content-Type: text/plain; charset="UTF-8" On Thu, Sep 14, 2017 at 6:42 PM Jeffrey Walton wrote: > To play devil's advocate, will the TLS stack need to keep a copy of > the certificate or authorized origins (an origin group?) for future > connections? Implementations that don't retain enough information for it can always just not offer sessions across domains. What resumption patterns to support and what state to retain to support those is an implementation decision. But stacks I've seen already retain this anyway. It's common to have APIs that retrieve the peer certificate and for resumption to be more-or-less transparent. That combination implies sessions must retain the peer certificate to resurface when asked. David --001a1140feaa287c3b05592e4b3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 14= , 2017 at 6:42 PM Jeffrey Walton <noloader@gmail.com> wrote:
To play devil's advocate, will the TLS stack need to k= eep a copy of
the certificate or authorized origins (an origin group?) for future
connections?

Implementations that don't retain enough informat= ion for it can always just not offer sessions across domains. What resumpti= on patterns to support and what state to retain to support those is an impl= ementation decision.

But stacks I've seen alre= ady retain this anyway. It's common to have APIs that retrieve the peer= certificate and for resumption to be more-or-less transparent. That combin= ation implies sessions must retain the peer certificate to resurface when a= sked.
David
--001a1140feaa287c3b05592e4b3f-- From nobody Fri Sep 22 18:15:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE661243F6 for ; Fri, 22 Sep 2017 18:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qns6dfjsyPhD for ; Fri, 22 Sep 2017 18:15:53 -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 66C37124F57 for ; Fri, 22 Sep 2017 18:15:53 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id j126so752627oia.10 for ; Fri, 22 Sep 2017 18:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jCzutHI2W4Fg/awQmzzOegf/UwoHNEpK9golDRE2jVM=; b=A5sEKRYfmIWAtRRagIW8I+Eol0dcmO6ky8lqyUvlETMJgW7YWML2q84w1pUvffmwnP GA6fh8X71LgZOlCntWoWlkM6Ud67LfqA0UuKDiyxGWgW+Oz9bbaz5nQEV13E6kIk+0Zd L9ABAV7rChm3RJ+X6YvWS5K4nOyMNJkEImk6REaaPRwu+12/qqYytD0ou8l2QPl5v40c 9Wc47sBvW2iTaqPPpAvV1ry0r9reB2u9ihFmc2LotNGNBayuRkhFpruJZJaDxOLVslZ7 WFSb/AQ45OuSYThXPIQS+wBDsropxYOzmYDLnYIlgahE8vS0vC9pt10Hr8LM+uIx1fwX qGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=jCzutHI2W4Fg/awQmzzOegf/UwoHNEpK9golDRE2jVM=; b=RWA0gLJewN1w3PbxKyfcc337clEfayZyJNpO/QYD31awxnfq/PTy5Q3tRh0CmoT4LA DKhQB4Z/tW7n3gS0Da0uCk0YTuIebc2Hu4xpQS8LiPiJCO5YeNx0tpK41RGJUEbcFkiG EbwZPPk0QZGSRSXHTeW5Iy71WR755cTWSGLZBjfMnyuiPdtd5aghZW9JIr7CAdlVhqrG LqNO3m4CErXteiDpyz/PolRYqOtA5oRVXDpRlhpaN5AyvskxhriQ0nc2WplGxlFR2BNK 6zejfVrU0Go5bCw1EDMz8ScZMk04Ec3uen00HV7dgkxEXw6jAV3ObI/j/iBP21qrfaYr I83g== X-Gm-Message-State: AHPjjUiaXlrYoneb/VYXX47uOX5muyzKvJxxLT23BoOcAyG0bqj36YjT +zyaKiBvMastYFaB4TRAdwPOJyyhzWs62OxKB6s= X-Google-Smtp-Source: AOwi7QBoK55FJqfHfCNUTtoXg9C+TOfIynYHOlJBaUog/ZXxBfFoELeelfP2uOuLr3LP+2gWU2tsfjcxtT+kiYW/RFE= X-Received: by 10.202.75.66 with SMTP id y63mr1134449oia.5.1506129352806; Fri, 22 Sep 2017 18:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Fri, 22 Sep 2017 18:15:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 23 Sep 2017 11:15:52 +1000 Message-ID: To: noloader@gmail.com Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Sep 2017 01:15:55 -0000 On Fri, Sep 15, 2017 at 8:42 AM, Jeffrey Walton wrote: > The current models uses origins as a boundary, so they are different > security contexts. That's not relevant here. A certificate allows a server to speak for multiple origins. The notion of an origin is, as you say, established at a higher layer. TLS establishes a broader notion of identity. If you are interested in what origins a server might be authoritative for and how those might be managed, see http://httpwg.org/http-extensions/origin-frame.html From nobody Fri Sep 22 22:14:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E756813302A for ; Fri, 22 Sep 2017 22:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrsHFfiZJOKC for ; Fri, 22 Sep 2017 22:14:53 -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 A840C132CE7 for ; Fri, 22 Sep 2017 22:14:53 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b184so1084901oii.13 for ; Fri, 22 Sep 2017 22:14:53 -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=8ORzsFRwuaWIH8S/cRcbGJZNgXZqiP7h19DZtlaYKMc=; b=l61JSTwoFV3qtJfVGlvlFTkML8ZOYBsXe2NEbKQR5PSX6WeUJAri28r8CzXK2X5eX4 ioB+apHoBxYKCOyKzbregOB2gTH6/FRU9rKS04VkPRuw3PxM+Q6jt0DGi7Uuf4wbiehk CuSiuSjxaI0fJu+kLIw9HqHMexmx8hZNsX67FknLgXXTohiOXdrckwIKRvflwEed5RGg 2S+1POWX7dfIOzZeAvDaIFEQRXrbjtnhROgqN16l1zkRpLdZjCl4Spc58rX6of/nlmxM RLGH+lOnZfH28FdT8sdu+Ra26xTwFgIY7BNIUaD2IysZDVSG/qom8l7obtNCriSJZYN2 Dhtg== 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=8ORzsFRwuaWIH8S/cRcbGJZNgXZqiP7h19DZtlaYKMc=; b=NYt10nmOhDXAm7As0uKUrj2xIbWo33M3haTt04tLGd3aL36FTMD3cpx302OIVw/kkb 6+pChSZHcpsh2+gYnUXLZGxwy4nOgHGR2OFhUjRF+nqGLB92q2q20Q6tEFqWEAm5M3/R qLcN4U6JHz5sHZjAygFmAaW7XgEr2Zy2lPBg66YKPCEi1TtuWBnKpau6OAzqggefou9I AhAimvP7mhnWdRi8bTIkjf+kUHLimbIxiYHfF5yHtQWGgfhjxtJdfXtAANhCWbUaevWW vO7/QUonCpDpDO1hCbIVgyHnwPlRIOf4kJRH3VGv9noGhsmmWez5zg0ZlfM4FXUhd6CE DBkA== X-Gm-Message-State: AHPjjUhh5AMRaCZ/kRDJbbZ3jfQolhLEKypEvyjjWBCfDsuqTUIZFpnt COwYrOYnV1TTeAHYtl9vSzFGePiilFvATlpC9dA= X-Google-Smtp-Source: AOwi7QClk5caru4jSOkaWx4d/7jcyKHmOqoPxFTsAwoc38sQU8gbjJfMZEDtPsXfqGDUEDNlrLeRGC0r8UwKeBwHeZA= X-Received: by 10.202.222.194 with SMTP id v185mr1712388oig.113.1506143693067; Fri, 22 Sep 2017 22:14:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.19.199 with HTTP; Fri, 22 Sep 2017 22:14:51 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: From: Jeffrey Walton Date: Sat, 23 Sep 2017 01:14:51 -0400 Message-ID: To: Martin Thomson Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Removing restriction on cross-domain resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Sep 2017 05:14:55 -0000 On Fri, Sep 22, 2017 at 9:15 PM, Martin Thomson wrote: > On Fri, Sep 15, 2017 at 8:42 AM, Jeffrey Walton wrote: >> The current models uses origins as a boundary, so they are different >> security contexts. > > That's not relevant here. A certificate allows a server to speak for > multiple origins. The notion of an origin is, as you say, established > at a higher layer. TLS establishes a broader notion of identity. As far as I know, the IETF does not forbid inclusion of logically or administratively disjoint hosts from a certificate. In a shared hosting environment with a super cert, it seems like it would be easy to confuse a user agent into binding the wrong name. The IETF does not forbid an IP address either, so it seems like IP addresses could be a sore spot, too. And the hosting provider could pass the customary checks, like DV emails. So there does not seem to be a security control available to contain the risk. Jeff From nobody Sun Sep 24 19:12:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF7132351 for ; Sun, 24 Sep 2017 19:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 63coPoyKsPo2 for ; Sun, 24 Sep 2017 19:12:11 -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 4217B126B7E for ; Sun, 24 Sep 2017 19:12:10 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j126so5006650oia.10 for ; Sun, 24 Sep 2017 19:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/TJcxPDyZEgC6LKAv1hj679ttO/AjvsfzY+4MfO/wU=; b=dMNuoK7tVvPXV+4QoezxQxuuIxMU5gA5M2avBCKbFkgPKdck1AVCeZwhB1X6/fSbWt JsR20+1PwxXixNpn2WZbB22KEIwyxKj/06APsF6R2aOBruCAghILi6Q1L42Sxm6Vsd9/ MYwHgTq+GZsN1uqySMBQogBh4m3OciormC8/WkH9ig++YlBnmYj0P0XUXXl7WOlnw3N8 gv2TuRpPHTdXOQW+4W7L0r/FF8Pvqll/yqi8tlEQ/oSwA+d0Ur5Y2aMu+oMuSIwODP+8 XrSFcVQiAW6x+yUDleKdrLkJg4BszASqpJyLKuRV/84xRhg31mlS3Nh5GT+4Bi13wIlb z20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=w/TJcxPDyZEgC6LKAv1hj679ttO/AjvsfzY+4MfO/wU=; b=SPdn+Fi4x/uhZF73nyB28HvdWCJR+ni2yCeGSMulwQUnV9jGD3ixkN8wc6WjgmiIuI TYYNXqLFbnzSa4zniyNewI+Wf1dmZYpVdfGebq8ykqMpRx78rXHY60Db0CQVPTMrkSPY ioUS+WUKWm9ZfM2bWkwFyng0h1ec1jQoaLz/Sfq0tECJ9ImER8gad9phlD9mHwJy0N4H llPxn8iYnQQ8O4tG21xquTEAhd6n7xFvoa/FYlAwRH5GPN3JO87SH3l4fsIJC0bwQoJ+ AWFF0/ZV9k+1gxNoHAXe1jsGcEoExhVJ/tafGH3N3yEJx3Z6BTYzSVhEzufzOAxVPuNH m/gA== X-Gm-Message-State: AHPjjUjLflV/P0OeaMzQAOEzpThmSA29iZj0Pp7wgba8ZyserwdKzfu+ MenRkvbbh8asaAQjcCXuVo8FA/3brlDpDxA29oM= X-Google-Smtp-Source: AOwi7QCbjLv0hwpsKp9/QM6H5sRlroMIsTDNzbEglMFPH/LzcX4rE798hxdgYK4ic/s/9QMFvkQAppQsx9Es85DKrFs= X-Received: by 10.202.229.203 with SMTP id c194mr7781352oih.92.1506305530065; Sun, 24 Sep 2017 19:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Sun, 24 Sep 2017 19:12:09 -0700 (PDT) In-Reply-To: <591ffde5-6ca6-e9a1-e99e-2ee8bc61708b@gmx.net> References: <2127515.TzRoSAlNJ7@pintsize.usersys.redhat.com> <591ffde5-6ca6-e9a1-e99e-2ee8bc61708b@gmx.net> From: Martin Thomson Date: Mon, 25 Sep 2017 12:12:09 +1000 Message-ID: To: Hannes Tschofenig Cc: Hubert Kario , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 02:12:13 -0000 Hi Hannes, I appreciate that the way that you calculate the available space is difficult, but I did think very long and hard about this. The current approach makes it easier for someone to *comply* with the size limit and I'd like to retain that property as much as possible. I want people to implement and deploy this extension in every stack even if they don't have a way to set a limit lower than 16k. The only alternative metric I can think of is the size of the ciphertext. The other overheads are either fixed or hard to measure at the (D)TLS layer. Other measures are too situation-dependent, such as whether you need to count TCP headers, and leads to other problems like what you do about TCP header extensions. A change to the length of ciphertext makes it more difficult to implement at the point when you fragment messages generically. And that means more testing. As it is, I replaced a constant (MAX_FRAGMENT_LENGTH) with a variable (recordSizeLimit) and the code was basically done. Requiring calculations here adds risk and you want as many people who are NOT building an implementation for constrained devices to implement this as possible. Yes, if you want byte-accurate numbers, the configuration calculation is going to need: * information about the lower layers of the stack (TCP/UDP/IP) and how much space they need * information about TLS versions for the explicit IV * information about enabled cipher suites and their maximum expansion The good news is that if you use TLS 1.3, all the AEADs have an expansion of 16 octets (unless you are using the truncated CMAC suite, which I have never seen myself) and records add 5 octets. The whole CBC EtM/MtE business is a mess for sure, but I think that we're putting the costs in the right place. As Hubert observes, you can always assume the worst case expansion, which is safe and relatively easy. Note that TLS 1.3 padding is covered, so no concern there. On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig wrote: > Hi Hubert, > > your proposal to include the worst case calculations are indeed another > possibility. It provides more information for the developer than the > current version of the document. > > A few additional remarks: > > On 09/12/2017 08:11 PM, Hubert Kario wrote: >> On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote: >>> Hi Martin, >>> >>> I have implemented the record size extension into mbed TLS. It can be >>> found at https://github.com/ARMmbed/mbedtls/pull/1088 >>> >>> There is only one problem that remains to be addressed IMHO. This >>> extension was developed to address the problem of devices with small >>> RAM. Application developers have to configure their embedded TLS stack >>> in such a way that the parameters configured with this TLS extensions >>> match the available hardware. >>> >>> The record_size_limit helps a lot already but does not quite to the >>> final goal since it uses an artificial metric for deciding when to >>> fragment records. >>> >>> Currently, a developer has to understand various security concepts to >>> get this right, namely >>> * Ciphersuite negotiated (and the overhead associated with it, such as >>> tag length), >>> * DTLS vs. TLS record layer header differences, >>> * potential compression being applied. >>> >>> Additionally, there is, of course, other header information that needs >>> to be considered in the overall buffer size calculation, such as TCP or >>> UDP, IP and potentially any lower layer headers. >>> >>> I just think that this is too much to ask for from an ordinary developer. >>> >>> Hence, I would suggest to use a different metric so that the developer >>> can be certain that at least from a DTLS/TLS layer there are not records >>> being sent that exceed the indicated threshold. >>> >>> If you think that this idea is worthwhile to entertain then I will make >>> a proposal. >> >> yes, I too found the necessary calculation rather complex and thus hard to get >> right >> >> that being said, if you are ok with "good enough" solutions (for memory >> allocation, for verifying correctness of packets it should be exact), the >> actual receive buffer for encrypted TLS records has to be only 85 bytes longer >> than the value you send to server: >> - max MAC size - 48 bytes >> - max IV size - 16 bytes >> - header size - 5 bytes > ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most > likely different since we are trying to optimize the record layer format. > >> - max block size for CBC ciphers - 16 bytes >> - max padding - 16 bytes > ... unless TLS/DTLS 1.3 is used where padding is a different meaning. > >> since MAC size is the exact multiple of block size, the padding starts in >> worst possible place if the MAC size is arranged on block boundary. Thus the >> worst case scenario padding length is 16 bytes. Same in case of EtM. > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Sep 25 04:01:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA85132D51 for ; Mon, 25 Sep 2017 04:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t-AS5-PqxTX for ; Mon, 25 Sep 2017 04:01:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6ED1320DC for ; Mon, 25 Sep 2017 04:01:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D14B7E443; Mon, 25 Sep 2017 11:01:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7D14B7E443 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 140556B8FE; Mon, 25 Sep 2017 11:01:14 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: Hannes Tschofenig , "tls@ietf.org" Date: Mon, 25 Sep 2017 13:01:06 +0200 Message-ID: <4358181.m49shj5WTR@pintsize.usersys.redhat.com> In-Reply-To: References: <591ffde5-6ca6-e9a1-e99e-2ee8bc61708b@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart83702556.l2QPPabb62"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 25 Sep 2017 11:01:14 +0000 (UTC) Archived-At: Subject: Re: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:01:20 -0000 --nextPart83702556.l2QPPabb62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 25 September 2017 04:12:09 CEST Martin Thomson wrote: > Hi Hannes, >=20 > I appreciate that the way that you calculate the available space is > difficult, but I did think very long and hard about this. >=20 > The current approach makes it easier for someone to *comply* with the > size limit and I'd like to retain that property as much as possible. > I want people to implement and deploy this extension in every stack > even if they don't have a way to set a limit lower than 16k. >=20 > The only alternative metric I can think of is the size of the > ciphertext. The other overheads are either fixed or hard to measure > at the (D)TLS layer. Other measures are too situation-dependent, such > as whether you need to count TCP headers, and leads to other problems > like what you do about TCP header extensions. >=20 > A change to the length of ciphertext makes it more difficult to > implement at the point when you fragment messages generically. And > that means more testing. As it is, I replaced a constant > (MAX_FRAGMENT_LENGTH) with a variable (recordSizeLimit) and the code > was basically done. =20 my understanding of this draft was that the TLS1.3 ContentType is included = in=20 the record limit while it is not included in the TLS 1.3 maximum payload si= ze > Requiring calculations here adds risk and you > want as many people who are NOT building an implementation for > constrained devices to implement this as possible. >=20 > Yes, if you want byte-accurate numbers, the configuration calculation > is going to need: >=20 > * information about the lower layers of the stack (TCP/UDP/IP) and how > much space they need > * information about TLS versions for the explicit IV > * information about enabled cipher suites and their maximum expansion >=20 > The good news is that if you use TLS 1.3, all the AEADs have an > expansion of 16 octets (unless you are using the truncated CMAC suite, > which I have never seen myself) and records add 5 octets. The whole > CBC EtM/MtE business is a mess for sure, but I think that we're > putting the costs in the right place. >=20 > As Hubert observes, you can always assume the worst case expansion, > which is safe and relatively easy. >=20 > Note that TLS 1.3 padding is covered, so no concern there. >=20 > On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig >=20 > wrote: > > Hi Hubert, > >=20 > > your proposal to include the worst case calculations are indeed another > > possibility. It provides more information for the developer than the > > current version of the document. > >=20 > > A few additional remarks: > >=20 > > On 09/12/2017 08:11 PM, Hubert Kario wrote: > >> On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote: > >>> Hi Martin, > >>>=20 > >>> I have implemented the record size extension into mbed TLS. It can be > >>> found at https://github.com/ARMmbed/mbedtls/pull/1088 > >>>=20 > >>> There is only one problem that remains to be addressed IMHO. This > >>> extension was developed to address the problem of devices with small > >>> RAM. Application developers have to configure their embedded TLS stack > >>> in such a way that the parameters configured with this TLS extensions > >>> match the available hardware. > >>>=20 > >>> The record_size_limit helps a lot already but does not quite to the > >>> final goal since it uses an artificial metric for deciding when to > >>> fragment records. > >>>=20 > >>> Currently, a developer has to understand various security concepts to > >>> get this right, namely > >>>=20 > >>> * Ciphersuite negotiated (and the overhead associated with it, such = as > >>>=20 > >>> tag length), > >>>=20 > >>> * DTLS vs. TLS record layer header differences, > >>> * potential compression being applied. > >>>=20 > >>> Additionally, there is, of course, other header information that needs > >>> to be considered in the overall buffer size calculation, such as TCP = or > >>> UDP, IP and potentially any lower layer headers. > >>>=20 > >>> I just think that this is too much to ask for from an ordinary > >>> developer. > >>>=20 > >>> Hence, I would suggest to use a different metric so that the developer > >>> can be certain that at least from a DTLS/TLS layer there are not reco= rds > >>> being sent that exceed the indicated threshold. > >>>=20 > >>> If you think that this idea is worthwhile to entertain then I will ma= ke > >>> a proposal. > >>=20 > >> yes, I too found the necessary calculation rather complex and thus hard > >> to get right > >>=20 > >> that being said, if you are ok with "good enough" solutions (for memory > >> allocation, for verifying correctness of packets it should be exact), = the > >> actual receive buffer for encrypted TLS records has to be only 85 bytes > >> longer>>=20 > >> than the value you send to server: > >> - max MAC size - 48 bytes > >> - max IV size - 16 bytes > >> - header size - 5 bytes > >=20 > > ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most > > likely different since we are trying to optimize the record layer forma= t. > >=20 > >> - max block size for CBC ciphers - 16 bytes > >> - max padding - 16 bytes > >=20 > > ... unless TLS/DTLS 1.3 is used where padding is a different meaning. > >=20 > >> since MAC size is the exact multiple of block size, the padding starts= in > >> worst possible place if the MAC size is arranged on block boundary. Th= us > >> the worst case scenario padding length is 16 bytes. Same in case of Et= M.>=20 > > Ciao > > Hannes > >=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 --nextPart83702556.l2QPPabb62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJZyOHyAAoJEJKo0bgB0vX1eJ8P/Rv8iDldLYrDQZwA/ynjo2pJ 22LsFY2fzsV97XJIIXStyzbyi+rNyYeBFQmb/eIIn0GHUT8ogbSOGZ4SMX7Aadvm SzLLSMBTgcyCzVg48wayAYBgoXMUloIEQT7W+l9LFxzMvGhxThlua4I1VNo/jcgY PnLKhnPV4fvCy1uUdOSL5hxnWWNXenf9v7pLshZCmnh0zhU1Zf5j7S4Afnl9LzPh ItxJnm43zYoNj1bEbY+BGZbZXdMqI3V5XQuIRr0ffz/kmkMZmfLFZdEsPJenCTn0 ULmlwmGtjKGxAXvNJzIgq64ekJZG+xlZKXDmB2AVO7qZr+28PBkJuMoX6X1sjAMM BRns8U5BfDZDPbXIg5CaOZJSkhr2JQD+lAt3In7lcNLM178fymKmEZVZ+a+cycrX fCEimr0D4pBEI3AL94pQlDDAqap+T1Ul7Izsde6BuukRKBLSGhLGIjAGjDxfWKt7 Mz3O3YxcJAxSnEjet/09u1BsQA5BeVmy9uWxEU0y3sxeTUVEk4rYMgDv9bHqn7Yl OPPjXDgk9ICnBKG9GpFv0J7xk5Gs+zGlQF7acWhSNqA2P8LjIsxeP2r3oZsMF3Pk KChq38rHFH258aJ1hBCrMjLggm/fz++cuoWoO3PRuVQAM2a6lwC2g5wRbbWYkub2 qYAda1/iT8z6wbOdDxlF =HaPH -----END PGP SIGNATURE----- --nextPart83702556.l2QPPabb62-- From nobody Mon Sep 25 09:21:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4171344CC for ; Mon, 25 Sep 2017 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ4FwAOjmXPG for ; Mon, 25 Sep 2017 09:21:13 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBF61344AE for ; Mon, 25 Sep 2017 09:21:10 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u205so5097278ywa.5 for ; Mon, 25 Sep 2017 09:21:10 -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=OoX6mvJ0XAp1lCWJBL1zyldoXbcuDI4TiBNqq2djTtE=; b=VOFt4w1BjFDoIqyOQGBKYrfI4pnYBYSn0kv3/KCLbKjeGvJNPeX3LIfBaukeE9sJfg S+5Fg8sYzCIZ8+RD2dWmP05YrfacXrAMOVXgs+0poXt9Y3oekDpCemtJJwSmkZai19+q prlR0eQgzKV4/bGDzwwWgI/YI2sbWOL2cay6pxwt2cJm6wzeH/ABwpBiYVYDbcDCPhyW awJa2lG6aB7QFTRWB57TAVBchLi/FNha/VOmiH6Vez4NSi9g7HRnZYBE55ijkyamHC9v 7ZZ7QCoJv4vAioPjGd9ZEsDhHRN6IINApI6doR5FV5DqHX6rWUk4Qp2mWMDLAm+SFj+U qOog== 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=OoX6mvJ0XAp1lCWJBL1zyldoXbcuDI4TiBNqq2djTtE=; b=lXGIFgB+FWlVtkek10vblWNDgtvOzdM1eab+VxjlAeoZgirAqclk26MqbJGU0Z0bs6 tHNU5FLURTpyX8xC4rQvIlehTpMPb2W9S8kRhaTYjCi2IV6K0dI6P+MrL80Raf4ZZWqV roLGwhe+OxGrMMnGRQG2ymHWo4LsS0kKlnXeiPs0pvfP6etRWAyySz7J7Dxwr/mTnf4U i5Cejyu735cPa217iTYlliRyDvBPTWzYPZI50pO+nrSC81//a0QapOao2gHhfclSutw2 PhxPUMENWb4rkFasXWv+R6Gyu+eDhSaClEGQtZ2deKbJ2zeilWSFjD4YP8DSCbAwqC3L d9Cw== X-Gm-Message-State: AHPjjUjFJl+2QItMjLGgFLYKAYxA7kKlpZ/UMNek4FeBsJ1pH5SwIHVo IGCc78sKGC6HY4CRIQmjPfZMsdBAqvj3gkLJEJEzqg== X-Google-Smtp-Source: AOwi7QBShgZizEgFYVq+jg7lHtt/qUCD92hLWi8Hf6Dw8HcyemLcDVOj9JDkL+K67MrmQP1x6Spuc5E8JdQN13pzb3Q= X-Received: by 10.129.156.200 with SMTP id t191mr4726882ywg.279.1506356468816; Mon, 25 Sep 2017 09:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.234.17 with HTTP; Mon, 25 Sep 2017 09:21:07 -0700 (PDT) From: devzero2000 Date: Mon, 25 Sep 2017 18:21:07 +0200 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0c091a3aa237055a05f2cb" Archived-At: Subject: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 25 Sep 2017 16:21:15 -0000 --94eb2c0c091a3aa237055a05f2cb Content-Type: text/plain; charset="UTF-8" Hello everyone >From the tls 1.2 specification, speaking of client authentication, https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the same for the last tls draft 1.3 par. 4.2.4.) when he says: certificate_authorities A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. What would be the right behavior if the server has the certificates of two different CAs (different subject key info, public key parameter) but whose subject DN differs only for the case (for example something like this Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com and Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com Note the different (M|m)ountain ) 1 - In one case the server could send both DNs to the client, the client could choose the one that signed its certificate, and the server would be able to validate, based on the autority key identier, the client with the right CA. 2 - In another case, instead, the server chooses to send only one of the two DNs, probably the first configured, and if that is not the one that signed the client certificate, the authentication would not continue. I have seen that some TLS implementations follow both of the behaviors described and this creates interoperability issues, i think. It should not be an ambiguous behavior, and it should be clarified. Opinions ? Thanks you very much for the attention Ciao Elia --94eb2c0c091a3aa237055a05f2cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone

From the tls 1.2 specification, speaking of client authentication,=20 https://tools= .ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is=20 the same for the last tls draft 1.3 par. 4.= 2.4.)

when he says:

certificate_authorities
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A list of the distinguished names [X501= ] of acceptable
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0certificat= e_authorities, represented in DER-encoded format.

What w= ould be the right behavior if the server has the certificates of two different CAs (different subject key info, public key parameter)=20 but whose subject DN differs only for the case (for example
som= ething like this

Subject: /C=3DUS/ST=3DCalifornia/L= =3DMountain View/O=3DXXX Inc/CN=3Dmail.xxx.= com
=

and


Subject: /C=3DUS/ST=3DCalifornia= /L=3Dmountain View/O=3DXXX Inc/CN=3Dmail.xx= x.com

Note the different (M|m)ountain
=
)
<= /span>

= 1 - In one case the server could send both DNs to the client, the=20 client could choose the one that signed its certificate, and the server=20 would be able to validate, based on the autority key identier, the=20 client with the right CA.

2 - In another ca= se, instead, the server chooses to send only one of=20 the two DNs, probably the first configured, and if that is not the one=20 that signed the client certificate, the authentication would not=20 continue.

I have seen that some TLS implementation= s follow both of the behaviors described and this creates interoperability = issues, i think. It should not be an ambiguous= behavior, and it should be clarified.


Thanks you very much for the attention
=
Ciao

Elia
--94eb2c0c091a3aa237055a05f2cb-- From nobody Mon Sep 25 11:54:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77313454D for ; Mon, 25 Sep 2017 11:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jH1i_WgYa5FI for ; Mon, 25 Sep 2017 11:54:54 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2259134546 for ; Mon, 25 Sep 2017 11:54:53 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 9E4A333D1A9; Mon, 25 Sep 2017 18:54:52 +0000 (UTC) Sender: geoffk@localhost.localdomain To: devzero2000 Cc: tls@ietf.org References: From: Geoffrey Keating Date: 25 Sep 2017 11:54:52 -0700 In-Reply-To: Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 25 Sep 2017 18:54:56 -0000 devzero2000 writes: > Hello everyone > > >From the tls 1.2 specification, speaking of client authentication, > https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the > same for the last tls draft 1.3 par. 4.2.4.) > > when he says: > > certificate_authorities > A list of the distinguished names [X501] of acceptable > certificate_authorities, represented in DER-encoded format. > > What would be the right behavior if the server has the certificates of two > different CAs (different subject key info, public key parameter) but whose > subject DN differs only for the case (for example > something like this > > Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com > > and > > > Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com These are the same distinguished name under RFC 5280 section 7.1, although in practice implementations may treat them as different, most notably under the older RFC 3280 rules. I believe the correct behaviour is to Not Do That---do not generate certificates which have distinguished names that match under RFC 5280 and are not byte-for-byte identical in DER format, if you must do that make sure they are not valid at the same time, and if you must do that, try to ensure no piece of software is aware of both of them, and if you must do that, don't be surprised if the behaviour is inconsistent and especially don't be surprised if the LDAP StringPrep rules are not implemented correctly or at all. And if you value your sanity, don't rely on anything that might change if the Unicode standard is revised. However, the TLS specification doesn't say that the list must contain each DN only once. So in this situation I would suggest the software should list both. Indeed I would recommend listing every distinct DER representation that's present in any acceptable certificate. From nobody Mon Sep 25 14:20:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB2F1345A5 for ; Mon, 25 Sep 2017 14:20: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 RYk0qWLWqE8e for ; Mon, 25 Sep 2017 14:20:33 -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 D1CC7127005 for ; Mon, 25 Sep 2017 14:20:32 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id i128so9012994oih.6 for ; Mon, 25 Sep 2017 14:20:32 -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=x2POWrXGbOFyfT9Sih1KqfI8cmskKiwaM8dSkWS8YkA=; b=SC4b8GCaSUVh4P9bb/R9aqIv33n1qa7ifs/xy+zbpaBNcNAgt8dMgqQDVAgS+1zhq4 2HUrqGrGzBxIVLy5SN8NTqazPnnohu4BK4hmYuIs4EpbsOhkDyhnNBRLeqT7NurmPb0v C4UyTyjG4+MG08TMUKi0S8p1d3t/ZoESslrCtZcsvkZ2GB8GtHjZgSQuC+Vjq1K62rf6 +bj+bQuVLGnnsshVaCWduJ0LP66qV02VKtAyTQlaXSV/VqsTF/WvfA7z+4yO0i8uT091 7jyDSyv7axFwIyF5yO/XZGw9p5ZP7q+HIPMLB4v8l8xiX5MlDZPTCTmE7fk4osSPu0Wi 1XkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=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=x2POWrXGbOFyfT9Sih1KqfI8cmskKiwaM8dSkWS8YkA=; b=kO3Up2aEjH1pvh/tWraUimzFrzMg+ICY82LbOIR/AnPIG7ZMDhp7zH5WsQ4ZZRbKj0 4FcAsetBZxHsguss3bMIocu6nvS+DC5WMl7lcQzT1IJ+VHHLzKvSZZcuE3GioYDjBucO P+T54YqYQ3OcdNjk5jf6AaJXWiFFgPRBmF7GL8RP+oR8rwZdW1hH1KSfk0Uth98XHl9r sCYJVXXddCMuyDPtKS7xaZzpgTZ47PMHQ7QVKleCPqRgDfyZK/y4bphh2QkACts/I94s S6dGQ1BYiAjjtAVIq6iGzeJbEOO1mCFo6z2SA1lGPHeVoTg+bqiUU247yuSOCSRsjMim BIaw== X-Gm-Message-State: AHPjjUhxqLaN+g4Z1AeS9+wzjTH41F1mtsa558Zc7M32z/sVrp1UbvqX QgaSZcI0L0H8gDcjzKH3xsRO5OBEMrO0Y93eNPw= X-Google-Smtp-Source: AOwi7QB5sv1LJ4INPLWRyirVAh08d+fbeR+fw9aJzofXBEXmiA1PskgfbMuLAjnV6sMG4MFiBcjT2lzeetrW5xPS7hc= X-Received: by 10.202.75.66 with SMTP id y63mr9580273oia.5.1506374432123; Mon, 25 Sep 2017 14:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 14:20:31 -0700 (PDT) In-Reply-To: <4358181.m49shj5WTR@pintsize.usersys.redhat.com> References: <591ffde5-6ca6-e9a1-e99e-2ee8bc61708b@gmx.net> <4358181.m49shj5WTR@pintsize.usersys.redhat.com> From: Martin Thomson Date: Tue, 26 Sep 2017 07:20:31 +1000 Message-ID: To: Hubert Kario Cc: Hannes Tschofenig , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-record-limit-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:20:34 -0000 On Mon, Sep 25, 2017 at 9:01 PM, Hubert Kario wrote: > my understanding of this draft was that the TLS1.3 ContentType is included in > the record limit while it is not included in the TLS 1.3 maximum payload size That's right, I forgot this detail. I subtract 1 for TLS 1.3 when I set the variable. From nobody Fri Sep 29 09:46:50 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B50126E64; Fri, 29 Sep 2017 09:46:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670360846.13933.15875604800239696553.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 09:46:48 -0700 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 100 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, 29 Sep 2017 16:46:48 -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.5 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: quic rtcweb stir curdle saag uta acme cfrg httpbis tokbind perc dispatch Second Priority: dprive ace Third Priority: tcpinc lamps People who must be present: Eric Rescorla Sean Turner Joseph A. Salowey Kathleen Moriarty Resources Requested: Special Requests: If sec-dispatch ends up being a thing please don't schedule us against that. Also please don't put us up against the TEEP or FUD BOFs. ---------------------------------------------------------