From nobody Fri Jan 1 03:19:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700291A065C for ; Fri, 1 Jan 2016 03:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFmlbE9Ih24M for ; Fri, 1 Jan 2016 03:19:31 -0800 (PST) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6C01A0545 for ; Fri, 1 Jan 2016 03:19:30 -0800 (PST) Received: from [192.168.90.50] (bl28-68-171.dsl.telepac.pt [37.189.68.171] (may be forged)) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01BImxI030338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jan 2016 11:18:53 GMT To: tls@ietf.org References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> From: Samuel Neves X-Enigmail-Draft-Status: N1110 Message-ID: <56866098.2010803@dei.uc.pt> Date: Fri, 1 Jan 2016 11:18:48 +0000 User-Agent: MIME-Version: 1.0 In-Reply-To: <20160101073508.4dd10442c5@ebeb88ce88adeb8> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp.dei.uc.pt [193.137.203.253]); Fri, 01 Jan 2016 11:18:53 +0000 (WET) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: u01BImxI030338 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-10.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 11:19:34 -0000 On 01/01/2016 06:35 AM, Aaron Zauner wrote: > This might be a good time to point again to my existing AES-OCB > draft that hasn't really seen a lot of discussion nor love lately. > It expired but I've recently updated the draft (not yet uploaded > to IETF as I'm waiting for implementer feedback from two particular > sources). The update has something to do with how GCM is implemented > in some stacks though, see: > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 OCB is, if anything, worse than GCM when it comes to data volume limits. It has the same confidentiality bounds as GCM (slightly worse, in fact), but once you hit a collision you also lose authenticity and enable simple forgeries [1]. The real issue here is the block size of AES, not the security bounds of particular modes. Those are by and large all limited by the birthday bound. You could go with more exotic beyond-birthday modes, but there don't seem to be any being proposed for TLS. The simple solution to the birthday blues is, of course, to use a larger block. [1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/General_Comments/papers/Ferguson.pdf From nobody Fri Jan 1 04:52:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC741A8746 for ; Fri, 1 Jan 2016 04:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM2lzPkipqzA for ; Fri, 1 Jan 2016 04:52:45 -0800 (PST) Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id C531C1A8745 for ; Fri, 1 Jan 2016 04:52:44 -0800 (PST) X-Halon-ID: 8b2c91d2-b086-11e5-a7a4-00505692585a X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP for ; Fri, 1 Jan 2016 13:52:41 +0100 (CET) Received: from [192.168.0.187] (unknown [92.39.33.245]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 98E49C9378 for ; Fri, 1 Jan 2016 13:52:40 +0100 (CET) To: tls@ietf.org References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> From: =?UTF-8?Q?Henrick_Wibell_Hellstr=c3=b6m?= Message-ID: <568676E8.6090802@streamsec.se> Date: Fri, 1 Jan 2016 13:54:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020503050403080703060407" Archived-At: Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 12:52:48 -0000 This is a multi-part message in MIME format. --------------020503050403080703060407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I think it is a good idea to rekey AES-GCM after approximately 2^32 records, give or take a few magnitudes. The question for me isn't whether AES-GCM requires frequent rekeying (it does), but exactly how much complexity the rekeying mechanism would add, to the protocol and to implementations. On 2015-12-28 20:54, Eric Rescorla wrote: > Scott, Henrick, > > Are you persuaded by Watson's analysis? > > Thanks, > -Ekr > > > > > On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario > wrote: > > On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > > So we have to trade off the risks of too much data vs. the risks > > of a complex rekey protocol vs. the risks having the big data > > applications build new connections every 2**36 or so bytes. > > > > If we don't have rekeying, then the big data applications are > > the only ones at risk. If we do, it may be a wedge which can > > compromise all users. > > if the rekey doesn't allow the application to change authentication > tokens (as it now stands), then rekey is much more secure than > renegotiation was in TLS <= 1.2 > > so if we include rekeying in TLS, I'd suggest to set its limit to > something fairly low for dig data transfers, that is gigabytes, not > terabytes, otherwise we'll be introducing code that is simply not > tested > for interoperability > > (with AES-NI you can easily transfer gigabytes in just few minutes) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > 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 --------------020503050403080703060407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I think it is a good idea to rekey AES-GCM after approximately 2^32 records, give or take a few magnitudes.

The question for me isn't whether AES-GCM requires frequent rekeying (it does), but exactly how much complexity the rekeying mechanism would add, to the protocol and to implementations.



On 2015-12-28 20:54, Eric Rescorla wrote:
Scott, Henrick,

Are you persuaded by Watson's analysis?

Thanks,
-Ekr




On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario <hkario@redhat.com> wrote:
On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote:
> So we have to trade off the risks of too much data vs. the risks
> of a complex rekey protocol vs. the risks having the big data
> applications build new connections every 2**36 or so bytes.
>
> If we don't have rekeying, then the big data applications are
> the only ones at risk. If we do, it may be a wedge which can
> compromise all users.

if the rekey doesn't allow the application to change authentication
tokens (as it now stands), then rekey is much more secure than
renegotiation was in TLS <= 1.2

so if we include rekeying in TLS, I'd suggest to set its limit to
something fairly low for dig data transfers, that is gigabytes, not
terabytes, otherwise we'll be introducing code that is simply not tested
for interoperability

(with AES-NI you can easily transfer gigabytes in just few minutes)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
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

--------------020503050403080703060407-- From nobody Fri Jan 1 06:40:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B681ACD1C for ; Fri, 1 Jan 2016 06:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 GyJJ37QYPnRU for ; Fri, 1 Jan 2016 06:40:21 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E71581ACD19 for ; Fri, 1 Jan 2016 06:40:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EE6CD1FC; Fri, 1 Jan 2016 16:40:18 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id EO_GbvYCBpij; Fri, 1 Jan 2016 16:40:18 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7530E27B; Fri, 1 Jan 2016 16:40:18 +0200 (EET) Date: Fri, 1 Jan 2016 16:40:16 +0200 From: Ilari Liusvaara To: Henrick Wibell =?utf-8?Q?Hellstr=C3=B6m?= Message-ID: <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <568676E8.6090802@streamsec.se> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 14:40:23 -0000 On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote: > I think it is a good idea to rekey AES-GCM after approximately 2^32 records, > give or take a few magnitudes. > > The question for me isn't whether AES-GCM requires frequent rekeying (it > does), but exactly how much complexity the rekeying mechanism would add, to > the protocol and to implementations. There have been three basic proposed categories of key update schemes: 1) Ratchet keys through KDF, no new randomness. 2) Ratchet keys through KDF, with new randomness 3) Do new PK key exchange Also, if one doesn't want applications to have to be aware of rekeying, one can't introduce new flights ("fully asynchronous key update"). This would cause _severe_ constraints. Then there is strictly weaker constraint that one can't introduce "dead air", where the protocol can't make forward progress without waiting for response (the previous constraint is sufficient but not necressary to meet this). Firstly, 1) The current scheme is example of 1) without new flights. Basically, send a message to ratchet sender's keys. There is no symmetry-breaking between updates, so if k(i) = k(j), then k(i+n) = k(j + n) (such symmetry-breaking could be introduced by adding key number to KDF inputs). Also, I noted that the current scheme seems to break HKDF pairing: It tries to expand already expanded value (traffic secret). This violates pairing. Also, scheme like this could nicely work with DTLS: One could use epoch numbers to signal rekeying (but one would then take care not wrap epoch in way that could cause confusion). Then 2) Doing 2) without new flights would imply: - Two traffic keys, one for each direction. The low-level ciper keys derive from traffic key of respective direction. - Sending message to update keys would update only the traffic key in sending direction, regenerating low-level cipher keys and resetting the RSN in that direction. - Entropy from peer can't be explicitly be used. The best one could do here is to recommend mixing last received ratchet entropy from peer into own entropy to produce the random value to send when replying (when that happens). I don't think this is terribly more complicated than 1). But it is more complicated nevertheless. I don't see dropping the stronger full asynchronous constraint would simplify things, due to possibility of "crossed rekey" caused by finite "speed of light". Also, this would cause issues with DTLS: One would have to reliably transmit these rekeying messages, whereas previous DTLS are reliable only within handshake. Finally 3) Now the rekeying necressarily involves two messages. Doing this fully asynchronously seems just about impossible (updating one half- key at a time would hit "key caching" problem). Then it would be whole new logic for performing PK exchange. One can't reuse handshake because it would introduce thorny issues about tying to previous handshake and ensuring that state doesn't change in all sorts of unexpected ways. It also would need to somehow prevent crossing a key update. All in all, the complexity looks grealy greater than 1) or 2). -Ilari From nobody Fri Jan 1 08:01:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CEC1A9244 for ; Fri, 1 Jan 2016 08:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMH28lPRZazo for ; Fri, 1 Jan 2016 08:01:30 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496C91A1B07 for ; Fri, 1 Jan 2016 08:01:30 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f206so139138242wmf.0 for ; Fri, 01 Jan 2016 08:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0ebQ5yeQZEuorqaRIM2MBA2Waic8WMc7KmsHbDAg2EQ=; b=enCJgq1yEy9tdV64ntAG3cu+6XmmS++S36H9j+Z1C086KQybUiv/MtpWptJoSgsdFa LFcWtI4DKY7B8HBIv1zlwFIZrio9bbElCv7E9UQQ6E+wiRKfubGBGPc2kMkyxQ4B9+iV HWkUw3gGlg+UOx7rZUUfQqEaYARX6t4u/HjmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0ebQ5yeQZEuorqaRIM2MBA2Waic8WMc7KmsHbDAg2EQ=; b=m0UCKJ8lPwnihaCQ/+wWr4FdFTmJIZmvlzdD/hjoT5imooUDLkNgPzZrGsD929ZYev QCCqpPYwBXzqtoAkrTTSrcTkV9fYJG8II8Yl/Qd7c+XQpF/qOv01ICNfHsGTlMz8pD02 cF0WS/t2CA6jpQfvPKG3xPEHr1Wfjnz9EmEgauzzBn35+CO48zLnYnmEHWCzMSLxmk4g cqKcatEB/dfIOaZwbtrOhHMoK4XY6GseeFjmfbmZtwAWPErFEvd2KcoVuSc+i8SE2Xda rpBdZtNCbkB38XDaQNrBHRiL+oMLInqWuA1a/syxx8xno9PfLUifWhun/jCKEzKdMnG7 Rcug== X-Gm-Message-State: ALoCoQla6yBYk3Xu59jgflI9gBtvQvXmDy24dX5nCz75YSsTFUq12j/NeejmCDaWKF8vrlP1JlrqSdTiRiLfam2YmXSMAATIOw== X-Received: by 10.195.11.129 with SMTP id ei1mr95425315wjd.80.1451664088717; Fri, 01 Jan 2016 08:01:28 -0800 (PST) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id q75sm25742855wmd.6.2016.01.01.08.01.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 08:01:26 -0800 (PST) Date: Fri, 1 Jan 2016 17:01:38 +0100 From: Aaron Zauner To: Samuel Neves Message-ID: <20160101165821.6cc8a962c4@1620a90cf4e0c0b> References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <56866098.2010803@dei.uc.pt> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 16:01:31 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Samuel, * Samuel Neves [01/01/2016 12:19:36] wrote: > OCB is, if anything, worse than GCM when it comes to data volume limits. = It has the same confidentiality bounds as GCM > (slightly worse, in fact), but once you hit a collision you also lose aut= henticity and enable simple forgeries [1]. >=20 If I understand correctly the same is true for GCM? I did not say that OCB provides beyond-birthday bound security. I'm well aware that the mode does not really affect this issue in that particular case. > The real issue here is the block size of AES, not the security bounds of = particular modes. Those are by and large all > limited by the birthday bound. You could go with more exotic beyond-birth= day modes, but there don't seem to be any being > proposed for TLS. The simple solution to the birthday blues is, of course= , to use a larger block. >=20 Sure. Agreed. Thanks for the feedback, Aaron --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWhqLfAAoJEOTbZJL9ubXVz7QP/i0wDIFjb+Vz3Z+0O4s1798l VZpVdDajSYZR5sx6D7fWuPnBELyZcjGFBOtUchH0ajzIRR9CHxU09ItaxpptcP2R BgOesWuTJQkOwS+c3vk6Qs1DUW3TVqVogRn3J1ime/GmPo+iKnLY88MWXWgTiYun 0RyO6eY89Nvkk8A0j6nZIuxmCg9Zngar9J2F5Z4w467d55xePiLdFMcr2nUMSxMT pkXUP2hHAwmzirBPkEuNfr89ipyCJfRJsLMGplwnTtiVqWcm5P32243eYx/3x2kH b9HNt+Z9zl8YJGHG2XjsbpWi6WDn7bbWNe4Mn5mpmIXpp9a8eUtH70CSH5liZMWo lMmTyJoRNisYcP8sMFxWawsTbeZ/ruX+T+eMONoFs2oEbrokpXx5Y5o+MaLll/Vd 5sLqiPr2CIoWcJAep2i/+4BEkwmMrRHO5ItOiM286v08QUMhIpWHF1PVKe7dsp4r kWkdBp5yCPUtNiSQZBdaI70vHNFsNu4ubr+ZGMqxluXZoR3Ji+DPVGNg/iHlPOvb ukGuPKxGzFQI87JExeYblnqbWoL+Ocsj0edf+ksqPyKoScEkyuWgXNbA7ulN/lEn FhDinI1XXwyPTyTu6F2oGG3Rd6Y1ekj9r0Jrad8sPbd5+L7XPxqP72NwR1NIFmZR 5GUfxLXYySxwUbDJLjDT =tyMb -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From nobody Fri Jan 1 09:19:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24C11ACDE1 for ; Fri, 1 Jan 2016 09:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47RoHgwaS-8h for ; Fri, 1 Jan 2016 09:19:28 -0800 (PST) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103761ACDDA for ; Fri, 1 Jan 2016 09:19:27 -0800 (PST) Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01HInjU005351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jan 2016 17:18:49 GMT Received: from mail.dei.uc.pt (localhost [127.0.0.1]) by mail.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01HGVrO016856; Fri, 1 Jan 2016 17:16:31 GMT Received: (from daemon@localhost) by mail.dei.uc.pt (8.14.4/8.14.4/Submit) id u01HGUSY016855; Fri, 1 Jan 2016 17:16:30 GMT Received: from bl28-68-171.dsl.telepac.pt (bl28-68-171.dsl.telepac.pt [37.189.68.171]) by mail.dei.uc.pt (Horde Framework) with HTTP; Fri, 01 Jan 2016 17:16:30 +0000 Message-ID: <20160101171630.15796qivr4d264xa@mail.dei.uc.pt> Date: Fri, 01 Jan 2016 17:16:30 +0000 From: sneves@dei.uc.pt To: Aaron Zauner References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> In-Reply-To: <20160101165821.6cc8a962c4@1620a90cf4e0c0b> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.8) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (smtp.dei.uc.pt [193.137.203.253]); Fri, 01 Jan 2016 17:18:49 +0000 (WET) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: u01HInjU005351 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-10.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 17:19:31 -0000 Quoting Aaron Zauner : > * Samuel Neves [01/01/2016 12:19:36] wrote: >> OCB is, if anything, worse than GCM when it comes to data volume >> limits. It has the same confidentiality bounds as GCM >> (slightly worse, in fact), but once you hit a collision you also >> lose authenticity and enable simple forgeries [1]. >> > > If I understand correctly the same is true for GCM? > The contention with GCM in this thread has been, so far, focused on confidentiality. This is because, by a result of Bernstein [1] (see also Appendix C of [2]), after q = 2^60 messages sent, plus q' = 2^60 attempted forgeries by an attacker with messages at most l_A = 2^16 blocks long, the probability of an attacker to forge a message is still ~2^-52. This does not present a data volume problem at the moment for the authentication part of AES-GCM. On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76 total blocks), a block collision is almost guaranteed to have happened, enabling the aforementioned forgeries. What you may be thinking of is the GCM behavior on _nonce reuse_. In this case, we are able to recover the authentication key by root finding and forge messages at will. This is also the case with OCB---on nonce reuse, we can forge any message that has the same checksum as a valid message. [1] http://cr.yp.to/antiforgery/securitywcs-20050227.pdf [2] https://eprint.iacr.org/2012/438 From nobody Fri Jan 1 10:22:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1291ACD27 for ; Fri, 1 Jan 2016 10:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGs4tCgS-O81 for ; Fri, 1 Jan 2016 10:22:44 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6301A8944 for ; Fri, 1 Jan 2016 10:22:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 204E220F for ; Fri, 1 Jan 2016 20:22:42 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 3-9IV5_Avgac for ; Fri, 1 Jan 2016 20:22:41 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D6C70138 for ; Fri, 1 Jan 2016 20:22:41 +0200 (EET) Date: Fri, 1 Jan 2016 20:22:40 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160101182240.GA25903@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151231201644.17780804.55594.43078@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151231201644.17780804.55594.43078@ll.mit.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 18:22:46 -0000 On Thu, Dec 31, 2015 at 08:16:35PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I think Watson made a good point about "omittable checks". ‎If an > implementation A "omits" this mechanism, it should fail session > establishment. Well, here is one scheme that I can't break myself and has no checks one can just "omit": PMS = SHA-512(A|B|DHF(a,B)) = SHA-512(A|B|DHF(b,A)) Where a and b are the private keys and A and B are the public keys and DHF is X25519 or X448. -Ilari From nobody Fri Jan 1 10:25:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243AC1ACE39 for ; Fri, 1 Jan 2016 10:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKJVI6XMdIRt for ; Fri, 1 Jan 2016 10:25:13 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D5A1ACE37 for ; Fri, 1 Jan 2016 10:25:13 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id l65so108607988wmf.1 for ; Fri, 01 Jan 2016 10:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cpc22ccJBa+baaLYF50UG2XL6LnWdEJvQ+WFFE6VgIprlB/3VRbdsy5NZ87BDf/3L8 hgKOUqX5PKnbx5YZusFQC2sxvVrgTOVW6y7S5TADCuDUYBzkJ+k6NJWzhqpgyaLrCc1L 0HlREu2kp2Kw4b2TJBO5YS4Ai/txHRr605XmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cJ3vQKADuPwYOTa9Ozl8ztaXpmReMBzBx6AtrHjVyZNWnOhlp1PQdHFKdd79KWHwCp TvX8fsrKUv6EbGYPehLDZ2FeVTsSMlWU4/nXYcIAe7ssAual1fDSFTz2gfx6xvljwYs/ TXXWdvPn+x/oo9UZYa8Q+GpEXhv++DD3x0iOQyTkYqyEpM7wMkso/1yW725fZ2eNFllV sIKNHh2FEYTmejntgolMScmBMn7r6fPhIkoFy6NBCNH7NgAF/uKCz1D+GbDE267+Gl6f V5fIBtlbxC2T05Kw6WYAIb+b5BsCEEddLqUY054fu+mCphTDfaDzJ4Mr0rV1+1GFnKAp 5kAQ== X-Gm-Message-State: ALoCoQnTBLZ2qEdsx4Q4lNxfzpj32BnE/vQPkQs78QfcHd5hdIW0jhbSoTFp6kj260S7064dQpeqwNPVSSvM+0Pz+PusJKmqYQ== X-Received: by 10.28.64.131 with SMTP id n125mr86192488wma.103.1451672711994; Fri, 01 Jan 2016 10:25:11 -0800 (PST) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id w80sm45101961wme.17.2016.01.01.10.25.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 10:25:10 -0800 (PST) Date: Fri, 1 Jan 2016 19:25:22 +0100 From: Aaron Zauner To: sneves@dei.uc.pt Message-ID: <20160101191936.62107c1c1c@f374df84e9aa7e5> References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> <20160101171630.15796qivr4d264xa@mail.dei.uc.pt> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20160101171630.15796qivr4d264xa@mail.dei.uc.pt> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 18:25:15 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * sneves@dei.uc.pt [01/01/2016 18:19:26] wrote: > The contention with GCM in this thread has been, so far, focused on > confidentiality. This is because, by a result of Bernstein [1] (see also > Appendix C of [2]), after q =3D 2^60 messages sent, plus q' =3D 2^60 atte= mpted > forgeries by an attacker with messages at most l_A =3D 2^16 blocks long, = the > probability of an attacker to forge a message is still ~2^-52. This does = not > present a data volume problem at the moment for the authentication part of > AES-GCM. >=20 Interesting - I was not aware of that. Thanks for taking the time to explain. > On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76 > total blocks), a block collision is almost guaranteed to have happened, > enabling the aforementioned forgeries. Sure. Would you see any way to improve this situation in the draft, i.e. give implementation recommendations or similar? > What you may be thinking of is the GCM behavior on _nonce reuse_. In this > case, we are able to recover the authentication key by root finding and > forge messages at will. This is also the case with OCB---on nonce reuse, = we > can forge any message that has the same checksum as a valid message. No. Nonce-reuse is a seperate issue, the one I addressed in my commit on the draft linked to in an earlier message. The construction used in the chacha20/poly1305 draft is very elegant I think: if you do not implement a proper nonce the implementation will not interoperate with other implementation conforming to spec. Thanks again, Aaron --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWhsSPAAoJEOTbZJL9ubXVyJIQALr8kSBdN8cY5TbAXboqvJFk zBSFcXqCDd3rEsNmp7YiKxpfrREYtoaaAeGKJjyNTLLP+lrLklTVkXcjvem7WLUj kNwMIgGOpz/KZGNxHm9hYspgO9i9it7ekamnu31999hd1EC+AhF1SqNW0mQOKdIU 2zTWHzo+pcbPTczygN6GdfbaXsap+bfDkv3RajTCdZK5czC8V2NrgvB8yl28CX17 fX03P1ISp4x4m++dbDhv5Y1gPStajgs75tBmafoKfUjowaA/uu+hYHm5+kFtrAKi Wir//UugdMvNXooe5D41u+PYC1uIVyM2ae9phmS1t1fzEx2HTVmKHSnvIPsUHAOw 73GNYc9yzDsd+GTiVqSALRlO5P5+qYBDpKseOxJgrJVNKLNJKXc1fsGh9eA+8pes gqh0lEheoU5lu7gpzlfRgQ70FjtBd6305vIOW//uCJw/ioeyqxosYTYlDedCcCKv aiSIBYmejZzNElS8w20+1o+Vph2Ci/pISWSe3zzBGB9NCcXd08TcmG0HXzYAllZ+ GnpwL103r7yCHB3nx1ZJ9bF2ZcBV73+j0Mj3LXnZ+r/REjH5i2EIUbDL2Ex423HN vEQPr0ug5g4KmayKDsyCARg0Mcx2y9AuTluwzyASpmFrNz9n7fXPim8qkUKAkh7T cTYts34eYbzLm9J/x2+V =tSoH -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From nobody Fri Jan 1 11:00:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704661ACE67 for ; Fri, 1 Jan 2016 11:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.289 X-Spam-Level: * X-Spam-Status: No, score=1.289 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 h2gbh-EVrQzD for ; Fri, 1 Jan 2016 11:00:51 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5A51ACE66 for ; Fri, 1 Jan 2016 11:00:50 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 0EF451E541; Fri, 1 Jan 2016 19:00:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1451674850; bh=UMVFeumEEMf6TsjI803eozgB7wZsdJGDCu6ZDO3Ejp0=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Hw5bVb/btaMaNFO+Pe2TVRXTPuz6BU0QkdxOiT56LUwn2S2kvkHnuWlaKLoKDeXqL NSigyr7zEcr/p/K+KcB5NqXC7zd9D/cjgP20Kzks6GwjHygvm8Gu3GGootCZdE64zk YtpdX+w82gcTA6+1uFyVg58Oo5aF1OmfHA+tnmms= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DE405100CD541; Fri, 1 Jan 2016 19:00:07 +0000 (UTC) From: James Cloos To: tls@ietf.org In-Reply-To: <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> (Ilari Liusvaara's message of "Fri, 1 Jan 2016 16:40:16 +0200") References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 01 Jan 2016 14:00:07 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:160101:tls@ietf.org::mhhSQCrguJ59i0xo:0000FBRLG Archived-At: Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 19:00:54 -0000 [Msg for followup picked at random from this thread -JimC] One thing we should remember on this thread is that it does not only apply to aes and its' 128-bit block size. Because TLS chose to create a NotQuiteChaCha rather than use ChaCha, its chacha20poly1305 also has a small data volume limit (2^40 bits; only twice aesgcm's limit). So key updates or re-keying will be more universally required. (Are there any aeads currently spec'ed with both large enough blocks and large enough nonces safely to avoid key updates?) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jan 1 11:04:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A8B1ACE70 for ; Fri, 1 Jan 2016 11:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgDdK0XOYq65 for ; Fri, 1 Jan 2016 11:04:49 -0800 (PST) Received: from smtp2.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC4B1ACE6F for ; Fri, 1 Jan 2016 11:04:48 -0800 (PST) Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp2.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01J4HpX007436; Fri, 1 Jan 2016 19:04:17 GMT Received: from mail.dei.uc.pt (localhost [127.0.0.1]) by mail.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u01J1xVr022054; Fri, 1 Jan 2016 19:01:59 GMT Received: (from daemon@localhost) by mail.dei.uc.pt (8.14.4/8.14.4/Submit) id u01J1xSR022053; Fri, 1 Jan 2016 19:01:59 GMT Received: from bl28-68-171.dsl.telepac.pt (bl28-68-171.dsl.telepac.pt [37.189.68.171]) by mail.dei.uc.pt (Horde Framework) with HTTP; Fri, 01 Jan 2016 19:01:59 +0000 Message-ID: <20160101190159.407028wg3fz8g10n@mail.dei.uc.pt> Date: Fri, 01 Jan 2016 19:01:59 +0000 From: Samuel Neves To: Aaron Zauner References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> <20160101171630.15796qivr4d264xa@mail.dei.uc.pt> <20160101191936.62107c1c1c@f374df84e9aa7e5> In-Reply-To: <20160101191936.62107c1c1c@f374df84e9aa7e5> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.8) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (smtp2.dei.uc.pt [193.137.203.234]); Fri, 01 Jan 2016 19:04:17 +0000 (WET) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: u01J4HpX007436 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-10.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 19:04:51 -0000 Quoting Aaron Zauner : >> On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76 >> total blocks), a block collision is almost guaranteed to have happened, >> enabling the aforementioned forgeries. > > Sure. Would you see any way to improve this situation in the draft, > i.e. give implementation recommendations or similar? > I think the FAQ you quoted before (itself quoting RFC 7253) suggesting the limitation of blocks processed to 2^48 is reasonable. Depending on the consensus here on what an acceptable success probability for an attacker is, you may want to bring that down to 2^32, as is being suggested for GCM. P.S.: Apologies. I had interpreted your diversion into OCB as suggesting it as an alternative to GCM to address the data volume limitation in question. On a second read, that turned out not to be the case, and you were only asking for help. From nobody Fri Jan 1 11:25:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B911ACE94 for ; Fri, 1 Jan 2016 11:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] autolearn=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 2oW06hKqKsBE for ; Fri, 1 Jan 2016 11:25:08 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146661ACE93 for ; Fri, 1 Jan 2016 11:25:08 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id k129so179461361yke.0 for ; Fri, 01 Jan 2016 11:25:08 -0800 (PST) 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:content-type; bh=6+UMxsyPZryEgsfIrc7RDrhbo17B2ky/kvNtnPv26XY=; b=GtvpewlBrjlPjpgVoonBXUkCvCUNi7nuxqXjmDC5wM5tEkV3MaiJY12aTdmAyooKt4 lYsLq8KK912uaTWFn3DP5O1sO67td8Y1pkfHIAHZ0gAU+UxsN+LynvpcLdNu5DWFxQ6m rmhZDlQwSWgCnBg25DVeM1aGmcXYvLwl95qfVse7LAF3tiQ/tUIM8VWSM/MVJueRAXoV pvDTO8/CovsEY6Q7XINVIklX04UdpMqOMFznvIEbHmT4nBZsh+S7FCkRJMnLLdoN4QrV T6asfK9+Uypmw89x7a4XWbDKGaLOvobHZ6al1P27SK14rDDF3PnJ65eU9DoKVeB2cfzt uI0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6+UMxsyPZryEgsfIrc7RDrhbo17B2ky/kvNtnPv26XY=; b=OfqJEABEdTV/JCnSqIPVKLU4n65wbyxAmy3akH5FZXa3EhL3gIAIukcI9F02CuvjXA EUv0PpOIp/JqHSFOpzW1fsxuCETxtV56tVDSLo1L8ZMCz5U6VfJEOSpobuqpFTm5S0p7 E299ZEGJiw5AgVEi6IanYuUWxXsE89DeoaRF/x6NHVlVdmD1gL4+9CX42zbhuGFf0Sts xXnuWP6O1CH7fCshAfehIM9/eDK1zTSfkw+pE+pFjmhN8C7xkK7ZLVLLgMn3qGE53crp curDhKftofGUOVfJsEDCG0PL+f9jE4nx7djGoYTSYeNnm8zKRJFwpM1/hQ/seP2g+LIO hZfw== X-Gm-Message-State: ALoCoQmD9ZUpHmM8LUlImbAr2eUgnF79B+Btns+nFTY4+z+KWEsLh+zJYjbYclxQg/b4nRHak702pBht7hrOijfHkSmGjcCODw== X-Received: by 10.129.46.208 with SMTP id u199mr55277414ywu.129.1451676307364; Fri, 01 Jan 2016 11:25:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 1 Jan 2016 11:24:27 -0800 (PST) In-Reply-To: References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 1 Jan 2016 11:24:27 -0800 Message-ID: To: James Cloos Content-Type: multipart/alternative; boundary=001a11408592a14ebf05284aba4f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 19:25:09 -0000 --001a11408592a14ebf05284aba4f Content-Type: text/plain; charset=UTF-8 On Fri, Jan 1, 2016 at 11:00 AM, James Cloos wrote: > [Msg for followup picked at random from this thread -JimC] > > One thing we should remember on this thread is that it does not only > apply to aes and its' 128-bit block size. > > Because TLS chose to create a NotQuiteChaCha rather than use ChaCha, > its chacha20poly1305 also has a small data volume limit (2^40 bits; > only twice aesgcm's limit). > Can you elaborate on this point a bit? I haven't been focusing on ChaCha, but we're not quite done with ChaCha yet, so if changes are needed, now would be the time. -Ekr > So key updates or re-keying will be more universally required. > > (Are there any aeads currently spec'ed with both large enough blocks and > large enough nonces safely to avoid key updates?) > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11408592a14ebf05284aba4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 1, 2016 at 11:00 AM, James Cloos <cloos@jhcloos.com>= ; wrote:
[Msg for followup picked = at random from this thread -JimC]

One thing we should remember on this thread is that it does not only
apply to aes and its' 128-bit block size.

Because TLS chose to create a NotQuiteChaCha rather than use ChaCha,
its chacha20poly1305 also has a small data volume limit (2^40 bits;
only twice aesgcm's limit).

Can you= elaborate on this point a bit? I haven't been focusing on ChaCha,
but we're not quite done with ChaCha yet, so if changes are neede= d, now would be
the time.

-Ekr


So key updates or re-keying will be more universally required.

(Are there any aeads currently spec'ed with both large enough blocks an= d
large enough nonces safely to avoid key updates?)

-JimC
--
James Cloos <cloos@jhcloos.com&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17ED7DAEA6

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

--001a11408592a14ebf05284aba4f-- From nobody Fri Jan 1 11:28:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDDE1A8A4C for ; Fri, 1 Jan 2016 11:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtzzuuPHfZnu for ; Fri, 1 Jan 2016 11:28:00 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFEE1A8A4A for ; Fri, 1 Jan 2016 11:28:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 72B0E23E; Fri, 1 Jan 2016 21:27:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id xZa3vFq4xSxr; Fri, 1 Jan 2016 21:27:59 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 15AB627D; Fri, 1 Jan 2016 21:27:59 +0200 (EET) Date: Fri, 1 Jan 2016 21:27:57 +0200 From: Ilari Liusvaara To: James Cloos Message-ID: <20160101192757.GA28560@LK-Perkele-V2.elisa-laajakaista.fi> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 19:28:02 -0000 On Fri, Jan 01, 2016 at 02:00:07PM -0500, James Cloos wrote: > [Msg for followup picked at random from this thread -JimC] > > One thing we should remember on this thread is that it does not only > apply to aes and its' 128-bit block size. > > Because TLS chose to create a NotQuiteChaCha rather than use ChaCha, > its chacha20poly1305 also has a small data volume limit (2^40 bits; > only twice aesgcm's limit). Huh? AFAIK, the limiting factor with Chacha20 as specced in TLS is the RSN space => 2^64 records maximum (which is 256ZB at max record size, and 352EB just to transmit the record overheads). Transferring just the 352EB at 1,000 Gbps would take about 100 years. -Ilari From nobody Fri Jan 1 16:45:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83091ADBFB for ; Fri, 1 Jan 2016 16:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t35jHiS7ZMnx for ; Fri, 1 Jan 2016 16:45:25 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF8A1ADBFE for ; Fri, 1 Jan 2016 16:45:25 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 53E6A1E541; Sat, 2 Jan 2016 00:45:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1451695525; bh=tqBrWMa+Ljazv4UQV2JCoZ7Nn1K9WWUpmdQ3pHyuIM0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FKafPI7JHJX5zGH1XF6s4IL1g8b3YO5W7w6D+9v3vsu4QX9oiUv5wZ/S0iPSpE84M N7Z2IQCHofDJp4igDZFbN6ldrxMw0MZ3dp8EPc8KsNWA+4pm/eNVI6eLiOgdBemiy5 BiLQCVUgCsmTk4JtmVTcMHV9Bz4HTbh7hvNRImzE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 6AA09100CD541; Sat, 2 Jan 2016 00:42:21 +0000 (UTC) From: James Cloos To: Eric Rescorla In-Reply-To: (Eric Rescorla's message of "Fri, 1 Jan 2016 11:24:27 -0800") References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 01 Jan 2016 19:42:21 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:160102:ekr@rtfm.com::w8B1T3xe/gKGzrQK:0000OHU77 X-Hashcash: 1:28:160102:"tls\@ietf.org"::RjhuUmL6caLn9Wpa:0VMdMP X-Hashcash: 1:28:160102:tls@ietf.org::6OQ2zpLdk0E+MOPi:0000E3iIN Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jan 2016 00:45:28 -0000 >>>>> "ER" == Eric Rescorla writes: ER> Can you elaborate on this point a bit? I haven't been focusing on ER> ChaCha, but we're not quite done with ChaCha yet, so if changes are ER> needed, now would be the time. The switch from 64 bit nonce + 64 bit counter to 96 bit nonce + 32 bit counter means a max of 2**32 * 256 bits before a key update is needed, yes? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jan 1 17:20:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532631B29D2 for ; Fri, 1 Jan 2016 17:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBes0Vo41QFF for ; Fri, 1 Jan 2016 17:20:44 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 DC0871B29D3 for ; Fri, 1 Jan 2016 17:20:43 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id v14so112080820ykd.3 for ; Fri, 01 Jan 2016 17:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Em7TltCAD+dpX9a5xERISZ7/Os1ebr/B3fMDPAEmw8=; b=BYfa0JLHYiJCw9qTFB4RsMguVYJhIxjMFOFWnam0EA5TUjQjN9GwpL092YEWQ+c7yB N43osTF2zV9DChAlPheNRZiBGdTe2AitfFJHfnRkiAW/1B5Z/8e0YJi9GVaRHtqdA0ZG yrwALUiUZgOp5oP//21/iZMSFoodFvfkBXl9ijQQ+GpSutYNVmq7/MCXoAVdAp0/lEYO wU/KsdLiBqmaqYis92CJWAWBPbpADZ+C6bO24dAYoQClWuy4bUHELlfRcwKvE45QMMMR a/y+DAr7ONWoV595Jwj3PhN/E4oVWkNYVNQaeZ86hSVy3OdElsjRKbtCPiVKxKiwKaWf 9LdQ== MIME-Version: 1.0 X-Received: by 10.129.29.14 with SMTP id d14mr50186992ywd.182.1451697643141; Fri, 01 Jan 2016 17:20:43 -0800 (PST) Received: by 10.13.216.150 with HTTP; Fri, 1 Jan 2016 17:20:42 -0800 (PST) In-Reply-To: References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 1 Jan 2016 20:20:42 -0500 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jan 2016 01:20:45 -0000 On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote: > Ilari Liusvaara wrote: >> >> OTOH, you can't drop an attacker knowing older key without doing >> new key exchange. > > > I think it would be very unfortunate to have the complexity of key update > (the new keys are derived from the old keys) without having the benefits of > rekeying (the new keys are independent of the old keys). What complexity? Sending a special packet with a different protocol that triggers a change in record layer state is not that tricky, and even DTLS is designed to handle this already. In fact one could even use the epoch number implicitly. What benefits? The concern isn't that an attacker obtains the key, but that confidentiality is lost. If we're worried about attackers who can read memory the answer is clear: write in a language that doesn't permit this. > > Note that NIST Special Publication 800-133 [1] defines these separate terms, > and I suggest we use them in this conversation to avoid confusion: > > Key update: A procedure in which a new cryptographic key is computed as a > function of the (old) cryptographic key that it will replace. > > Rekey: A procedure in which a new cryptographic key is generated in a manner > that is independent of the (old) cryptographic key that it will replace. > > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf. > > Cheers, > Brian > -- > https://briansmith.org/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Jan 1 18:04:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B3B1B2A11 for ; Fri, 1 Jan 2016 18:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 2__r5705_CO7 for ; Fri, 1 Jan 2016 18:03:58 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 1A51A1B2A10 for ; Fri, 1 Jan 2016 18:03:58 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id v14so112476316ykd.3 for ; Fri, 01 Jan 2016 18:03:58 -0800 (PST) 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:content-type; bh=hJUMHvIOHSAl159wlx//F32N4huGHk8ApcYGponiIxQ=; b=wIyYMl2n2G799YSDXGeQNkA7Zsf1u+c2zXWTZTzqV4C2nZ/0VLy1tNxfnJLszr8EZx 3LUZ6q6cnoCA8tnLtDWVHCs5t0i2wVOmJ3iTp+jEfKYD23tgbkW+9yQPJZ89k2Pchg6Z EXwjCkhKZWxTj+4bMx63A4mt30ccu//Z++1WvG6Qr4oGgjPOSxWlf9dll5qp3i6sJ8HJ ag9v4447+64JNptmGm18+hLxAZ34e3BnpL8zP+NuG/+d92Rf2O4sff6eqw9qhcf9vOAA Evp4/KGpMHyF/fgFixjwTfkzDm5b6ZFXaYiHCgfCUPbrcgqSyOJBa+I/OTDkr7Lk4yJb 9HoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hJUMHvIOHSAl159wlx//F32N4huGHk8ApcYGponiIxQ=; b=cUJ4nDv/LxKDyt7Ug6yXfd5rsy7kH2vNvvq8mGjKHhVG6OPg5SNunf2sj0Dq6dvRKj p/lHSOTVmKHUY70v9cvVqjOWla8Oe8UUA5XR74Yl0zgssoNmASzYCc5EsPzi0ZbUKzH9 FTQJ1QiyGhuD5VkzyJAmZjq6/s6TP3eqzQ/I02ScJioEvzgJouxkvV9P5FPu1Pge6X/V /Xgj3fjC15XnVUXXWEGbhnJj3qI9aS/NSNMGEwBXhyZPovSDOY6hhwh/VHnvoHwHoWxn FicU2AnpFZEFgsayrhNLH1C885HDjP+lQn9Ys0NjSu4gWMKsgvHvsqFF+xmZKvLYz3MK Jh9Q== X-Gm-Message-State: ALoCoQlSixK3x+p/pOy8eUyFdAhosWuB2ZrYAVVZhA9Zu1QVlC4AJ7P74XWgMcNLvhFmBSNqBdIxU0QCPRPZ2cOlwYs4y1OCTQ== X-Received: by 10.129.153.3 with SMTP id q3mr64313660ywg.231.1451700234179; Fri, 01 Jan 2016 18:03:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 1 Jan 2016 18:03:14 -0800 (PST) In-Reply-To: References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 1 Jan 2016 18:03:14 -0800 Message-ID: To: James Cloos Content-Type: multipart/alternative; boundary=94eb2c0bbfaec78ba60528504cc2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jan 2016 02:03:59 -0000 --94eb2c0bbfaec78ba60528504cc2 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 1, 2016 at 4:42 PM, James Cloos wrote: > >>>>> "ER" == Eric Rescorla writes: > > ER> Can you elaborate on this point a bit? I haven't been focusing on > ER> ChaCha, but we're not quite done with ChaCha yet, so if changes are > ER> needed, now would be the time. > > The switch from 64 bit nonce + 64 bit counter to 96 bit nonce + 32 bit > counter means a max of 2**32 * 256 bits before a key update is needed, yes? This doesn't sound right to me. In TLS, we use a distinct nonce for each record and then a block counter inside the record. So, it's true that you couldn't encrypt a record that was more than 2^{32} * 256 bits long, but since TLS records can't be more than 16KB long anyway, this isn't the critical limitation. -Ekr --94eb2c0bbfaec78ba60528504cc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 1, 2016 at 4:42 PM, James Cloos <cloos@jhcloos.com> = wrote:
>>>>> "ER"= ; =3D=3D Eric Rescorla <ekr@rtfm.com= > writes:

ER> Can you elaborate on this point a bit? I haven't been focusing o= n
ER> ChaCha, but we're not quite done with ChaCha yet, so if changes = are
ER> needed, now would be the time.

The switch from 64 bit nonce + 64 bit counter to 96 bit nonce + 32 bit
counter means a max of 2**32 * 256 bits before a key update is needed, yes?=

This doesn't sound right to me.
<= div>
In TLS, we use a distinct nonce for each record and then= a block counter
inside the record. So, it's true that you co= uldn't encrypt a record that
was more than 2^{32} * 256 bits = long, but since TLS records can't be
more than 16KB long anyw= ay, this isn't the critical limitation.

-Ekr


--94eb2c0bbfaec78ba60528504cc2-- From nobody Sat Jan 2 08:20:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AC91A03A1 for ; Sat, 2 Jan 2016 08:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI6DOo0xqpbZ for ; Sat, 2 Jan 2016 08:20:29 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB7E1A03A0 for ; Sat, 2 Jan 2016 08:20:29 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id C37771E541; Sat, 2 Jan 2016 16:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1451751628; bh=EYmqFHAplDhTcaRrIUBOG2Zfar9zNEpGFe4LurjkZxc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=m23OhK/HAFRs+KJ1urF1megNpElSUlN7goJFSHerJsdKMFq2HV1p2x3lC3JeLCJ43 DbwuPnCIkgDF7Z+uZHdpn3qtftytd4b8bqMDLgEE5pFL5/de/plyxyKWpL5s/ziZ0u yZBsqJlghw/EmoWUhkypN5V+Sy+v4ZBfBl+PiO3A= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 851E1100CD541; Sat, 2 Jan 2016 16:19:11 +0000 (UTC) From: James Cloos To: Eric Rescorla In-Reply-To: (Eric Rescorla's message of "Fri, 1 Jan 2016 18:03:14 -0800") References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568676E8.6090802@streamsec.se> <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 02 Jan 2016 11:19:11 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:160102:ekr@rtfm.com::4GewseNqMsMLRtfF:0000CxOtR X-Hashcash: 1:28:160102:"tls\@ietf.org"::C7dqky2neZJHb/vN:03sph7 X-Hashcash: 1:28:160102:tls@ietf.org::LXFpc2uZfq65ILu/:0000C8Iq1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jan 2016 16:20:32 -0000 >>>>> "ER" == Eric Rescorla writes: ER> In TLS, we use a distinct nonce for each record and then a block counter ER> inside the record. So, it's true that you couldn't encrypt a record that ER> was more than 2^{32} * 256 bits long, but since TLS records can't be ER> more than 16KB long anyway, this isn't the critical limitation. That does change things. I do not recall any posts noting that after I posted an objection to the change, but I mostly missed everything from May thru July or so because of the stroke... Thanks for the correction. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jan 4 04:00:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F2E1A1ACA for ; Mon, 4 Jan 2016 04:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiVLR8I9Wl_7 for ; Mon, 4 Jan 2016 04:00:01 -0800 (PST) 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 F1B241A1A72 for ; Mon, 4 Jan 2016 04:00:00 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 66C3D42E5C8 for ; Mon, 4 Jan 2016 12:00:00 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04Bxwo0012418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 06:59:59 -0500 From: Hubert Kario To: Florian Weimer Date: Mon, 04 Jan 2016 12:59:53 +0100 Message-ID: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <568196AA.4040100@redhat.com> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568196AA.4040100@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2846276.v47S9rN5B6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:00:02 -0000 --nextPart2846276.v47S9rN5B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 28 December 2015 21:08:10 Florian Weimer wrote: > On 12/21/2015 01:41 PM, Hubert Kario wrote: > > if the rekey doesn't allow the application to change authentication= > > tokens (as it now stands), then rekey is much more secure than > > renegotiation was in TLS <=3D 1.2 >=20 > You still have the added complexity that during rekey, you need to > temporarily switch from mere sending or receiving to at least > half-duplex interaction. this situation already happens in initial handshake so the=20 implementation needs to support that I don't see how rekey adds complexity here... =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2846276.v47S9rN5B6 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 iQIcBAABCgAGBQJWil65AAoJEJKo0bgB0vX1DuEQAJoP+sCLaW1qrD1gHlTXn1Ov 8ujChBI8EsHWpuE4hcL7EgY1+inkvA/81sCj6EJqpYMgoaDfN1bRQXXUQsYBG2lo GtoXRDYZ5uz98PaAa4gsQ+JViu2WbcTZFDvYsZGPpRFiEuVwBdYjVNgLuntIRLK1 UoJvIMy2mxODrb8LUrkLJJLBxnvL6jNIZvTsE8zKeEbuXFu06eXvRvIf9+htx0YA oE8rvSW1Oo16k30wqKPpmD/DzMjShsHGey6DRHbFAsiCXXrqiEBBafJGu/lAHpwu nymb9z8q7BKCRDBIB5Cc7MgBMlTB1kPjG9CD2Qg3H5WwXp7k/+w6vhgxKIE8mUFW idYoRxsKugX14sHE7DJk18nQCSfSqUKOptcyZps4aTU9ItmOm+YySZqdudSzkznY +cb0SOBjLmRPP8flLyzR1B8jWKIpXnpOIpmy/stEGDQuAdlD7dsR6eEx2yE0aP+/ sTFL2CC6OcwJ2whXtHg73h3L85I6hVCJG2IGOEkdpUwGv9YMtDd3100oIYm9Xw39 WQ18bgeOF1G8DKcS2j4vMIRNU/7TcMM6aYQQa74gzTv7iCMjPlbifP0A6/5igsc2 oEHipVk+FpX9SKlItKXnpflN8e0hta28WnxfDawGUZvbqG925wiYToHv2cJTDeno URiPFhpmpnkVtP71FXJa =nosr -----END PGP SIGNATURE----- --nextPart2846276.v47S9rN5B6-- From nobody Mon Jan 4 04:03:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1B71A1EE8 for ; Mon, 4 Jan 2016 04:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-hChIpp5jlz for ; Mon, 4 Jan 2016 04:02:59 -0800 (PST) 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 96B4F1A1BF6 for ; Mon, 4 Jan 2016 04:02:59 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 662F18E763 for ; Mon, 4 Jan 2016 12:02:59 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04C2vtA002412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 07:02:58 -0500 To: Hubert Kario References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568196AA.4040100@redhat.com> <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> From: Florian Weimer Message-ID: <568A5F71.9040002@redhat.com> Date: Mon, 4 Jan 2016 13:02:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:03:00 -0000 On 01/04/2016 12:59 PM, Hubert Kario wrote: > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: >> On 12/21/2015 01:41 PM, Hubert Kario wrote: >>> if the rekey doesn't allow the application to change authentication >>> tokens (as it now stands), then rekey is much more secure than >>> renegotiation was in TLS <= 1.2 >> >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. > > this situation already happens in initial handshake so the > implementation needs to support that But after and the handshake and without real re-key, sending and receiving operations exactly match what the application requests. If you need to switch directions against the application's wishes, you end up with an API like OpenJDK's SSLEngine (or a callback variant which is equivalent in complexity). Dealing with this during the initial handshake is fine. But supporting direction-switching after that is *really* difficult. Florian From nobody Mon Jan 4 04:13:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C071A874D for ; Mon, 4 Jan 2016 04:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyS4XicQb5SO for ; Mon, 4 Jan 2016 04:13:51 -0800 (PST) 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 82B901A8711 for ; Mon, 4 Jan 2016 04:13:51 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 10941C00330F; Mon, 4 Jan 2016 12:13:51 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04CDmmu020051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 07:13:50 -0500 To: "Salz, Rich" , "Blumenthal, Uri - 0553 - MITLL" , Eric Rescorla References: <20151228205101.17780804.92503.42669@ll.mit.edu> <054fc579d2fa41dfa03ad8366bb3c02b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Florian Weimer X-Enigmail-Draft-Status: N1110 Message-ID: <568A61FC.7040708@redhat.com> Date: Mon, 4 Jan 2016 13:13:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <054fc579d2fa41dfa03ad8366bb3c02b@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:13:52 -0000 On 12/28/2015 10:09 PM, Salz, Rich wrote: >> When the key is changed, the change procedure should involve new randomness. > > I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not a cryptographer, maybe one of the ones on this list can chime in. > > "Crank the KDF" suffices. The attacks against GCM are at the stage where even “periodically increment the key by one“ would thwart them, right? The risk is that without real re-key (introducing additional randomness), someone might come up with a better attack that reduces the security level below the design target, and which requires similar effort as the existing GCM attack (four years of traffic at terabit speed, it seems). Real re-key is difficult to introduce as an afterthought (see my recent response to Hubert), and I'd rather see such issues fixed at the cipher level if at all possible. The current update-key mechanism doesn't have the complexity issue of real re-key, but it's ambiguous if it's a design goal to paper over cipher deficiencies in the rest of the protocol. Florian From nobody Mon Jan 4 04:19:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097EE1A8828 for ; Mon, 4 Jan 2016 04:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcoYkIWzu98P for ; Mon, 4 Jan 2016 04:19:47 -0800 (PST) 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 0BBF41A8827 for ; Mon, 4 Jan 2016 04:19:47 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id CF203C0467FF for ; Mon, 4 Jan 2016 12:19:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04CJjSe011873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 07:19:46 -0500 From: Hubert Kario To: Florian Weimer Date: Mon, 04 Jan 2016 13:19:44 +0100 Message-ID: <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <568A5F71.9040002@redhat.com> References: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> <568A5F71.9040002@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2992437.DLhpOxrDri"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:19:48 -0000 --nextPart2992437.DLhpOxrDri Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 04 January 2016 13:02:57 Florian Weimer wrote: > On 01/04/2016 12:59 PM, Hubert Kario wrote: > > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: > >> On 12/21/2015 01:41 PM, Hubert Kario wrote: > >>> if the rekey doesn't allow the application to change > >>> authentication > >>> tokens (as it now stands), then rekey is much more secure than > >>> renegotiation was in TLS <=3D 1.2 > >>=20 > >> You still have the added complexity that during rekey, you need to= > >> temporarily switch from mere sending or receiving to at least > >> half-duplex interaction. > >=20 > > this situation already happens in initial handshake so the > > implementation needs to support that >=20 > But after and the handshake and without real re-key, sending and > receiving operations exactly match what the application requests. If= > you need to switch directions against the application's wishes, you > end up with an API like OpenJDK's SSLEngine (or a callback variant > which is equivalent in complexity). for renegotiation, yes but for rekey it doesn't need any input from application so there is no= =20 need for any callbacks =20 > Dealing with this during the initial handshake is fine. But > supporting direction-switching after that is *really* difficult. yes, this is a bit more problematic, especially for one-sided transfers= .=20 For example, when one side is just sending a multi-gigabyte transfer as= =20 a reply to a single command - there may be megabytes transferred before= =20 the other side reads our request for rekey and then our "CCS" message I thought you just meant the need to keep two cipher contexts in memory= =20 at the same time (current and currently negotiated). =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2992437.DLhpOxrDri 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 iQIcBAABCgAGBQJWimNgAAoJEJKo0bgB0vX161UQAIBWjGwRDpiJvCY4JWUCBZKL wMTmiwQ9KOgbNtfXqvCgt136p1GIP42eOjZvJSVayNQHOYhHcEOBTtGgbzJdcIWm W02bEMzg61LfJI3Ah35vRM0LiQqnA57ENF8vaWxmILTqwI2iHs32EWgteuxUYfiP yCut/FMt4dt2rkq9MfflJoquyfsXPaVqwtHllCHrtSjflP7YNvU0mKrVUd8Klg3v CutQS6TXmxpfZRPlVB7bo4r7nxTgnHMdyYf4rlBUIn6zNdv4Sjd9EwSb6fOIH9i0 Crqob3nMaNbpQFEXK/j6vqUg72K8xkrFnY5/hySSa2dOXnjKoeZIUVkAE6Iua7oS 4ATYYUL8KJzy6cnql1R9BNN8bVTgvOTMYmubslXE29OL4Yj7m9BBV03N+1K+Dei/ V7oyBdTsu01BvASb8roLpW80CIjiOPBBmyGset5+LWa0tajRc0ebLOkYvw3odPUT 74ofEscrT5EnffmWTjawXS+6h2w4l420b8pg0s3kyh1ww1jq64G87DDuWCugCDkV zb8OHwyhmqC/kY2tdxUAHbj61vM7rbJg5rl8jTV20kYK2CJsEJDvHK/8H9+ePX1B V+d2dAmFmYbxlR4a5k+T4IsyuPwnK9yVkoYbndsgZQMbSM4dk0uRe8M9SaRZ9iRm jGNUmAMjEkP2gpby7idT =7Vxp -----END PGP SIGNATURE----- --nextPart2992437.DLhpOxrDri-- From nobody Mon Jan 4 04:22:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E951A0395 for ; Mon, 4 Jan 2016 04:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoUHi3fy2Q0E for ; Mon, 4 Jan 2016 04:22:17 -0800 (PST) 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 906A11A0383 for ; Mon, 4 Jan 2016 04:22:17 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5E594C109087 for ; Mon, 4 Jan 2016 12:22:17 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04CMFJt004756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 07:22:16 -0500 To: Hubert Kario References: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> <568A5F71.9040002@redhat.com> <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> From: Florian Weimer Message-ID: <568A63F7.10307@redhat.com> Date: Mon, 4 Jan 2016 13:22:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:22:18 -0000 On 01/04/2016 01:19 PM, Hubert Kario wrote: >> Dealing with this during the initial handshake is fine. But >> supporting direction-switching after that is *really* difficult. > > yes, this is a bit more problematic, especially for one-sided transfers. > For example, when one side is just sending a multi-gigabyte transfer as > a reply to a single command - there may be megabytes transferred before > the other side reads our request for rekey and then our "CCS" message Yes, this is the issue I meant. I simply don't see a way to re-inject new randomness without a round-trip. (Key update without new randomness doesn't face this challenge, but then it's mostly cheating.) Florian From nobody Mon Jan 4 07:46:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0902E1A89E0 for ; Mon, 4 Jan 2016 07:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7xrrUsiiBJ6 for ; Mon, 4 Jan 2016 07:45:58 -0800 (PST) Received: from nm17-vm3.bullet.mail.ne1.yahoo.com (nm17-vm3.bullet.mail.ne1.yahoo.com [98.138.91.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA231A89C7 for ; Mon, 4 Jan 2016 07:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1451922357; bh=r8UXPYyTYO2SyjdfIP6BmCiOI+z1TgHqNN6r2bDxB2k=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Q/V6Pv/wYRhiftpMUpbGC9PmGaObaVAcV2SbC2CRV1I/a2HB5BjERIWMWBWlI9mWFKmiIiMpecAodwET9/CQxZQXG5qMTvwcaeZUMpxGM3KHZIE02Oq3MYVyF40+kdO9rDM0oT/TGkjRtBKbLACV5MDB0b9KT5tchdRtN357xqfGrk7lESP99/mfOqOS8GGCMspKQmzhPXCYIpo7FBPr6w7pPNaTGzyAOvv7THXK3qxD2OtPvBc3/lmuzV3BDE6TcJSQ9K0dsqXJ+/1ThtHyd+YbX0gmiBP7lFcnThTpaLrizqlQp5vqaBwXXspsKWPn3ZuyEYEfytcwpoFlqT1Y5Q== Received: from [98.138.100.117] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:45:57 -0000 Received: from [98.138.86.156] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:45:57 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:45:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 290198.76711.bm@omp1014.mail.ne1.yahoo.com X-YMail-OSG: IG_fO3QVM1kJ7E39o3k_a6eimM367aOy_3Iz9o_ys1Dt07BEK0Xlh6SG8DhDwsK G6sPRJlOmMrfBpyTtstT61tXDo0_CKEx4dTCUBLlABSqhib4yJhynhDYcY7M3HIQM5GJx6Jrx9b7 6cYpDu3fpl9TZ3b2YlC6SqVn9TYvJb5etwDzcvmH6PrNZpo4t.FvvL0edUCvuU4Yjhy.XpjrIa6h 0xtzt7P7Yd.nzxdqzfarDUvUoyEJkKGthBvSS4Y0vLKINqUy7ByQ0IsoMr2QTLGd23nTWtKXemyj 1phThJxvSpoW.fuKY_tk3zWXgdWo4V9vzLneOaeUKYSfWKbeCg9_39B0m.LnLmQHD.TYp7gFT.42 vYkxm5qz_esYyuAQ5JmP3rVjbgGqkUGEYUby28ZkKcSap9O3nEBKW6hRRHFMfMIkuXUdNOT0XFzH cPQedKwn3rjcQoEOFJev.yqo9HBE1fJJuG7xy20NjFc3fjRpriHBuxvXIhUBvHk5oABLvVK09lqU 43aGvFXIfAFU5AIm.HjtnzZt5RyS9lO2NKfHWolOIg_I4KB6LCiw7DAAQIKgTvJesnNNzCnk- Received: by 98.138.105.206; Mon, 04 Jan 2016 15:45:56 +0000 Date: Mon, 4 Jan 2016 15:45:56 +0000 (UTC) From: To: IETF TLS Message-ID: <1646739694.494868.1451922356384.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20151231214704.GA24931@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231214704.GA24931@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "This is the mailing list 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 Jan 2016 15:45:59 -0000 Hello All, Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. Section 5 of draft-ietf-tls-tls13-11 reads: "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." Then continues with: "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an "unexpected_message" alert." In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Mon Jan 4 07:52:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0427C1A898C for ; Mon, 4 Jan 2016 07:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEEXRcP2INTx for ; Mon, 4 Jan 2016 07:52:18 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 692021A1B69 for ; Mon, 4 Jan 2016 07:52:18 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id k129so229048912yke.0 for ; Mon, 04 Jan 2016 07:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJVF3P59NLjT2Jvyc38AXkmfrRPRp5mkBvghM6bjoME=; b=S6WNAuIXXI5jHgEeM9sGaKlYLCv2i7ELLSNFKI/PfoE//7ei2LD03jb3w8uYLQiib8 x4vbIXSJPswVF/nVnKWQtmgr9nQYt5uj55xqAQMl7bxZXPlOyF/3kjMrrTcWVttO3cv+ AvxEaW/L3ADfFV0jFLo1g2jLLYZbUEuiip3JTD5LMlVqfPvX45Coo8F778IGqXVonrnt jv+tFmKU13vu8SmtneCf10nWD/UVt6Q5fE4YGj1c4432VnC3/eKPmTmSIGTmMdcT+X1s njqnaKdvLjUNr4G+1pyG6vM+7uSCldrkq1HvLW2/JS4Ny/o4oiSydTp8Fbg7XfnnRShN /1tw== MIME-Version: 1.0 X-Received: by 10.13.213.215 with SMTP id x206mr65322267ywd.97.1451922737650; Mon, 04 Jan 2016 07:52:17 -0800 (PST) Received: by 10.13.216.150 with HTTP; Mon, 4 Jan 2016 07:52:17 -0800 (PST) In-Reply-To: <1646739694.494868.1451922356384.JavaMail.yahoo@mail.yahoo.com> References: <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231214704.GA24931@LK-Perkele-V2.elisa-laajakaista.fi> <1646739694.494868.1451922356384.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 4 Jan 2016 07:52:17 -0800 Message-ID: From: Watson Ladd To: nalini.elkins@insidethestack.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 15:52:21 -0000 On Mon, Jan 4, 2016 at 7:45 AM, wrote: > Hello All, > > Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. > > Section 5 of draft-ietf-tls-tls13-11 reads: > > "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." > > Then continues with: > > "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an > "unexpected_message" alert." > > In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? TCP Keep Alive is invisible to the TLS connection. > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 4 07:59:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD01A8A06 for ; Mon, 4 Jan 2016 07:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjiL09sbe9Qt for ; Mon, 4 Jan 2016 07:59:56 -0800 (PST) Received: from nm19-vm5.bullet.mail.ne1.yahoo.com (nm19-vm5.bullet.mail.ne1.yahoo.com [98.138.91.241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B3F1A89FD for ; Mon, 4 Jan 2016 07:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1451923196; bh=IB9Z7j5o9XRo4LdxPkog3bd0SiRtWDf07PDexN9cXw0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SxLWxxo8YTObKOFyrfauEgNBlakSWMicbSIPrzuZeOgJZnpwHer4sQeqdKHKfCrzhkvDbqxh7X98S3dnW4XUhQFwjxyj5GVGowu9JhNbrsjcIJXuTx7+QCeB1BQZ6cMgv2LEIJ0a4lfGaxNfJwvjcHb+a2FX/syrp/YAJHC1f6TGjz7jJtQkQh9ow0Da5kg7wTR521J5lOv+rIB+DTvlt+fArG4TaXLPc0mB/tqgXbBUYFFuL82JBl/7tn1f6QReXxQUw+WJ3KqCEYYY+G+347gRmeerim+RXiWnjSJ7J+JLAnlB6p7N1g+jii7Gsd7uzMWyrIXgTAtFzmxFHsqmRQ== Received: from [98.138.101.130] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:59:56 -0000 Received: from [98.138.89.192] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:59:56 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 15:59:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189734.60932.bm@omp1050.mail.ne1.yahoo.com X-YMail-OSG: hAZKNEQVM1meL.B2ly4NZw9QUR_4AKdSuHpjBvUu0HUv0JvDgwiwIIUgC5XQp.9 SG9craEMgn7GCxBZOte9f9zXqbeLGN55vwNaPebmnXM4V1mx.kdketH9TPduURfCgnup18WJjfqL L4qAiW0tYurcM8vdEV6xCq_IP2l..JlzSwOB2ZeYBLUTrM2TgAt9ZA1kahKJAZ1lNlC58fp_Rskr _PMIJ.MY60AiNVflSUtKoHBOk2bqxV1jd0UkREMp_VfUi11NtFMf1oW4Uo3C4sWaLw8rTfpdRQBN YcX_qlMQc8UpaRh4uzOZkMn3.sWJWqs1O8Wnh.hgeDJmN56mEVAnQXGt.s..E2mwb5t9Oqq3eLR8 Lp1qKpr7OI84oX5wfyf6MM6miuXZyMYzDuXF23cxGPdXV1.fl0OKisZZQ6su3eKOb6HKc.XUxn7x i_PjiI9KBFcpwsbHkb61FjjUejw_thLAQbv3UBR.4ySAWqBAYxogvqlJ4e0NM3kN909w95VfPP.x ECYrrvn2TeJcBbiqdWAY8hRV_D4paGtCFV_j9GePbWzo0klyWVfSbMoPHVg-- Received: by 98.138.105.220; Mon, 04 Jan 2016 15:59:55 +0000 Date: Mon, 4 Jan 2016 15:59:55 +0000 (UTC) From: To: Watson Ladd Message-ID: <652841533.487342.1451923195258.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "This is the mailing list 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 Jan 2016 15:59:58 -0000 On Mon, Jan 4, 2016 at 7:45 AM, wrote: >> Hello All, >> >> Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. >> >> Section 5 of draft-ietf-tls-tls13-11 reads: >> >> "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." >> >> Then continues with: >> >> "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an >> "unexpected_message" alert." >> >> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? >TCP Keep Alive is invisible to the TLS connection. I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described? Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS? > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 4 08:31:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B031A8A50 for ; Mon, 4 Jan 2016 08:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=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 E0sAtu5PeiCj for ; Mon, 4 Jan 2016 08:31:55 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 B8BD01A8A47 for ; Mon, 4 Jan 2016 08:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1451925111; l=1628; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=G/Zx2yJwbsNSNBMfOPyz5Sqlznrwt3RE3A77UA14+eM=; b=kxulbYpfcJhAjNYkd2rcj6BQpjhY/DRgUkk8JKqHrzT5We8DiNG7gIQV66KeNJMhWWq IbDh/7Whzl2uEjmTMicHvu0FikEUtgHtHcG8Xj7K0FAD6Cr7LkH0ITpjbgateNRdYUuGc K5XBJOM+NesxqfObT/26inYthHDTF0fMd30= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIm+dxs6P4z8eYGLHQraBl7TqcmA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:992c:b672:6189:fcc5] ([2001:4dd0:ff67:0:992c:b672:6189:fcc5]) by smtp.strato.de (RZmta 37.15 AUTH) with ESMTPSA id v04828s04GVooy5 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Mon, 4 Jan 2016 17:31:50 +0100 (CET) To: tls@ietf.org References: <652841533.487342.1451923195258.JavaMail.yahoo@mail.yahoo.com> From: Roland Zink Message-ID: <568A9E83.8050502@zinks.de> Date: Mon, 4 Jan 2016 17:32:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <652841533.487342.1451923195258.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:31:57 -0000 TCP keep alives are handled by the TCP stack and not given to TLS or as Watson said invisible to TLS. Roland Am 04.01.2016 um 16:59 schrieb nalini.elkins@insidethestack.com: > > On Mon, Jan 4, 2016 at 7:45 AM, wrote: >>> Hello All, >>> >>> Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. >>> >>> Section 5 of draft-ietf-tls-tls13-11 reads: >>> >>> "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." >>> >>> Then continues with: >>> >>> "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an >>> "unexpected_message" alert." >>> >>> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? >> TCP Keep Alive is invisible to the TLS connection. > I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described? > > Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS? > > > >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> www.insidethestack.com >> (831) 659-8360 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Mon Jan 4 08:44:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0C1A8A7B for ; Mon, 4 Jan 2016 08:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QTVjzD69i-4 for ; Mon, 4 Jan 2016 08:44:27 -0800 (PST) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC59C1A8A6D for ; Mon, 4 Jan 2016 08:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1451925867; bh=2QnU+OUbZaLo8htps00jRxjin6rXUK+yxBRiHxRR0e8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=BvM0qzYOvXJTUgxUKH0+WCOp6/hML1oNvYeeepdrkuxTZ9p9MvaQD2d02cKCS/uc67KnOjBLIj4NwI8M+RBy7pIDFHbj7N5k3u6WxbHKItviZl0a5NYQcwqWUTF9LgM/PQZfjHRYvxK8aVHaa7eKVVWgOEzza3IMfGDKOvlwlG3tSDiq/EVqf+D8aLu07rLcS+yhuX8WUBGUvPJxRb3sFWq2akwilNS0TLclNke/jATAmLDQF/3ImUPnYK7weeA5DJyVq3IVa1AXyWvam98CkBHsc1K0wrO2LZ01FczznGZRGN7/vtRryAe6+GUWN+gkw/ZayLnHAIbZKDpFJIEY+Q== Received: from [98.138.101.128] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 16:44:27 -0000 Received: from [98.138.89.199] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 16:44:27 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 04 Jan 2016 16:44:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 88260.28802.bm@omp1057.mail.ne1.yahoo.com X-YMail-OSG: Z9vwf3cVM1mFCRFseLiQOFOASl8aDIRp6Jyw0eJtZUomEIMakuDFzrzeH96j9vl .Uz_QCrSnIjU6rcrD36knLy4vB1CuXrJX1K2A1llVEewUJmLGxRqfUIo780QYfbT.WmPwnYJh0C9 OhHw8W6uIbaVTkzX731NHD4sz1FcYAgWQ0b1gbjxMOKiXGQBDflpZsKfs4hm.09V2GZsqml5lHOK uZu.MeCqirK7PEn8MKkPcutYHSreOTY56Wr7XPqrcMsr1aqTNug.cP6WqXDQQY1DPKbHela6hCJ7 pgRKcayOxHUV17iXv3sQVeF7k_wvfZEBZbIkn_2jtf9fiFVPZ93Y5uahmVKLLa9ImMO2iya17fU9 Gp0fcoyHtS6XJa1yNoTse29nRbFiHwbfYX9.cfSLD.vVflB3gfwW5jhHGvKBgmY11ZPo95Q5bycy 1o25JwDTynheJWb2jEUqCb8xwATGC3lIKBaGPVzc.YrGFIMRKEti0lCvNWbwaf55YjlEOlSX55CD typ9lz10YbRzVu2asD2xgLc5tpXPWJki2g7qm0nnBFYU_9.Ti6yc3mFOHRA-- Received: by 98.138.101.176; Mon, 04 Jan 2016 16:44:26 +0000 Date: Mon, 4 Jan 2016 16:44:26 +0000 (UTC) From: To: Roland Zink , "tls@ietf.org" Message-ID: <1317549572.504472.1451925866126.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <568A9E83.8050502@zinks.de> References: <568A9E83.8050502@zinks.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "This is the mailing list 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 Jan 2016 16:44:30 -0000 Thank you all for your help. Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: Roland Zink To: tls@ietf.org Sent: Monday, January 4, 2016 8:32 AM Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 TCP keep alives are handled by the TCP stack and not given to TLS or as Watson said invisible to TLS. Roland Am 04.01.2016 um 16:59 schrieb nalini.elkins@insidethestack.com: > > On Mon, Jan 4, 2016 at 7:45 AM, wrote: >>> Hello All, >>> >>> Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. >>> >>> Section 5 of draft-ietf-tls-tls13-11 reads: >>> >>> "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." >>> >>> Then continues with: >>> >>> "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an >>> "unexpected_message" alert." >>> >>> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? >> TCP Keep Alive is invisible to the TLS connection. > I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described? > > Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS? > > > >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> www.insidethestack.com >> (831) 659-8360 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jan 4 09:22:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25ACD1A8BB1 for ; Mon, 4 Jan 2016 09:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1I5M5W_HL8O for ; Mon, 4 Jan 2016 09:22:11 -0800 (PST) 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 CDAE11A8BAF for ; Mon, 4 Jan 2016 09:22:11 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6ADBCC109083; Mon, 4 Jan 2016 17:22:11 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04HM91m013567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 12:22:11 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 04 Jan 2016 18:22:09 +0100 Message-ID: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3127394.K0HvgcMGsj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:22:13 -0000 --nextPart3127394.K0HvgcMGsj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byt= e > >> for the "label"?>=20 > > No. I wonder if we should instead add the '\0' explicitly in the > > 4.8.1 for maximal clarity. > Either that, or just remove the trailing 00 from the binary > description. the 0-byte is a C-ism that looks like a wart to me neither of the previous TLS versions used null-terminated C-style=20 strings so why TLS1.3 should? Especially in just one 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 99/71, 612 45, Brno, Czech Republi= c --nextPart3127394.K0HvgcMGsj 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 iQIcBAABCgAGBQJWiqpBAAoJEJKo0bgB0vX1CuoQAJdkrCNn0rG2dFEGE01cRNjb cfEWfvhng2J3581mH/8zSwWOJrxxEk8OQk+60uAvkcchbvOezOnHADPk52xZEZtW msT3fS3PS8DL8E7KE0XIS71C8u1DcRF5XPyPFMls+gSYxxGKyz10yGR/yMGh1xYp jDVj0i3k/nzfrCkFEwW51aFyUctKdvgH+zz/0ApWijVOwWUfgr21DKhOdIO0a4Pl adFYZx9fS0YN0TnBPKGePWhfPWPOYBCzueFgmtjGc86pPN+cA48oP8XZGNzweiSR OzXv+onFcWtkDfzylE542yDNgge2AjoCAHTFzxqQSOUVH/8i3wqxDVEwIlZI/LrM w5arV8k2Wzc+82+lNAv0dEuZhFvNrRNwlF4HJpCl7zwWLFnE0a5SHU2ycjnXRies JJQCXNsjcyg+13rKXuBa2PS9xWVkiEJgQ4AU1QGeEuAVt8Z7kUELkCnkde2phy2Z NZGZ/iw3DxWJgpbwU1Ztj2Q8Vp5KHXZkkepyzgdikj4dXZlQhFWdUkXraEB6ryRJ cj57x/KGtYNXhhqmLG5QGdDVT0tuqF5EDI9uhy8cnZGVofGdaMgWc6Wc0x/vJu6U BhjmbP+yF/UQZLRzsdLLu0Dmnypu4NnFH+JAYXD22U27s9IJg7xqdS9h2CM5uL4J o6vMeGRyCmPM9r6mUFhf =RwmD -----END PGP SIGNATURE----- --nextPart3127394.K0HvgcMGsj-- From nobody Mon Jan 4 09:45:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73B1A900A for ; Mon, 4 Jan 2016 09:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 aBNuCNFZjzrR for ; Mon, 4 Jan 2016 09:45:37 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 35D321A9009 for ; Mon, 4 Jan 2016 09:45:37 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id v14so161986123ykd.3 for ; Mon, 04 Jan 2016 09:45:37 -0800 (PST) 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:content-type; bh=Vj1p5sFvxoAWW7Jw2qFmZXndi4rJL0yBMc8csG7JJuQ=; b=saYg9jMgbe0B62wj/KCaB7YruUjQ7+IFT7UwZp/8CYSltR8t5f6pYtsy67uYfYec0f RONe2dJtej1SomSAa0hvHmLL3dlpfG1dMJb1Psdo7a9pC7lWv2AAYjD/y1b7w2zYRaT+ mwrlK5EaWMJGAChrf9ffVy4y8GaMj2LwcOMJKrHkPU0JkQOICL2oY7H0tO1z6M13MyBU VSlCDJzScIxPwEym3y3o6STkgm5wgh51CDvhdHEkeTqzZEn9YklqURq+VXMWIybwbfjF r23PR4pwT0HF5w1/n9rHo5KBhYymahxxua1p73mgtQriuPtFZIEfxmQbxBkGLHTXigV6 XoXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Vj1p5sFvxoAWW7Jw2qFmZXndi4rJL0yBMc8csG7JJuQ=; b=HjXNN23rlyfkecX2JwrhdbfWcagHJnt61ljcchuSEYeosCvoZjHAzfVRm6ykumvpP/ ERVwjPUvqMAWyCctCp8LIUgBFrKdDIk/y7IylNdjR6jkMFDHzd2YvUCegcgwnF/lx9nb aiIBoiU3uLU1w46DEI0PXihfG0On2k7IXUYeEV3H9Mcdj2Cy5Eo0fdzbxNbKaRonrOkk 8mAXoePrzpeYWzNC9/93EB6tFIkP3FRnvh1j0d3pu2H04sL2rNKmmEGjKPkkHflBgQEs rLBsbWodOABAwUZqKcTIFgfijFbolssO3UQ6AxQktGeF3Z0Ek6iVxwaVDCOKc000/40m kokA== X-Gm-Message-State: ALoCoQnQ5Jqsn6fXoAA0aKARLFebsTz3uI5U1T103suIvk1P2XBQyQmb+p5WRXFqc7ep3hwjuMsuriCNr1sTYQHkjoeguQNZtg== X-Received: by 10.129.79.87 with SMTP id d84mr63382720ywb.115.1451929536545; Mon, 04 Jan 2016 09:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 4 Jan 2016 09:44:57 -0800 (PST) In-Reply-To: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 4 Jan 2016 09:44:57 -0800 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a114dc36043f9b1052885b0ed Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:45:42 -0000 --001a114dc36043f9b1052885b0ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario wrote: > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte > > >> for the "label"?> > > > No. I wonder if we should instead add the '\0' explicitly in the > > > 4.8.1 for maximal clarity. > > Either that, or just remove the trailing 00 from the binary > > description. > > the 0-byte is a C-ism that looks like a wart to me > > neither of the previous TLS versions used null-terminated C-style > strings so why TLS1.3 should? Especially in just one place The idea is to make this prefix-free. I added it as an explicit byte but would be ok with a different separator as long as we banned it from the context strings. -Ekr > > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --001a114dc36043f9b1052885b0ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 4, 2016 at 9:22 AM, Hubert Kario <hkario@redhat.com>= wrote:
On Thursday 24 D= ecember 2015 01:04:59 Christian Huitema wrote:
> On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> >> Similarly, in the HKDF-Expand-Label, = do we assume a final null byte
> >> for the "label"?>
> > No. I wonder if we should instead add the '\0' explicitly= in the
> > 4.8.1 for maximal clarity.
> Either that, or just remove the trailing 00 from the binary
> description.

the 0-byte is a C-ism that looks like a wart to me

neither of the previous TLS versions used null-terminated C-style
strings so why TLS1.3 should? Especially in just one place

The idea is to make this prefix-free. I added it as an expl= icit byte but would
be ok with a different separator as long as w= e banned it from the context
strings.

-E= kr
=C2=A0

Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic

--001a114dc36043f9b1052885b0ed-- From nobody Mon Jan 4 09:56:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD681A900A for ; Mon, 4 Jan 2016 09:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI5WpBCSltxz for ; Mon, 4 Jan 2016 09:56:52 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 13CBD1A903E for ; Mon, 4 Jan 2016 09:56:52 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7CE0316C5CB; Mon, 4 Jan 2016 17:56:51 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6716616C4CC; Mon, 4 Jan 2016 17:56:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1451930211; bh=Axnv6Pxa3EK+5G2IeWeVEI/tlGuHfeGdG+rq2IX5b2w=; l=292; h=From:To:CC:Date:References:In-Reply-To:From; b=cEjJ2V3Ga8fSXqIhtx/OsvpqighY+7za+CFILNBiPeX8BO8UFAw/iLB9Xtu3a3uI7 Bi1xMsol2yCO+OZ5/v6pHkpwhkLPcjK2QreQ0vq49ueqYOWaU3/4LeFy+zK7sf3NnG VpZyNHHojETAJzXmkuV5QSI4GH4Lb0DvQuUxkK/k= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 4C7DF1E07C; Mon, 4 Jan 2016 17:56:51 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 4 Jan 2016 09:56:50 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Mon, 4 Jan 2016 12:56:50 -0500 From: "Salz, Rich" To: Eric Rescorla , Hubert Kario Thread-Topic: [TLS] A small detail in HMAC key generation for Finished message Thread-Index: AdE9zLUIRqzr9WCoSK+Y1yfu8/UHSAAM4oSAAAQxe4ACS1UvgAAAy9mAAAoUuMA= Date: Mon, 4 Jan 2016 17:56:50 +0000 Message-ID: References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:56:53 -0000 PiBUaGUgaWRlYSBpcyB0byBtYWtlIHRoaXMgcHJlZml4LWZyZWUuIEkgYWRkZWQgaXQgYXMgYW4g ZXhwbGljaXQgYnl0ZSBidXQgd291bGQgYmUgb2sgd2l0aCBhIGRpZmZlcmVudCBzZXBhcmF0b3Ig YXMgbG9uZyBhcyB3ZSBiYW5uZWQgaXQgZnJvbSB0aGUgY29udGV4dCBzdHJpbmdzLg0KDQpQZXJo YXBzIGV4cGxhaW4gdGhhdCByYXRpb25hbGUgaW4gdGhlIGRvYz8NCg== From nobody Mon Jan 4 09:59:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3351A903F for ; Mon, 4 Jan 2016 09:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfI3gZOwbyeT for ; Mon, 4 Jan 2016 09:59:10 -0800 (PST) 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 EA9A41A903E for ; Mon, 4 Jan 2016 09:59:09 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ABA58C0A516B; Mon, 4 Jan 2016 17:59:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u04Hx87U027042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 12:59:09 -0500 From: Hubert Kario To: Eric Rescorla Date: Mon, 04 Jan 2016 18:58:44 +0100 Message-ID: <4038107.aFUxodDpT4@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart38213661.DcMFxHUZQk"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:59:11 -0000 --nextPart38213661.DcMFxHUZQk Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 04 January 2016 09:44:57 Eric Rescorla wrote: > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario =20 wrote: > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null= > > > >> byte > > > >> for the "label"?> > > > >=20 > > > > No. I wonder if we should instead add the '\0' explicitly in th= e > > > > 4.8.1 for maximal clarity. > > >=20 > > > Either that, or just remove the trailing 00 from the binary > > > description. > >=20 > > the 0-byte is a C-ism that looks like a wart to me > >=20 > > neither of the previous TLS versions used null-terminated C-style > > strings so why TLS1.3 should? Especially in just one place >=20 > The idea is to make this prefix-free. I added it as an explicit byte > but would > be ok with a different separator as long as we banned it from the > context strings. Calling it explicitly a separator would be less confusing. Advising implementers to check other values passed in for it and=20 aborting if detected would be even better =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 99/71, 612 45, Brno, Czech Republi= c --nextPart38213661.DcMFxHUZQk 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 iQIcBAABCgAGBQJWirLUAAoJEJKo0bgB0vX1EikP/3hvM2erpXqDtS63IjccshzZ sXPtxEMOhzWGE7eByetS/id0rLxi2rZKsZrJVO8ldqUe5z464WZdkF5waz4sR7G0 bBBvweCmkXdyOC62wRjQrLiKPUZfeLjrXh2vA5Vpdg9MCA9NSpfne9oCEBWC9stU meXMMxA+6neJRKKwl1qjWV40clIgN3i726I9V8YRdNdg4WTDCnYNWx44dOIho71J yvsLmlPxZgrFbDVYthTl9JyS0CNE4ndZu9fJqbuft0w29FIt09Yx2SGjHen2ih65 33SStfyhoNzboAadxIh73t9CU/83tC/AILILn6gNNeWXTWc092QxNk7vFW0p0WV/ FVo7DbyLw7eAIRdqXtNcOllXMGnbVQjtapzE/9oKuxHVAXV2i02dhRyGJ4BKbN1k IPvX15zN/61Btml4hlXYmehOaQHWpyDXgSnRn1Xo1ZuXSsHaYEwSekztOONhGvl/ bgn4PtbjrZH2E1Epkn8FebiHVY0vTgtqCJnahsks8+nbgzZZFjcxrEvrzQBs5wq1 LpcAJJhEI+SjudJ5nyVGQsBy0uC4va+1gyrISHuAMw+zSHOGVEbPX1tJvjafROIM DT6Nwf6X888PMKQbujTy1MOL+ldeH8vu41H2viDZs/prhd/WhW/P9P5354npSuYB JIhMvoLsyWwS61jPryCN =VNUT -----END PGP SIGNATURE----- --nextPart38213661.DcMFxHUZQk-- From nobody Mon Jan 4 10:04:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0E21A9048 for ; Mon, 4 Jan 2016 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 EygakYye9xJj for ; Mon, 4 Jan 2016 10:04:13 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549171A904A for ; Mon, 4 Jan 2016 10:04:13 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id x67so255380202ykd.2 for ; Mon, 04 Jan 2016 10:04:13 -0800 (PST) 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:content-type; bh=9cxGGVqrIWf/m9PfKhkBE/biq1Vpcbs1YgbHI2roF2Q=; b=lh/Y3BIXdcXQHkBHm8otp/78IfSD5yJRkUd2W/khWQGy5t1o5F+RT3l0FNp/vPvHSf MP5c7b+V7I+Kl6TuH6UH+CCAcnk4INYmdx31I5eUPP2BUPDzN2dNof9PLWI4tbdHf76k 9fel69wD2+P9BwjLFWVkFuk4e2ES0CfElIdi/efMy1VkjgSXReaJRpMj2IbyrWJlA/2d /+2z7dkrAhYzPg6HoX39VvyrhmM4IjKgUvEbtLFhLE6kFaBeiSeejHyYsu+c9A2mTNGB vUeFrLXVqHtyH6/zcknTNavgasiXgg8hMzODcN9aBoCVReDdjfHAILwzQ7rdE/y3vJJ0 bOhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9cxGGVqrIWf/m9PfKhkBE/biq1Vpcbs1YgbHI2roF2Q=; b=fhzqrMyW/9dwrYUnHSF/A0qc8NOcssGY2zfJCLqge2RbJUqRo3fNOh5WP0B2hkh3Q+ MwRIPDPBueONuf4T40wVDwMQz8JcVvkIcEOtEUbA5cYmJkbw70YBqeomhkOLRyvUH88g Xvq9d3yZP7Liw0eh8QkBFpPaDwdmtkKj4DEP5QeQOrGVEGKd9E22VoYPn+81Q1y0t/IF 6ZRWpdRUWp4adWNrgqbwIWwNYTAs/26Iqi1wbagZql4Jd6kgo7uArjVCgCBiiH3Zx7hK Q29J8D8rxbFeSUWfZiam4TyCsk0Ii24I54Yr55SKUop9Ujo6oyUXnzAgjh76tRqg97gp nptw== X-Gm-Message-State: ALoCoQk+LdXzmEW8KB0cqD1BqeYGwDIL1H2W44o/4xMXcbwvfp39YI0kOFkusS4Tat+YbNIFRQZnNXTQ5ylYwIa2T2yLLx1djA== X-Received: by 10.13.218.198 with SMTP id c189mr71055727ywe.165.1451930652622; Mon, 04 Jan 2016 10:04:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 4 Jan 2016 10:03:33 -0800 (PST) In-Reply-To: <4038107.aFUxodDpT4@pintsize.usersys.redhat.com> References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> <4038107.aFUxodDpT4@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 4 Jan 2016 10:03:33 -0800 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=94eb2c08192ac9f51d052885f248 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:04:14 -0000 --94eb2c08192ac9f51d052885f248 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario wrote: > On Monday 04 January 2016 09:44:57 Eric Rescorla wrote: > > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario > wrote: > > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null > > > > >> byte > > > > >> for the "label"?> > > > > > > > > > > No. I wonder if we should instead add the '\0' explicitly in the > > > > > 4.8.1 for maximal clarity. > > > > > > > > Either that, or just remove the trailing 00 from the binary > > > > description. > > > > > > the 0-byte is a C-ism that looks like a wart to me > > > > > > neither of the previous TLS versions used null-terminated C-style > > > strings so why TLS1.3 should? Especially in just one place > > > > The idea is to make this prefix-free. I added it as an explicit byte > > but would > > be ok with a different separator as long as we banned it from the > > context strings. > > Calling it explicitly a separator would be less confusing. > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signin= g "Following that padding is a context string used to disambiguate signatures for different purposes. The context string will be specified whenever a digitally-signed element is used. A single 0 byte is appended to the context to act as a separator." Advising implementers to check other values passed in for it and > aborting if detected would be even better > This seems like it's probably not necessary because these strings are standardized and internal to the implementation. -Ekr > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > --94eb2c08192ac9f51d052885f248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
On Monday 04 January 2= 016 09:44:57 Eric Rescorla wrote:
> On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario <hkario@redhat.com>
wrote:
> > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote= :
> > > >> Similarly, in the HKDF-Expand-Label, do we assume a= final null
> > > >> byte
> > > >> for the "label"?>
> > > >
> > > > No. I wonder if we should instead add the '\0' = explicitly in the
> > > > 4.8.1 for maximal clarity.
> > >
> > > Either that, or just remove the trailing 00 from the binary<= br> > > > description.
> >
> > the 0-byte is a C-ism that looks like a wart to me
> >
> > neither of the previous TLS versions used null-terminated C-style=
> > strings so why TLS1.3 should? Especially in just one place
>
> The idea is to make this prefix-free. I added it as an explicit byte > but would
> be ok with a different separator as long as we banned it from the
> context strings.

Calling it explicitly a separator would be less confusing.


"Following that pa= dding is a context string used to disambiguate=20 signatures for different purposes.
The context string will be spe= cified=20 whenever a digitally-signed element is used. A single 0 byte is=C2=A0
=
appended to the context to act as a separator."


<= /div>
Advising implementers to check other values passed in for it and
aborting if detected would be even better

This seems like it's probably not necessary because these strings ar= e standardized
and internal to the implementation.

=
-Ekr
=C2=A0
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic

--94eb2c08192ac9f51d052885f248-- From nobody Mon Jan 4 16:11:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC21ACD4D for ; Mon, 4 Jan 2016 16:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg96D07cTWbL for ; Mon, 4 Jan 2016 16:11:29 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 98B6E1ACD95 for ; Mon, 4 Jan 2016 16:11:29 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id to4so3354949igc.0 for ; Mon, 04 Jan 2016 16:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JgU/5Jto7+yfCRrXWZ+F7xpuyWFnuAqGhP1y7CUR2Is=; b=QT+7Sy7Kt7ytHTbMNFcfdjjSX2ahd7Ac0mDvNnrxLQHUnYJ6dhiZXvTUcJhnGWY4WP 3Bi0CPFX+GZlcAjPcaBLnaSMYe8Z+MewkdGXAmISfoDWd5FRIST2Gj+0YqR5KeCQkdJg 8HB1o8Ac9MNeI2gAC7SDB1TkCH0lFnHyIqG+ME7u4BpGkseMWchQ27aZReKprjVM8l9c vYDtepBakkbJyotrIeErnBU+1QXpco8c+PwpoUSYUVAkG0H4dm2sl+cgpToS7zZi/lHC o/8Gx/fkJSsqvQ2OiZNstcmxV32F92X86E58NwzyIztPkUhxUGQzvAnEolHQQOgl5YNR eLXw== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr1047033igb.77.1451952688996; Mon, 04 Jan 2016 16:11:28 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 4 Jan 2016 16:11:28 -0800 (PST) In-Reply-To: References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> <4038107.aFUxodDpT4@pintsize.usersys.redhat.com> Date: Tue, 5 Jan 2016 11:11:28 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jan 2016 00:11:34 -0000 On 5 January 2016 at 05:03, Eric Rescorla wrote: > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing > > "Following that padding is a context string used to disambiguate signatures > for different purposes. > The context string will be specified whenever a digitally-signed element is > used. A single 0 byte is > appended to the context to act as a separator." You call this NUL in the following paragraph, without context. This might need to be tied together better. From nobody Mon Jan 4 16:20:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3068A1ACD92 for ; Mon, 4 Jan 2016 16:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 wWzsC-cgw9ze for ; Mon, 4 Jan 2016 16:20:17 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 D815B1ACD91 for ; Mon, 4 Jan 2016 16:20:16 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id a85so188363473ykb.1 for ; Mon, 04 Jan 2016 16:20:16 -0800 (PST) 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:content-type; bh=JXpJUrVHKQVqO7Dgo+f4tQe1nHUkWjAy2Rx/2CQo8AQ=; b=W66iaIKdx76qt9HBVgPxm1urYFaHHyWAc3YvWkY+UcqNxHtnv84S6bXPM+p/fimez9 /rkKWLXxaLb3xhttOJrqfuira5h64VZOwbsBo23VbQA6obblNLqG0xaO4mgggLtWcxxh cLeDjWrhjWBJy38wGauWS5qCyHbSzXl6IDQe3pcWx5T55cc0RAryVwhsvNw6weNfO/pn xpGS50nvSaG5fO8/KRB38KPUZMkXbqoADYzC+Gsd7voocmTKUJ+xoVrICpP3xhXfnnJ7 us+7fjoh6S9oYsHnQ8+jaJjaizFYoti7+q+blkAOd9aqKQAgm3ycKTVkKdfL53UKanuk yJdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JXpJUrVHKQVqO7Dgo+f4tQe1nHUkWjAy2Rx/2CQo8AQ=; b=AsYXE4sRF30wQhLpdZQcMUxddGO9vQY8MkERgNtDkAL6JNB+OiEFfDpHInomhmjjjZ MMD9PpQ6KZj2qTBWpq+p1zap/HTUDrvYQZcr/gJvp9lLdaGkV0XX/bEYlWvpDF3Kd55f WHc+Cxc25IRBAuBb2vDzK8DI+f4e/6XVPr2KcvEqOSL6IAAvQnAhwBu3l2tyKXgJKvF+ 5tRI2WYVEkXgFEivFEBm8AkVE7ZT+2LCuDRdZx7TXRNxO0kQeUjm3FO89dcUfeO80Zlk 6WVl06n8Q18GcEuw5/sAY7R19YOMkUgjy2qrYQfnAUmSAK/hiT96NNz3qNofKbukdtTQ Mc7g== X-Gm-Message-State: ALoCoQmyS9FFarpIYPcdCE7uNfCPZFqCkag49l0JHgZ4SiNwO5TLnMsZsUhoqkfDCGaH3v/B9xwTeHBlc2s00jsP3t1ggPo7aQ== X-Received: by 10.129.148.3 with SMTP id l3mr65793161ywg.155.1451953216134; Mon, 04 Jan 2016 16:20:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 4 Jan 2016 16:19:36 -0800 (PST) In-Reply-To: References: <1559494.V2ctEmMh08@pintsize.usersys.redhat.com> <4038107.aFUxodDpT4@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 4 Jan 2016 16:19:36 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c07c8bcadd3b005288b33c6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jan 2016 00:20:18 -0000 --94eb2c07c8bcadd3b005288b33c6 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 4, 2016 at 4:11 PM, Martin Thomson wrote: > On 5 January 2016 at 05:03, Eric Rescorla wrote: > > Ask and ye shall receive: > http://tlswg.github.io/tls13-spec/#digital-signing > > > > "Following that padding is a context string used to disambiguate > signatures > > for different purposes. > > The context string will be specified whenever a digitally-signed element > is > > used. A single 0 byte is > > appended to the context to act as a separator." > > > You call this NUL in the following paragraph, without context. This > might need to be tied together better. > Fixed. --94eb2c07c8bcadd3b005288b33c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 4, 2016 at 4:11 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 5 January 2016 at 05:03, Eric Rescorla <ekr@rtfm.com> wrote:
> Ask and ye shall receive: http://tlswg.github= .io/tls13-spec/#digital-signing
>
> "Following that padding is a context string used to disambiguate = signatures
> for different purposes.
> The context string will be specified whenever a digitally-signed eleme= nt is
> used. A single 0 byte is
> appended to the context to act as a separator."


You call this NUL in the following paragraph, without context.=C2=A0= This
might need to be tied together better.

= Fixed.=C2=A0

--94eb2c07c8bcadd3b005288b33c6-- From nobody Tue Jan 5 12:36:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1A51A90E0 for ; Tue, 5 Jan 2016 12:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f3TltgjW1na for ; Tue, 5 Jan 2016 12:36:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 243C01A90DC for ; Tue, 5 Jan 2016 12:36:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7386E433456; Tue, 5 Jan 2016 20:36:35 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5DA3E433445; Tue, 5 Jan 2016 20:36:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452026195; bh=OVNHIQI98Jn+BS0ma/NmJg7hjjlXeMDgrMSFfAbKFZM=; l=5334; h=To:References:Cc:From:Date:In-Reply-To:From; b=uaEp/L9sFuxJto9AEazw7g4+IdvDSSKAhXk/ijDJPocS48KIMQV6ZEk1VRE6Z2tEs 8QwiAnQwRdaUJvxFJMvcKHPfb4ZClzOzu3U92vSAX4m9M8/Y+Wy0nYVomXEK4Yti/G ACvPLNQed6tz/zoQwVWG61OThUysXKgJd/bxTlYg= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 18B0C2029; Tue, 5 Jan 2016 20:36:35 +0000 (GMT) To: Eric Rescorla , Hugo Krawczyk References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> From: Benjamin Kaduk Message-ID: <568C2952.7010503@akamai.com> Date: Tue, 5 Jan 2016 14:36:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040902040108020200060302" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Jan 2016 20:36:37 -0000 This is a multi-part message in MIME format. --------------040902040108020200060302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/17/2015 02:11 PM, Eric Rescorla wrote: > > > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk > wrote: > > I have mentioned this in private conversations but let me say this > here: I would prefer that the nonces be explicitly concatenated to > the handshake hash. That is, > > handshake_hash = Hash( > > client random || > > serverrandom || > > Hash(handshake_messages) || > > Hash(configuration) || ) > > > The reason is that nonces are essential for freshness and session > uniqueness and I want to see them explicitly included in the > signed/mac-ed/KDF-ed information. I can envision a future > variant/mode of the protocol where parties do not transmit nonces > but have a synchronized state that they advance separately and use > as nonces (e.g., for key refreshing) - in such case the nonces > would not be included in the handshake-hash computation. > > So while the redundancy of having them twice in the handshake_hash > calculation may be annoying, this adds robustness to the security > (and analysis) of the protocol. > > > This change doesn't make implementation or specification significantly > more difficult. > Does anyone else object or feel it makes analysis harder? :) > I don't object, but since elsewhere in the thread the possibility of changing the size of or omitting the randoms in the future came up, I will mention the possibility of adding length/framing information and/or labels into the hash input as well as the randoms themselves. -Ben --------------040902040108020200060302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/17/2015 02:11 PM, Eric Rescorla wrote:


On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash. That is,

handshake_hash = Hash(

                            client random            ||
                            server random            ||
                            Hash(handshake_messages) ||
                            Hash(configuration)      ||
                           )

The reason is that nonces are essential for freshness and session uniqueness and I want to see them explicitly included in the signed/mac-ed/KDF-ed information. I can envision a future variant/mode of the protocol where parties do not transmit nonces but have a synchronized state that they advance separately and use as nonces (e.g., for key refreshing) - in such case the nonces would not be included in the handshake-hash computation.

So while the redundancy of having them twice in the handshake_hash calculation may be annoying, this adds robustness to the security (and analysis) of the protocol.
This change doesn't make implementation or specification significantly more difficult.
Does anyone else object or feel it makes analysis harder? :)


I don't object, but since elsewhere in the thread the possibility of changing the size of or omitting the randoms in the future came up, I will mention the possibility of adding length/framing information and/or labels into the hash input as well as the randoms themselves.

-Ben
--------------040902040108020200060302-- From nobody Tue Jan 5 16:56:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796E1A0AF1 for ; Tue, 5 Jan 2016 16:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZwokcFwXeJQ for ; Tue, 5 Jan 2016 16:56:05 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 291651A03A2 for ; Tue, 5 Jan 2016 16:56:05 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C6A45423714; Wed, 6 Jan 2016 00:56:03 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id B08F442372D; Wed, 6 Jan 2016 00:56:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452041763; bh=2qQkKcKsMaEmgEOLOP+5grW1nauzekwq1LBdBcxRhqE=; l=1088; h=To:References:Cc:From:Date:In-Reply-To:From; b=Iq5jno9Ax6RRStJ1mJ78JFFVwfIFXLawJhMbbk034w1RkdIIjTKSgcflGmrQXE9f3 CLWZVguTrsOwiM9MvRYERJRiJnUaoG7cRJv/42T2HhK8hJEC/8S1y2mSiDsO0Zz0Oj sFvBjj8ZcOZ3PUAtKDjG7NltiERZILyrkJ4aGSxk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7D1542029; Wed, 6 Jan 2016 00:56:03 +0000 (GMT) To: Florian Weimer References: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> <568A5F71.9040002@redhat.com> <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> <568A63F7.10307@redhat.com> From: Benjamin Kaduk Message-ID: <568C6623.4020904@akamai.com> Date: Tue, 5 Jan 2016 18:56:03 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <568A63F7.10307@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2016 00:56:06 -0000 On 01/04/2016 06:22 AM, Florian Weimer wrote: > On 01/04/2016 01:19 PM, Hubert Kario wrote: > >>> Dealing with this during the initial handshake is fine. But >>> supporting direction-switching after that is *really* difficult. >> yes, this is a bit more problematic, especially for one-sided transfers. >> For example, when one side is just sending a multi-gigabyte transfer as >> a reply to a single command - there may be megabytes transferred before >> the other side reads our request for rekey and then our "CCS" message > Yes, this is the issue I meant. I simply don't see a way to re-inject > new randomness without a round-trip. (Key update without new randomness > doesn't face this challenge, but then it's mostly cheating.) > EKR asked for an explanation of what risk you want to mitigate by adding new randomness on the 28th of December, but I don't recall seeing an explanation. This belief that key update without new randomness is undesirable does not really seem to be supported by any concrete arguments, in the recent history of this thread. -Ben From nobody Thu Jan 7 02:45:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF51A889B for ; Thu, 7 Jan 2016 02:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6KJdn6hcqAp for ; Thu, 7 Jan 2016 02:45:07 -0800 (PST) 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 CA22D1A8899 for ; Thu, 7 Jan 2016 02:45:07 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6CCD0A4534; Thu, 7 Jan 2016 10:45:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-204-25.brq.redhat.com [10.40.204.25]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u07Aj5ft018194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 05:45:06 -0500 To: Benjamin Kaduk References: <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> <568A5F71.9040002@redhat.com> <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> <568A63F7.10307@redhat.com> <568C6623.4020904@akamai.com> From: Florian Weimer Message-ID: <568E41B0.4080805@redhat.com> Date: Thu, 7 Jan 2016 11:45:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <568C6623.4020904@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2016 10:45:09 -0000 On 01/06/2016 01:56 AM, Benjamin Kaduk wrote: > On 01/04/2016 06:22 AM, Florian Weimer wrote: >> On 01/04/2016 01:19 PM, Hubert Kario wrote: >> >>>> Dealing with this during the initial handshake is fine. But >>>> supporting direction-switching after that is *really* difficult. >>> yes, this is a bit more problematic, especially for one-sided transfers. >>> For example, when one side is just sending a multi-gigabyte transfer as >>> a reply to a single command - there may be megabytes transferred before >>> the other side reads our request for rekey and then our "CCS" message >> Yes, this is the issue I meant. I simply don't see a way to re-inject >> new randomness without a round-trip. (Key update without new randomness >> doesn't face this challenge, but then it's mostly cheating.) >> > > EKR asked for an explanation of what risk you want to mitigate by adding > new randomness on the 28th of December, but I don't recall seeing an > explanation. I tried, but maybe it's not clear. Anyway, I don't see the current key update mechanism provides much value. I don't think it is desirable to have a full re-key mechanism with the complexity it involves. Florian From nobody Sat Jan 9 02:17:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB121A6F5A for ; Sat, 9 Jan 2016 02:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEF_W97-thkn for ; Sat, 9 Jan 2016 02:17:54 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id C5CC81A6F58 for ; Sat, 9 Jan 2016 02:17:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A47A24C1 for ; Sat, 9 Jan 2016 12:17:51 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id i2-nO3dWpuuF for ; Sat, 9 Jan 2016 12:17:51 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 5F1B8231 for ; Sat, 9 Jan 2016 12:17:51 +0200 (EET) Date: Sat, 9 Jan 2016 12:17:48 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160109101748.GA8925@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151231201644.17780804.55594.43078@ll.mit.edu> <20160101182240.GA25903@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160101182240.GA25903@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 10:17:56 -0000 On Fri, Jan 01, 2016 at 08:22:40PM +0200, Ilari Liusvaara wrote: > On Thu, Dec 31, 2015 at 08:16:35PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > I think Watson made a good point about "omittable checks". ‎If an > > implementation A "omits" this mechanism, it should fail session > > establishment. > > Well, here is one scheme that I can't break myself and has no checks one > can just "omit": > > PMS = SHA-512(A|B|DHF(a,B)) = SHA-512(A|B|DHF(b,A)) > > Where a and b are the private keys and A and B are the public keys > and DHF is X25519 or X448. And I broke that too... Really, the only choice without omittable checks nor known security issues is to imply EMS (or another modification to master secret derivation) off the codeponts in TLS 1.0-1.2. That is, if those groups are sent, thekey derivation will be EMS, even if EMS extension was absent (and sending it is no-op). (If there ever is another key derivation modifying extension, let that specify what the heck to do with those groups). -Ilari From nobody Sat Jan 9 05:57:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49811A875A for ; Sat, 9 Jan 2016 05:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uac6D8sEJWmW for ; Sat, 9 Jan 2016 05:57:13 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 146181A8762 for ; Sat, 9 Jan 2016 05:57:13 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id v14so297138963ykd.3 for ; Sat, 09 Jan 2016 05:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P2/oAwXM4ygT5GW+NdYGe05YzouNHM4pLxLnO0OB2rY=; b=QDOy/Dkr742Bf72wzb+GnMGRn1uRo1bxiKbxMhYifcO68IBlQLzEudVgJLf4PoJ0j9 MhT3m7HG3JyL5bvJVhRiWG/DSltpuTi2vuew5Yk86iFirVplGLNg6BQDvpj7f6uwX1rf u88wlCgpq3/YQAswh+dgUlaKHVRKAQV7/orXaEOA7dMDVs7PLDe2CVRsugwlsh5DZktT 9vM0Si3i67nQifyHI3PjNjuWMlICVClYH35FANTOsYQx8LZswoQBwAyp/yOLbO3VBjNV MdCwQsuQM6v8w61iwxqWSe5foTwpQkLSrAyd4z3WxyUP8BBpvSnMyjV69DRsfPT6ZzGc KOWg== MIME-Version: 1.0 X-Received: by 10.129.123.134 with SMTP id w128mr62421481ywc.345.1452347832363; Sat, 09 Jan 2016 05:57:12 -0800 (PST) Received: by 10.13.216.150 with HTTP; Sat, 9 Jan 2016 05:57:11 -0800 (PST) Received: by 10.13.216.150 with HTTP; Sat, 9 Jan 2016 05:57:11 -0800 (PST) In-Reply-To: <20160109101748.GA8925@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151231201644.17780804.55594.43078@ll.mit.edu> <20160101182240.GA25903@LK-Perkele-V2.elisa-laajakaista.fi> <20160109101748.GA8925@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 9 Jan 2016 05:57:11 -0800 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1144fe52a370790528e714c6 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 13:57:14 -0000 --001a1144fe52a370790528e714c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jan 9, 2016 2:18 AM, "Ilari Liusvaara" wrote: > > On Fri, Jan 01, 2016 at 08:22:40PM +0200, Ilari Liusvaara wrote: > > On Thu, Dec 31, 2015 at 08:16:35PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > I think Watson made a good point about "omittable checks". =E2=80=8EI= f an > > > implementation A "omits" this mechanism, it should fail session > > > establishment. > > > > Well, here is one scheme that I can't break myself and has no checks on= e > > can just "omit": > > > > PMS =3D SHA-512(A|B|DHF(a,B)) =3D SHA-512(A|B|DHF(b,A)) > > > > Where a and b are the private keys and A and B are the public keys > > and DHF is X25519 or X448. > > And I broke that too... > > Really, the only choice without omittable checks nor known security > issues is to imply EMS (or another modification to master secret > derivation) off the codeponts in TLS 1.0-1.2. That is, if > those groups are sent, thekey derivation will be EMS, even if EMS > extension was absent (and sending it is no-op). > > (If there ever is another key derivation modifying extension, let > that specify what the heck to do with those groups). Would you mind explaining the attack in more detail? I'm pretty sure that with at least one honestly generated value the result cannot be controlled. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1144fe52a370790528e714c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 9, 2016 2:18 AM, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
>
> On Fri, Jan 01, 2016 at 08:22:40PM +0200, Ilari Liusvaara wrote:
> > On Thu, Dec 31, 2015 at 08:16:35PM +0000, Blumenthal, Uri - 0553 = - MITLL wrote:
> > > I think Watson made a good point about "omittable check= s". =E2=80=8EIf an
> > > implementation A "omits" this mechanism, it should= fail session
> > > establishment.
> >
> > Well, here is one scheme that I can't break myself and has no= checks one
> > can just "omit":
> >
> > PMS =3D SHA-512(A|B|DHF(a,B)) =3D SHA-512(A|B|DHF(b,A))
> >
> > Where a and b are the private keys and A and B are the public key= s
> > and DHF is X25519 or X448.
>
> And I broke that too...
>
> Really, the only choice without omittable checks nor known security > issues is to imply EMS (or another modification to master secret
> derivation) off the codeponts in TLS 1.0-1.2. That is, if
> those groups are sent, thekey derivation will be EMS, even if EMS
> extension was absent (and sending it is no-op).
>
> (If there ever is another key derivation modifying extension, let
> that specify what the heck to do with those groups).

Would you mind explaining the attack in more detail? I'm= pretty sure that with at least one honestly generated value the result can= not be controlled.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a1144fe52a370790528e714c6-- From nobody Sun Jan 10 19:49:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAB21A6FD9 for ; Sun, 10 Jan 2016 19:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 XQZ_AB6bbMBh for ; Sun, 10 Jan 2016 19:49:35 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 BCD661A6FDA for ; Sun, 10 Jan 2016 19:49:34 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id m198so58516870lfm.0 for ; Sun, 10 Jan 2016 19:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3BjmVGxLrliEiZM/rNlE4jr60lyzQGC/wbQKImtP13s=; b=DphcWCHRjoJby/2fwTxmRCKMio9RH3RBI0v4z/ypMU5H8Q90axtvPCiK168Ir3IHhW uwmkRBPTC4xTOAevCeycLu/KyGpDzSBntSqxr2uIsVIwwTE7EfygDibd1VnNLqbOLimT 6HWgmqUH1jrt1S87TBRgoWlggXSCiBPmPd+ykheuk5bkcxhAHQpk0DlliaMb3SzBjbB4 haRnwWD5t6Udqhe0dwgh5ZKUhyKwCiPMk3gzLTsptOjX4Dyai+uf/+Hvn/1JKVvzXwHM j3Ts9Q0ZPNznL6/sabXwvbkuBSwlRCJrpyoKIywgYzOCFUR01GYaGCNHZQZfMjvgzGwI kPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3BjmVGxLrliEiZM/rNlE4jr60lyzQGC/wbQKImtP13s=; b=fNjTzOpIKJ6f1mbGfbdvrFzk57vrp4uLEnsfVKIW/giDz8lUqTuk61hUQlnFwn7Zjg wnkqqXL9WGOsrxDBUTHebPThMebtzGw+Qpzh1r5FEL3v7nX5Pr7eNsM9MtxTIr0aNGf+ T8cJzl9w+4zVrECGzRFNxg9aJVxmEHU8160byjFioYBTHLA989xrQy86gKqX8PcRUwE7 +jexpMTKMQTrPyPuaeTRB991l1O7EBb6xY+PNcnfz+Cpf5vXfVlanC/EMPEAXBsGjM2Q 33z4HOAvandGJjqYY3ks0sNqpl4zkeBOXSdcgvZxm3W40NKrSDrOr7OH/KE+efqhe99Q sGRQ== X-Gm-Message-State: ALoCoQnF9zJhViXK/fsy7zGKPF1Nn315i2IaxVHb1jFaRnr/yugUXZDqHP5o5jRsFkXfYHQSYjfdRQCFOlbnm8pwYuSU90ySOQ== MIME-Version: 1.0 X-Received: by 10.25.5.205 with SMTP id 196mr41559875lff.143.1452484172907; Sun, 10 Jan 2016 19:49:32 -0800 (PST) Received: by 10.112.2.104 with HTTP; Sun, 10 Jan 2016 19:49:32 -0800 (PST) In-Reply-To: References: Date: Sun, 10 Jan 2016 19:49:32 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113e9c162b21ee052906d3fe Archived-At: Subject: Re: [TLS] WGLC for ChaCha20-poly1305 ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 03:49:36 -0000 --001a113e9c162b21ee052906d3fe Content-Type: text/plain; charset=UTF-8 The working group last call for draft-ietf-tls-chacha20- poly1305-03 has completed. A new draft has been submitted draft-ietf-tls-chacha20- poly1305-04 . There has been some discussion of changing the PRF digest function for the cipher suites. The chairs do not believe there is working group consensus to make a change. We will forward this draft to the IESG and ask the working group if there is objection to early code point assignment. Thanks, J&S On Thu, Dec 3, 2015 at 1:16 PM, Joseph Salowey wrote: > draft-ietf-tls-chacha20- > > poly1305-03 > has > been submitted incorporating feedback from working group discussions. In > particular the construction now matches what is used in TLS 1.3. Please > review the draft and send any comments by December 17, 2015. > > Thanks, > > J&S > --001a113e9c162b21ee052906d3fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The working group last call for=C2=A0draft-ietf-tls-chacha20-poly1305-03=C2=A0has completed.= =C2=A0 A new draft has been submitted=C2=A0draft-= ietf-tls-chacha20-poly1305-04.=C2=A0 There has been some discussion of= changing the PRF digest function for the cipher suites.=C2=A0 The chairs d= o not believe there is working group consensus to make a change.=C2=A0 We w= ill forward this draft to the IESG and ask the working group if there is ob= jection to early code point assignment. =C2=A0

Thanks,

J&S

<= div class=3D"gmail_quote">On Thu, Dec 3, 2015 at 1:16 PM, Joseph Salowey <jo= e@salowey.net> wrote:
draft-ietf-tl= s-chacha20-pol= y1305-03 has been submitted incorporating feedback from working group d= iscussions. In particular the construction now matches what is used in TLS = 1.3. =C2=A0 Please review the draft and send any comments by December 17, 2= 015. =C2=A0

Thanks,

J&S

--001a113e9c162b21ee052906d3fe-- From nobody Sun Jan 10 19:49:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77E21A6FE0 for ; Sun, 10 Jan 2016 19:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 XVTmQ99-Y_BX for ; Sun, 10 Jan 2016 19:49:40 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 74FCC1A6FDE for ; Sun, 10 Jan 2016 19:49:39 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id oh2so247909799lbb.3 for ; Sun, 10 Jan 2016 19:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=uIrvCwhuGWuCKAHICnVZmdnLlAaJ7iuqJEx8Q4NY5M4=; b=09YJ/hwX3h9duhWw14btpcOvGfeJGY59UUzJH6ulE6O9qtvgbQOsht10M3S5w5RGK7 f6XGxgdC0RCin2zneQecCNhuDAjTaO43M0Sflw6LeUogF4wnsAQYAq6Sa4FaP1QpHM3o 3chSYiNPrfFUAskeRDeZ6RhQTGgUHJ8/nxKi4NKQ1VmJCGVZKr9pgklAxdLa78hQKOMh GUDuAQyKPVtzo2rTxgwiz1gNl4Gv3f3oaLjfysV7U1YGWXm4VUjMy6922tYTOX5CRB9P gstwG0zip1dmYONDBz4wzTzunzVdw8Rma/XDCABPwlqA2i3cwG1Rt1/sFJWhq5mfkyjP 6ETw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uIrvCwhuGWuCKAHICnVZmdnLlAaJ7iuqJEx8Q4NY5M4=; b=Ww1IV1/1t/n7pT7nfFiN5uHIeTYO/GMjn9l2LFUnZpVxvAu/KWUSiQNplFnc9vyZfE hTX3O/U9+0SyqVZK9CjvDdGHcXF8ngZr0KgoYaIZ0R6GOL2TY0ARJYInV+0raXx/5KDK TneMbthVvzelhkZ/xoqLBIsiva0m4ZdMEVNOk3yYxkLChxGKFdUKHz2wjFbpFLpMoWep xnzodzMqRQF25FMySphdZLBmUVe0smaPwZttItJNMlfNrBQn0H7qvO7hlpFnnwEw/J4B /2ezITWltJE6kBS/ysbkxqSP5d7DXLYZbcVGATFYtnyGsRGlfg6jvnjXJgJRVlFM2Rap wTXQ== X-Gm-Message-State: ALoCoQnfLMva+e4zpLkHp2YXI0ka62B79BiPDmz+aNr2B8VpeJbBnsTno1gDmJ2su+SNrh50j0TdB/s0PBo6j/eRGouUsbeK0w== MIME-Version: 1.0 X-Received: by 10.112.147.161 with SMTP id tl1mr6984786lbb.4.1452484177726; Sun, 10 Jan 2016 19:49:37 -0800 (PST) Received: by 10.112.2.104 with HTTP; Sun, 10 Jan 2016 19:49:37 -0800 (PST) Date: Sun, 10 Jan 2016 19:49:37 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a804c74a9b9052906d359 Archived-At: Subject: [TLS] Early code point assignment for ChaCha20-poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 03:49:40 -0000 --047d7b3a804c74a9b9052906d359 Content-Type: text/plain; charset=UTF-8 Please respond if you have concerns about early code point assignment for cipher suites in draft-ietf-tls-chacha20-poly1305-04 . Thanks, J&S --047d7b3a804c74a9b9052906d359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please respond if you have concerns about early code point= assignment for cipher suites in=C2=A0draft-ietf-tls-chacha20-= poly1305-04.

Thanks,

J&S



--047d7b3a804c74a9b9052906d359-- From nobody Sun Jan 10 19:53:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77401A6FDD for ; Sun, 10 Jan 2016 19:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 vlN0NXJuD_3q for ; Sun, 10 Jan 2016 19:53:10 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 7A4F51A6FD7 for ; Sun, 10 Jan 2016 19:53:10 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id oh2so247932373lbb.3 for ; Sun, 10 Jan 2016 19:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=fVX1KQL83XT/YmVjMoZvzkmLOJczpU59Eko/r/hLHAI=; b=tFmh0boYOznmmMOJb3HsgJeiKTlw7vF411YC8oWWBq4H/BDDk2MH8slMl90SdKZzCl 8pxEb2nkYwvjETj1ISHKhbpunlsJf21akxKczX9k+CDSE3aSzTcQUJVieDptpbaVAbmo WfUkbab87TFjhsyzZukOdzXsI1xoTxUD4LfsLQZ+mpOeYOFqt57JQIjUI6roihF7YDW0 EWnWAQgqTuSg1HNWnpR6WjkFfzWwBgGLi/otHBKRUy/7AR9GKbowdDwK0EGqBIuLRs1I wcSUOA02JxmLhh+f1YWDW82IVguuE4SJs9dt5KlGPoJvt5fb0l90svYNO+b9EIUwkOQa RICA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=fVX1KQL83XT/YmVjMoZvzkmLOJczpU59Eko/r/hLHAI=; b=OLlux/X0BzYoXjWlkO20TLfe2230tWS/1lStz+gMeLDv8qOW+FDs+RreqPrZ0F0viI nToEogVqhMQwYkNIofX3dVPjb6cHc35nztcIsTZAwvJd4Ln24d6ALayXCpQaLZTDLFrU 49sJ38j67U/Np9AO7ck2pC+ePzNkEat8caPHm2vYX5sCN9lYj60IHWpi5FArRilZ48ig O8zCYaG72R2/LE5C3OsezAlzkwMyzNEShHQ0O/nKDYHDYqc9pL91vQYBRXbzkHuGsEC8 hboKDRzkHeU7bWkDKCBdgTChSjkYrPIom5sBDlLOA+kH6e1XEq7kjrJ75efenIFN4OJN 1S2A== X-Gm-Message-State: ALoCoQkWXGZpZ7UHa4Ipjvk9ZBen4JKGeIy4R2hxuss27X1hb5Gn3uPlrYkuNjbaEnX8DtKlcHTuQk44s75PmNTHCs+0VSn9uA== MIME-Version: 1.0 X-Received: by 10.112.84.44 with SMTP id v12mr44519113lby.46.1452484388746; Sun, 10 Jan 2016 19:53:08 -0800 (PST) Received: by 10.112.2.104 with HTTP; Sun, 10 Jan 2016 19:53:08 -0800 (PST) Date: Sun, 10 Jan 2016 19:53:08 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11347bda0896ab052906e0e1 Archived-At: Subject: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 03:53:11 -0000 --001a11347bda0896ab052906e0e1 Content-Type: text/plain; charset=UTF-8 Please respond if you have concern about early code point assignment for the curves listed in draft-ietf-tls-curve25519-01 . Thanks, J&S --001a11347bda0896ab052906e0e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please respond if you have concern about early code point = assignment for the curves listed in=C2=A0draft-ietf-tls-curve25519-01.
Thanks,

J&S
--001a11347bda0896ab052906e0e1-- From nobody Sun Jan 10 23:29:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033BA1A8732 for ; Sun, 10 Jan 2016 23:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QWOknESmkZC for ; Sun, 10 Jan 2016 23:29:02 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE01A8733 for ; Sun, 10 Jan 2016 23:29:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EE9FC326; Mon, 11 Jan 2016 09:29:00 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id x54-W5vo6RTL; Mon, 11 Jan 2016 09:29:00 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0657F230D; Mon, 11 Jan 2016 09:29:00 +0200 (EET) Date: Mon, 11 Jan 2016 09:28:57 +0200 From: Ilari Liusvaara To: Joseph Salowey Message-ID: <20160111072857.GA12169@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 07:29:05 -0000 On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: > Please respond if you have concern about early code point assignment for > the curves listed in draft-ietf-tls-curve25519-01 > . Wasn't that document effectively merged to RFC4492bis? Also, one contention point in recent thread has seemed how to deal with THS. Basically, in the basic variant, there is a check (specified as MUST) that partially mitigates THS (without EMS) to the level of P-256 (and to level stronger than P-384 for X448). But if omitted, THS attacks are easy (assuming no EMS). I did look at if it would be possible to modify PMS derivation to render it immune to THS without requiring any checks nor touching MS derivation. The answer turned out to be negative (through some variants, like the SHA512(A|B|DH(A,B)) one were impossible to exploit given some reasonable-sounding extra assumptions).. -Ilari From nobody Mon Jan 11 00:03:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082241A87A2 for ; Mon, 11 Jan 2016 00:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvD-1m_87w_0 for ; Mon, 11 Jan 2016 00:03:24 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id EA4681A21BA for ; Mon, 11 Jan 2016 00:03:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 716BA24AB; Mon, 11 Jan 2016 10:03:22 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 33TSacVd0hBo; Mon, 11 Jan 2016 10:03:21 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A71E8231; Mon, 11 Jan 2016 10:03:21 +0200 (EET) Date: Mon, 11 Jan 2016 10:03:18 +0200 From: Ilari Liusvaara To: Joseph Salowey Message-ID: <20160111080318.GA12436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160111072857.GA12169@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160111072857.GA12169@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 08:03:27 -0000 On Mon, Jan 11, 2016 at 09:28:57AM +0200, Ilari Liusvaara wrote: > On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: > > Please respond if you have concern about early code point assignment for > > the curves listed in draft-ietf-tls-curve25519-01 > > . > > Wasn't that document effectively merged to RFC4492bis? > > Also, one contention point in recent thread has seemed how to deal > with THS. And as terms of my current position on this: I don't think this is signficant. If you want protection from THS that actually works, you require EMS anyway (or ensure THS is of no consequence at application layer), not try to do TLS configuration "workarounds" (that don't actually work). -Ilari From nobody Mon Jan 11 00:12:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75C61A8797 for ; Mon, 11 Jan 2016 00:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0KG7qiMTaX5 for ; Mon, 11 Jan 2016 00:12:48 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 044611A87C0 for ; Mon, 11 Jan 2016 00:12:48 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id x67so423711869ykd.2 for ; Mon, 11 Jan 2016 00:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g6CbKXCgfxUYxq6oGNEysCK3HiAGlB1of7xsJErNl/A=; b=04OMHesTYCs7YQMpjepID65HBLoxXPZPW3+0vhfpLG9vjySUwAw9HaWZxQVHu25hW+ ZDyaSCONU7n+ZKXmI5cfbqOGSq+VOMS8YCadbe8OqXtFRGsHiBiJsUlk6xk3kbSqJ9T+ Nxw0tEfucIQ9jvzX1Ig4JiVGdzRu/CJohsyEJlmQmOLuC6UQmW3Ky89TucdpI+coFbq2 MWgnOv9XmtJXqXjJjCxovcUZasd6yN3mJkQPSMFj9b68jFiuaxfcrN71IBZ8OFlVPb7e PQLlHOYkVeArLmF8fSkY/R5vjQ8vQxMXJI9wPL4t0TJxby86/QdsjXwyBLI1SjjbX/Z8 3VbA== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr94403016ywe.326.1452499967362; Mon, 11 Jan 2016 00:12:47 -0800 (PST) Received: by 10.13.216.150 with HTTP; Mon, 11 Jan 2016 00:12:47 -0800 (PST) In-Reply-To: <20160111080318.GA12436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160111072857.GA12169@LK-Perkele-V2.elisa-laajakaista.fi> <20160111080318.GA12436@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 11 Jan 2016 00:12:47 -0800 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 08:12:49 -0000 On Mon, Jan 11, 2016 at 12:03 AM, Ilari Liusvaara wrote: > On Mon, Jan 11, 2016 at 09:28:57AM +0200, Ilari Liusvaara wrote: >> On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: >> > Please respond if you have concern about early code point assignment for >> > the curves listed in draft-ietf-tls-curve25519-01 >> > . >> >> Wasn't that document effectively merged to RFC4492bis? >> >> Also, one contention point in recent thread has seemed how to deal >> with THS. > > And as terms of my current position on this: > > I don't think this is signficant. If you want protection from THS that > actually works, you require EMS anyway (or ensure THS is of no > consequence at application layer), not try to do TLS configuration > "workarounds" (that don't actually work). Are you saying that a Suite B only deployment of TLS which does point validation is THS vulnerable? I also don't see what attack on SHA512(A|B|DH(A,B)) needs extra assumptions to be prevented. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 11 00:30:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313E41A87E7 for ; Mon, 11 Jan 2016 00:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXQWuoWWt3K4 for ; Mon, 11 Jan 2016 00:30:28 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id F35581A87A9 for ; Mon, 11 Jan 2016 00:30:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 8D233406; Mon, 11 Jan 2016 10:30:26 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id K8j_wKXkgK1o; Mon, 11 Jan 2016 10:30:26 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5CCDFC4; Mon, 11 Jan 2016 10:30:26 +0200 (EET) Date: Mon, 11 Jan 2016 10:30:23 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20160111083023.GA15940@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160111072857.GA12169@LK-Perkele-V2.elisa-laajakaista.fi> <20160111080318.GA12436@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 08:30:32 -0000 On Mon, Jan 11, 2016 at 12:12:47AM -0800, Watson Ladd wrote: > On Mon, Jan 11, 2016 at 12:03 AM, Ilari Liusvaara > > > > I don't think this is signficant. If you want protection from THS that > > actually works, you require EMS anyway (or ensure THS is of no > > consequence at application layer), not try to do TLS configuration > > "workarounds" (that don't actually work). > > Are you saying that a Suite B only deployment of TLS which does point > validation is THS vulnerable? If both ends are Suite B only, highly unlikely... However, things get more exciting (as in "exciting crypto") if one end is and the other isn't... (Suite B isn't special here, there are other possible profiles with similar properties). -Ilari From nobody Mon Jan 11 10:30:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625E1A01C6 for ; Mon, 11 Jan 2016 10:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFiQqsmj-_vM for ; Mon, 11 Jan 2016 10:30:20 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 745B91A01A2 for ; Mon, 11 Jan 2016 10:30:20 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 36486A8A166A for ; Mon, 11 Jan 2016 18:30:18 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 093181FE0748; Mon, 11 Jan 2016 19:30:17 +0100 (CET) Date: Mon, 11 Jan 2016 19:30:17 +0100 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20160111183017.GA12243@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:30:22 -0000 Hi, After the SLOTH paper, we should think about starting to deprecate TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2. As I understand it, they estimate that both TLS 1.2 with SHA1 and TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be broken. They all depend on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1.1 not adding much. It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything unless you also disable TLS 1.0 and 1.1. Kurt From nobody Mon Jan 11 15:09:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9E1AC41A for ; Mon, 11 Jan 2016 15:09:31 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpp_xXseZKMG for ; Mon, 11 Jan 2016 15:09:29 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C201AC419 for ; Mon, 11 Jan 2016 15:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452553769; x=1484089769; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Hzdu2ZIZlJ9t82S0ZOTOmDKr/tEY4H/8y+IcQ38/d1U=; b=AxYGsYeedxAc2KvCJ9H5iKNGXc+RbrNO3kdYnybxvZJOvTRT497eUNeW 1DbJq0xOU4WpYqHt9zXkdhXdTHk3fB7DWU9kCSNX/8sc2P30blk+J0O3k N4DUQwRBX3TVBAu1SrVPB2QBh1LnA97dOZflWaNZr0Zm9VCzVyG2RPBAx uT7vQgMSwvdsGu/YmcF/dj/hEs6VddshZMZQXEYtn3M60L/uwU4yxW/zq widIkgBh5Mzjn7v5F9aWa3kekSa906Fx8zjWQxkwnUFMgTxXk4XhCbxeX pIs2qrwKgtRagS6nFJzZyybQsSGxzrFaCVP5LrNz1+Ris8Xs2ZLHDup01 w==; X-IronPort-AV: E=Sophos;i="5.20,555,1444647600"; d="scan'208";a="62677016" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2016 12:09:27 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 12:09:26 +1300 From: Peter Gutmann To: Kurt Roeckx , "tls@ietf.org" Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ728Kke Date: Mon, 11 Jan 2016 23:09:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> In-Reply-To: <20160111183017.GA12243@roeckx.be> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:09:31 -0000 Kurt Roeckx writes:=0A= =0A= >After the SLOTH paper, we should think about starting to deprecate TLS 1.0= =0A= >and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.=0A= =0A= The vulnerabilities shown in the SLOTH paper were based on the fact that=0A= implementations still allow MD5 for authentication/integrity protection, ev= en=0A= if (for example) it's explicitly disabled in the config. So the problem=0A= wasn't a fault in the protocol, it's buggy implementations (as it was for o= nes=0A= that allowed 512-bit keys, non-prime primes, and so on). Throwing out TLS = 1.1=0A= based on this seems rather premature.=0A= =0A= >As I understand it, they estimate that both TLS 1.2 with SHA1 and TLS 1.0 = and=0A= >1.1 with MD5|SHA1 currently require about 2^77 to be broken. They all dep= end=0A= >on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1= .1=0A= >not adding much.=0A= =0A= That's presumably based on Joux' multicollisions paper, which also says tha= t=0A= "We also discuss the potential impact of our attack on several published=0A= schemes. Quite surprisingly, for subtle reasons, the schemes we study happe= n=0A= to be immune to our attack".=0A= =0A= More pragmatically, no-one has ever demonstrated any problem with the MD5 |= |=0A= SHA1 construct used in TLS, despite there being obvious problems in MD5 and= =0A= SHA1 by themselves.=0A= =0A= Peter.=0A= From nobody Mon Jan 11 15:14:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDED1AC411 for ; Mon, 11 Jan 2016 15:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut9Xp9w8m2wI for ; Mon, 11 Jan 2016 15:13:58 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E22F1A8F4D for ; Mon, 11 Jan 2016 15:13:58 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so231223966wmf.0 for ; Mon, 11 Jan 2016 15:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=twbP1NRIXqxFiDRH2dRVww5r/CkksKCrne2bEJwS9HE=; b=LDw+jV80VxFiduCNns39HOq0ou7G7b7fjyZUJwdWTxFY3SRKHZM+JgQZs8ZwhCzcBw hYA/FwsNLsLMvYGNhVKnGwd9muK0TAEB7q24DQPGdZHgPa3bbVHN/zKziOClPLAItMZM JbJC1zsA6dsOg2ucFPe3v229ZR+jX53vpvcGqFzXW0Flrc01Uss/VEoYHyxG97Q3O7pA +NOlYn81NXeO21mdQ1uQUr6ZJmRb8u0DTW3ulsB4wtimrth/ftwV66sjDN5y9iMp9r1e ofdmB6oUOZtlwlzaDwmRC20pOEdD/ruMBAQBHt7QUUQutZxfs5XN7M6xNGf+ix87jaPc rkhw== X-Received: by 10.194.75.202 with SMTP id e10mr153789610wjw.160.1452554037082; Mon, 11 Jan 2016 15:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.47.73 with HTTP; Mon, 11 Jan 2016 15:13:37 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> From: Tony Arcieri Date: Mon, 11 Jan 2016 15:13:37 -0800 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=047d7bb049c065c4a705291717ae Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:14:00 -0000 --047d7bb049c065c4a705291717ae Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann wrote: > The vulnerabilities shown in the SLOTH paper were based on the fact that > implementations still allow MD5 for authentication/integrity protection, > even > if (for example) it's explicitly disabled in the config. So the problem > wasn't a fault in the protocol, it's buggy implementations (as it was for > ones > that allowed 512-bit keys, non-prime primes, and so on). Throwing out TLS > 1.1 > based on this seems rather premature. > My understanding is TLS 1.2 specifically was amended to allow MD5 signatures even though this was not the case in previous TLS versions, or at least that was the claim of the miTLS presenters on SLOTH at RealWorldCrypto 2016. If this is the case, this seems like a big regression in TLS 1.2. -- Tony Arcieri --047d7bb049c065c4a705291717ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 11, 2016 at 3:09 PM, Peter Gutmann <pgut001@cs.auckland.ac= .nz> wrote:
The vulnerabili= ties shown in the SLOTH paper were based on the fact that
implementations still allow MD5 for authentication/integrity protection, ev= en
if (for example) it's explicitly disabled in the config.=C2=A0 So the p= roblem
wasn't a fault in the protocol, it's buggy implementations (as it w= as for ones
that allowed 512-bit keys, non-prime primes, and so on).=C2=A0 Throwing out= TLS 1.1
based on this seems rather premature.

M= y understanding is TLS 1.2 specifically was amended to allow MD5 signatures= even though this was not the case in previous TLS versions, or at least th= at was the claim of the miTLS presenters on SLOTH at RealWorldCrypto 2016.<= /div>

If this is the case, this seems like a big regress= ion in TLS 1.2.

--
Tony Arcieri
--047d7bb049c065c4a705291717ae-- From nobody Mon Jan 11 15:17:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD931A8ADF for ; Mon, 11 Jan 2016 15:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 BD3H0FCi40OC for ; Mon, 11 Jan 2016 15:17:12 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E941A8F4D for ; Mon, 11 Jan 2016 15:17:12 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id h5so80643189igh.0 for ; Mon, 11 Jan 2016 15:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=EUN6prsYkvWrznhmlADeCho/Trmm6ExqI4s6ZA2/0WY=; b=l8QOo4USpw2lU4wxJ0q7QF/w6fqAmiSZiCfqEeWkvAIq7Gge7xIwjnFcvewwRMH0TN tvVYmsddlvJ6y2DDqZ4rCuz2XEW9UZnjoKgnInRX5OXExpaMa4mGBM4QkXXHpOLza8qI 7YZW7gl5XDYt3kC+Hf4bzksJhqrHboMtbelI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=EUN6prsYkvWrznhmlADeCho/Trmm6ExqI4s6ZA2/0WY=; b=Wr0OmxNcsCJK8x/6Tg8knmEPxPDyZml3icMDtJLeB+qhjLa3+tmZPwgXnK23ueiWDJ Qp2hELM4RLdvxFzyo2c7JiotlJzivIO4ffoUY+ypxHgy2bEi0jnCsHOZdvrHlQbUY+Ua PY+DZkxNucHlQ1Wbe3g6qjyJ3NXnOfS1OLdpipZnXT8aIFXeKtXtZdXb92NhQj7MnZDY /OtEeHEkCLTmKGxURWnbAzsZZ6Yukvd0869spQ/a7oX7erdKdhChSUjbTGyCXf8y/3H4 BdZ/ry1IPvXmNuZrdsPyHsmr5vxwiF2i1VGjkdCt1pSLw06e61D+4pmZ4YrN21FAmwiq 9hiw== X-Gm-Message-State: ALoCoQmvuVplTYrbc0I5wSieGtKDg/2J3P6zd7d+sv7Pw34Fyt68329eikl5EkDqrca5wSFpRICvGEibFjhqUwNKCi1b2ezNYMVWk/JbO2m+KjPaCXaUoh4= X-Received: by 10.50.171.200 with SMTP id aw8mr15267442igc.77.1452554231572; Mon, 11 Jan 2016 15:17:11 -0800 (PST) MIME-Version: 1.0 References: <20160111183017.GA12243@roeckx.be> In-Reply-To: <20160111183017.GA12243@roeckx.be> From: David Benjamin Date: Mon, 11 Jan 2016 23:17:01 +0000 Message-ID: To: Kurt Roeckx , tls@ietf.org Content-Type: multipart/alternative; boundary=089e010d9562fdbef50529172255 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:17:14 -0000 --089e010d9562fdbef50529172255 Content-Type: text/plain; charset=UTF-8 In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's likely that enterprise deployments are much worse. I started gathering numbers on ServerKeyExchange hashes back in November. The code isn't on Chrome's stable channel yet, but earlier channels say a bit over 5% of ServerKeyExchanges are signed with SHA-1, which is also quite high. I also started probing servers in November and observed: (a) Servers which always sign SHA-1. (b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then they sign SHA-256!?!!? (c) Servers which sign SHA-2 but fail if signature_algorithms omits SHA-1. The ones I looked at were all from serving SHA-1 certificates, so probably their SSL stack compares certs against sig_algs. (b) and (c) mean that getting a sense of the true impact will be complicated until we finish getting SHA-1 certificates out of our system. I have not dug into what's going on with groups (a) and (b) yet. This all is not to say we shouldn't phase these out. But I do not expect it to be a speedy process for browsers. David On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx wrote: > Hi, > > After the SLOTH paper, we should think about starting to deprecate > TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS > 1.2. > > As I understand it, they estimate that both TLS 1.2 with SHA1 and > TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be > broken. They all depend on the chosen prefix collision on SHA1, > with the MD5 part in TLS 1.0 and 1.1 not adding much. > > It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything > unless you also disable TLS 1.0 and 1.1. > > > Kurt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e010d9562fdbef50529172255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In terms of getting rid of TLS 1.0 and TLS 1.1 altogether,= we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. That&#= 39;s quite high, and it's likely that enterprise deployments are much w= orse.

I started gathering numbers on ServerKeyExchange hashes back i= n November. The code isn't on Chrome's stable channel yet, but earl= ier channels say a bit over 5% of ServerKeyExchanges are signed with SHA-1,= which is also quite high.

I also started probing server= s in November and observed:
(a) Servers which always sign SHA-1.
(b)= Servers which sign SHA-1 *unless* signature_algorithms omits it. Then they= sign SHA-256!?!!?
(c) Servers which sign SHA-2 but fail if signature_al= gorithms omits SHA-1. The ones I looked at were all from serving SHA-1 cert= ificates, so probably their SSL stack compares certs against sig_algs.
<= br>(b) and (c) mean that getting a sense of the true impact will be complic= ated until we finish getting SHA-1 certificates out of our system. I have n= ot dug into what's going on with groups (a) and (b) yet.

This al= l is not to say we shouldn't phase these out. But I do not expect it to= be a speedy process for browsers.
<= br>David

On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx <kurt@roeckx.be> wrote:<= br>
Hi,

After the SLOTH paper, we should think about starting to deprecate
TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
1.2.

As I understand it, they estimate that both TLS 1.2 with SHA1 and
TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
broken.=C2=A0 They all depend on the chosen prefix collision on SHA1,
with the MD5 part in TLS 1.0 and 1.1 not adding much.

It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything
unless you also disable TLS 1.0 and 1.1.


Kurt

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--089e010d9562fdbef50529172255-- From nobody Mon Jan 11 15:23:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63261AC428 for ; Mon, 11 Jan 2016 15:23:52 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-A-reyCZLlh for ; Mon, 11 Jan 2016 15:23:50 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F66B1AC427 for ; Mon, 11 Jan 2016 15:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452554631; x=1484090631; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7cszKDCFQ768G6UvFkGS7wv01WIDOndcCxgQoxCk55E=; b=JeQIxcvdbY/J8hIbO2EAu4gQ+bmetvkz6HxhZ27+mVkJ8quOqJ365Pcy hM7vaJDkufi5gLAfrYrc86FcAseaV1AK5V9QSbIAZtge8zdAXIegrYf9x aOSrLstnrJWipGP/8QnypTsMIGTeLvg3G3ARTw4WpQajgAFRo1ADyZl8t XuxvZzRfjEsmApU0Fj+sq2XoTmDNlkes3anIPix0ae/oBZt3pn4n576u3 UqenBb48uYADe2T1EXMcwWA3Tf46G2pII8XSSNpNoYnF4PG1z9RgM0K8b OwxN3aXhTpHZ0l6tdcShues23Z3nDJAGz39X9Tbk4C9PrFvwuBQSeNLks g==; X-IronPort-AV: E=Sophos;i="5.20,555,1444647600"; d="scan'208";a="62679285" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2016 12:23:21 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 12:23:20 +1300 From: Peter Gutmann To: David Benjamin , Kurt Roeckx , "tls@ietf.org" Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ72GS+AgADblhU= Date: Mon, 11 Jan 2016 23:23:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC603E@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:23:52 -0000 David Benjamin writes:=0A= =0A= >In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing=0A= >around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and = it's=0A= >likely that enterprise deployments are much worse.=0A= =0A= Embedded is even worse. I don't have any figures since it's mostly invisib= le=0A= stuff, but anecdotally I'd say the bell-curve is centered around TLS 1.0/1.= 1.=0A= =0A= Peter.=0A= =0A= From nobody Mon Jan 11 15:29:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1151A1A57 for ; Mon, 11 Jan 2016 15:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrcY50f1W-H6 for ; Mon, 11 Jan 2016 15:29:42 -0800 (PST) Received: from BLU004-OMC1S23.hotmail.com (blu004-omc1s23.hotmail.com [65.55.116.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6BC1A1A56 for ; Mon, 11 Jan 2016 15:29:42 -0800 (PST) Received: from BLU177-W18 ([65.55.116.8]) by BLU004-OMC1S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 11 Jan 2016 15:29:41 -0800 X-TMN: [oEO9/rqVHapHbTj8nQCWcikPHcwQiBO6] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: David Benjamin , Kurt Roeckx , "tls@ietf.org" Date: Mon, 11 Jan 2016 15:29:41 -0800 Importance: Normal In-Reply-To: References: <20160111183017.GA12243@roeckx.be>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2016 23:29:41.0949 (UTC) FILETIME=[F266EED0:01D14CC7] Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:29:44 -0000 > (c) Servers which sign SHA-2 but fail if signature_algorithms omits =0A= > SHA-1. The ones I looked at were all from serving SHA-1 certificates=2C = =0A= > so probably their SSL stack compares certs against sig_algs. =0A= I think SChannel is one of them. = From nobody Mon Jan 11 15:38:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714231A90A8 for ; Mon, 11 Jan 2016 15:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7wwuFjTwQOc for ; Mon, 11 Jan 2016 15:38:27 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F381A9084 for ; Mon, 11 Jan 2016 15:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=unZPqkrU1Bi+f0ARzqv9oJKm0F8Kg4SuwqsBCJrBfN4=; b=GgRBvVrhkTX3PXy/UyW72K4BRJc1KbJsv5gQPF+zbYa64qLT1X5JEnt6npPPJvZafNe6bArJqgtlrpc0GhrmCkoyz709PDXaYBXwiNsWoC8es1F7XnAjzTRbiRDC8TPyYEn1Y1elgAXY0CKwPHx5YpUI9+BZ80L3UHXhn8fEwww= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 23:38:25 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 23:38:25 +0000 From: Andrei Popov To: Yuhong Bao , David Benjamin , Kurt Roeckx , "tls@ietf.org" Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4m/d32IOQTx0qUA0UaDUeUnZ728x2AgAADioCAAAFHQA== Date: Mon, 11 Jan 2016 23:38:25 +0000 Message-ID: References: <20160111183017.GA12243@roeckx.be>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:Q88B4tFJGLfolncCbBYOlj9Ft8ZjolrfY/laPOssdNWRF01lfZsZJ0UvBQJiFO21Hr7+5M/1ZbVLG4oB9GyJuQ761Qj+tBD5f/3RMTswboJCZQ73OqyihAJZchhTe9u21xmw6+n7td5BHzl4oP+0Ug==; 24:U6rTaL0fjmGJfnGilOF6DsJhStKlx81NiPrWbmTqiZxQ5uhEOn3dtsaZMXQNVlRrcTsY/gzK7ens9Srf8becAsI8SyNk28doW4/AtGS9CC0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-ms-office365-filtering-correlation-id: 5ff23777-1ddd-419f-dac2-08d31ae04d35 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(189002)(199003)(19580405001)(40100003)(97736004)(74316001)(5008740100001)(5003600100002)(5002640100001)(10290500002)(33656002)(107886002)(5001770100001)(11100500001)(86612001)(86362001)(19580395003)(5004730100002)(54356999)(2501003)(102836003)(8990500004)(1220700001)(99286002)(76576001)(586003)(92566002)(77096005)(6116002)(1096002)(575784001)(2900100001)(76176999)(105586002)(87936001)(10090500001)(5001960100002)(2950100001)(10400500002)(5005710100001)(122556002)(81156007)(101416001)(50986999)(189998001)(106356001)(106116001)(2906002)(15975445007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 23:38:25.7712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:38:29 -0000 Yes, per RFC 5246:=20 " If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao Sent: Monday, January 11, 2016 3:30 PM To: David Benjamin ; Kurt Roeckx ; t= ls@ietf.org Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms > (c) Servers which sign SHA-2 but fail if signature_algorithms omits=20 > SHA-1. The ones I looked at were all from serving SHA-1 certificates,=20 > so probably their SSL stack compares certs against sig_algs. I think SChannel is one of them. =20 _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7cdca8115118694f6fd88808d31adf1a2d%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3DNMe0Q4tKP6RdFTuDEkKavQF4YysdBEBX%2ftX4u1SEw7o%3d From nobody Mon Jan 11 15:43:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5669D1AC434 for ; Mon, 11 Jan 2016 15:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBpkhnCBuJMo for ; Mon, 11 Jan 2016 15:43:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094DB1AC431 for ; Mon, 11 Jan 2016 15:43:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E08F8284F19; Mon, 11 Jan 2016 23:43:14 +0000 (UTC) Date: Mon, 11 Jan 2016 23:43:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160111234314.GD18704@mournblade.imrryr.org> References: <20160111183017.GA12243@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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 Jan 2016 23:43:17 -0000 On Mon, Jan 11, 2016 at 11:38:25PM +0000, Andrei Popov wrote: > Yes, per RFC 5246: > " If the client provided a "signature_algorithms" extension, then all > certificates provided by the server MUST be signed by a > hash/signature algorithm pair that appears in that extension." Yes. Though for the record, and as discussed ad nauseam before, this is a bug in the RFC, and should not be implemented as written. (Please let's not re-open that thread). Ideally, at some point SChannel will implement the TLS 1.3 draft bug fix also for TLS 1.2. -- Viktor. From nobody Mon Jan 11 16:31:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078ED1A1AE1 for ; Mon, 11 Jan 2016 16:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbXplqkqx6xE for ; Mon, 11 Jan 2016 16:30:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A17B1A92AF for ; Mon, 11 Jan 2016 16:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hu/wvHoQOo3dOTj7EpT46ErTssOH7/CIInSFXGFPBQo=; b=EwHRc4D+HWrXIkcUpwfH0LP7bQFHNb+JFcgHeGMxYa8JhWWzsw2l7sdzNxY0dTXS2Y4oWVpRlHz0b+wzOHFIO3I5AfR+KD/ou0etub6fsAGUnjSC4BFRoIZnN+f8LpYQiy12Zjy1BVAj2HxYNrbyOOanYaCuc2DXzmgL3050/Fg= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 00:30:52 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 00:30:52 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4m/d32IOQTx0qUA0UaDUeUnZ728x2AgAADioCAAAFHQIAAAoIAgAAM9XA= Date: Tue, 12 Jan 2016 00:30:52 +0000 Message-ID: References: <20160111183017.GA12243@roeckx.be> <20160111234314.GD18704@mournblade.imrryr.org> In-Reply-To: <20160111234314.GD18704@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:MkCwf6VYoipEav8QQezPuL9uPzzarm3XsnkrkQZOs7mBiRT91ozHMZTFyB+TGBxt+SYRbH1qPjRWz2DZGdmqq/278G4/I0CaBXN9XPjE446EydeUneb1OMSD4ZFEHJUkGK9erPqBc0Ei/QKJQ8rYmg==; 24:QlXMYtdotg4lk4HbLREku6Yzq27q3FqD+a+r9XPT2NxMYGP0rQyPxUOW+Y87euOnpcjWc0Wg748vajzuM1P0e6a7Zd/y5ILNX7sq2XFnx80= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-ms-office365-filtering-correlation-id: 8e71b1cc-cadd-4e24-a63b-08d31ae7a0b9 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(13464003)(189002)(377454003)(86362001)(1730700002)(86612001)(74316001)(97736004)(50986999)(107886002)(93886004)(5005710100001)(5003600100002)(76176999)(10400500002)(101416001)(2900100001)(76576001)(77096005)(87936001)(81156007)(106116001)(105586002)(99286002)(40100003)(110136002)(5001960100002)(106356001)(575784001)(5002640100001)(450100001)(54356999)(586003)(92566002)(6116002)(19580395003)(102836003)(19580405001)(122556002)(15975445007)(1096002)(189998001)(2351001)(33656002)(2950100001)(10090500001)(1220700001)(10290500002)(11100500001)(2501003)(5004730100002)(2906002)(8990500004)(5008740100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 00:30:52.3785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:31:00 -0000 > (Please let's not re-open that thread). Indeed, let's agree to disagree on this. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Monday, January 11, 2016 3:43 PM To: tls@ietf.org Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms On Mon, Jan 11, 2016 at 11:38:25PM +0000, Andrei Popov wrote: > Yes, per RFC 5246:=20 > " If the client provided a "signature_algorithms" extension, then all > certificates provided by the server MUST be signed by a > hash/signature algorithm pair that appears in that extension." Yes. Though for the record, and as discussed ad nauseam before, this is a = bug in the RFC, and should not be implemented as written. (Please let's not re-open that thread). Ideally, at some point SChannel will implement the TLS 1.3 draft bug fix al= so for TLS 1.2. --=20 Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7cf0ce972e5c7b41e5454f08d31ae0fe01%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3D1s56rzccDOpU1SudCjc4k1LeVmeVsPxqy6XeGDZhQTM%3d From nobody Mon Jan 11 16:33:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EAA1ACC72 for ; Mon, 11 Jan 2016 16:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKVgeQyyXOKI for ; Mon, 11 Jan 2016 16:32:59 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE731AC3CF for ; Mon, 11 Jan 2016 16:32:58 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id a85so373362313ykb.1 for ; Mon, 11 Jan 2016 16:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ljRJ5UUJulzxoufy5gsAzyvi1XAIfi959w7X/1eeUV8=; b=iIXo5qv8J78SMpcc0ZAtvt+XjXzjBdgg994ZAjX/0E9WIllMRPuqtkvU4i/btrNTxX iKLP35hyKhY72DOigFtkf8ijXyyf0XXGTkDfWQaB7EZfiYieqAUJLgtaJ6PMqDehRyEb Rp3xJFCP5Z8DC53/OAxKqn9TVcYo0u41mlDcvnsYY51bTV/NLLV1yx2Bl78s3XPfn3Ah WnrJJv6n/+Dk9NcKjVHm1SkajPxpLHZDIduoLiNr0VLgFHA/uW1Jz/B1z6Jq53gZMi7R 3hIzJziN7SrZHXgukuHfckMR68sseIGFZCQ1y1NytLKz5cdQlXy0SZ9ANImvGHUj+Hrx 1xCg== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr92630932ywa.244.1452558778202; Mon, 11 Jan 2016 16:32:58 -0800 (PST) Received: by 10.13.216.150 with HTTP; Mon, 11 Jan 2016 16:32:58 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Jan 2016 16:32:58 -0800 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:33:00 -0000 On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann wrote: > Kurt Roeckx writes: > >>After the SLOTH paper, we should think about starting to deprecate TLS 1.0 >>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2. > > The vulnerabilities shown in the SLOTH paper were based on the fact that > implementations still allow MD5 for authentication/integrity protection, even > if (for example) it's explicitly disabled in the config. So the problem > wasn't a fault in the protocol, it's buggy implementations (as it was for ones > that allowed 512-bit keys, non-prime primes, and so on). Throwing out TLS 1.1 > based on this seems rather premature. Do the RFCs require the relevant checks or not? And given that implementations frequently get these sorts of things wrong, how do we make the standard robust against it? > >>As I understand it, they estimate that both TLS 1.2 with SHA1 and TLS 1.0 and >>1.1 with MD5|SHA1 currently require about 2^77 to be broken. They all depend >>on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1.1 >>not adding much. > > That's presumably based on Joux' multicollisions paper, which also says that > "We also discuss the potential impact of our attack on several published > schemes. Quite surprisingly, for subtle reasons, the schemes we study happen > to be immune to our attack". And if you actually read beyond the abstract, you would see that he never considers the straight up concatenation of MD5 and SHA1 which is indeed vulnerable, exactly matching the attacks he develops. > > More pragmatically, no-one has ever demonstrated any problem with the MD5 || > SHA1 construct used in TLS, despite there being obvious problems in MD5 and > SHA1 by themselves. That's because real cryptographers understand that this is only 64 times better then SHA1, and so don't bother to mention it. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 11 16:33:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5C71ACC82 for ; Mon, 11 Jan 2016 16:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQT08kx0wCh6 for ; Mon, 11 Jan 2016 16:33:12 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640281ACC83 for ; Mon, 11 Jan 2016 16:33:12 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id g73so171196748ioe.3 for ; Mon, 11 Jan 2016 16:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mWd0qA373duq2oFB8qR2uLd5I03Inwek0FKNZbiW5JM=; b=AqNpD9jv/JiTAFcgcLk9pywSK6mseY1S3DlWvvnsEHWt8cC3xkcSO8MoxQVOBEknTz /8Ak7IpXhscO0P3ZZvQK/d5H6sjqJwUKgWkJQQn59B79R24ql1MjkQz5nYl9AuzQuHGT i9RkDi+3bp3BbiOT+7AHn0L8MZBpxdelc27AKYZm9ihrf/vib0Ziy4EVT+AVQugNkBvP g/GEJnjMO4JlVaUL6rqiIfxKPDZibE5kjoMc6omY2Qq3Cq0YXQecwN43iPt1OY0SqpWw GmIfK0y9DQEjIbLkmna5rlC53WvBvq10JeRkJ7Q/N7hvYLMe0x/f4Gc1IWW69Np4hQfq FIMA== MIME-Version: 1.0 X-Received: by 10.107.33.12 with SMTP id h12mr59873322ioh.108.1452558791771; Mon, 11 Jan 2016 16:33:11 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 11 Jan 2016 16:33:11 -0800 (PST) In-Reply-To: <20160111183017.GA12243@roeckx.be> References: <20160111183017.GA12243@roeckx.be> Date: Tue, 12 Jan 2016 11:33:11 +1100 Message-ID: From: Martin Thomson To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:33:13 -0000 On 12 January 2016 at 05:30, Kurt Roeckx wrote: > After the SLOTH paper, we should think about starting to deprecate > TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS > 1.2. Let's be clear about this: TLS 1.0 represents far too high a proportion of our usage to remove it at this point. TLS 1.2 growth is still solid, but it really isn't that long ago that we turned on TLS 1.2. The encouragement we give people to upgrade will remain our best option until TLS 1.0 usage drops an awful lot. From nobody Mon Jan 11 16:38:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBD91ACCC7 for ; Mon, 11 Jan 2016 16:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E16i83eVn4Mo for ; Mon, 11 Jan 2016 16:38:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F406E1ACC92 for ; Mon, 11 Jan 2016 16:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LC/k+zp4XvUblv2LdGLO3L08RvSgDjxJOzRknfkDBTk=; b=UuHE0FHKE1CWKwM3vvR0DklZ1OUkDwgUfBNLVq7beKintH+Pjlp0Y2ZJ8TCcG1BE7LB4xnxfdHlDv8GGKusmtMkE/srbqiS73I6rrJt1MYQ98H+JnbUOJThOSzo053/1UuN6Q182P2ma8hWSkXbQWpM7z6fIbelDYOJ/DX469gc= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 00:38:02 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 00:38:02 +0000 From: Andrei Popov To: Martin Thomson , Kurt Roeckx Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4m/d32IOQTx0qUA0UaDUeUnZ73CGWAgAAAkdA= Date: Tue, 12 Jan 2016 00:38:02 +0000 Message-ID: References: <20160111183017.GA12243@roeckx.be> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:ZTTKhovkKs/DCPpmm3qJ5/K90Sdvv/uOZKv9QVQQK0g3xMA4j8wDmR/HAmzOzSu4cdxhYc0BZ7avgPMzlW/E0y9Q3bUO8CO91Bj6xcRwM/7Y1Axz/BkpTOfl2ePhqIqEia69nxxWFeVWjRkfDErwsQ==; 24:8g35hBEV0bo4glvnHe1G3puT/4EDAOqwWNTro3mW3PE8fROGAZmvru0uJZZ9ca/JobZ5MhnxpcT95t/DVA38eKiA+upRfbvDX3QgD5kJjdc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-ms-office365-filtering-correlation-id: aa541afe-be06-49f4-00a1-08d31ae8a128 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(377454003)(24454002)(189002)(5001960100002)(106116001)(11100500001)(8990500004)(4326007)(5003600100002)(99286002)(5004730100002)(77096005)(33656002)(2950100001)(19580395003)(10090500001)(1096002)(86362001)(2900100001)(50986999)(2906002)(19580405001)(5008740100001)(6116002)(101416001)(15975445007)(86612001)(122556002)(97736004)(87936001)(81156007)(74316001)(5002640100001)(105586002)(1220700001)(92566002)(40100003)(106356001)(10290500002)(5001770100001)(586003)(189998001)(76576001)(10400500002)(76176999)(54356999)(102836003)(5005710100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 00:38:02.7235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:38:26 -0000 Yes, our telemetry shows the same. The use of TLS 1.2 increases and the use= of TLS 1.0 goes down, but it will likely be a while before we can disable = TLS 1.0 by default in Windows. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Monday, January 11, 2016 4:33 PM To: Kurt Roeckx Cc: tls@ietf.org Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms On 12 January 2016 at 05:30, Kurt Roeckx wrote: > After the SLOTH paper, we should think about starting to deprecate TLS=20 > 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2. Let's be clear about this: TLS 1.0 represents far too high a proportion of our usage to remove it at this point. TLS 1.2 growth is still solid, but it really isn't that long ago that we turned on TLS 1.2. The encouragement we give people to upgrade will remain our best option until TLS 1.0 usage drops an awful lot. _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c6fb3e54eee074bb130fc08d31ae7f945%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3D1VqipRFwf5mpoYunrkaM3Uy%2f22nZWtMGg5m27W72aBU%3d From nobody Mon Jan 11 17:28:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA60A1ACD02 for ; Mon, 11 Jan 2016 17:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnMHLQjCMXOh for ; Mon, 11 Jan 2016 17:28:45 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 82B041ACD01 for ; Mon, 11 Jan 2016 17:28:45 -0800 (PST) Received: from [173.75.83.132] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aInl8-0001Fp-3Y; Mon, 11 Jan 2016 20:28:30 -0500 Date: Mon, 11 Jan 2016 17:28:33 -0800 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79a506127e315a26c1e244823b78ab1dc2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.132 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 01:28:47 -0000 On 1/11/16 at 4:32 PM, watsonbladd@gmail.com (Watson Ladd) wrote: >Do the RFCs require the relevant checks or not? And given that >implementations frequently get these sorts of things wrong, how do we >make the standard robust against it? The best way I can think of is to test to see if the checks are=20 being done. For example, if a implementation is supposed to=20 check if a number is prime, send a non-prime and see if it takes=20 the correct action. Publicly available test suites would be a good step toward=20 implementing this strategy. I will note that as the Javascript=20 standards people were developing the ES2015 standard, they=20 maintained a test suite which following the evolving standard. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Mon Jan 11 18:02:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF01ACD21 for ; Mon, 11 Jan 2016 18:02:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaIyoCacJRx0 for ; Mon, 11 Jan 2016 18:01:58 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E951A1F16 for ; Mon, 11 Jan 2016 18:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452564118; x=1484100118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W05NnTU68YVD6JFVhUjPKmurJsx2ksK9glljSlikfFQ=; b=eSqoYrT+PJ3xNDchqxDDc9ubumc0mHFR4+M4r2RmUTzxkM7qwDsiQrNo bGIBZZvFfmui4Kq63y8I7VpBUQd8/2m9yWh1K/PuLM7p2yJFk4WxNB+GB IjIU5absRtoetiA84o6XwD0Gqo3uLR+2m5VvSB7UFFRFak3CBdCPWpFTr v83JgbsrB0gWdEkQTzNaUd2WZkeryIkL9HciHlNAQBUoEFUpBYUwOWOtL 3vs9kaV646JQ945U1XEGRB2+ucCtWkv3kfSZj11GzFDiCVWMh07ujbVoj B0kWL2/docDt3IUoAQ5g9ZyAfo60QYNouFNCMdWdmCpuEEPHvXvAOCi5K w==; X-IronPort-AV: E=Sophos;i="5.20,555,1444647600"; d="scan'208";a="62708016" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2016 15:01:55 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 15:01:55 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ728Kke//89vgCAAPKVvA== Date: Tue, 12 Jan 2016 02:01:55 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 02:02:01 -0000 Watson Ladd writes:=0A= =0A= >Do the RFCs require the relevant checks or not?=0A= =0A= No, they just specify the algorithms and bits on the wire (with a side-orde= r=0A= of MTI stuff for interoperability). It's up to implementers to not do stup= id=0A= things.=0A= =0A= >That's because real cryptographers understand that this is only 64 times= =0A= >better then SHA1, and so don't bother to mention it.=0A= =0A= If it's so trivial to compromise then why, of all the many, many papers=0A= attacking TLS, has no-one every published an attack based on this? In fact= ,=0A= since it's so easy, perhaps you could publish a paper demonstrating it in= =0A= practice?=0A= =0A= Peter.=0A= From nobody Mon Jan 11 18:03:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8241ACD18 for ; Mon, 11 Jan 2016 18:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJCssfhdzFcG for ; Mon, 11 Jan 2016 18:03:49 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 067231A1F16 for ; Mon, 11 Jan 2016 18:03:49 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id v14so359548300ykd.3 for ; Mon, 11 Jan 2016 18:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M3deKsJA8oG7D8xFSZ7Q1tzYT9q/u6yS8HUbVUE1gMw=; b=G2dDVHqw38LFUE/EuVhiqNDkMDCRddZJruEs3/xIKjRhPj8+LfXDt7WEgbw7vK7BaC +rmy0B6Fb3UIqTvpixtN20SGpvDkTi5i6B7YX/4DblX5iTo5oIKKQBAxSwyH03fj9+Jr Ix7X/pmPJEQ85T5TYxud6xo5XBEPgASPe87oTYDYDq1jXISsAUTp3y4M7UMVSjbpkeYF DIPK2V3qflYsbLxyTAl4FTwNZFp9F7H2Fs5EMQGQ6N3G/RA1mes/4xijgZO0dqpYYPxi 90GwOMkvUguResFzvfN5QU/yyBNz2/vQKjzzHVjVOfrRoPuf+/5d9Q5xKpaVHoiCO1ZG O6Ww== MIME-Version: 1.0 X-Received: by 10.129.123.134 with SMTP id w128mr71731854ywc.345.1452564228254; Mon, 11 Jan 2016 18:03:48 -0800 (PST) Received: by 10.13.216.150 with HTTP; Mon, 11 Jan 2016 18:03:48 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 11 Jan 2016 18:03:48 -0800 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 02:03:51 -0000 On Mon, Jan 11, 2016 at 6:01 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>Do the RFCs require the relevant checks or not? > > No, they just specify the algorithms and bits on the wire (with a side-order > of MTI stuff for interoperability). It's up to implementers to not do stupid > things. > >>That's because real cryptographers understand that this is only 64 times >>better then SHA1, and so don't bother to mention it. > > If it's so trivial to compromise then why, of all the many, many papers > attacking TLS, has no-one every published an attack based on this? In fact, > since it's so easy, perhaps you could publish a paper demonstrating it in > practice? SHA-1 collisions have not yet been found. Marc Stevens has published algorithms he claims reduce the complexity of finding these collisions to feasible amounts, but they have not yet been run. However, free-start collisions have been found, as have ways to modify constants in the SHA-1 IV to get collisions. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 11 18:07:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD41ACD2D for ; Mon, 11 Jan 2016 18:07:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCpqdAENjwWY for ; Mon, 11 Jan 2016 18:06:59 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815611ACD2A for ; Mon, 11 Jan 2016 18:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452564419; x=1484100419; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X8zWXugIszEgLFqKL8ZtePxcV7PiSfW5fON4vd+L6/g=; b=mH3cHKFLS6xsRGLuxqA8s+zAWipKxpaXZjIH+ZK8KTNNEkc2IGfUcGHi dHf4jxKIvWTdKqWjPvFIh4aA5+uFhE2q5WHys0vYg0JE+bmSDQ+N+SHyx sczKTRhSKmed0pw+AkNyAbimPe7JAoOeeB0J7Pe4ob3x+RUqjfcDWApdF 7mo+RxOJqelREqkKm81/cczdvtiArKLWREeFU/ID73KUWNXcFp5EKdL08 kRSIiTHTWoQRPIyqvR015i+S9rEfLB10NcAHIjf5L3nh74agPMiHFAJmI ACnerxgEn7Kc8jVtu1eo4RGvxncSsKakGUMxrzH83MY//lab6bPkNKuQa A==; X-IronPort-AV: E=Sophos;i="5.20,555,1444647600"; d="scan'208";a="62709152" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2016 15:06:58 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 15:06:57 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ728Kke//89vgCAAPKVvP//JswAgADalN8= Date: Tue, 12 Jan 2016 02:06:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC619C@uxcn10-5.UoA.auckland.ac.nz> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 02:07:01 -0000 Watson Ladd writes:=0A= =0A= >SHA-1 collisions have not yet been found. Marc Stevens has published=0A= >algorithms he claims reduce the complexity of finding these collisions to= =0A= >feasible amounts, but they have not yet been run. However, free-start=0A= >collisions have been found, as have ways to modify constants in the SHA-1 = IV=0A= >to get collisions.=0A= =0A= I'm aware of that (and related) work, but this is about finding=0A= multicollisions in MD5 || SHA1.=0A= =0A= Peter.=0A= From nobody Mon Jan 11 18:26:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F441ACD40 for ; Mon, 11 Jan 2016 18:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_T0zZtv3NX8 for ; Mon, 11 Jan 2016 18:26:54 -0800 (PST) Received: from smtp2.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DBB1ACD41 for ; Mon, 11 Jan 2016 18:26:53 -0800 (PST) Received: from 127.0.0.1 (bl15-129-177.dsl.telepac.pt [188.80.129.177]) (authenticated bits=0) by smtp2.dei.uc.pt (8.14.4/8.14.4) with ESMTP id u0C2QLQh008539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 02:26:22 GMT To: Watson Ladd References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz> From: Samuel Neves X-Enigmail-Draft-Status: N1110 Message-ID: <5694644C.5090904@dei.uc.pt> Date: Tue, 12 Jan 2016 02:26:20 +0000 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp2.dei.uc.pt [193.137.203.234]); Tue, 12 Jan 2016 02:26:22 +0000 (WET) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: u0C2QLQh008539 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.248, required 3.252, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00, TVD_RCVD_IP 0.00, TVD_RCVD_IP4 0.00) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 02:26:56 -0000 On 12/01/2016 02:03, Watson Ladd wrote: > However, free-start collisions have been found, as have ways to modify > constants in the SHA-1 IV to get collisions. To be clear, the research into maliciously altering SHA-1 to make collisi= ons easier changed the K_i constants added during the rounds, not the IV. From nobody Mon Jan 11 19:42:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98BB1ACDA8 for ; Mon, 11 Jan 2016 19:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcv7ypzbzuir for ; Mon, 11 Jan 2016 19:42:49 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31661ACDA1 for ; Mon, 11 Jan 2016 19:42:48 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id q19so179666910qke.3 for ; Mon, 11 Jan 2016 19:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=R1AgmzRqF88/rbjL1Ld+JQ06YribtFiqV3wYlmc3JGo=; b=eopckfNhM3ncnBCABK3ec/LTIBU29Do79BzYzWZtjuxUQ0b6ozhDYzvdHgj3/Yqo3c mSxt2yjk+8uuYVIrXGLHFcfE7tnEC7TQ/uccyaKFbKvK7V648dLYgxGPOxOMszPug4d9 PCC8hIOiqk/inrYdaNP75TcdeBlOAfA6YFvrFquDN9YYmcsfsf6izYxmXcCFpXrpG8Ly MNK2anTeorDAsxhB1InKZpgkKfioB1wP7dy45wXoYF0wufmwGi2juVVVMRZRVGZ/84MA oOkXOR4wnQuR9doxUoL9gW+H6qqvmkU1q/+m908W7kAFlI5YrkL2DLrIIUhkRLLt1eLh sL3g== X-Received: by 10.55.74.86 with SMTP id x83mr41490961qka.89.1452570168116; Mon, 11 Jan 2016 19:42:48 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w71sm26715332qha.30.2016.01.11.19.42.47 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jan 2016 19:42:47 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Mon, 11 Jan 2016 22:42:45 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601112242.46115.davemgarrett@gmail.com> Archived-At: Subject: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 03:42:50 -0000 On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote: > My understanding is TLS 1.2 specifically was amended to allow MD5 > signatures even though this was not the case in previous TLS versions, or > at least that was the claim of the miTLS presenters on SLOTH at > RealWorldCrypto 2016. > > If this is the case, this seems like a big regression in TLS 1.2. I'd like to propose killing the low hanging fruit first, and then continue to build on top of that. No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping MD5||SHA1 in old TLS for compatibility and we are well aware that needs to go eventually too. Thus, I suggest we publish an MD5 diediedie standards track RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standards. Constructions using MD5 with something else (namely MD5||SHA1) would also be explicitly recommended against in existing specifications, and explicitly prohibited in all new drafts (even if unlikely). Also, when I say "prohibited" here, I mean _completely_. No MD5 function should remain in the relevant codebase; if MD5||SHA1 support is continued, there should be one function that does only that without any way to get a plain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are also fine for that, and if you're wrong, it's safer) There are too many implementation bugs in this realm to not state this explicitly [0]. Note that continued support of trust anchors with MD5 hashes is not dependent on this, as we've already agreed they don't need to be validated. (they need to be phased out, but with less urgency) If used within this specific context, nothing even needs the ability to understand MD5 hashes at all in order to handle these; the certificate as a whole is trusted or not. Dave PS To whomever came up with the "diediedie" term, thank you. ;) [0] Note the 3 disabled-but-accepted bugs listed here: https://www.mitls.org/pages/attacks/SLOTH#disclosure From nobody Mon Jan 11 19:54:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275631ACDC0 for ; Mon, 11 Jan 2016 19:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAuWAtdW9IJI for ; Mon, 11 Jan 2016 19:54:15 -0800 (PST) Received: from BLU004-OMC3S12.hotmail.com (blu004-omc3s12.hotmail.com [65.55.116.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956671ACDBF for ; Mon, 11 Jan 2016 19:54:15 -0800 (PST) Received: from BLU177-W29 ([65.55.116.73]) by BLU004-OMC3S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 11 Jan 2016 19:54:15 -0800 X-TMN: [OIhNk6YVn+bE/6uuJhO6EZqkN4q8Akx9] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Dave Garrett , "tls@ietf.org" Date: Mon, 11 Jan 2016 19:54:14 -0800 Importance: Normal In-Reply-To: <201601112242.46115.davemgarrett@gmail.com> References: <20160111183017.GA12243@roeckx.be>, <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz>, , <201601112242.46115.davemgarrett@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2016 03:54:15.0146 (UTC) FILETIME=[E79094A0:01D14CEC] Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 03:54:19 -0000 > Note that continued support of trust anchors with MD5 hashes is not depen= dent on this=2C as we've already agreed they don't need to be validated. (t= hey need to be phased out=2C but with less urgency) If used within this spe= cific context=2C nothing even needs the ability to understand MD5 hashes at= all in order to handle these=3B the certificate as a whole is trusted or n= ot.=0A= That being said=2C I think there are very few of the roots left in Mozilla'= s root store anyway. Similarly HMAC-MD5 is safe too but the only non-export= cipher suite that uses it is the RC4 one anyway.=0A= =0A= Yuhong Bao = From nobody Mon Jan 11 20:24:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F451ACDE1 for ; Mon, 11 Jan 2016 20:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41gWScT5hFSF for ; Mon, 11 Jan 2016 20:24:29 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDD11ACDDB for ; Mon, 11 Jan 2016 20:24:29 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id e65so56058078pfe.0 for ; Mon, 11 Jan 2016 20:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dJD8KusB3oslbB4l5qqfWn94FIKgmfCvxToonR8AAqE=; b=qOftzuFYNUlQrOiSx8XsyM/BoZJsuBJrYZ/GYHE2fy8F1csuGT/qDDDbm0I7YyEMaB YUvluMANG07YCC/VjQ0Fcx6evoX5dBmgTmFASNX0CjpdQcTJK8GTJ1tglZKbkVbl9u+q Rgow8xGsMKZDjY7PeT+vvarkBd/K/MlLOgk8K/SOjWolCpgSyqmMjFuuTK0NdjHbGtSm 3H+aPJfuOVh9Xe7zLjYF67mQoELQRWMiPC5SPNUBHRzlFip7u3wMHBowftCA8tTH81OT Bh3T1U+7urrEsERseEJZ0ENt6ykxvtS9ktyWuRXcvWzkAdJWBq2WFNmXgGXBDQvjx2/w ovGA== MIME-Version: 1.0 X-Received: by 10.98.19.65 with SMTP id b62mr778403pfj.59.1452572668933; Mon, 11 Jan 2016 20:24:28 -0800 (PST) Received: by 10.66.235.7 with HTTP; Mon, 11 Jan 2016 20:24:28 -0800 (PST) In-Reply-To: <201601112242.46115.davemgarrett@gmail.com> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <201601112242.46115.davemgarrett@gmail.com> Date: Tue, 12 Jan 2016 04:24:28 +0000 Message-ID: From: Loganaden Velvindron To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 04:24:30 -0000 On Tue, Jan 12, 2016 at 3:42 AM, Dave Garrett wrot= e: > On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote: >> My understanding is TLS 1.2 specifically was amended to allow MD5 >> signatures even though this was not the case in previous TLS versions, o= r >> at least that was the claim of the miTLS presenters on SLOTH at >> RealWorldCrypto 2016. >> >> If this is the case, this seems like a big regression in TLS 1.2. > > I'd like to propose killing the low hanging fruit first, and then continu= e to build on top of that. > > No sane person disputes that MD5 needs to be eradicated ASAP. We're keepi= ng MD5||SHA1 in old TLS for compatibility and we are well aware that needs = to go eventually too. Thus, I suggest we publish an MD5 diediedie standards= track RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standar= ds. Constructions using MD5 with something else (namely MD5||SHA1) would al= so be explicitly recommended against in existing specifications, and explic= itly prohibited in all new drafts (even if unlikely). > > Also, when I say "prohibited" here, I mean _completely_. No MD5 function = should remain in the relevant codebase; if MD5||SHA1 support is continued, = there should be one function that does only that without any way to get a p= lain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are als= o fine for that, and if you're wrong, it's safer) There are too many implem= entation bugs in this realm to not state this explicitly [0]. > I completely agree. At least one open source SSL/TLS implementation is looking at purging their code of MD5 functions. > Note that continued support of trust anchors with MD5 hashes is not depen= dent on this, as we've already agreed they don't need to be validated. (the= y need to be phased out, but with less urgency) If used within this specifi= c context, nothing even needs the ability to understand MD5 hashes at all i= n order to handle these; the certificate as a whole is trusted or not. > > > Dave > > > PS > To whomever came up with the "diediedie" term, thank you. ;) > > > [0] Note the 3 disabled-but-accepted bugs listed here: > https://www.mitls.org/pages/attacks/SLOTH#disclosure > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jan 11 21:32:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED611ACE1B for ; Mon, 11 Jan 2016 21:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEl_9N-tmQn5 for ; Mon, 11 Jan 2016 21:32:09 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD151ACE1A for ; Mon, 11 Jan 2016 21:32:09 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9D74B284E5C; Tue, 12 Jan 2016 05:32:08 +0000 (UTC) Date: Tue, 12 Jan 2016 05:32:08 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160112053208.GE18704@mournblade.imrryr.org> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <201601112242.46115.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201601112242.46115.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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 Jan 2016 05:32:12 -0000 On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote: > No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping > MD5||SHA1 in old TLS for compatibility and we are well aware that needs > to go eventually too. Thus, I suggest we publish an MD5 diediedie standards > track RFC to prohibit ALL standalone MD5 use in ALL IETF > protocols/standards. With some exceptions, for example: * As you note in your last comment, X.509 self-signatures via MD5 may continue to be ignored, once MD5 is "banned" in the same way that they should have been ignored before it was "banned". * S/MIME parsers may continue to parse old S/MIME messages with MD/5 signatures. More generally, Encrypted data at rest may need support for MD5 for the lifetime of the data (until re-encrypted, ...). * PEM files holding RSA private encrypted keys may continue to use the legacy MD5-based KDF so that the keys can be decrypted. > Also, when I say "prohibited" here, I mean _completely_. There is no Internet police, and the IETF does not get to prohibit the use of MD5, we only get to write protocol standards. > No MD5 function should remain in the relevant codebase; In particular the IETF does not get to tell anyone which functions they get to include in their codebase. So no IETF document saying such a thing makes much difference. > if MD5||SHA1 support is continued, > there should be one function that does only that without any way to get > a plain MD5 hash. This turns out to be a good idea anyway, thus, for example, OpenSSL 1.1.0-apha2 just recently added an EVP_md5_sha1() hash function. -- Viktor. From nobody Mon Jan 11 23:30:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AC51A034C for ; Mon, 11 Jan 2016 23:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H4ywy2yK4po for ; Mon, 11 Jan 2016 23:30:23 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ADD1A033A for ; Mon, 11 Jan 2016 23:30:23 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id t64so7469293qke.1 for ; Mon, 11 Jan 2016 23:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=nmLRaLzxboquzOGIEeh7c9XRNifWxPJCmMYNpdfZnHs=; b=S9YmLQ/RZh2DS7DgmmaIPWsjRe9yjcq88NWhSJ4aaA+SAHL9Mi3w5+mq9IrpQ1/iyq uZ3al1TF0wPLOWrjqJhgwxsRuI92dJLhLcuKI3Nu5ZURfstqlZVRj3J/Z+zEtsWVzbDQ MbVX5mqL0F3+25G2QPrFDX/wmGuu3ovyjaOO2ue1r13LkOocH9I9cDXfyBa+PQjbFmWV 2BmvzGjZ6BvpkpoWZKhvx7Jw/0Jaf22Ugrg08AZKs0ciWjWHI81++ndosfbaxiikE2AM uFiZ6UqDL2Tn4NnITcCLFeWq7ghS6g8UE825HWKTP/Zgal1Zj41ztGDenqOvcKqShGTf swbw== X-Received: by 10.55.22.9 with SMTP id g9mr30428283qkh.12.1452583822725; Mon, 11 Jan 2016 23:30:22 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id h14sm40208483qhc.33.2016.01.11.23.30.22 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jan 2016 23:30:22 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Tue, 12 Jan 2016 02:30:20 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160111183017.GA12243@roeckx.be> <201601112242.46115.davemgarrett@gmail.com> <20160112053208.GE18704@mournblade.imrryr.org> In-Reply-To: <20160112053208.GE18704@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201601120230.21146.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 07:30:25 -0000 On Tuesday, January 12, 2016 12:32:08 am Viktor Dukhovni wrote: > > Also, when I say "prohibited" here, I mean _completely_. > > There is no Internet police, and the IETF does not get to prohibit > the use of MD5, we only get to write protocol standards. Of course, but the IETF can state that MD5 is not considered secure, must not be used in any of its old specifications (I do agree that a short list of exceptions will be needed), and put forth a set of basic requirements to continue to use IETF specifications with any intent of considering them even slightly secure. The IETF can't directly enforce this, but plenty of organizations do take this sort of thing seriously, even if others ignore it completely. I would hope that lawyers that wish to reduce their companies' liability for ever-frequent data breaches might pay attention when a primary standards body officially disavows things they're still using as insecure. > > No MD5 function should remain in the relevant codebase; > > In particular the IETF does not get to tell anyone which functions > they get to include in their codebase. So no IETF document saying > such a thing makes much difference. It's not a list of demands; it's basic specifications maintenance. It's just a matter of stating what's necessary to avoid well-known security problems when using IETF specs. We know it's a problem and should say so, loudly, on the standards track, as we are well aware that obsolete standards are still in regular use and are dangerous unless their implementations are properly handling all issues discovered since initial release. I am of course aware that the IETF doesn't like to wade into implementation issues in this kind of detail, but just blaming implementations for screw ups isn't an answer. We should be reliably telling implementors what's needed to avoid them. The disabled-but-accepted nonsense is a common enough high-risk issue that comes up way too often, and not prominently specifying how to deal with it is irresponsible. An argument could be made for coding/API safety issues like this being in a separate BCP RFC, especially if we actually wanted to cover other things like this, but that's a much larger proposal than what I'm currently talking about. > > if MD5||SHA1 support is continued, > > there should be one function that does only that without any way to get > > a plain MD5 hash. > > This turns out to be a good idea anyway, thus, for example, OpenSSL > 1.1.0-apha2 just recently added an EVP_md5_sha1() hash function. Ah, good to hear. Thanks for the info. Dave From nobody Mon Jan 11 23:46:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3081D1A0130 for ; Mon, 11 Jan 2016 23:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxzKciugSLmR for ; Mon, 11 Jan 2016 23:46:10 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679FA1A03ED for ; Mon, 11 Jan 2016 23:46:10 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id q21so375163060iod.0 for ; Mon, 11 Jan 2016 23:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=2n65PdUxxw7NeoOcEm1ns01po8lgOM0dueyBUNKS++w=; b=Vc3LzSKE8Q50y8u0+nSMCImFrdnmU4wDhVhBV07AYZaTD4rEuuX/B/0jltDuhXRMIp VP57DqVU5wrdzuzgM8uSF0qHVClfl+LfVg3JCKXNdc6h27qoawckaUy80WQ1UiG77iF8 UitUgqOuQPFQ7R4bhPF2KC3jM1vsH1nlF4RaZg+BQlR89f3eCn63uUCmGDNNOqfdn/VY 5mpkS55V/Lp5drP2nvEnH8FPxwNAyxvYyuuazox2luV4N/TPZnwbBHY8vgmwSqjAS2Cl th2PgoQ5VgnB8Mnry/ydUgQNpMSSt42/7alXBnFbc7oGTdu0YJQFX54VNWHMeIALXVAv xfFQ== X-Received: by 10.107.166.85 with SMTP id p82mr26909916ioe.146.1452584769772; Mon, 11 Jan 2016 23:46:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.37.17 with HTTP; Mon, 11 Jan 2016 23:45:50 -0800 (PST) In-Reply-To: <20160112053208.GE18704@mournblade.imrryr.org> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <201601112242.46115.davemgarrett@gmail.com> <20160112053208.GE18704@mournblade.imrryr.org> From: Tony Arcieri Date: Mon, 11 Jan 2016 23:45:50 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a1141d06235627005291e3f67 Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 07:46:13 -0000 --001a1141d06235627005291e3f67 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 9:32 PM, Viktor Dukhovni wrote: > > No MD5 function should remain in the relevant codebase; > > In particular the IETF does not get to tell anyone which functions > they get to include in their codebase. So no IETF document saying > such a thing makes much difference. Not being the person who called "diediedie", but being in total agreement with the OP, "diediedie" should represent a "burn notice" from the IETF to all implementers: DO NOT DO THIS!!! Clearly many TLS stacks still implement MD5, and there are no TLS police to arrest the people who are ignoring the IETF RFCs and still shipping diediedie-filled crypto, but if we want any modicum of security want any sort of security guarantees from TLS, all stacks *MUST* abandon MD5 in its entirety. -- Tony Arcieri --001a1141d06235627005291e3f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 11, 2016 at 9:32 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
> No MD5 fun= ction should remain in the relevant codebase;

In particular the IETF does not get to tell anyone which functions they get to include in their codebase.=C2=A0 So no IETF document saying
such a thing makes much difference.

Not bei= ng the person who called "diediedie", but being in total agreemen= t with the OP, "diediedie" should represent a "burn notice&q= uot; from the IETF to all implementers:

DO NOT DO = THIS!!!

Clearly many TLS stacks still implement MD= 5, and there are no TLS police to arrest the people who are ignoring the IE= TF RFCs and still shipping diediedie-filled crypto, but if we want any modi= cum of security want any sort of security guarantees from TLS, all stacks *= MUST* abandon MD5 in its entirety.

--=C2=A0<= br>
Tony Arcieri
--001a1141d06235627005291e3f67-- From nobody Tue Jan 12 00:58:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2151A1B98 for ; Tue, 12 Jan 2016 00:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z5TEkaQb22S for ; Tue, 12 Jan 2016 00:58:19 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0021A1B7C for ; Tue, 12 Jan 2016 00:58:18 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f206so308301224wmf.0 for ; Tue, 12 Jan 2016 00:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DaCitt5w6DvQDNJB4o8Lkv8rwcbGlG1/UeWL7WBto9U=; b=y6SookoscmH0g94oeSz9nzJwRhoT8CkefFMCPcHPe0EgXCYcDR2GQHO2omlaY2SteV j4iKHzXTiWovTeTJoNjUX+vEpHVsiRyyZv36tUMG2A+f5qvxLxiswqV8XUxWfsGg3Pk1 dPgJr/bdgd0xhRvgFjB82brysFVRy5RhWzGvMr8QF2Rft/A5TCBjukFNnCvgyk4wJRN4 hMB+jmGwL96qIK59ikQ6vhHYxK556FakkRhubVpYJTLCtJd8YjKiob+LILFc8NZer8Uz 9rIC5hqlCBBjLTgmTMugOmNFtYXlqzykU40+aOPaV0/ac9MjF51WRtGvLnYPKpDNeMS7 6f9g== X-Received: by 10.194.242.67 with SMTP id wo3mr33929163wjc.180.1452589097351; Tue, 12 Jan 2016 00:58:17 -0800 (PST) Received: from [128.93.85.191] ([128.93.85.191]) by smtp.gmail.com with ESMTPSA id u4sm122764744wjz.4.2016.01.12.00.58.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 00:58:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC619C@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 12 Jan 2016 09:58:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <178C01CE-A312-47C0-8E70-659CCB17C8F7@gmail.com> References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC617B@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC619C@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 08:58:20 -0000 > I'm aware of that (and related) work, but this is about finding > multicollisions in MD5 || SHA1. To be clear, there is no published collision on MD5 || SHA1 right now. In our paper, we only say that *if SHA-1 collisions were to appear* with = complexity 2^x,=20 then MD5||SHA1 collisions would cost 2^(6+x). Hence, if the current = estimate of 2^61 for SHA1 were true, then the cost of MD5||SHA1 is 2^67.=20 It is up to protocol designers and implementers to decide whether this = is an acceptable security margin. If we decide to wait for a =E2=80=9Creal=E2=80=9D SHA-1 collision to = appear, then we must be prepared for =E2=80=9Creal=E2=80=9D attacks to = appear soon after. Best, Karthik From nobody Tue Jan 12 01:24:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49DC1A6F77 for ; Tue, 12 Jan 2016 01:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 Vina3cpfQlri for ; Tue, 12 Jan 2016 01:24:22 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 D6C791A6F5D for ; Tue, 12 Jan 2016 01:24:21 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0C9OAnm015935 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Jan 2016 10:24:11 +0100 From: Simon Josefsson To: Joseph Salowey References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160112:joe@salowey.net::H0qwiUcVO/I9oCJr:A5r5 X-Hashcash: 1:22:160112:tls@ietf.org::xpF9mSourZTpvNu8:QQqL Date: Tue, 12 Jan 2016 10:24:09 +0100 In-Reply-To: (Joseph Salowey's message of "Sun, 10 Jan 2016 19:53:08 -0800") Message-ID: <87mvsbywue.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 09:24:27 -0000 --=-=-= Content-Type: text/plain Joseph Salowey writes: > Please respond if you have concern about early code point assignment for > the curves listed in draft-ietf-tls-curve25519-01 > . The above draft, and rfc4492bis and tls13-11, has known issues/inconsistencies related to X25519/X448 that have been discussed on the list. When it was decided (offlist..) to move the content of draft-ietf-tls-curve25519 to other documents, I stopped working on it. What would the semantics of these code points related to the known issues be (e.g., code point validation or not)? Do the code points refer to what the draft above says, or what people appear to prefer (don't reject, but ignore set bit) and have been implementing? I can update the document to fix the known issues. The content has been copied to other documents that I have no editor influence of, so modifying draft-ietf-tls-curve25519 may make the situation even more confusing. Please advice if you want anything more to happen with the document above. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWlMY5AAoJEIYLf7sy+BGdmAoIAKsD6SjEcQgawUkoBJhgiq2W 7yJ2jvPE3jt5dfICJ6SAvLVwmrxhOU3LpVO7PFUoY65jT9b6XDdO0Sifh/rrozSm xiCmNUXSI2JLfkiM2gSgwbmckJTpWC7WotpdWl8FSLxHLv0gB9Wt+yVKOUt+FeZ7 i3MYQ9aJh9STkM/HCmOXTl3E+PlB+77XbS5Jdip6Qggmup0YRlVuDM9f/Ya9bdHe 4LMBqP9EpVE+W80sRE++4K8nEskcayZXFwi4RB1SWHGUHuNMfNHDGXh3vIhl7WOo aogmeHAYhylHJ+1+pu4Qj1qElLrpugI1PRZDMdkMviZB7/OQmYaAKSm3coT3MfA= =swVv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 12 03:05:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF01A884E for ; Tue, 12 Jan 2016 03:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ZLW4ainekm for ; Tue, 12 Jan 2016 03:05:08 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBEA1A8777 for ; Tue, 12 Jan 2016 03:05:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EBBF9BE56; Tue, 12 Jan 2016 11:05:05 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N77SQVsg8m8o; Tue, 12 Jan 2016 11:05:05 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4F763BE55; Tue, 12 Jan 2016 11:05:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452596705; bh=MBwgWLxxncf/Ls2Mq5nHRm0IAseVmE5fNpU91EFB8dw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=srHY/+r8I4TRQr4M5h9VcW9EqTsqMWox664FuJTxHXUCWfanDnr1C+uO98vf06KJ3 x6iMZ95AHXipvv1NUBLhDuktsKW4qTwwFtrVqXfuy6VIf0xHpF4GZx52++9fnEDr55 yOcJFlrimAxFh8hrseY1YbfG0pLEuECEOfqC9gU8= To: Dave Garrett , tls@ietf.org References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <201601112242.46115.davemgarrett@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <5694DDE1.5040308@cs.tcd.ie> Date: Tue, 12 Jan 2016 11:05:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201601112242.46115.davemgarrett@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 11:05:10 -0000 A few notes on this: - Calling for the IETF to do something isn't how it works. People who want thing X to be done need to write the draft and then see if it gets support. I suspect an md5-die-die-die draft would get quite a bit of support but... - The points Victor made about long-term stored data are valid. In various cases it simply wouldn't be a good plan to re-encrypt or re-sign old data. Yes, that stored data may not be as secure as it once was, but it may be impractical to re-encrypt it all. The openpgp wg [1] are dealing with this particular issue as they work to do updates, so feel free to get involved in that debate there if it's of interest. - If your envisaged scope is for all IETF protocols, then I'm sad to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing folks just won't let die it seems, even though we formally obsoleted that [3] 5 years ago. (And yes, that really is sad.) - Lastly, and again if your envisaged scope is to deprecate MD5 for all IETF protocols then that might better fit the charter of the new curdle wg. [4] And your draft might be an update to RFC6151 [5] I guess, depending on how you wrote it. So by all means, write the draft and post a link to the curdle list (maybe cc'ing this). Cheers, S. [1] https://tools.ietf.org/wg/openpgp/ [2] https://tools.ietf.org/html/rfc2385 [3] https://tools.ietf.org/html/rfc5925 [4] https://tools.ietf.org/wg/curdle [5] https://tools.ietf.org/html/rfc6151 On 12/01/16 03:42, Dave Garrett wrote: > On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote: >> My understanding is TLS 1.2 specifically was amended to allow MD5 >> signatures even though this was not the case in previous TLS >> versions, or at least that was the claim of the miTLS presenters on >> SLOTH at RealWorldCrypto 2016. >> >> If this is the case, this seems like a big regression in TLS 1.2. > > I'd like to propose killing the low hanging fruit first, and then > continue to build on top of that. > > No sane person disputes that MD5 needs to be eradicated ASAP. We're > keeping MD5||SHA1 in old TLS for compatibility and we are well aware > that needs to go eventually too. Thus, I suggest we publish an MD5 > diediedie standards track RFC to prohibit ALL standalone MD5 use in > ALL IETF protocols/standards. Constructions using MD5 with something > else (namely MD5||SHA1) would also be explicitly recommended against > in existing specifications, and explicitly prohibited in all new > drafts (even if unlikely). > > Also, when I say "prohibited" here, I mean _completely_. No MD5 > function should remain in the relevant codebase; if MD5||SHA1 support > is continued, there should be one function that does only that > without any way to get a plain MD5 hash. (and no "it's fine for this" > junk; non-broken hashes are also fine for that, and if you're wrong, > it's safer) There are too many implementation bugs in this realm to > not state this explicitly [0]. > > Note that continued support of trust anchors with MD5 hashes is not > dependent on this, as we've already agreed they don't need to be > validated. (they need to be phased out, but with less urgency) If > used within this specific context, nothing even needs the ability to > understand MD5 hashes at all in order to handle these; the > certificate as a whole is trusted or not. > > > Dave > > > PS To whomever came up with the "diediedie" term, thank you. ;) > > > [0] Note the 3 disabled-but-accepted bugs listed here: > https://www.mitls.org/pages/attacks/SLOTH#disclosure > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jan 12 05:24:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37481AD289 for ; Tue, 12 Jan 2016 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcxvYVAy8aRH for ; Tue, 12 Jan 2016 05:24:34 -0800 (PST) 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 1FBE81AD255 for ; Tue, 12 Jan 2016 05:24:34 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 C164B44741; Tue, 12 Jan 2016 14:24:31 +0100 (CET) X-purgate-ID: 152705::1452605071-00002D85-327171A1/0/0 X-purgate-size: 2708 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 739BA40471; Tue, 12 Jan 2016 14:24:31 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 237AA1A3E4; Tue, 12 Jan 2016 14:24:31 +0100 (CET) In-Reply-To: To: Tony Arcieri Date: Tue, 12 Jan 2016 14:24:31 +0100 (CET) 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: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Jan 2016 13:24:36 -0000 Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > Peter Gutmann wrote: > >> The vulnerabilities shown in the SLOTH paper were based on the fact that >> implementations still allow MD5 for authentication/integrity protection, >> even if (for example) it's explicitly disabled in the config. >> So the problem wasn't a fault in the protocol, it's buggy implementations >> (as it was for ones that allowed 512-bit keys, non-prime primes, >> and so on). Throwing out TLS 1.1 based on this seems rather premature. Actually no, the TLSv1.2 made a few terribly braindead design choices - newly introduce raw md5RSA digital signatures into TLSv1.2 in 2008 where all prior TLS protocol versions, including SSLv3 had been using the concatenation SHA-1||MD5 - making the sha1RSA rather than sha256RSA digital signature algorithm the default and mandatory-to-implement algorithm for use with TLSv1.2(!!) although it was well-known weaker than the algorithm (SHA-1||MD5) in all earlier TLS protocol versions, including SSLv3, and in spite of SHA-1 already being officially scheduled for end-of-life 2 years later (NIST, SP800-57 pt.1 rev2) This is ridiculous considering that SHA-256 is mandatory-to-use in the TLSv1.2 PRF. - failing to adjust the truncation of the HMAC output in the TLSv1.2 Finished handshake message to be at least half the size of the underlying hash function (SHA-256), see RFC 2104 Section 5: https://tools.ietf.org/html/rfc2104#section-5 > > My understanding is TLS 1.2 specifically was amended to allow MD5 > signatures even though this was not the case in previous TLS versions, or > at least that was the claim of the miTLS presenters on SLOTH at > RealWorldCrypto 2016. > > If this is the case, this seems like a big regression in TLS 1.2. And a fairly well-known & discussed regression, e.g. http://www.ietf.org/mail-archive/web/tls/current/msg10664.html that was subsequently removed in OpenSSL 1.0.1f in January 2014, i.e. 2 years before the SLOTH paper. I'm also wondering whether it might be misleading to lump the (in)significance of the currently known collisions for HMAC-SHA1 and HMAC-MD5 together with the (in)significance for (general, low-frequent) digital signatures and together with PKCS#10 & Certificate-issuance design flaw that enables a mere collision attack to achieve what would normally require a successful 2nd preimage attack. Compare the Security Considerations of rfc2104 for the (in)significance of current collision attacks for HMAC. https://tools.ietf.org/html/rfc2104#section-6 -Martin From nobody Tue Jan 12 05:32:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA31AD2D9 for ; Tue, 12 Jan 2016 05:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It4Okkg7Zbpg for ; Tue, 12 Jan 2016 05:32:44 -0800 (PST) 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 788AC1AD289 for ; Tue, 12 Jan 2016 05:32:44 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 9D85B19EF1D; Tue, 12 Jan 2016 13:24:55 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-89.brq.redhat.com [10.40.204.89]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0CDOrhS009718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 08:24:55 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 12 Jan 2016 14:10:23 +0100 Message-ID: <3168950.s00T8GSD8Q@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <20160112053208.GE18704@mournblade.imrryr.org> References: <20160111183017.GA12243@roeckx.be> <201601112242.46115.davemgarrett@gmail.com> <20160112053208.GE18704@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1459750.nnbNaxrvNS"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 13:32:46 -0000 --nextPart1459750.nnbNaxrvNS Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 12 January 2016 05:32:08 Viktor Dukhovni wrote: > On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote: > > No sane person disputes that MD5 needs to be eradicated ASAP. We're= > > keeping MD5||SHA1 in old TLS for compatibility and we are well > > aware that needs to go eventually too. Thus, I suggest we publish > > an MD5 diediedie standards track RFC to prohibit ALL standalone MD5= > > use in ALL IETF > > protocols/standards. >=20 > With some exceptions, for example: >=20 > * As you note in your last comment, X.509 self-signatures via > MD5 may continue to be ignored, once MD5 is "banned" in the same > way that they should have been ignored before it was "banned". >=20 > * S/MIME parsers may continue to parse old S/MIME messages with > MD/5 signatures. More generally, Encrypted data at rest may > need support for MD5 for the lifetime of the data (until > re-encrypted, ...). in case of digital signatures, that means "lifetime of the data", you=20= can't expect them being possible to re-sign so it must not completely forbid use of MD-5 in implementations of stuf= f=20 like PAdES-A. Though it should strongly recommend allowing its use in=20= only *very* specific circumstances. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1459750.nnbNaxrvNS 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 iQIcBAABCgAGBQJWlPs/AAoJEJKo0bgB0vX1BoEP/04qcO6QChpfU7gIGp18lCO6 j0VjcE2JgjWTll/7Jt7ZSZwCG4+rHXv0BIXVoUFuRf9u+/fbvwKSHP/iUkQcUstO 3jHQNFpe2qM/wV60/7dcFscZEoAqJv34M+n/4B510T/WlSu22sp+bK5h48RKetQm FKiBCERfymAMO33RTjf4BBwfa9CfbuftYGL8iLab1yPpVCQijDbHvsC3ktYtsPGP aFJSUJKZ+O0y8bhHanCdoAUoWFygPoBxVUnfB6J4KodhISvYTQrJO6Vlcz0SxPhE Dm14ouBMF2bP6myEAboTgq1DWbRNhNHFZttktJVc0eT44bo5YPmNyJpjZSelCH+j gQ7ZZ4kligVNenjPYJ4akwN31QSQUSHRpsYGssIxZertSvdwHDptRjqq1kM7uCjE HmIqx/gwN+P+cdClWH08PCnRhylU+vUj0KZ9cZjePXLy5UD1E2U0I0e8T/eIR+lg +5lMt62V6uE2ojcrvUgNVYy3WSwenpXM+9XM8Xg5VQxbytFZsGWxqVU94Dl8lmdu LpLu0P9rNBeYDBmVMQheljaVUfJkg91PebbOgwPcs0Uxo0I1+vnBAWXKWyeLTb1d xJ+TRn63zldk5/h1KmVTx5rZdRsUzTOELfRnZ4Usl0IFovrNGMURg43e2jlnWaOJ XRwLRD4CITjZ8f8P6UL9 =X48T -----END PGP SIGNATURE----- --nextPart1459750.nnbNaxrvNS-- From nobody Tue Jan 12 05:49:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307131AD35D for ; Tue, 12 Jan 2016 05:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZijrYb-WCn8 for ; Tue, 12 Jan 2016 05:49:49 -0800 (PST) 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 4020D1AD35C for ; Tue, 12 Jan 2016 05:49:49 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l65so252732770wmf.1 for ; Tue, 12 Jan 2016 05:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QtGO/UkgjDlPUlYocqY7Fe5LVwm7f5zXFNr997tOa54=; b=jQ9FPzYEYW0xOAZAzbPgUv6HqUlKf+dbhHYBwaZ2MCLpExsqVg+3vCJBhaXl8x8SkY EF/0YH6OexUDozzoWlvHnb0vXlvfnE/89NBoZJpGoDvwngiSTU8LsOZDKONLy8XmZsGd 4H9PedW0iSVezRvS3g4vDeBTR5yGuyqWLoauD2UzUwZ0u/OUqmjAuvcvIYqhjswxCATm Xu1gDVbiN21XxyK7JB7LI/MyPPAUm+loHQ8v0lgEKXc2HTB60sWOBvP0wfRpdY6E1ydc 6GwRig9zefRQJ9k4lXyeSOxrOIN0Pz4XLFipErULhQCmJU1qEA/c723Y/OSt+1M+sw9P ARzQ== X-Received: by 10.194.79.37 with SMTP id g5mr43291428wjx.89.1452606587860; Tue, 12 Jan 2016 05:49:47 -0800 (PST) Received: from [128.93.85.191] ([128.93.85.191]) by smtp.gmail.com with ESMTPSA id id1sm123813508wjb.19.2016.01.12.05.49.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 05:49:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Karthikeyan Bhargavan In-Reply-To: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp> Date: Tue, 12 Jan 2016 14:49:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 13:49:51 -0000 > I'm also wondering whether it might be misleading to lump the > (in)significance of the currently known collisions for HMAC-SHA1 > and HMAC-MD5 together with the (in)significance for=20 > (general, low-frequent) digital signatures and together with > PKCS#10 & Certificate-issuance design flaw that enables a > mere collision attack to achieve what would normally require > a successful 2nd preimage attack. I couldn=E2=80=99t really parse this sentence very well, but here are = some clarification. As far as we know, HMAC-MD5 and HMAC-SHA1 are still sufficiently strong = MAC functions, and their use in the TLS Record is not vulnerable to currently known = attacks. TLS also uses HMAC in other situations though, and those may well be = vulnerable to collisions. In particular, the Finished message in TLS 1.1 is not a strong MAC = because it first hashes the transcript before applying the HMAC. Similarly, the use of truncated = HMACs in Finished breaks tls-unique and weakens the renegotiation indication = countermeasure. Generally, HMAC uses as a MAC is ok, but when used as a hash function is = as vulnerable to collisions as the underlying hash function. Coming back to digital signatures, all uses of weak hash functions are = essentially broken.=20 The attacks on certificates were well known, and SLOTH shows that other = uses of digital signatures in many mainstream protocols also require = collision resistance. Best, Karthik >=20 > Compare the Security Considerations of rfc2104 for the = (in)significance > of current collision attacks for HMAC. >=20 > https://tools.ietf.org/html/rfc2104#section-6 >=20 >=20 > -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jan 12 06:04:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DC1B2A17 for ; Tue, 12 Jan 2016 06:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0RPqyvNoQiq for ; Tue, 12 Jan 2016 06:03:57 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24561B2A15 for ; Tue, 12 Jan 2016 06:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452607437; x=1484143437; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yeWRc8KPSPwYpM6NUkI3lH2uV4d2AREe7RrMTSm6Lt8=; b=FQSsC2DBcjBqlLx/cbhkszybL6+n7ZU1z4uzifSIYd41Ud2hmeToKl6+ 2kkG7KXwI8pbXbmF9Avv9xOSQtGJ7Bjc+d0WqPfxET2qnBurabziB36Mr eUPTHhG/UDzrLFXd5q0susRMY32d55y0RKuiLDAiHuavjw0T4qJhPMdXo mz6qhMpDx1+l/OosaY0J3FSe229gQVJEb/PCImuoQVqEyXKPOlcWUJrYI 6vWdWOqQ9EYzFscsfUJ/QZsvYLlwFOHHtM8Hu0aKUyc3DMjyJcE8sslqt 5yo6t6bxS78MrONI0N5tU+iU7ZU/hKq2dzMRVgrp6c/sTaSAABqT/fhts A==; X-IronPort-AV: E=Sophos;i="5.20,557,1444647600"; d="scan'208";a="62783138" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 03:03:54 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 03:03:54 +1300 From: Peter Gutmann To: "" Thread-Topic: Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzQ== Date: Tue, 12 Jan 2016 14:03:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 14:04:01 -0000 Martin's comment reminded me of the following that I've been meaning to=0A= post...=0A= =0A= In a recent discussion among some crypto folks, the topic of what TLS 1.3= =0A= could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path f= rom=0A= TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discussi= on=0A= centered around the fact that we already have lots of analysis done for TLS= =0A= 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3=0A= problems while being as compatible as possible with existing infrastructure= .=0A= So what this would do is take existing security analysis applied to TLS,=0A= namely:=0A= =0A= Bhargavan et al, "Proving the TLS handshake secure (as is)".=0A= =0A= Brzuska et al, "Less is more: relaxed yet compatible security notions for k= ey=0A= exchange".=0A= =0A= Dowling et al, "Modelling ciphersuite and version negotiation in the TLS=0A= protocol".=0A= =0A= Firing, "Analysis of the Transport Layer Security protocol".=0A= =0A= Gajek et al, "Universally Composable Security Analysis of TLS".=0A= =0A= Giesen et al, "On the security of TLS renegotiation".=0A= =0A= Jager et al, "On the security of TLS-DHE in the standard model".=0A= =0A= Krawczyk et al, "On the security of the TLS protocol".=0A= =0A= (and probably several more) and use them to simplify TLS 1.2 to create an= =0A= improved TLS that leverages about 15 years of analysis, rather than creatin= g=0A= what's almost a new protocol based on bleeding-edge/experimental ideas,=0A= mechanisms, and algorithms.=0A= =0A= The discussion started out somewhat informally so by the time it got really= =0A= interesting it was too late to take notes, but I thought I'd try and recrea= te=0A= the design points...=0A= =0A= - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC= +=0A= HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMA= C-=0A= SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for O= CB=0A= instead of GCM as the AEAD if it were freely available).=0A= =0A= - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD a= s=0A= well).=0A= =0A= - Get rid of the IPsec cargo-cult MAC truncation.=0A= =0A= - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) = to=0A= allow verification (for those who don't have a copy of X9.42, it requires= =0A= the same verification steps as FIPS 186 does). Also, mix the hash of the= =0A= DHE values into the computed premaster secret to protect against use of= =0A= manipulated curves.=0A= =0A= - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-chec= k=0A= done as encode-then-compare, which fixes all known padding-manipulation= =0A= issues).=0A= =0A= - No compression or rehandshake.=0A= =0A= - Replace the PRF with HKDF? (No pressing need for this, but it would be p= art=0A= of the general cleanup).=0A= =0A= Longer discussion points:=0A= =0A= - The DHE/ECDHE parameters were a bit contentious. For DHE the choice is= =0A= between server-specified ephemeral parameters and IETF-blessed fixed ones= .=0A= Arguments can be made either way, we had de facto IETF-blessed fixed DHE= =0A= params in the form of the RFC 2409 ones, but that wasn't such a good idea= .=0A= OTOH with ephemeral DHE params many implementations didn't check them, bu= t=0A= then the spec never required any checking (or much of anything at all in= =0A= regard to DHE use, which no doubt contributed to some of the dubious=0A= practices that have been found in the wild). The situation wasn't helped= by=0A= the use of the PKCS #3 representation, which the requirement to use the= =0A= X9.42 form alongside the accompanying checks attempts to address.=0A= =0A= - Similarly, for ECDHE the choice is between NIST and CFRG ones. The CFRG= =0A= ones are obviously better (for various values of better, see endless deba= tes=0A= elsewhere), but some people will insist on only using something that's co= me=0A= from NIST (I'll reserve my opinion on that one, and wouldn't dream of=0A= stooping to phrases like "cargo cult protocol design"...).=0A= =0A= Peter.= From nobody Tue Jan 12 06:13:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8C71B2A30 for ; Tue, 12 Jan 2016 06:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u2MAYKrc2dU for ; Tue, 12 Jan 2016 06:13:39 -0800 (PST) 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 9996B1B2A2C for ; Tue, 12 Jan 2016 06:13:39 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 4CE9F8AE73; Tue, 12 Jan 2016 14:13:39 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-89.brq.redhat.com [10.40.204.89]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0CEDbba018989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 09:13:38 -0500 From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Tue, 12 Jan 2016 15:13:26 +0100 Message-ID: <4735857.6t4KtpL18H@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp> References: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3462825.qlr0uTr7ec"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 14:13:41 -0000 --nextPart3462825.qlr0uTr7ec Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 12 January 2016 14:24:31 Martin Rex wrote: > Tony Arcieri wrote: > [ Charset UTF-8 unsupported, converting... ] >=20 > > Peter Gutmann wrote: > >> The vulnerabilities shown in the SLOTH paper were based on the fac= t > >> that implementations still allow MD5 for authentication/integrity > >> protection, even if (for example) it's explicitly disabled in the > >> config. So the problem wasn't a fault in the protocol, it's buggy > >> implementations (as it was for ones that allowed 512-bit keys, > >> non-prime primes,>>=20 > >> and so on). Throwing out TLS 1.1 based on this seems rather > >> premature. > Actually no, the TLSv1.2 made a few terribly braindead design choices= > - newly introduce raw md5RSA digital signatures into TLSv1.2 in 200= 8 > where all prior TLS protocol versions, including SSLv3 had been using= > the concatenation SHA-1||MD5 > - making the sha1RSA rather than sha256RSA digital signature > algorithm the default and mandatory-to-implement algorithm for use > with TLSv1.2(!!) although it was well-known weaker than the algorithm= > (SHA-1||MD5) in all earlier TLS protocol versions, including SSLv3, > and in spite of SHA-1 already being officially scheduled for > end-of-life 2 years later (NIST, SP800-57 pt.1 rev2) > This is ridiculous considering that SHA-256 is mandatory-to-use > in the TLSv1.2 PRF. > - failing to adjust the truncation of the HMAC output in the > TLSv1.2 Finished handshake message to be at least half the size o= f > the underlying hash function (SHA-256), see RFC 2104 Section 5: >=20 > https://tools.ietf.org/html/rfc2104#section-5 the problem stems from the fact that the same field is used for=20 announcing support for signatures in ServerKeyExchange *and* for=20 certificates provided by server. while SKE signatures could have easily been made mandatory to SHA-256 a= t=20 least, the depreciation of SHA-1 signatures for certificates certainly=20= wasn't possible at the time - only now we are closing on migration from= =20 them so, it was a _bad_ decision, but calling it a "braindead" one is a bit=20= over the top, sorry =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 99/71, 612 45, Brno, Czech Republi= c --nextPart3462825.qlr0uTr7ec 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 iQIcBAABCgAGBQJWlQoGAAoJEJKo0bgB0vX1dMUP/3lV7frSWYBdS63wSCW7WN9O B71uF+sn82IFIH9cgwmXZ/pL6ixcNilKizLezZNIdKyOpUkkD22PW3onZNK+ZW7f 9Q1yNqN1XaXRnrDjPK3ren+PLswBmTPk+F4i5b18b95kolIEUQ6k2qM76m6c2v/w X83cbFjXZn3HDQWmLeIJ1zkyT7T4prt44cb900C53xLGZTaSXItjWgMmuGM3J1I+ 8nGSrqMZIHIRyBOCOXlPsl7AM0PvMsLwEpSIZZc39wj0OfVUbnQeTHEZztFu1e1D Ff87mOHou3+uDN/0wI6OqexSutTVl+UT6hKth9Ai5WIPVLrbTXDfvIbY+RRVn6R5 LdoPOWjtbinVvOCoqYTCx588+8gpWlYDY8BZ4iTjfQg2KLcgZY8sryDOavCE6Y9y JcW9EQ8biYiabRt5oemezXp+ARgV3VY6W16ilOF2392JK0/OF+c9c9OnKnqCwZMp VKpATeAt8EbW3Vys4FP7mi6xrGIDaSoGQ3iWr18MZ39/YzuQ2PqKeBSqj2ghd1nb V1hTUU9TmqvPRjXcL1Q92WwKVvZR5LC0cYMxBoLv5J2+0EwCclLjHqneGAgqq9N9 JynpkprPP4hiYjwuFt0ljVuU/CL1JM5Z9aqg8PeU8J5gzhp6bUnH54jnbE5D2LSW d/9WboW+3hNg2B3sSmxh =uwdJ -----END PGP SIGNATURE----- --nextPart3462825.qlr0uTr7ec-- From nobody Tue Jan 12 06:14:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1514F1B2A43 for ; Tue, 12 Jan 2016 06:14:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlhQqDcAgomj for ; Tue, 12 Jan 2016 06:14:21 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC351B2A42 for ; Tue, 12 Jan 2016 06:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452608060; x=1484144060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/YPxi2gDOnNP8hqR+ljWK/CGnS6Nl6qe6L2xjzscVCs=; b=ZHxnLZ5qTgMoik/VrmxQJF4biSmGSrNr6rcmMMhgs8y6lYcinqtIMx1/ nWLsw+xwiVq7TbScZ3qOR8b6qZzCL2BCy+03GX6JSZBSDfS6uxc836sX9 KCOS9chUHebSSo+l8l78ck+EyyAdrksgaxXTzXn9xWCZ093a3tUwYEBDf L7fhLW4nKskJNZEdCTTz4Mt3/mLsE8nxAlfMHPkKofA7vYVx5eXk+hGZF CqsBxQbFWZ6CMJrpeIwAL7LVRPjIJ5Zcyt74J+sdIyO1bzghJsJHaHJlw xTaW8mYHXK7jc7dk+3pivZUHPKCqr3AyyZ21EiRg812aFEmRjk4wI7umD w==; X-IronPort-AV: E=Sophos;i="5.20,557,1444647600"; d="scan'208";a="62783791" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 03:14:19 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 03:14:19 +1300 From: Peter Gutmann To: Karthikeyan Bhargavan , "mrex@sap.com" Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ728Kke//8nk4CAAO29gIAABw4AgADgoM4= Date: Tue, 12 Jan 2016 14:14:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC6877@uxcn10-5.UoA.auckland.ac.nz> References: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 14:14:22 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >Coming back to digital signatures, all uses of weak hash functions are=0A= >essentially broken.=0A= =0A= Not necessarily. Use of weak hash functions where the attacker has time to= do=0A= offline precomputations/calculations are essentially broken. I'm not sayin= g=0A= "keep on using MD5", but unless your attacker can find collisions in real t= ime=0A= you're still OK while you take time to switch to SHA-2 or whatever.=0A= =0A= Peter.= From nobody Tue Jan 12 06:19:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8411B2A30 for ; Tue, 12 Jan 2016 06:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REaMtFtFNx8y for ; Tue, 12 Jan 2016 06:19:25 -0800 (PST) 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 536D21B2A2F for ; Tue, 12 Jan 2016 06:19:25 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 07A1DC02C6A7; Tue, 12 Jan 2016 14:19:25 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-89.brq.redhat.com [10.40.204.89]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0CEJNn7016876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 09:19:24 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 12 Jan 2016 15:19:21 +0100 Message-ID: <2252854.439XugcI3g@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4660031.6FCMEPLKvO"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 14:19:26 -0000 --nextPart4660031.6FCMEPLKvO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 11 January 2016 17:28:33 Bill Frantz wrote: > On 1/11/16 at 4:32 PM, watsonbladd@gmail.com (Watson Ladd) wrote: > >Do the RFCs require the relevant checks or not? And given that > >implementations frequently get these sorts of things wrong, how do w= e > >make the standard robust against it? >=20 > The best way I can think of is to test to see if the checks are > being done. For example, if a implementation is supposed to > check if a number is prime, send a non-prime and see if it takes > the correct action. >=20 > Publicly available test suites would be a good step toward > implementing this strategy. shameful plug: https://github.com/tomato42/tlsfuzzer and the underlying= =20 https://github.com/tomato42/tlslite-ng =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 99/71, 612 45, Brno, Czech Republi= c --nextPart4660031.6FCMEPLKvO 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 iQIcBAABCgAGBQJWlQtpAAoJEJKo0bgB0vX10ZoP/21u9IaOsvakFmbnMPlfB4v5 zxC18moMgp/dcaR1xd9ZlMLOKQwQP5w8nny9cMvJ6Pe/htlla4WD2/1pFYXRxSV+ HyEHCOCnywaUUvprIyMmMU5ZA3ss72LYSSaN8CA/eh0K5ljD504FA1+q1vrwiyTG CmNG59W0F+PIxzrORnykvAEtKd+Jb1zlbFzzeKWyR8Ju9aZS20Srjm0dJ53VIbqj NkLMeKDbdwcmPvDxH4Vr6F4t9+hL6crNDjuWV1wkjoTmt75uWnt4X1AK7eAF/n4u R0/ozhfKZrcxWt4MXbhcBHaDhcObNq3g4+/v3qw8M75woQfNG89IGpoc1pPi2g4G bisaP+GUTdwjAwshzaDq6hPvs0jcmkNETzaSGuJMBzvhDJqB0MAcdfe2X9cFlYAj rwOvl7jR1Y4vf9v292Ab271AtpeKU1kwocXgo3V+FKUCHah14BacXnw2ugA7nwl1 aUibCTQ72zz/DP5urlROqaIjHF/MZKEBZ/+2Fd8SsI/qsWvS+DB/zdOXma/GNc5P hAS7GyWPcxbjjKjDdv7Co5Sc403HfRvdzn10RK4LX4OwdxRBi/Ony8/jBG/iG62K lABVvwHQCOCK2FwmLuPOu17G6VnYnbUWBwW7htJf4nj81j+C+d1oHidjDSzZoNGW B0oxLLq1AvfRMp1rS5Xj =RXq1 -----END PGP SIGNATURE----- --nextPart4660031.6FCMEPLKvO-- From nobody Tue Jan 12 06:24:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660B21B2A45 for ; Tue, 12 Jan 2016 06:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 AgUNiQPh2sLv for ; Tue, 12 Jan 2016 06:24:47 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 9F0EF1B2A43 for ; Tue, 12 Jan 2016 06:24:46 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0CEOXDi012134 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Jan 2016 15:24:34 +0100 From: Simon Josefsson To: Adam Langley References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160112:agl@imperialviolet.org::XbCINwQyaAbJzGV4:4Ni8 X-Hashcash: 1:22:160112:tls@ietf.org::BwnzhvSD8zkgkvD5:CM7k Date: Tue, 12 Jan 2016 15:24:32 +0100 In-Reply-To: (Adam Langley's message of "Tue, 22 Dec 2015 10:52:28 -0800") Message-ID: <87si22j2ov.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 14:24:49 -0000 --=-=-= Content-Type: text/plain Adam Langley writes: > Curve25519, as the name suggests, operates on 255-bit numbers. When > encoded as bytes, there's obviously a 256th bit that needs to be > specified. > > Curve25519 implementations didn't set the bit but did used to vary on > how they parsed it. Some would take a 256-bit number and reduce it > while others would ignore the bit completely. > > However, I believe that implementations have converged on ignoring it. > That behaviour is specified in draft-irtf-cfrg-curves and tested via > the test vectors. > > Currently https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > says that implementations SHOULD reject inputs with the high-bit set. > I think that should be dropped. The X25519 function is specified in > terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec > should just use that draft. I agree. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWlQygAAoJEIYLf7sy+BGda24H/2basiY24q78/YDHyJjiC2QU Ci6nLMKwblue4ANJwx7LkvGHn+OgbvTBGWdfzQ/xwnEcRGxL6UEsU6ZajWaQMD/c dEIymGG2mBDXfmEis2bUh/EqwKnWXWUDtGHNBhQMPKQOE1clFzRIiqcs3rRG1f1r W5/6K+GURX9yyZJiHVKizSvtF8DEMBmmihjqZun+pAhXIEo1Xtak60MuYo15GDFq X/MHYzgpFyqu4dMseh9AhoixTUgS9M4w/nfXUm+4HzKLJTRxcdB0KOAVulkDup6J 4CAYOLwvaWveKqtq3003/RsHSm/LGm14jRkf+oZvOZeljch8rWbdA12W8s76Iyg= =zdsy -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 12 08:03:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7E41B2AEF for ; Tue, 12 Jan 2016 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jxCqIobvTKn for ; Tue, 12 Jan 2016 08:03:29 -0800 (PST) Received: from us-smtp-delivery-180.mimecast.com (us-smtp-delivery-180.mimecast.com [63.128.21.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236611B2AD9 for ; Tue, 12 Jan 2016 08:03:28 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-14-T6hb9h1TRTaWTDFvBN9uUA-1; Tue, 12 Jan 2016 11:03:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tableau.onmicrosoft.com; s=selector1-tableau-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b5ZRZya/4SMe0eU6SmiI4SwnIMFzuJPe+ubyZuOKNws=; b=fqthjJADOYoEF8rubgWp4g2qa6Igbqq0subqUom9ethx+7grJ7mJm/RCxpEdgIeOtSwdECXxYpqfoe1/HbfmEGUXIKZPZmPQ8WOvY59CHiiQsHCrAVbVCJcFI50qDVGEvup0jTM96rjTpFb4iq7TAnT/0oEoT1uTE1Fn/QftKoM= Received: from BL2PR03MB148.namprd03.prod.outlook.com (10.255.230.27) by BL2PR03MB146.namprd03.prod.outlook.com (10.255.230.18) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 12 Jan 2016 16:03:13 +0000 Received: from BL2PR03MB148.namprd03.prod.outlook.com ([169.254.9.10]) by BL2PR03MB148.namprd03.prod.outlook.com ([169.254.9.10]) with mapi id 15.01.0365.023; Tue, 12 Jan 2016 16:03:13 +0000 From: Joe Salowey To: Simon Josefsson , Adam Langley Thread-Topic: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 Thread-Index: AQHRTVK9GYK+c24UM0+pEDGJ49lIww== Date: Tue, 12 Jan 2016 16:03:13 +0000 Message-ID: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151217 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.168.161.122] x-ms-office365-filtering-correlation-id: 6bc3deb6-e7a8-42f1-8ece-08d31b69e016 x-microsoft-exchange-diagnostics: 1; BL2PR03MB146; 5:c90rCDuthtrtw7m+/L8VzlWLEmUm68sMUWbeSRZUx79EhUopHdwIFdcBk1NMPMWJ45wN8wUhSKB9HJZ03NYQ4pW75zCnq23M2r0N14qB0r4ScVIjyLUSLuRfdZe1PIzQmJWTaOOmLhmxXDi7BewnJw==; 24:8Oh0GM03ZjFZ6gNURj/lKni7s/x8dIO1OjyMg+uHzSGR5KH3razhPBYJaI9cuor7ZLqG5CNKmNkFKzCYTWYeTMjG2IWbiOcIVc48iuIM/wE=; 20:IqIFj/krD154Ii0H/MkcxKoN4LSURFle2op6NQ5nZThH6b5D7tXd7DM6LCl6B7m8PsTZ0gA9VkNXZdhCtHmFKxVnPOh74qn2t8jyfjrfHMoIK0xmi8kXirFHDZqfcd8ADyPSwMYNq/SNAx/CiqUgxYJq7dOfOqagU49hBKmijNI= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB146; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BL2PR03MB146; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB146; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(51444003)(164054003)(377454003)(479174004)(24454002)(189002)(199003)(97736004)(86362001)(4001350100001)(81156007)(5001960100002)(5001770100001)(189998001)(83716003)(66066001)(82746002)(83506001)(50986999)(54356999)(87936001)(102836003)(2900100001)(11100500001)(106356001)(6116002)(106116001)(586003)(5004730100002)(105586002)(15975445007)(92566002)(5002640100001)(229853001)(2906002)(40100003)(122556002)(10400500002)(36756003)(33656002)(19580405001)(19580395003)(5008740100001)(99286002)(1220700001)(1096002)(101416001)(4326007)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB146; H:BL2PR03MB148.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: tableau.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 16:03:13.0562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5067385a-c584-42cc-8679-3fa2879f99be X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB146 X-MC-Unique: T6hb9h1TRTaWTDFvBN9uUA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:03:39 -0000 V2hvb3BzLCB0aGFua3MgZm9yIHRoZSBjb3JyZWN0aW9uLiAgSXQgc2hvdWxkIGJlIHRoZSBjb2Rl IHBvaW50IGFzc2lnbm1lbnQgaW4gZHJhZnQtaWV0Zi10bHMtcmZjNDQ5MmJpcy0wNSBmb3IgQ3Vy dmUyNTUxOSwgQ3VydmU0NDgsIEVkMjU1MTkgYW5kIEVkNDQ4LiANCg0KVGhhbmtzLA0KDQpKb2UN Cg0KDQoNCg0KDQpPbiAxLzEyLzE2LCA2OjI0IEFNLCAiU2ltb24gSm9zZWZzc29uIiA8c2ltb25A am9zZWZzc29uLm9yZz4gd3JvdGU6DQoNCj5BZGFtIExhbmdsZXkgPGFnbEBpbXBlcmlhbHZpb2xl dC5vcmc+IHdyaXRlczoNCj4NCj4+IEN1cnZlMjU1MTksIGFzIHRoZSBuYW1lIHN1Z2dlc3RzLCBv cGVyYXRlcyBvbiAyNTUtYml0IG51bWJlcnMuIFdoZW4NCj4+IGVuY29kZWQgYXMgYnl0ZXMsIHRo ZXJlJ3Mgb2J2aW91c2x5IGEgMjU2dGggYml0IHRoYXQgbmVlZHMgdG8gYmUNCj4+IHNwZWNpZmll ZC4NCj4+DQo+PiBDdXJ2ZTI1NTE5IGltcGxlbWVudGF0aW9ucyBkaWRuJ3Qgc2V0IHRoZSBiaXQg YnV0IGRpZCB1c2VkIHRvIHZhcnkgb24NCj4+IGhvdyB0aGV5IHBhcnNlZCBpdC4gU29tZSB3b3Vs ZCB0YWtlIGEgMjU2LWJpdCBudW1iZXIgYW5kIHJlZHVjZSBpdA0KPj4gd2hpbGUgb3RoZXJzIHdv dWxkIGlnbm9yZSB0aGUgYml0IGNvbXBsZXRlbHkuDQo+Pg0KPj4gSG93ZXZlciwgSSBiZWxpZXZl IHRoYXQgaW1wbGVtZW50YXRpb25zIGhhdmUgY29udmVyZ2VkIG9uIGlnbm9yaW5nIGl0Lg0KPj4g VGhhdCBiZWhhdmlvdXIgaXMgc3BlY2lmaWVkIGluIGRyYWZ0LWlydGYtY2ZyZy1jdXJ2ZXMgYW5k IHRlc3RlZCB2aWENCj4+IHRoZSB0ZXN0IHZlY3RvcnMuDQo+Pg0KPj4gQ3VycmVudGx5IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1jdXJ2ZTI1NTE5LTAxI3NlY3Rp b24tMi4zDQo+PiBzYXlzIHRoYXQgaW1wbGVtZW50YXRpb25zIFNIT1VMRCByZWplY3QgaW5wdXRz IHdpdGggdGhlIGhpZ2gtYml0IHNldC4NCj4+IEkgdGhpbmsgdGhhdCBzaG91bGQgYmUgZHJvcHBl ZC4gVGhlIFgyNTUxOSBmdW5jdGlvbiBpcyBzcGVjaWZpZWQgaW4NCj4+IHRlcm1zIG9mIGJ5dGVz IGluIGRyYWZ0LWlydGYtY2ZyZy1jdXJ2ZXMgYW5kIEkgdGhpbmsgdGhlIFRMUyBzcGVjDQo+PiBz aG91bGQganVzdCB1c2UgdGhhdCBkcmFmdC4NCj4NCj5JIGFncmVlLg0KPg0KPi9TaW1vbg0K From nobody Tue Jan 12 08:45:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C801A21A5 for ; Tue, 12 Jan 2016 08:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRyjCwXtfZls for ; Tue, 12 Jan 2016 08:45:28 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5881A1E0E for ; Tue, 12 Jan 2016 08:45:27 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id t64so24576692qke.1 for ; Tue, 12 Jan 2016 08:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ZT9vUiIFdUzaZbmf7GjTdVbG6/XjU2uNuenzw2K1eeM=; b=qGj3DMzWsDoIl0NURRENb5/NZV1I4GcgyA4R9WLeqOQGLXJh8r/eULn7VxLq31WYu2 qK+0xc9ME3nbFCnfSDKGuS6MujIOX8KXKLakuWH5wu/1vIQvft+QfY0J8FRdXYvGYhHm vsTxUZS70wS28u/SuZ4iZvqa4Jwc/Xtw4oOkMUYX1Xfnm+NCs44JqYyPEszwtOVZTZm8 XKZdabrCHLtSheLGZ7O9CCoKFuboz9JsC9LrvsdYfRePare19ul/Mfr//d3rl/SF2Uim vV9s6e/RB2rg53hEgi601c0q6phMZvl7B50lfE/sv3UtDPUZyi9aH+mCXrpxvq8V07Bq jVgw== X-Received: by 10.55.71.135 with SMTP id u129mr175212782qka.26.1452617127022; Tue, 12 Jan 2016 08:45:27 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id x79sm57177594qka.37.2016.01.12.08.45.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 08:45:26 -0800 (PST) From: Dave Garrett To: Stephen Farrell Date: Tue, 12 Jan 2016 11:45:25 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160111183017.GA12243@roeckx.be> <201601112242.46115.davemgarrett@gmail.com> <5694DDE1.5040308@cs.tcd.ie> In-Reply-To: <5694DDE1.5040308@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601121145.25426.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:45:30 -0000 On Tuesday, January 12, 2016 06:05:05 am Stephen Farrell wrote: > A few notes on this: > > - Calling for the IETF to do something isn't how it works. People > who want thing X to be done need to write the draft and then see > if it gets support. I suspect an md5-die-die-die draft would get > quite a bit of support but... I'm just bringing up the idea to see what kind of support there is. I don't particularly want to write up a draft in full on my own without discussing it first. > - The points Victor made about long-term stored data are valid. > In various cases it simply wouldn't be a good plan to re-encrypt > or re-sign old data. Yes, that stored data may not be as secure > as it once was, but it may be impractical to re-encrypt it all. > The openpgp wg [1] are dealing with this particular issue as they > work to do updates, so feel free to get involved in that debate > there if it's of interest. Yes, decryption of long term storage would have to be one notable exception. The main concern is is with real time (or near) security protocols like TLS, SSH, & etc. It's also important to note that just because we shouldn't be doing obsolete and risky things in modern software, that doesn't mean that old software (even if maintained) shouldn't be allowed to exist at all. However, doing both in the same application has proven to be very dangerous. On the client side, having separate legacy clients with no modern support and modern clients with no legacy support would drastically improve security, not to mention force users to actively acknowledge when they're doing something risky. (yes, the server side isn't as simple, nor is this always viable on the client side, either) > - If your envisaged scope is for all IETF protocols, then I'm sad > to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing > folks just won't let die it seems, even though we formally obsoleted > that [3] 5 years ago. (And yes, that really is sad.) Yeah... stuff like that is why I kinda don't want to write up a whole draft to change the world on my own. ;) > - Lastly, and again if your envisaged scope is to deprecate MD5 for > all IETF protocols then that might better fit the charter of the new > curdle wg. [4] And your draft might be an update to RFC6151 [5] I > guess, depending on how you wrote it. > > So by all means, write the draft and post a link to the curdle > list (maybe cc'ing this). Yes, I am aware of the new CURDLE WG. Brining up the idea here first simply made more sense, as MD5 was already coming up in discussion here again. Rich Salz also suggested CURDLE being the ideal place to deal with this topic, and I don't disagree. Near as I can tell, though, TLS isn't directly within its charter and a consensus on what to do for it would have to come out of the TLS WG first before CURDLE would be able to include it in any widespread MD5 I-D. > Cheers, > S. > > [1] https://tools.ietf.org/wg/openpgp/ > [2] https://tools.ietf.org/html/rfc2385 > [3] https://tools.ietf.org/html/rfc5925 > [4] https://tools.ietf.org/wg/curdle > [5] https://tools.ietf.org/html/rfc6151 Dave From nobody Tue Jan 12 09:02:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC281B2B5D for ; Tue, 12 Jan 2016 09:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO6JKdp6XC3N for ; Tue, 12 Jan 2016 09:02:36 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 EBBF71B2B50 for ; Tue, 12 Jan 2016 09:02:28 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id e32so344476024qgf.3 for ; Tue, 12 Jan 2016 09:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Pd0GIYDEMMI3QIP4lX9Amf25IMwLQK42vRTXIka7r0g=; b=xZF8bodmeDdjA7etGb+22OHtjZO8ICQ0nZ6heKevINDovtVUZj3gxMJX/KUdhD65sz ynZeO9mU+YNKFRblBVKGYHA6kCWMloG89QJtohCy9BoyQedBF0xBx2FJNyTahAKgXNa2 o7JaaO1K7Gc9wHNnVPS7L+PGizs4v5fhFb9wwxVSzytAUZT/ZSsoSfKpfNzLq/DhIy57 flV7lJMd5LACmdqjSNsWWjf2oL4hx7O1tlMQ2o21IAeDkOl4Pd8r617xI7ZBr8PjT7Tr MLe03K1Bkao1WrRTYxjTPzgbDY/ZFtiE9t5hEh5E+aPlBIVlfEBaXLOl2ihUcVBU5AvJ xToA== X-Received: by 10.140.19.52 with SMTP id 49mr170228473qgg.65.1452618148181; Tue, 12 Jan 2016 09:02:28 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id s188sm52168176qhc.41.2016.01.12.09.02.27 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 09:02:27 -0800 (PST) From: Dave Garrett To: Peter Gutmann Date: Tue, 12 Jan 2016 12:02:26 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201601121202.26624.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:02:37 -0000 On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from > TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discussion > centered around the fact that we already have lots of analysis done for TLS > 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 > problems while being as compatible as possible with existing infrastructure. > So what this would do is take existing security analysis applied to TLS, [...] Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks. I'll be the bearer of bad news and tell you that your proposal has come up in multiple forms. I suggested a similar thing a while back and far before me others have as well. The chairs have, however, long declared consensus that we want to focus on a single new version not leaving out other more complex changes, namely latency improvements. The primary argument is that TLS version adoption rates are horrible and we would be far better suited to one major upgrade rather than incremental changes that would likely inhibit adoption of the more complex changes that we also need. (just a quick summary from my view; someone else can chime in here if they need to) I can't dispute this position, though personally I think it's not the best move. That said, if we were going to do a more incremental TLS version, doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up with would have been the way to go. That ship has sailed, and we're now well into TLS 1.3 development, so I guess I'm now on board with working to finalize the work that we're already doing (frankly, with a rename to TLS 2.0 being a good idea). If you can somehow drum up consensus to overturn the previous consensus, more power to you, but I think that's not likely to be the best route anymore. Dave From nobody Tue Jan 12 09:13:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6E1B2B6D for ; Tue, 12 Jan 2016 09:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gs3Ul6Voq5Q for ; Tue, 12 Jan 2016 09:13:44 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FAE1B2B6C for ; Tue, 12 Jan 2016 09:13:44 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f206so331454246wmf.0 for ; Tue, 12 Jan 2016 09:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BKveq88VYlGfQjlCGxnGkSh8njiuqHsyQa9teQTWljk=; b=q8TdeBgOQjnz5kL5EKzXJPcvzzYDdPTxDehECq1ibH6odx35yPd3twpP2apAtrA1pO pz07VhQ3umqYG7BbzCHtXVmhrtCMJk/okgMSEAXT5QlrqK25IOEF0Wv0PaMKxQNVi9iA CbKQYCcfA7DnrY4zxeEsogQdSjDoJmftIwxgXs0RDYyTtwVbasFNWl3wmyLEmOkJ8mOF XtfeCfbdiKsF2EAIjGfFc9wgaD54ptvNqdvMzQ23cprzymEzKW+FKpGyUBj2XPleHgbE 3MdicTSBV3ewIp0kTr9nF/AUzLe2iNvkkeD8YCun2yoDLrCsl+A+WB6nZ8JSZqY0PwW0 Sunw== X-Received: by 10.194.79.227 with SMTP id m3mr139622821wjx.5.1452618823059; Tue, 12 Jan 2016 09:13:43 -0800 (PST) Received: from [192.168.137.45] ([109.253.223.29]) by smtp.gmail.com with ESMTPSA id t9sm70880707wjf.33.2016.01.12.09.13.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 09:13:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 12 Jan 2016 19:13:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:13:47 -0000 Hi, Peter Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or = 2.0) that this WG is working on right now, why? Other groups are not working on HTTP/1.2 or IKEv1.1 or any other = $protocolv$(major-1).$(minor+1). Any TLS library that exists now doesn=E2=80=99t have an implementation = of either =E2=80=9Cyour=E2=80=9D TLS 1.3 or =E2=80=9Cour=E2=80=9D TLS = 1.3. To get either, you=E2=80=99ll need to get an upgraded version of = your favorite library. So the upgrade path is no smoother for either = protocol. If this had been brought up before the work on the current = draft started, maybe we would be convinced. As it is, I don=E2=80=99t = see the point. Yoav > On 12 Jan 2016, at 4:03 PM, Peter Gutmann = wrote: >=20 > Martin's comment reminded me of the following that I've been meaning = to > post... >=20 > In a recent discussion among some crypto folks, the topic of what TLS = 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade = path from > TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The = discussion > centered around the fact that we already have lots of analysis done = for TLS > 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < = 1.3 > problems while being as compatible as possible with existing = infrastructure. > So what this would do is take existing security analysis applied to = TLS, > namely: >=20 > Bhargavan et al, "Proving the TLS handshake secure (as is)". >=20 > Brzuska et al, "Less is more: relaxed yet compatible security notions = for key > exchange". >=20 > Dowling et al, "Modelling ciphersuite and version negotiation in the = TLS > protocol". >=20 > Firing, "Analysis of the Transport Layer Security protocol". >=20 > Gajek et al, "Universally Composable Security Analysis of TLS". >=20 > Giesen et al, "On the security of TLS renegotiation". >=20 > Jager et al, "On the security of TLS-DHE in the standard model". >=20 > Krawczyk et al, "On the security of the TLS protocol". >=20 > (and probably several more) and use them to simplify TLS 1.2 to create = an > improved TLS that leverages about 15 years of analysis, rather than = creating > what's almost a new protocol based on bleeding-edge/experimental = ideas, > mechanisms, and algorithms. >=20 > The discussion started out somewhat informally so by the time it got = really > interesting it was too late to take notes, but I thought I'd try and = recreate > the design points... >=20 > - Drop 99% of all cipher suites, leaving one traditional one (DHE + = AES-CBC + > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + = HMAC- > SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference = for OCB > instead of GCM as the AEAD if it were freely available). >=20 > - For the non-AEAD cipher, use EtM not MtE (so effectively making it = AEAD as > well). >=20 > - Get rid of the IPsec cargo-cult MAC truncation. >=20 > - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS = #3) to > allow verification (for those who don't have a copy of X9.42, it = requires > the same verification steps as FIPS 186 does). Also, mix the hash of = the > DHE values into the computed premaster secret to protect against use = of > manipulated curves. >=20 > - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the = sig-check > done as encode-then-compare, which fixes all known = padding-manipulation > issues). >=20 > - No compression or rehandshake. >=20 > - Replace the PRF with HKDF? (No pressing need for this, but it would = be part > of the general cleanup). >=20 > Longer discussion points: >=20 > - The DHE/ECDHE parameters were a bit contentious. For DHE the choice = is > between server-specified ephemeral parameters and IETF-blessed fixed = ones. > Arguments can be made either way, we had de facto IETF-blessed fixed = DHE > params in the form of the RFC 2409 ones, but that wasn't such a good = idea. > OTOH with ephemeral DHE params many implementations didn't check them, = but > then the spec never required any checking (or much of anything at all = in > regard to DHE use, which no doubt contributed to some of the dubious > practices that have been found in the wild). The situation wasn't = helped by > the use of the PKCS #3 representation, which the requirement to use = the > X9.42 form alongside the accompanying checks attempts to address. >=20 > - Similarly, for ECDHE the choice is between NIST and CFRG ones. The = CFRG > ones are obviously better (for various values of better, see endless = debates > elsewhere), but some people will insist on only using something that's = come > from NIST (I'll reserve my opinion on that one, and wouldn't dream of > stooping to phrases like "cargo cult protocol design"...). >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jan 12 09:17:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885071A00BB for ; Tue, 12 Jan 2016 09:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vWoGEC0asXW for ; Tue, 12 Jan 2016 09:17:12 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67A1A00A8 for ; Tue, 12 Jan 2016 09:17:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 05F43467 for ; Tue, 12 Jan 2016 19:17:10 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id FqkqmmgejqdJ for ; Tue, 12 Jan 2016 19:17:09 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AF603138 for ; Tue, 12 Jan 2016 19:17:09 +0200 (EET) Date: Tue, 12 Jan 2016 19:17:06 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160112171706.GA16749@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:17:15 -0000 On Tue, Jan 12, 2016 at 02:03:53PM +0000, Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from > TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discussion > centered around the fact that we already have lots of analysis done for TLS > 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 > problems while being as compatible as possible with existing infrastructure. > So what this would do is take existing security analysis applied to TLS, > namely: Don't forget that there is lots of "features" that are security problems to deprecate. And that alone creates problems with software trying to use those. > (and probably several more) and use them to simplify TLS 1.2 to create an > improved TLS that leverages about 15 years of analysis, rather than creating > what's almost a new protocol based on bleeding-edge/experimental ideas, > mechanisms, and algorithms. Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10 years old. The basic framework for doing 0-RTT is the obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old. So I don't see anything "experimential" ideas, mechanisms or algorithms in there > The discussion started out somewhat informally so by the time it got really > interesting it was too late to take notes, but I thought I'd try and recreate > the design points... > > - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC + > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC- > SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB > instead of GCM as the AEAD if it were freely available). DHE has serious problems. While the present TLS 1.3 way of doing DHE isn't totally horrible, advertise DHE and you can get downnegotiation to TLS 1.2 DHE, and now you are screwed. Also, AES-CBC has multitude of problems. And they actually dropped most of the ciphersuites. > - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as > well). Easier to define everything in terms of AEAD mode. Making generic composition AES-CBC+HMAC-SHA2 isn't as easy as it seems (even pro cryptographers may not get that right). > - Get rid of the IPsec cargo-cult MAC truncation. Finished hashes are no longer truncated (which turned to be a security problem). > - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to > allow verification (for those who don't have a copy of X9.42, it requires > the same verification steps as FIPS 186 does). Also, mix the hash of the > DHE values into the computed premaster secret to protect against use of > manipulated curves. The needed checks at that length are just too slow for realtime. > - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check > done as encode-then-compare, which fixes all known padding-manipulation > issues). Well, the server sig for RSA is RSA-PSS (the recommendation about encode- and-compare isn't the tho). > - No compression or rehandshake. They dropped those. > - Replace the PRF with HKDF? (No pressing need for this, but it would be part > of the general cleanup). They replaced it with just that. > Longer discussion points: > > - The DHE/ECDHE parameters were a bit contentious. For DHE the choice is > between server-specified ephemeral parameters and IETF-blessed fixed ones. > Arguments can be made either way, we had de facto IETF-blessed fixed DHE > params in the form of the RFC 2409 ones, but that wasn't such a good idea. > OTOH with ephemeral DHE params many implementations didn't check them, but > then the spec never required any checking (or much of anything at all in > regard to DHE use, which no doubt contributed to some of the dubious > practices that have been found in the wild). The situation wasn't helped by > the use of the PKCS #3 representation, which the requirement to use the > X9.42 form alongside the accompanying checks attempts to address. Dubious? I would say downright insecure (including some I would say F grade in SSL labs is too generous). > - Similarly, for ECDHE the choice is between NIST and CFRG ones. The CFRG > ones are obviously better (for various values of better, see endless debates > elsewhere), but some people will insist on only using something that's come > from NIST (I'll reserve my opinion on that one, and wouldn't dream of > stooping to phrases like "cargo cult protocol design"...). There's also Brainpool (if you want to burn CPU, those are just inefficient). :-) -Ilari From nobody Tue Jan 12 09:27:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5462F1A0104 for ; Tue, 12 Jan 2016 09:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG6Hd3OQorBq for ; Tue, 12 Jan 2016 09:27:42 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB8C1A00FF for ; Tue, 12 Jan 2016 09:27:40 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id e65so66178161pfe.0 for ; Tue, 12 Jan 2016 09:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=alfQ+ODx2AOKjQi3++/rvXDfFKwrbzApCeNlyPqzH9c=; b=e9kupY9s7f27XAZ+DNd5wxw5usB27bqLSBy2xIAq96g0JNEDWl+FMCZ7o8B3Reh7a3 mGcLypkZkkG1ihw2cfp3OgEqtpl08jA+P1+3HFLIx3oDFSk0LghuNwhMYnVL2eQ3uLgQ ZvuzShzQNViKAm5/Xs0f+dE7XqvU847aNg8dP0UCKXPiFz9rRbgqggBveeY36ICL8U7z 3QowjmLJ8TZbzvo4/2guLidw4ygXJ6MyI25lxBWsVCQDRz8K1kZLq5BW33Vqf336e7mV d1bty7pQYm0qQKMtOWp2xaDI1OxaxScbWTZcs2b8f30n1rxRYLvGhRmD0CHU2yNERDVO Gagg== MIME-Version: 1.0 X-Received: by 10.98.13.7 with SMTP id v7mr35702482pfi.150.1452619660466; Tue, 12 Jan 2016 09:27:40 -0800 (PST) Received: by 10.66.142.193 with HTTP; Tue, 12 Jan 2016 09:27:40 -0800 (PST) In-Reply-To: <201601121202.26624.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> Date: Tue, 12 Jan 2016 09:27:40 -0800 Message-ID: From: Peter Bowen To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:27:44 -0000 On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrot= e: > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >> Martin's comment reminded me of the following that I've been meaning to >> post... >> >> In a recent discussion among some crypto folks, the topic of what TLS 1.= 3 >> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade pat= h from >> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discu= ssion >> centered around the fact that we already have lots of analysis done for = TLS >> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >> problems while being as compatible as possible with existing infrastruct= ure. >> So what this would do is take existing security analysis applied to TLS, > [...] > > Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snac= ks. > > I'll be the bearer of bad news and tell you that your proposal has come u= p in multiple forms. I suggested a similar thing a while back and far befor= e me others have as well. The chairs have, however, long declared consensus= that we want to focus on a single new version not leaving out other more c= omplex changes, namely latency improvements. Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter way to go to document a profile of TLS 1.2 that covers almost all of this. From a quick read, existing RFCs and I-Ds cover most of this: - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256) - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256) - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) - RFC 7366 (EtM) - RFC 7627 (extended master secret) - RF 4055 (RSA-PSS) The gaps seem to be: - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated (BoringSSL has an implementation using cipher suite 0xca,0xfe) - DH parameters -- the alternative would be using FFDH named groups (draft-ietf-tls-negotiated-ff-dhe-10), right? This would only leave "Get rid of the IPsec cargo-cult MAC truncation", rig= ht? Thanks, Peter From nobody Tue Jan 12 09:29:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E471C1A00FD for ; Tue, 12 Jan 2016 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ausx0hpcbxua for ; Tue, 12 Jan 2016 09:29:17 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 D16571A00FF for ; Tue, 12 Jan 2016 09:29:16 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id x67so460047917ykd.2 for ; Tue, 12 Jan 2016 09:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e/qjhHCm5sfv6S/eYBe0JcjgJC4zWjfT8C960oOquLU=; b=sHEfekkNF+6Qc4RZBMEsCKnVwsrmi7ybqIPlSTkRYXjdSRztAJZVVI6fXbOtkCQ7lN clakYkjv+3g2jfy+3Oj6D2KQPhUBlTyz+ZP97hTgVhbEH4fBGcYn2fIcOd6Cclc3v6LJ qQO5aXaj+X+VgDsTeWNRQqXz7mJcrarA3rw4/CM3CE390NpcneEYGKmFPl+/5wFpQAJF o4suxsvV7lTQM9ZuFrQI1wnmyJ7u/WfSULVBKZBoKeV3S2dWMZkir9LtJNr9Ac3XwUav Dz5SfYj2828jdEw5gTPhcD7jPlrW/EZqr9LLyyaCF8W8ErgoV2MnRYjvsaAfLeLiHcr4 OzOA== MIME-Version: 1.0 X-Received: by 10.13.213.215 with SMTP id x206mr99978757ywd.97.1452619756173; Tue, 12 Jan 2016 09:29:16 -0800 (PST) Received: by 10.13.216.150 with HTTP; Tue, 12 Jan 2016 09:29:16 -0800 (PST) In-Reply-To: <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> Date: Tue, 12 Jan 2016 09:29:16 -0800 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:29:24 -0000 On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)= that this WG is working on right now, why? > > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other $protoco= lv$(major-1).$(minor+1). > > Any TLS library that exists now doesn=E2=80=99t have an implementation of= either =E2=80=9Cyour=E2=80=9D TLS 1.3 or =E2=80=9Cour=E2=80=9D TLS 1.3. To= get either, you=E2=80=99ll need to get an upgraded version of your favorit= e library. So the upgrade path is no smoother for either protocol. If thi= s had been brought up before the work on the current draft started, maybe w= e would be convinced. As it is, I don=E2=80=99t see the point. Not if TLS 1.2.1 is a subset of TLS 1.2, similar to the UTA profile. In fact, that's what happened the last time this idea was raised: it got kicked over to UTA. > > Yoav > > >> On 12 Jan 2016, at 4:03 PM, Peter Gutmann wr= ote: >> >> Martin's comment reminded me of the following that I've been meaning to >> post... >> >> In a recent discussion among some crypto folks, the topic of what TLS 1.= 3 >> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade pat= h from >> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discu= ssion >> centered around the fact that we already have lots of analysis done for = TLS >> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >> problems while being as compatible as possible with existing infrastruct= ure. >> So what this would do is take existing security analysis applied to TLS, >> namely: >> >> Bhargavan et al, "Proving the TLS handshake secure (as is)". >> >> Brzuska et al, "Less is more: relaxed yet compatible security notions fo= r key >> exchange". >> >> Dowling et al, "Modelling ciphersuite and version negotiation in the TLS >> protocol". >> >> Firing, "Analysis of the Transport Layer Security protocol". >> >> Gajek et al, "Universally Composable Security Analysis of TLS". >> >> Giesen et al, "On the security of TLS renegotiation". >> >> Jager et al, "On the security of TLS-DHE in the standard model". >> >> Krawczyk et al, "On the security of the TLS protocol". >> >> (and probably several more) and use them to simplify TLS 1.2 to create a= n >> improved TLS that leverages about 15 years of analysis, rather than crea= ting >> what's almost a new protocol based on bleeding-edge/experimental ideas, >> mechanisms, and algorithms. >> >> The discussion started out somewhat informally so by the time it got rea= lly >> interesting it was too late to take notes, but I thought I'd try and rec= reate >> the design points... >> >> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-= CBC + >> HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HM= AC- >> SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for = OCB >> instead of GCM as the AEAD if it were freely available). >> >> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEA= D as >> well). >> >> - Get rid of the IPsec cargo-cult MAC truncation. >> >> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #= 3) to >> allow verification (for those who don't have a copy of X9.42, it require= s >> the same verification steps as FIPS 186 does). Also, mix the hash of th= e >> DHE values into the computed premaster secret to protect against use of >> manipulated curves. >> >> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-c= heck >> done as encode-then-compare, which fixes all known padding-manipulation >> issues). >> >> - No compression or rehandshake. >> >> - Replace the PRF with HKDF? (No pressing need for this, but it would b= e part >> of the general cleanup). >> >> Longer discussion points: >> >> - The DHE/ECDHE parameters were a bit contentious. For DHE the choice i= s >> between server-specified ephemeral parameters and IETF-blessed fixed one= s. >> Arguments can be made either way, we had de facto IETF-blessed fixed DHE >> params in the form of the RFC 2409 ones, but that wasn't such a good ide= a. >> OTOH with ephemeral DHE params many implementations didn't check them, b= ut >> then the spec never required any checking (or much of anything at all in >> regard to DHE use, which no doubt contributed to some of the dubious >> practices that have been found in the wild). The situation wasn't helpe= d by >> the use of the PKCS #3 representation, which the requirement to use the >> X9.42 form alongside the accompanying checks attempts to address. >> >> - Similarly, for ECDHE the choice is between NIST and CFRG ones. The CF= RG >> ones are obviously better (for various values of better, see endless deb= ates >> elsewhere), but some people will insist on only using something that's c= ome >> from NIST (I'll reserve my opinion on that one, and wouldn't dream of >> stooping to phrases like "cargo cult protocol design"...). >> >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Jan 12 09:42:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60E31A0105 for ; Tue, 12 Jan 2016 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 6AOP7G3ze0aO for ; Tue, 12 Jan 2016 09:42:06 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 3AB201A00FC for ; Tue, 12 Jan 2016 09:42:06 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id x67so460491880ykd.2 for ; Tue, 12 Jan 2016 09:42:06 -0800 (PST) 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:content-type; bh=XTy5SJbfv1nHD+qDfybUsOvDgVKgDd9oVTULoLJ5DmQ=; b=eCbYBxM46SDLeIpscTnQ6Xp8QFI4oPhnV0xSE3XRIlQDWJRTwtzC287/XPu6MB8ebN 5gpvB1zOiLQXutyeWUMpmBYaiaNs/3oBD/oqvMBnaMh7NWg5ud667MscGIuRMNrMohg2 4hJLuEly2gsNVr/LAVNIorn/wTk2TJyk2RpvNHNnfLtf5Pd+GyBisHbiJb3mxg9VsKrW yXwb8wVKrqEv8cnkiTWgR2wX/Usl+lUz7JNYZ3G2VjOvzhKcfuFfa5zSpImVFZBd4Pzi J3lVhnP+jrbrXGj2HK9uuBaYCC4kVnepNFnXD9JGc/AWhGBs0nP/4zyg2hSKLDkpF5EG fvqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XTy5SJbfv1nHD+qDfybUsOvDgVKgDd9oVTULoLJ5DmQ=; b=OYZgC3noVvkXJDehgL5b8bK3zUGsPqpNKkTi5CDHmBGbuqubedTmrlm+adPBQRFh+n JidDv+/oGtOkTQ9pppQ4dwYhJXlERyps+WW4jciLUX6uqbbWWm8Xpa5ZObtotaiB1PLR gMat6BocKJo2j4GuR8qED+NMA39oCjC+9veh8SAfGyqbKyueiq4vrPDjysKL5sJSZP0I 1C6RMgJ5nSAvxwGPGKgxWrPlMSN9WSYbJsS4cPw1UZJfTbEcbtdGCIzjJJ1gxVN5dyWK xcCg2qT3yuNgXsXhwIi2aY6tXppXYF2QMzJ2CtZZSXKZJKn/Itp7bwbcr+aBCQQbh+Jn jFlg== X-Gm-Message-State: ALoCoQnOzubp1QcGOUrkq97nHkJOfUJYJUPpo0yq149VTGFuF4G90neno7xKeswr1fldgbGV8YvBRliZ0W6sFAa02Y+5JjwTzg== X-Received: by 10.129.79.87 with SMTP id d84mr96322062ywb.115.1452620525571; Tue, 12 Jan 2016 09:42:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 09:41:26 -0800 (PST) In-Reply-To: <20160112171706.GA16749@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <20160112171706.GA16749@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 12 Jan 2016 09:41:26 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114dc3606bc21d052926928c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:42:07 -0000 --001a114dc3606bc21d052926928c Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara wrote: > > > - Drop 99% of all cipher suites, leaving one traditional one (DHE + > AES-CBC + > > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + > HMAC- > > SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference > for OCB > > instead of GCM as the AEAD if it were freely available). > > DHE has serious problems. While the present TLS 1.3 way of doing DHE > isn't totally horrible, advertise DHE and you can get downnegotiation to > TLS 1.2 DHE, and now you are screwed. > Nit: this shouldn't be possible with the anti-downgrade mechanism that was introduced in draft-11 because the server's signature will cover the random value. If you area aware of an issue here, I would appreciate more information. -Ekr --001a114dc3606bc21d052926928c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AE= S-CBC +
>=C2=A0 =C2=A0HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE = + AES-GCM + HMAC-
>=C2=A0 =C2=A0SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a stro= ng preference for OCB
>=C2=A0 =C2=A0instead of GCM as the AEAD if it were freely available).
DHE has serious problems. While the present TLS 1.3 way of doing DHE=
isn't totally horrible, advertise DHE and you can get downnegotiation t= o
TLS 1.2 DHE, and now you are screwed.

N= it: this shouldn't be possible with the anti-downgrade mechanism that w= as introduced
in draft-11 because the server's signature will= cover the random value. If you area
aware of an issue here, I wo= uld appreciate more information.

-Ekr

--001a114dc3606bc21d052926928c-- From nobody Tue Jan 12 09:51:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9D1A0167 for ; Tue, 12 Jan 2016 09:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahrjzI8k1cEf for ; Tue, 12 Jan 2016 09:51:30 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5101A0158 for ; Tue, 12 Jan 2016 09:51:29 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id n128so66259671pfn.3 for ; Tue, 12 Jan 2016 09:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ku2T6n4XXs7Hf97fENqGdbtukG+0mOV4lQk2xmEBRl0=; b=Esu8Bq9C+DNaTq7rjgiOV4GSw9V7HtL/OH09x2lcBtCoNNGD/ZycrTNyaARXriC2FK ZCmZo+TMhR3mWAaasZEGSbEBLPSyGsO+XgR0K9EXQ6N29Ub3pFYHW+JkdMHuSu33jgkH DiezW2ReKpW9MhyoBjb5ag2pjGHCUaEz6SXBJYQ6GobPxcbhsgPZq6T5UTh53CAkzCDw N1GO1HyoYwRHZ5nXMW1dtdQrDOxuRsGzWojFPCMN/kpAkWHDQzzu/qgpjmgFPOHJssvI hbdJsmPX2JmpnVCpVZ6g+JYfi9qLO4pfn8GbP+mY6nshT8KMBrsl53rFurO7R//KpFVx ikvw== MIME-Version: 1.0 X-Received: by 10.98.9.147 with SMTP id 19mr30766425pfj.163.1452621088852; Tue, 12 Jan 2016 09:51:28 -0800 (PST) Received: by 10.66.142.193 with HTTP; Tue, 12 Jan 2016 09:51:28 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> Date: Tue, 12 Jan 2016 09:51:28 -0800 Message-ID: From: Peter Bowen To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:51:31 -0000 On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wr= ote: >> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >>> Martin's comment reminded me of the following that I've been meaning to >>> post... >>> >>> In a recent discussion among some crypto folks, the topic of what TLS 1= .3 >>> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade pa= th from >>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The disc= ussion >>> centered around the fact that we already have lots of analysis done for= TLS >>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >>> problems while being as compatible as possible with existing infrastruc= ture. >>> So what this would do is take existing security analysis applied to TLS= , >> [...] >> >> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have sna= cks. >> >> I'll be the bearer of bad news and tell you that your proposal has come = up in multiple forms. I suggested a similar thing a while back and far befo= re me others have as well. The chairs have, however, long declared consensu= s that we want to focus on a single new version not leaving out other more = complex changes, namely latency improvements. > > Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter > way to go to document a profile of TLS 1.2 that covers almost all of > this. From a quick read, existing RFCs and I-Ds cover most of this: > - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256) > - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256) > - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) > - RFC 7366 (EtM) > - RFC 7627 (extended master secret) > - RF 4055 (RSA-PSS) > > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. Still no cipher suite allocated, but there is an active draft. > - DH parameters -- the alternative would be using FFDH named groups > (draft-ietf-tls-negotiated-ff-dhe-10), right? > > This would only leave "Get rid of the IPsec cargo-cult MAC truncation", r= ight? > > Thanks, > Peter From nobody Tue Jan 12 10:06:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616621A0252 for ; Tue, 12 Jan 2016 10:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uscRC-DoePdu for ; Tue, 12 Jan 2016 10:06:35 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 60AFD1A024E for ; Tue, 12 Jan 2016 10:06:35 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id 6so356462946qgy.1 for ; Tue, 12 Jan 2016 10:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=GmeHU+y2xSccMHJe/O7OAx8yMjpUkzVVqdDYfNJt7IQ=; b=yx1Ghra0MiffNOsZDfM5ccImxEk65NucSkeHv+JWq5YppDdCl3kwriq3NsM7eIiN1w jaWqQSEa+kfQLPcTVhBl1T6UNdOFJIohrCC3XL8sCItVmhGj7JG3sgF4zezTFi9xCnXR xuquBGpTVS5FipmQRWm4smUtM07u2LBQ3aibJNAGCkj2X5gSf0AYdZRPQ4ppJJJ7PUO2 wnzEidD/tMwIKaTUU7g/dvTpHxMtkNhAIDM/c+l21HQ6oxQ5k1uFPd5fjrTTxr4Jh767 yvErqLo3L96ud97G1X206tpeoby+RZ3gKgmxtyXu9Hy4NCdj/4n3v/ODNdOSij2i5I5y WOrw== X-Received: by 10.140.137.199 with SMTP id 190mr179843807qhj.91.1452621994406; Tue, 12 Jan 2016 10:06:34 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id o75sm10598915qgd.12.2016.01.12.10.06.33 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 10:06:33 -0800 (PST) From: Dave Garrett To: Peter Bowen Date: Tue, 12 Jan 2016 13:06:32 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601121306.32859.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:06:37 -0000 On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote: > On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote: > > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > > Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. > Still no cipher suite allocated, but there is an active draft. I have a short WIP PR for integrating these suites into the TLS 1.3 draft sitting on GitHub, by the way. https://github.com/tlswg/tls13-spec/pull/381 Unless I'm misunderstanding the procedure here, though, that draft needs to progress to WG adoption before we're ready for it here. (hence the WIP label) Dave From nobody Tue Jan 12 10:13:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78BD1A036D for ; Tue, 12 Jan 2016 10:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 KRTNG0rZquvS for ; Tue, 12 Jan 2016 10:13:42 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 01B281A0373 for ; Tue, 12 Jan 2016 10:13:42 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id a85so382851233ykb.1 for ; Tue, 12 Jan 2016 10:13:41 -0800 (PST) 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:content-type; bh=iBvNM5iPKTYaOr3Jv624t9YCN6l1WlUzZ+2+sk0KXDY=; b=nARoJ2uA4ITZYQXQgbAI+OaiL3mj4CLBdn6uFuVStVJe+S23kO6U/oGUPR//Ecjlzi fc8fbDkQlnDoaFIp1EGwZCaWgtS5lPMoIynZs9jWDC61GByYfDcx4XiktCjseUZrm9nU J0wLb6oW/IeEaQ6K2ZwhDMnmk46+rvKSHqSWrXUItHDfymMx5+pfC4aDVHL3Jno+6l2w QCZ+wQcBNdaN7iEx2fPEXEdGsgzGTRF/EpQr+/l+190xh9aRqUKwh45/A4KqaDKCHRy3 /XwJKAJ2sofb3X7mKS7Xiyun03H9yTcPPYLogXFQvw6TChZ0hnLkNbavtUF+YU6u4GwS YczA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iBvNM5iPKTYaOr3Jv624t9YCN6l1WlUzZ+2+sk0KXDY=; b=BwT4ne50ZJZc7szpaVUXsLjjLHpQf+qqfGpBrleE3SFTiE5VTo64B/ZBwFooMz8xnQ 0T5PXmx+h48bd7F0nAdLZB3uEQ2vnTYk6R74DnGjo/dViwqgC3sgN0ULNw9fECKiui6s Wy12PBU68QhHLcgrhaik8rULr2kjgZc1+sCeG7PO0B6M9kD9aALjv1vBgxdoGe8lpFuh uvHSnWZUCQ+xIAaFYiKnlE0jZrjC4hnHBjf9vwJHCI+IamkGd1TFUQnLnRD5W/0kGVE2 JSbx30hDPh2I+R2B80dkmO43MmzJmXYwvZQDpsBovbmz+mqOJWgJ4alCl/xuliwDlrP7 mFIw== X-Gm-Message-State: ALoCoQmvPTdS4Od1DFg59gX32Cx5x9OhlHs2QTAUhPOhddYtB/WRtTdxS4a3kf8/Xf8Cj5ClFZm3G4wfO+pCZZwcbnNYjlHBBg== X-Received: by 10.129.79.87 with SMTP id d84mr96437703ywb.115.1452622421291; Tue, 12 Jan 2016 10:13:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 10:13:01 -0800 (PST) In-Reply-To: <201601121306.32859.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121306.32859.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 12 Jan 2016 10:13:01 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114dc3606a25e1052927032e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:13:43 -0000 --001a114dc3606a25e1052927032e Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett wrote: > On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote: > > On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote: > > > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > > > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > > > > Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. > > Still no cipher suite allocated, but there is an active draft. > > I have a short WIP PR for integrating these suites into the TLS 1.3 draft > sitting on GitHub, by the way. > > https://github.com/tlswg/tls13-spec/pull/381 > > Unless I'm misunderstanding the procedure here, though, that draft needs > to progress to WG adoption before we're ready for it here. (hence the WIP > label) This matches my understanding of the policy. -Ekr > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dc3606a25e1052927032e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen <pzbowen@gmail.com> wrote:
> > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA25= 6 cipher suite allocated
> > (BoringSSL has an implementation using cipher suite 0xca,0xfe) >
> Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. > Still no cipher suite allocated, but there is an active draft.

I have a short WIP PR for integrating these suites into the TLS 1.3 = draft sitting on GitHub, by the way.

https://github.com/tlswg/tls13-spec/pull/381

Unless I'm misunderstanding the procedure here, though, that draft need= s to progress to WG adoption before we're ready for it here. (hence the= WIP label)

This matches my understanding o= f the policy.

-Ekr
=C2=A0


Dave

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

--001a114dc3606a25e1052927032e-- From nobody Tue Jan 12 10:23:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD71A1A96 for ; Tue, 12 Jan 2016 10:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4jkVV0DDnPA for ; Tue, 12 Jan 2016 10:23:09 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6641A1A6D for ; Tue, 12 Jan 2016 10:23:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DF7FE5D6; Tue, 12 Jan 2016 20:23:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id KD6rO9Ua94Ej; Tue, 12 Jan 2016 20:23:06 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9606B287; Tue, 12 Jan 2016 20:23:06 +0200 (EET) Date: Tue, 12 Jan 2016 20:23:03 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160112182303.GA16894@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <20160112171706.GA16749@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:23:11 -0000 On Tue, Jan 12, 2016 at 09:41:26AM -0800, Eric Rescorla wrote: > On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara > wrote: > > > > DHE has serious problems. While the present TLS 1.3 way of doing DHE > > isn't totally horrible, advertise DHE and you can get downnegotiation to > > TLS 1.2 DHE, and now you are screwed. > > > > Nit: this shouldn't be possible with the anti-downgrade mechanism that was > introduced > in draft-11 because the server's signature will cover the random value. If > you area > aware of an issue here, I would appreciate more information. Won't help here, since the server just doesn't support TLS 1.3. The issue isn't that TLS 1.2 was negotiated, it is that the client is now faced with old-style DHE. -Ilari From nobody Tue Jan 12 10:25:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DB31A1B28 for ; Tue, 12 Jan 2016 10:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 iW2qgGmJE52l for ; Tue, 12 Jan 2016 10:25:23 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342E31A1A45 for ; Tue, 12 Jan 2016 10:25:23 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id q21so392674110iod.0 for ; Tue, 12 Jan 2016 10:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=uzmAhhsPIn7HY8KbJjVoC0n5nwTjw4iB/unxCoRPv6k=; b=RLWGFpTqvGkePKshwnlZc8RCRLLpylcbnYmXWWGVLyw5zrCynPLlWwsh8ZhkdU1kbZ qW7r/xd4ieoNSHa5u6oW2nnRDxCZlbKWa+RqZo266JfkjvaudHyzYcdJZE8QG7gV+x2m KqD6xv5U0NFbQOhgQA++9OsFlY4pPgnHYf1co= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=uzmAhhsPIn7HY8KbJjVoC0n5nwTjw4iB/unxCoRPv6k=; b=B8sY62zEewdTtAA1JlklNW3lEW5q/6I9xig7bXMr+jrqC+3+wnRRsJObW9kk8iVF83 wiAymBpS76Yr38P/JZDwhtp4jtFq2nwWRGPMF0Z7kxLsMOJHli/Yf3nll9puinVszyId qWvpLxvl+jeuc20gVJVqmuFuFsDPgu2wGDtXp2SoPtmDVB3TbpK8TkR6uRllUUVqlu+A TITy9lnVcQfXH+uGgNr7e1+CQ5YjPxrVFnOaL6IfTcc40NYhu49cmyXyJftLUU1RgMmJ BF4ez1msDVYJ8QixFW5mstxJ4uFlkelusDZXop0/NgimGy1TZ4Pv05SV3LlyTN9LfH18 DgGg== X-Gm-Message-State: ALoCoQl9Hm6yI4pfgV3/dgZe+noT/cPeBYNiBdK868TEiCxSRi5P4qXke8z+w93PDAs2jmBu/fC0uwZ6ANNalbUk/8uVKb/GothHot/tDqj3jFsLqrHtm2E= X-Received: by 10.107.10.65 with SMTP id u62mr119787408ioi.120.1452623122525; Tue, 12 Jan 2016 10:25:22 -0800 (PST) MIME-Version: 1.0 References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Tue, 12 Jan 2016 18:25:12 +0000 Message-ID: To: Peter Bowen , Dave Garrett Content-Type: multipart/alternative; boundary=001a113ecd443654150529272d51 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:25:24 -0000 --001a113ecd443654150529272d51 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote: > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > 0xca,0xfe has since been removed as nothing was using it. I'm not aware of anything that ever shipped with it enabled. https://boringssl.googlesource.com/boringssl/+/1feb42a2fbbd8c1a1ed945edb5836d69f7241cda David > - DH parameters -- the alternative would be using FFDH named groups > (draft-ietf-tls-negotiated-ff-dhe-10), right? > > This would only leave "Get rid of the IPsec cargo-cult MAC truncation", > right? > > Thanks, > Peter > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113ecd443654150529272d51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 12= , 2016 at 12:27 PM Peter Bowen <pzb= owen@gmail.com> wrote:
The gaps seem to be:
- No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
(BoringSSL has an implementation using cipher suite 0xca,0xfe)

0xca,0xfe has since been removed as nothing was usi= ng it. I'm not aware of anything that ever shipped with it enabled.

David
=C2=A0
- DH parameters -- the alternative would be using FFDH named groups
(draft-ietf-tls-negotiated-ff-dhe-10), right?

This would only leave "Get rid of the IPsec cargo-cult MAC truncation&= quot;, right?

Thanks,
Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113ecd443654150529272d51-- From nobody Tue Jan 12 11:26:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821F1A8738 for ; Tue, 12 Jan 2016 11:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 RHYRXmWQ6KVe for ; Tue, 12 Jan 2016 11:26:32 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 0CF091A8737 for ; Tue, 12 Jan 2016 11:26:31 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0CJQIAT009221 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Jan 2016 20:26:19 +0100 Date: Tue, 12 Jan 2016 20:26:11 +0100 From: Simon Josefsson To: Joe Salowey Message-ID: <20160112202611.187f8263@latte.josefsson.org> In-Reply-To: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/3prkEI/C6Gc+IQCqGdFk+vL"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:26:35 -0000 --Sig_/3prkEI/C6Gc+IQCqGdFk+vL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The same concern still applies: what does it mean to allocate code point for the 4492bis-05 description? The document currently says to reject invalid ECDH keys, but I believe we want to remove that text. We could ask Yoav to issue a 4492bis-06 quickly that fix this issue, and then proceed with early code point allocation. Further, I believe allocating code points for Ed25519/Ed448 is premature since 1) the CFRG draft on Ed448 is not updated, and 2) 4492bis-05 does not contain sufficient detail to implement EdDSA authentication in TLS. See draft-josefsson-tls-eddsa2-02 for some discussion to make EdDSA work in TLS, as it relates to PKIX handling as well. To be clear: I support allocating a code point for X25519 as described in 4492bis with the relaxed public key check. /Simon > Whoops, thanks for the correction. It should be the code point > assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448, > Ed25519 and Ed448.=20 >=20 > Thanks, >=20 > Joe >=20 >=20 >=20 >=20 >=20 > On 1/12/16, 6:24 AM, "Simon Josefsson" wrote: >=20 > >Adam Langley writes: > > > >> Curve25519, as the name suggests, operates on 255-bit numbers. When > >> encoded as bytes, there's obviously a 256th bit that needs to be > >> specified. > >> > >> Curve25519 implementations didn't set the bit but did used to vary > >> on how they parsed it. Some would take a 256-bit number and reduce > >> it while others would ignore the bit completely. > >> > >> However, I believe that implementations have converged on ignoring > >> it. That behaviour is specified in draft-irtf-cfrg-curves and > >> tested via the test vectors. > >> > >> Currently > >> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > >> says that implementations SHOULD reject inputs with the high-bit > >> set. I think that should be dropped. The X25519 function is > >> specified in terms of bytes in draft-irtf-cfrg-curves and I think > >> the TLS spec should just use that draft. > > > >I agree. > > > >/Simon --Sig_/3prkEI/C6Gc+IQCqGdFk+vL Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWlVNTAAoJEIYLf7sy+BGdV2IH/Rh64p/wopTgGqIvYo+xmJDi 9xu/8MYTAzTjhvnZE19i2ROV8n6M1ETTpJAv5z2z3qe7aMMMk1o/fGjbWVf5ZL+v +h/4AkDl/FQHVp7jwzn4dR5t3hELBze5GKNp+V6sXvVB0MUpmLzN+9RfYDr9IxSu TNcPepWZB9IDgkdd5/+ozwf8CjNRqC5qp/S3Ediq8kx3qq45XuJ/sq0qIDiqK7H4 Hj6Bf9Jld+l0icjzsslYtcRHG1Gn9LfaRaVVvEHAMJhAsKICdUGZLHaXcVlf8PIW egrUhvNBCmhJ9vtNlnZlA1vhLfl7TlUzMXc4TevON3+gRrrMr60akajn95pK+FM= =uzBi -----END PGP SIGNATURE----- --Sig_/3prkEI/C6Gc+IQCqGdFk+vL-- From nobody Tue Jan 12 11:27:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2821A8742 for ; Tue, 12 Jan 2016 11:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 FGA81_fRme8f for ; Tue, 12 Jan 2016 11:27:03 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 168031A8735 for ; Tue, 12 Jan 2016 11:27:03 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id t15so128465632igr.0 for ; Tue, 12 Jan 2016 11:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Teffki3v+RnVSS7lLijnoW0ztU5yxnI71fvrdqMnkHk=; b=gUqO/XhqBZjyP0C4AlYV/rhc+kBbM7I7d0RsI1rxkwCUSwgdhUOvSSHFJU8awCd5Z0 rKx+A2Tac7jZvpcn2a5ANtw2SiXl9mMJmghgqJwM906IdjDE8G44sHWvorIEYuUT/UIa pd/Y3RsUun0vVhCr54CRI6Ywr+N76rZ0ck8zggqI4RmgcozuoGO5fsDA2ACirfpUs6Y9 5eq8lWhFv4KkeW45sEiyWqgQZS/Oikx7DdXjqsGXHVpfGWbLsaTyVEs3mCqJxQDJhn9x Oxkvahj3PnpXEptyXW5Q6MN5N3YjSnLXADfZaRl5YMNDNVxPSeobbf3qaP/OiRwj0ZIR t5/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Teffki3v+RnVSS7lLijnoW0ztU5yxnI71fvrdqMnkHk=; b=NBhOAhZJrciWllf8f/uju1+j3CWdydtRnyyMLaXLxAcgHb0sLzM8DQf7h3ImEvCzXs ++o1H/nyZ3QNOX+Y01GGQkYhrxe7YFebme0j7rQX29Q4nD7N+ayTTr3O39MFcHz6ugFx Ul81X+KsQq99b1S5ubQbPYEpj094qI/G7xXZeYoVI4KTjdOSaq8fIARyQ83lyuX0b+a6 5SUBl6zNaUmekpvUW71IA7MCVXbXJuqofzGYo9yndsVZzsh9glcTzUkjnc4DjsKrJHF/ J4PdwpToKYWvumVnDWEY+ftYJvcjNvWHUN1Fh0jnEWeVcEU9if0juKWnxXo3DikDx+50 K1RQ== X-Gm-Message-State: ALoCoQlK6ptuqvjlaE1YiXJsNsEUEvhRNRZsD4oSS33ijm5BWsz14RUPpWgXoEpCUE6YahqnAyT/Y7vwTOJ3J4UGE46m915zXvS+kz+umhv2yXs7tsLMMhA= MIME-Version: 1.0 X-Received: by 10.50.85.107 with SMTP id g11mr7087300igz.4.1452626822366; Tue, 12 Jan 2016 11:27:02 -0800 (PST) Received: by 10.107.141.12 with HTTP; Tue, 12 Jan 2016 11:27:02 -0800 (PST) In-Reply-To: <201601121202.26624.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> Date: Tue, 12 Jan 2016 11:27:02 -0800 Message-ID: From: Bill Cox To: Dave Garrett Content-Type: multipart/alternative; boundary=089e0149bb02bd51e0052928099a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:27:05 -0000 --089e0149bb02bd51e0052928099a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote: > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > I'll be the bearer of bad news and tell you that your proposal has come up > in multiple forms. I suggested a similar thing a while back and far before > me others have as well. The chairs have, however, long declared consensus > that we want to focus on a single new version not leaving out other more > complex changes, namely latency improvements. The primary argument is that > TLS version adoption rates are horrible and we would be far better suited > to one major upgrade rather than incremental changes that would likely > inhibit adoption of the more complex changes that we also need. (just a > quick summary from my view; someone else can chime in here if they need to) > > I can't dispute this position, though personally I think it's not the best > move. That said, if we were going to do a more incremental TLS version, > doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up > with would have been the way to go. That ship has sailed, and we're now > well into TLS 1.3 development, so I guess I'm now on board with working to > finalize the work that we're already doing (frankly, with a rename to TLS > 2.0 being a good idea). If you can somehow drum up consensus to overturn > the previous consensus, more power to you, but I think that's not likely to > be the best route anymore. > I'll just second what David said here. 0-RTT mode is here to stay, and I don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is a huge upgrade for users. The trick is doing this securely... My opinion counts little here, and TLS 1.3 is already nearly completely defined, so I think it is too late for this discussion. However, if it were not... A clean-slate TLS 2.0 which reuses as little as possible, and simplifies life as much as possible, would have been preferable, IMO. I look at the QUIC crypto code and then go back to the TLS/SSL code, and there is a night and day difference in complexity. I think it is going to be painful for some of us to watch the simple, clean QUIC crypto code move to the archives and get replaced with TLS 1.3, which is surely going to be a substantial bolt-on of code to the existing TLS 1.2 code base. It takes a super-genius just to see all the potential pitfalls in the TLS 1.2 code as it is. I think it will be even harder to analyze after the TLS 1.3 bolt-on. Fortunately, we seem to have a large number of super-geniuses working in TLS, much of the present company on this thread included :) However, if I personally were making changes to the code, it would be maybe 4X faster to do it in QUIC crypto, and 4X more likely that I would not introduce a critical bug in the process. I think it is natural for many members of this email list to discount this complexity issue in TLS 1.2/1.3, since many of the most brilliant programmers see the existing code as not all that complex. For regular mortal programmers out there like me, we would very much appreciate a clean-slate effort with minimal complexity, and there are a lot of lessons you folks have learned over the years that could be included. Maybe next time, in TLS 1.4? :-p Bill --089e0149bb02bd51e0052928099a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarrett@gmail.com= > wrote:
On Tu= esday, January 12, 2016 09:03:53 am Peter Gutmann wrote:

I'll be the bearer of bad news and tell you that your proposal has come= up in multiple forms. I suggested a similar thing a while back and far bef= ore me others have as well. The chairs have, however, long declared consens= us that we want to focus on a single new version not leaving out other more= complex changes, namely latency improvements. The primary argument is that= TLS version adoption rates are horrible and we would be far better suited = to one major upgrade rather than incremental changes that would likely inhi= bit adoption of the more complex changes that we also need. (just a quick s= ummary from my view; someone else can chime in here if they need to)

I can't dispute this position, though personally I think it's not t= he best move. That said, if we were going to do a more incremental TLS vers= ion, doing it along side HTTP/2 to avoid the messy TLS restrictions it ende= d up with would have been the way to go. That ship has sailed, and we'r= e now well into TLS 1.3 development, so I guess I'm now on board with w= orking to finalize the work that we're already doing (frankly, with a r= ename to TLS 2.0 being a good idea). If you can somehow drum up consensus t= o overturn the previous consensus, more power to you, but I think that'= s not likely to be the best route anymore.

<= div>I'll just second what David said here. =C2=A00-RTT mode is here to = stay, and I don't see a simple upgrade path from TLS 1.2.=C2=A0 Speed m= atters, and 0-RTT is a huge upgrade for users.=C2=A0 The trick is doing thi= s securely...

My opinion counts little here, and T= LS 1.3 is already nearly completely defined, so I think it is too late for = this discussion.=C2=A0 However, if it were not...

= A clean-slate TLS 2.0 which reuses as little as possible, and simplifies li= fe as much as possible, would have been preferable, IMO.=C2=A0 I look at th= e QUIC crypto code and then go back to the TLS/SSL code, and there is a nig= ht and day difference in complexity.=C2=A0 I think it is going to be painfu= l for some of us to watch the simple, clean QUIC crypto code move to the ar= chives and get replaced with TLS 1.3, which is surely going to be a substan= tial bolt-on of code to the existing TLS 1.2 code base.=C2=A0 It takes a su= per-genius just to see all the potential pitfalls in the TLS 1.2 code as it= is.=C2=A0 I think it will be even harder to analyze after the TLS 1.3 bolt= -on.=C2=A0 Fortunately, we seem to have a large number of super-geniuses wo= rking in TLS, much of the present company on this thread included :) =C2=A0= However, if I personally were making changes to the code, it would be maybe= 4X faster to do it in QUIC crypto, and 4X more likely that I would not int= roduce a critical bug in the process.

I think = it is natural for many members of this email list to discount this complexi= ty issue in TLS 1.2/1.3, since many of the most brilliant programmers see t= he existing code as not all that complex.=C2=A0 For regular mortal programm= ers out there like me, we would very much appreciate a clean-slate effort w= ith minimal complexity, and there are a lot of lessons you folks have learn= ed over the years that could be included.

Maybe ne= xt time, in TLS 1.4? :-p

Bill
--089e0149bb02bd51e0052928099a-- From nobody Tue Jan 12 11:39:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BF01A8755 for ; Tue, 12 Jan 2016 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJnas17s-8_Q for ; Tue, 12 Jan 2016 11:39:18 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 6A4D21A873A for ; Tue, 12 Jan 2016 11:39:18 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id 6so358765494qgy.1 for ; Tue, 12 Jan 2016 11:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=qwFQ5ehNFlwmpnP61vrz4Qerkw2iF1VN+NKec5nA5xw=; b=t956smEj2pizml0brCOJKSSPX8G9UJ2hWFjo26b5Dql5T8jCLsXRD9+PnQvgPJvmUS yj3SigOez78VCaLimIYixkBvyUL/62j0HBJgmxgllE0fEw2dWqqc8/f2tTyLWWRK7rFU MkTljrwBQ2MAKtx+X8ivUUAyNPnqZ7/OFVgfXm0IkTXNgq6rzn+GPonSIFd7BioE5icP H3x8HrI7sN7AB6xGDRYl4V2SXCT6VHA4J7PiSchfcKk7npnfJvkSOObCfsTnHDFzVoVo PA1LrEiVM4BFVF5Yta3e8v74bGwArial4LTDxegViz+9SULSfij4f2XqK3k7TuvWhril b8HQ== X-Received: by 10.140.133.146 with SMTP id 140mr15172072qhf.99.1452627557569; Tue, 12 Jan 2016 11:39:17 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w75sm57431657qka.49.2016.01.12.11.39.16 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 11:39:16 -0800 (PST) From: Dave Garrett To: Bill Cox Date: Tue, 12 Jan 2016 14:39:15 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601121439.15891.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:39:20 -0000 On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett > wrote: > > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > > > I'll be the bearer of bad news and tell you that your proposal has come up > > in multiple forms. I suggested a similar thing a while back and far before > > me others have as well. The chairs have, however, long declared consensus > > that we want to focus on a single new version not leaving out other more > > complex changes, namely latency improvements. The primary argument is that > > TLS version adoption rates are horrible and we would be far better suited > > to one major upgrade rather than incremental changes that would likely > > inhibit adoption of the more complex changes that we also need. (just a > > quick summary from my view; someone else can chime in here if they need to) > > > > I can't dispute this position, though personally I think it's not the best > > move. That said, if we were going to do a more incremental TLS version, > > doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up > > with would have been the way to go. That ship has sailed, and we're now > > well into TLS 1.3 development, so I guess I'm now on board with working to > > finalize the work that we're already doing (frankly, with a rename to TLS > > 2.0 being a good idea). If you can somehow drum up consensus to overturn > > the previous consensus, more power to you, but I think that's not likely to > > be the best route anymore. > > I'll just second what David said here. 0-RTT mode is here to stay, and I > don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is > a huge upgrade for users. The trick is doing this securely... > > My opinion counts little here, and TLS 1.3 is already nearly completely > defined, so I think it is too late for this discussion. However, if it > were not... > > A clean-slate TLS 2.0 which reuses as little as possible, and simplifies > life as much as possible, would have been preferable, IMO. I look at the > QUIC crypto code and then go back to the TLS/SSL code, and there is a night > and day difference in complexity. I think it is going to be painful for > some of us to watch the simple, clean QUIC crypto code move to the archives > and get replaced with TLS 1.3, which is surely going to be a substantial > bolt-on of code to the existing TLS 1.2 code base. It takes a super-genius > just to see all the potential pitfalls in the TLS 1.2 code as it is. I > think it will be even harder to analyze after the TLS 1.3 bolt-on. > Fortunately, we seem to have a large number of super-geniuses working in > TLS, much of the present company on this thread included :) However, if I > personally were making changes to the code, it would be maybe 4X faster to > do it in QUIC crypto, and 4X more likely that I would not introduce a > critical bug in the process. > > I think it is natural for many members of this email list to discount this > complexity issue in TLS 1.2/1.3, since many of the most brilliant > programmers see the existing code as not all that complex. For regular > mortal programmers out there like me, we would very much appreciate a > clean-slate effort with minimal complexity, and there are a lot of lessons > you folks have learned over the years that could be included. > > Maybe next time, in TLS 1.4? :-p Personally, I hope this new version of TLS, save for possibly some minor update & extensions, is the final version. I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement. (the early documentation for QUIC was horrible, but the current work is vastly improved) As far as I'm concerned, TLS 1.3 is a transitional measure which should only be used in the medium-term by those who adopt new tech very slowly, and in the long-term phased out entirely. It is a very important transitional measure that needs to be done with as high a security and performance as possible, but a finite one nonetheless. (well, arguably, pretty much everything is, given a long enough timeframe ;) We have to get through the short-term to get to the long-term, though. Dave From nobody Tue Jan 12 12:04:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B91A8823 for ; Tue, 12 Jan 2016 12:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KybO7U7yJPpO for ; Tue, 12 Jan 2016 12:04:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EE31A8824 for ; Tue, 12 Jan 2016 12:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sXNHYJzwEsiBWk9bfytWlIdbEP4ihPbdnNQO0xQHA2o=; b=JxV6ptOyYqXmT8FnELj/S6wuJp3IHm83M2sinyWAGUOkYjSRFPivCwfjGKLdisDGejMHqA1491BOocSMt0Cz2D9bu6MQS62JQU2pxN7HDrVr9P5cJAvbHEh9lc6sKttcDQF5cWVtxuH/FLk2sc2TqZjDi0GU/Z9wsCcpzKn5Bt4= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 20:03:42 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 20:03:42 +0000 From: Andrei Popov To: Dave Garrett , Bill Cox Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzQAGPEwAAAUM0wAAAG06gAAAvcSA Date: Tue, 12 Jan 2016 20:03:42 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <201601121439.15891.davemgarrett@gmail.com> In-Reply-To: <201601121439.15891.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:O7nE5O1Nf8ttPPrhZBCMbBeJn+aAGMSxn9d5go/7jkhlWXdWPm75PwbyK7cZ7bpLwFOwtOXpbx0Y2ZDNaHgpSPsq/LwHlfQRLo7ZwKkvqhd8mTN58Y7fpMDC7t5eTOlbIeAHd7sXNKBw+o4Tc0Oq6g==; 24:PJ4Po+3guel67j0pA6wlGxuJwkFV1qcamX0ah04pl6hNhVRRa2guEjP5skoBSLBcf2ewCtpQkz+y4jkmgc0VhiMb1Tco13N82CojZ+V7lPM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-ms-office365-filtering-correlation-id: 56b37b35-1fd8-4ffe-8230-08d31b8b7869 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(377454003)(24454002)(189002)(8990500004)(50986999)(93886004)(189998001)(40100003)(81156007)(5004730100002)(19580395003)(2950100001)(4326007)(5001960100002)(19580405001)(97736004)(2906002)(5001770100001)(76576001)(102836003)(10090500001)(122556002)(11100500001)(101416001)(1096002)(6116002)(54356999)(15975445007)(106356001)(10400500002)(86362001)(99286002)(10290500002)(74316001)(86612001)(105586002)(87936001)(5005710100001)(76176999)(5002640100001)(5008740100001)(1220700001)(33656002)(77096005)(5003600100002)(76534003)(92566002)(2900100001)(561944003)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 20:03:42.1612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:04:06 -0000 > I hope that Google's efforts to get QUIC as-is specced out go quickly and= smoothly, and that it can be used as a basis to develop an official total = TCP/TLS replacement. If this were the path forward (and I doubt that it is), I would very much p= refer Peter Gutman's evolutionary TLS 1.3. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, January 12, 2016 11:39 AM To: Bill Cox Cc: tls@ietf.org Subject: Re: [TLS] Fixing TLS On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett > wrote: > > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > > > I'll be the bearer of bad news and tell you that your proposal has=20 > > come up in multiple forms. I suggested a similar thing a while back=20 > > and far before me others have as well. The chairs have, however,=20 > > long declared consensus that we want to focus on a single new=20 > > version not leaving out other more complex changes, namely latency=20 > > improvements. The primary argument is that TLS version adoption=20 > > rates are horrible and we would be far better suited to one major=20 > > upgrade rather than incremental changes that would likely inhibit=20 > > adoption of the more complex changes that we also need. (just a=20 > > quick summary from my view; someone else can chime in here if they=20 > > need to) > > > > I can't dispute this position, though personally I think it's not=20 > > the best move. That said, if we were going to do a more incremental=20 > > TLS version, doing it along side HTTP/2 to avoid the messy TLS=20 > > restrictions it ended up with would have been the way to go. That=20 > > ship has sailed, and we're now well into TLS 1.3 development, so I=20 > > guess I'm now on board with working to finalize the work that we're=20 > > already doing (frankly, with a rename to TLS > > 2.0 being a good idea). If you can somehow drum up consensus to=20 > > overturn the previous consensus, more power to you, but I think=20 > > that's not likely to be the best route anymore. >=20 > I'll just second what David said here. 0-RTT mode is here to stay,=20 > and I don't see a simple upgrade path from TLS 1.2. Speed matters,=20 > and 0-RTT is a huge upgrade for users. The trick is doing this securely.= .. >=20 > My opinion counts little here, and TLS 1.3 is already nearly=20 > completely defined, so I think it is too late for this discussion. =20 > However, if it were not... >=20 > A clean-slate TLS 2.0 which reuses as little as possible, and=20 > simplifies life as much as possible, would have been preferable, IMO. =20 > I look at the QUIC crypto code and then go back to the TLS/SSL code,=20 > and there is a night and day difference in complexity. I think it is=20 > going to be painful for some of us to watch the simple, clean QUIC=20 > crypto code move to the archives and get replaced with TLS 1.3, which=20 > is surely going to be a substantial bolt-on of code to the existing=20 > TLS 1.2 code base. It takes a super-genius just to see all the=20 > potential pitfalls in the TLS 1.2 code as it is. I think it will be even= harder to analyze after the TLS 1.3 bolt-on. > Fortunately, we seem to have a large number of super-geniuses working=20 > in TLS, much of the present company on this thread included :) =20 > However, if I personally were making changes to the code, it would be=20 > maybe 4X faster to do it in QUIC crypto, and 4X more likely that I=20 > would not introduce a critical bug in the process. >=20 > I think it is natural for many members of this email list to discount=20 > this complexity issue in TLS 1.2/1.3, since many of the most brilliant=20 > programmers see the existing code as not all that complex. For=20 > regular mortal programmers out there like me, we would very much=20 > appreciate a clean-slate effort with minimal complexity, and there are=20 > a lot of lessons you folks have learned over the years that could be incl= uded. >=20 > Maybe next time, in TLS 1.4? :-p Personally, I hope this new version of TLS, save for possibly some minor up= date & extensions, is the final version. I hope that Google's efforts to ge= t QUIC as-is specced out go quickly and smoothly, and that it can be used a= s a basis to develop an official total TCP/TLS replacement. (the early docu= mentation for QUIC was horrible, but the current work is vastly improved) A= s far as I'm concerned, TLS 1.3 is a transitional measure which should only= be used in the medium-term by those who adopt new tech very slowly, and in= the long-term phased out entirely. It is a very important transitional mea= sure that needs to be done with as high a security and performance as possi= ble, but a finite one nonetheless. (well, arguably, pretty much everything = is, given a long enough timeframe ;) We have to get through the short-term = to get to the long-term, though. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c882faa8317114da26f3e08d31b881439%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3DmMYoE%2bpBJpL6NKES01ZsFsN%2bwsf%2f8G7OwBhRkfWWDpI%3d From nobody Tue Jan 12 12:12:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37881A8836 for ; Tue, 12 Jan 2016 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 Hr9RAXd8Oxmz for ; Tue, 12 Jan 2016 12:12:40 -0800 (PST) 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 B78F91A8830 for ; Tue, 12 Jan 2016 12:12:40 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g73so200496879ioe.3 for ; Tue, 12 Jan 2016 12:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qm3rLeWEhgf4JJ3akCYxpC8A1d4oIsCJpoVQfBJp8gI=; b=D8ZJJJHVioB63J23l+/Brc5w3FbXsqxekDWAFazH2fU/q1FC+LG3e5svbklXQO7gya dMUztBTAOxIeP7WuRXLBPJgNbevEOo18ZWtqvzDfkC/1pbtltCaqMDVIxMaQpx/FLsbn fZ1mPS8l9b+MYZGiFCxYtYtaAIanbo2A/o1j48J9/y0Kn+nDMvIBniFDI5vprGagNgeZ ashkRrJwMqhg2MESCbQpkpM61anQDSfaBZR0zH97zzxsk2Lqc/8cfK3DkDAgLwfOUqDv ThYn8Qt/e7n0QiBBaWDCVNzwprT9Jy1jntkgsVy7dkQJVQUuW7T5Hg7SDTqp4Do44vW7 5ATw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qm3rLeWEhgf4JJ3akCYxpC8A1d4oIsCJpoVQfBJp8gI=; b=mOOpjf4LqhTpyAroIafr3D5GZQKbD+y5b/F7PVtckrMCE+1cbEkg+2UyuDNCixE7H5 mQgntqY3DGLbUNUzx4w42AQU4/xUVtPmq8eYDDEro1Xn5IxLCyBIEbAY1H9EDxULIWXx FNfn7q1TmLrJhrBRhBgrZMsjJ9NEdNYqbMlF0gj1SHPbHwpoZ8oKt+ZW6tB+D+nAomUj CarbbDrn4PLsyA61Uloc7lkYksTWVDTPJvv+OXBKNDS4luhTjrahqkHV75U7aYerXqfu 7G3x4RT+Jbwgr8EkYjWUZLdbIqbRsv9T6Xdz7iUOpf+YP8Jee2+2jZRykjEW9aUp2B2v YHIw== X-Gm-Message-State: ALoCoQmd9k9pocMLZE2oyyYHyX+wrcBN4FLj1SZiJcb8Vv7TsSsOwgmKGH+w2+GfvdtprYDc/ygwse5EhU0hb1qmorwtVK0/DEZji4VRIXrn3J8PKSFxDg0= MIME-Version: 1.0 X-Received: by 10.107.10.225 with SMTP id 94mr5084179iok.132.1452629559625; Tue, 12 Jan 2016 12:12:39 -0800 (PST) Received: by 10.107.141.12 with HTTP; Tue, 12 Jan 2016 12:12:39 -0800 (PST) In-Reply-To: <201601121439.15891.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <201601121439.15891.davemgarrett@gmail.com> Date: Tue, 12 Jan 2016 12:12:39 -0800 Message-ID: From: Bill Cox To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113f8cace4cdab052928ac23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:12:42 -0000 --001a113f8cace4cdab052928ac23 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett wrote: > On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > > Personally, I hope this new version of TLS, save for possibly some minor > update & extensions, is the final version. I hope that Google's efforts to > get QUIC as-is specced out go quickly and smoothly, and that it can be used > as a basis to develop an official total TCP/TLS replacement. (the early > documentation for QUIC was horrible, but the current work is vastly > improved) As far as I'm concerned, TLS 1.3 is a transitional measure which > should only be used in the medium-term by those who adopt new tech very > slowly, and in the long-term phased out entirely. It is a very important > transitional measure that needs to be done with as high a security and > performance as possible, but a finite one nonetheless. (well, arguably, > pretty much everything is, given a long enough timeframe ;) We have to get > through the short-term to get to the long-term, though. > > > Dave > I wish that were the plan (to upgrade QUIC crypto and eventually make that the new crypto platform). If I am not mistaken, QUICK crypto is going to be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the transport layer. So, maybe long-term you folks could do a clean-slate TLS 2.0? That would would be awesome, IMO. Bill --001a113f8cace4cdab052928ac23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:=

Personally, I hope this new version of TLS, save for possibly s= ome minor update & extensions, is the final version. I hope that Google= 's efforts to get QUIC as-is specced out go quickly and smoothly, and t= hat it can be used as a basis to develop an official total TCP/TLS replacem= ent. (the early documentation for QUIC was horrible, but the current work i= s vastly improved) As far as I'm concerned, TLS 1.3 is a transitional m= easure which should only be used in the medium-term by those who adopt new = tech very slowly, and in the long-term phased out entirely. It is a very im= portant transitional measure that needs to be done with as high a security = and performance as possible, but a finite one nonetheless. (well, arguably,= pretty much everything is, given a long enough timeframe ;) We have to get= through the short-term to get to the long-term, though.


Dave

I wish that were the= plan (to upgrade QUIC crypto and eventually make that the new crypto platf= orm).=C2=A0 If I am not mistaken, QUICK crypto is going to be archived, TLS= 1.3 will replace the crypto code, and QUIC will remain the transport layer= .=C2=A0 So, maybe long-term you folks could do a clean-slate TLS 2.0?=C2=A0= That would would be awesome, IMO.

Bill=C2=A0
--001a113f8cace4cdab052928ac23-- From nobody Tue Jan 12 12:14:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D891A8859 for ; Tue, 12 Jan 2016 12:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXIMVgWcYM-W for ; Tue, 12 Jan 2016 12:14:17 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 A136D1A885C for ; Tue, 12 Jan 2016 12:14:16 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so349286126qgf.3 for ; Tue, 12 Jan 2016 12:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ta3IXvYFdqjJso4q9Pk/i5B2QSn4m29x9J4okLSBac8=; b=1BcPU9IuzSdrGcsrYAEHIhY0IIAxHj53HnduCI6/oUondXK7eeW0XKoqqiggO2sCW6 VIHjwuJLsa1U2h6VfP7QnPCY4V2pB5Mpcz5SizBot7v3N+nF5VN22VjYB5DnHtopwLvW 5OHDQ6hfhBgFvl3h1lU8sxlppNRmsy65UUPT3vel/oFtbrXm5kZztJrTX1ubPzrU1ZMp SCgVHaXuoVZ5dQFZrpsMxOrUyBh3AUZ6Su5mxS8R4N4nyMPpQskF4KPVkvHuMFqYo5p5 oyvkEFNq6qPSWjMVkv9P6CvXcAzVa5e5o7T18N6RVuEj5EZwAmS+BrZiaCX6uO3GGHI6 JYAA== X-Received: by 10.140.96.8 with SMTP id j8mr168197610qge.93.1452629655894; Tue, 12 Jan 2016 12:14:15 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id f132sm38986458qhe.6.2016.01.12.12.14.15 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 12:14:15 -0800 (PST) From: Dave Garrett To: Andrei Popov Date: Tue, 12 Jan 2016 15:14:13 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121439.15891.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201601121514.14360.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:14:19 -0000 On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote: > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote: > > I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement. > > If this were the path forward (and I doubt that it is), I would very much prefer Peter Gutman's evolutionary TLS 1.3. I was just chatting a bit off-list, and apparently I wasn't aware of QUIC's latest plans, so it's not as clear as I previously said. Unfortunately, it seems that they have yet to actually write anything down (a too frequent pattern with QUIC), so I can't really comment on what I'd like to see happen in this realm anymore. In any case, ~whatever~ comes after TLS 1.3 will hopefully have some major changes. I have no idea what that will be, but TLS 1.3 comes first. That's a discussion for a future time. Dave From nobody Tue Jan 12 12:18:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61B1A8863 for ; Tue, 12 Jan 2016 12:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwqh1ZhJSNzT for ; Tue, 12 Jan 2016 12:18:24 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 589D51A885F for ; Tue, 12 Jan 2016 12:18:24 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id z14so152453333igp.0 for ; Tue, 12 Jan 2016 12:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QTgO4AffR94C3kEkjybHcc7XnRXCBYhIEktWisso02A=; b=kFc+wDt8tlOK1CKSix3nD1mox6YBY9YRUPoZjgkZBsUSeE6YdsFrJBjicnkZEs9Rzy hNqM2S2BK+rriqL2qsWEM1yu2kz7SNTu0DrWX7edBpR4zg/Ef+X50dsmFeF27lpLN3wY n7W3c2mbO2cjktaNdAwmEitWd+32pfGYy3TmPL2/k2mPCkrcdfTjeE/hTd9qSYnQ2dat VNBIZv23DA+lCyN47mGKQgz/6M59U2/Odvvgu3glP5AJb10GceUOTIkJ7yvqse6sWNVf ArQwzIGcMq3A6QjfZT4BWnAPkbqUtEuWBn/N9LBOvWuMYYZUFEkbiBd1TNAhkEoYZ3br Dw9A== X-Received: by 10.50.17.39 with SMTP id l7mr19459480igd.18.1452629903821; Tue, 12 Jan 2016 12:18:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.37.17 with HTTP; Tue, 12 Jan 2016 12:18:04 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <201601121439.15891.davemgarrett@gmail.com> From: Tony Arcieri Date: Tue, 12 Jan 2016 12:18:04 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=089e01184e626852fc052928c10c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:18:25 -0000 --089e01184e626852fc052928c10c Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > I wish that were the plan (to upgrade QUIC crypto and eventually make that > the new crypto platform). If I am not mistaken, QUICK crypto is going to > be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the > transport layer. So, maybe long-term you folks could do a clean-slate TLS > 2.0? That would would be awesome, IMO. > Have you looked at OPTLS? It provides a clean "core" for TLS, and also supports Diffie-Hellman authentication ala Trevor Perrin's protocol Noise. If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for "TLS 2.0" -- Tony Arcieri --089e01184e626852fc052928c10c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 12:12 PM, Bill Cox <waywardgeek@google.com>= ; wrote:
I wish that were the pla= n (to upgrade QUIC crypto and eventually make that the new crypto platform)= .=C2=A0 If I am not mistaken, QUICK crypto is going to be archived, TLS 1.3= will replace the crypto code, and QUIC will remain the transport layer.=C2= =A0 So, maybe long-term you folks could do a clean-slate TLS 2.0?=C2=A0 Tha= t would would be awesome, IMO.
Have you looked at OPTLS? It provides a clean "core" = for TLS, and also supports Diffie-Hellman authentication ala Trevor Perrin&= #39;s protocol Noise.=C2=A0

If TLS 1.3 can s= hed the cruft, OPTLS seems like a nice direction to go for "TLS 2.0&qu= ot;

--
Tony Arcieri<= br>
--089e01184e626852fc052928c10c-- From nobody Tue Jan 12 12:18:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C061A8863 for ; Tue, 12 Jan 2016 12:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 fUs8uh_F0bQr for ; Tue, 12 Jan 2016 12:18:51 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 7F7A51A885F for ; Tue, 12 Jan 2016 12:18:51 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id a85so386941500ykb.1 for ; Tue, 12 Jan 2016 12:18:51 -0800 (PST) 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:content-type; bh=nqy/9cDnRexl2MOMN9JispGoPGLRu4MyPkpcnh8g8PY=; b=LiVego6fnxFukcOKbGPV1whBKFG8cL3uiAd6p5n6TqjBm8xPWotJRrcIZqmrAw4a1P T4/KIQsiUELOB3wpgZN6xjJKXdQT1Y/AynjKzSn4pDk34QLNez1JlwIuPFhMlyi3u4um vqIgyEZFgegSj6PrvcPcEr2bqA0AUUxZYtiKQgLIpGSBCEyjOLzwk8EiEdYmpAy3MKew N4rxhMyf33/cDs06Cdqcb6zuOv1sI/tDMGDs0xXBvHTCVYSYvpJ7sb53Uo4K9Mx+stRk xSlhmNBCdxdV+yk36szuHvREHhoXCjqxbsaC0Y/hJFsAjpKk5Fmo0PaZfJwCts5Qo3u/ h7Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nqy/9cDnRexl2MOMN9JispGoPGLRu4MyPkpcnh8g8PY=; b=XoSK1y5vP6rS0CmCdUx1a3ZBD7jWRCNwW3VF/ylxQCecVMqFFQEFcBDyhWuUVNXzTa S3/XHgNtBCD3ilKUVLAdr6uu1ltLYZvrt3Cn0i5vZ9/fimjogvEpg737Z/wlo6TMfsfS OL3VBRAyedBMwCrah6sEfKCLIFqGjLvWP73SkMqnJkALmp2fJ6p446RV9kHIgCgv55Qm TCeAuGSn0Ff+vN8c1myWhrjTep6838aMvHlVck1nVF/M/zbqytX/+ZopJjmLYJyumzJm z7jHv4Xx/HdPSMgcQDhCBjGw9lNJvAh8p30E1C6Iffbo228aAzihT7yCTdA6VmLc9Kt2 LjqQ== X-Gm-Message-State: ALoCoQkTtNTE7KIjVG9VYqrImSRDdP6KfGqzDZCGsxNsxqyJ34tJQdkDi+r4p657ISir1IdmVmum+8jrEZpjF7BVuBUZ1pkS9A== X-Received: by 10.13.218.198 with SMTP id c189mr107401853ywe.165.1452629930808; Tue, 12 Jan 2016 12:18:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 12:18:11 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <201601121439.15891.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 12 Jan 2016 12:18:11 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c08192a0444a0052928c30a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:18:52 -0000 --94eb2c08192a0444a0052928c30a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett > wrote: > >> On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: >> >> Personally, I hope this new version of TLS, save for possibly some minor >> update & extensions, is the final version. I hope that Google's efforts to >> get QUIC as-is specced out go quickly and smoothly, and that it can be used >> as a basis to develop an official total TCP/TLS replacement. (the early >> documentation for QUIC was horrible, but the current work is vastly >> improved) As far as I'm concerned, TLS 1.3 is a transitional measure which >> should only be used in the medium-term by those who adopt new tech very >> slowly, and in the long-term phased out entirely. It is a very important >> transitional measure that needs to be done with as high a security and >> performance as possible, but a finite one nonetheless. (well, arguably, >> pretty much everything is, given a long enough timeframe ;) We have to get >> through the short-term to get to the long-term, though. >> >> >> Dave >> > > I wish that were the plan (to upgrade QUIC crypto and eventually make that > the new crypto platform). If I am not mistaken, QUICK crypto is going to > be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the > transport layer. > This is my understanding as well, based both onconversations with the QUIC folks, and Adam and Jana's public presentations. A number of us (MT, I, Jana, Ian, AGL, Christian) have already started some initial conversations at how to do that. With that said, I don't think there's a plausible story in which QUIC becomes the only transport protocol in the world any time soon, so I don't think standalone TLS 1.3 is going away. -Ekr --94eb2c08192a0444a0052928c30a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox <waywardgeek@google.co= m> wrote:
=
On T= ue, Jan 12, 2016 at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
Personally, I hope this new version of = TLS, save for possibly some minor update & extensions, is the final ver= sion. I hope that Google's efforts to get QUIC as-is specced out go qui= ckly and smoothly, and that it can be used as a basis to develop an officia= l total TCP/TLS replacement. (the early documentation for QUIC was horrible= , but the current work is vastly improved) As far as I'm concerned, TLS= 1.3 is a transitional measure which should only be used in the medium-term= by those who adopt new tech very slowly, and in the long-term phased out e= ntirely. It is a very important transitional measure that needs to be done = with as high a security and performance as possible, but a finite one nonet= heless. (well, arguably, pretty much everything is, given a long enough tim= eframe ;) We have to get through the short-term to get to the long-term, th= ough.


Dave


--94eb2c08192a0444a0052928c30a-- From nobody Tue Jan 12 12:20:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A771A8864 for ; Tue, 12 Jan 2016 12:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFpd6jYW8-vw for ; Tue, 12 Jan 2016 12:20:31 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 B93331A8861 for ; Tue, 12 Jan 2016 12:20:31 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id A3E20A8A16C4; Tue, 12 Jan 2016 20:20:29 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 7C1751FE05D3; Tue, 12 Jan 2016 21:20:29 +0100 (CET) Date: Tue, 12 Jan 2016 21:20:29 +0100 From: Kurt Roeckx To: Bill Cox Message-ID: <20160112202029.GA8903@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:20:33 -0000 On Tue, Jan 12, 2016 at 11:27:02AM -0800, Bill Cox wrote: > > I'll just second what David said here. 0-RTT mode is here to stay, and I > don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is > a huge upgrade for users. The trick is doing this securely... And I think because it's seems non-obvious how to get that correct implementations may delay implementing that part. Kurt From nobody Tue Jan 12 12:21:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B781A886E for ; Tue, 12 Jan 2016 12:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO_RHy8GmyYQ for ; Tue, 12 Jan 2016 12:21:27 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938AB1A887C for ; Tue, 12 Jan 2016 12:21:27 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id u188so271215685wmu.1 for ; Tue, 12 Jan 2016 12:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=LwiW77vZbEsiT4mUs+B0mJua9OHjGKbQhBBQsuU/hB0=; b=Y4D85UtfKhN6av4tieAlW61HR8xQz6zozHq8/od7DodDL06Nuy5aN18N3PDcneXrW4 HL2g2uD0lpYm9JOFNthUmHQ94HbImHCz+Wj5iBZPLKzjgrnwPKm3qDYYopG3H49UgjNt eKYRP3NKJWGlgIfSPzWLi0hFVnCwM9T4edpALD6eem4m0YLn7Fj/UVx43MmZgxQMHYW0 I4ci2hQ6HihP2P0ThYZXmWrY0Zv5gFBym6Z2/dRYPWP7ABM/kW86Yo757qLvxue9yvyd g52MEf+vH8D3D69f/TmpIkU3xegm9H0JeyIkj9wEUKyPryDQysaeCbpX984eUAbzMp1M nflQ== X-Received: by 10.194.205.103 with SMTP id lf7mr139703659wjc.147.1452630086150; Tue, 12 Jan 2016 12:21:26 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id u191sm16517811wmd.4.2016.01.12.12.21.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 12:21:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3145C0EC-89E3-4FA3-ABFB-733AC045F894"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <20160112202611.187f8263@latte.josefsson.org> Date: Tue, 12 Jan 2016 22:21:21 +0200 Message-Id: <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:21:29 -0000 --Apple-Mail=_3145C0EC-89E3-4FA3-ABFB-733AC045F894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jan 2016, at 9:26 PM, Simon Josefsson = wrote: >=20 > The same concern still applies: what does it mean to allocate code > point for the 4492bis-05 description? Allocating code points just means an implementation of draft-05 is = likely to interoperate just fine with an implementation of the final = RFC. Of course nothing is ever final until the RFC is out, so there=E2=80=99s = always a risk involved, but it is considered prudent to allocate numbers = when we=E2=80=99re reasonably certain of the calculations and = on-the-wire formats. Any debate about whether we should or should not = check certain inputs for certain conditions need not be a bar for = allocating numbers. Yoav --Apple-Mail=_3145C0EC-89E3-4FA3-ABFB-733AC045F894 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWlWBCAAoJECXR4BOacZZUAgAH/1584Te3JmD4qsMk8rpjGdF9 Uww6wt/ItH9eTJqkOGVzCvSF0DwepALXKcD9Eh5IA1L7553+TX4q5yRW26EgK4Ra iWI7bXFGZ8Ea77bGsFGioH9Gl+l2rfT4sypyCUto7VdvO4mXit9cNitI5l0zpPdx +NFCkO7SvMLIREBwl9weVyTHovNLWq2whMxtmYaKHGZbXapr++/skUnpcEtCHPIS u0Wk0YqQLwMpzr+h5lobqAxS5+G2XjX0gsARaighIE1opZlJ+kMJWZjxYLbiqLtw jNh8bDDmWL5vd6OyNr/6pDuv7cJs6lRBoHiI32Bk5sYgxg2DpBTA5b6ReyM56Nk= =joA6 -----END PGP SIGNATURE----- --Apple-Mail=_3145C0EC-89E3-4FA3-ABFB-733AC045F894-- From nobody Tue Jan 12 12:26:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89CB1A888E for ; Tue, 12 Jan 2016 12:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 sxEL1UMk4xzQ for ; Tue, 12 Jan 2016 12:26:16 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0AF1A8881 for ; Tue, 12 Jan 2016 12:26:16 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id v14so371466056ykd.3 for ; Tue, 12 Jan 2016 12:26:16 -0800 (PST) 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:content-type; bh=FKQuA1QeclTFleY/pENO8LcBhl3lynn+U5ybwGyli38=; b=FnjCexPts0qCXSNVEIpecgS34TlZ8j+btpp1GYYARrcSKSLk74PDS05L2nI2pp+ZyY lA/+WVWdthZ1MjBjBGb8UgL8jxAKcnwkzPOP6ugg9v/FKEfldrwFhlrv4OUKdd86POMQ 3h4hHpdezejtJU+7lvE/TkTWcNo9vnfJBV6+HRMp7gUEGSZFtW/gMAdSj4d2U0rDBSxB 7meFE6gczB5EE2O1SIvjl+Bd+iyw6YOXDlbXTPSWuXMPOi4e6FEuWsYoO5wtqK2ZW8cv JtPxp3Bs2LVxFtOfo+Si115kq3M3GvWcyeNqpsQnFz4HHnQ5qbgISX0zqb3alxliJO0S 92Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FKQuA1QeclTFleY/pENO8LcBhl3lynn+U5ybwGyli38=; b=SziGpRg8y/rVU6zntnLujUZ3CetCkgVV8E9mtx3YEOB0zuSVOEYBKu+d9OrPaq7TPW lQGnb64Y1muFlGZ+3qcinKriDwGxB+C7iw7Tou2QNehuf2DJkUJqLndng/A1XWSOznXM 3wsBI2IzzufsBKRDCyjZbuJIvnM9H/DPkUlbkviYbO9qj5zCWzneGiEFRGpxlKqI4eZ8 4IcI89Z72281qDgIsu+Oha+9C1FKdN2XUeticSxPU6VZrvxqE0PCynMYJkGE5kUZVsD9 GbBDN2eIXbeWcaEj9EasmbLDNWdWZ1gT3PoyBDNh/YGzI+HhWa14bbYiGf41lLq/a3IV 8Crw== X-Gm-Message-State: ALoCoQlFSGvPxX/QfZ6nZCb3Z+IHP2udrIdBr7nwXDP+5KS4qHAzxP5DymntSRPIMqnAYVfyfsufONSeX0dXM15I3DkwxLrvOw== X-Received: by 10.129.38.135 with SMTP id m129mr6361165ywm.155.1452630375816; Tue, 12 Jan 2016 12:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 12:25:36 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121202.26624.davemgarrett@gmail.com> <201601121439.15891.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 12 Jan 2016 12:25:36 -0800 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a1141618c8a99bf052928dd36 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:26:18 -0000 --001a1141618c8a99bf052928dd36 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri wrote: > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > >> I wish that were the plan (to upgrade QUIC crypto and eventually make >> that the new crypto platform). If I am not mistaken, QUICK crypto is going >> to be archived, TLS 1.3 will replace the crypto code, and QUIC will remain >> the transport layer. So, maybe long-term you folks could do a clean-slate >> TLS 2.0? That would would be awesome, IMO. >> > > Have you looked at OPTLS? It provides a clean "core" for TLS, and also > supports Diffie-Hellman authentication ala Trevor Perrin's protocol Noise. > > If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for > "TLS 2.0 > TLS 1.3 actually takes quite a bit of stuff from OPTLS (as you can see in the most recent OPTLS paper). To a great extent, the differences are due to explicit WG decisions, specifically the following two decisions; - Not to have an offline-signed DH credential - To require signing on every public-key-based handshake. IIRC there was pretty strong consensus for both these decisions, but if there is a lot of feeling to the contrary, presumably we could revisit these. -Ekr -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1141618c8a99bf052928dd36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 12:18 PM, Tony Arcieri <bascule@gmail.com> wrote:
On Tue, Jan 12, 20= 16 at 12:12 PM, Bill Cox <waywardgeek@google.com> wrote= :
I wish that we= re the plan (to upgrade QUIC crypto and eventually make that the new crypto= platform).=C2=A0 If I am not mistaken, QUICK crypto is going to be archive= d, TLS 1.3 will replace the crypto code, and QUIC will remain the transport= layer.=C2=A0 So, maybe long-term you folks could do a clean-slate TLS 2.0?= =C2=A0 That would would be awesome, IMO.

Have you looked at OPTLS? It provides a clean = "core" for TLS, and also supports Diffie-Hellman authentication a= la Trevor Perrin's protocol Noise.=C2=A0

If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for= "TLS 2.0

TLS 1.3 ac= tually takes quite a bit of stuff from OPTLS (as you can see in the most
recent OPTLS paper). To a great extent, the differences
a= re due to explicit WG decisions, specifically the following two decisions;<= /div>

- Not to have an offline-signed DH credential
- To require signing on every public-key-based handshake.
<= br>
IIRC there was pretty strong consensus for both these decisio= ns, but if there is
a lot of feeling to the contrary, presumably = we could revisit these.

-Ekr

--
Tony Arcieri<= br>

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


--001a1141618c8a99bf052928dd36-- From nobody Tue Jan 12 12:34:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DC1A889D for ; Tue, 12 Jan 2016 12:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHJdGY6JISx2 for ; Tue, 12 Jan 2016 12:34:02 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AFA1A8899 for ; Tue, 12 Jan 2016 12:34:02 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n135so260420896qka.2 for ; Tue, 12 Jan 2016 12:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Alhf1g3FGt9tYeVrdj+qCoPplKoGjACvO3MKOYuTeHo=; b=Fj9KHLIO/QdMK3d/zJHn5M6RYBd1ClprQYBucAj8WXuSt/pYMN71+0ZwJXrCdEb06q RLiCNp6ZeVLuswaQ4f6UdVzaFWC2LPprz6OZyMAqDIJ/6AAzofxxbpnLWAx6y88BfCnm JZtaUyWbes6wBqIo7+Qb3zi3y9FBYf61hma7YcvaGikWNta7CF8WjV5J6yxyeNMIUN08 yUqBjQ36I1HMlFvBb+hbBi30D3YGb+R6e0popbPlmO4ncI+YKP/1BZHyS/9Xvp+ieR2H sQeQ72aorUduFZwTOn+uW/5AFCZicjGzGUu6GSHMEDlVsmHbQf3FPdkZsqo4dUNcb5DX S+8A== X-Received: by 10.55.72.87 with SMTP id v84mr159877166qka.9.1452630841918; Tue, 12 Jan 2016 12:34:01 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id v64sm7246339qkv.24.2016.01.12.12.34.01 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 12:34:01 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Tue, 12 Jan 2016 15:33:59 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601121533.59799.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:34:04 -0000 On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote: > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote: > > I wish that were the plan (to upgrade QUIC crypto and eventually make that > > the new crypto platform). If I am not mistaken, QUICK crypto is going to > > be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the > > transport layer. > > This is my understanding as well, based both onconversations with the QUIC > folks, and Adam and Jana's public presentations. A number of us (MT, I, > Jana, Ian, AGL, Christian) have already started some initial conversations > at how to do that. I'm quite interested to hear what the plans are there. I'd appreciate it if, whenever there is a fleshed-out starting point, an outline could be posted to this list to keep us in the loop with what's going to be the initial design. Not necessarily for debate here, but just so we can have an idea of where things are going. > With that said, I don't think there's a plausible story in which QUIC becomes the only > transport protocol in the world any time soon, so I don't think standalone TLS 1.3 > is going away. Yes. Whatever the discussion for future work, TLS 1.3 is the current direction. One step at a time so we don't trip over our feet. ;) Dave From nobody Tue Jan 12 12:35:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF01A8899 for ; Tue, 12 Jan 2016 12:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 Xxgi-EU-bzFz for ; Tue, 12 Jan 2016 12:35:53 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 401791A8898 for ; Tue, 12 Jan 2016 12:35:53 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id v14so371773331ykd.3 for ; Tue, 12 Jan 2016 12:35:53 -0800 (PST) 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:content-type; bh=OtyyA9ZgGd3Z0ZoRFO5ucoHrr3oNPe3+3daeq2Bk6Ec=; b=hL9Shn+4h8RvFEHF/HDtVSkehquaVPCuAYqPD4VsHJzgq5QwnQFsXtoX+RDnjD2kFp HY8Y+aZXiek1hPpEKAhDClDf6tHotRT36p2zOA5RkWFGKcnqCS72Jg/I89OMegdi9R40 QikvC1baDfDQ7jFGQPEzVeibfIll3x+bKYIE47QAt56kS0JCjCCUS9LaTM1uMLoGejRI PQJelqKitZ3ObguS2yuiW2NOvEsdh+oo1Q07MsWMJBs5CVFiHarwqtEO0JwpNLVUrfo4 Pk+mHD+uaddwKRWSdCoMwkx98xHQWdM3h9udAwWqPk/+HnwQSttEwBNC75QtKb/eD2Nb J7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OtyyA9ZgGd3Z0ZoRFO5ucoHrr3oNPe3+3daeq2Bk6Ec=; b=B0XFmfVmiDNRzWshnREw7WdwxOe/sQ7tkEN/qgdk8nMZQcRKO6R07X3X1SpXlfQuPs 51RHPZdq1VG9DLX+OX0py8lDb7D4dLMY4vZOHedzuZpF2PEQxsX+k+nzzhCF6sE3x+fH TkMrlUlMKD88dYWffxh8QhyD6knIRUaM3GjcTg2tjaT/5yrxg6uIMak68ncRdw9lIA+F ugUgvTGIJmOCtVqZvzWvi6yUV1dNh2mqNY8Rjo3y1Yk811O9msZ5nDbcHYArlZAkgzTr L9vqKbYlKmvDz4Un7VZU6PfHz5WeoUQh01/YSveaIsMOArAp578AZP7M203KhqrLVtOp RfSA== X-Gm-Message-State: ALoCoQl4hiIE6Gj5uIvKjGZOIWOHhyKc4gbfRxFuhJ7vYzkZ6HRDYf0VS+aopy0u8VoBjN7NLs1jYoCVOKjH2ZOGoLS47xSEbA== X-Received: by 10.129.79.87 with SMTP id d84mr96945645ywb.115.1452630952572; Tue, 12 Jan 2016 12:35:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 12:35:13 -0800 (PST) In-Reply-To: <201601121533.59799.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121533.59799.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 12 Jan 2016 12:35:13 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114dc360eb2e3c052928ffc7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:35:55 -0000 --001a114dc360eb2e3c052928ffc7 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett wrote: > On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote: > > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox > wrote: > > > I wish that were the plan (to upgrade QUIC crypto and eventually make > that > > > the new crypto platform). If I am not mistaken, QUICK crypto is going > to > > > be archived, TLS 1.3 will replace the crypto code, and QUIC will > remain the > > > transport layer. > > > > This is my understanding as well, based both onconversations with the > QUIC > > folks, and Adam and Jana's public presentations. A number of us (MT, I, > > Jana, Ian, AGL, Christian) have already started some initial > conversations > > at how to do that. > > I'm quite interested to hear what the plans are there. I'd appreciate it > if, whenever there is a fleshed-out starting point, an outline could be > posted to this list to keep us in the loop with what's going to be the > initial design. Not necessarily for debate here, but just so we can have an > idea of where things are going. > We definitely would post that somewhere, but thanks for the reminder to send a pointer to TLS WG. -Ekr > > > With that said, I don't think there's a plausible story in which QUIC > becomes the only > > transport protocol in the world any time soon, so I don't think > standalone TLS 1.3 > > is going away. > > Yes. Whatever the discussion for future work, TLS 1.3 is the current > direction. One step at a time so we don't trip over our feet. ;) > > > Dave > --001a114dc360eb2e3c052928ffc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox <waywardgeek@google.com> wrote:
> > I wish that were the plan (to upgrade QUI= C crypto and eventually make that
> > the new crypto platform).=C2=A0 If I am not mistaken, QUICK crypt= o is going to
> > be archived, TLS 1.3 will replace the crypto code, and QUIC will = remain the
> > transport layer.
>
> This is my understanding as well, based both onconversations with the = QUIC
> folks, and Adam and Jana's public presentations. A number of us (M= T, I,
> Jana, Ian, AGL, Christian) have already started some initial conversat= ions
> at how to do that.

I'm quite interested to hear what the plans are there. I'd a= ppreciate it if, whenever there is a fleshed-out starting point, an outline= could be posted to this list to keep us in the loop with what's going = to be the initial design. Not necessarily for debate here, but just so we c= an have an idea of where things are going.

<= div>We definitely would post that somewhere, but thanks for the reminder to= send a pointer
to TLS WG.

-Ekr
=C2=A0

=C2=A0

> With that said, I don't think there's a plausible story in whi= ch QUIC becomes the only
> transport protocol in the world any time soon, so I don't think st= andalone TLS 1.3
> is going away.

Yes. Whatever the discussion for future work, TLS 1.3 is the current= direction. One step at a time so we don't trip over our feet. ;)


Dave

--001a114dc360eb2e3c052928ffc7-- From nobody Tue Jan 12 13:08:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FA11A1AA1 for ; Tue, 12 Jan 2016 13:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3EPtX070SOJ for ; Tue, 12 Jan 2016 13:08:18 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0A51A891F for ; Tue, 12 Jan 2016 13:07:36 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g73so202048994ioe.3 for ; Tue, 12 Jan 2016 13:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=5gCX8Nh/kJn40w06KnZwq7Ehx0c1hdW9N20V78cdb/Q=; b=UULvlDl4vR+A6F3cb0xEiovGvBxQrCuGNiRhWJQHx2RV/uQaOHsJeAj/euLeb6zmyo Am2gsndGSq0qr1el6emJPQpP9XGCmhKSWeeThVEayJcnHP0Ij7QLWpu4aiq/YwGOtpIR WBPQ6degGna6MVyo+SRY+o+61UOqKqPcLducym68Zj2N1IIh5J37v6RTzG0RyIRXy/BK Lrc+S7lzI8rr+ZHGOiTaVFuH1flvfBqstWuskLgktbQVUAsNVwV0rnPu4Wtw59j/OPFc 2ReAJthzZ67su7IV1sePTaNfIlD9GZjn+vE3IhL7MM/cf7M89bnzxfr2QUcNtWpz68mf ZcBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=5gCX8Nh/kJn40w06KnZwq7Ehx0c1hdW9N20V78cdb/Q=; b=eb9265q2veH10pQdcMLh49/PR5djbse6Mfb1ij6qR5lDoWyfnL7/fW3eG/Qetqh8jZ K+xvVCXQv4Bq6+xICg6RwSX6l1grjsX/qH3gMuRDe8L60GzlKdDe2FVxWzo2fhXBC6vh pUYhe97FUOgarVqh6l1tI/OCcZxD8m+8ntgNF/UbWnaWcanPYyFSC+7m71cgYGXBdCdC OxYw8gTX0O5QmnHWV3ttViAzY7T2++xV9pvl+zKYKLkoDCgTAxkJh8IARPdkjs2at9m1 IHD8eqNipmzKtE9G+Aj7pNcj4tKSTLBCJMpDTgdyLUfOElisQoywVJ2aZYvvrQM9Awtl IKdA== X-Gm-Message-State: ALoCoQknQdGTem+WrkQneVzia7BUEaCRcOOWEuJCh9Ci52NtyGgHwyk4LapDc6pH1UTEfdx8R0BBnbPGLyXYxm/+ZZaSbT8Rxw== X-Received: by 10.107.128.201 with SMTP id k70mr83397843ioi.3.1452632856130; Tue, 12 Jan 2016 13:07:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.14.200 with HTTP; Tue, 12 Jan 2016 13:07:16 -0800 (PST) From: Fabrice Gautier Date: Tue, 12 Jan 2016 13:07:16 -0800 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:08:20 -0000 Hi, TLS 1.2 RFC says that a a client certificate MUST be compatible the parameters specified in the Certificate Request: key type, hash/signature algorithm and CA. If a client does not have such a compatible cert, it MUST send an empty Certificate message. In practice, what is a common behavior for Servers in the case where the client sends an incompatible cert ? Treat it as if there was an empty cert or an invalid cert ? Fail the handshake ? In practice, is it okay for a client to send a cert that may not be compatible with the CertificateRequest, knowing that the client cert might be selected by user action, or by an application layer above the TLS layer, and knowing that on the server side, the client cert verification might also be done a different layer, that may actually have a different idea of what an acceptable cert is than the TLS layer ? Thanks -- Fabrice From nobody Tue Jan 12 13:14:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141361A01AA for ; Tue, 12 Jan 2016 13:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 EeInt9-3MXHK for ; Tue, 12 Jan 2016 13:14:32 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 99AD61A00C3 for ; Tue, 12 Jan 2016 13:14:32 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id x67so467445495ykd.2 for ; Tue, 12 Jan 2016 13:14:32 -0800 (PST) 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:content-type; bh=NzdRxFywAUW8GOcFUGZFMFPPqn03Wgdcsm/jVL8PLUI=; b=cM7NiHExlLZ/3s80VREm5gtaWCpAwhzM6giK638fXI7IQBIxytVU5Ba60MTKjW2sr3 7izFh3pKyvHwqpVyzQ7xZUfyXUHi/aEDqL3M6d26veQAOJ8igAA7RIk09YXmP6LmzqbJ HYtuygV/0I53VC0X3Wo41YBBWzJQ0nJ+PXhVpaee8hO9NzgVUTViRPJG6x+GJ8FTrXkO dqha1gKVG39zct4JYeZ+HiM9tkVQQ04g49ZO+ESn0PUvbhJEii6FixhzaNpa4cxZwvFn gRbbMJiZyX55d33tYOwdeNOc0J1HuEgKOoKsTbX+ErCCu4H4cw8pWLKqPJNOCDg751nN 3LSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NzdRxFywAUW8GOcFUGZFMFPPqn03Wgdcsm/jVL8PLUI=; b=Q5XT4TXCN1BD9fWgSy7c8a1yUTNi1tJL5HEWCAadJV4aHF7qeb3LGuif1ZPSqDu9OC 0Q0B/CPmc3WIIo6qhNSjbXSXNhEcucSGyZUn9Zhvmrd44hOC7yvtjmsCzsd0L6E7M3PG 7eE9v1S8+ZfjrNbmnFiJVNRDQtDXkV8l7KsZJnFgjmKtAHwQFHYB+/dzpBGGF+l3TXV/ FjnLYpyFd3uIqBygBuPpfbAHTrmQxQVRy4gbDCjqhguKLPaqaUVVzCwGTQFZkfMspKyr g2k72T0rSeZGJJYGGdzzEqhssgd9zO0Raf8C+O24AC0abEJrJNlxB5YoU5onEBVBPeJ7 UV8g== X-Gm-Message-State: ALoCoQn9wvBCQYZhS/4ilSBO6G0e8IfloGRVDJNkmY5A52lzzd7C0F0gfhd9Kw5fWBQhMEbdZYcGeAYcfotQjjOa7adK2ksAiQ== X-Received: by 10.13.218.198 with SMTP id c189mr107626306ywe.165.1452633271929; Tue, 12 Jan 2016 13:14:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 13:13:52 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 12 Jan 2016 13:13:52 -0800 Message-ID: To: Fabrice Gautier Content-Type: multipart/alternative; boundary=94eb2c08192a29dc7b0529298a57 Archived-At: Cc: "" Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:14:34 -0000 --94eb2c08192a29dc7b0529298a57 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier wrote: > Hi, > > TLS 1.2 RFC says that a a client certificate MUST be compatible the > parameters specified in the Certificate Request: key type, > hash/signature algorithm and CA. > If a client does not have such a compatible cert, it MUST send an > empty Certificate message. > > In practice, what is a common behavior for Servers in the case where > the client sends an incompatible cert ? Treat it as if there was an > empty cert or an invalid cert ? Fail the handshake ? > > In practice, is it okay for a client to send a cert that may not be > compatible with the CertificateRequest, knowing that the client cert > might be selected by user action, or by an application layer above the > TLS layer, and knowing that on the server side, the client cert > verification might also be done a different layer, that may actually > have a different idea of what an acceptable cert is than the TLS layer > ? > Would a fair rephrase of this be "How many servers advertise some set of requirements for CertificateRequest that is actually stricter than what they would accept"? [0] -Ekr [0] The case of "I advertise requirements that are looser than I would accept" is, I suspect, quite common. For instance, you might advertise an empty CA list. > Thanks > > -- Fabrice > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08192a29dc7b0529298a57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <= fabrice.gaut= ier@gmail.com> wrote:
Hi,
TLS 1.2 RFC says that a a client certificate MUST be compatible the
parameters specified in the Certificate Request: key type,
hash/signature algorithm and CA.
If a client does not have such a compatible cert, it MUST send an
empty Certificate message.

In practice, what is a common behavior for Servers in the case where
the client sends an incompatible cert ? Treat it as if there was an
empty cert or an invalid cert ? Fail the handshake ?

In practice, is it okay for a client to send a cert that may not be
compatible with the CertificateRequest, knowing that the client cert
might be selected by user action, or by an application layer above the
TLS layer, and knowing that on the server side, the client cert
verification might also be done a different layer, that may actually
have a different idea of what an acceptable cert is than the TLS layer
?

Would a fair rephrase of this be &quo= t;How many servers advertise some set of
requirements for Certifi= cateRequest that is actually stricter than what they
would accept= "? [0]

-Ekr

[0] The = case of "I advertise requirements that are looser than I would accept&= quot;
is, I suspect, quite common. For instance, you might advert= ise an empty
CA list.



Thanks

-- Fabrice

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

--94eb2c08192a29dc7b0529298a57-- From nobody Tue Jan 12 13:31:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBB1A89B0 for ; Tue, 12 Jan 2016 13:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ij4qq1Yvo3f for ; Tue, 12 Jan 2016 13:31:08 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 C5C2D1A89A5 for ; Tue, 12 Jan 2016 13:31:07 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id mw1so138456551igb.1 for ; Tue, 12 Jan 2016 13:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6HTSknZ/fdqEYSeu8LRPfqENfeKkRF1wffbB6TuF5oo=; b=gesqkzpvxj/FeV1n65rFcdqr8eCcY/StChbGAC6jMOwpDjPGiNgvCTHM8ZnfRlAMmu 7sDxg+kXeVPeV6oSgXogyOVsc89sS2Qxxwu/8HHFkLXj8GHqeYI+WPOzpcCRdl43KOEC i3tEDYOhlCpO6Ixffk/XR/IoK2i6OPnR3asOPOFYtb7Q1Vu08W5wf5eBGWxx2vFFyna5 ElWPEDQxFDeDaa8pm7SsLQiTFkZAje+iVKSWO+VtZhISTa1DV2l6Ln5+qw/gM10IcSWv LzmK3i4AW6RM44Dr+a+Y9JNRSRz8h06BHOKpYzPhTe3Qfw/52y48gTOnGTR6ZkjDuQpP IuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6HTSknZ/fdqEYSeu8LRPfqENfeKkRF1wffbB6TuF5oo=; b=MxGKzXthp8Cr91S51x0oQ4Q0oyySmnM/N3rRgVbe4XNlgnNWXQd236LetPvrgz3FgP pxKKHO7OciaPfH7pOb77w0Flc1XPcVGV81WThZMQcXynBlW//DL6/BFfWxwnwfGEnGxy QXuwTrFwuwqHlJcNdNqTnK2bSYoWCgf9itMhMSgngJ4g0JilXw15QrlICRbT7nIhrtKV KZXTaU/JPvHT7vKDbKLXXUliO73QejgbHaTlQw+bCPdP15SXvfS8HfxhFslP/RnHQtJV XTp77MDKMABIP+HiY7HaqLcIrt7BtxH7fGu6R4F4/ZkHQ3cFz/AMR4oGDAPrYDoAUFu8 Gb5Q== X-Gm-Message-State: ALoCoQl/C8LGoFzjCw8haJWcZna/8jLR/cjQL6xHYyyllzSzO0CAGf/R29gfIzPfT6K91BpeLAasAiYYSksbnaYFnUJSt/SY2A== X-Received: by 10.50.61.177 with SMTP id q17mr19287564igr.68.1452634267058; Tue, 12 Jan 2016 13:31:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.14.200 with HTTP; Tue, 12 Jan 2016 13:30:47 -0800 (PST) In-Reply-To: References: From: Fabrice Gautier Date: Tue, 12 Jan 2016 13:30:47 -0800 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:31:09 -0000 On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla wrote: > > > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier > wrote: >> >> Hi, >> >> TLS 1.2 RFC says that a a client certificate MUST be compatible the >> parameters specified in the Certificate Request: key type, >> hash/signature algorithm and CA. >> If a client does not have such a compatible cert, it MUST send an >> empty Certificate message. >> >> In practice, what is a common behavior for Servers in the case where >> the client sends an incompatible cert ? Treat it as if there was an >> empty cert or an invalid cert ? Fail the handshake ? >> >> In practice, is it okay for a client to send a cert that may not be >> compatible with the CertificateRequest, knowing that the client cert >> might be selected by user action, or by an application layer above the >> TLS layer, and knowing that on the server side, the client cert >> verification might also be done a different layer, that may actually >> have a different idea of what an acceptable cert is than the TLS layer >> ? > > > Would a fair rephrase of this be "How many servers advertise some set of > requirements for CertificateRequest that is actually stricter than what they > would accept"? [0] Yes, that's another way to put it. Other related questions: "Do TLS libraries act strictly on those requirements, or do they leave it to the application layers?" "How do TLS libraries/server applications act when such requirements are not respected?" > -Ekr > > [0] The case of "I advertise requirements that are looser than I would > accept" > is, I suspect, quite common. For instance, you might advertise an empty > CA list. Right, And I guess servers may also advertise empty hash/sig list, and empty certificate_types list, although that would be violating the RFC. > >> >> Thanks >> >> -- Fabrice >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Tue Jan 12 13:31:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43B1A89B5 for ; Tue, 12 Jan 2016 13:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69mrrSpQuTWM for ; Tue, 12 Jan 2016 13:31:50 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 286151A89A5 for ; Tue, 12 Jan 2016 13:31:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 720BB1D1; Tue, 12 Jan 2016 23:31:49 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 8yBZPzY--nOv; Tue, 12 Jan 2016 23:31:48 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2BC25230D; Tue, 12 Jan 2016 23:31:48 +0200 (EET) Date: Tue, 12 Jan 2016 23:31:45 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:31:52 -0000 On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > > > On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote: > > > > The same concern still applies: what does it mean to allocate code > > point for the 4492bis-05 description? > > Allocating code points just means an implementation of draft-05 is > likely to interoperate just fine with an implementation of the final > RFC. > > Of course nothing is ever final until the RFC is out, so there’s > always a risk involved, but it is considered prudent to allocate > numbers when we’re reasonably certain of the calculations and on- > the-wire formats. Any debate about whether we should or should not > check certain inputs for certain conditions need not be a bar for > allocating numbers. Assuming CFRG chairs really did declare consensus on Ed448 hash, then the final characteristics of Ed448 are known and I have a reference implementation. And the PKIX draft looks implementable (has wrong example?) More serious interop hazard is what to do with X25519/X448 and THS (some of the proposed stuff is not wire-compatible). -Ilari From nobody Tue Jan 12 13:42:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBACA1A8A3E for ; Tue, 12 Jan 2016 13:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 IxFi3tjaFgf8 for ; Tue, 12 Jan 2016 13:42:39 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527881A8A29 for ; Tue, 12 Jan 2016 13:42:39 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id x67so468286947ykd.2 for ; Tue, 12 Jan 2016 13:42:39 -0800 (PST) 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:content-type; bh=ntrX1LIBtAR7HEUiLRpvzkTaOFUHIa+BhKPxenhquvg=; b=JsHR+xRmpouw7v1idELsuoZXmI5FKXarFh2MloYHNVJi75r9dzAoihjc7oRRMLKhwp T/kv0pfqNeDOipgOnHQb/LetNUt8dStvovq2Tzyg6VmuuQpjf2xpF1MEFTJ1gzJVAlam 9KbgHmG9Zf/IF+QX52qadmCmzSn20c7yUuO3VHrUNgBgapkG356grEZNjY50x5ZLaSy2 B65bGv+qkFhPIEnJB6wUdXQ2aZaPdBNi44HKPw8JwkktIoS29HPvd4+kMqA9mRvVFOza K0nHaFq++H6Kj/hctIEcs7AEgyva/VaaA/SGzj3lwUSrSY1bDj+DlhEmnaKDYFD/6HUg XD3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ntrX1LIBtAR7HEUiLRpvzkTaOFUHIa+BhKPxenhquvg=; b=kx6OLDs9UFHVOVuEledpDa982j+jQKMjWMgTAO63KXbcpy9xTNOwMXfhADX3JuZEtD rahLoFtj0YfTTcFvwkslImy2Diodj+QgFxjb1vhoub++QqsQNepaHKU4B8SfZPHbvkMp JDSfZ2aMnCD8hPBHKuN6xIqqG24QZJWHcfmVS8xNmv+68wNXz4/rd3eXT11wlqaKr+h3 wm7PbNCkZmfjKR3izyuU8bAtIDNa8XdnNndsP/9/c64kBdr46NuN0Y7M4eLxEe8d2p/Y UK3W9rzqGgx/Rbv0dSItYw29cXV1iI39e3kCk6s4+QNGZCKcmbQpBagaYKV6GJrR+FFl evfA== X-Gm-Message-State: ALoCoQmo8V3EeKoFdPrBzw95oc7hfTIuXYXK4tHj3vzPJDTRpZMuu1wHrP63r44RY6mMG1zibdHzvMLfigHKMBpud/Jw3T6u+A== X-Received: by 10.13.193.4 with SMTP id c4mr113071547ywd.192.1452634958600; Tue, 12 Jan 2016 13:42:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 13:41:59 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 12 Jan 2016 13:41:59 -0800 Message-ID: To: Fabrice Gautier Content-Type: multipart/alternative; boundary=001a114caa9eb24f7f052929ee9f Archived-At: Cc: "" Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:42:41 -0000 --001a114caa9eb24f7f052929ee9f Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier wrote: > On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla wrote: > > > > > > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier < > fabrice.gautier@gmail.com> > > wrote: > >> > >> Hi, > >> > >> TLS 1.2 RFC says that a a client certificate MUST be compatible the > >> parameters specified in the Certificate Request: key type, > >> hash/signature algorithm and CA. > >> If a client does not have such a compatible cert, it MUST send an > >> empty Certificate message. > >> > >> In practice, what is a common behavior for Servers in the case where > >> the client sends an incompatible cert ? Treat it as if there was an > >> empty cert or an invalid cert ? Fail the handshake ? > >> > >> In practice, is it okay for a client to send a cert that may not be > >> compatible with the CertificateRequest, knowing that the client cert > >> might be selected by user action, or by an application layer above the > >> TLS layer, and knowing that on the server side, the client cert > >> verification might also be done a different layer, that may actually > >> have a different idea of what an acceptable cert is than the TLS layer > >> ? > > > > > > Would a fair rephrase of this be "How many servers advertise some set of > > requirements for CertificateRequest that is actually stricter than what > they > > would accept"? [0] > > Yes, that's another way to put it. > > Other related questions: > "Do TLS libraries act strictly on those requirements, or do they leave > it to the application layers?" > "How do TLS libraries/server applications act when such requirements > are not respected?" > I know NSS isn't used in a lot of servers, but at this point I believe that to a first order it enforces the same rules that it advertises. -Ekr > > > -Ekr > > > > [0] The case of "I advertise requirements that are looser than I would > > accept" > > is, I suspect, quite common. For instance, you might advertise an empty > > CA list. > > Right, > And I guess servers may also advertise empty hash/sig list, and empty > certificate_types list, although that would be violating the RFC. > > > > >> > >> Thanks > >> > >> -- Fabrice > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > --001a114caa9eb24f7f052929ee9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier <= fabrice.gaut= ier@gmail.com> wrote:
On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <fabrice.gautier@gmail.com>
> wrote:
>>
>> Hi,
>>
>> TLS 1.2 RFC says that a a client certificate MUST be compatible th= e
>> parameters specified in the Certificate Request: key type,
>> hash/signature algorithm and CA.
>> If a client does not have such a compatible cert, it MUST send an<= br> >> empty Certificate message.
>>
>> In practice, what is a common behavior for Servers in the case whe= re
>> the client sends an incompatible cert ? Treat it as if there was a= n
>> empty cert or an invalid cert ? Fail the handshake ?
>>
>> In practice, is it okay for a client to send a cert that may not b= e
>> compatible with the CertificateRequest, knowing that the client ce= rt
>> might be selected by user action, or by an application layer above= the
>> TLS layer, and knowing that on the server side, the client cert >> verification might also be done a different layer, that may actual= ly
>> have a different idea of what an acceptable cert is than the TLS l= ayer
>> ?
>
>
> Would a fair rephrase of this be "How many servers advertise some= set of
> requirements for CertificateRequest that is actually stricter than wha= t they
> would accept"? [0]

Yes, that's another way to put it.

Other related questions:
"Do TLS libraries act strictly on those requirements, or do they leave=
it to the application layers?"
"How do TLS libraries/server applications act when such requirements are not respected?"

I know NSS isn= 't used in a lot of servers, but at this point I believe that to a
first order it enforces the same rules that it advertises.
=
-Ekr





> -Ekr
>
> [0] The case of "I advertise requirements that are looser than I = would
> accept"
> is, I suspect, quite common. For instance, you might advertise an empt= y
> CA list.

Right,
And I guess servers may also advertise empty hash/sig list, and empty
certificate_types list, although that would be violating the RFC.

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

--001a114caa9eb24f7f052929ee9f-- From nobody Tue Jan 12 15:11:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318161A9037 for ; Tue, 12 Jan 2016 15:11:20 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL-d-BYWHp_6 for ; Tue, 12 Jan 2016 15:11:16 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8191A903E for ; Tue, 12 Jan 2016 15:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452640278; x=1484176278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/cpzeOfSK4wd676mA5krgbQBL2WQ1WbC5lsCQAbKeFw=; b=FTSg/04NBwmeR53HBl1cTCJl4MB0hGFSA0En+lWxmcwzuEjNbXKZJW42 Zd5Gn5NQgTldH7gqCrfkUwp4EP/z6jr80t/hGv/dxCaoEvJkWI1FpfSyk 2Jt4xOalutSVXJJTX/WsOgYxvLsYNfqSGJOhE4bQpmCvo5JKtuHNPgacz 6tXldPURdWkaNV8xiMy6vbw2vo5j+2Tc0NMG8qnBfulTMlJH7JaQdLnSR 1LRvy+aE1w+0DjeBMt2KEA0rX6RbN6UEkRIMxd/S2FRmGBNHJIA8hxK0w jL8y7wz7h2usjY2xeeeY3NeCh4NrmZXdKwr9V6jZK0AFEVJf6qf+kHE79 A==; X-IronPort-AV: E=Sophos;i="5.22,285,1449486000"; d="scan'208";a="62846998" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 12:11:15 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 12:11:13 +1300 From: Peter Gutmann To: Fabrice Gautier , Eric Rescorla Thread-Topic: [TLS] Server behavior when client certificate does not match the request ? Thread-Index: AQHRTX5DOS6Aa444ckqcdYefrftCbZ73jBWAgAD1zoM= Date: Tue, 12 Jan 2016 23:11:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC7075@uxcn10-5.UoA.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:11:20 -0000 Fabrice Gautier writes:=0A= =0A= >"Do TLS libraries act strictly on those requirements, or do they leave it = to=0A= >the application layers?"=0A= >=0A= >"How do TLS libraries/server applications act when such requirements are n= ot=0A= >respected?"=0A= =0A= This has already been discussed in the past, it's not up to TLS to constrai= n=0A= what a CA can do, and more to the point if you've paid a CA a small fortune= =0A= for a cert you don't want some TLS implementation to reject it because of s= ome=0A= minor disagreement over what colour the cert frame is painted.=0A= =0A= Redde Caesari quae sunt Caesaris, the PKI code decides whether a cert chain= is=0A= acceptable or not, not the TLS code. =0A= =0A= Which is exactly what my code does.=0A= =0A= Peter.= From nobody Tue Jan 12 15:53:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA161A90AA for ; Tue, 12 Jan 2016 15:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztHg0LEO90a8 for ; Tue, 12 Jan 2016 15:53:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7621A90A5 for ; Tue, 12 Jan 2016 15:53:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C5B0C284F1B; Tue, 12 Jan 2016 23:53:32 +0000 (UTC) Date: Tue, 12 Jan 2016 23:53:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160112235332.GG18704@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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 Jan 2016 23:53:35 -0000 On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > In practice, what is a common behavior for Servers in the case where > the client sends an incompatible cert ? Treat it as if there was an > empty cert or an invalid cert ? Fail the handshake ? With TLS 1.0/1.1, in which the server cannot indicate support for a list signature algorithms, the logical conclusion is that the client MUST NOT use a public key algorithm that is different from the agreed cipher-suite. It can accomplish this by only advertising cipher suites compatible with the client certificate it will (can be tricky if it has more than one). With TLS 1.0/1.1 there is no reason to expect that the server will understand signatures made with a public key algorithm other than the one used in the the server certificate (which agrees with the ciphersuite in the server HELLO). With TLS 1.2, where the server does send a supported_signature_algorithms list, clients that use signatures other than those listed should expect to run into servers that reject this with a fatal alert. The server's TLS stack (not its X.509 chain verification code) has to check the signature in the client's "Certifice Verify" message. The server's list of CA's on the other hand is largely a hint, and clients often just ignore it entirely. If the server can verify the certificate, it generally does not matter whether the CA was listed in the certificate request message or not. For many servers client certificates are optional anyway, or they verify them without reference to any particular PKI. -- Viktor. From nobody Tue Jan 12 16:14:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7863E1A90E7 for ; Tue, 12 Jan 2016 16:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE_TMwALexgV for ; Tue, 12 Jan 2016 16:14:03 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDE41A908A for ; Tue, 12 Jan 2016 16:14:02 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id h5so100089178igh.0 for ; Tue, 12 Jan 2016 16:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HLU9tzjCIQyEdkNAQp5+ycWvePBCquksUG+3bZFbS+E=; b=OlTGhDbF/9wQoGJzYH88oAxfp5nq5BdcNgD2Kh7jGs4AAK15fxZ2vlg9Na+PGWBmHq 3clnd4nFkEW66M2DGWqHRB9aBFvTFNTlVwP0jPC5t15AFDfbQ1LQkPZYfT8vOvxYihxF fPxlzJBAIPnBnOGkKnRgMJtLLhktq9hEWCWXvInzK9bRYXolqFjW5MDsEpPtR8/I3CnE PXMa1hFB1adp5q9XfqdLqNPuaYDalJvrPgLVJ+TulAlc8XCEboRffZco/kRYubbFMdho vwcgEIrRlvoJdku4+yEtV2RSq57Wg6SIV7Fadb8hTAfcLyv76afFKlp1K/jQ9woO/ke1 aCXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=HLU9tzjCIQyEdkNAQp5+ycWvePBCquksUG+3bZFbS+E=; b=UI5MxUq2wmuFs6Mt6ciz2eJEYSqSifj6dF8V+9uf8M5imfaSm3kjQ7C+JoAb0wlutN NDN48PKQpJoF9EVclVvn1R+D79zlJok0hMuzEvOvWNWPbEf6GQ0qWH4OMhdVQIGC7Eek vVnx1w9xbFiH1GBfShicMAXpPZhKgLL/E7V41YsDCsQ49kyuAYw+J1YLirOGPx7xJqc8 t6sqfE0V3xvGzSHwmNUrb9OckB721c17pUkPye34u/lijN1S2l5zGjAAc+77Y80lA51/ y0mftCMo2K+R/G1uFybXS/fL3hcCf6uT31IFKmg7kLx4GWDfm1vGwG94dg+Xw2sox7U+ /o/g== X-Gm-Message-State: ALoCoQmlc3fVDjXo/mG7bvFN032ppnHgdaQ8wr+izFE4gf8ZA2jLbmKO+AST9RCXNIznO2Gh98yo3raGgV/W9ibOUTWY19y9Tw== X-Received: by 10.50.79.165 with SMTP id k5mr21658533igx.10.1452644042171; Tue, 12 Jan 2016 16:14:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.14.200 with HTTP; Tue, 12 Jan 2016 16:13:42 -0800 (PST) In-Reply-To: <20160112235332.GG18704@mournblade.imrryr.org> References: <20160112235332.GG18704@mournblade.imrryr.org> From: Fabrice Gautier Date: Tue, 12 Jan 2016 16:13:42 -0800 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:14:04 -0000 On Tue, Jan 12, 2016 at 3:53 PM, Viktor Dukhovni wrote: > On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > >> In practice, what is a common behavior for Servers in the case where >> the client sends an incompatible cert ? Treat it as if there was an >> empty cert or an invalid cert ? Fail the handshake ? > > With TLS 1.0/1.1, in which the server cannot indicate support for > a list signature algorithms, the logical conclusion is that the > client MUST NOT use a public key algorithm that is different from > the agreed cipher-suite. It can accomplish this by only advertising > cipher suites compatible with the client certificate it will (can > be tricky if it has more than one). > With TLS 1.0/1.1 there is no reason to expect that the server will > understand signatures made with a public key algorithm other than > the one used in the the server certificate (which agrees with the > ciphersuite in the server HELLO). Hum, the client certificate type would theoretically defined by the "certificate_types" list in the CertificateRequest message, not the cipher suite. So you can have RSA client cert with EC ciphersuites and server certs and vice-versa, even in TLS 1.0/1.1 > With TLS 1.2, where the server does send a supported_signature_algorithms > list, clients that use signatures other than those listed should > expect to run into servers that reject this with a fatal alert. > The server's TLS stack (not its X.509 chain verification code) has > to check the signature in the client's "Certifice Verify" message. Which does raise another interesting question when certificate_types and supported_signature_algorithms conflicts. > The server's list of CA's on the other hand is largely a hint, and > clients often just ignore it entirely. If the server can verify > the certificate, it generally does not matter whether the CA was > listed in the certificate request message or not. For many servers > client certificates are optional anyway, or they verify them without > reference to any particular PKI. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jan 12 16:20:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C311A9114 for ; Tue, 12 Jan 2016 16:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 4Am_wz9TdMrX for ; Tue, 12 Jan 2016 16:20:41 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 C4DE31A9111 for ; Tue, 12 Jan 2016 16:20:40 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id v14so377738803ykd.3 for ; Tue, 12 Jan 2016 16:20:40 -0800 (PST) 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:content-type; bh=LMFK8YypvqW3o+wWwK8S8EbQ4Uyk4FM9kv9GKUrRnds=; b=Fq6i86siBP12gUsKc/BX7ofriSouIUnpJ/+OVZAqppqyrNUg6ZbmsP/3fxNgGKHt/D zvLwL8+8nNpCJO/HDUMQQIVTT1Dnf99MMS8fOolVmwODQMT9ZZ13eC35SmpOTvHTSEvF 8Rytebmx2OpIBKnTb5ebFLvN5/FIyxJ8REZ+7DwabcdC9he+MWKwP6zdkYTHU/lVdLbC tLm73JRzwIsijchZnVHObjn8L82AJcfXzH2uQKsOWzw3VCuVxe6RWmWvulA8ZIwsQUd9 OqPSQtjIMKcrKfpHsiv7SOauDqyw4D/DAR4Uq59obtC1pYqJkId+WEnb3tNy+sdV+Zb4 eapg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LMFK8YypvqW3o+wWwK8S8EbQ4Uyk4FM9kv9GKUrRnds=; b=RqmOP/X9Ljxd/hlNlfjLaInEJzr86mRSg06ft9GgHUKUtFr8iimSNSzzC0Hh1ZMxFK M3u/T1/lrmGghrVijhfZ6nFT8JJhcXZVqnRrJyN/vgnE4gt0FGLG7LasRaUxJI834QYI b4RhUu3p8ZzVDMYLdRnuvvbWnsdF+Qwi6d8vCQN5zb7j868KabhukiJgd59aQxjSaUwb lmSl+KZEFVU8Oq5XH7dBsOest21csL9Bv0pus0XG6z+imkmVPwl28bddGwYSA9bPslU6 bpYMfUotk3S/pTHieuyua88KuTJC/CuTPkgwsaJUfV8Chao/nNM3chj6pE++DRMJcMv+ hxJA== X-Gm-Message-State: ALoCoQlsvUJyQ1jVQCfXRXtjnmbCwdOfggPqi2xoJRtasYPJuCo3c87s9ArBUEQlyguItDe37GN+d74cvWtOjaqIXs9gTL91BA== X-Received: by 10.129.38.135 with SMTP id m129mr7074445ywm.155.1452644440033; Tue, 12 Jan 2016 16:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 16:20:00 -0800 (PST) In-Reply-To: References: <20160112235332.GG18704@mournblade.imrryr.org> From: Eric Rescorla Date: Tue, 12 Jan 2016 16:20:00 -0800 Message-ID: To: Fabrice Gautier Content-Type: multipart/alternative; boundary=001a1141618cd57c6405292c2309 Archived-At: Cc: "" Subject: Re: [TLS] Server behavior when client certificate does not match the request ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:20:42 -0000 --001a1141618cd57c6405292c2309 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier wrote: > > > With TLS 1.2, where the server does send a supported_signature_algorithms > > list, clients that use signatures other than those listed should > > expect to run into servers that reject this with a fatal alert. > > The server's TLS stack (not its X.509 chain verification code) has > > to check the signature in the client's "Certifice Verify" message. > > Which does raise another interesting question when certificate_types > and supported_signature_algorithms conflicts. It's the intersection: https://tools.ietf.org/html/rfc5246#section-7.4.4 - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. - The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. However, it's confusing, and so we removed certificate_types in 1.3. -Ekr > > > The server's list of CA's on the other hand is largely a hint, and > > clients often just ignore it entirely. If the server can verify > > the certificate, it generally does not matter whether the CA was > > listed in the certificate request message or not. For many servers > > client certificates are optional anyway, or they verify them without > > reference to any particular PKI. > > > > -- > > Viktor. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141618cd57c6405292c2309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier <fabrice.gautier@gma= il.com> wrote:

> With TLS 1.2, where the server does send a supported_signature_algorit= hms
> list, clients that use signatures other than those listed should
> expect to run into servers that reject this with a fatal alert.
> The server's TLS stack (not its X.509 chain verification code) has=
> to check the signature in the client's "Certifice Verify"= ; message.

Which does raise another interesting question when certificate_types=
and supported_signature_algorithms conflicts.

It's the intersection:

   -  Any certificates provided by the client MUST be s=
igned using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.

   -  The end-entity certificate provided by the client MUST contain a
      key that is compatible with certificate_types.  If the key is a
      signature key, it MUST be usable with some hash/signature
      algorithm pair in supported_signature_algorithms.
However, it's conf=
using, and so we removed certificate_types in 1.3.
-Ekr
=C2=A0

> The server's list of CA's on the other hand is largely a hint,= and
> clients often just ignore it entirely.=C2=A0 If the server can verify<= br> > the certificate, it generally does not matter whether the CA was
> listed in the certificate request message or not.=C2=A0 For many serve= rs
> client certificates are optional anyway, or they verify them without > reference to any particular PKI.
>
> --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Viktor.
>
> _______________________________________________
> 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

--001a1141618cd57c6405292c2309-- From nobody Tue Jan 12 17:12:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722BA1AC7E7 for ; Tue, 12 Jan 2016 17:12:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFCja0zx6gxJ for ; Tue, 12 Jan 2016 17:12:16 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7801AC445 for ; Tue, 12 Jan 2016 17:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452647536; x=1484183536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kX2QpgkzEfETrDKBKtjcXvoFaycEVp2JX7J+fFA0TMY=; b=QspJJxGn0CT7ExVkB4DTe8argX0KCoONipMXSBD828AoXkHD+VfsSOeU RLNoUVFacjxxRzBf6Xf7bur1r2H2C77dsaz/d9Gw6bm93WtKPRwVZT8/P niRrxo8KW3E5sYBOoNNVS4ucDf5QEXrm1W6wUF22ht9gwfjEAyectyXVU VDLSBtuqUziQMfyr/ujHadaAYhDCgC2KsSXBL0VJiNl/CMsmkEZzflY50 TJtRJVdpyI/dti+Q6DHCSm/5f6iRm4b8V0JEmyyYOOv8qKJ6h23cwXIwk i4+wPqBYlg1UXsJG96NGeUyd6l7UQBnj8x7d2vBkq69LQazhwlrJchp92 A==; X-IronPort-AV: E=Sophos;i="5.22,286,1449486000"; d="scan'208";a="62866163" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jan 2016 14:12:14 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 13 Jan 2016 14:12:14 +1300 From: Peter Gutmann To: Yoav Nir Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzf//Ww+AgAFZaKY= Date: Wed, 13 Jan 2016 01:12:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz>, <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> In-Reply-To: <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 01:12:18 -0000 Yoav Nir writes:=0A= =0A= >Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)= =0A= >that this WG is working on right now, why?=0A= =0A= Embedded devices and similar systems with long-term requirements. Most of = my=0A= user base is embedded (or non-embedded equivalents, systems that need to ru= n=0A= in a fixed configuration for a very long time after they're deployed). As= =0A= I've mentioned in an earlier post, the median point on the bell curve is=0A= probably around TLS 1.0/1.1. These are systems with an expected lifetime o= f=0A= 10-20 years or more, deployment of new versions moves slowly and carefully = so=0A= the less radical changes you need to make the better, and most importantly = you=0A= can't roll out patches every month or two when the next attack on TLS is=0A= published.=0A= =0A= To expand on this, I'll take Ilari Liusvaara's comments:=0A= =0A= >Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10= =0A= >years old. The basic framework for doing 0-RTT is the obvious one. The onl= y=0A= >new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old.=0A= >=0A= >So I don't see anything "experimential" ideas, mechanisms or algorithms in= =0A= >there=0A= =0A= When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH= ,=0A= RSA, DES, etc, only SHA-1 was relatively new). They were mature algorithms= ,=0A= lots of research had been published on them, and yet we're still fixing iss= ues=0A= with them 20 years later (DH =3D 1976, SSLv3 =3D 1996, Logjam =3D 2015).=0A= =0A= TLS 2.0-called-1.3 will roll back the 20 years of experience we have with a= ll=0A= the things that can go wrong and start again from scratch. SIGMA, at ten= =0A= years old, is a relative newcomer to DH's 20 years when it was used in SSLv= 3,=0A= but in either case we didn't discover all the problems with it until after = the=0A= protocol that used it was rolled out. We currently have zero implementatio= n=0A= and deployment experience with 2.0-called-1.3 [0], which means we're likely= to=0A= have another 10-20 years of patching holes ahead of us. This is what I mea= nt=0A= by "experimental, bleeding-edge".=0A= =0A= What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially=0A= what's already out there with the bugs fixed, and where you've got a pretty= =0A= good chance that you won't be rolling out hotfixes every other month to pat= ch=0A= the newly-discovered-vulnerability of the month (which, in the case of most= =0A= things that aren't web browsers and servers, is more or less impossible to= =0A= do).=0A= =0A= (Which also means that the requirements for it should include explicit "don= 't=0A= use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the=0A= values", all the other obvious-but-apparently-not-obvious-enough stupid tha= t's=0A= turned up recently).=0A= =0A= TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did,=0A= targeting the specialised requirements of web servers/browsers and ignoring= =0A= everything else. The HTTPS 2 WG's response to this at the time was "let th= em=0A= eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for-= =0A= everything-else (1.1). Is the TLS equivalent going to be "let them eat TLS= =0A= 1.1"?=0A= =0A= (General note: That one short post has generated an enormous amount of emai= l=0A= off-list as well as on, for all those waiting for replies to private mail,= =0A= please be patient, I'm working through it...).=0A= =0A= Peter.=0A= =0A= [0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will= be=0A= known as 1.3".= From nobody Tue Jan 12 17:31:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86C41B2A94 for ; Tue, 12 Jan 2016 17:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpUeh7D0yWDg for ; Tue, 12 Jan 2016 17:31:35 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC6B1ACCF5 for ; Tue, 12 Jan 2016 17:31:35 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id a85so394942694ykb.1 for ; Tue, 12 Jan 2016 17:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=17GgKPnHtwAm1lVQbeyIRSSdBjRqOTB9vPE1J+BH9Qs=; b=baIrji/XETBsH5CgjbEq6dlKcQejJJVXnKrueaON8ezkr8YDiqwnyZqTBpNwMrC6NU 1sNyZYVZdA7on+Ua8Qy41ap7+tU2mR2/JZKWPecNRGc9wX2EM/udJLQQ2i8SCfvynJkw 7z59S7/JCjZVp0+CSTx1h308sd/vrg+FpNfzha6lbGLUhwEcSfuhSP+RZ5UbB6PSJvhb U4Jkkb9JYADmSDYHFxC16wX7zZOKJPDMvzjnUXDmp8QNkIrcNBCgTS/9y8wYy0luIIV9 9hrqcfWAIP6tIIr6yj8ANkzKSIvzYLY+NROA5JF4QTAU/OjjMlhf4A8FMGXc+Z84G9nk 6z1g== MIME-Version: 1.0 X-Received: by 10.129.72.84 with SMTP id v81mr98499533ywa.101.1452648694839; Tue, 12 Jan 2016 17:31:34 -0800 (PST) Received: by 10.13.216.150 with HTTP; Tue, 12 Jan 2016 17:31:34 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 12 Jan 2016 17:31:34 -0800 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 01:31:37 -0000 On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann wrote: > Yoav Nir writes: > >>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) >>that this WG is working on right now, why? > > Embedded devices and similar systems with long-term requirements. Most of my > user base is embedded (or non-embedded equivalents, systems that need to run > in a fixed configuration for a very long time after they're deployed). As > I've mentioned in an earlier post, the median point on the bell curve is > probably around TLS 1.0/1.1. These are systems with an expected lifetime of > 10-20 years or more, deployment of new versions moves slowly and carefully so > the less radical changes you need to make the better, and most importantly you > can't roll out patches every month or two when the next attack on TLS is > published. So for your proposal to solve this problem, it needs to be more likely to be secure then TLS 1.3. Of course, the slow rollout gives time to thoroughly test massive changes, while large numbers of small changes will not be a good idea. > > To expand on this, I'll take Ilari Liusvaara's comments: > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10 >>years old. The basic framework for doing 0-RTT is the obvious one. The only >>new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old. >> >>So I don't see anything "experimential" ideas, mechanisms or algorithms in >>there > > When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH, > RSA, DES, etc, only SHA-1 was relatively new). They were mature algorithms, > lots of research had been published on them, and yet we're still fixing issues > with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015). We all understand that the security of a protocol is not a function not of the primitives but of the way the protocol works. The confusion between export and nonexport DH shares was noted almost immediately in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a discovery in 2015, given that the reasons for this were all worked out in the early 90's. So no, Logjam is not a result of unknown issues appearing after 20 years, but ignoring known issues. > > TLS 2.0-called-1.3 will roll back the 20 years of experience we have with all > the things that can go wrong and start again from scratch. SIGMA, at ten > years old, is a relative newcomer to DH's 20 years when it was used in SSLv3, > but in either case we didn't discover all the problems with it until after the > protocol that used it was rolled out. We currently have zero implementation > and deployment experience with 2.0-called-1.3 [0], which means we're likely to > have another 10-20 years of patching holes ahead of us. This is what I meant > by "experimental, bleeding-edge". There is an old joke about the resume with one years experience repeated 20 times. All of the problems in TLS have been known for decades, as I've repeatedly demonstrated on this list. All of them were known to cryptographers at the time TLS was being designed and deployed. It does not take deployment to trigger analysis. > > What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially > what's already out there with the bugs fixed, and where you've got a pretty > good chance that you won't be rolling out hotfixes every other month to patch > the newly-discovered-vulnerability of the month (which, in the case of most > things that aren't web browsers and servers, is more or less impossible to > do). TLS 1.3 is being designed in cooperation with people who *actually know cryptography* with computer-based models and theorem provers for the entire protocol. Your proposal isn't, instead patching a collection of known issues. But we already did that in UTA. I don't see why we should believe your proposal solves it better. > > (Which also means that the requirements for it should include explicit "don't > use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the > values", all the other obvious-but-apparently-not-obvious-enough stupid that's > turned up recently). > > TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did, > targeting the specialised requirements of web servers/browsers and ignoring > everything else. The HTTPS 2 WG's response to this at the time was "let them > eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for- > everything-else (1.1). Is the TLS equivalent going to be "let them eat TLS > 1.1"? What features in TLS 1.3, other than 0-RTT (which is optional!) make it unsuitable for embedded devices? > > (General note: That one short post has generated an enormous amount of email > off-list as well as on, for all those waiting for replies to private mail, > please be patient, I'm working through it...). > > Peter. > > [0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will be > known as 1.3". > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Jan 13 01:53:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08501A0025 for ; Wed, 13 Jan 2016 01:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XMWRWdYnM60 for ; Wed, 13 Jan 2016 01:53:40 -0800 (PST) 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 2536E1A0021 for ; Wed, 13 Jan 2016 01:53:40 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 857298CF5D; Wed, 13 Jan 2016 09:53:39 +0000 (UTC) Received: from dhcp-10-40-2-130.brq.redhat.com (dhcp-10-40-2-130.brq.redhat.com [10.40.2.130]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0D9ra7n009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Jan 2016 04:53:38 -0500 Message-ID: <1452678816.25588.38.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir , Peter Gutmann Date: Wed, 13 Jan 2016 10:53:36 +0100 In-Reply-To: <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 09:53:41 -0000 On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol. Switching to a new version invalidates all the existing analysis. That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options: 1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS. > Any TLS library that exists now doesn’t have an implementation of > either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to > get an upgraded version of your favorite library. So the upgrade path > is no smoother for either protocol.   If this had been brought up > before the work on the current draft started, maybe we would be > convinced. As it is, I don’t see the point. The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable. [0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf regards, Nikos From nobody Wed Jan 13 02:09:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB51A037B for ; Wed, 13 Jan 2016 02:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhKSemG6wDBE for ; Wed, 13 Jan 2016 02:09:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35DD1A036B for ; Wed, 13 Jan 2016 02:09:13 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id BB791128BF909 for ; Wed, 13 Jan 2016 10:09:08 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u0DA944l012958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Jan 2016 11:09:10 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.142]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 13 Jan 2016 11:09:05 +0100 From: "SCHWARZ, Albrecht (Albrecht)" To: "" Thread-Topic: [TLS] Fixing TLS Thread-Index: AQHRTehT2rYBdeSLgEifQoT+VaXxrp75N4MA Date: Wed, 13 Jan 2016 10:09:04 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACDF7F0E17@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> <1452678816.25588.38.camel@redhat.com> In-Reply-To: <1452678816.25588.38.camel@redhat.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 10:09:15 -0000 PiBTd2l0Y2hpbmcgdG8gYSBwcm90b2NvbCBsaWtlIFRMUyAxLjMgYXMgaXQgaXMgdG9kYXkgdG8g Zml4IHRoYXQgdGhpbmcgaXQgaXMgYW4gb3ZlcmtpbGwuDQoNClRoZSBwcmltYXJ5IHB1cnBvc2Ug b2YgYSBzZWN1cml0eSBwcm90b2NvbCBpcyB0byBzdXBwb3J0IHNlY3VyaXR5IGFzIGJlc3QgYXMg cG9zc2libGUuIEtub3dpbmcgc2VjdXJpdHkgZ2FwcyBjYXVzZXMgZGlzdHJ1c3QgaW4gZ2VuZXJh bC4gUHJvYmFibHkgbm90IGluIHRoZSBzZWN1cml0eSBwcm90b2NvbCBleHBlcnRzIGNvbW11bml0 eSwgYnV0IGluIHRoZSBvdmVyYWxsIGNvbW11bmljYXRpb25zIGFuZCBpbmZvcm1hdGlvbiB0ZWNo bm9sb2d5IGluZHVzdHJ5Lg0KVGhlIHF1YW50aWZpY2F0aW9uIG9mICJvdmVya2lsbCIgc2hvdWxk IGJlIHJhdGVkIGZyb20gdGhhdCB0cnVzdCBwZXJzcGVjdGl2ZSBpbiBteSBvcGluaW9uLg0KDQpB bGJyZWNodA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaWtvcyBNYXZyb2dpYW5ub3BvdWxv cw0KU2VudDogTWl0dHdvY2gsIDEzLiBKYW51YXIgMjAxNiAxMDo1NA0KVG86IFlvYXYgTmlyOyBQ ZXRlciBHdXRtYW5uDQpDYzogPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBGaXhp bmcgVExTDQoNCk9uIFR1ZSwgMjAxNi0wMS0xMiBhdCAxOToxMyArMDIwMCwgWW9hdiBOaXIgd3Jv dGU6DQo+IEhpLCBQZXRlcg0KPiANCj4gSWdub3JpbmcgZm9yIGEgbW9tZW50IHRoZSBtZXJpdHMg b2YgdGhpcyBwcm9wb3NhbCB2cyB0aGUgVExTIDEuMyAob3INCj4gMi4wKSB0aGF0IHRoaXMgV0cg aXMgd29ya2luZyBvbiByaWdodCBub3csIHdoeT8NCj4gT3RoZXIgZ3JvdXBzIGFyZSBub3Qgd29y a2luZyBvbiBIVFRQLzEuMiBvciBJS0V2MS4xIG9yIGFueSBvdGhlciANCj4gJHByb3RvY29sdiQo bWFqb3ItMSkuJChtaW5vcisxKS4NCg0KTm90ZSB0aGF0IHRoZXNlIGFyZSBub3Qgc2VjdXJpdHkg cHJvdG9jb2xzIGFuZCB0aGV5IGRvbid0IGJlbmVmaXQgZnJvbSBhIGZvcm1hbCBhbmFseXNpcyBv ZiBhIHByb3RvY29sLiBTdWNoIGFuIGFuYWx5c2lzIHRha2VzIHNldmVyYWwgeWVhcnMgdG8gYmUg ZG9uZSBhbmQgaXQgb2Z0ZW4gYXBwbGllcyB0byBzbWFsbCBwYXJ0cyBvZiB0aGUgcHJvdG9jb2wu DQpTd2l0Y2hpbmcgdG8gYSBuZXcgdmVyc2lvbiBpbnZhbGlkYXRlcyBhbGwgdGhlIGV4aXN0aW5n IGFuYWx5c2lzLg0KDQpUaGF0IGlzIG9mIGNvdXJzZSBub3QgbmVjZXNzYXJpbHkgYmFkLCBidXQg YXMgd2UgYXJlIG1vdmluZyB0b3dhcmRzIGZvcm1hbGx5IHZlcmlmaWVkIHByb3RvY29scyBpdCBp cyB2ZXJ5IGJhZCB0byBnaXZlIHRoZXNlIHR3byBvcHRpb25zOg0KMS4gU3RheSB3aXRoIGEgZm9y bWFsbHkgdmVyaWZpZWQgYnV0IHdpdGgga25vd24gdnVsbmVyYWJpbGl0aWVzIHByb3RvY29sIDIu IFN3aXRjaCB0byBhIG5ldyB1bmtub3duIHByb3RvY29sIHdoaWNoIGhhcyBub3QgYmVlbiBzdHVk aWVkIGJ5IGFzIG1hbnkgY3J5cHRvZ3JhcGhlcnMgYnV0IGlzIF9iZWxpZXZlZF8gdG8gc29sdmUg dGhlIGlzc3VlcyBmb3VuZCBpbiBUTFMuDQoNCg0KPiBBbnkgVExTIGxpYnJhcnkgdGhhdCBleGlz dHMgbm93IGRvZXNu4oCZdCBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIA0KPiBlaXRoZXIg4oCc eW91cuKAnSBUTFMgMS4zIG9yIOKAnG91cuKAnSBUTFMgMS4zLiBUbyBnZXQgZWl0aGVyLCB5b3Xi gJlsbCBuZWVkIHRvIA0KPiBnZXQgYW4gdXBncmFkZWQgdmVyc2lvbiBvZiB5b3VyIGZhdm9yaXRl IGxpYnJhcnkuIFNvIHRoZSB1cGdyYWRlIHBhdGggDQo+IGlzIG5vIHNtb290aGVyIGZvciBlaXRo ZXIgcHJvdG9jb2wuwqDCoMKgSWYgdGhpcyBoYWQgYmVlbiBicm91Z2h0IHVwIA0KPiBiZWZvcmUg dGhlIHdvcmsgb24gdGhlIGN1cnJlbnQgZHJhZnQgc3RhcnRlZCwgbWF5YmUgd2Ugd291bGQgYmUg DQo+IGNvbnZpbmNlZC4gQXMgaXQgaXMsIEkgZG9u4oCZdCBzZWUgdGhlIHBvaW50Lg0KDQpUaGUg bWFpbiBwcm9ibGVtIG9mIFRMUyAxLjIgaXMgdGhhdCBpdCBpcyB2dWxuZXJhYmxlIHRvIGNyb3Nz LXByb3RvY29sIGF0dGFja3MgYW5kIHRoZXJlIGlzIG5vIHdheSB0byBtaXRpZ2F0ZSB0aGF0LiBU aGVyZSB3YXMgc3VjaCBhbiBhdHRhY2sgZGVzY3JpYmVkIGluIDIwMTIgYW5kIGFub3RoZXIgaW4g MjAxNSBbMF0uIFdoZXRoZXIgdGhlcmUgd2lsbCBiZSBhIG5ldyBvbmUgaW4gMjAxNyBpcyBhbiBv cGVuIHF1ZXN0aW9uLiBTd2l0Y2hpbmcgdG8gYSBwcm90b2NvbCBsaWtlIFRMUyAxLjMgYXMgaXQg aXMgdG9kYXkgdG8gZml4IHRoYXQgdGhpbmcgaXQgaXMgYW4gb3ZlcmtpbGwuDQoNClRoYXQgaXMg YmVjYXVzZSBUTFMgMS4zIGlzIGEgcmV3cml0ZSBvZiB0aGUgcHJvdG9jb2wsIGFuZCByZXF1aXJl cyBhIHJld3JpdGUgb2YgdGhlIGNvZGUgYmFzZS4gR2l2ZW4gdGhhdCB0aGUgbWFqb3JpdHkgb2Yg dGhlIGlzc3VlcyBpbiBUTFMgaW1wbGVtZW50YXRpb25zIGFyZSBpbiB0aGUgY29kZSBiYXNlcyBh bmQgbm90IGluIHRoZSBwcm90b2NvbCwgaXQgaXMgdmVyeSByaXNreSB0byBzd2l0Y2ggdG8gc3Vj aCBhIG5ldyB2ZXJzaW9uIGp1c3QgbGlrZSB0aGF0LiBGb3Igb2xkIHN5c3RlbXMgaXQgbW9zdCBs aWtlbHkgd2lsbCBuZXZlciBoYXBwZW4gYW5kIHRoZXkgd2lsbCByZW1haW4gdnVsbmVyYWJsZS4N Cg0KWzBdLsKgaHR0cHM6Ly93ZWFrZGgub3JnL2ltcGVyZmVjdC1mb3J3YXJkLXNlY3JlY3ktY2Nz MTUucGRmDQoNCnJlZ2FyZHMsDQpOaWtvcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From nobody Wed Jan 13 03:01:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305141A6F52 for ; Wed, 13 Jan 2016 03:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPd0RGbboCD5 for ; Wed, 13 Jan 2016 03:01:12 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F30DF1A6F49 for ; Wed, 13 Jan 2016 03:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1452682870; d=isode.com; s=selector; i=@isode.com; bh=1CJM2XYYlR684STh5LgyyrDcrBgAD3kmEC3TGbIm+dc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=l72zW3ShAsPPAIwOUuSzqDEyzLX2Emn+zWcSbnB3Dz7Hk67PZ/9jKPfrW41iFD1zndY/wy b6NMmfuuE6FcdgsMBm4cXy26coPOO2QvEsYMBkMNaIiAWedwnX1qzLQt4wExnkUkWzXojG jAt2oRLD17D3bbssTAAwtauMAuAUfXM=; Received: from [172.22.50.30] ((unknown) [62.232.206.186]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 13 Jan 2016 11:01:10 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13C75) In-Reply-To: <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 13 Jan 2016 11:04:37 +0000 Message-Id: References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara , Simon Josefsson MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 11:01:14 -0000 > On 12 Jan 2016, at 21:31, Ilari Liusvaara wrote= : >=20 >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: >>=20 >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote:= >>>=20 >>> The same concern still applies: what does it mean to allocate code >>> point for the 4492bis-05 description? >>=20 >> Allocating code points just means an implementation of draft-05 is >> likely to interoperate just fine with an implementation of the final >> RFC. >>=20 >> Of course nothing is ever final until the RFC is out, so there=92s >> always a risk involved, but it is considered prudent to allocate >> numbers when we=92re reasonably certain of the calculations and on- >> the-wire formats. Any debate about whether we should or should not >> check certain inputs for certain conditions need not be a bar for >> allocating numbers. >=20 > Assuming CFRG chairs really did declare consensus on Ed448 hash, then > the final characteristics of Ed448 are known and I have a reference > implementation. >=20 > And the PKIX draft looks implementable (has wrong example?) >=20 > More serious interop hazard is what to do with X25519/X448 and THS > (some of the proposed stuff is not wire-compatible). This CFRG co-chair would like to see an updated CFRG draft before the code p= oint is allocated. From nobody Wed Jan 13 03:44:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACB21A86DD for ; Wed, 13 Jan 2016 03:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7Dy9zxesU1T for ; Wed, 13 Jan 2016 03:44:32 -0800 (PST) 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 551C81A7D84 for ; Wed, 13 Jan 2016 03:44:32 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A985AC09FA8F for ; Wed, 13 Jan 2016 11:44:31 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DBiU41022602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jan 2016 06:44:31 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jan 2016 12:44:24 +0100 Message-ID: <2188470.QJNceayIVJ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <201601121514.14360.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <201601121514.14360.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14530835.UFk19S31L8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 11:44:33 -0000 --nextPart14530835.UFk19S31L8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 12 January 2016 15:14:13 Dave Garrett wrote: > On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote: > > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote: > > > I hope that Google's efforts to get QUIC as-is specced out go > > > quickly and smoothly, and that it can be used as a basis to > > > develop an official total TCP/TLS replacement.>=20 > > If this were the path forward (and I doubt that it is), I would ver= y > > much prefer Peter Gutman's evolutionary TLS 1.3. > I was just chatting a bit off-list, and apparently I wasn't aware of > QUIC's latest plans, so it's not as clear as I previously said. > Unfortunately, it seems that they have yet to actually write anything= > down (a too frequent pattern with QUIC), so I can't really comment on= > what I'd like to see happen in this realm anymore. >=20 > In any case, ~whatever~ comes after TLS 1.3 will hopefully have some > major changes. I have no idea what that will be, but TLS 1.3 comes > first. That's a discussion for a future time. I remember this one quote, not sure who is it attributed to, but it goe= s=20 something like this: "I don't know what will replace Ethernet, but I'm sure it also will be=20= called Ethernet" =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 99/71, 612 45, Brno, Czech Republi= c --nextPart14530835.UFk19S31L8 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 iQIcBAABCgAGBQJWljiYAAoJEJKo0bgB0vX1tVAP/iqiZ3ZMU+MRvHqrVYXfT09p Zxs4+h20ohR/+gcQhGqilhR84KFaO146CPRkl0Zb1ZqpwOOBXtbK7I09IDRYYlJJ hfI9MO8ZWhGVVPT7LSn4X7P6njGOIcDBf0W2NZokCVizk6MxinFWEWZn0hp+zQuk p37OTohikLHPhj+E+HIF0IHHRowRtT2jJxUIS5IAgDL/TNiHA7/ktnrNUredE4CD zGg9xHBSNaNb9Vc1BpGDe1r9i+9Cf/dV7kW0oVFmp+TC2awpDaeeef8AMbyl3QW/ 7vhrWtLJ9NkSiqFy1/hUoacq/29eKFFAbX08Uk+OOBzG3PlVv/0GjuF/A02L78Za yk8Yvo3ogxmgP+rwFj1YlcTUn+gHyBLeJWaOzZowte8VuGs5GfBoAI3ah+JNlJFm YfW6/DFbqpUqMNMaJTEs3DQYyOrlLhJe2toeKlxy3y2A9f81ZF4ps4Tu/5zK+dDa TIR4PowObpU+GfhdVj0hSqFOZ6bQ8qwbOYG5JI8K+9ahqfcAbSRiGStEkixHAkUA mjLSgzimgO1fVuIqX0nDQtIn1WdqzMaUJCo19KsCFSicNRGcRYSlmgBMumD/AFmr 2zXA67MqlbdRv8Xt8rP1vQJ0hBCjp5n+dnFsspQR0nKwtMp867RMn42y9Xx91rr4 0El1gDg9661RwCnkxDXb =1s9T -----END PGP SIGNATURE----- --nextPart14530835.UFk19S31L8-- From nobody Wed Jan 13 03:52:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8CF1A8702 for ; Wed, 13 Jan 2016 03:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP__RshmIeT3 for ; Wed, 13 Jan 2016 03:52:30 -0800 (PST) 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 E1C921A8701 for ; Wed, 13 Jan 2016 03:52:29 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id ADF698F4E9; Wed, 13 Jan 2016 11:52:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DBqStH008949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 06:52:29 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jan 2016 12:52:27 +0100 Message-ID: <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2295283.bFljbMyDS6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 11:52:31 -0000 --nextPart2295283.bFljbMyDS6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann >=20 > wrote: > > Yoav Nir writes: > > To expand on this, I'll take Ilari Liusvaara's comments: > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is > >>over 10 years old. The basic framework for doing 0-RTT is the > >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, > >>which is just 5 years old. > >> > >>So I don't see anything "experimential" ideas, mechanisms or > >>algorithms in there > >> > > When SSLv3 was introduced, it also used ideas that were 10-20 years= > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They were > > mature algorithms, lots of research had been published on them, and= > > yet we're still fixing issues with them 20 years later (DH =3D 1976= , > > SSLv3 =3D 1996, Logjam =3D 2015). > We all understand that the security of a protocol is not a function > not of the primitives but of the way the protocol works. The confusio= n > between export and nonexport DH shares was noted almost immediately > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a= > discovery in 2015, given that the reasons for this were all worked > out in the early 90's. So no, Logjam is not a result of unknown > issues appearing after 20 years, but ignoring known issues. >=20 > > TLS 2.0-called-1.3 will roll back the 20 years of experience we hav= e > > with all the things that can go wrong and start again from scratch.= > > SIGMA, at ten years old, is a relative newcomer to DH's 20 years > > when it was used in SSLv3, but in either case we didn't discover > > all the problems with it until after the protocol that used it was > > rolled out. We currently have zero implementation and deployment > > experience with 2.0-called-1.3 [0], which means we're likely to > > have another 10-20 years of patching holes ahead of us. This is > > what I meant by "experimental, bleeding-edge". >=20 > There is an old joke about the resume with one years experience > repeated 20 times. All of the problems in TLS have been known for > decades, as I've repeatedly demonstrated on this list. All of them > were known to cryptographers at the time TLS was being designed and > deployed. It does not take deployment to trigger analysis. Exactly this: BEAST and Lucky 13 "possible" problem was described in th= e=20 RFC itself. Same thing for the "new" Bicycle attack - described in the=20= RFC for TLS 1.0 and repeated in each version since. So lets not repeat those mistakes - if there are possible issues, lets=20= fix those, now. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2295283.bFljbMyDS6 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 iQIcBAABCgAGBQJWljp7AAoJEJKo0bgB0vX1nQcP/jF6d/SYitfok1Pm1mC4z9iz 8ZUc8Wxu9kFgTYLBJZZrhmoyYG5CQ/zt8OFJW3Kgplsjvo0u1FE3U836GjF51f49 VzKTZvfHwWKdyGZXSQRRBMkIBOU8bFkJ35CDaHHocRjhAyoO9BK05edCEcO+wCvR F1ivJ9onHX6np/Vp5vo3h987+as93zGD4GV/PzKC5/fIHgcHC3Mz/bDxhGg0iC31 W4t7zlYTjjX+0aVek/9pOga7tWQpb8qYnsn0JpxTiOuYsHLxUBkfMIxGZxzttYQl 7BRAKLpOVdwH9k288sqJuXsuN988UVO5rjtGI+0N1sQyc41ThtjEyC2xfTaCmP+v C/jWk38Id4ujyAMlkSIUgyXl9762kT/3hJziHNh5JMZiiuoJIGX1NCWsc0jrZUGH sy+qDactknPp+gLgtxWsg05DqdFpHSZSNK8X9pNAn7s6DA4d10zO/5H8dOdfkG7h MD8ymMi5ApUIMkj8xjqxCLKCoHO8NjcXTYROI/9j9gFkLKYbfAHDh2Ux8uDdZa4+ 9EQ1WlV2dKvtJ8x8z4dCkVpjYPIaJY7U1wBjapRvJJcagxz+XU2pTW2J6SIamlBb brllhvz6qnSlaInmMETVgfNH1oGVscLrapNE7R2LJW9KfDd1d1NnIlks5fhwxEoS kc4IO24C3XLeBUDrVACM =qu3c -----END PGP SIGNATURE----- --nextPart2295283.bFljbMyDS6-- From nobody Wed Jan 13 04:11:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9BB1A88A0 for ; Wed, 13 Jan 2016 04:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeGdhZnP-F_c for ; Wed, 13 Jan 2016 04:11:49 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 469551A8897 for ; Wed, 13 Jan 2016 04:11:49 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id h129so58759765lfh.3 for ; Wed, 13 Jan 2016 04:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CkgJORAewg+Tt/QJUPMcPVpUAxD/g7l6tBd7Pnu3Mv4=; b=VY3fsIzZFRaKzlrUfsA3cOH5BqAxJrQC9/IUFmNkELzTh4AFXGNmV51RxnA6oLq3fz VLkSAroxZMGduAa7oQxGw5oqDyWkPMge+tTOX89oeQfCZ/4oVo3aEzGG1YEpVcF+hs8v s7sdqM3QHjnk9VlqsbIwXwMjS1ALQFs9J+Jgm54ZDZfgYok0ix5M5b9Q+7ef9fnD8RwK r/ggDy4n4cvNk4MCjUypN8qIaWsSgbma32sH+sG/3D7yqtgnUP7na4KR6zcfnUiuP+U+ 6xN5WoZiV2RxYjfCOLX9/Htek50CpUaGPBnkJBZxzA5Bl32Gz24c4CkCaVdILNy57z6k S0vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CkgJORAewg+Tt/QJUPMcPVpUAxD/g7l6tBd7Pnu3Mv4=; b=KCsJ/1Iw3z4hMsphNepZfwg/MGiPcMX+fwmt42c4tsCG9r5pP6o9AIBdsHg321rPoP BIS+b3fRMpPhLpmR6ng4wGnybi/egGyqd1aD2u0dcxllSI/HlOz9uGDcT3HpYmBHyCv4 BLmMyF51NxFiu57C8qn/p6was4xTc2ZyS1Yp5LZDuaEhDvBAXoJQPqk5bYVkyg+UTwlf +ogKVyV0K0DJbhbDgWzQIM4mCTQmCAMWn8/yzXVG/c3hc3CO+CIM3yrhuFX763IbpU6j kgonvoLVxrNdQOulvXE61KgXRVJXQCq63sKmggA3PUY9zEIQC73TH1BP9rrj79dVvNfS aVAg== X-Gm-Message-State: ALoCoQkdSyAh+A3PmZ3rVP4+oaRRJkY50pljvR9S8tk7oudiU9x++10c8AyM487PO/58+h3faiLe6RuEue8uaqUTydeODiZOEg== MIME-Version: 1.0 X-Received: by 10.25.206.143 with SMTP id e137mr30464863lfg.97.1452687107407; Wed, 13 Jan 2016 04:11:47 -0800 (PST) Received: by 10.25.196.83 with HTTP; Wed, 13 Jan 2016 04:11:47 -0800 (PST) In-Reply-To: <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> Date: Wed, 13 Jan 2016 15:11:47 +0300 Message-ID: From: Dmitry Belyavsky To: Hubert Kario Content-Type: multipart/alternative; boundary=001a1141225a01cb5505293613ba Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:11:52 -0000 --001a1141225a01cb5505293613ba Content-Type: text/plain; charset=UTF-8 Hello Hubert, On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario wrote: > On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > > > wrote: > > > Yoav Nir writes: > > > To expand on this, I'll take Ilari Liusvaara's comments: > > >>Bleeding edge ideas? They essentially re-invented SIGMA, which is > > >>over 10 years old. The basic framework for doing 0-RTT is the > > >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF, > > >>which is just 5 years old. > > >> > > >>So I don't see anything "experimential" ideas, mechanisms or > > >>algorithms in there > > >> > > > When SSLv3 was introduced, it also used ideas that were 10-20 years > > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They were > > > mature algorithms, lots of research had been published on them, and > > > yet we're still fixing issues with them 20 years later (DH = 1976, > > > SSLv3 = 1996, Logjam = 2015). > > We all understand that the security of a protocol is not a function > > not of the primitives but of the way the protocol works. The confusion > > between export and nonexport DH shares was noted almost immediately > > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a > > discovery in 2015, given that the reasons for this were all worked > > out in the early 90's. So no, Logjam is not a result of unknown > > issues appearing after 20 years, but ignoring known issues. > > > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we have > > > with all the things that can go wrong and start again from scratch. > > > SIGMA, at ten years old, is a relative newcomer to DH's 20 years > > > when it was used in SSLv3, but in either case we didn't discover > > > all the problems with it until after the protocol that used it was > > > rolled out. We currently have zero implementation and deployment > > > experience with 2.0-called-1.3 [0], which means we're likely to > > > have another 10-20 years of patching holes ahead of us. This is > > > what I meant by "experimental, bleeding-edge". > > > > There is an old joke about the resume with one years experience > > repeated 20 times. All of the problems in TLS have been known for > > decades, as I've repeatedly demonstrated on this list. All of them > > were known to cryptographers at the time TLS was being designed and > > deployed. It does not take deployment to trigger analysis. > > Exactly this: BEAST and Lucky 13 "possible" problem was described in the > RFC itself. Same thing for the "new" Bicycle attack - described in the > RFC for TLS 1.0 and repeated in each version since. > > So lets not repeat those mistakes - if there are possible issues, lets > fix those, now. > But we should leave the description of the fixed problems somewhere to avoid them in future. --001a1141225a01cb5505293613ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Hubert,

On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario <hkario@red= hat.com> wrote:
On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
>
> <pgut001@cs.auckland.a= c.nz> wrote:
> > Yoav Nir <ynir.ietf@gma= il.com> writes:
> > To expand on this, I'll take Il= ari Liusvaara's comments:
> >>Bleeding edge ideas? They essentially re-invented SIGMA, which= is
> >>over 10 years old. The basic framework for doing 0-RTT is the<= br> > >>obvious one. The only new algorithm prsent since TLS 1.2 is HK= DF,
> >>which is just 5 years old.
> >>
> >>So I don't see anything "experimential" ideas, m= echanisms or
> >>algorithms in there
> >>
> > When SSLv3 was introduced, it also used ideas that were 10-20 yea= rs
> > old (DH, RSA, DES, etc, only SHA-1 was relatively new).=C2=A0 The= y were
> > mature algorithms, lots of research had been published on them, a= nd
> > yet we're still fixing issues with them 20 years later (DH = =3D 1976,
> > SSLv3 =3D 1996, Logjam =3D 2015).
> We all understand that the security of a protocol is not a function > not of the primitives but of the way the protocol works. The confusion=
> between export and nonexport DH shares was noted almost immediately > in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this i= s a
> discovery in 2015, given that the reasons for this were all worked
> out in the early 90's. So no, Logjam is not a result of unknown > issues appearing after 20 years, but ignoring known issues.
>
> > TLS 2.0-called-1.3 will roll back the 20 years of experience we h= ave
> > with all the things that can go wrong and start again from scratc= h.
> >=C2=A0 SIGMA, at ten years old, is a relative newcomer to DH's= 20 years
> > when it was used in SSLv3, but in either case we didn't disco= ver
> > all the problems with it until after the protocol that used it wa= s
> > rolled out.=C2=A0 We currently have zero implementation and deplo= yment
> > experience with 2.0-called-1.3 [0], which means we're likely = to
> > have another 10-20 years of patching holes ahead of us.=C2=A0 Thi= s is
> > what I meant by "experimental, bleeding-edge".
>
> There is an old joke about the resume with one years experience
> repeated 20 times. All of the problems in TLS have been known for
> decades, as I've repeatedly demonstrated on this list. All of them=
> were known to cryptographers at the time TLS was being designed and > deployed. It does not take deployment to trigger analysis.

Exactly this: BEAST and Lucky 13 "possible" problem w= as described in the
RFC itself. Same thing for the "new" Bicycle attack - described i= n the
RFC for TLS 1.0 and repeated in each version since.

So lets not repeat those mistakes - if there are possible issues, lets
fix those, now.

But we should leave the= description of the fixed problems somewhere to avoid them in future.

--001a1141225a01cb5505293613ba-- From nobody Wed Jan 13 04:14:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1E01ACD63 for ; Wed, 13 Jan 2016 04:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpso5GCww5-v for ; Wed, 13 Jan 2016 04:14:50 -0800 (PST) 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 C57E91A898C for ; Wed, 13 Jan 2016 04:14:50 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 83D8DC0BF2AF; Wed, 13 Jan 2016 12:14:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DCEmti026760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 07:14:50 -0500 From: Hubert Kario To: Dmitry Belyavsky Date: Wed, 13 Jan 2016 13:14:48 +0100 Message-ID: <1591617.U2JlsF4Qh1@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3930162.DYRtC3veHI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:14:52 -0000 --nextPart3930162.DYRtC3veHI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 January 2016 15:11:47 Dmitry Belyavsky wrote: > Hello Hubert, >=20 > On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario =20 wrote: > > On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote: > > > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann > > >=20 > > > wrote: > > > > Yoav Nir writes: > > > >=20 > > > > To expand on this, I'll take Ilari Liusvaara's comments: > > > >>Bleeding edge ideas? They essentially re-invented SIGMA, which > > > >>is > > > >>over 10 years old. The basic framework for doing 0-RTT is the > > > >>obvious one. The only new algorithm prsent since TLS 1.2 is > > > >>HKDF, > > > >>which is just 5 years old. > > > >> > > > >>So I don't see anything "experimential" ideas, mechanisms or > > > >>algorithms in there > > > >> > > > > When SSLv3 was introduced, it also used ideas that were 10-20 > > > > years > > > > old (DH, RSA, DES, etc, only SHA-1 was relatively new). They > > > > were > > > > mature algorithms, lots of research had been published on them,= > > > > and > > > > yet we're still fixing issues with them 20 years later (DH =3D > > > > 1976, > > > > SSLv3 =3D 1996, Logjam =3D 2015). > > >=20 > > > We all understand that the security of a protocol is not a > > > function > > > not of the primitives but of the way the protocol works. The > > > confusion between export and nonexport DH shares was noted almost= > > > immediately in SSLv3. Furthermore, 512 bit DH is weak: I don't > > > know how this is a discovery in 2015, given that the reasons for > > > this were all worked out in the early 90's. So no, Logjam is not > > > a result of unknown issues appearing after 20 years, but ignoring= > > > known issues. > > >=20 > > > > TLS 2.0-called-1.3 will roll back the 20 years of experience we= > > > > have > > > > with all the things that can go wrong and start again from > > > > scratch. > > > >=20 > > > > SIGMA, at ten years old, is a relative newcomer to DH's 20 > > > > years > > > >=20 > > > > when it was used in SSLv3, but in either case we didn't discove= r > > > > all the problems with it until after the protocol that used it > > > > was > > > > rolled out. We currently have zero implementation and > > > > deployment > > > > experience with 2.0-called-1.3 [0], which means we're likely to= > > > > have another 10-20 years of patching holes ahead of us. This i= s > > > > what I meant by "experimental, bleeding-edge". > > >=20 > > > There is an old joke about the resume with one years experience > > > repeated 20 times. All of the problems in TLS have been known for= > > > decades, as I've repeatedly demonstrated on this list. All of the= m > > > were known to cryptographers at the time TLS was being designed > > > and > > > deployed. It does not take deployment to trigger analysis. > >=20 > > Exactly this: BEAST and Lucky 13 "possible" problem was described i= n > > the RFC itself. Same thing for the "new" Bicycle attack - described= > > in the RFC for TLS 1.0 and repeated in each version since. > >=20 > > So lets not repeat those mistakes - if there are possible issues, > > lets fix those, now. >=20 > But we should leave the description of the fixed problems somewhere t= o > avoid them in future. yes, decisions and recommendations should have rationale attached to=20= them. And especially for recommendations, I don't see why we couldn't=20= incorporate them in the RFC - at least for one, if the rationale is=20 proven wrong it will be easier to explain why the recommendation should= =20 be disregarded. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart3930162.DYRtC3veHI 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 iQIcBAABCgAGBQJWlj+4AAoJEJKo0bgB0vX1w0wP/14dTIk9X4nksWIP9BxquWT5 bMrkTHxzJeQnVrPmILz3A1EAhNgDSUvynouwllBf61h4Bm2gcC6XJSTnfnKjqKNT egE2Js5Aotjc7iwFbSns8OG+ezEhP5wtTqoi46UqgKG2f71DO4YzDrgqS43uZ7Sn oLF9J/2lD43APvGc9WZUepNfaxsDO2laE2A15drtxTNLyVLtXNeEaT9S7b6ZHxEe 4hCyum2+St2OIanis6f3y8tSfKSLfKRJd+Kp4Wdia2T0D5rlN+0k8dDtGoeReWqc HOpQsXn6Hhxv56hLTfNgvyJ4+go5fzt+fTaBLiNoq2HjtG+BhRCrk6BokTCEpUfc 9QsMLs4oZg/WeYEAQRqz/CXcrKiVz2fSYyzMei1JrA5rBaxRFuYFqqIBkn8J3/XB kGJ6vQvggFEagPVNcAKQoivQ10s96hFGwb5MQjbCi1914hf0CELWrW84vV9UxfWC Au2yBuwSaV7UnRbT0zC4shcXyfxzoJuPWKECugypsNQEVUGMA03urGEYS6XR46TS HFH9CwZ2jWoM6uMnpv1r2Qz10dXrNZWAwDr502HbyfcZSDuW2ApA/2yDW5NYAVGW rlvgu0zWEuM0vohJ/GmxLfewK1wmUflEv4GoNFJfJ9s7OsWk0r6x9pL6MIqrIXtb fG13Yjyvchg4ccWFN81f =SbFP -----END PGP SIGNATURE----- --nextPart3930162.DYRtC3veHI-- From nobody Wed Jan 13 04:32:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA161A6F99 for ; Wed, 13 Jan 2016 04:32:13 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPSXQuAi-afM for ; Wed, 13 Jan 2016 04:32:08 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF071ACD9F for ; Wed, 13 Jan 2016 04:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452688329; x=1484224329; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HKM1pZV0o1cxs1AOD2/5Vt6txRPm1czZwdiTj40uuEk=; b=S7gkbHWpNkboKskpbqac/GX56QJ4hfOocuFJXahKNMmLz7z76HUn4M/K n/QS3QgCkpwF+mK+9w682lXKMNeP0PzEd36reHQJJcfTOqkN76uFlWvSF 8pzQJ267iRCRPYHb413Y4p+Bu2VbGY/y1MPmwqW/uZAHyqDzA+5wl48sD kqMT1dSLCKWkpfuKrFGtEpisVpqpEvvK8dgb0Ewj+dsKAaQPqshUCfR3K Fik8ccD6lTc4dxgtNct/dfX+WYgJuYrnELTQrwnnNjdyqEQI62UCbRJdn eBPj+N9R70CGkIMIBSFuYhID5hK0U11IKXqKqU8A6DtuC8y5SUK52us8/ A==; X-IronPort-AV: E=Sophos;i="5.22,288,1449486000"; d="scan'208";a="62935061" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jan 2016 01:32:06 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Thu, 14 Jan 2016 01:32:05 +1300 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzf//Ww+AgAFZaKb//zG9AIAArXmAgADjpcM= Date: Wed, 13 Jan 2016 12:32:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> , <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> In-Reply-To: <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:32:13 -0000 Hubert Kario writes:=0A= =0A= >So lets not repeat those mistakes=0A= =0A= Exactly, there are more than enough new ones for 2.0-called-1.3 to make tha= t=0A= we don't (necessarily) have to repeat existing ones (although I'm sure we w= ill=0A= in some cases).=0A= =0A= And that's exactly my point, we're throwing away 20 years of refining TLS 1= .x=0A= and more or less starting again with 2.0-called-1.3, with a whole new set o= f=0A= mistakes to make. I really don't want to spend the next 20 years patching = all=0A= the holes that will be found in 2.0-called-1.3, I've already had enough of= =0A= that for the 1.x version.=0A= =0A= TLS needs an LTS version that you can just push out and leave to its own=0A= devices, for the same reason that other products also have LTS versions, th= at=0A= lots of people have better things to do with their life than playing bugfix= =0A= whack-a-mole for the duration of it.=0A= =0A= Peter.= From nobody Wed Jan 13 04:44:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565E01ACDC2 for ; Wed, 13 Jan 2016 04:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M23ps722E01Y for ; Wed, 13 Jan 2016 04:44:28 -0800 (PST) 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 CAE4E1ACDC0 for ; Wed, 13 Jan 2016 04:44:28 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 744D78E257; Wed, 13 Jan 2016 12:44:28 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DCiQD2009556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 07:44:28 -0500 From: Hubert Kario To: Peter Gutmann Date: Wed, 13 Jan 2016 13:44:26 +0100 Message-ID: <4202504.P0SWC7onAW@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2252725.GHKkY8NAg0"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 12:44:30 -0000 --nextPart2252725.GHKkY8NAg0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 January 2016 12:32:05 Peter Gutmann wrote: > Hubert Kario writes: > >So lets not repeat those mistakes >=20 > Exactly, there are more than enough new ones for 2.0-called-1.3 to > make that we don't (necessarily) have to repeat existing ones > (although I'm sure we will in some cases). >=20 > And that's exactly my point, we're throwing away 20 years of refining= > TLS 1.x and more or less starting again with 2.0-called-1.3, with a > whole new set of mistakes to make. I really don't want to spend the > next 20 years patching all the holes that will be found in > 2.0-called-1.3, I've already had enough of that for the 1.x version. The only thing I saw in the "TLS 1.2.1" proposal that isn't already=20 available is the longer Finished hash and a new signature type.=20 Something that an extension can easily fix, rest is just a matter of=20= setting a policy *and following it* with respect to used extensions and= =20 settings. If you want to patch it up like this, please do. But TLS 1.3 fixes more= =20 problems. > TLS needs an LTS version that you can just push out and leave to its > own devices, for the same reason that other products also have LTS > versions, that lots of people have better things to do with their > life than playing bugfix whack-a-mole for the duration of it. You're asking for impossible. The problems mentioned were not introduce= d=20 into the protocols intentionally to make them obsolete, they are there=20= because they weren't seen as big enough to fix. That's the mistake I sa= y=20 we should not repeat - "no issue left behind, no matter how small". =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2252725.GHKkY8NAg0 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 iQIcBAABCgAGBQJWlkaqAAoJEJKo0bgB0vX1eyUP/3nZ2kVBhITej3bP7tePH8Cm 8CHFnecFAGT/804X69+yri/2Xm4VzrIsyfo20w+pgHVGt9DMWMhe1dfYEgTq07oX 90fFcf7GFhm4mxfOGnUBYZvjdUhmF2k2seGXxmKmJyijJuJtcv7NZ0CLyU+ptQ7I mnbptGrZVuxR1XzWkeNwqmQ9MS9Dos13EOCl2yPaG89TChWEmgG4AYLEKONztVJJ 5zVCub7cp60MOTA8utX29FVKFi85JnlQpwwJRJOqJdGyxEo1ngvhyo+I4Nf89Q5l 3KAhMCFwyAtath9u9si6Q1F2kfRsJb7t7yIbkac27JGNaM1hKqKgUs//ydViO2ZH fLV6Xu0VRgN0Lmahst88mZIeu6LLf4pZqf9hdzhX7hiLNDVlVtePzEhAT6B1tGao zEjZVmjhsvWw1OIP9lu9qbMv8K+XsrhNqU6JIoX3Gw5cJ276ALPFhl6PJCwTG2nG QvcoUVu4gG5clDpT2t+c1HRV8c4Jp1chsdHERhEibKczc2eBHPyw/Ogk7qSJuT5x JRBxYuiacj71opPH1CRl2+U7tWEhAL8BB6Z6DUf2tZK6Sy6YaAetQmr1t/G4nSnD 4Dlio2MG09e7QA+qZqSWdOpoRp1Bs5/coRs0PiVwNORJzRTSOUAEU1zG4mntA47+ 5Mvx+HMBB9nCRynJZrl5 =YHkW -----END PGP SIGNATURE----- --nextPart2252725.GHKkY8NAg0-- From nobody Wed Jan 13 05:16:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBD01ACE14 for ; Wed, 13 Jan 2016 05:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2FlRx1YenM3 for ; Wed, 13 Jan 2016 05:16:34 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 78D561ACD57 for ; Wed, 13 Jan 2016 05:16:34 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D6AED16CA75; Wed, 13 Jan 2016 13:16:33 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C0DC016CA1A; Wed, 13 Jan 2016 13:16:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452690993; bh=WzeybjlwgjRStAKm0o5/+qBJWH6199zVKXEitaFnq7g=; l=174; h=From:To:Date:References:In-Reply-To:From; b=YNb8k/tQ1kwge3oFkGXsK8eEqdZVJbh1/MOSoQ2oQsEZifKhFh6ZNgEUaoigToJRn ayqmGRniE0pmB+3Oxv+vnRtm4MGvC5PJu7nokj5iS4ajwPhWM3e0bGf4tWY1X450KK TuK1X1x+jR4J8R/pbtBWCsR0o4sHL/k8qsn/7CDY= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 9D9EF98082; Wed, 13 Jan 2016 13:16:33 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 13 Jan 2016 05:16:32 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 13 Jan 2016 08:16:33 -0500 From: "Salz, Rich" To: Peter Gutmann , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzQARGeWAABC3dwAAAK0nAAAVryGAAAFiWoAACPG4oA== Date: Wed, 13 Jan 2016 13:16:32 +0000 Message-ID: <94395a3c029c493eb491eb3db90e3ed1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> , <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.81] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 13:16:35 -0000 > TLS needs an LTS version that you can just push out and leave to its own > devices So don't you have that with TLS 1.1 and appropriate cipher and option choic= es? From nobody Wed Jan 13 05:48:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970671B2DC3 for ; Wed, 13 Jan 2016 05:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNlSqPQI9Noj for ; Wed, 13 Jan 2016 05:48:40 -0800 (PST) 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 4D6301B2DC1 for ; Wed, 13 Jan 2016 05:48:40 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 56AE4448AB; Wed, 13 Jan 2016 14:48:38 +0100 (CET) X-purgate-ID: 152705::1452692918-00006F99-3AC1C1C2/0/0 X-purgate-size: 675 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 0074140872; Wed, 13 Jan 2016 14:48:36 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D12071A3E8; Wed, 13 Jan 2016 14:48:36 +0100 (CET) In-Reply-To: <94395a3c029c493eb491eb3db90e3ed1@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Date: Wed, 13 Jan 2016 14:48:36 +0100 (CET) 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: <20160113134836.D12071A3E8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Jan 2016 13:48:42 -0000 Salz, Rich wrote: > >> TLS needs an LTS version that you can just push out and leave to its own >> devices > > So don't you have that with TLS 1.1 and appropriate cipher and option choices? Actually, you already have that with TLSv1.0 plus the known mitigations. The only cryptographical improvement of TLSv1.1 over TLSv1.0 can be sufficiently achieved with 1+(n-1) record splitting -- for those few situations where this difference is meaningful at all. Only web-browsers that will happily execute any attacker supplied active-content plus the abuse of SSL known as SSL-VPNs need the record-splitting mitigation for block-ciphers in TLSv1.0. -Martin From nobody Wed Jan 13 08:40:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9993E1B2F05 for ; Wed, 13 Jan 2016 08:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 fjx3nlw4_T0H for ; Wed, 13 Jan 2016 08:40:32 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 8E9091B2AE7 for ; Wed, 13 Jan 2016 08:40:31 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id 17so56842226lfz.1 for ; Wed, 13 Jan 2016 08:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SW2CslKoSowJLB5VL66j6/8tnNfLHuPPT9vLeDULmVw=; b=hoFtknzr1VlEJt5ON3yoqYwaHtrvITv6OZ2Bk4j4+9jk9dtAOCECMCFhO4y2c1+hGn 5XDeOW838Orvco7sEWM404jNiZjfd4/eEozkWLZSDYDqU3TJLYsNmtXHM7hfh2DytsHA 5IJssJ5SKranP1QzOr+LnryWpgRoz9RB19DR3Qv63FDdUDrVefEXrViH1JxdCymIGXut /nvwU2Pz2YliAU6p149V0V7Ar9IhFaHXKDmLeeLwocyQreN8JKd/vDg7h0mVdHFD/xeB n64vsnAb+m5FU+VmOme1jibCjxaKbTk8ZgzlndAmUQbw6y6DohTVilKnH9AaiYuNWz4K 67nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SW2CslKoSowJLB5VL66j6/8tnNfLHuPPT9vLeDULmVw=; b=hDATazWdUBhWkjBpJnhzqVQG2g/N3ngtMTLr58wt/5pGkzoEc5VzVzE27YMwd0cuj/ eHo/Q7VktB+ovGanig5/ddPTWwFaxjL8oGhUFP5oG/8mczu2kZBi0+1D9I1gXTVtd/eN Ly1WTeBvDluoRITbZqcefBoHihQWFgFZC6umG8U1dgovZN6lpo7QxmmfdCpBboA1hLjY AHgjLUNw7v3Rm07g+A60hQDtPXHFPnpjAqqLCT1OepKhAxnaq32NwqA2kNMHd3++AQsR ARATtaPOVpd78NS5q2dBe2SDa1OlNN0ixhdt96mGdMdDxcC4aGQfCAZVP8Pq7AM84I4U VK2w== X-Gm-Message-State: ALoCoQmYn2ZNkg18c1ko2AdtpT4piZlVCaiJqV8wTCAnm9JN7LB1zeT0GENJYkLvu0N1m9y1Lu8bnomudhbtJU7VSxpopbaPWA== MIME-Version: 1.0 X-Received: by 10.25.168.133 with SMTP id r127mr26979638lfe.134.1452703229494; Wed, 13 Jan 2016 08:40:29 -0800 (PST) Received: by 10.112.2.104 with HTTP; Wed, 13 Jan 2016 08:40:29 -0800 (PST) In-Reply-To: References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 13 Jan 2016 08:40:29 -0800 Message-ID: From: Joseph Salowey To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11401a16f5615d052939d384 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:40:33 -0000 --001a11401a16f5615d052939d384 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, Looks like I jumped too soon on this one. In particular, both the CFRG signature draft and 4492bis need to be updated. Let's hold of on code point assignment until then. Thanks, Joe (crawling back under my rock now) On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov wrote: > > > On 12 Jan 2016, at 21:31, Ilari Liusvaara > wrote: > > > >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > >> > >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson > wrote: > >>> > >>> The same concern still applies: what does it mean to allocate code > >>> point for the 4492bis-05 description? > >> > >> Allocating code points just means an implementation of draft-05 is > >> likely to interoperate just fine with an implementation of the final > >> RFC. > >> > >> Of course nothing is ever final until the RFC is out, so there=E2=80= =99s > >> always a risk involved, but it is considered prudent to allocate > >> numbers when we=E2=80=99re reasonably certain of the calculations and = on- > >> the-wire formats. Any debate about whether we should or should not > >> check certain inputs for certain conditions need not be a bar for > >> allocating numbers. > > > > Assuming CFRG chairs really did declare consensus on Ed448 hash, then > > the final characteristics of Ed448 are known and I have a reference > > implementation. > > > > And the PKIX draft looks implementable (has wrong example?) > > > > More serious interop hazard is what to do with X25519/X448 and THS > > (some of the proposed stuff is not wire-compatible). > > This CFRG co-chair would like to see an updated CFRG draft before the cod= e > point is allocated. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11401a16f5615d052939d384 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,=C2=A0

Looks like I jumped too s= oon on this one.=C2=A0 In particular, both the CFRG signature draft and 449= 2bis need to be updated.=C2=A0 Let's hold of on code point assignment u= ntil then. =C2=A0

Thanks,

Joe
(crawling back under my rock now)=C2=A0

On Wed, Jan 13, 2016 at 3:= 04 AM, Alexey Melnikov <alexey.melnikov@isode.com> w= rote:

> On 12 Jan 2016, at 21:31, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
>> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
>>
>>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson <simon@josefsson.org> wrote:
>>>
>>> The same concern still applies: what does it mean to allocate = code
>>> point for the 4492bis-05 description?
>>
>> Allocating code points just means an implementation of draft-05 is=
>> likely to interoperate just fine with an implementation of the fin= al
>> RFC.
>>
>> Of course nothing is ever final until the RFC is out, so there=E2= =80=99s
>> always a risk involved, but it is considered prudent to allocate >> numbers when we=E2=80=99re reasonably certain of the calculations = and on-
>> the-wire formats. Any debate about whether we should or should not=
>> check certain inputs for certain conditions need not be a bar for<= br> >> allocating numbers.
>
> Assuming CFRG chairs really did declare consensus on Ed448 hash, then<= br> > the final characteristics of Ed448 are known and I have a reference > implementation.
>
> And the PKIX draft looks implementable (has wrong example?)
>
> More serious interop hazard is what to do with X25519/X448 and THS
> (some of the proposed stuff is not wire-compatible).

This CFRG co-chair would like to see an updated CFRG draft before th= e code point is allocated.

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

--001a11401a16f5615d052939d384-- From nobody Wed Jan 13 09:48:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148A71B2FE7 for ; Wed, 13 Jan 2016 09:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rll1PSyFkavg for ; Wed, 13 Jan 2016 09:48:38 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2701B2FE5 for ; Wed, 13 Jan 2016 09:48:38 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 02A3C16C6F9 for ; Wed, 13 Jan 2016 17:48:38 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D6E9716C4CC for ; Wed, 13 Jan 2016 17:48:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452707317; bh=Ubq3pi7wOw6EAaEmlHgjnbfrOfgxm1Bc+zcKut3Ap04=; l=3649; h=From:To:Date:From; b=ooOo7kn54dcUf/T1HzAIjupTqlPcOXxJ72SZOgiSvwvDNJmKlmYee/uZ7g3zKkS/C 1fcnvnFmOQhANyfAcppeDPluTUm04kQwamzrwuNUKjxmzW4VbxN+6F3p1p2QQJ88IY XsnEnxO0opkHr+BNnv4IiQtTORyaA4241n7hQZmw= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id BB49E98082 for ; Wed, 13 Jan 2016 17:48:37 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 13 Jan 2016 12:48:37 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 13 Jan 2016 12:48:37 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: chacha/poly for http/2 Thread-Index: AdFOKgjbV50WxwDKRNyYWOPJPzIw1w== Date: Wed, 13 Jan 2016 17:48:37 +0000 Message-ID: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.37] Content-Type: multipart/alternative; boundary="_000_326d1a7af9ae441081f5c272e5758d9fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:48:40 -0000 --_000_326d1a7af9ae441081f5c272e5758d9fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We (OpenSSL) have already tested interop of chacha/poly with other browsers= and TLS stacks, and now it all works. (The official IETF version, not the= QUIC version). We (Akamai) are planning on enabling it for our customers in a few weeks, i= n case anyone might be interested. Thanks. /r$, a me who is part of both of the we's above :) -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_326d1a7af9ae441081f5c272e5758d9fusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We (OpenSSL) have already tested interop of chacha/p= oly with other browsers and TLS stacks, and now it all works.  (The of= ficial IETF version, not the QUIC version).

 

We (Akamai) are planning on enabling it for our cust= omers in a few weeks, in case anyone might be interested.

 

Thanks.

 

        &nbs= p;       /r$, a me who is part of both of the= we’s above J

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_326d1a7af9ae441081f5c272e5758d9fusma1exdag1mb1msgcorpak_-- From nobody Wed Jan 13 10:21:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC81B3056 for ; Wed, 13 Jan 2016 10:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.928 X-Spam-Level: * X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 7EtntxZz6rlW for ; Wed, 13 Jan 2016 10:21:06 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 8D43B1B3031 for ; Wed, 13 Jan 2016 10:21:06 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id k129so475730835yke.0 for ; Wed, 13 Jan 2016 10:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7z5g9+b5Syw1z+Q6k0lTl6MdJmLrHlhD8SKR2/yd0I0=; b=i9oNUB7sLiGkTxXkupmG/r3dUiM3AUi2Cpp7DpvC4jS0k1I+ic9QgwfwgdEVHpPOF0 /gmyRECewXwjFmc4kH2ctYguYx6xdeMYX5Dzsia/Z4Gr2h0UaKPPIo+JFTzvgxAaXDKR jo1eaWiSfJshqA1XQxO8stOr6W7pySASZSEbV+aetx8HPxHGkx7M7X7scEzISumdOwdc GWPC3l7SYxf+iVNhzLLOf4dWUoukCeado9XPVzF5k/uzIdCey+Zi1VTNomC/QLhZO0kL fyYhkhoPV1PEceqLXHw/lNCjYOXg46APntp4lF9+UVgEVL6EKwrnGIZJa3WXi1nr/S0/ bL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7z5g9+b5Syw1z+Q6k0lTl6MdJmLrHlhD8SKR2/yd0I0=; b=dFhfcSUT19tSuhthGJh2AMZ0NwXjymLafN/anwU4UCDFVb9WRaAvHz8qcDE10EWvT1 mUyKai3FJbAp4has69zWDF3YxTdo4G979areokDFD/swi60ytZpq20YeFxSYK8SQBGEH LHF7lGQ6P/VQSLrDwl3ywaZrIIQpV392jVqhrRsdJSfMfUOl0WtpHpdARIMJeiK7BYil OzaznqGv6FSislSlG1ZJwMDLo3Pz9DT8HOPxZIAy7qFarMyxjmSUU273n3tA6A30QHT4 2wOtamE5isXfDT9NU5uylY6dGl768bCBfJ3uCbXrPziSldVHuqHDQkP1pxrT5EL7FhuN 6k4Q== X-Gm-Message-State: ALoCoQk8upx0nwlnA9rCu3rkR6xPXtaY3jK09y88OuM+M908TZOo75LruwbrVDw8UrJm4mge8obnekHExKE5fgTawPCruBFm883qWvCzCn7m8u+oAvHz5oI= MIME-Version: 1.0 X-Received: by 10.13.223.69 with SMTP id i66mr87022061ywe.323.1452709265631; Wed, 13 Jan 2016 10:21:05 -0800 (PST) Received: by 10.37.115.16 with HTTP; Wed, 13 Jan 2016 10:21:05 -0800 (PST) In-Reply-To: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 13 Jan 2016 10:21:05 -0800 Message-ID: From: Wan-Teh Chang To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:21:07 -0000 On Wed, Jan 13, 2016 at 9:48 AM, Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other browsers > and TLS stacks, and now it all works. (The official IETF version, not the > QUIC version). Hi Rich, Did you test interop of chacha/poly with a developer build of Firefox? The NSS patch is still being reviewed at https://codereview.appspot.com/277090043/. So official Firefox releases don't support chacha/poly cipher suite yet. Wan-Teh Chang From nobody Wed Jan 13 10:38:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17D1B309A for ; Wed, 13 Jan 2016 10:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 TojbnZAQW9-w for ; Wed, 13 Jan 2016 10:38:54 -0800 (PST) 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 BE7D91B3098 for ; Wed, 13 Jan 2016 10:38:54 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 77so396489814ioc.2 for ; Wed, 13 Jan 2016 10:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=g4ow63fChnXx28lmuA67ueK7eYZoQw5x6bT6h2zZbpA=; b=XIev5Bemjgu3j8UyquDA1htdzXt4LzO/Ta/dxFZ6oRqaHvonLEcGTaVCqlEm668Nwi stFY+pdxPQv6MF0K3qUEOs3AJ4c6DEtJCNVfxZdoC3GFUgM7RR0DevUnG5/uF+5DTVMp MAQ9h9LCnH6w3XC9rErxrzNI6+uLaryvbWCZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=g4ow63fChnXx28lmuA67ueK7eYZoQw5x6bT6h2zZbpA=; b=l8y3QuysH3O8YU5w/RsDpJzKg+ezzfSLUopvmuP+pbnUZ4W680cmFUoE8QFeH4qcbb xFc42FcVoSiOHjPrlqyeURHdSNIPTs7Xew8xucDV3T367G/GQZ9yiHmJWkz0RFtg62Tz JfMnK5k4pICN6i7qxQzUPcy86nhlO1t8O8mOSMhJ+WWnL1eMxLMgNjAmOkzcRfapc/GU A3VIBS4w2Pu8Q7EuNubWDm9obOFNCSaGTV4pFDJSmRQmd5umP3v/nGjiYsCYjX979t9F Tp79GaMN4jS2C9KzZ8d65BI6cXwf2vikHBBaELJ5D8f9quAjYhrsmP2UuZPAxGybm8tH rrfQ== X-Gm-Message-State: ALoCoQnAbn3l2VrZtl5esBeheBVN6fEhGOpamxUVvyY86r9F1Kysac4Ss2NZvhICoJzYuOMXSrnv5rccd++LikEqF7CxZzEqXqQ2mq1k+wZpA/twOEVGMfc= X-Received: by 10.107.44.88 with SMTP id s85mr477741ios.62.1452710334035; Wed, 13 Jan 2016 10:38:54 -0800 (PST) MIME-Version: 1.0 References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> From: David Benjamin Date: Wed, 13 Jan 2016 18:38:43 +0000 Message-ID: To: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a033c6c5c6805293b7b40 Archived-At: Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 18:38:56 -0000 --001a113a033c6c5c6805293b7b40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chrome is also expecting to ship the cipher in Chrome 49. It's available in Canary and Dev channel right now. It should interop with OpenSSL's master branch as of when I last tested this. David On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other > browsers and TLS stacks, and now it all works. (The official IETF versio= n, > not the QUIC version). > > > > We (Akamai) are planning on enabling it for our customers in a few weeks, > in case anyone might be interested. > > > > Thanks. > > > > /r$, a me who is part of both of the we=E2=80=99s above J > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113a033c6c5c6805293b7b40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chrome is also expecting to ship the cipher in Chrome 49. = It's available in Canary and Dev channel right now. It should interop w= ith OpenSSL's master branch as of when I last tested this.

David

On Wed, Jan= 13, 2016 at 12:48 PM Salz, Rich <rs= alz@akamai.com> wrote:

We (OpenSSL) have already tested interop of chacha/p= oly with other browsers and TLS stacks, and now it all works.=C2=A0 (The of= ficial IETF version, not the QUIC version).

=C2=A0

We (Akamai) are planning on enabling it for our cust= omers in a few weeks, in case anyone might be interested.

=C2=A0

Thanks.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /r$, a me who is part of both of th= e we=E2=80=99s above J

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113a033c6c5c6805293b7b40-- From js@crypto.tw Wed Jan 13 12:45:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318F1B324A for ; Wed, 13 Jan 2016 12:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 HlA99utL0xU5 for ; Wed, 13 Jan 2016 12:45:11 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8F31B3248 for ; Wed, 13 Jan 2016 12:45:10 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id py5so97846900obc.2 for ; Wed, 13 Jan 2016 12:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crypto-tw.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=aomyqoiU9C+Enw/rurM+Jpgbrw2EzDDgUj3Aemhmxco=; b=maL71ajbSgZfBEWA2FS8RFnFzGbkQYj7eSh8YRfjOHR/WUrzQr0CrUT9IN46AqdIhx VlJLzHEHB1752l1nWerkbh4m5IHbLSVi88OpkU2ixKj6fK2bICMS884xgrbjyalBl0PJ G23B0fd8iExjSQFdEv0J0U7V/jVXSf7pf/s43vvwWe/rBeOG84JpMf23yGchsgpJCBcE 4pFSvEmVjCa6WH1/X2/fvgfHgD9Hsz97/M+ZjZJOeIJxGQTQKyIpHFEYHD6sX/49ZJWF VfRKvkocAFbihrC+Y4nfYKG29Ht1lnfFwjqnQS0deG5gFzbLreNFt4kKjZQWH7DHiAAo A66Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=aomyqoiU9C+Enw/rurM+Jpgbrw2EzDDgUj3Aemhmxco=; b=gfxXs8VDt/dEz2PvALI8gwhDkp7/cXbrgtC+5hu4Rsmr16aCyr7s0OB0tDxGUvZJCs 9W7JngEHX2ux7QtOqi6JNHGRT8YWDjJ2K5zs+1b0XjzitxrWewxPhbB55hvxiDUnaDgo s55Qbmd8J6kHiz/BRrJmcP+VGu0iC0fOBp0NMDC1YBU7t/68aEixPys9koZfLnA4sssR zFPTR/fQl1ZG4mVi8KyojTdVIZYt+9yj6tB4AtFYo5sMgolUiD3D7PAkNByGCTahKezn Bn8nESu6iHNjnsivYhu343X7mRPq9MED/LPRI4QhljFtAcivwjOxD4E+bzJJvgytOrEW UHYg== X-Gm-Message-State: ALoCoQlC0PDsC/ha/PKzqAMsxyIaslaoho8s4keVu16bZALx0ZHRwUNTRsrFEckFRuDiLC1PIvhc8E+pxcxn0ot/5KvVUX3LDw== X-Received: by 10.60.137.137 with SMTP id qi9mr230840oeb.56.1452717910214; Wed, 13 Jan 2016 12:45:10 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id r9sm1503849oih.6.2016.01.13.12.45.09 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 12:45:09 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id vt7so65577902obb.1 for ; Wed, 13 Jan 2016 12:45:09 -0800 (PST) X-Received: by 10.60.226.136 with SMTP id rs8mr189760oec.31.1452717909580; Wed, 13 Jan 2016 12:45:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.197.131 with HTTP; Wed, 13 Jan 2016 12:44:30 -0800 (PST) From: Jong-Shian Wu Date: Thu, 14 Jan 2016 04:44:30 +0800 X-Gmail-Original-Message-ID: Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:50:23 -0000 I have a question about the even-vs-odd restrictions on the length of a valid variable-length vector defined in TLS specification after reading the section 4.3 of RFC 5246 [1] which states that: "The length of an encoded vector must be an even multiple of the length of a single element (for example, a 17-byte vector of uint16 would be illegal)." Does it also means that an 18-byte vector of uint16 would be illegal? (18 is an odd multiple of 2, not an *even* multiple of 2) To put it differently, given the following definitions for Foo and Bar: opaque Foo[2]; Foo Bar<4..8>; Is it correct to say that there does not exist any valid 6-byte value of type Bar? (6 is not an even multiple of 2) [1]: https://tools.ietf.org/html/rfc5246#section-4.3 From nobody Wed Jan 13 12:53:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A661B3264 for ; Wed, 13 Jan 2016 12:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1hFFaDsSze3 for ; Wed, 13 Jan 2016 12:53:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 904061B3253 for ; Wed, 13 Jan 2016 12:53:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A71E6433446; Wed, 13 Jan 2016 20:53:26 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8F4AE433437; Wed, 13 Jan 2016 20:53:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452718406; bh=ZQG3UlhRd4+jrdr1UDKezgEEFn79eFPMNf0JdR/VbCE=; l=535; h=To:References:From:Date:In-Reply-To:From; b=ij/zm+aXp4L8PvMPa/oRV/N5azVHj3jHIvHC6wFEZ/rll56wfzzlsKLkxFmYmxeoY kAea5TuJjtINOjzOrPNvCEMvqAwvFf+H9bWBb3e2gg/lWhLkfIWwne8juthQxz/AoD ip5N+ZoAA+jLO8Vk/+3HwZ6525BL4T2n8FUsFV6E= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 54DB92026; Wed, 13 Jan 2016 20:53:26 +0000 (GMT) To: Jong-Shian Wu , tls@ietf.org References: From: Benjamin Kaduk Message-ID: <5696B946.3050405@akamai.com> Date: Wed, 13 Jan 2016 14:53:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:53:29 -0000 On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > I have a question about the even-vs-odd restrictions on the length of > a valid variable-length vector defined in TLS specification after > reading the section 4.3 of RFC 5246 [1] which states that: "The length > of an encoded vector must be an even multiple of the length of a > single element (for example, a 17-byte vector of uint16 would be > illegal)." > It means "whole-number" as opposed to fractional, i.e., there should not be unused "junk bytes" at the end. -Ben From nobody Wed Jan 13 13:03:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321321A0104 for ; Wed, 13 Jan 2016 13:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 0F1daXK5o_Pb for ; Wed, 13 Jan 2016 13:03:33 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F231A0105 for ; Wed, 13 Jan 2016 13:03:33 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id is5so65962677obc.0 for ; Wed, 13 Jan 2016 13:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crypto-tw.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0Lapep4TdAxEZ1+nx641/8UJbnCg9iNg+AmlQOTB0gQ=; b=uORwT45EWYEOZ9EmZSfvQiuivNVycKJ7k+U8BklVSMrB8SaxgmDm7GNFmvMBlrqaz1 vcq2jptf6BS1Cp1DlfC4PajVrAQfwnnLhWSbSGUYUPp9IrAFiT7kTPDuABJLZBBRWEjA CcJSP97aVdbr+M6b+zD2wA1NiBYSsGpPtOlywutr9u//a7ChwvqnHP99K8cwpL+14Wwv Q/oTEE558rdpcJ2y/F7ooOBIdLD8K75VuISjI6JEg8fgi74fcG7Wuv3xa4ZTpEMw0aYg 3L6Lfe2X1LQQCXFEREhvxmEHLC+s2lGdQBOCVnLpnTdnau9fHFy39oZim5cXBpC1EQXo Hxdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0Lapep4TdAxEZ1+nx641/8UJbnCg9iNg+AmlQOTB0gQ=; b=mK5rnwZiZNqlo8UlnRlQE3ibHkhvYzOxpE3NQKCnk3La0o8jMFRozMSDmGK1llgaFS 1mOFpzHSPwcGPFSSZJbTYzszyqRqJ5J9h5Fy3nlDwmSU/4IrosoXF7onaoE3hk1p6JpQ at8R5QMRQLTQ6mxBCWfShIMsixQuRxnQ4ktfgazSGd/bUoy1QlhWyuOrU72H03kn92wp ecGefviXSqIWb3w/+BLZMfGoKY1fJWJc/1Z2RFcMQhlujY+qadov+T0D7qdHqYIRAN8n XK5zchpmkrmOTD7q34SvfHEbbduW45tA+9ea/+ck8f5SLS2eFkRuwh8dpTOcwWoZEItx nEeA== X-Gm-Message-State: ALoCoQlVnAHrceJeWHNFMtOo5AevCfGrOhomuKccESmtdKOOF4twL0HcQ7lQ9PLeIE9zwFA6Ybb1Kv3uXxLH2syS+ALYxtpnPA== X-Received: by 10.182.18.105 with SMTP id v9mr245358obd.59.1452719012870; Wed, 13 Jan 2016 13:03:32 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id w143sm1548122oiw.16.2016.01.13.13.03.32 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 13:03:32 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id py5so98263902obc.2 for ; Wed, 13 Jan 2016 13:03:32 -0800 (PST) X-Received: by 10.182.241.3 with SMTP id we3mr268831obc.82.1452719012296; Wed, 13 Jan 2016 13:03:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.197.131 with HTTP; Wed, 13 Jan 2016 13:02:53 -0800 (PST) In-Reply-To: <5696B946.3050405@akamai.com> References: <5696B946.3050405@akamai.com> From: Jong-Shian Wu Date: Thu, 14 Jan 2016 05:02:53 +0800 X-Gmail-Original-Message-ID: Message-ID: To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 21:03:34 -0000 On Thu, Jan 14, 2016 at 4:53 AM, Benjamin Kaduk wrote: > It means "whole-number" as opposed to fractional, i.e., there should not > be unused "junk bytes" at the end. > > -Ben Ah, so that is not about even vs odd numbers at all. Thank you very much for the quick clarification! From nobody Wed Jan 13 16:14:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8B01A9067 for ; Wed, 13 Jan 2016 16:14:56 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGzXK8frsenA for ; Wed, 13 Jan 2016 16:14:52 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E833D1A906A for ; Wed, 13 Jan 2016 16:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452730492; x=1484266492; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jzrx/ka5l2+ZrJY9A2PbPYDWtw9LFNZMd9ekd4XsfWU=; b=WvXUhwUlOPMZQnNxzQHAS1UMkm3ieoeeivvVRfDINDlUCkp3H8Qegh/t +mG0jGqzE7evVSo69mEtw7E3uWgEYml82apPLX4w1PQTlsA18mE1gWDmt 1P8zO9Z6ohqC77aaa/4vDdMWogI5XiIwAiyAH28R4bjWe4++hYrwSzke1 gVbVRUaAEHZDkY9qjWzAOFZ8L4lTjdn/hkuD9kp3xu+S0nfr031DzRXTU edqw2P4PK+P2+HKrKg2rw2yX0F403saVN6hZtSx4PNQgzF/LQeDIAij45 YePWjM0ev9mgcdU1GWdJ3gMEKuqppiEOpd0158Z2ec2N64LiiA2LFIZGH g==; X-IronPort-AV: E=Sophos;i="5.22,291,1449486000"; d="scan'208";a="63021515" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jan 2016 13:14:50 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Thu, 14 Jan 2016 13:14:49 +1300 From: Peter Gutmann To: "Salz, Rich" , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzf//Ww+AgAFZaKb//zG9AIAArXmAgADjpcP//zPZAIABkT2/ Date: Thu, 14 Jan 2016 00:14:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC815F@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> , <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz>, <94395a3c029c493eb491eb3db90e3ed1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <94395a3c029c493eb491eb3db90e3ed1@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:14:56 -0000 Salz, Rich writes:=0A= =0A= >> TLS needs an LTS version that you can just push out and leave to its own= =0A= >> devices=0A= >=0A= >So don't you have that with TLS 1.1 and appropriate cipher and option=0A= >choices?=0A= =0A= That's the approach suggested previously by Peter Bowen, assemble it yourse= lf=0A= from a huge list of extensions. The problem there is that you're after a= =0A= fixed, known-good config drawn from the maybe 10 extension-RFCs you'd need = to=0A= cover (from Peter's post + a few extra to cover new things), I don't want t= o=0A= go through all of those and count up the possible options but I'm pretty su= re=0A= I'd need to resort to special notation to express the magnitude of=0A= combinations once you plug them into the nCk formula.=0A= =0A= Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft= =0A= that specifices just a single boolean flag, "use this known-good configurat= ion=0A= and not the 6.023e23 other ones and you should be good for the next decade = or=0A= so". That can then be baked into long-term systems and devices and left al= one=0A= while people get on with other things.=0A= =0A= (Speaking of feedback, still got a bucketload of private email to respond t= o,=0A= including stuff from people I didn't know where on the list any more, turn= s=0A= out there's a lot more reading than writing, I'm working through it...).= =0A= =0A= Peter.= From nobody Wed Jan 13 16:17:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213F61ACEF3 for ; Wed, 13 Jan 2016 16:17:13 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-Mt_HILS2Zr for ; Wed, 13 Jan 2016 16:17:12 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38251ACEEF for ; Wed, 13 Jan 2016 16:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452730632; x=1484266632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ag05PkgvkO4FVMAIVedZuHB+KmhUcyzzla8M1jvGDEw=; b=dcHxtcgx03irR0ftw9LW74uGEZUhYKgCkz+MtC/Qpdplz6GTH9ez7RcP LHziN7rJv5YfJ50ms3k+VzXs1RJLYXGCwAtbd4Dwoo1dqcuHhijDQuTha mhGOuaRrONP7c2+o6P0Uaxg6vUdawOkKoX/fvNRCszV7eKuVySPi4U3Pz WFAqGCuOfA2+wWdZf6WlFm0jzKm7QsKmnUwppDjell8cj/6Pbm1n/hyJG XDDBq8Ro2SjdLFIVGFCM+vLMbv2hy53uU3QqhrPWtAcbWrVO2Ml+yUFve bjJEA31E7roZAKQ59QpRXHKhEzI1EoAzOL0k0rwN6Fl6sowVNH+1Zgmdb Q==; X-IronPort-AV: E=Sophos;i="5.22,291,1449486000"; d="scan'208";a="63021954" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jan 2016 13:17:11 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 14 Jan 2016 13:17:10 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Yoav Nir Thread-Topic: [TLS] Fixing TLS Thread-Index: AdFNQhHrFy3mVBx6TGiPN32I/iztzf//Ww+AgAEXaQCAAcsWBQ== Date: Thu, 14 Jan 2016 00:17:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC8183@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com>, <1452678816.25588.38.camel@redhat.com> In-Reply-To: <1452678816.25588.38.camel@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:17:13 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >That is because TLS 1.3 is a rewrite of the protocol, and requires a rewri= te=0A= >of the code base. Given that the majority of the issues in TLS=0A= >implementations are in the code bases and not in the protocol, it is very= =0A= >risky to switch to such a new version just like that.=0A= =0A= +1. This is exactly what the 1.2LTS approach (at least it has a name now := -)=0A= is trying to address.=0A= =0A= Peter.=0A= From nobody Wed Jan 13 21:06:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7BE1A8FD7 for ; Wed, 13 Jan 2016 21:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_CWHY-UQPx0 for ; Wed, 13 Jan 2016 21:06:36 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 00F061A903F for ; Wed, 13 Jan 2016 21:06:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4E4F4425; Thu, 14 Jan 2016 07:06:34 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZnEGYDnC1RZx; Thu, 14 Jan 2016 07:06:33 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3013B286; Thu, 14 Jan 2016 07:06:33 +0200 (EET) Date: Thu, 14 Jan 2016 07:06:30 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20160114050629.GA23796@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4BC727B@uxcn10-5.UoA.auckland.ac.nz> <1697088.4ma2uCFsM4@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC7853@uxcn10-5.UoA.auckland.ac.nz> <94395a3c029c493eb491eb3db90e3ed1@usma1ex-dag1mb1.msg.corp.akamai.com> <9A043F3CF02CD34C8E74AC1594475C73F4BC815F@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC815F@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 05:06:38 -0000 On Thu, Jan 14, 2016 at 12:14:48AM +0000, Peter Gutmann wrote: > Salz, Rich writes: > > >> TLS needs an LTS version that you can just push out and leave to its own > >> devices > > > >So don't you have that with TLS 1.1 and appropriate cipher and option > >choices? > > Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft > that specifices just a single boolean flag, "use this known-good configuration > and not the 6.023e23 other ones and you should be good for the next decade or > so". That can then be baked into long-term systems and devices and left alone > while people get on with other things. To actually fix the known problems with TLS 1.2, you would at minimum need a new extension, since there is currently no way to fix the broken server authentication. Then there are the other security fix extensions (at least three already). Those all would need to be impiled. And then there is the TLS 1.2 Diffie-Hellman issue... -Ilari From nobody Thu Jan 14 01:40:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEA01B2DAE for ; Thu, 14 Jan 2016 01:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDaHmqVrp-iq for ; Thu, 14 Jan 2016 01:40:47 -0800 (PST) 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 457C91B2DAD for ; Thu, 14 Jan 2016 01:40:47 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 62F2E4496D; Thu, 14 Jan 2016 10:40:45 +0100 (CET) X-purgate-ID: 152705::1452764445-00006F99-8A62FCD9/0/0 X-purgate-size: 2282 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 mail05.wdf.sap.corp (Postfix) with ESMTP id CD60240918; Thu, 14 Jan 2016 10:40:44 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 497531A3E9; Thu, 14 Jan 2016 10:40:44 +0100 (CET) In-Reply-To: <20160114050629.GA23796@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Thu, 14 Jan 2016 10:40:44 +0100 (CET) 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: <20160114094044.497531A3E9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Jan 2016 09:40:49 -0000 Ilari Liusvaara wrote: > > Peter Gutmann wrote: > >> Salz, Rich writes: >> >>>> TLS needs an LTS version that you can just push out and leave to its own >>>> devices >>> >>>So don't you have that with TLS 1.1 and appropriate cipher and option >>>choices? >> >> Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft >> that specifices just a single boolean flag, "use this known-good >> configuration and not the 6.023e23 other ones and you should be good >> for the next decade or so". That can then be baked into long-term >> systems and devices and left alone while people get on with other things. > > To actually fix the known problems with TLS 1.2, you would at minimum > need a new extension, since there is currently no way to fix the broken > server authentication. One Boolean signaling is sufficent to fix all of the problems. one SCSV in the Client->Server direction and a TLS extension Boolean response in ServerHello. > > Then there are the other security fix extensions (at least three already). > Those all would need to be impiled. > > And then there is the TLS 1.2 Diffie-Hellman issue... TLS 1.2LTS should fix them all at once, including: - promise to support minimum DHE key lengths >= 2048 bits whenever ClientHello includes DHE cipher suites - promise to support a certain small subset of EC curves and uncompressed point format whenever ClientHello includes ECDHE cipher suites (but may omit TLS extensions). - new/improved ServerKeyExchange handshake message, which does not only contain the reasonable set of DHE parameters, but also uses a digititally signed covering all prior handshake messages, not just the two hello randoms. - overriding any TLS record layer protocol version and ClientHello.client_version that is less than TLSv1.2 - promise that digital signatures using SHA-256 are supported - fix the misunderstood semantics of the signature_algorithm extension so that it is only used as a hint to certificate selection, but *NEVER* seen as a hard requirement (or reason for server to abort the TLS handshake based on the signature of the server cert). -Martin From nobody Thu Jan 14 02:29:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E0D1B32BB for ; Thu, 14 Jan 2016 02:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq6_XIzK61dH for ; Thu, 14 Jan 2016 02:29:38 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 63F751B32BA for ; Thu, 14 Jan 2016 02:29:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 85CB52375; Thu, 14 Jan 2016 12:29:36 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id XlSbdCBiUKZU; Thu, 14 Jan 2016 12:29:36 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 45BE527B; Thu, 14 Jan 2016 12:29:36 +0200 (EET) Date: Thu, 14 Jan 2016 12:29:33 +0200 From: Ilari Liusvaara To: Martin Rex Message-ID: <20160114102933.GA24088@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160114050629.GA23796@LK-Perkele-V2.elisa-laajakaista.fi> <20160114094044.497531A3E9@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160114094044.497531A3E9@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 10:29:41 -0000 On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > > > > To actually fix the known problems with TLS 1.2, you would at minimum > > need a new extension, since there is currently no way to fix the broken > > server authentication. > > One Boolean signaling is sufficent to fix all of the problems. > one SCSV in the Client->Server direction and a TLS extension Boolean > response in ServerHello. Just stick it as an extension. Extensions have been required since TLS 1.0, its precessor SSL 3.0 is _dead_. And extension-intolerant servers are just plain problems for everybody. > > > > Then there are the other security fix extensions (at least three already). > > Those all would need to be impiled. > > > > And then there is the TLS 1.2 Diffie-Hellman issue... > > TLS 1.2LTS should fix them all at once, including: > > - promise to support minimum DHE key lengths >= 2048 bits > whenever ClientHello includes DHE cipher suites The problem is that client that tries to be secure will just abort if it receives DHE <2048 bits. Regardless if server accepted the extension or not. Then there's also similar problems with RSA. And then RSA PKCS #1 v1.5 encryption is on just about every "do not use!" list. Get it wrong (good luck getting it right) and it is game over. > - promise to support a certain small subset of EC curves > and uncompressed point format whenever ClientHello includes > ECDHE cipher suites (but may omit TLS extensions). You have EC formats extension already. Or do you mean that there are broken endpoints that can't mix-and- match ECDHE curves and signatures? (I know about problems doing mix-and-match on hashes and curves in ECDSA... TLS has currently no way to signal those limits). > - new/improved ServerKeyExchange handshake message, which > does not only contain the reasonable set of DHE parameters, > but also uses a digititally signed covering all prior > handshake messages, not just the two hello randoms. You mean fixing the DHE groups? Because the present arbitrary groups are source of many problems. This also causes problems for anyone trying to support DHE in TLS 1.3. > - overriding any TLS record layer protocol version and > ClientHello.client_version that is less than TLSv1.2 > > - promise that digital signatures using SHA-256 are supported You mean upgrade the default SHA-1 to SHA-256? > - fix the misunderstood semantics of the signature_algorithm extension > so that it is only used as a hint to certificate selection, > but *NEVER* seen as a hard requirement (or reason for server to > abort the TLS handshake based on the signature of the server cert). The client aborts if server certificate chain won't validate due to bad algorithms, right? And then: - Imply Extended Master Secret. - Require Renego fixes. - Imply EtM on block modes. (Any others?) -Ilari From nobody Thu Jan 14 03:27:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1232C1B336D for ; Thu, 14 Jan 2016 03:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnzsLwGZSzj4 for ; Thu, 14 Jan 2016 03:27:10 -0800 (PST) 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 C6E011B336B for ; Thu, 14 Jan 2016 03:27:09 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 162404485D; Thu, 14 Jan 2016 12:27:08 +0100 (CET) X-purgate-ID: 152705::1452770828-00002D85-3C786464/0/0 X-purgate-size: 5993 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 mail05.wdf.sap.corp (Postfix) with ESMTP id CD51640406; Thu, 14 Jan 2016 12:27:07 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id BFB721A3E9; Thu, 14 Jan 2016 12:27:07 +0100 (CET) In-Reply-To: <20160114102933.GA24088@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Thu, 14 Jan 2016 12:27:07 +0100 (CET) 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: <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Jan 2016 11:27:12 -0000 Ilari Liusvaara wrote: [ Charset UTF-8 unsupported, converting... ] > On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote: > > Ilari Liusvaara wrote: > > > > > > To actually fix the known problems with TLS 1.2, you would at minimum > > > need a new extension, since there is currently no way to fix the broken > > > server authentication. > > > > One Boolean signaling is sufficent to fix all of the problems. > > one SCSV in the Client->Server direction and a TLS extension Boolean > > response in ServerHello. > > Just stick it as an extension. Extensions have been required since TLS > 1.0, its precessor SSL 3.0 is _dead_. And extension-intolerant servers > are just plain problems for everybody. Nope, TLS extensions (rfc3546, jun-2003) are not required, and were not part of TLSv1.0 (rfc2246, jan-1999). TLSv1.0 contains only a forward-compatibility notice as a comment to the ClientHello PDU. The same notice that was retrofitted to the carefully hidden SSLv3 specification from November 1996 that was used as a starting point for the TLSv1.0 spec. But we all know how little interop was tested for this forward compatibility notice, similar to the untested protocol versions > { 3, 1 } (aka TLSv1.0). > > > > > > > Then there are the other security fix extensions (at least three already). > > > Those all would need to be impiled. > > > > > > And then there is the TLS 1.2 Diffie-Hellman issue... > > > > TLS 1.2LTS should fix them all at once, including: > > > > - promise to support minimum DHE key lengths >= 2048 bits > > whenever ClientHello includes DHE cipher suites > > The problem is that client that tries to be secure will just abort > if it receives DHE <2048 bits. Regardless if server accepted the > extension or not. > > Then there's also similar problems with RSA. And then RSA PKCS #1 > v1.5 encryption is on just about every "do not use!" list. Get it > wrong (good luck getting it right) and it is game over. Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into TLS 1.2LTS as well. How to do it right for signatures has been described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already, It is a real pity that neither TLSv1.1 (rfc4346,apr-2006) nor TLSv1.2 (rfc5246,aug-2008) did not prohibit the dangerous PKCS#1 v1.5 processing entirely, because that's an extremly low hanging fruit. > >> - promise to support a certain small subset of EC curves >> and uncompressed point format whenever ClientHello includes >> ECDHE cipher suites (but may omit TLS extensions). > > You have EC formats extension already. rfc4492 is severly broken, in that it specifies that a ClientHello without the two TLS EC extensions indicates that the client supports *EVERYTHING* in the rfc4492 spec (rather than a reasonable default subset). I hope that the IESG does not let such obvious breakage enter the standards track. > > > - new/improved ServerKeyExchange handshake message, which > > does not only contain the reasonable set of DHE parameters, > > but also uses a digititally signed covering all prior > > handshake messages, not just the two hello randoms. > > You mean fixing the DHE groups? Because the present arbitrary groups > are source of many problems. I would be OK with implying support for a reasonable small set of (assumed) secure fixed groups. But ServerKeyExchange for DHE needs to be fixed to allow arbitrary groups as well. They're a performance problem, so I assume the marketplace will decide. After the severe problems of DHE had been publicly described on the TLS mailing list in 2008, I decided that we will never support DHE in our (then OEM) implementation, and never regretted that decision. We've recently addes support for ECDHE, but will not support DHE. > > This also causes problems for anyone trying to support DHE in TLS 1.3. > >> - overriding any TLS record layer protocol version and >> ClientHello.client_version that is less than TLSv1.2 >> >> - promise that digital signatures using SHA-256 are supported > > You mean upgrade the default SHA-1 to SHA-256? Yup. What TLSv1.2 (rfc5246) should have done in 2008 already. > >> - fix the misunderstood semantics of the signature_algorithm extension >> so that it is only used as a hint to certificate selection, >> but *NEVER* seen as a hard requirement (or reason for server to >> abort the TLS handshake based on the signature of the server cert). > > The client aborts if server certificate chain won't validate due to > bad algorithms, right? The client remains free to perform local policy enforcement for any *incoming* data from the server. The extreme nuisance with rfc5246 is what Microsoft has shipped in SChannel, where an extensionless ClientHello offering TLSv1.2 will cause a Microsoft Server (2008&2012) to choke and abort the TLS handshake when the server has only a server certificate signed with sha256withRSAEncryption, wereas it will handshake successfully (and negotiate TLSv1.1) if the very same client offers only TLSv1.1 or offers TLSv1.2 in an SSL Version 2 CLIENT-HELLO. > > And then: > > - Imply Extended Master Secret. > - Require Renego fixes. wfm. > > - Imply EtM on block modes. Personally, I do _not_ like this one. DTLS implementers that followed the poor advise from the DTLS spec might want this one, though. I would strongly prefer (pad,mac,encrypt), as originally proposed by Vaudenay, because it is safer and more secure in TLS. EtM is bad for support, because it can more easily result in corrupted plaintext while not showing up as error at the TLS level -- and the application will not necessarily notice this. I've already seen this happening in the real world with AEAD (AES-GCM) in TLS (occasional encryption failures). -Martin From nobody Thu Jan 14 05:41:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99FD1B34F7 for ; Thu, 14 Jan 2016 05:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7ch4x-vVCHj for ; Thu, 14 Jan 2016 05:41:42 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4731B34F9 for ; Thu, 14 Jan 2016 05:41:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 390846B8; Thu, 14 Jan 2016 15:41:40 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id NlN9VpXAYcEk; Thu, 14 Jan 2016 15:41:39 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E63F1138; Thu, 14 Jan 2016 15:41:39 +0200 (EET) Date: Thu, 14 Jan 2016 15:41:36 +0200 From: Ilari Liusvaara To: Martin Rex Message-ID: <20160114134136.GA24427@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160114102933.GA24088@LK-Perkele-V2.elisa-laajakaista.fi> <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160114112707.BFB721A3E9@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 13:41:45 -0000 On Thu, Jan 14, 2016 at 12:27:07PM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > [ Charset UTF-8 unsupported, converting... ] Pfft... > > Then there's also similar problems with RSA. And then RSA PKCS #1 > > v1.5 encryption is on just about every "do not use!" list. Get it > > wrong (good luck getting it right) and it is game over. > > Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into > TLS 1.2LTS as well. How to do it right for signatures has been > described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already, I was talking about encryption, not signatures. Those are used by TLS_RSA_WITH_* ciphersuites. The encrpytion is very broken, the signatures are at most slightly such. (And those lists of crypto algorithms don't list RSA PKCS #1 v1.5 signatures the same as encryption). > >> - promise to support a certain small subset of EC curves > >> and uncompressed point format whenever ClientHello includes > >> ECDHE cipher suites (but may omit TLS extensions). > > > > You have EC formats extension already. > > rfc4492 is severly broken, in that it specifies that a ClientHello > without the two TLS EC extensions indicates that the client supports > *EVERYTHING* in the rfc4492 spec (rather than a reasonable default > subset). I hope that the IESG does not let such obvious breakage > enter the standards track. Does RFC4492bis fix that? > > > > > - new/improved ServerKeyExchange handshake message, which > > > does not only contain the reasonable set of DHE parameters, > > > but also uses a digititally signed covering all prior > > > handshake messages, not just the two hello randoms. > > > > You mean fixing the DHE groups? Because the present arbitrary groups > > are source of many problems. > > I would be OK with implying support for a reasonable small set of > (assumed) secure fixed groups. But ServerKeyExchange for DHE needs > to be fixed to allow arbitrary groups as well. They're a performance > problem, so I assume the marketplace will decide. After the severe > problems of DHE had been publicly described on the TLS mailing > list in 2008, I decided that we will never support DHE in our > (then OEM) implementation, and never regretted that decision. > We've recently addes support for ECDHE, but will not support DHE. It currently allows arbitrary groups, and all the nasty problems that come with those. > > - Imply EtM on block modes. > > Personally, I do _not_ like this one. > DTLS implementers that followed the poor advise from the DTLS spec > might want this one, though. > > I would strongly prefer (pad,mac,encrypt), as originally proposed by > Vaudenay, because it is safer and more secure in TLS. > > EtM is bad for support, because it can more easily result in corrupted > plaintext while not showing up as error at the TLS level -- and the application > will not necessarily notice this. I've already seen this happening in the real > world with AEAD (AES-GCM) in TLS (occasional encryption failures). P-E-M would be yet another mode... Then there is fun question of proving all this secure. I'm way less comfortable with this than TLS 1.3 security-wise. -Ilari From nobody Thu Jan 14 06:11:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783291ACE81 for ; Thu, 14 Jan 2016 06:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzAiNAK0tKDV for ; Thu, 14 Jan 2016 06:11:29 -0800 (PST) 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 520E61ACE7D for ; Thu, 14 Jan 2016 06:11:29 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 D31B1449BC; Thu, 14 Jan 2016 15:11:26 +0100 (CET) X-purgate-ID: 152705::1452780686-00006F99-07AA0F45/0/0 X-purgate-size: 2024 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 3B8E440B76; Thu, 14 Jan 2016 15:11:25 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DAE761A3E9; Thu, 14 Jan 2016 15:11:25 +0100 (CET) In-Reply-To: <20160114134136.GA24427@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Thu, 14 Jan 2016 15:11:25 +0100 (CET) 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: <20160114141125.DAE761A3E9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fixing TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Jan 2016 14:11:31 -0000 Ilari Liusvaara wrote: > Martin Rex wrote: >> Ilari Liusvaara wrote: > >>> Then there's also similar problems with RSA. And then RSA PKCS #1 >>> v1.5 encryption is on just about every "do not use!" list. Get it >>> wrong (good luck getting it right) and it is game over. >> >> Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into >> TLS 1.2LTS as well. How to do it right for signatures has been >> described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already, > > I was talking about encryption, not signatures. Those are used by > TLS_RSA_WITH_* ciphersuites. The encrpytion is very broken, the > signatures are at most slightly such. Encryption is a public key operation. Maybe you're thinking of *de*cryption instead (aka Bleichenbacher)? AFAIK, the Bleichenbacher countermeasure uses the fact that RSA is homomorphic to multiplication. Decoding the PKCS#1 v1.2 Blocktype 02 padding of the decrypted RSA premaster secret in constant time does also not require rocket science. But it seems sufficiently non-obvious that example code might help. > > (And those lists of crypto algorithms don't list RSA PKCS #1 v1.5 > signatures the same as encryption). > >>>> - promise to support a certain small subset of EC curves >>>> and uncompressed point format whenever ClientHello includes >>>> ECDHE cipher suites (but may omit TLS extensions). >>> >>> You have EC formats extension already. >> >> rfc4492 is severly broken, in that it specifies that a ClientHello >> without the two TLS EC extensions indicates that the client supports >> *EVERYTHING* in the rfc4492 spec (rather than a reasonable default >> subset). I hope that the IESG does not let such obvious breakage >> enter the standards track. > > Does RFC4492bis fix that? rfc4492bis can not fix that, unless a new signal is added that clients can include in ClientHello and that enables servers to distinguish rfc4492 peers from rfc4492bis peers. -Martin From nobody Thu Jan 14 07:14:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BCA1B3562 for ; Thu, 14 Jan 2016 07:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 DA8y5PJXB7Ms for ; Thu, 14 Jan 2016 07:14:45 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 387E61A9045 for ; Thu, 14 Jan 2016 07:14:44 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0EFERU1006761 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 14 Jan 2016 16:14:28 +0100 From: Simon Josefsson To: Joseph Salowey References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160114:joe@salowey.net::qiZU+QxgE0FjE0bU:1/ea X-Hashcash: 1:22:160114:agl@imperialviolet.org::kpuApEcP4mL3e3b4:1zyx X-Hashcash: 1:22:160114:tls@ietf.org::7Hlivvx5Q+q4Ar3e:AQ57 X-Hashcash: 1:22:160114:alexey.melnikov@isode.com::dZVII910GQpwBr6k:KLP9 Date: Thu, 14 Jan 2016 16:14:26 +0100 In-Reply-To: (Joseph Salowey's message of "Wed, 13 Jan 2016 08:40:29 -0800") Message-ID: <8737u0gpm5.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 15:14:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Allocating a code point for X25519 could be done and is long overdue (first draft September 2013). X448 is also stable. Code points for Ed25519 and Ed448 is more problematic since TLS authentication has historically had interaction with PKIX certs. I agree with Yoav's assertion that the curve point verification issue is not big enough to stall code point allocation. /Simon Joseph Salowey writes: > Hi All, > > Looks like I jumped too soon on this one. In particular, both the CFRG > signature draft and 4492bis need to be updated. Let's hold of on code > point assignment until then. > > Thanks, > > Joe > (crawling back under my rock now) > > On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov > wrote: > >> >> > On 12 Jan 2016, at 21:31, Ilari Liusvaara >> wrote: >> > >> >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: >> >> >> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson >> wrote: >> >>> >> >>> The same concern still applies: what does it mean to allocate code >> >>> point for the 4492bis-05 description? >> >> >> >> Allocating code points just means an implementation of draft-05 is >> >> likely to interoperate just fine with an implementation of the final >> >> RFC. >> >> >> >> Of course nothing is ever final until the RFC is out, so there=E2=80= =99s >> >> always a risk involved, but it is considered prudent to allocate >> >> numbers when we=E2=80=99re reasonably certain of the calculations and= on- >> >> the-wire formats. Any debate about whether we should or should not >> >> check certain inputs for certain conditions need not be a bar for >> >> allocating numbers. >> > >> > Assuming CFRG chairs really did declare consensus on Ed448 hash, then >> > the final characteristics of Ed448 are known and I have a reference >> > implementation. >> > >> > And the PKIX draft looks implementable (has wrong example?) >> > >> > More serious interop hazard is what to do with X25519/X448 and THS >> > (some of the proposed stuff is not wire-compatible). >> >> This CFRG co-chair would like to see an updated CFRG draft before the co= de >> point is allocated. >> >> _______________________________________________ >> 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 > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWl7tSAAoJEIYLf7sy+BGdw9sH/3NAVNiQEngOaD1dF7OJ9XAY g9v6qS+rDOw50I/55BWm4DGn3MVHYKJlQZ9YJquIwT/Bm74M2vfdwwkOV0RQs9ep 06xq5j7jpnKxQgwnGY8weyrvj+k6l/7aO4Vk1ejtgGFo7w4CblT61a4D2Bi5veFv yDMWa9GOyY/jhg368Nrz73033lNj2ifyr1rBsTDzxW5CaVB7Kh4fsLv/o2ybGz1m 0ezPF+eIv6DNKUsafBdSCn3xagHCEDpdZt67nIeJWJKTKJGTL0YbCeYFWCanL5pK E348Cen+6k+hLfVlDTlMWz7eJxIO2dpoIgslQrc3TMSy1yym6QfjjtyXrfR84c0= =b2PB -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 14 07:18:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997BE1B3570 for ; Thu, 14 Jan 2016 07:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 9RAuknYHuB95 for ; Thu, 14 Jan 2016 07:18:41 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 37FA31B356E for ; Thu, 14 Jan 2016 07:18:40 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id 6so405140061qgy.1 for ; Thu, 14 Jan 2016 07:18:40 -0800 (PST) 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:content-type; bh=rbBjXT9zyaBvPc9lPCiFjVH8SfWfub8Td9sN6RUK8eM=; b=RbsB2n3JVTPxw8fFyq3yQCmm6mZEBwC2PJUTBOupVX2thh5jwnEwWwCTRBIQym2n58 tymPV8cWXjWnqOtXfVJ7yjSgaSPK5px5rbrpgaxNQ6GMOOm81Fj280OS7svLiTQev5zB hoAeQ8u/iz/phsmi7RYrAxTMQePG6lUBt7yxtPulIO/5LUZlz/w2KKzP8YnaDW3uJlk8 hUDV8WrTZxlunmYXk8ZupQQT3Uwhei0hmZbgXMtDtUzv1TT9O3OVXznPVp1RptEe2M2J NadpYLiI81IWWeaFxxIbMI5jRZyZUelhcYlr2zKMKeGmlwWEyhzQhbhc1qcNT18WvIjP Q4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rbBjXT9zyaBvPc9lPCiFjVH8SfWfub8Td9sN6RUK8eM=; b=I7TzGLdt7DnKEWFW0sLA3YwQ4sC88srZsLTIzn15u0HfXnSHvuyTIocDGQJe/+XE6I S+qTGnCI6rxWblWircUjXpTK5lIx+ktvMhZtWgrOjRFif3mbNCwhYQvLW3a4eapUeXQx 0FZ5wp2e7v5zTVbAw14eYQ1YiTRA6wWljDxsrLzqeYdazWSUZXCkQors9L9PUVbkRszr OtKzmPyrJbqnw6uFhhsaLfgpiIJVI+4LfS6xU+RdKiA8UOE0nDpjW1W4t6xgqlhBA0jC eQ8jKQspTMHURxBopmeaJPGIRA1Csp7SYIbUOwnAjyEI2lAhWx+EaEeE/8Dq/sg4XIs4 ew9w== X-Gm-Message-State: ALoCoQm6ne4vm2Wd8yRp9Zv8krvNVa6GuIr5i8kKfFnHxHg2L2bIOezGzFwSIsiPL99h+ObHhlYUtzb2tRhrT3OXMZ3Dx+OSvA== X-Received: by 10.129.153.3 with SMTP id q3mr3506840ywg.231.1452784719265; Thu, 14 Jan 2016 07:18:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 14 Jan 2016 07:17:59 -0800 (PST) In-Reply-To: <8737u0gpm5.fsf@latte.josefsson.org> References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> From: Eric Rescorla Date: Thu, 14 Jan 2016 07:17:59 -0800 Message-ID: To: Simon Josefsson Content-Type: multipart/alternative; boundary=94eb2c0bbfae20b70305294ccdc8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 15:18:42 -0000 --94eb2c0bbfae20b70305294ccdc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I concur. -Ekr On Thu, Jan 14, 2016 at 7:14 AM, Simon Josefsson wrote: > Allocating a code point for X25519 could be done and is long overdue > (first draft September 2013). X448 is also stable. Code points for > Ed25519 and Ed448 is more problematic since TLS authentication has > historically had interaction with PKIX certs. I agree with Yoav's > assertion that the curve point verification issue is not big enough to > stall code point allocation. > > /Simon > > Joseph Salowey writes: > > > Hi All, > > > > Looks like I jumped too soon on this one. In particular, both the CFRG > > signature draft and 4492bis need to be updated. Let's hold of on code > > point assignment until then. > > > > Thanks, > > > > Joe > > (crawling back under my rock now) > > > > On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov < > alexey.melnikov@isode.com> > > wrote: > > > >> > >> > On 12 Jan 2016, at 21:31, Ilari Liusvaara > >> wrote: > >> > > >> >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > >> >> > >> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson > >> wrote: > >> >>> > >> >>> The same concern still applies: what does it mean to allocate code > >> >>> point for the 4492bis-05 description? > >> >> > >> >> Allocating code points just means an implementation of draft-05 is > >> >> likely to interoperate just fine with an implementation of the fina= l > >> >> RFC. > >> >> > >> >> Of course nothing is ever final until the RFC is out, so there=E2= =80=99s > >> >> always a risk involved, but it is considered prudent to allocate > >> >> numbers when we=E2=80=99re reasonably certain of the calculations a= nd on- > >> >> the-wire formats. Any debate about whether we should or should not > >> >> check certain inputs for certain conditions need not be a bar for > >> >> allocating numbers. > >> > > >> > Assuming CFRG chairs really did declare consensus on Ed448 hash, the= n > >> > the final characteristics of Ed448 are known and I have a reference > >> > implementation. > >> > > >> > And the PKIX draft looks implementable (has wrong example?) > >> > > >> > More serious interop hazard is what to do with X25519/X448 and THS > >> > (some of the proposed stuff is not wire-compatible). > >> > >> This CFRG co-chair would like to see an updated CFRG draft before the > code > >> point is allocated. > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0bbfae20b70305294ccdc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I concur.

-Ekr


On Thu, Jan 14, 2016 at 7:1= 4 AM, Simon Josefsson <simon@josefsson.org> wrote:
Allocating a code point for X25519 could be done= and is long overdue
(first draft September 2013).=C2=A0 X448 is also stable.=C2=A0 Code points = for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.=C2=A0 I agree with Yoav's=
assertion that the curve point verification issue is not big enough to
stall code point allocation.

/Simon

Joseph Salowey <joe@salowey.net&g= t; writes:

> Hi All,
>
> Looks like I jumped too soon on this one.=C2=A0 In particular, both th= e CFRG
> signature draft and 4492bis need to be updated.=C2=A0 Let's hold o= f on code
> point assignment until then.
>
> Thanks,
>
> Joe
> (crawling back under my rock now)
>
> On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov <alexey.melnikov@isode.com>
> wrote:
>
>>
>> > On 12 Jan 2016, at 21:31, Ilari Liusvaara <ilariliusvaara@welho.com>
>> wrote:
>> >
>> >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:=
>> >>
>> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson <simon@josefsson.org>
>> wrote:
>> >>>
>> >>> The same concern still applies: what does it mean to = allocate code
>> >>> point for the 4492bis-05 description?
>> >>
>> >> Allocating code points just means an implementation of dr= aft-05 is
>> >> likely to interoperate just fine with an implementation o= f the final
>> >> RFC.
>> >>
>> >> Of course nothing is ever final until the RFC is out, so = there=E2=80=99s
>> >> always a risk involved, but it is considered prudent to a= llocate
>> >> numbers when we=E2=80=99re reasonably certain of the calc= ulations and on-
>> >> the-wire formats. Any debate about whether we should or s= hould not
>> >> check certain inputs for certain conditions need not be a= bar for
>> >> allocating numbers.
>> >
>> > Assuming CFRG chairs really did declare consensus on Ed448 ha= sh, then
>> > the final characteristics of Ed448 are known and I have a ref= erence
>> > implementation.
>> >
>> > And the PKIX draft looks implementable (has wrong example?) >> >
>> > More serious interop hazard is what to do with X25519/X448 an= d THS
>> > (some of the proposed stuff is not wire-compatible).
>>
>> This CFRG co-chair would like to see an updated CFRG draft before = the code
>> point is allocated.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


--94eb2c0bbfae20b70305294ccdc8-- From nobody Thu Jan 14 15:22:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121041A19E4 for ; Thu, 14 Jan 2016 15:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 w-NdaMvRKhTu for ; Thu, 14 Jan 2016 15:22:16 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F301A19E3 for ; Thu, 14 Jan 2016 15:22:16 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id is5so96741690obc.0 for ; Thu, 14 Jan 2016 15:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Pr8weIn/ZJzBtjtWZuelbB20d3S1JOigpE5njhB30s=; b=cKEhv+8d/HNAQ4jXolzvgGk/82Kx3yPGE4QIaOcKlNQeHDYT7fbEvh7d/jUhoYTQ5h jJbIJEPZ/oU9OIJjJFepIkt2QHDC3fQ8DuAo1JLlgq9QY08AOWvJGPA376R46WoP+5KH zWeLTBCbp0poI0mGnxagbA6wD5ypyjiRWoIpTEhI1eQv3OksJmIxz3eRcqiWaAfFM6Ak jd617E5mOV/kIH8PsNtLVqHVXk447zDbc4vL0uNQwR8PAUfORnjBtkfzknn4qXqafw8S ApSpVlP+7XznUbTz9axBvEuVuSj1hD2csTC2p4P+H4uIYpndaZXmvnT6+TFBTlNlslSr D3Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Pr8weIn/ZJzBtjtWZuelbB20d3S1JOigpE5njhB30s=; b=m1CNhEfJGeOAiy3DKyY4O0YawA2WLoWuRhUhB2OPNkTD2Ua/8Iq/pgFXZJg4HmlpcF ZPVsgS21qn4Ug3mm39/wDx6BBUriixjV4lAMU686fQgzDXIDogR8oKRBZWzfnNSvr9GT rFvD0cGi3c0G79L0CvyYeAs9Ariz2muBid2hR8X/Y5kgsUevJa1vDMEv3PqXPWl8SCI1 gmRbIMmd9pczdkI8K2+54JkA9Gvs/JOW+QQ+YiIES7EJ11F7j6eYHJ1RVYbQmhNri4DZ nqmAmTfI2M3Ok47V5fc0JLFUEFEPthZiLSW1fp/YvwvsrazT9ml8LqBGB+G79AuFfsOm ZmYg== X-Gm-Message-State: ALoCoQmmxnul/1YgfdoIYKjImk3NbcCbEWJsE6mwKsVQewlKTKVGaluWGA98bP2+MBogn7Hrqdes8sf7GMAxJXHvaf4ElJv0fA== MIME-Version: 1.0 X-Received: by 10.60.134.202 with SMTP id pm10mr5680066oeb.50.1452813735440; Thu, 14 Jan 2016 15:22:15 -0800 (PST) Received: by 10.76.170.225 with HTTP; Thu, 14 Jan 2016 15:22:15 -0800 (PST) In-Reply-To: <8737u0gpm5.fsf@latte.josefsson.org> References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> Date: Thu, 14 Jan 2016 13:22:15 -1000 Message-ID: From: Brian Smith To: Simon Josefsson Content-Type: multipart/alternative; boundary=047d7b417a63a04e8e0529538e4e Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:22:17 -0000 --047d7b417a63a04e8e0529538e4e Content-Type: text/plain; charset=UTF-8 Simon Josefsson wrote: > Allocating a code point for X25519 could be done and is long overdue > (first draft September 2013). X448 is also stable. Code points for > Ed25519 and Ed448 is more problematic since TLS authentication has > historically had interaction with PKIX certs. I agree with Yoav's > assertion that the curve point verification issue is not big enough to > stall code point allocation. I agree with this. Cheers, Brian --047d7b417a63a04e8e0529538e4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simo= n Josefsson <simon@josefsson.org> wrote:
Allocating a code point for X25519 could be done and is lo= ng overdue
(first draft September 2013).=C2=A0 X448 is also stable.=C2=A0 Code points = for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.=C2=A0 I agree with Yoav's=
assertion that the curve point verification issue is not big enough to
stall code point allocation.

I agree with t= his.

Cheers,
Brian
--047d7b417a63a04e8e0529538e4e-- From nobody Fri Jan 15 12:45:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641C91B3224 for ; Fri, 15 Jan 2016 12:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 vlejhplHNVRq for ; Fri, 15 Jan 2016 12:45:45 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843C91A8A4A for ; Fri, 15 Jan 2016 12:45:45 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 1so451664669ion.1 for ; Fri, 15 Jan 2016 12:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=zeI0FsuWW4qAyCklAnh2Y8q2Lx+bCv0wdMFv9O8zGKk=; b=a2Xra4/WKVm/UvCzX6JPwWPuRcjv4iIxgjJvgegZHwTpQHwPbTaTvDPE5LKUzwt3WM ND7+orX/Ng+0gXPo+gQ1Npgm166ZTB4i4uWUgMhYvjagSNoUMb9mwcadqa5oj99Q8tMw Jrc4pV77ki0kYBKvtjdl+tbmvjde6I3RWg9vU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=zeI0FsuWW4qAyCklAnh2Y8q2Lx+bCv0wdMFv9O8zGKk=; b=nCq0pA4A+bj4+0H5C7NXr177yIQHGbQORwR5sYPtQ+pKZzpZq9cZXn5VKQUCl1Aje1 M3NQF0hxobaq4pi1Ep5QbbQEjNkFjyRSYhXcKEQDSARfykRF+1VocmDfC903cYtw7QLM pONYmJN12S+9zYBblj4CNqav0qvhuiqzqtYEvb06wvRBLY1001WPQUJd095kuIQ4nJlr pMJYHqn7/eUNX3KUioL+eW82bulbKAh1BR/18z5Cishtqni6jLYImknEUCHksdf98EPK Cxbv/hOHa5QMXBzkWS9a2pTdKfG/EdVe5OYhBvQDaiBSqU7DduEZTQs0/x+5tIFgWnNa MZmQ== X-Gm-Message-State: ALoCoQn2RCI5Rvfn7RXGnw7dF3eswR+Y528VGopDUYMYJl2GumAYHOzfInToYC1EJuvc0XwoMCrzNp0aTTvFGUiS6cMBeKMibZXgVjaUa3v5EljF6+iZUkc= X-Received: by 10.107.10.65 with SMTP id u62mr11981977ioi.120.1452890744756; Fri, 15 Jan 2016 12:45:44 -0800 (PST) MIME-Version: 1.0 From: David Benjamin Date: Fri, 15 Jan 2016 20:45:34 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ecd44bd74f10529657c4f Archived-At: Subject: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jan 2016 20:45:47 -0000 --001a113ecd44bd74f10529657c4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature algorithms are spread across the handshake. We have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registries. NamedGroup is sent in one list, also used for (EC)DH, while the other two are sent as a pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in separate registries. This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to be messy to implement. Client certificate keys may be in smartcards via OS-specific APIs, so a lot of time is spent transiting new preference shapes across API boundaries in order to discover smartcard bugs. Sometimes I think people deploy client certs because they hate me and want to cause me pain=E2=80=A6 :-) Anyway, the new CFRG curves also bind signature curve and hash together. The current draft represents this as eddsa_ed25519 and eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this doesn=E2=80=99t capture = that EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.) I propose we fold the negotiable parameters under one name. Think of how we=E2=80=99ve all settled on AEADs being a good named primitive with a comm= on type signature[1]. Specifically: 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now on, NamedGroup is only used for (EC)DH. 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as they are. Introduce a new SignatureAlgorithm u16 type and negotiate that instead. (Or maybe a different name to not collide.) u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty. 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with HashAlgorithm from TLS 1.2. Note this does not introduce new premultiplications on the wire. Just in the spec and registry. 4. Deprecate ecdsa_sha256, etc., in favor of new ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this introduces new premultiplications, it=E2=80=99s only 9 values with the prun= ed TLS 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and curve pre-specified. (See [2] at the bottom for full list of allocations.) Thoughts? David [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need some map= ping to a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14. And RSA key generation still has size parameter. Hopefully future things can look more like Ed25519. [2] 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note this is wire-compatible with TLS 1.2. - 0x0101 - rsa_pkcs1_md5 - 0x0201 - rsa_pkcs1_sha1 - 0x0301 - rsa_pkcs1_sha224 - 0x0401 - rsa_pkcs1_sha256 - 0x0501 - rsa_pkcs1_sha334 - 0x0601 - rsa_pkcs1_sha512 - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but ignored in TLS 1.3. 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to avoid colliding with existing signature algorithms, but I don=E2=80=99t thi= nk that=E2=80=99s necessary[3]. - rsapss_sha256 - rsapss_sha384 - rsapss_sha512 - ecdsa_p256_sha256 - ecdsa_p256_sha384 - ecdsa_p256_sha512 - ecdsa_p384_sha256 - ecdsa_p384_sha384 - ecdsa_p384_sha512 - ecdsa_p521_sha256 - ecdsa_p521_sha384 - ecdsa_p521_sha512 - eddsa_ed25519 - eddsa_ed448 0xfe00-0xffff - reserved for private use, compatible with existing HashAlgorithm reservation. [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7), RSA}, they should ignore it since hash 7 doesn't exist. --001a113ecd44bd74f10529657c4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

This is a proposal for revisi= ng SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature algorithms are s= pread across the handshake. We have SignatureAlgorithm, NamedGroup/Curve (f= or ECDSA), and HashAlgorithm, all in independent registries. NamedGroup is = sent in one list, also used for (EC)DH, while the other two are sent as a p= air of (HashAlgorithm, SignatureAlgorithm) tuples but live in separate regi= stries.

This is a lot of moving parts. Signature negotiation in TLS = 1.2 tends to be messy to implement. Client certificate keys may be in smart= cards via OS-specific APIs, so a lot of time is spent transiting new prefer= ence shapes across API boundaries in order to discover smartcard bugs. Some= times I think people deploy client certs because they hate me and want to c= ause me pain=E2=80=A6 :-)

Anyway, the new CFRG curves also bind sign= ature curve and hash together. The current draft represents this as eddsa_e= d25519 and eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this d= oesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA= + FF3072.)

I propose we fold the negotiable parameters under one na= me. Think of how we=E2=80=99ve all settled on AEADs being a good named prim= itive with a common type signature[1]. Specifically:

1. Drop eddsa_e= d25519(31) and eddsa_ed448(32) from NamedGroup. From now on, NamedGroup is = only used for (EC)DH.

2. Remove HashAlgorithm, SignatureAlgorithm, S= ignatureAndHashAlgorithm as they are. Introduce a new SignatureAlgorithm u1= 6 type and negotiate that instead. (Or maybe a different name to not collid= e.) u8 is a little tight to allocate=C2=A0eddsa_ed25519 and=C2=A0eddsa_ed44= 8 separately, but u16 is plenty.

3. Allocate values for SignatureAlg= orithm wire-compatibly with TLS 1.2 by (ab)using the old (HashAlgorithm, Si= gnatureAlgorithm) tuples. 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ran= ges consistently with HashAlgorithm from TLS 1.2. Note this does not introd= uce new premultiplications on the wire. Just in the spec and registry.
<= br>4. Deprecate ecdsa_sha256, etc., in favor of new ecdsa_{p256,p384,p521}_= {sha256,sha384,sha512} allocations. The old ecdsa_* values are for TLS 1.2 = compatibility but ignored in TLS 1.3. Although this introduces new premulti= plications, it=E2=80=99s only 9 values with the pruned TLS 1.3 lists. I thi= nk this is worth 9 values to keep NamedGroups separate.

5. Add new a= llocations for eddsa_ed25519, eddsa_ed448, and rsapss_{sha256,sha384,sha512= }. These come with the signature algorithm and curve pre-specified. (See [2= ] at the bottom for full list of allocations.)

Thoughts?

Davi= d

[1] We=E2=80=99re stuck with RSA-PSS's generality, so that'= ;ll need some mapping to a subset of X.509's RSA-PSS. We'll just no= t bother with RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm MGF-7-v3= .0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14. And RSA = key generation still has size parameter. Hopefully future things can look m= ore like Ed25519.

[2]
0x0000-0x06ff - Reserved range for TLS 1.2 = compatibility values. Note this is wire-compatible with TLS 1.2.
- 0x010= 1 - rsa_pkcs1_md5
- 0x0201 - rsa_pkcs1_sha1
- 0x0301 - rsa_pkcs1_sha2= 24
- 0x0401 - rsa_pkcs1_sha256
- 0x0501 - rsa_pkcs1_sha334
- 0x060= 1 - rsa_pkcs1_sha512
- 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. <= br>- 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but= ignored in TLS 1.3.

0x0700-0xfdff - Allocate new values = here. Optionally avoid 0x??0[0-3] to avoid colliding with existing signatur= e algorithms, but I don=E2=80=99t think that=E2=80=99s necessary[3].
- r= sapss_sha256
- rsapss_sha384
- rsapss_sha512
- ecdsa_p256_sha256- ecdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p384_sha256
- ec= dsa_p384_sha384
- ecdsa_p384_sha512
- ecdsa_p521_sha256
- ecdsa_p5= 21_sha384
- ecdsa_p521_sha512
- eddsa_ed25519
- eddsa_ed448
0xfe00-0xffff - reserved for private use, compatible with existing HashAlg= orithm reservation.

[3] If a TLS 1.2 implementation sees 0x0701 and = interprets it as {hash(7), RSA}, they should ignore it since hash 7 doesn&#= 39;t exist.
--001a113ecd44bd74f10529657c4f-- From nobody Fri Jan 15 16:08:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FB11B3422 for ; Fri, 15 Jan 2016 16:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 sUM194NJj5R3 for ; Fri, 15 Jan 2016 16:08:34 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07611B3421 for ; Fri, 15 Jan 2016 16:08:33 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id is5so123436525obc.0 for ; Fri, 15 Jan 2016 16:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G9Unnb/T64QfZOTpK5IJyImkeizpRyvx0lu0PcJHv4w=; b=FMCVTWb8PeWRpJfaxFAVw4gH/xDhtD0wv5mR3lYrBf+4dqOnL2k2VeYNlXKRUrIBlR 5t1Gk/p6ELotd1OiofEKyw1QNQDMdKF60uyOeTR1evTgqV4H68uvTPw6RG7jeLPRYcav uAZtsDW8QElXImxSq3mUFpRh6KKdO3VM82q/YVcr4N10JYa8f5ZaFMzMBfzFEAO/EKOb +CEyr3hSleZfKOaYAWFdwRAg6W/QopzTDX5aqnEDptmHHAUrmy9tdUUpEOBbbMFgyRZw 1ua6yauWItgjsccLboXZuDUO9VJA/6MeVSh1gDHtroR1nw3mOY9YI3e3qAyeaVD973si Tsrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G9Unnb/T64QfZOTpK5IJyImkeizpRyvx0lu0PcJHv4w=; b=BqOh1iIFlcuAMIibzibSSG7N78NZFiB/bMi864TRKGbqGWbiweVi3/F90vBbAtrJJX OZgFMCrj3/wPup9qtiJHqAQd2XhGAUrjVTjh0agezX22Ru4ahLkr6Ig1bBcCILlxp2v2 +cGA84PXLrZ76KYCyUE/7JOYeK18oG3NpxpO2HBbqylscL8Ab0bUdxlL/xInLag8sKkX TmA9KHx/hvHtXxFCjHaZFcRDv582dXoisjF3NYw13ASm7Jea4FXO7YeFUboRMscH79rf 9tq+4fbzQdYkZwNrwCT62xqnCfwFSj/I/FWsGN7gwfahYFqxEK4KGm0mNpN2Lhl72Pxb mkJA== X-Gm-Message-State: ALoCoQmjhJbCy+U7iOF/CDnPns+b1uGmXfvMzzRkczxzdKLMHLLgO/L1hshIH9/7zb3QLlbfAXu12yxkdBbRv8ru/qfQYkC/DA== MIME-Version: 1.0 X-Received: by 10.60.177.67 with SMTP id co3mr11058065oec.62.1452902913253; Fri, 15 Jan 2016 16:08:33 -0800 (PST) Received: by 10.76.170.225 with HTTP; Fri, 15 Jan 2016 16:08:33 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Jan 2016 14:08:33 -1000 Message-ID: From: Brian Smith To: David Benjamin Content-Type: multipart/alternative; boundary=047d7bd7646809bcf80529685248 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 00:08:35 -0000 --047d7bd7646809bcf80529685248 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David Benjamin wrote: > 4. Deprecate ecdsa_sha256, etc., in favor of new > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_= * > values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although thi= s > introduces new premultiplications, it=E2=80=99s only 9 values with the pr= uned TLS > 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. > Have you considered the possibility of using this mapping?: TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256. TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384. TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521. Then: 1. You don't have to define any new values. 2. The extension size would be smaller. 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. (I don't have any particular affinity for that profile other than it seems to have made choices that have historically been shown to be above average, and it might be a good idea to avoid interop failure with other implementations that might have a special affinity for it.) 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and > rsapss_{sha256,sha384,sha512}. > This seems like a good idea to me. > [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need some m= apping to > a subset of X.509's RSA-PSS. > I believe this is already largely taken care of in TLS 1.3 by fixing all the parameters to be a function of the digest algorithm used for the message. - ecdsa_p256_sha384 > - ecdsa_p256_sha512 > - ecdsa_p384_sha256 > - ecdsa_p384_sha512 > - ecdsa_p521_sha256 > - ecdsa_p521_sha384 > The subset of your proposed values I listed above do not seem helpful. For example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get truncated to 256 bits. > 0xfe00-0xffff - reserved for private use, compatible with existing > HashAlgorithm reservation. > > [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7)= , > RSA}, they should ignore it since hash 7 doesn't exist. > I think we should expect more pure ECC (no RSA) deployments soon. In that case, it would be better if new ECC-based values used the value "ECDSA" (3) instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them as support for RSA. [1] https://tools.ietf.org/html/rfc6460 Cheers, Brian --=20 https://briansmith.org/ --047d7bd7646809bcf80529685248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Davi= d Benjamin <davidben@chromium.org> wrote:
4. Deprecate ecdsa_sha256, etc., in favor of ne= w ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_= * values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although thi= s introduces new premultiplications, it=E2=80=99s only 9 values with the pr= uned TLS 1.3 lists. I think this is worth 9 values to keep NamedGroups sepa= rate.

Have you considered t= he possibility of using this mapping?:

TLS 1.2'= ;s { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
TLS 1.2&= #39;s=C2=A0{=C2=A0ecdsa, sha384=C2=A0}=C2=A0is TLS 1.3's ecdsa_p384_sha= 384.
TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_= sha521.

Then:
1. You don't have to d= efine any new values.
2. The extension size would be smaller.
=
3. You get better interoperability with TLS 1.2's NSA S= uite B profile [1]. (I don't have any particular affinity for that prof= ile other than it seems to have made choices that have historically been sh= own to be above average, and it might be a good idea to avoid interop failu= re with other implementations that might have a special affinity for it.)

5. Add new = allocations for eddsa_ed25519, eddsa_ed448, and rsapss_{sha256,sha384,sha51= 2}.

This seems like a good idea= to me.
=C2=A0
[1] We= =E2=80=99re stuck with RSA-PSS's generality, so that'll need some m= apping to a subset of X.509's RSA-PSS.
I believe this is already largely taken care of in TLS 1.3 by f= ixing all the parameters to be a function of the digest algorithm used for = the message.

- e= cdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p384_sha256
- ecdsa_p= 384_sha512
- ecdsa_p521_sha256
- ecdsa_p521_sha384

The subset of your proposed values I listed a= bove do not seem helpful. For example, a P-256 signature of a SHA-384 or SH= A-512 hash is going to get truncated to 256 bits.
=C2=A0
0xfe00-0xffff - reserved for private us= e, compatible with existing HashAlgorithm reservation.

[3] If a TLS = 1.2 implementation sees 0x0701 and interprets it as {hash(7), RSA}, they sh= ould ignore it since hash 7 doesn't exist.

I think we should expect more pure ECC (no RSA) deployments= soon. In that case, it would be better if new ECC-based values used the va= lue "ECDSA" (3) instead of RSA (1) so that TLS 1.2 implementation= s do not misinterpret them as support for RSA.


Cheers,
Brian
--
--047d7bd7646809bcf80529685248-- From nobody Fri Jan 15 16:59:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0931B34BA for ; Fri, 15 Jan 2016 16:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWr6PC48Pv63 for ; Fri, 15 Jan 2016 16:59:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E811B34BC for ; Fri, 15 Jan 2016 16:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6FDBCBEC6 for ; Sat, 16 Jan 2016 00:59:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP6urDBZe1Lc for ; Sat, 16 Jan 2016 00:59:47 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.41.53.98]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B25FBE55 for ; Sat, 16 Jan 2016 00:59:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452905987; bh=9IrBOtq6btlBjLTAycCA/eAXTRV0MqAkxegtRtQdNyY=; h=From:Subject:References:To:Date:In-Reply-To:From; b=bafo8wBUbNlUFaJY3Nj7GdNSV8gi6FhooqUKtMpZtlJ8N/Za4tA9kgfTQSAOEAnRs yuPIDxMWXQAjlqhKp2kfCjSG6fdmjVYilJr1sR0QTikcjRCk1TUDQwWpwoH04rri78 FJ8opE2LlZXm5Zkw8Xr0ck4lu5U3cQ5e/BvMsTpc= From: Stephen Farrell References: <20160116005444.17735.40712.idtracker@ietfa.amsl.com> To: "tls@ietf.org" Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56999602.2050705@cs.tcd.ie> Date: Sat, 16 Jan 2016 00:59:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160116005444.17735.40712.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Fwd: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 00:59:51 -0000 We discussed this topic briefly at IETF94 and in more detail at the Marnew workshop. There seemed to be at least enough interest for a list so... Cheers, S. PS: I'd say best to wait 'till next Wednesday or so to start list discussion so that folks have time to join the list. -------- Forwarded Message -------- Subject: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys Date: Fri, 15 Jan 2016 16:54:44 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: @ericsson.com, stephen.farrell@cs.tcd.iedaniel.migault, lurk@ietf.org A new IETF non-working group email list has been created. List address: lurk@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=lurk To subscribe: https://www.ietf.org/mailman/listinfo/lurk Purpose: Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based the proof of ownership of a private key. Currently most trust models assume the private key is associated and owned by the peer. In addition, the remote peer is both responsible of the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of service on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application, - like a web browser - expects to authenticate a content provider while authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content. There may be a BoF at IETF95 to discuss this topic. For additional information, please contact the list administrators. From nobody Fri Jan 15 17:07:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C61B34AD for ; Fri, 15 Jan 2016 17:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeROPg9Y-k-0 for ; Fri, 15 Jan 2016 17:07:15 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D902D1B34AC for ; Fri, 15 Jan 2016 17:07:14 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id e32so432947896qgf.3 for ; Fri, 15 Jan 2016 17:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=TTp0Je0KVKcR0f0iDWjTIrKwXx0J8O7dL2ED4RSRDzA=; b=YEj01Md8BtNowwBtVhRnSmBt5asZN5d+QjmTHduhlv3ZRVI1wsIFGVvXq8K0QJWPJ3 2zYWCd6vClJKNZzdcida6jbdYFma5r8WvECdctB8hOLxCDi5gg5tIw+3KR9qh5JwjEt9 VAFlz3mJ2KTGdbCGOiLGn+U/32Uma6sbewv5LWmUydo8A4Kw+tIJt6Vc+3wq7J+Qjkzy //eIXJdvw94/I+g4InFp66XyZIzyznArx2AWuPo+rS5zT8l3QWUAZ2lwsFUnFjgUuDhB 6yseJCNzJLjw1TR+Ce8Wx9gCjlKue7DXCNUCci+HHtT7iJsKtudn2wRlrQoRy4LMeG7R PGjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=TTp0Je0KVKcR0f0iDWjTIrKwXx0J8O7dL2ED4RSRDzA=; b=BNu9VE4+PJMtnyLhEAWSRWDiHA/lw3i+A9UrIWsHBgIp6NtLpWGL1dGWNQpUSXoOX+ bzc91HUX+jp5JPr6tt2FqwrFvzrc0pSab7mwtCvqAA1mYHjrHIMSJ2htFHWi8I2C/2w2 jqUTUKjd3O/io2gfSfL7I8YiSPMn3VaIYtMnL40vYNpuil6gmP5CkdwaI+jj3KLNnIR1 wOCt6NnZLtDsrFyA5Yvshk3gR+qC/OU1wWpsmsca9oJ+QJXwRjRtipKt5CqOJsiJSxVD Nym/A6gRznPfER/69TVGHCdjZhgBb5//jc+lG2uDQKuMH6eB2F3+U3AWVRTKcMLCk6Tk 8IyA== X-Gm-Message-State: ALoCoQmkY/ukJnBFTUe8y5SUQkqDqfy/wNpw7yWqrPeKqWBzDHNMbBIFOfeIPiyhAa0v5Z3ZElpidyC/o6RR6m8ooE4wRE3zNQ== X-Received: by 10.140.142.207 with SMTP id 198mr18151121qho.77.1452906434022; Fri, 15 Jan 2016 17:07:14 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id a5sm5547708qga.46.2016.01.15.17.07.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 15 Jan 2016 17:07:13 -0800 (PST) From: Dave Garrett To: David Benjamin Date: Fri, 15 Jan 2016 20:07:12 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201601152007.12464.davemgarrett@gmail.com> Archived-At: Cc: ekr , tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 01:07:16 -0000 On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. [...] > I propose we fold the negotiable parameters under one name. [...] > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > instead. I previously proposed this here: https://www.ietf.org/mail-archive/web/tls/current/msg18035.html ekr was against it, though it hasn't been discussed that throughly. https://www.ietf.org/mail-archive/web/tls/current/msg18036.html Dave From nobody Fri Jan 15 17:10:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8D1B34BD for ; Fri, 15 Jan 2016 17:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_FuHEamsZA6 for ; Fri, 15 Jan 2016 17:10:17 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79B41B2B0C for ; Fri, 15 Jan 2016 17:10:16 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id z14so24482706igp.0 for ; Fri, 15 Jan 2016 17:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=T569sDQd9m7t8oGPVQ1dQmmuG/V3+9XSA747pWmcZEawYD7Hxg5j0cBEPEKi3/XSTZ V+7xEh2/n7XVx+fq6gIRM+cQ2xmjbb+/TB0UtMcCa4jBnWozJvx3yFpQ1rE6oyVcTzsE jHR7hXRWs5EfHt4T47igsfU+GaYRVmmJ4jr2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=PB/KXGJOb2BZjmk+VdLVuxHhj2JWy0//5PtAj34F7oSRDWZgIZutOq3ZyFAHMoI/yO 2AMF0rZCs0ZnvD/gVNYcdVx1Ve4KveGLnlYCZ+1vI/HyNWFtXFjv8VfN7rJ7XUZm6pD/ R1FSLzWcJPY08RNOsgNulDDEkjgzKSaHQCOeDY8oY6yqhvs+jKNUCD7OkUYc19hcXROK vdYtLNV1WETMX139ghPMQqnG4JU9tl/Yx6yzzlPz8k4+BbxqydRGAvwmIv6hn81DgVQL OyZbPQJMEjVB66mp7gk5KlT7AmeRawQC6B78d8HxAON+UCZK4buywTHOqvKCZF4tJ/2X OSdg== X-Gm-Message-State: AG10YORGAOxnEI8uLuLZqqE4331uMkYLpglNv8h6DAhkdFE844nSjqD266/Ce6ipz3ocMFdcVJBjOh19ttjfvDRC X-Received: by 10.50.134.129 with SMTP id pk1mr1365490igb.11.1452906616225; Fri, 15 Jan 2016 17:10:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Sat, 16 Jan 2016 01:10:06 +0000 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=047d7b2e3fe6c0b0e20529692ee5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 01:10:19 -0000 --047d7b2e3fe6c0b0e20529692ee5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote: > David Benjamin wrote: > >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa= _* >> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although th= is >> introduces new premultiplications, it=E2=80=99s only 9 values with the p= runed TLS >> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. >> > > Have you considered the possibility of using this mapping?: > > TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256. > TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384. > TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521. > > Then: > 1. You don't have to define any new values. > 2. The extension size would be smaller. > Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can lose them. I just wrote out all 9 without thinking about it much. Apart from "please don't cause me interop pain", I don't have strong opinions about how aggressively we prune the list. My main worry is, for better or worse (I realize this is a point of contention), some servers apply sigalgs to both CertificateVerify and certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a nuisance. Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though it would prevent them from adopting TLS 1.3 without switching certificates. Alternatively, if people decide that sigalgs and certificates officially have nothing to do with each other in TLS 1.3, then things are fine but we wouldn't have a way to negotiate such algorithms. I was hoping to avoid that issue for this proposal, but there is some interaction. (Whether such certificates exist on the web is probably answerable via CT logs, but I haven't checked.) If changing the existing meaning is a nuisance, another option is to continue to allocate new values but only define ecdsa_p256_sha256, ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset is) for TLS 1.3 and later. > 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]= . > (I don't have any particular affinity for that profile other than it seem= s > to have made choices that have historically been shown to be above averag= e, > and it might be a good idea to avoid interop failure with other > implementations that might have a special affinity for it.) > What interop faliures are you worried about here? > - ecdsa_p256_sha384 >> - ecdsa_p256_sha512 >> - ecdsa_p384_sha256 >> > - ecdsa_p384_sha512 >> - ecdsa_p521_sha256 >> - ecdsa_p521_sha384 >> > > The subset of your proposed values I listed above do not seem helpful. Fo= r > example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get > truncated to 256 bits. > Good point. That makes some of the combinations unlikely. > [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7)= , >> RSA}, they should ignore it since hash 7 doesn't exist. >> > > I think we should expect more pure ECC (no RSA) deployments soon. In that > case, it would be better if new ECC-based values used the value "ECDSA" (= 3) > instead of RSA (1) so that TLS 1.2 implementations do not misinterpret th= em > as support for RSA. > Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with 'ECDSA'. The same footnote applies. :-) I don't think it makes sense to strategically assign the second byte for new numbers. Either we believe TLS 1.2 implementations are unlikely to react to 0x0703 and not worry about it, or we believe they will and we reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to u16 hack is too silly and don't do it at all.) David --047d7b2e3fe6c0b0e20529692ee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 15= , 2016 at 7:08 PM Brian Smith <b= rian@briansmith.org> wrote:
=
Davi= d Benjamin <davidben@chromium.org> wrote:
4. Deprecate ecdsa_sha256, etc., in favor of ne= w ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_= * values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although thi= s introduces new premultiplications, it=E2=80=99s only 9 values with the pr= uned TLS 1.3 lists. I think this is worth 9 values to keep NamedGroups sepa= rate.

Have yo= u considered the possibility of using this mapping?:

TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
TLS 1.2's=C2=A0{=C2=A0ecdsa, sha384=C2=A0}=C2=A0is TLS 1.3's = ecdsa_p384_sha384.
TLS 1.2's { ecdsa, sha512 } is TLS 1.3'= ;s ecdsa_p521_sha521.
=C2=A0
=
=
Then:
1. You don't have to de= fine any new values.
2. The extension size would be smaller.

Hrm. That hadn'= ;t occurred to me, no. Fewer values sounds good, if we can lose them. I jus= t wrote out all 9 without thinking about it much. Apart from "please d= on't cause me interop pain", I don't have strong opinions abou= t how aggressively we prune the list.

My main worr= y is, for better or worse (I realize this is a point of contention), some s= ervers apply sigalgs to both CertificateVerify and certificates. If someone= has an ECDSA-P384-SHA256 certificate, changing the definition of { ecdsa, = sha256 } between TLS 1.2 and TLS 1.3 could be a nuisance.

Or maybe it won't? Such servers wouldn't be using TLS 1.3 r= ight now. Though it would prevent them from adopting TLS 1.3 without switch= ing certificates. Alternatively, if people decide that sigalgs and certific= ates officially have nothing to do with each other in TLS 1.3, then things = are fine but we wouldn't have a way to negotiate such algorithms. I was= hoping to avoid that issue for this proposal, but there is some interactio= n.

(Whether such certificates exist on the web is = probably answerable via CT logs, but I haven't checked.)

=
If changing the existing meaning is a nuisance, another option i= s to continue to allocate new values but only define ecdsa_p256_sha256, ecd= sa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset is)= for TLS 1.3 and later.
=C2=A0
3. You get better interoperability with TLS 1.2= 9;s NSA Suite B profile [1]. (I don't have any particular affinity for = that profile other than it seems to have made choices that have historicall= y been shown to be above average, and it might be a good idea to avoid inte= rop failure with other implementations that might have a special affinity f= or it.)=C2=A0

What interop faliures are you worried about here?
=C2=A0
- ecdsa_= p256_sha384
- ecdsa_p256_sha512
- ecdsa_p384_sha256
- ecdsa_p38= 4_sha512
- ecdsa_p521_sha256
- ecdsa_p521_sha384

The subset of your proposed values I listed = above do not seem helpful. For example, a P-256 signature of a SHA-384 or S= HA-512 hash is going to get truncated to 256 bits.
<= /blockquote>

Good point. That makes some of the combinat= ions unlikely.
=C2=A0
[3] If a TLS 1.2 implementation sees 0x0701 and= interprets it as {hash(7), RSA}, they should ignore it since hash 7 doesn&= #39;t exist.

I th= ink we should expect more pure ECC (no RSA) deployments soon. In that case,= it would be better if new ECC-based values used the value "ECDSA"= ; (3) instead of RSA (1) so that TLS 1.2 implementations do not misinterpre= t them as support for RSA.

Sure, if you like, read my sentence replacing '1' with '= ;3' and 'RSA' with 'ECDSA'. The same footnote applies. = :-)

I don't think it makes sense to strategically assign the sec= ond byte for new numbers. Either we believe TLS 1.2 implementations are unl= ikely to react to 0x0703 and not worry about it, or we believe=C2=A0they wi= ll and we reserve all numbers ending in 00-03. (Or we decide that this (u8,= u8) to u16 hack is too silly and don't do it at all.)

David
--047d7b2e3fe6c0b0e20529692ee5-- From nobody Fri Jan 15 17:19:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0091B34D2 for ; Fri, 15 Jan 2016 17:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 TICA74TveMJh for ; Fri, 15 Jan 2016 17:19:51 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 E5A701B2B45 for ; Fri, 15 Jan 2016 17:19:50 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id ik10so24515542igb.1 for ; Fri, 15 Jan 2016 17:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=I7bZQokv1sZLcM4+FS6nbwAI4reL1+Oj4Kirn+ZV93c=; b=VW2dAVSpWy5OMq0zwrxWiz5NLBstJA6fnOfZXFH0msclvRdKuB5eIFO1r8K1lkAdRu vosnE+9lmKUhKuDRHDeSRN3AIdUOmSWnmDE0AeGKPugX9Fk5H2Fd20HYCb4qIuzjbY9B zrWGjOZEE/yuExxCtdhZgE7YZLtE7oRCmX//M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=I7bZQokv1sZLcM4+FS6nbwAI4reL1+Oj4Kirn+ZV93c=; b=Sxb/tn2KneAMpoMw44frCqwiUxyZqZ2RUlctmW9B0gkrG7dM+J1yySewpYFvCiz5FG a7YMNneag4V/tm6XzaD+tyOQxAdhRjaDXBjo7QZkeG29laF1Fb8PykLGlQAu9GCzEGvq VQ+YmPlCI+voILk2n0J0zuB/iwJvFhZYx7yx2g3kgmOe7LegwVdcYr2BiPsFgOutbda0 60VMvS+3gCics2yNs9RiCDWwlAAV3tq7lw3lMcEmXBpA+fL0Xrbr8rZAeLkF5jUHJ0TV A4wddAlGWZJlfN3Yv58LTRcVHJBCYv4SDF5zNwOqaCDKcJ1jqE2vz9TR0uQineliY4rh 3BsQ== X-Gm-Message-State: AG10YOSAYKFrER7KSQvmZHRJa1wTPHY5LNFOPILspbPnYowjQF+izPgDcOo79fNcuCPiVaZFIihIHaIEd/LF70Oe X-Received: by 10.50.79.196 with SMTP id l4mr1402348igx.11.1452907190256; Fri, 15 Jan 2016 17:19:50 -0800 (PST) MIME-Version: 1.0 References: <201601152007.12464.davemgarrett@gmail.com> In-Reply-To: <201601152007.12464.davemgarrett@gmail.com> From: David Benjamin Date: Sat, 16 Jan 2016 01:19:40 +0000 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e01183f48f7d2840529695081 Archived-At: Cc: ekr , tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 01:19:52 -0000 --089e01183f48f7d2840529695081 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote: > On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > > 1.2, signature algorithms are spread across the handshake. > [...] > > I propose we fold the negotiable parameters under one name. > [...] > > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > > instead. > > I previously proposed this here: > https://www.ietf.org/mail-archive/web/tls/current/msg18035.html > > ekr was against it, though it hasn't been discussed that throughly. > https://www.ietf.org/mail-archive/web/tls/current/msg18036.html Ah, thanks! I must have missed this discussion. Or perhaps I saw it and forgot. ekr, are you still against this sort of thing? I think the new CFRG signature algorithms tying decisions together is a good argument for why we'd want this. If we believe this trend is to continue (and I hope it does. Ed25519 is a nice and simple interface), trying to decompose it all seems poor. David --089e01183f48f7d2840529695081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 15= , 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David Benjam= in wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. Or perha= ps I saw it and forgot.

ekr, are you still against this sort of thin= g? I think the new CFRG signature algorithms tying decisions together is a = good argument for why we'd want this. If we believe this trend is to co= ntinue (and I hope it does. Ed25519 is a nice and simple interface), trying= to decompose it all seems poor.

David
=C2=A0
--089e01183f48f7d2840529695081-- From nobody Fri Jan 15 17:23:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258F1B34DA for ; Fri, 15 Jan 2016 17:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 guZU6qccvfH7 for ; Fri, 15 Jan 2016 17:23:47 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 6EB5D1B34D9 for ; Fri, 15 Jan 2016 17:23:47 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id v14so468820616ykd.3 for ; Fri, 15 Jan 2016 17:23:47 -0800 (PST) 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:content-type; bh=VzF2/yLQRUVvsocPxx8Fn4K29P/GaNHqBfOFXIW2WHc=; b=xPUe02/+QJns3pZVdtAdsICprsM4zELw0J7lBBN+N7NBJuLkSOflJVijMHWYyqceQ/ dLhVq/t87HlwDgHUb8zRhG8wsqRfpvb5XAC1ZXAguNi6ZOjaddguERQWPZh6Mqc/Q8em fswamwll/Sf8yWZyCHxdKjCj+gGpJ0iz5kSU08ivOTgqSAsGxM/nT3icFB6unisVMPfg 7/rKeMfwwdxQRonsgO6R77/HGCbe7WbHBjltY54W5A91IqGOnO5eoblxS0xOTgNqXFJ9 cH4sOc59RH4ol3O5sNmSw1q4FlcUrgxqOlLv/M214+oDHlVLa6gExAeNoXzf2n75hUBm nxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VzF2/yLQRUVvsocPxx8Fn4K29P/GaNHqBfOFXIW2WHc=; b=c/0OF+XSo7aIl3QVf6sxVniE/NeRFh1Q5fgeei+Tu9Q/3Rv9tO+P85BuAQxUMz+x5v CXjDoVN4xQttbENjSEZlF8zW1UZS1CO9WLxqnL4HiDTWex9FDPkvzAXlb8TPvgN8oN1A I6Q9Ssv0bUBRH8nl1HAGQdLP8HqxCs+HBskV5VAowjju45J0duMuarBoViacrnrUCt5D euf9GPM89HTJDWdjJZyz9pwBQZby7z0CoS5vKw2Ix7myJbVVejm9ByswXftmWYVKeFSd b2Wp6w2Lk2pSVbiJS4Ws364d8VKUG+D9P6qHRb+WXRGhqkHuLSXwz39ZYC0Z57vFsRms lo7A== X-Gm-Message-State: AG10YOSdwdgF8IEJ2a5Dd+6Gc0MeFGY4n6PDNIyKFSe5qEkVvZmYGDyw+5quNOatg7+cW48EDueVnGBv9Is/Bg== X-Received: by 10.37.24.195 with SMTP id 186mr847565yby.162.1452907426760; Fri, 15 Jan 2016 17:23:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 15 Jan 2016 17:23:07 -0800 (PST) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 15 Jan 2016 17:23:07 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114159b6107c0c0529695fda Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 01:23:49 -0000 --001a114159b6107c0c0529695fda Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin wrote: > On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett > wrote: > >> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS >> > 1.2, signature algorithms are spread across the handshake. >> [...] >> > I propose we fold the negotiable parameters under one name. >> [...] >> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm >> as >> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that >> > instead. >> >> I previously proposed this here: >> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >> >> ekr was against it, though it hasn't been discussed that throughly. >> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html > > > Ah, thanks! I must have missed this discussion. Or perhaps I saw it and > forgot. > > ekr, are you still against this sort of thing? I think the new CFRG > signature algorithms tying decisions together is a good argument for why > we'd want this. If we believe this trend is to continue (and I hope it > does. Ed25519 is a nice and simple interface), trying to decompose it all > seems poor. > I'm not sure. I agree that the CFRG thing seems to be a new development. I'll try to confirm my previous opinion or develop a new one over the weekend :) Ekr > David > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114159b6107c0c0529695fda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Fri, Jan= 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David Ben= jamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG thing seems to= be a new development. I'll
try to confirm my previous op= inion or develop a new one over the weekend :)

Ekr=


David
=C2=A0

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


--001a114159b6107c0c0529695fda-- From nobody Fri Jan 15 17:26:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02721B34DE for ; Fri, 15 Jan 2016 17:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 HPxIt4D6HJVF for ; Fri, 15 Jan 2016 17:26:15 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 E49DB1B34DC for ; Fri, 15 Jan 2016 17:26:14 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id t15so23537231igr.0 for ; Fri, 15 Jan 2016 17:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=BZSAzDYxr9sj9iifU3jC5Aj0V5dRiG4FTueh7N7GBAs=; b=XGy289SJX8kRqK6JLDHcrzSwSkdJlzpPJy5GWcafVIS7dyUG0lOROFuIpDpklb1gmn gU21CAuNHfacdK/Ioq3LbBCMGy4tbJmML9IWrdCl8lozvI8spurUMxKVtqiIpKE+HESk qJ6MFkZ5MzzHE3JQkdOp9XEZH3mF3eRhU7l3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=BZSAzDYxr9sj9iifU3jC5Aj0V5dRiG4FTueh7N7GBAs=; b=fo5+vUbyWD4GUAK7zjMO9DkfOH9qjgKmDFTmFLFAz4NPuSS9UmbGg58apBZDiS6anI xMg6cgsZb0zwPyqY4w2hj9yT/0J8yhe6avXxedfnGlhvCTAky98WdUkhnxcNjFsklKNn e+spk020Bme9lQHDrkptDOcs33Rk9753375j42nGPWm+y/w/HM4hkb7kkTFTHVY0LlNw 3eBBf28k4UmwSX5UP7ZsINMer7nN2oXt/aRYC/CdCL3lZEDcqBs7yQdkNYukZ/8XbJzT chVDV/sFv9U3iQtHgAs0hdT8aWUhBLPB2ZydCuO4bGg4Il45lq2pQUxKD/15O4HXA8AI fOpg== X-Gm-Message-State: AG10YOTqNwscb0baJwhPgh8tiOQASzZTnooHQ9yDI7XUN7v2zsbW5Oobywjq4EWMZ7bCg3O1snvOcv5cS4k6DDSH X-Received: by 10.50.8.106 with SMTP id q10mr996036iga.67.1452907574272; Fri, 15 Jan 2016 17:26:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Sat, 16 Jan 2016 01:26:04 +0000 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=089e013c65dcdb844305296967b3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 01:26:16 -0000 --089e013c65dcdb844305296967b3 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 8:10 PM David Benjamin wrote: > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset > is) for TLS 1.3 and later. > (Hrm. Nevermind, actually. If we go with only those three, I don't think this option does anything useful. If we go with a superset, we might want it separate? Would have to think about that to convince myself. Anyway, whether/how to subset is the more important question. Overlap's mostly an optimization.) David --089e013c65dcdb844305296967b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 15= , 2016 at 8:10 PM David Benjamin <davidben@chromium.org> wrote:
If changing the exis= ting meaning is a nuisance, another option is to continue to allocate new v= alues but only define ecdsa_p256_sha256, ecdsa_p384_sha384, and ecdsa_p521_= sha512 (or whatever your favorite subset is) for TLS 1.3 and later.

(Hrm. Nevermind, actually.= If we go with only those three, I don't think this option does anythin= g useful. If we go with a superset, we might want it separate? Would have t= o think about that to convince myself. Anyway, whether/how to subset is the= more important question. Overlap's mostly an optimization.)
=
David
--089e013c65dcdb844305296967b3-- From nobody Fri Jan 15 19:13:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A981B364E for ; Fri, 15 Jan 2016 19:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 TpTsUW5Q28Up for ; Fri, 15 Jan 2016 19:13:29 -0800 (PST) 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 B6F2D1B3651 for ; Fri, 15 Jan 2016 19:13:29 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id k206so148013605oia.1 for ; Fri, 15 Jan 2016 19:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GHi2gcZqfCeg2vkDmEkfjaVZ5R4WdKwYd2S1nnu0D8c=; b=k08+K9jzLUDHUNuFcF2ckP7BKTQb9C+gfuatPuvCGZOT215KfC38HQ8uXvms2B7eiI WG2wYYTiOGCLeW8f/3PpxAEyWDiTDqsfOzqcK8bp2KRoiI417tCCd2tUNJNopriKW5iT XpXLmPWJA0T5lwBgZ2LteldP1LzC511Jl76DzBhKoLmjNhvo11II5Om/FPEeFc79hwMa VS4AQqWeqBCh+gMyq5NNrO6sEYkeb8Jwvbj7AbeuiUhxGRvlH3O20ywgDx57tzcTkASt HHzUN/1cmA6KRPl2TbdhrSMd6Bo5KVc1A5pFxWtnhTK/2OnQLgGaFZ6vz1ETPc4JVpCp hHlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GHi2gcZqfCeg2vkDmEkfjaVZ5R4WdKwYd2S1nnu0D8c=; b=dixqnZRMmJQyX2tWFC3h/CCkFJnTb9MeI5FvCj+W4C7/OQ31JLEclq+NscxtLQ5/2w CRnvZ2smpi4rcvy3xW2fTn0cbD5j56T3RVxvpMBzI2cbZIP/MSarKVqN0nmtVTSQ1/p5 OnqbJldYWeyjcYUjkG6+P99ahBhQnzjTux8c5swbxLQ3ZKcDS4GqkHhcpV0yq1Ju8iwn gMXxsQW+c4R0mMFkeP+2PgNlX7skqVhGMmIOhq57mFDi83x5lq7+3oXcWk69KJu3HRZG yWoQckoZ5/XzLKHSvCH70m5lmyHkZ0Nou/ophMdep1weiFztjSvtZbzl9vTthCff785D wJzQ== X-Gm-Message-State: ALoCoQnjnTqhg8HzEsPouJBAeBpNVej4aTdW2rkBLYWkKZLLwo5hwrMZ5M6IrTAcXhEWpBNT4kJUYBnq9g/tTvGTjxe2nGKu6Q== MIME-Version: 1.0 X-Received: by 10.202.60.135 with SMTP id j129mr10533484oia.70.1452914009131; Fri, 15 Jan 2016 19:13:29 -0800 (PST) Received: by 10.76.170.225 with HTTP; Fri, 15 Jan 2016 19:13:29 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Jan 2016 17:13:29 -1000 Message-ID: From: Brian Smith To: David Benjamin Content-Type: multipart/alternative; boundary=001a113ccad067664005296ae7ab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 03:13:31 -0000 --001a113ccad067664005296ae7ab Content-Type: text/plain; charset=UTF-8 David Benjamin wrote: > (Whether such certificates exist on the web is probably answerable via CT > logs, but I haven't checked.) > Me neither, and I think that's the key thing that would need to be checked to see if my suggestion is viable. 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. >> (I don't have any particular affinity for that profile other than it seems >> to have made choices that have historically been shown to be above average, >> and it might be a good idea to avoid interop failure with other >> implementations that might have a special affinity for it.) >> > > What interop faliures are you worried about here? > The way I proposed things to work for TLS 1.3 is what the Suite B profile does for TLS 1.2. A Suite B client cannot describe the Suite B profile policy with the signature_algorithms extension as-is, so in theory if a Suite B profile client even exists, it would work better if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't know if any such "Suite B client" actually exists, though. > I don't think it makes sense to strategically assign the second byte for > new numbers. Either we believe TLS 1.2 implementations are unlikely to > react to 0x0703 and not worry about it, or we believe they will and we > reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to > u16 hack is too silly and don't do it at all.) > I would bet there will be some logic like "Is sha-256 mentioned at all in the signature_algorithms extension" and/or "is ecdsa mentioned at all in the signature_algorithms" extension that is used by some servers to decide whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think it would be worth the effort at least when the effort is minimal. Cheers, Brian -- https://briansmith.org/ --001a113ccad067664005296ae7ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Davi= d Benjamin <davidben@chromium.org> wrote:
(Whether such certificates exist on the web is proba= bly answerable via CT logs, but I haven't checked.)

Me neither, and I think that'= s the key thing that would need to be checked to see if my suggestion is vi= able.

<= div class=3D"gmail_quote">
<= div dir=3D"ltr">
=
3. You get better interoperability with TLS 1.2's NSA Suite B prof= ile [1]. (I don't have any particular affinity for that profile other t= han it seems to have made choices that have historically been shown to be a= bove average, and it might be a good idea to avoid interop failure with oth= er implementations that might have a special affinity for it.)=C2=A0
<= /div>

What interop= faliures are you worried about here?
The way I proposed things to work for TLS 1.3 is what the Suit= e B profile does for TLS 1.2. A Suite B client cannot describe the Suite B = profile policy with the signature_algorithms extension as-is, so in theory = if a Suite B profile client even exists, it would work better if servers as= sumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don= 't know if any such "Suite B client" actually exists, though.=
=C2=A0
=
I don't think it makes= sense to strategically assign the second byte for new numbers. Either we b= elieve TLS 1.2 implementations are unlikely to react to 0x0703 and not worr= y about it, or we believe=C2=A0they will and we reserve all numbers ending = in 00-03. (Or we decide that this (u8, u8) to u16 hack is too silly and don= 't do it at all.)

<= div>I would bet there will be some logic like "Is sha-256 mentioned at= all in the signature_algorithms extension" and/or "is ecdsa ment= ioned at all in the signature_algorithms" extension that is used by so= me servers to decide whether to use a SHA-1 cert and/or whether to use an E= CDSA cert, so I think it would be worth the effort at least when the effort= is minimal.

Cheers,
--001a113ccad067664005296ae7ab-- From nobody Fri Jan 15 23:48:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BFA1A1A27 for ; Fri, 15 Jan 2016 23:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaUpzCMoGA2w for ; Fri, 15 Jan 2016 23:47:56 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id E512C1A1A25 for ; Fri, 15 Jan 2016 23:47:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 57CE1501; Sat, 16 Jan 2016 09:47:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 44pCxDbnPqJ0; Sat, 16 Jan 2016 09:47:53 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 703E8230D; Sat, 16 Jan 2016 09:47:53 +0200 (EET) Date: Sat, 16 Jan 2016 09:47:49 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160116074749.GA10333@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 07:47:59 -0000 On Sat, Jan 16, 2016 at 01:10:06AM +0000, David Benjamin wrote: > On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote: > > Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can > lose them. I just wrote out all 9 without thinking about it much. Apart > from "please don't cause me interop pain", I don't have strong opinions > about how aggressively we prune the list. Also, only the matching-size 3 of those 9 combinations tend to be properly (as in, computing correct results most of the time) implemented. Other 6 can easily be busted, especially the 3 where hash is larger than curve, as that hits the hash truncation special case. > My main worry is, for better or worse (I realize this is a point of > contention), some servers apply sigalgs to both CertificateVerify and > certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the > definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a > nuisance. I would think that any case where meanings are different (except for case where use in TLS 1.3 is restricted) is a nuisance. Avoiding these differences with restriction of server signatures to RSA-PSS would imply that if client signals TLS 1.3 with only the only RSA algorithms being the v1.5 ones, then server can't sign using RSA if selecting TLS 1.3. And it would also imply that if TLS 1.2 server gets TLS 1.3 client hello with the new RSA-PSS algorithms, it can sign using RSA-PSS, even after having downnegotiated TLS 1.2. > Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though > it would prevent them from adopting TLS 1.3 without switching certificates. > Alternatively, if people decide that sigalgs and certificates officially > have nothing to do with each other in TLS 1.3, then things are fine but we > wouldn't have a way to negotiate such algorithms. I was hoping to avoid > that issue for this proposal, but there is some interaction. The ECDSA nasty case can only occur for certificate-to-certificate linkages, since EE SPKI does not contain hash algorithm, and server is always able to choose matching one. Then TLS 1.3 AFAIK does not deprecate Brainpool, so Brainpool ECDSA can also be seen... Then RSA might be nastier: do normal RSA certificates work with RSA- PSS? If not, then the TLS 1.3 servers can't use them. > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset > is) for TLS 1.3 and later. If one does not want to change too much, then one would have to sup- port those for TLS 1.2 as well (not breaking signature verification if such algorithm is first advertised and then selected with connection downnegotiated to TLS 1.2). > > 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. > > (I don't have any particular affinity for that profile other than it seems > > to have made choices that have historically been shown to be above average, > > and it might be a good idea to avoid interop failure with other > > implementations that might have a special affinity for it.) > > > > What interop faliures are you worried about here? Things like: Trying to use ECDSA-P256-SHA384 and then one end not imp- lementing it correctly (e.g. missing truncation). Apparently ECDSA-P256-SHA384 failure rate is much higher than ECDSA-P256-SHA256 and ECDSA-P384-SHA384. > I don't think it makes sense to strategically assign the second byte for > new numbers. Either we believe TLS 1.2 implementations are unlikely to > react to 0x0703 and not worry about it, or we believe they will and we > reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to > u16 hack is too silly and don't do it at all.) I think it is fairly unlikely that TLS 1.2 endpoints react to things like 0x0703 or 0x0404. Since even known signature algorithms are un- usable with unknown hashes, ServerKeyExchange is temporally localized and CertificateRequest comes too late to be useful for filtering. -Ilari From nobody Sat Jan 16 02:00:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1B1A6EE9 for ; Sat, 16 Jan 2016 02:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 AAUrZlgQ2rAN for ; Sat, 16 Jan 2016 02:00:40 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A08C1A0019 for ; Sat, 16 Jan 2016 02:00:39 -0800 (PST) Received: from pc1 ([::ffff:194.19.189.228]) (AUTH: LOGIN hanno-default@schokokeks.org, SSL: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sat, 16 Jan 2016 11:00:35 +0100 id 0000000000000099.00000000569A14C3.000017DB Date: Sat, 16 Jan 2016 11:01:12 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160116110112.4af15baf@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-6107-1452938436-0001-2" Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 10:00:42 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-6107-1452938436-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I generally like the idea of simplifying the different algorithm negotiation things, but: On Fri, 15 Jan 2016 20:45:34 +0000 David Benjamin wrote: > [2] > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note > this is wire-compatible with TLS 1.2. > - 0x0101 - rsa_pkcs1_md5 > - 0x0201 - rsa_pkcs1_sha1 > - 0x0301 - rsa_pkcs1_sha224 > - 0x0401 - rsa_pkcs1_sha256 > - 0x0501 - rsa_pkcs1_sha334 > - 0x0601 - rsa_pkcs1_sha512 > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility > but ignored in TLS 1.3. I think a couple of them (esp. everything with dsa and _md5) should get a diediedie rfc and never be seen again. > - rsapss_sha256 > - rsapss_sha384 > - rsapss_sha512 > - ecdsa_p256_sha256 > - ecdsa_p256_sha384 > - ecdsa_p256_sha512 > - ecdsa_p384_sha256 > - ecdsa_p384_sha384 > - ecdsa_p384_sha512 > - ecdsa_p521_sha256 > - ecdsa_p521_sha384 > - ecdsa_p521_sha512 > - eddsa_ed25519 > - eddsa_ed448 Do we really need that many? I think the "complexity zoo" of TLS is one of its current downsides and I really think we should go with fewer options in the future. Can we strip that down to - below 5 or something? (personal opinion: Strip down to 2, but this may be too radical for now.) --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-6107-1452938436-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWmhToAAoJEKWIAHK7tR5CZksQAKa7Gjf3s/tJ7oruk0XToq4U z80diL9tlCPXwWMJSOnU1nNQB7CnUU/qzWBzPiK5ETKPWzXSrX99EI3xgnArIAtw QFnWWRF+TUrVZQXoN7xg+sbrCv+nczEiZAfxMXRHeBL18lAPzSuY8g5l/YnB3vsh GS3UCjhiRB12mF5P2GUxZ/X8MSOdho8ti+FXF3PNS1l8f6Y55ntIRweW5TxTuuVk lrFutx4RuvHcjllh5A0knWkVLqYQDrEHbbaptzTeGMvvTJEOAwOwhj8j/2Y+dJLl IUGbs31orMkKN/nUQJmwXTYT7a6T8iWtuwtGyRGuAOoKJjLwas0yFVeT6nwRebfe PequYlStuDa6NA0DjFxQbM6LHDbKK6J8svT5x4DM383+TMlScLQpiDcwcl9252M/ iNN35W1nmdvCn8fTHO5Cs023dyuPqGRsYq0340PRr1vbRZFeOx+GjgLpa7LZufFi FkN4xCqFm6r71s0dGhfy0bMQvJZiJx9SGhiUctgb2S9U7Klf99Idsx28rrhXHtac Ja820nZ+PhN4+u7j4n1nE35aY/mmdcEm5WwUdy1VAEHrZ3hIrC/1f33bGTx9kYcr hL/r7+oFCgcmmookQfn0Es3DolyBgdWutqjT2gWboSk8H23ZA+0b2zlzEBI4P/GQ x+PGdnajCg661/wt/B63 =FJDa -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-6107-1452938436-0001-2-- From nobody Sat Jan 16 13:02:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D96A1AC3C6 for ; Sat, 16 Jan 2016 13:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 avyJhv4fAETd for ; Sat, 16 Jan 2016 13:02:22 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C31AC3C1 for ; Sat, 16 Jan 2016 13:02:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 86EA955A; Sat, 16 Jan 2016 23:02:20 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fm5IbW9qKARQ; Sat, 16 Jan 2016 23:02:20 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3ADB7287; Sat, 16 Jan 2016 23:02:20 +0200 (EET) Date: Sat, 16 Jan 2016 23:02:16 +0200 From: Ilari Liusvaara To: Hanno =?utf-8?B?QsO2Y2s=?= Message-ID: <20160116210216.GA10852@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160116110112.4af15baf@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160116110112.4af15baf@pc1> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 21:02:24 -0000 On Sat, Jan 16, 2016 at 11:01:12AM +0100, Hanno Böck wrote: > > > - rsapss_sha256 > > - rsapss_sha384 > > - rsapss_sha512 > > - ecdsa_p256_sha256 > > - ecdsa_p256_sha384 > > - ecdsa_p256_sha512 > > - ecdsa_p384_sha256 > > - ecdsa_p384_sha384 > > - ecdsa_p384_sha512 > > - ecdsa_p521_sha256 > > - ecdsa_p521_sha384 > > - ecdsa_p521_sha512 > > - eddsa_ed25519 > > - eddsa_ed448 > > Do we really need that many? > I think the "complexity zoo" of TLS is one of its current downsides and > I really think we should go with fewer options in the future. Can we > strip that down to - below 5 or something? (personal opinion: Strip > down to 2, but this may be too radical for now.) Well, there already are 3 main signature schemes... Six of those on the list could be cut down (cutting the list to 8) for purposes of server signature. Unfortunately there might be more in certificate-to-certificate signatures. Also, I don't think having N signature algorithms is that bad (unless your TLS stack architecture is garbage, but then you have other problems anyway). But if that gets coupled to other things, you are in world of hurt. Such annoyances include the TLS_ECDHE_RSA_*/TLS_ECDHE_ECDSA_* cipher- suites, since RSA_PSS presumably uses _RSA_ and others use _ECDSA_. -Ilari From nobody Sat Jan 16 14:39:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA3F1ACD30 for ; Sat, 16 Jan 2016 14:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Jdx3iOQrU3 for ; Sat, 16 Jan 2016 14:39:19 -0800 (PST) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 AA9AD1ACD2F for ; Sat, 16 Jan 2016 14:39:19 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0GMdF7K026243; Sat, 16 Jan 2016 17:39:15 -0500 Date: Sat, 16 Jan 2016 17:39:14 -0500 (EST) From: Nikos Mavrogiannopoulos To: Hanno =?utf-8?B?QsO2Y2s=?= Message-ID: <1784001619.6652310.1452983954794.JavaMail.zimbra@redhat.com> In-Reply-To: <20160116110112.4af15baf@pc1> References: <20160116110112.4af15baf@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.63.68] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922) Thread-Topic: Simplifying signature algorithm negotiation Thread-Index: kHxlw2gl1QvrZucIWQp9wDXKdbIjgQ== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jan 2016 22:39:21 -0000 ----- Original Message ----- > Hi, > > - rsapss_sha256 > > - rsapss_sha384 > > - rsapss_sha512 > > - ecdsa_p256_sha256 > > - ecdsa_p256_sha384 > > - ecdsa_p256_sha512 > > - ecdsa_p384_sha256 > > - ecdsa_p384_sha384 > > - ecdsa_p384_sha512 > > - ecdsa_p521_sha256 > > - ecdsa_p521_sha384 > > - ecdsa_p521_sha512 > > - eddsa_ed25519 > > - eddsa_ed448 > Do we really need that many? > I think the "complexity zoo" of TLS is one of its current downsides and > I really think we should go with fewer options in the future. Can we > strip that down to - below 5 or something? (personal opinion: Strip > down to 2, but this may be too radical for now.) In addition options like ecdsa_p384_sha256 ignore the NIST DSS recommendations of using equivalent security strength for hash and signature (SP-800-57). Having fewer options is indeed better. regards, Nikos From nobody Sun Jan 17 23:04:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81FF1B3161 for ; Sun, 17 Jan 2016 23:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.697 X-Spam-Level: * X-Spam-Status: No, score=1.697 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=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 EjhWSxSlmapx for ; Sun, 17 Jan 2016 23:04:38 -0800 (PST) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id E01EB1B315D for ; Sun, 17 Jan 2016 23:04:37 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-49-237-216-46.revip6.asianet.co.th; To: tls@ietf.org References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> From: Peter Dettman X-Enigmail-Draft-Status: N1110 Message-ID: <569C8E71.3090504@bouncycastle.org> Date: Mon, 18 Jan 2016 14:04:17 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 07:04:40 -0000 We (BouncyCastle) have just updated our TLS implementations to draft-ietf-tls-chacha20-poly1305-04 and have confirmed interop with OpenSSL. Regards, Pete Dettman On 14/01/2016 12:48 AM, Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other > browsers and TLS stacks, and now it all works. (The official IETF > version, not the QUIC version). From nobody Mon Jan 18 03:08:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBE1B34C5 for ; Mon, 18 Jan 2016 03:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecchFKG3iyrw for ; Mon, 18 Jan 2016 03:08:25 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 A4D461B34BF for ; Mon, 18 Jan 2016 03:08:25 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id B6B73A8A0553; Mon, 18 Jan 2016 11:08:22 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 972C51FE0575; Mon, 18 Jan 2016 12:08:22 +0100 (CET) Date: Mon, 18 Jan 2016 12:08:22 +0100 From: Kurt Roeckx To: Peter Dettman Message-ID: <20160118110822.GA23779@roeckx.be> References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> <569C8E71.3090504@bouncycastle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569C8E71.3090504@bouncycastle.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 11:08:27 -0000 On Mon, Jan 18, 2016 at 02:04:17PM +0700, Peter Dettman wrote: > We (BouncyCastle) have just updated our TLS implementations to > draft-ietf-tls-chacha20-poly1305-04 and have confirmed interop with OpenSSL. As far as I know, OpenSSL has an outstanding interop issue with BoringSSL where OpenSSL would not follow the draft. Kurt From nobody Mon Jan 18 03:10:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BA1B34C7 for ; Mon, 18 Jan 2016 03:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzGbfvjr7qt9 for ; Mon, 18 Jan 2016 03:10:43 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 937BE1B34C5 for ; Mon, 18 Jan 2016 03:10:43 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 34E49A8A1A9D; Mon, 18 Jan 2016 11:10:42 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 105941FE0575; Mon, 18 Jan 2016 12:10:41 +0100 (CET) Date: Mon, 18 Jan 2016 12:10:41 +0100 From: Kurt Roeckx To: Peter Dettman Message-ID: <20160118111041.GB23779@roeckx.be> References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> <569C8E71.3090504@bouncycastle.org> <20160118110822.GA23779@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160118110822.GA23779@roeckx.be> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 11:10:44 -0000 On Mon, Jan 18, 2016 at 12:08:22PM +0100, Kurt Roeckx wrote: > On Mon, Jan 18, 2016 at 02:04:17PM +0700, Peter Dettman wrote: > > We (BouncyCastle) have just updated our TLS implementations to > > draft-ietf-tls-chacha20-poly1305-04 and have confirmed interop with OpenSSL. > > As far as I know, OpenSSL has an outstanding interop issue with > BoringSSL where OpenSSL would not follow the draft. Oh, it has been commited after all. Kurt From nobody Mon Jan 18 03:42:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD831B3556 for ; Mon, 18 Jan 2016 03:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.003 X-Spam-Level: X-Spam-Status: No, score=-5.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoXcijNvLo9N for ; Mon, 18 Jan 2016 03:42:15 -0800 (PST) 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 ACBCB1B3555 for ; Mon, 18 Jan 2016 03:42:15 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 1838C219D; Mon, 18 Jan 2016 11:42:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0IBgDqC005187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2016 06:42:14 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 18 Jan 2016 12:42:12 +0100 Message-ID: <2092123.sVeecb0TOa@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3539876.In70kUN9XR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 11:42:17 -0000 --nextPart3539876.In70kUN9XR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 15 January 2016 17:13:29 Brian Smith wrote: > David Benjamin wrote: > > (Whether such certificates exist on the web is probably answerable > > via CT logs, but I haven't checked.) >=20 > Me neither, and I think that's the key thing that would need to be > checked to see if my suggestion is viable. >=20 > 3. You get better interoperability with TLS 1.2's NSA Suite B profile= > [1]. > >> (I don't have any particular affinity for that profile other than > >> it seems to have made choices that have historically been shown to= > >> be above average, and it might be a good idea to avoid interop > >> failure with other implementations that might have a special > >> affinity for it.) > >=20 > > What interop faliures are you worried about here? >=20 > The way I proposed things to work for TLS 1.3 is what the Suite B > profile does for TLS 1.2. A Suite B client cannot describe the Suite > B profile policy with the signature_algorithms extension as-is, so in= > theory if a Suite B profile client even exists, it would work better > if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 > implies P-384. I don't know if any such "Suite B client" actually > exists, though. OpenSSL since version 1.0.2 has a setting to enforce strict Suite B=20 compliance =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 99/71, 612 45, Brno, Czech Republi= c --nextPart3539876.In70kUN9XR 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 iQIcBAABCgAGBQJWnM+UAAoJEJKo0bgB0vX1en8P/R+8d6Mydts1hOEAaq/n0HbX SoevmL0sr22Wd407SpUxrWuLS7XOzML0RVCO7xFpanJ20Y5DJLWHluCDDVFewr/V mKlSxlCJWWnitjFjanq90hqE1g4qKKcsk1hnS4JzI0HOsLRIYeP72WX8XznMfQni TyP3o+CMveHzjQzOJzhYbWHTYpLNQJUZXl8+WQwS+wRs8Eb1niW7e3l31ll1hi73 nXnxhiObgmYMwOcsdSGcPARP6vlebpobUNpDIdqV0FFA91oOrMgqa83boveTccCk gXgtKrIRyWbLjk0IW+cYj7+mxu8BtVNLeKhboCckOFBQVr/aatqoNO5ibtspg78R jhn71DmWYNDlJ0lR1RF7kZEjAr/MVbxNagSgb2lm4GuX2wiJ4nCJliNOKTBZ4+sD MFXiQJ+ImMyozHnMUK0G+wEH97FT5l+shgpRSFz9T8v9TiBuE0vOAFjGc4Cl50k5 lQ00RZu8xcxSCsPW0zoQBUkrXZ49LvUoaY6ANISFMwvMt8KgCKSUBSjmOOQMUTSE mQhln/O7uwPSKQvTAt/vzu9BBfI/fh3HBqmVvwkVFdf56HkiMJ5qegW6bVrnChO/ i6/2muRIKtybB1Qoo+Acurc/STwvNmB/V6XOtb3Z+nUeO9zX7FQ7WbMt3HFWQ49W isNnsWvp3+3/hlwxrYYC =0U/r -----END PGP SIGNATURE----- --nextPart3539876.In70kUN9XR-- From nobody Mon Jan 18 03:54:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED51B3530 for ; Mon, 18 Jan 2016 03:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDAMUIJQ2wJT for ; Mon, 18 Jan 2016 03:54:36 -0800 (PST) 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 B2DC61B3570 for ; Mon, 18 Jan 2016 03:54:36 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 4DEB4C0A5242; Mon, 18 Jan 2016 11:48:25 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0IBmNkn016765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2016 06:48:24 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 18 Jan 2016 12:48:23 +0100 Message-ID: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2893212.be2fzV1mJ1"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 11:54:38 -0000 --nextPart2893212.be2fzV1mJ1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 15 January 2016 20:45:34 David Benjamin wrote: > Hi folks, >=20 > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > TLS 1.2, signature algorithms are spread across the handshake. We > have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and > HashAlgorithm, all in independent registries. NamedGroup is sent in > one list, also used for (EC)DH, while the other two are sent as a > pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in > separate registries. >=20 > This is a lot of moving parts. Signature negotiation in TLS 1.2 tends= > to be messy to implement. Client certificate keys may be in > smartcards via OS-specific APIs, so a lot of time is spent transiting= > new preference shapes across API boundaries in order to discover > smartcard bugs. Sometimes I think people deploy client certs because > they hate me and want to cause me pain=E2=80=A6 :-) >=20 > Anyway, the new CFRG curves also bind signature curve and hash > together. The current draft represents this as eddsa_ed25519 and > eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this > doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is illegal. (O= r ECDSA > + FF3072.) >=20 > I propose we fold the negotiable parameters under one name. Think of > how we=E2=80=99ve all settled on AEADs being a good named primitive w= ith a > common type signature[1]. Specifically: >=20 > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From > now on, NamedGroup is only used for (EC)DH. >=20 > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorith= m > as they are. Introduce a new SignatureAlgorithm u16 type and > negotiate that instead. (Or maybe a different name to not collide.) > u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448 > separately, but u16 is plenty. >=20 > 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.= 2 > by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. > 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently > with HashAlgorithm from TLS 1.2. Note this does not introduce new > premultiplications on the wire. Just in the spec and registry. >=20 > 4. Deprecate ecdsa_sha256, etc., in favor of new > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old > ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3. > Although this introduces new premultiplications, it=E2=80=99s only 9 = values > with the pruned TLS 1.3 lists. I think this is worth 9 values to keep= > NamedGroups separate. >=20 > 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and > rsapss_{sha256,sha384,sha512}. These come with the signature algorith= m > and curve pre-specified. (See [2] at the bottom for full list of > allocations.) >=20 > Thoughts? >=20 > David >=20 > [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need so= me > mapping to a subset of X.509's RSA-PSS. We'll just not bother with > RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerFiel= d > 14. And RSA key generation still has size parameter. Hopefully future= > things can look more like Ed25519. >=20 > [2] > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note= > this is wire-compatible with TLS 1.2. > - 0x0101 - rsa_pkcs1_md5 > - 0x0201 - rsa_pkcs1_sha1 > - 0x0301 - rsa_pkcs1_sha224 > - 0x0401 - rsa_pkcs1_sha256 > - 0x0501 - rsa_pkcs1_sha334 > - 0x0601 - rsa_pkcs1_sha512 > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility > but ignored in TLS 1.3. >=20 > 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3]= > to avoid colliding with existing signature algorithms, but I don=E2=80= =99t > think that=E2=80=99s necessary[3]. > - rsapss_sha256 > - rsapss_sha384 > - rsapss_sha512 > - ecdsa_p256_sha256 > - ecdsa_p256_sha384 > - ecdsa_p256_sha512 > - ecdsa_p384_sha256 > - ecdsa_p384_sha384 > - ecdsa_p384_sha512 > - ecdsa_p521_sha256 > - ecdsa_p521_sha384 > - ecdsa_p521_sha512 > - eddsa_ed25519 > - eddsa_ed448 Then what ECDHE share gets signed? if the same as the curve, what about FFDHE, what about ECDHE-RSA? why n= o - rsapss_dh2048_sha256 - rsapss_dh3072_sha256 - rsapss_dh4096_sha384 - (etc.) - rsapss_p256_sha256 - rsapss_p384_sha384 - (etc.) If it does not specify the DH share signed, it doesn't really change=20= anything... =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2893212.be2fzV1mJ1 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 iQIcBAABCgAGBQJWnNEHAAoJEJKo0bgB0vX1jv4P/RWZJgm/Lwdga/t/FBRgckko kl14AEMKqpS4HvB2p1GJBFtEYVuEM29siM7lbh+v9taqOqXP/FMKiSFnJio9VYx7 u5cnWK3LvUf9q4nVx0QqhgS+NPGgXqRQtM4klsOd4Ru0zgPYMVTYWA4uk3PcPCo7 JlqttfDnfE7BRtzIiWdU8JaocjucHcMLidCgrtWTY8esJ+f5XISxdEjFJeF5asWH 1jizxNaDiSd5IDHMdnICi/Vg9ZMV5+TeQD/CzbfUQ5vB2QZJr8tMfFL5imXAL+S1 tEzbn6xG07P3MFLtdfIadAQS2DDXLhLsXSbPH7agFVqcWyyFA6a43dN1GwDlf8U2 hnA9QdLJ/OhkupryFeXWD8zRbWU1qCLz0Z3JF3amBXrArXw9bAf96IWCRk689BRt ObM4yfeCPSkW/XEruZhK7cskC4kko70jl00hvrZEhGReEjCD9OWZXSZgmfeiNwHq euT1tBYRhtI5PwtX2kbKsXulmu5TkzhYqHNR/szTAQeE25tgNuebGlzwKhDiZEok +uwndcGHEuA93ElsEno/b6sc1xeKzYREV2e9WU7U/C5qL5urCsaSrOOjBScODO6x vtJrC9ijtwhjfVftCN1K4XSfkUCYEIuK1Nsi1S3DYs2pm0yRESxUFezrmwuysarj 4kA81JHduzko6/jpIPKs =3ovT -----END PGP SIGNATURE----- --nextPart2893212.be2fzV1mJ1-- From nobody Tue Jan 19 07:02:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618BA1B2FFD for ; Tue, 19 Jan 2016 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZbLNEW0vlzX for ; Tue, 19 Jan 2016 07:02:40 -0800 (PST) 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 147761B2FFA for ; Tue, 19 Jan 2016 07:02:39 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6FBD419F22E for ; Tue, 19 Jan 2016 15:02:39 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0JF2c6Z010318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jan 2016 10:02:39 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 19 Jan 2016 16:02:26 +0100 Message-ID: <9890018.hCD1Bb9HJi@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <326d1a7af9ae441081f5c272e5758d9f@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6957382.jaiZUQRqRk"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] chacha/poly for http/2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 15:02:44 -0000 --nextPart6957382.jaiZUQRqRk Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 January 2016 17:48:37 Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other > browsers and TLS stacks, and now it all works. (The official IETF > version, not the QUIC version). I was able to confirm interoperability between tlslite-ng[1] and curren= t=20 OpenSSL master (0e76014e584ba7), using draft-ietf-tls-chacha20- poly1305-04 implementation. 1 - https://github.com/tomato42/tlslite-ng/tree/chacha-ecdhe =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 99/71, 612 45, Brno, Czech Republi= c --nextPart6957382.jaiZUQRqRk 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 iQIcBAABCgAGBQJWnlACAAoJEJKo0bgB0vX1T2YP/0FRNJu+2acw76IhI+QqQwqg CwmqylHpnVtRtptde3mCTIZUXOKS+vLFCxzMt3VYznSC4RFySZzcU7P7m629jsL7 hmHEN90nRJ7gpZlHwidFilxEzGaLtabzp+HvJn0Bq/citRx7lwx0ba88Gk6jHFtf 6EHnJQr90URFs/2QyXYHfMv+fr7pfn19b/+VKT6S4Wchimh2vx3l/x5quEfwblY4 ZM6EUrJ9WWCp19g5np+FucKWhCA4W/CHVb8BwLiDQmI0Ka+shOfGsfxQ8OjQT1+8 3esgX6TMQ4RYzJ/XVhFYR4olXymByjAAJFQd8IDvwOz/Dk+RqcsmA3E8BUWVdT/r sP5xVuvfVlKSllQMFWlDXNaqMl7dQ/Nz50trvwA2a+MEXZ9icyYtWTFFS5yI3zuL Nywelcm4jJ3E92Bu4ftE+s7BqekE5kiXPXQx5EZCgp2iLVEJ4q3guJVt+3LfsJ4Z Z/CzWHCpl+/45ts+lAs7doqF7Zl2RreCNig/+oqZnS5fVDlSRSbWFzlOUQ2eZAY2 oyNgC8mCGKdYNGAd2TLOEJsuFGGeSl3/kO7YbKvq5u4V7aIlewGzyhpWEqK1vCjp Z4qrE+CljnTneHgFYcLmXr6VcpTJE1NgyQxHLZReWg6a/cTU4lXiYcXF9OsO7xq2 lm/UdH65sGfERSpJYvXi =FC9T -----END PGP SIGNATURE----- --nextPart6957382.jaiZUQRqRk-- From nobody Tue Jan 19 08:50:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE61B3246 for ; Tue, 19 Jan 2016 08:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ebSNNCGyAaOo for ; Tue, 19 Jan 2016 08:50:28 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED4A1B3242 for ; Tue, 19 Jan 2016 08:50:28 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id z14so81233260igp.0 for ; Tue, 19 Jan 2016 08:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=Kbn7M4qMnJqGRBaCvTwdAcViGf4UJ65ALRZK5iVu92M=; b=UoOoq8ODX28e8qibZKJ6Z13Xgmqh0MbDgkfyQi/6aKrCkeU+hN5aZ39T1P7GucK0dp YzQR/IwpWiDQjeqIewGKuNbEQIO8q8A6PT4eFLz4AmJok7FIm9xOnkaw4KSOVnRv0ckJ soosNyegC2aBxV+IlJ2fhMU6HjKl8AaHFIsnU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Kbn7M4qMnJqGRBaCvTwdAcViGf4UJ65ALRZK5iVu92M=; b=SX5rPvZutvosARidJQsaeyOuG/t2tt39p6PQYTK3fcdAV4SnA1tPgB6dGUF8d/wYyk EwN1Ce+x1+pUewA0IEO1ReKiGIJGTDfF3H6kQmxtxaroA1xb+/X0jZKoOxsnQ90mAGD2 AoMGcIAmL9u2fkwwcL2QV0DSk3e06VeMzSv4K4+mrJCLzVJUKE2Oal07DgLZBydIozKz sagSPIlsGwZyPi8XqPheYFTyleMA/pcYbQH6ivkfGY/soVGQj7yMdw1SDiLmBGXEo+0E lMvpbSCSTV5eTkepRyFBFruXVbPNOzzWAev13S3CuDq8u2/gcI8EM2/LtfLeWneUygv3 es2g== X-Gm-Message-State: AG10YOQvxtvnGg+4k/qNh30SC4jFKNd3HdZJeAMmxM/dSsVx8BFWfuuEgaH58wz3xXPqWP1BmRNBRGi7E6dJFkaK X-Received: by 10.50.134.129 with SMTP id pk1mr17056250igb.11.1453222227972; Tue, 19 Jan 2016 08:50:27 -0800 (PST) MIME-Version: 1.0 References: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> In-Reply-To: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> From: David Benjamin Date: Tue, 19 Jan 2016 16:50:18 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=047d7b2e3fe6adf0a30529b2aaba Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 16:50:31 -0000 --047d7b2e3fe6adf0a30529b2aaba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote: > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > Hi folks, > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > > TLS 1.2, signature algorithms are spread across the handshake. We > > have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and > > HashAlgorithm, all in independent registries. NamedGroup is sent in > > one list, also used for (EC)DH, while the other two are sent as a > > pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in > > separate registries. > > > > This is a lot of moving parts. Signature negotiation in TLS 1.2 tends > > to be messy to implement. Client certificate keys may be in > > smartcards via OS-specific APIs, so a lot of time is spent transiting > > new preference shapes across API boundaries in order to discover > > smartcard bugs. Sometimes I think people deploy client certs because > > they hate me and want to cause me pain=E2=80=A6 :-) > > > > Anyway, the new CFRG curves also bind signature curve and hash > > together. The current draft represents this as eddsa_ed25519 and > > eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this > > doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is illegal. (Or = ECDSA > > + FF3072.) > > > > I propose we fold the negotiable parameters under one name. Think of > > how we=E2=80=99ve all settled on AEADs being a good named primitive wit= h a > > common type signature[1]. Specifically: > > > > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From > > now on, NamedGroup is only used for (EC)DH. > > > > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm > > as they are. Introduce a new SignatureAlgorithm u16 type and > > negotiate that instead. (Or maybe a different name to not collide.) > > u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448 > > separately, but u16 is plenty. > > > > 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 > > by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. > > 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently > > with HashAlgorithm from TLS 1.2. Note this does not introduce new > > premultiplications on the wire. Just in the spec and registry. > > > > 4. Deprecate ecdsa_sha256, etc., in favor of new > > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old > > ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3. > > Although this introduces new premultiplications, it=E2=80=99s only 9 va= lues > > with the pruned TLS 1.3 lists. I think this is worth 9 values to keep > > NamedGroups separate. > > > > 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and > > rsapss_{sha256,sha384,sha512}. These come with the signature algorithm > > and curve pre-specified. (See [2] at the bottom for full list of > > allocations.) > > > > Thoughts? > > > > David > > > > [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need some > > mapping to a subset of X.509's RSA-PSS. We'll just not bother with > > RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm > > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField > > 14. And RSA key generation still has size parameter. Hopefully future > > things can look more like Ed25519. > > > > [2] > > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note > > this is wire-compatible with TLS 1.2. > > - 0x0101 - rsa_pkcs1_md5 > > - 0x0201 - rsa_pkcs1_sha1 > > - 0x0301 - rsa_pkcs1_sha224 > > - 0x0401 - rsa_pkcs1_sha256 > > - 0x0501 - rsa_pkcs1_sha334 > > - 0x0601 - rsa_pkcs1_sha512 > > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. > > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility > > but ignored in TLS 1.3. > > > > 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] > > to avoid colliding with existing signature algorithms, but I don=E2=80= =99t > > think that=E2=80=99s necessary[3]. > > - rsapss_sha256 > > - rsapss_sha384 > > - rsapss_sha512 > > - ecdsa_p256_sha256 > > - ecdsa_p256_sha384 > > - ecdsa_p256_sha512 > > - ecdsa_p384_sha256 > > - ecdsa_p384_sha384 > > - ecdsa_p384_sha512 > > - ecdsa_p521_sha256 > > - ecdsa_p521_sha384 > > - ecdsa_p521_sha512 > > - eddsa_ed25519 > > - eddsa_ed448 > > Then what ECDHE share gets signed? > if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no > - rsapss_dh2048_sha256 > - rsapss_dh3072_sha256 > - rsapss_dh4096_sha384 > - (etc.) > - rsapss_p256_sha256 > - rsapss_p384_sha384 > - (etc.) > > If it does not specify the DH share signed, it doesn't really change > anything... > Why would it need to specify what [DH group's] DH share gets signed? NamedGroup still exists for the key exchange (see step 1). I'm only proposing pulling signature curves out of NamedGroup. (Is the DH share even signed directly? It looks like TLS 1.3 signs via CertificateVerify's handshake context in both directions. Either way, it's just a byte-string message. We could also backport this sort of thing to TLS 1.2 and the signature algorithm still doesn't care about the DH share. That gets encoded into a byte string somehow.) I'm trying to make the decompositions and premultiplications align with how the protocol is structured. TLS 1.2 decomposed algorithm, signing curve, and hash which isn't universal (Ed25519, Ed448, even RSA-PSS's params in full generality aren't the same shape, the definition of "digitally-signed" takes only a byte-string message as input), so they should be premultiplied. Whereas signature algorithm and DH group are cleanly separated in the protocol and needn't be premultiplied. David --047d7b2e3fe6adf0a30529b2aaba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 18= , 2016 at 6:48 AM Hubert Kario <hka= rio@redhat.com> wrote:
On Fr= iday 15 January 2016 20:45:34 David Benjamin wrote:
> Hi folks,
>
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > TLS 1.2, signature algorithms are spread across the handshake. We
> have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and
> HashAlgorithm, all in independent registries. NamedGroup is sent in > one list, also used for (EC)DH, while the other two are sent as a
> pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in
> separate registries.
>
> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends<= br> > to be messy to implement. Client certificate keys may be in
> smartcards via OS-specific APIs, so a lot of time is spent transiting<= br> > new preference shapes across API boundaries in order to discover
> smartcard bugs. Sometimes I think people deploy client certs because > they hate me and want to cause me pain=E2=80=A6 :-)
>
> Anyway, the new CFRG curves also bind signature curve and hash
> together. The current draft represents this as eddsa_ed25519 and
> eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this
> doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is illegal. (Or= ECDSA
> + FF3072.)
>
> I propose we fold the negotiable parameters under one name. Think of > how we=E2=80=99ve all settled on AEADs being a good named primitive wi= th a
> common type signature[1]. Specifically:
>
> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From > now on, NamedGroup is only used for (EC)DH.
>
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm=
> as they are. Introduce a new SignatureAlgorithm u16 type and
> negotiate that instead. (Or maybe a different name to not collide.) > u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448
> separately, but u16 is plenty.
>
> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2=
> by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples.
> 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently
> with HashAlgorithm from TLS 1.2. Note this does not introduce new
> premultiplications on the wire. Just in the spec and registry.
>
> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old
> ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3. > Although this introduces new premultiplications, it=E2=80=99s only 9 v= alues
> with the pruned TLS 1.3 lists. I think this is worth 9 values to keep<= br> > NamedGroups separate.
>
> 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm=
> and curve pre-specified. (See [2] at the bottom for full list of
> allocations.)
>
> Thoughts?
>
> David
>
> [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll = need some
> mapping to a subset of X.509's RSA-PSS. We'll just not bother = with
> RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm
> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField=
> 14. And RSA key generation still has size parameter. Hopefully future<= br> > things can look more like Ed25519.
>
> [2]
> 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note<= br> > this is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
> - 0x0201 - rsa_pkcs1_sha1
> - 0x0301 - rsa_pkcs1_sha224
> - 0x0401 - rsa_pkcs1_sha256
> - 0x0501 - rsa_pkcs1_sha334
> - 0x0601 - rsa_pkcs1_sha512
> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility > but ignored in TLS 1.3.
>
> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3]<= br> > to avoid colliding with existing signature algorithms, but I don=E2=80= =99t
> think that=E2=80=99s necessary[3].
> - rsapss_sha256
> - rsapss_sha384
> - rsapss_sha512
> - ecdsa_p256_sha256
> - ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha384
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448

Then what ECDHE share gets signed?
if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no =C2=A0- rsapss_dh2048_sha256
=C2=A0- rsapss_dh3072_sha256
=C2=A0- rsapss_dh4096_sha384
=C2=A0- (etc.)
=C2=A0- rsapss_p256_sha256
=C2=A0- rsapss_p384_sha384
=C2=A0- (etc.)

If it does not specify the DH share signed, it doesn't really change anything...

Why would it need to specif= y what [DH group's] DH share gets signed? NamedGroup still exists for t= he key exchange (see step 1). I'm only proposing pulling signature curv= es out of NamedGroup.

(Is the DH share even signed= directly? It looks like TLS 1.3 signs via CertificateVerify's handshak= e context in both directions. Either way, it's just a byte-string messa= ge. We could also backport this sort of thing to TLS 1.2 and the signature = algorithm still doesn't care about the DH share. That gets encoded into= a byte string somehow.)

I'm trying to make the decomposi= tions and premultiplications align with how the protocol is structured. TLS= 1.2 decomposed algorithm, signing curve, and hash which isn't universa= l (Ed25519, Ed448, even RSA-PSS's params in full generality aren't = the same shape, the definition of "digitally-signed" takes only a= byte-string message as input), so they should be premultiplied. Whereas si= gnature algorithm and DH group are cleanly separated in the protocol and ne= edn't be premultiplied.

David=C2=A0
--047d7b2e3fe6adf0a30529b2aaba-- From nobody Tue Jan 19 09:53:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304C71B33BC for ; Tue, 19 Jan 2016 09:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 9lWDN5sXeVlS for ; Tue, 19 Jan 2016 09:53:33 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 E75841B33BF for ; Tue, 19 Jan 2016 09:53:24 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id x4so112109983lbm.0 for ; Tue, 19 Jan 2016 09:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0mFr61Jf7/Dne5TFTEaOOtkXoZqpyMVlQ139VvYyeg=; b=voZhmlhCJHCZutKxsxXLH8DjAyANLr3s54PfYCO78KveKBmvlIEKC2gTr3KNvTyNsB yrzm/gC2Xf5erWZ3rKjk2VCbAKkvlzIkuDqWKlUZRwXE6j9hUWhx0WiJflUN1segdU9T sDxTVF1W/y3Owasgs1eyK/6kcVZidMkt/+AirEXDLrRId3me9uygN7xuHYo9r3drn140 BVsxzJb4BbHMzzaEpM5yItO2Rjj8XOlX1RPST66uabLQ+ZxdUBHQE/aN+WIvBsjGJnh1 PnVErgd4r33DcfYUn33e3yGR7PcedbKCUcaCGcE61TBTBywVGcoi+v5Hy8FVF9Niad73 NKXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m0mFr61Jf7/Dne5TFTEaOOtkXoZqpyMVlQ139VvYyeg=; b=f1kulCKtl0HUqHZPKFEWnXwdRXczL8rlCnaArLUXT5diJ9YjW45cuf2yIFTyGgsPUy 2+pDAsCRNZtQ8UczpdJsjlnA3qdzW6vneQZoXouHWwdlHKJluBYyl/etEIUgnPpMxf8O d4Wl1KzE5oJkXJEqqJoAqexveuJ+wfZF2Fca0jvmNaLKBTLklC84cBNapfJTkjSkj++7 ERWxF2nNs7uCfW9mvDPPhSZntN9Yr4BY10Ium1Nk+xRHnTdNYpm9eePF7pUDuV7nCzqi oLGIxZybwfvmw/Hx2tEik6ZnndFOYPTfCJacfcixWF8ENnaqorR1BUVftfG8ygwmCQmm dlAg== X-Gm-Message-State: ALoCoQkVt4ofPs3b9JJB1KGV03wCrcjsWJPzBK/Ov+M0w48bNG1Do1UuEoKdU3ceAlFjoacfnWXxMMhpZibfnOUSlbGyoxSZdQ== MIME-Version: 1.0 X-Received: by 10.112.140.169 with SMTP id rh9mr9203711lbb.69.1453226003120; Tue, 19 Jan 2016 09:53:23 -0800 (PST) Received: by 10.112.2.104 with HTTP; Tue, 19 Jan 2016 09:53:23 -0800 (PST) In-Reply-To: References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> Date: Tue, 19 Jan 2016 09:53:23 -0800 Message-ID: From: Joseph Salowey To: Brian Smith Content-Type: multipart/alternative; boundary=001a11c25934b1db160529b38b24 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 17:53:34 -0000 --001a11c25934b1db160529b38b24 Content-Type: text/plain; charset=UTF-8 Any objections to early allocation for X25519 and X448? Are there implementers with code ready to test interop? Thanks, Joe On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith wrote: > Simon Josefsson wrote: > >> Allocating a code point for X25519 could be done and is long overdue >> (first draft September 2013). X448 is also stable. Code points for >> Ed25519 and Ed448 is more problematic since TLS authentication has >> historically had interaction with PKIX certs. I agree with Yoav's >> assertion that the curve point verification issue is not big enough to >> stall code point allocation. > > > I agree with this. > > Cheers, > Brian > --001a11c25934b1db160529b38b24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Any objections to early allocation for X25519 and X448?=C2= =A0 Are there implementers with code ready to test interop? =C2=A0

=
Thanks,

Joe

On Thu, Jan 14, 2016 at 3:22 PM, = Brian Smith <brian@briansmith.org> wrote:

--001a11c25934b1db160529b38b24-- From nobody Tue Jan 19 10:00:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207731B33C4 for ; Tue, 19 Jan 2016 10:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 A6R2NcwXL17V for ; Tue, 19 Jan 2016 10:00:51 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90811B329C for ; Tue, 19 Jan 2016 10:00:51 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id q21so589601717iod.0 for ; Tue, 19 Jan 2016 10:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=rAa5ZnCKxtUdGZMcyZYf5bARnZU8wvAgkxVGMx2SWOY=; b=f6KbvCMSYXTG10YtO4QOqUxPaZCku4RL+FI8EG9k+Og58wUVUXKj2baEWXvYYHODUP ZBqAEEQXMzk2/gVIJQZxt7EF75IHXY2bNzla5MJvOyCPdYRjoCFCn2b9oUuCiMsKY5Zg EiFeXfRKyNpjARq3tfP87MiaaHHD8/aIytJSQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=rAa5ZnCKxtUdGZMcyZYf5bARnZU8wvAgkxVGMx2SWOY=; b=CnzvjW6Hhjn/0lhTyYgnQa62rh/TS0TcdO1lFoXeM15XpA9TkMYWNCOyL1WZ/w0gUM 2mARR9bXlDHLwJtlM0EHKO+n2YBgLcANyFbNM2bILlOPanznjv3r2tEIs1/TAfZpdSrq xsSzTAXI3V7VabPpyn1+wA5PM7VJMzcSFwfnezvW6lVo+Vd2fPp2bqB3vra2LdAZs/IU aOnMbku4kyioa/hBdfg5SsjzifKigdX9GKyCRqUZdGrFVU4oN4v4TA3A9dd7d8IfpQps z67Ev335f4265nlcL10UghDYH9nptgXxoOaUtt83OToutYLsu5V/p98ptAEYnytaF5AB GAbw== X-Gm-Message-State: ALoCoQnskR0FSiQPRaa1VqUD/7XGAkkTacWUCzqW8tS5rjSwd9sSNMnAOKIO58LglC/haMMJvGskWr8nTW5TmC8minM6ERg0UTx96l71tMLVR5y1O5ZGbqs= X-Received: by 10.107.30.15 with SMTP id e15mr27625355ioe.166.1453226450934; Tue, 19 Jan 2016 10:00:50 -0800 (PST) MIME-Version: 1.0 References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> In-Reply-To: From: David Benjamin Date: Tue, 19 Jan 2016 18:00:40 +0000 Message-ID: To: Joseph Salowey , Brian Smith Content-Type: multipart/alternative; boundary=001a1140c900632b290529b3a6a6 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 18:00:53 -0000 --001a1140c900632b290529b3a6a6 Content-Type: text/plain; charset=UTF-8 BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon. David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey wrote: > Any objections to early allocation for X25519 and X448? Are there > implementers with code ready to test interop? > > Thanks, > > Joe > > On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith wrote: > >> Simon Josefsson wrote: >> >>> Allocating a code point for X25519 could be done and is long overdue >>> (first draft September 2013). X448 is also stable. Code points for >>> Ed25519 and Ed448 is more problematic since TLS authentication has >>> historically had interaction with PKIX certs. I agree with Yoav's >>> assertion that the curve point verification issue is not big enough to >>> stall code point allocation. >> >> >> I agree with this. >> >> Cheers, >> Brian >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1140c900632b290529b3a6a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BoringSSL has a pair of implementations ready (in C and in= our fork of Go's TLS stack for testing). We're using the value in = the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome buil= ds, but I'm expecting to change this soon.

David

Any objections to early allocation for = X25519 and X448?=C2=A0 Are there implementers with code ready to test inter= op? =C2=A0

Thanks,

Joe

On Thu, Jan 14= , 2016 at 3:22 PM, Brian Smith <brian@briansmith.org> wro= te:
Simon Josefsson &= lt;simon@josefsson= .org> wrote:
Allocating a c= ode point for X25519 could be done and is long overdue
(first draft September 2013).=C2=A0 X448 is also stable.=C2=A0 Code points = for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.=C2=A0 I agree with Yoav's=
assertion that the curve point verification issue is not big enough to
stall code point allocation.

I agree= with this.

Cheers,
Brian

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1140c900632b290529b3a6a6-- From nobody Tue Jan 19 10:25:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609D41B33FD for ; Tue, 19 Jan 2016 10:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4D7fvVlYAeE for ; Tue, 19 Jan 2016 10:25:16 -0800 (PST) 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 16F901B33FB for ; Tue, 19 Jan 2016 10:25:15 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6C2F918B249; Tue, 19 Jan 2016 18:25:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0JIPDNK023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2016 13:25:14 -0500 From: Hubert Kario To: David Benjamin Date: Tue, 19 Jan 2016 19:25:13 +0100 Message-ID: <1717909.HACNtZYKZV@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2622625.sc6tRH5ysJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 18:25:18 -0000 --nextPart2622625.sc6tRH5ysJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 19 January 2016 16:50:18 David Benjamin wrote: > On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario =20 wrote: > > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > > Hi folks, > > >=20 > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm.= > > > In > > > TLS 1.2, signature algorithms are spread across the handshake. We= > > > have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and > > > HashAlgorithm, all in independent registries. NamedGroup is sent > > > in > > > one list, also used for (EC)DH, while the other two are sent as a= > > > pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in > > > separate registries. > > >=20 > > > This is a lot of moving parts. Signature negotiation in TLS 1.2 > > > tends > > > to be messy to implement. Client certificate keys may be in > > > smartcards via OS-specific APIs, so a lot of time is spent > > > transiting > > > new preference shapes across API boundaries in order to discover > > > smartcard bugs. Sometimes I think people deploy client certs > > > because > > > they hate me and want to cause me pain=E2=80=A6 :-) > > >=20 > > > Anyway, the new CFRG curves also bind signature curve and hash > > > together. The current draft represents this as eddsa_ed25519 and > > > eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this > > > doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is illegal= . (Or > > > ECDSA > > > + FF3072.) > > >=20 > > > I propose we fold the negotiable parameters under one name. Think= > > > of > > > how we=E2=80=99ve all settled on AEADs being a good named primiti= ve with a > > > common type signature[1]. Specifically: > > >=20 > > > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. > > > From > > > now on, NamedGroup is only used for (EC)DH. > > >=20 > > > 2. Remove HashAlgorithm, SignatureAlgorithm, > > > SignatureAndHashAlgorithm as they are. Introduce a new > > > SignatureAlgorithm u16 type and negotiate that instead. (Or maybe= > > > a different name to not collide.) u8 is a little tight to > > > allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is > > > plenty. > > >=20 > > > 3. Allocate values for SignatureAlgorithm wire-compatibly with TL= S > > > 1.2 by (ab)using the old (HashAlgorithm, SignatureAlgorithm) > > > tuples. 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges > > > consistently with HashAlgorithm from TLS 1.2. Note this does not > > > introduce new premultiplications on the wire. Just in the spec > > > and registry. > > >=20 > > > 4. Deprecate ecdsa_sha256, etc., in favor of new > > > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The ol= d > > > ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS > > > 1.3. > > > Although this introduces new premultiplications, it=E2=80=99s onl= y 9 > > > values > > > with the pruned TLS 1.3 lists. I think this is worth 9 values to > > > keep > > > NamedGroups separate. > > >=20 > > > 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and > > > rsapss_{sha256,sha384,sha512}. These come with the signature > > > algorithm and curve pre-specified. (See [2] at the bottom for > > > full list of allocations.) > > >=20 > > > Thoughts? > > >=20 > > > David > > >=20 > > > [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll nee= d some > > > mapping to a subset of X.509's RSA-PSS. We'll just not bother wit= h > > > RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm > > > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, > > > trailerField 14. And RSA key generation still has size parameter.= > > > Hopefully future things can look more like Ed25519. > > >=20 > > > [2] > > > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. > > > Note > > > this is wire-compatible with TLS 1.2. > > > - 0x0101 - rsa_pkcs1_md5 > > > - 0x0201 - rsa_pkcs1_sha1 > > > - 0x0301 - rsa_pkcs1_sha224 > > > - 0x0401 - rsa_pkcs1_sha256 > > > - 0x0501 - rsa_pkcs1_sha334 > > > - 0x0601 - rsa_pkcs1_sha512 > > > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. > > > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 > > > compatibility > > > but ignored in TLS 1.3. > > >=20 > > > 0x0700-0xfdff - Allocate new values here. Optionally avoid > > > 0x??0[0-3] > > > to avoid colliding with existing signature algorithms, but I don=E2= =80=99t > > > think that=E2=80=99s necessary[3]. > > > - rsapss_sha256 > > > - rsapss_sha384 > > > - rsapss_sha512 > > > - ecdsa_p256_sha256 > > > - ecdsa_p256_sha384 > > > - ecdsa_p256_sha512 > > > - ecdsa_p384_sha256 > > > - ecdsa_p384_sha384 > > > - ecdsa_p384_sha512 > > > - ecdsa_p521_sha256 > > > - ecdsa_p521_sha384 > > > - ecdsa_p521_sha512 > > > - eddsa_ed25519 > > > - eddsa_ed448 > >=20 > > Then what ECDHE share gets signed? > > if the same as the curve, what about FFDHE, what about ECDHE-RSA? > > why no>=20 > > - rsapss_dh2048_sha256 > > - rsapss_dh3072_sha256 > > - rsapss_dh4096_sha384 > > - (etc.) > > - rsapss_p256_sha256 > > - rsapss_p384_sha384 > > - (etc.) > >=20 > > If it does not specify the DH share signed, it doesn't really chang= e > > anything... >=20 > Why would it need to specify what [DH group's] DH share gets signed? > NamedGroup still exists for the key exchange (see step 1). I'm only > proposing pulling signature curves out of NamedGroup. >=20 > (Is the DH share even signed directly? It looks like TLS 1.3 signs vi= a > CertificateVerify's handshake context in both directions. Either way,= > it's just a byte-string message. We could also backport this sort of > thing to TLS 1.2 and the signature algorithm still doesn't care about= > the DH share. That gets encoded into a byte string somehow.) >=20 > I'm trying to make the decompositions and premultiplications align > with how the protocol is structured. TLS 1.2 decomposed algorithm, > signing curve, and hash which isn't universal (Ed25519, Ed448, even > RSA-PSS's params in full generality aren't the same shape, the > definition of "digitally-signed" takes only a byte-string message as > input), so they should be premultiplied. Whereas signature algorithm > and DH group are cleanly separated in the protocol and needn't be > premultiplied. Problem I am pointing out is that NamedGroup specifies not only what=20= curves can be used for signing but also what curves can get signed. Or are you saying that the NamedGroup would stay, and would now specify= =20 only the supported parameters for the key exchange, not how they are=20= authenticated (as it is now)? Or to put it other way: what extensions and with what values should I=20= sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with eithe= r=20 P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA= ? =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2622625.sc6tRH5ysJ 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 iQIcBAABCgAGBQJWnn+JAAoJEJKo0bgB0vX1p8YP/3Emv9ueKKogQ2BNpnsHHvsP sDBVoBSzjWtg7J/q5nKrEF1fdg0FzkuXBpT8x+eJ8odYEg9Ssc9fqIg5fxSgita6 UezezjvCWoOKZs95mKQ1gCX4wkjewPR+reUFv4IIOdX4iXXUcVUFg9jsIhTYQxyd FY5LwV/TiqVB9jazlK/c3bx3RtMo8dCLXtQndH6YwaKY8BtiAdXhkXU+DP/RU0iA TEueBLArg/P8xU5jbDZbpe8WKqWgdFBTGz0ZHgJCtTe1s+bh09O89TNW4RynQha9 LTNXvJFMmyvT3ZJqRoQGCEa2kZB2wgUxzD5D5GseIbRB9iq4L7fCIWbcoZ5VgQNJ 8UpujmmiUmXTMQr5nW6uqA/bM3VuxGYEw4NDM+0/dfKJcnWysrIJA6HQCQBYwMRT +Pn+u1qIJ/lg8rvMkrKW9XtQWw7hjRjSrTCDiJKwULUk/Mf5Jw1H5GXvf7aKQ7+y 3ndqxLVFvGA0K28g017boIbPKPeoAR1q9OvhtWVmaU9WTLMxUU21PhPgrDVQPo6z o9S1n6ZQeRk55X71EBOoDr2J5dJjjXYbRcgmQ0Jfy5kG9nmcm5JKCkymrgYK9Fln Sgukmuxxvc3Kfa2LUMyx5LHKOw+redJHzxaWZMmyEAZpWfZAiyoYJH3ffz6DkfXl 8mrg0KPtkixYHMqr1d8s =vgNh -----END PGP SIGNATURE----- --nextPart2622625.sc6tRH5ysJ-- From nobody Tue Jan 19 10:56:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95B41B3460 for ; Tue, 19 Jan 2016 10:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 MMoxbcbsgCK2 for ; Tue, 19 Jan 2016 10:56:00 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 E9F9B1B345C for ; Tue, 19 Jan 2016 10:55:59 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id z14so84485207igp.1 for ; Tue, 19 Jan 2016 10:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=OkmCFkpEzVG3tHSY7Nikp7xrdfN5AccfWVrQXBdi5i8=; b=d8lUlrfzoFHaM+RPB+ZDpNIpDOz1/Gp9GlwRvJuOq/bX/6M7zq6k7WsIEsoF7KLWO0 GOUhDz+eGpF8Coj/bycsrL4uhFNDUDw9NmZEBVbDO4XiWAUwJYgRT/kqUt4uho8cLTmr EsKYVeSOS8QIEz5zigXNYyD4IqkDJNPRc/u8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=OkmCFkpEzVG3tHSY7Nikp7xrdfN5AccfWVrQXBdi5i8=; b=f02qRHxEtbndQ+x3pXDzDkUhM0G5jEl8JL9JEv8iiAUPx4FFHizESQvOTy4CSipIxN SSDuC+Hb8U6brB+XZJYni6lfb1pBy59+G9eF4dHlqsTd/PuWuzbFYrrwRzeMAyLv/0BU t1h9xm3VK8XjtE92iqhrY3T4JysX4X9ajsh85+G9CdhNTqaTXE89RjeaQBw7kMuRESko D2vIMzM1vMBgZfPLbcZXijLb/iwaUOmUOImqqrDwT9H3/JmYgNM/OEa9yLQhBWiMLaVU s0/ZBrcwAou8OywttZHqAGlolntnFMCoRr6XcW3dtNHZkZxnQMySn4516kci1FUd0FiS //+A== X-Gm-Message-State: AG10YORovYfS2MfLT8+j4Jj5lMgPI8lrvBJ7Ih5IjuX5zRg375uEjSyBwUIJZyvo9I9fxk52yOabODaySW7/MHSy X-Received: by 10.50.8.106 with SMTP id q10mr15964758iga.67.1453229759045; Tue, 19 Jan 2016 10:55:59 -0800 (PST) MIME-Version: 1.0 References: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> <1717909.HACNtZYKZV@pintsize.usersys.redhat.com> In-Reply-To: <1717909.HACNtZYKZV@pintsize.usersys.redhat.com> From: David Benjamin Date: Tue, 19 Jan 2016 18:55:49 +0000 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=089e013c65dc914b740529b46b86 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 18:56:01 -0000 --089e013c65dc914b740529b46b86 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote: > > > If it does not specify the DH share signed, it doesn't really change > > > anything... > > > > Why would it need to specify what [DH group's] DH share gets signed? > > NamedGroup still exists for the key exchange (see step 1). I'm only > > proposing pulling signature curves out of NamedGroup. > > > > (Is the DH share even signed directly? It looks like TLS 1.3 signs via > > CertificateVerify's handshake context in both directions. Either way, > > it's just a byte-string message. We could also backport this sort of > > thing to TLS 1.2 and the signature algorithm still doesn't care about > > the DH share. That gets encoded into a byte string somehow.) > > > > I'm trying to make the decompositions and premultiplications align > > with how the protocol is structured. TLS 1.2 decomposed algorithm, > > signing curve, and hash which isn't universal (Ed25519, Ed448, even > > RSA-PSS's params in full generality aren't the same shape, the > > definition of "digitally-signed" takes only a byte-string message as > > input), so they should be premultiplied. Whereas signature algorithm > > and DH group are cleanly separated in the protocol and needn't be > > premultiplied. > > Problem I am pointing out is that NamedGroup specifies not only what > curves can be used for signing but also what curves can get signed. > > Or are you saying that the NamedGroup would stay, and would now specify > only the supported parameters for the key exchange, not how they are > authenticated (as it is now)? > Yes. > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now on, NamedGroup is only used for (EC)DH. > On Tuesday 19 January 2016 16:50:18 David Benjamin wrote: > Why would it need to specify what [DH group's] DH share gets signed? > NamedGroup still exists for the key exchange (see step 1). I'm only > proposing pulling signature curves out of NamedGroup. Or to put it other way: what extensions and with what values should I > sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either > P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA? supported_groups {p256, p384} supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512} (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.) For your example, nothing on the wire changes at all. Before, you'd end up sending: supported_groups {p256, p384} supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512, rsa}} And rsa_pkcs1_sha256 should be allocated to align with {sha256, rsa}, etc. The interesting case is Ed25519 and Ed448. You'd currently have to send: supported_groups {..., eddsa_ed25519, eddsa_ed448} supported_signature_algorithms {..., {sha512, eddsa}, {shake256[1], eddsa}} However, this does not capture that {shake256, eddsa} + eddsa_ed25519 isn't legal. Instead I want: supported_groups {..., irrelevant to ed25519 and friends} supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448} David [1] I have not been following the CFRG curve work very closely. Adam tells me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion, let's assume that's how it ends up. --089e013c65dc914b740529b46b86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 19= , 2016 at 1:25 PM Hubert Kario <hkario@redhat.com> wrote:
> > If it does not specify the DH share signed, it doesn'= ;t really change
> > anything...
>
> Why would it need to specify what [DH group's] DH share gets signe= d?
> NamedGroup still exists for the key exchange (see step 1). I'm onl= y
> proposing pulling signature curves out of NamedGroup.
>
> (Is the DH share even signed directly? It looks like TLS 1.3 signs via=
> CertificateVerify's handshake context in both directions. Either w= ay,
> it's just a byte-string message. We could also backport this sort = of
> thing to TLS 1.2 and the signature algorithm still doesn't care ab= out
> the DH share. That gets encoded into a byte string somehow.)
>
> I'm trying to make the decompositions and premultiplications align=
> with how the protocol is structured. TLS 1.2 decomposed algorithm,
> signing curve, and hash which isn't universal (Ed25519, Ed448, eve= n
> RSA-PSS's params in full generality aren't the same shape, the=
> definition of "digitally-signed" takes only a byte-string me= ssage as
> input), so they should be premultiplied. Whereas signature algorithm > and DH group are cleanly separated in the protocol and needn't be<= br> > premultiplied.

Problem I am pointing out is that NamedGroup specifies not only what
curves can be used for signing but also what curves can get signed.

Or are you saying that the NamedGroup would stay, and would now specify
only the supported parameters for the key exchange, not how they are
authenticated (as it is now)?

Yes.=C2=A0<= /div>

> On Friday 15 January 2016 20:45:34 David = Benjamin wrote:
> 1. Drop eddsa_ed25519(31) and e= ddsa_ed448(32) from NamedGroup. From now on, NamedGroup is only used for (E= C)DH.

> On Tuesday 19 January 2016 16:50:= 18 David Benjamin wrote:
> Why would it need to s= pecify what [DH group's] DH share gets signed?
> NamedGrou= p still exists for the key exchange (see step 1). I'm only
&g= t; proposing pulling signature curves out of NamedGroup.
= =C2=A0

Or to put it other way: what extensions and with what values should I
sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?

supported_groups {p256, p384}
<= div>supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa= _pkcs1_sha512}
(Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)
=

For your example, nothing on the wire changes at all. B= efore, you'd end up sending:
supported_groups {p256, p384}
supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512= , rsa}}
And=C2=A0rsa_pkcs1_sha256 should be allocated to align with {sha= 256, rsa}, etc.

The interesting case is Ed25= 519 and Ed448. You'd currently have to send:
supported_groups= {..., eddsa_ed25519, eddsa_ed448}
supported_signature_algorithms= {..., {sha512, eddsa}, {shake256[1], eddsa}}

However, this does not= capture that {shake256, eddsa}=C2=A0+ eddsa_ed25519 isn't legal. Inste= ad I want:
supported_groups {..., irrelevant to ed25519 and friends= }
supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448= }

David

[1] I have not been following the = CFRG curve work very closely. Adam tells me Ed448 is likely to be bound to = SHAKE-256. For the sake of discussion, let's assume that's how it e= nds up.
--089e013c65dc914b740529b46b86-- From nobody Tue Jan 19 11:00:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0A1B346E for ; Tue, 19 Jan 2016 11:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEWB0ptVoL5a for ; Tue, 19 Jan 2016 11:00:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E1B1B346A for ; Tue, 19 Jan 2016 11:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kw3iAqm+5AXpzasOM5FBho6xXD9C3xqzk3uR+j5Pnw4=; b=EUY2aW/IiEcszKVZ3d0/Ky3Nwjhr/oOrpB5SDH7bThVSKPhHQtTa/FH5PJh1orhzraOOo7jjLkEAGafVDqLczsqWPZVVdCrrubAHWx2mHSUGqNyPfg20OO5netc0Qv6JzdYPn42a1F44LMAMUviYJC6WrsWdTq/xCizAf6NBMdo= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 18:59:54 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0365.024; Tue, 19 Jan 2016 18:59:54 +0000 From: Andrei Popov To: David Benjamin , Joseph Salowey , Brian Smith Thread-Topic: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 Thread-Index: AQHRTW8rTSREyY74WE69KiP5VcYCAJ74UruAgAATq4CAAOMdgIAAXdeAgAF6cbyAAIglgIAHf8WAgAACCQCAAA/ZAA== Date: Tue, 19 Jan 2016 18:59:54 +0000 Message-ID: References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 3e62db0a-2db2-4fe0-45aa-08d32102b7c9 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:yWCHHfvgwTI5PACk/YTh6Jv9qEg2idAAWV4eUfZHE2zw1gymUIMNGt2+qocDq3FHEIB00kyU2xHBW41yJgXGudpLcHCnRqWaHKlmqATL5CeMCI+e2wErfNJUSxVnAfim1f+TllbAtoq3h2UWWD8yYw==; 24:CtivCwK7iKiS5TMDi3AUNr7Bbm1HDfcajWmQGhyQWfTT84YzzxwVMNraWkF1in3W51Ks8RXKj9eo9SK0FBRFp5cmOFP8cFKGINzwO684p/4= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(24454002)(199003)(164054003)(16236675004)(15975445007)(122556002)(19617315012)(5002640100001)(5001770100001)(33656002)(5001960100002)(19300405004)(93886004)(5003600100002)(19580395003)(2950100001)(86612001)(19580405001)(19625215002)(86362001)(2900100001)(97736004)(54356999)(50986999)(76176999)(77096005)(40100003)(74316001)(81156007)(106356001)(19609705001)(189998001)(10400500002)(2906002)(4326007)(8990500004)(106116001)(87936001)(101416001)(92566002)(6116002)(790700001)(10290500002)(11100500001)(102836003)(76576001)(105586002)(5008740100001)(10090500001)(1096002)(586003)(99286002)(1220700001)(5005710100001)(5004730100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396B5360C32F906A8E0E87C8CC10BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 18:59:54.2694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 19:00:17 -0000 --_000_BLUPR03MB1396B5360C32F906A8E0E87C8CC10BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBwbGVhc2UgYWxsb2NhdGUsIGVzcC4gMjU1MTkuIE1TIHdpbGwgc3RhcnQgdGVzdGluZyBp bnRlcm9wIHNvb24uDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgQmVuamFtaW4NClNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMTksIDIwMTYgMTA6MDEgQU0NClRvOiBKb3NlcGggU2Fsb3dleSA8am9l QHNhbG93ZXkubmV0PjsgQnJpYW4gU21pdGggPGJyaWFuQGJyaWFuc21pdGgub3JnPg0KQ2M6IEFk YW0gTGFuZ2xleSA8YWdsQGltcGVyaWFsdmlvbGV0Lm9yZz47IFNpbW9uIEpvc2Vmc3NvbiA8c2lt b25Aam9zZWZzc29uLm9yZz47IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIENvcnJl Y3Rpb246IGVhcmx5IGNvZGVwb2ludCBhc3NpZ25tZW50IGZvciBDdXJ2ZTI1NTE5LCBDdXJ2ZTQ0 OCwgRWQyNTUxOSBhbmQgRWQ0NDgNCg0KQm9yaW5nU1NMIGhhcyBhIHBhaXIgb2YgaW1wbGVtZW50 YXRpb25zIHJlYWR5IChpbiBDIGFuZCBpbiBvdXIgZm9yayBvZiBHbydzIFRMUyBzdGFjayBmb3Ig dGVzdGluZykuIFdlJ3JlIHVzaW5nIHRoZSB2YWx1ZSBpbiB0aGUgVExTIDEuMyBkcmFmdCwgc28g MjkuIEl0J3Mgbm90IGN1cnJlbnRseSBlbmFibGVkIGluIGFueSBDaHJvbWUgYnVpbGRzLCBidXQg SSdtIGV4cGVjdGluZyB0byBjaGFuZ2UgdGhpcyBzb29uLg0KDQpEYXZpZA0KDQpPbiBUdWUsIEph biAxOSwgMjAxNiBhdCAxMjo1NCBQTSBKb3NlcGggU2Fsb3dleSA8am9lQHNhbG93ZXkubmV0PG1h aWx0bzpqb2VAc2Fsb3dleS5uZXQ+PiB3cm90ZToNCkFueSBvYmplY3Rpb25zIHRvIGVhcmx5IGFs bG9jYXRpb24gZm9yIFgyNTUxOSBhbmQgWDQ0OD8gIEFyZSB0aGVyZSBpbXBsZW1lbnRlcnMgd2l0 aCBjb2RlIHJlYWR5IHRvIHRlc3QgaW50ZXJvcD8NCg0KVGhhbmtzLA0KDQpKb2UNCg0KT24gVGh1 LCBKYW4gMTQsIDIwMTYgYXQgMzoyMiBQTSwgQnJpYW4gU21pdGggPGJyaWFuQGJyaWFuc21pdGgu b3JnPG1haWx0bzpicmlhbkBicmlhbnNtaXRoLm9yZz4+IHdyb3RlOg0KU2ltb24gSm9zZWZzc29u IDxzaW1vbkBqb3NlZnNzb24ub3JnPG1haWx0bzpzaW1vbkBqb3NlZnNzb24ub3JnPj4gd3JvdGU6 DQpBbGxvY2F0aW5nIGEgY29kZSBwb2ludCBmb3IgWDI1NTE5IGNvdWxkIGJlIGRvbmUgYW5kIGlz IGxvbmcgb3ZlcmR1ZQ0KKGZpcnN0IGRyYWZ0IFNlcHRlbWJlciAyMDEzKS4gIFg0NDggaXMgYWxz byBzdGFibGUuICBDb2RlIHBvaW50cyBmb3INCkVkMjU1MTkgYW5kIEVkNDQ4IGlzIG1vcmUgcHJv YmxlbWF0aWMgc2luY2UgVExTIGF1dGhlbnRpY2F0aW9uIGhhcw0KaGlzdG9yaWNhbGx5IGhhZCBp bnRlcmFjdGlvbiB3aXRoIFBLSVggY2VydHMuICBJIGFncmVlIHdpdGggWW9hdidzDQphc3NlcnRp b24gdGhhdCB0aGUgY3VydmUgcG9pbnQgdmVyaWZpY2F0aW9uIGlzc3VlIGlzIG5vdCBiaWcgZW5v dWdoIHRvDQpzdGFsbCBjb2RlIHBvaW50IGFsbG9jYXRpb24uDQoNCkkgYWdyZWUgd2l0aCB0aGlz Lg0KDQpDaGVlcnMsDQpCcmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZkYXRhPTAxJTdjMDEl N2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjZjk4YTY5ZjU3NDliNDIwMWRiOTYwOGQz MjBmYTdkNDElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NXZl aG9UeVFydW5LSk9LcWVXb2xIOVRTQW5kSFNXaFg0ekt6NVJzQmNKMCUzZD4NCg== --_000_BLUPR03MB1396B5360C32F906A8E0E87C8CC10BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCBwbGVhc2UgYWxsb2NhdGUsIGVz cC4gMjU1MTkuIE1TIHdpbGwgc3RhcnQgdGVzdGluZyBpbnRlcm9wIHNvb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhdmlkIEJlbmphbWluPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMTksIDIwMTYgMTA6MDEgQU08YnI+DQo8 Yj5Ubzo8L2I+IEpvc2VwaCBTYWxvd2V5ICZsdDtqb2VAc2Fsb3dleS5uZXQmZ3Q7OyBCcmlhbiBT bWl0aCAmbHQ7YnJpYW5AYnJpYW5zbWl0aC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBZGFtIExh bmdsZXkgJmx0O2FnbEBpbXBlcmlhbHZpb2xldC5vcmcmZ3Q7OyBTaW1vbiBKb3NlZnNzb24gJmx0 O3NpbW9uQGpvc2Vmc3Nvbi5vcmcmZ3Q7OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtUTFNdIENvcnJlY3Rpb246IGVhcmx5IGNvZGVwb2ludCBhc3NpZ25tZW50IGZvciBD dXJ2ZTI1NTE5LCBDdXJ2ZTQ0OCwgRWQyNTUxOSBhbmQgRWQ0NDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb3JpbmdTU0wgaGFzIGEgcGFpciBvZiBpbXBsZW1lbnRhdGlv bnMgcmVhZHkgKGluIEMgYW5kIGluIG91ciBmb3JrIG9mIEdvJ3MgVExTIHN0YWNrIGZvciB0ZXN0 aW5nKS4gV2UncmUgdXNpbmcgdGhlIHZhbHVlIGluIHRoZSBUTFMgMS4zIGRyYWZ0LCBzbyAyOS4g SXQncyBub3QgY3VycmVudGx5IGVuYWJsZWQgaW4gYW55IENocm9tZSBidWlsZHMsIGJ1dCBJJ20g ZXhwZWN0aW5nIHRvIGNoYW5nZSB0aGlzIHNvb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAxOSwgMjAxNiBhdCAxMjo1NCBQ TSBKb3NlcGggU2Fsb3dleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZUBzYWxvd2V5Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmpvZUBzYWxvd2V5Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueSBv YmplY3Rpb25zIHRvIGVhcmx5IGFsbG9jYXRpb24gZm9yIFgyNTUxOSBhbmQgWDQ0OD8mbmJzcDsg QXJlIHRoZXJlIGltcGxlbWVudGVycyB3aXRoIGNvZGUgcmVhZHkgdG8gdGVzdCBpbnRlcm9wPyAm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Sm9lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDM6MjIgUE0sIEJyaWFuIFNtaXRoICZsdDs8YSBocmVm PSJtYWlsdG86YnJpYW5AYnJpYW5zbWl0aC5vcmciIHRhcmdldD0iX2JsYW5rIj5icmlhbkBicmlh bnNtaXRoLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbW9uIEpvc2Vmc3NvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNpbW9uQGpvc2Vmc3Nvbi5vcmciIHRhcmdldD0iX2JsYW5rIj5z aW1vbkBqb3NlZnNzb24ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsb2NhdGluZyBhIGNvZGUgcG9pbnQgZm9yIFgy NTUxOSBjb3VsZCBiZSBkb25lIGFuZCBpcyBsb25nIG92ZXJkdWU8YnI+DQooZmlyc3QgZHJhZnQg U2VwdGVtYmVyIDIwMTMpLiZuYnNwOyBYNDQ4IGlzIGFsc28gc3RhYmxlLiZuYnNwOyBDb2RlIHBv aW50cyBmb3I8YnI+DQpFZDI1NTE5IGFuZCBFZDQ0OCBpcyBtb3JlIHByb2JsZW1hdGljIHNpbmNl IFRMUyBhdXRoZW50aWNhdGlvbiBoYXM8YnI+DQpoaXN0b3JpY2FsbHkgaGFkIGludGVyYWN0aW9u IHdpdGggUEtJWCBjZXJ0cy4mbmJzcDsgSSBhZ3JlZSB3aXRoIFlvYXYnczxicj4NCmFzc2VydGlv biB0aGF0IHRoZSBjdXJ2ZSBwb2ludCB2ZXJpZmljYXRpb24gaXNzdWUgaXMgbm90IGJpZyBlbm91 Z2ggdG88YnI+DQpzdGFsbCBjb2RlIHBvaW50IGFsbG9jYXRpb24uPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGgg dGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs aXN0aW5mbyUyZnRscyZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0 LmNvbSU3Y2Y5OGE2OWY1NzQ5YjQyMDFkYjk2MDhkMzIwZmE3ZDQxJTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT01dmVob1R5UXJ1bktKT0txZVdvbEg5VFNB bmRIU1doWDR6S3o1UnNCY0owJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB1396B5360C32F906A8E0E87C8CC10BLUPR03MB1396namp_-- From nobody Tue Jan 19 11:28:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285931B34C7 for ; Tue, 19 Jan 2016 11:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykp4A4H47XxQ for ; Tue, 19 Jan 2016 11:28:20 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BB9041B34C3 for ; Tue, 19 Jan 2016 11:28:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 40BE85E3; Tue, 19 Jan 2016 21:28:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id VD3K_YlJpyrx; Tue, 19 Jan 2016 21:28:19 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 02A0E230D; Tue, 19 Jan 2016 21:28:19 +0200 (EET) Date: Tue, 19 Jan 2016 21:28:15 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160119192815.GA5795@LK-Perkele-V2.elisa-laajakaista.fi> References: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> <1717909.HACNtZYKZV@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 19:28:23 -0000 On Tue, Jan 19, 2016 at 06:55:49PM +0000, David Benjamin wrote: > On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote: > > > > > Problem I am pointing out is that NamedGroup specifies not only what > > curves can be used for signing but also what curves can get signed. > > > > Or are you saying that the NamedGroup would stay, and would now specify > > only the supported parameters for the key exchange, not how they are > > authenticated (as it is now)? > > > > Yes. Also, IIRC some have expressed that sometimes softare can sanely do ECDHE over some curve but not signature verification. Or it can sanely do signature verification but not ECDSA. > > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now > on, NamedGroup is only used for (EC)DH. > > > On Tuesday 19 January 2016 16:50:18 David Benjamin wrote: > > Why would it need to specify what [DH group's] DH share gets signed? > > NamedGroup still exists for the key exchange (see step 1). I'm only > > proposing pulling signature curves out of NamedGroup. > > > Or to put it other way: what extensions and with what values should I > > sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either > > P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA? > > > supported_groups {p256, p384} > supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512} > (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.) Of course, one wants at least semi-sane behaviour when downnegotiating... > [1] I have not been following the CFRG curve work very closely. Adam tells > me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion, > let's assume that's how it ends up. Actually, it isn't raw SHAKE256 but some weird prefixed variant... Fortunately only matters for TLS 1.2 client signatures, due to every- thing else being highly temporally localized. I do have should-be-final reference implementation and test vectors (and another implementation that is just slow and has the test vectors pass). Currently waiting on co-editor. -Ilari From nobody Tue Jan 19 11:43:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA4E1B34F9 for ; Tue, 19 Jan 2016 11:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 KVKo-i-w05bW for ; Tue, 19 Jan 2016 11:42:58 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 022C61B34F1 for ; Tue, 19 Jan 2016 11:42:58 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id h129so151277923lfh.3 for ; Tue, 19 Jan 2016 11:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QBAve0eZO0X4e6AynwU0hg73OG9uI88+Zkqf5wyRLJ4=; b=jbYBHvbpR0WZQSYG8eIXSNlx2J7yhBcafbW7VbeppEuSNNv98m63Cxu2z6LfS7VSqB 5s+zmXOAxXX5UJuKgxhp0KvDIPXSAgHKYVcl/B6uFRHwozX0RJimFAMT2qMGGqRS7IZ0 Lgc5S3vmDWIM7uvbSrVSCqYY19eDqMT4gHv/5DnYWTClImkm/4aYgnNVu2a8+Vg1Bq+7 KPpuUZ9ZRr1VYA62yTwqQnd+4gtcNHZ7m2qoBiGdsicC5yTa3M2JaB40dOl5dHE15GV1 9EHLuJziiuaMOh5eMDU4wZgfxSPYBSa1z9fXIDJg585V/Grh/TQ/Rpi12wJbISsA38Kz otCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QBAve0eZO0X4e6AynwU0hg73OG9uI88+Zkqf5wyRLJ4=; b=UYgNDn67u44gz6a8YW481qcUWV96NFu8Sljs1onoq5SVj557yWajfTFS43yh2cHvBj oq14oNwQgCOzWBeUF0wArJDzoKYnTyWVe6mnNs9slMff5vqQCa4Ue6FPLUKf6asiNs1c TNXPC5WhlJFA5CbVl+/0Gi3OrToc0Rzji7rY7pVW6a/YJHXNj7jeHJutHXxvQrMyBwcT VQLf00ZsPHIZ7ofK51e2uBsjR6WXT3AIsENSc5BHwOnAJADOlaXD0tR6vWsc21MnWTFf 3RHqOSxhFVDdRs5AhKivlayZtFgbqDAoXH+Vs6xDdULWJ6jSy1qaoacxuH6zgIxMSPrk F86Q== X-Gm-Message-State: ALoCoQklQTjGPq9zT3NAaNVDSgv5uMyQgpEvIxu/PryEt0RO/9NtmmMVjrKjffzziPKIrrEplZLOme1/v4ALyvDVj72AbHI8Tw== MIME-Version: 1.0 X-Received: by 10.25.5.205 with SMTP id 196mr11690077lff.143.1453232576139; Tue, 19 Jan 2016 11:42:56 -0800 (PST) Received: by 10.112.2.104 with HTTP; Tue, 19 Jan 2016 11:42:56 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Jan 2016 11:42:56 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113e9c167a2a700529b513f4 Archived-At: Subject: Re: [TLS] Early code point assignment for ChaCha20-poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 19:43:02 -0000 --001a113e9c167a2a700529b513f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We're asking the IESG for early allocation of these code points. =E2=80=8B --001a113e9c167a2a700529b513f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're asking the IESG for early allocation of these co= de points. =C2=A0=E2=80=8B
--001a113e9c167a2a700529b513f4-- From nobody Tue Jan 19 13:31:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31F71B334E for ; Mon, 18 Jan 2016 01:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 85mbsFZD1uVg for ; Mon, 18 Jan 2016 01:26:45 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048E11B334F for ; Mon, 18 Jan 2016 01:26:44 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id m198so168205742lfm.0 for ; Mon, 18 Jan 2016 01:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JB+k2g2cNDexGmajSy91JjwkgfWz74e9we/l5W4MTt0=; b=baiicqR39MN2auUx112wllvR2a5zBaJJqVjIWLIw1TYFDW6RqL+KadSnAF3kIvkY83 y9mm1kSjwX8Ih9oSyRgkJQWxV2PQELlKce3iX7jcCqkH2CRmn06KrAPtYQqSq9VppXSL tr/3rWRqIZ69ORnYNx7toToakTzxMZ5zcnM6NklF2oLPRcLMpk9LRrSBjYS6omEEXNSG cEZYCUgce8iDz+XuXhpfdMrw3AyE5yb+/97v/j1Np+5wN4W7NmoyCSXHmz/+8w5kSvS3 WB2xSR43XTtw14Fy4Voxiq6gpwEJZ8kmooEC26LiNiGkEgueYXV0/Fud9mQCIBM2KV/N HLyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=JB+k2g2cNDexGmajSy91JjwkgfWz74e9we/l5W4MTt0=; b=kF5fxthBOS1CbEi1lAuQm/8HQ9QB1xu8bg4Pq2KSdGD7sRtalxpFrrBYGBpXBs/Kk4 ZEfc4QlpCm9lX8rUroTN2oXvLKyLUe+5Q9rS6OaxX1SxxpGEzCtFlnEtlnXZEd2gnr6z 45YkgqNP9b1a1YgUFaBgQ5JajxHtVSOqRHpdY9WfwtfLPkgMcb9IGo9DhP63e58raexK vEttD8vor3FL845AU4L4gO+RJLrhNxuE4qwT7JPvIfxM4QTtRjxA6viGbTIHG6OybPwP qAWtC3qHNPtZcEWm+GRmQAsQDNg9eB0fTcOFYeuWx9GqDHol5v7hsTlV0LWZpSQ0Q0Tc 5Lrg== X-Gm-Message-State: ALoCoQn1jFz7ny7wMW2c5NU9J4Xeaj1iNQgOzYteIkFgIDEemB5/rxmpZaVcd2YzF8gFY2wz6f/aKTVSXbE5sQeR6Q6l23HQQg== X-Received: by 10.25.137.194 with SMTP id l185mr7986811lfd.41.1453109203064; Mon, 18 Jan 2016 01:26:43 -0800 (PST) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.12.132 with HTTP; Mon, 18 Jan 2016 01:26:03 -0800 (PST) In-Reply-To: <569BE33D.7050709@openfortress.nl> References: <20151130160212.90398180013@rfc-editor.org> <569BE33D.7050709@openfortress.nl> From: Nikos Mavrogiannopoulos Date: Mon, 18 Jan 2016 10:26:03 +0100 X-Google-Sender-Auth: oWE9F9roA3bK1zIeYhh_tV9LE3c Message-ID: To: Rick van Rein Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2016 13:31:04 -0800 Cc: dtaylor@gnutls.org, sean+ietf@sn3rd.com, Kathleen.Moriarty.ietf@gmail.com, "tls@ietf.org" , thomwu@cisco.com, RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5054 (4546) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2016 09:26:47 -0000 Hi, I find the reported errata reasonable. On Sun, Jan 17, 2016 at 7:53 PM, Rick van Rein wrote: > Hello, > > Could I bring this erratum reported in November to your attention once > more? I think it calls for correction. > > Thanks, > -Rick >> RFC Errata System >> 30 November 2015 at 17:02 >> The following errata report has been submitted for RFC5054, >> "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546 >> >> -------------------------------------- >> Type: Technical >> Reported by: Rick van Rein >> >> Section: 2.6 >> >> Original Text >> ------------- >> B = k*v + g^b % N >> >> Corrected Text >> -------------- >> B = ( k*v + g^b ) % N >> >> Notes >> ----- >> The customary binding is that + has lower priority than % and so the >> default reading of the expression would be >> B = k*v + ( g^b % N ) >> That is inconsistent with the existence of PAD(B) and the size of B in >> the test vectors, so the context hints at proper brackets, but this >> may still lead to implementation errors (of which I actually ran into >> an example). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5054 (draft-ietf-tls-srp-14) >> -------------------------------------- >> Title : Using the Secure Remote Password (SRP) Protocol for TLS >> Authentication >> Publication Date : November 2007 >> Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin >> Category : INFORMATIONAL >> Source : Transport Layer Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> From nobody Tue Jan 19 13:31:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB3F1B3080 for ; Sun, 17 Jan 2016 10:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLN9jNYvvgR for ; Sun, 17 Jan 2016 10:53:57 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA78A1B307F for ; Sun, 17 Jan 2016 10:53:56 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id 76tq1s00K10HQrX016trYx; Sun, 17 Jan 2016 19:53:54 +0100 Message-ID: <569BE33D.7050709@openfortress.nl> Date: Sun, 17 Jan 2016 19:53:49 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: RFC Errata System References: <20151130160212.90398180013@rfc-editor.org> In-Reply-To: <20151130160212.90398180013@rfc-editor.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2016 13:31:17 -0800 Cc: dtaylor@gnutls.org, sean+ietf@sn3rd.com, Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, nmav@gnutls.org, thomwu@cisco.com Subject: Re: [TLS] [Technical Errata Reported] RFC5054 (4546) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jan 2016 18:53:59 -0000 Hello, Could I bring this erratum reported in November to your attention once more? I think it calls for correction. Thanks, -Rick > RFC Errata System > 30 November 2015 at 17:02 > The following errata report has been submitted for RFC5054, > "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546 > > -------------------------------------- > Type: Technical > Reported by: Rick van Rein > > Section: 2.6 > > Original Text > ------------- > B = k*v + g^b % N > > Corrected Text > -------------- > B = ( k*v + g^b ) % N > > Notes > ----- > The customary binding is that + has lower priority than % and so the > default reading of the expression would be > B = k*v + ( g^b % N ) > That is inconsistent with the existence of PAD(B) and the size of B in > the test vectors, so the context hints at proper brackets, but this > may still lead to implementation errors (of which I actually ran into > an example). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5054 (draft-ietf-tls-srp-14) > -------------------------------------- > Title : Using the Secure Remote Password (SRP) Protocol for TLS > Authentication > Publication Date : November 2007 > Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > From nobody Tue Jan 19 14:09:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897021B36E2 for ; Tue, 19 Jan 2016 14:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 8njQv8m96UKd for ; Tue, 19 Jan 2016 14:08:55 -0800 (PST) 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 758FC1B36E1 for ; Tue, 19 Jan 2016 14:08:55 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id 1so419776ion.1 for ; Tue, 19 Jan 2016 14:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=r1+UBkCjdQvVtQ573IjKRt/i30ZvyRA0vrfsICDMRQE=; b=Bgh1+OkimOZnNPhMD5KK+d+ST2iAuOFw3wWW5mPEKkSYQ8cgFIWvadjVdd3tl/IyLB D2F83Bw5bBtJWUAMAZnZ8o4CEPorUSHp/om6sEHckXYTJxWejyUZ26f2pkTJ7MI5Uvqx T8Y5vCu/Qv/aiGGME2RR1pJqCLvABIjCV6jQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=r1+UBkCjdQvVtQ573IjKRt/i30ZvyRA0vrfsICDMRQE=; b=XOCWjZ4h/ys/VW/qL01vQ+xDMoCTFALGrX8AbBcyJZLth2dOzMXXmSv+ifyUHeebId rzdBOfpqeV+WF3O/2/H8PaJJWgnVA9XExOX9EC4oXbBG5yc4wfMcnkb8YFC4KN3V0ff7 UwKz1PGvmM3riviXHTNFJybVsRpx0H8rJMSDh1YBpBwgQqQAShvIi6ozdMuy4wiEwIXG fmSLntveVj/5BzBLA75Yl5bcJvP62t67MBqkOQDE+XhK5PA7a8lIt+AQnYrXqGauYHAm GMgjAHNKAwAMRd1bKtcKRMLks9y6wuYv19/1opA+RCNGRQDBdQA4vKYXstx26Qk+cwIq tntg== X-Gm-Message-State: ALoCoQmmGuFnYT48d/83FNVkA11m9Bt5Zfu42s+yjI5KPT1Hi+D64+dQw5Dx5W9Hiy7vkSb2AbSDjvr0BD8M2zuOAiL8LNMGKjLLFulLY9gxctl3gAspLZQ= X-Received: by 10.107.44.88 with SMTP id s85mr34767917ios.62.1453241334747; Tue, 19 Jan 2016 14:08:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 19 Jan 2016 22:08:45 +0000 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a113a033c8819320529b71d38 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 22:08:58 -0000 --001a113a033c8819320529b71d38 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote: > David Benjamin wrote: > >> (Whether such certificates exist on the web is probably answerable via CT >> logs, but I haven't checked.) >> > > Me neither, and I think that's the key thing that would need to be checked > to see if my suggestion is viable. > Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more often than not. https://crt.sh/?CN=%25&iCAID=1516 But it's not actually all that many hostnames (all of which presumably don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change, and whether sigalgs are stronger than a hint w.r.t. X.509 is... controversial. I wasn't able to find anyone else doing it. So +1 from me on dropping the 3x3 product to just the three you listed. I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_* allocations, but I can't think of any weird behaviors, so it seems reasonable. (The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and yet still speaking TLS 1.2 would have problems. But if we're actually limiting to those three, that can't happen anyway, and this hypothetical client seems pretty weird.) If other people still want to allow ecdsa_p384_sha256 and friends, I'm also happy with allocating 6 values and throwing out ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512. David --001a113a033c8819320529b71d38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 15= , 2016 at 10:13 PM Brian Smith <brian@briansmith.org> wrote:
David Benjamin <davidben@chromium.org> = wrote:
(Whether such certificates exist on the we= b is probably answerable via CT logs, but I haven't checked.)
=

Me neit= her, and I think that's the key thing that would need to be checked to = see if my suggestion is viable.
Looks like DigiCert's EC intermediates are P-384 = and they sign SHA-256 more often than not.
https://crt.sh/?CN=3D%25&iCA= ID=3D1516

But it's not actually all that many hostnames (all= of which presumably don't speak TLS 1.3 yet), the existing semantics o= f TLS 1.2 won't change, and whether sigalgs are stronger than a hint w.= r.t. X.509 is... controversial. I wasn't able to find anyone else doing= it. So +1 from me on dropping the 3x3 product to just the three you listed= .

I'm less confident about the consequences of reusing the TLS 1= .2 ecdsa_* allocations, but I can't think of any weird behaviors, so it= seems reasonable.

(The one thing I can think of is requires we keep= ecdsa_p384_sha256. Then a client wishing to advertise ecdsa_p384_sha256 an= d not ecdsa_p256_sha256 and yet still speaking TLS 1.2 would have problems.= But if we're actually limiting to those three, that can't happen a= nyway, and this hypothetical client seems pretty weird.)

If other pe= ople still want to allow=C2=A0ecdsa_p384_sha256 and friends, I'm also h= appy with allocating 6 values and throwing out ecdsa_p256_sha384,=C2=A0ecds= a_p256_sha512, and=C2=A0ecdsa_p384_sha512.

<= /div>
David
--001a113a033c8819320529b71d38-- From nobody Tue Jan 19 14:21:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9CC1B36F5 for ; Tue, 19 Jan 2016 14:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 HD8GhOza4SiC for ; Tue, 19 Jan 2016 14:21:05 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE311B36E1 for ; Tue, 19 Jan 2016 14:21:05 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id mw1so438455igb.1 for ; Tue, 19 Jan 2016 14:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=DHnwz6ju8q1oUHKG+m2KG1EDqDLbLmaNDIQviPpvZFw=; b=ePUBI0lJ4gj0G4n+LN6rO0mveLMwCPi1sL42EMngpBKnu9SkZW2U14SU/KonNSsu+3 KOKytguM5+afvhMiwQ7fxTxKWxu8jenWnOQN0SX1VzTRY+j3ns+PGx+xs+/8++0tLQ2k gJWW3GAJZoMReQWIT/aYCrERjwetZzxROf3uw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=DHnwz6ju8q1oUHKG+m2KG1EDqDLbLmaNDIQviPpvZFw=; b=RfGgHKRp56e0ziFSi+AeR0LBSFWDRJTftatB//2W/0An/rLv5RiVoREtrIw/mzyr1s 5M0T/Wv9YE84N++cAEs4o3u9lsDlY3xxEFgVVz5h6b1WvcdvQ44C/smqdyAl+WD6ufOe y1IOu+JJgrk2R5rDTWefVEyQz40P4vBNuVowCQiUDe3lw2ecHrXQvwvZRd3KaeXeyEB/ ZBEsu7c+veZ7Q33DFQ4vZd+eb8egV8pH3pJYPMZTUY0s7KHE+UEiujQCFS1nyFEinIv8 CbIvJ7DkCcxZteVuo8YvyoWj1Zd9657rBPpdHAsgBbuKZNl7+2XqKM+pr7SG4PKSmctS FmXQ== X-Gm-Message-State: AG10YOQPCAzNBOPoR3tRMVzyyw28Pw6iRmIn4WGAc1qtfcA1ncs6nNAuHyK2JeKay2GICwEo1MgSbDxMwyaM6BQi X-Received: by 10.50.171.200 with SMTP id aw8mr312526igc.77.1453242064681; Tue, 19 Jan 2016 14:21:04 -0800 (PST) MIME-Version: 1.0 References: <20160116110112.4af15baf@pc1> In-Reply-To: From: David Benjamin Date: Tue, 19 Jan 2016 22:20:55 +0000 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= , tls@ietf.org Content-Type: multipart/alternative; boundary=089e010d956209fd800529b749a0 Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2016 22:21:06 -0000 --089e010d956209fd800529b749a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, sent from the wrong address. On Tue, Jan 19, 2016 at 5:19 PM David Benjamin wrote: > On Sat, Jan 16, 2016 at 5:00 AM Hanno B=C3=B6ck wrote: > >> Hi, >> >> I generally like the idea of simplifying the different algorithm >> negotiation things, but: >> >> On Fri, 15 Jan 2016 20:45:34 +0000 >> David Benjamin wrote: >> >> > [2] >> > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note >> > this is wire-compatible with TLS 1.2. >> > - 0x0101 - rsa_pkcs1_md5 >> > - 0x0201 - rsa_pkcs1_sha1 >> > - 0x0301 - rsa_pkcs1_sha224 >> > - 0x0401 - rsa_pkcs1_sha256 >> > - 0x0501 - rsa_pkcs1_sha334 >> > - 0x0601 - rsa_pkcs1_sha512 >> > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. >> > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility >> > but ignored in TLS 1.3. >> >> I think a couple of them (esp. everything with dsa and _md5) should get >> a diediedie rfc and never be seen again. >> > > Sounds good. I included all the TLS 1.2 values thinking we'd want to > retroactively express TLS 1.2 (DSA, MD5, and SHA-1 warts and all) this wa= y > too. But leaving it alone is probably simpler. Reserving the range should > be sufficient to keep collisions out. > > If TLS 1.3 takes this proposal, I expect that I will make BoringSSL > implement TLS 1.2 this way (with whatever quirks are needed around ECDSA) > for convenience, but there's no reason this needs to be reflected in the > spec. > > >> > - rsapss_sha256 >> > - rsapss_sha384 >> > - rsapss_sha512 >> > - ecdsa_p256_sha256 >> > - ecdsa_p256_sha384 >> > - ecdsa_p256_sha512 >> > - ecdsa_p384_sha256 >> > - ecdsa_p384_sha384 >> > - ecdsa_p384_sha512 >> > - ecdsa_p521_sha256 >> > - ecdsa_p521_sha384 >> > - ecdsa_p521_sha512 >> > - eddsa_ed25519 >> > - eddsa_ed448 >> >> Do we really need that many? >> I think the "complexity zoo" of TLS is one of its current downsides and >> I really think we should go with fewer options in the future. Can we >> strip that down to - below 5 or something? (personal opinion: Strip >> down to 2, but this may be too radical for now.) >> > > Brian Smith proposed elsewhere in the thread to cutting the ECDSA ones > down to just > - ecdsa_p256_sha256 > - ecdsa_p384_sha384 > - ecdsa_p521_sha512 > and folding them into the TLS 1.2 compatibility ECDSA values, which I > think I am in favor of. I'm personally okay losing P-521 too since > BoringSSL doesn't advertise it, but I imagine others might object, so > *shrug*. > > That brings us down to 8. No strong opinions from me on whether we need > all three rsapss_* values. I just took what was in the 1.3 draft. > > > David > --089e010d956209fd800529b749a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, sent from the wrong address.

On Tue, Jan 19, 2016 at 5:19 PM David Benjamin= <davidben@google.com> wro= te:
On Sat, Jan 16, 2016 at 5:00 AM Hanno B=C3=B6= ck <hanno@hboeck.de= > wrote:
Hi,

I generally like the idea of simplifying the different algorithm
negotiation things, but:

On Fri, 15 Jan 2016 20:45:34 +0000
David Benjamin <davidben@chromium.org> wrote:

> [2]
> 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note<= br> > this is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
> - 0x0201 - rsa_pkcs1_sha1
> - 0x0301 - rsa_pkcs1_sha224
> - 0x0401 - rsa_pkcs1_sha256
> - 0x0501 - rsa_pkcs1_sha334
> - 0x0601 - rsa_pkcs1_sha512
> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility > but ignored in TLS 1.3.

I think a couple of them (esp. everything with dsa and _md5) should get
a diediedie rfc and never be seen again.

Sounds good. I included all = the TLS 1.2 values thinking we'd want to retroactively express TLS 1.2 = (DSA, MD5, and SHA-1 warts and all) this way too. But leaving it alone is p= robably simpler. Reserving the range should be sufficient to keep collision= s out.

If TLS 1.3 takes this proposal, I expect that I will make Bor= ingSSL implement TLS 1.2 this way (with whatever quirks are needed around E= CDSA) for convenience, but there's no reason this needs to be reflected= in the spec.
=
=C2=A0
> - rsapss_sha256
> - rsapss_sha384
> - rsapss_sha512
> - ecdsa_p256_sha256
> - ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha384
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448

Do we really need that many?
I think the "complexity zoo" of TLS is one of its current downsid= es and
I really think we should go with fewer options in the future. Can we
strip that down to - below 5 or something? (personal opinion: Strip
down to 2, but this may be too radical for now.)

Brian Smith proposed= elsewhere in the thread to cutting the ECDSA ones down to just
- e= cdsa_p256_sha256
- ecdsa_p384_sha384
- ecdsa_p521_s= ha512
and folding them into the TLS 1.2 compatibility ECDSA values, whic= h I think I am in favor of. I'm personally okay losing P-521 too since = BoringSSL doesn't advertise it, but I imagine others might object, so *= shrug*.

That brings us down to 8. No strong opinions from me on whet= her we need all three rsapss_* values. I just took what was in the 1.3 draf= t.
=


David
--089e010d956209fd800529b749a0-- From nobody Wed Jan 20 03:50:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E451B3AA0 for ; Wed, 20 Jan 2016 03:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P70dAgjY_rA for ; Wed, 20 Jan 2016 03:50:41 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 606B21B3A9B for ; Wed, 20 Jan 2016 03:50:40 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 5D22DA8A136E; Wed, 20 Jan 2016 11:50:38 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 29E1C1FE0575; Wed, 20 Jan 2016 12:50:38 +0100 (CET) Date: Wed, 20 Jan 2016 12:50:38 +0100 From: Kurt Roeckx To: David Benjamin Message-ID: <20160120115037.GA28992@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jan 2016 11:50:45 -0000 On Tue, Jan 19, 2016 at 10:08:45PM +0000, David Benjamin wrote: > On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote: > > > David Benjamin wrote: > > > >> (Whether such certificates exist on the web is probably answerable via CT > >> logs, but I haven't checked.) > >> > > > > Me neither, and I think that's the key thing that would need to be checked > > to see if my suggestion is viable. > > > > Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more > often than not. > https://crt.sh/?CN=%25&iCAID=1516 This is my current count of ECDSA based signatures: ECDSA_SHA256 | 1970793 ECDSA_SHA384 | 53 (That's all valid certificate I know about, most of those have expired.) Kurt From nobody Wed Jan 20 10:47:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FD1ACD09 for ; Wed, 20 Jan 2016 10:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.302 X-Spam-Level: X-Spam-Status: No, score=-16.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ad7Ln1ssjhh for ; Wed, 20 Jan 2016 10:47:15 -0800 (PST) Received: from den-ipout-02-data1.paypalcorp.com (den-ipout-02-data1.paypalcorp.com [173.224.160.155]) (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 BDEF11ACD0F for ; Wed, 20 Jan 2016 10:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1453315635; x=1484851635; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5SrB2USQih9NDYBYMLHZ7zQmvWhc5+w7KJOCjYwrI/8=; b=nn8LxqTnctsYGw2zNsMo0BkzbkCF3Y3Bmv4HK2BN1VQNUNgi32YnyYnL J3yGSA2SR2P9pDUEdaQO9T/LNsNZ8WPSzxEmlxRFH0PnzosepHQkMNBXx WJ4lImTQRoqlHSFkM2LeBGhV7uBiNY77KDllrmi6kTQaeSC3aAbWC6gGv H5nkY5z1LGqq3HN09ugKjJ1XhyupMly/jouQFE2lwiKsguSQWotboFmh3 9x/hX6Jbk7WVoaLO5fiNQOkWKqJe4m8INKuGzU/TWWaPEeCnpnMNkTqgn H9UNbz1EE8TBDphso3cLJioPR3fekZbjoPMZE4XQO24bo/TcnfPDCOL5p g==; X-IronPort-AV: E=Sophos;i="5.22,322,1449558000"; d="scan'208";a="9025647" Received: from unknown (HELO den-ipcld-02-data1.paypalcorp.com) ([10.184.246.164]) by den-ipout-02-data1.paypalcorp.com with ESMTP; 20 Jan 2016 11:47:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,322,1449558000"; d="scan'208";a="4583638" X-CloudService: Office365 Received: from mail-bn1lp0142.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) ([207.46.163.142]) by den-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 20 Jan 2016 11:47:14 -0700 Received: from CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) by CO2PR06MB460.namprd06.prod.outlook.com (10.141.196.154) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 20 Jan 2016 18:47:12 +0000 Received: from CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) by CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) with mapi id 15.01.0361.006; Wed, 20 Jan 2016 18:47:12 +0000 From: "Hodges, Jeff" To: Benjamin Kaduk , Jong-Shian Wu , "tls@ietf.org" Thread-Topic: [TLS] Length of a variable-length vector: Could it be an odd multiple? Thread-Index: AQHRTkR4epX27goF9EGhvHqqCgIza58EQ2wA Date: Wed, 20 Jan 2016 18:47:12 +0000 Message-ID: References: <5696B946.3050405@akamai.com> In-Reply-To: <5696B946.3050405@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [73.202.80.238] x-microsoft-exchange-diagnostics: 1; CO2PR06MB460; 5:F3qnKALuSDcLAE6loCd6jNvenaOWH5k4mfaxMcWEWTts3N/LmuEdjzSssfMhR/tTMRNAZcCMtpVd5po0W8uuRrPHYkVd91pn/jvgPsI6sQwl7FRdtpjER5gzvV0reAbQmGk4qxhp33b3R7SccPRRDw==; 24:J8dTLmkUqt3E4sUSLVOF8ZdxR0P226z9b4ClnAG0YGWwwPSh7M2xgb1e++7x10NW6Jcaep47zbFcRChC0Ooz1CTCqk1VLKUr2DryqmGbGRU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR06MB460; x-ms-office365-filtering-correlation-id: 6e410789-9877-44ef-6ef6-08d321ca1c32 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CO2PR06MB460; BCL:0; PCL:0; RULEID:; SRVR:CO2PR06MB460; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(199003)(189002)(10400500002)(10130500003)(5002640100001)(10290500002)(101416001)(5004730100002)(10300500001)(189998001)(86362001)(77072002)(66066001)(5001770100001)(87936001)(97736004)(81156007)(54356999)(76176999)(5001960100002)(107886002)(50986999)(99286002)(92566002)(19580405001)(19580395003)(105586002)(2501003)(2950100001)(2900100001)(106116001)(77096005)(102836003)(106356001)(6116002)(3846002)(36756003)(10770500003)(5008740100001)(73692002)(11100500001)(1220700001)(40100003)(4500500003)(1096002)(82432001)(10630500004)(122556002)(586003)(2906002)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR06MB460; H:CO2PR06MB457.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4DF77D3825CB7449B51FC9B80B228F11@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 18:47:12.7830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR06MB460 X-CFilter: Scanned den1 Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jan 2016 18:47:17 -0000 On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: >On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: >> I have a question about the even-vs-odd restrictions on the length of >> a valid variable-length vector defined in TLS specification after >> reading the section 4.3 of RFC 5246 [1] which states that: >>"The length of an encoded vector must be an even multiple of the length >>of a single element (for example, a 17-byte vector of uint16 would be >> illegal)." >> > >It means "whole-number" as opposed to fractional, i.e., there should not >be unused "junk bytes" at the end. In case it's helpful, here's a suggested re-write of that quoted sentence above.. The length of an encoded variable-length vector must be an exact multiple of the length of a single element. For example, an encoded 17-byte vector of uint16 would be illegal, and an encoded variable-length vector of four 32 byte elements, having a ceiling of 2^16-1, will be 130 bytes long overall (2 byte length field followed by 128 bytes of data). ..assuming I'm correctly understanding variable-length vectors :) HTH, =3DJeffH From nobody Wed Jan 20 11:02:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D875B1ACD22 for ; Wed, 20 Jan 2016 11:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq5FigOjBBsb for ; Wed, 20 Jan 2016 11:01:58 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B3FD61ACD39 for ; Wed, 20 Jan 2016 11:01:58 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 73E8B433434; Wed, 20 Jan 2016 19:01:57 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5DA8143340B; Wed, 20 Jan 2016 19:01:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453316517; bh=+oYy5Elv6Lgv3QiqeKdPAbh+1JCeR/o2eVh//1dSAgU=; l=1303; h=To:References:From:Date:In-Reply-To:From; b=uzseFoNDyBP3rnBkbmiXp8188ypAMtQxJ2PHtA8r/oiI5Dx3ja2XCmXGvPH1Pcdl6 fEqH3YobaqktyEmMy5X4/h0Gisk3RZWXFGTQyaV2tV3/6vuYMpZowq0zjrvXBhlR+p Fj9u7EJu5rUuxeOmslbFJzG7tSObUE1SNaJOWms0= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1D5872026; Wed, 20 Jan 2016 19:01:57 +0000 (GMT) To: "Hodges, Jeff" , Jong-Shian Wu , "tls@ietf.org" References: <5696B946.3050405@akamai.com> From: Benjamin Kaduk Message-ID: <569FD9A4.4030600@akamai.com> Date: Wed, 20 Jan 2016 13:01:56 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jan 2016 19:02:01 -0000 On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: >> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: >>> I have a question about the even-vs-odd restrictions on the length of >>> a valid variable-length vector defined in TLS specification after >>> reading the section 4.3 of RFC 5246 [1] which states that: >>> "The length of an encoded vector must be an even multiple of the length >>> of a single element (for example, a 17-byte vector of uint16 would be >>> illegal)." >>> >> It means "whole-number" as opposed to fractional, i.e., there should not >> be unused "junk bytes" at the end. > In case it's helpful, here's a suggested re-write of that quoted sentence > above.. > > The length of an encoded variable-length vector must be an > exact multiple of the length of a single element. For example, > an encoded 17-byte vector of uint16 would be illegal, and an > encoded variable-length vector of four 32 byte elements, > having a ceiling of 2^16-1, will be 130 bytes long overall > (2 byte length field followed by 128 bytes of data). Wouldn't the ceiling more properly be 2^16-4 in that case? -Ben > ..assuming I'm correctly understanding variable-length vectors :) > > HTH, > > =JeffH > > > > > From nobody Wed Jan 20 11:20:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366421ACD8B for ; Wed, 20 Jan 2016 11:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.201 X-Spam-Level: X-Spam-Status: No, score=-18.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuaUMNgm9mf8 for ; Wed, 20 Jan 2016 11:20:56 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (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 F08151ACD84 for ; Wed, 20 Jan 2016 11:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1453317655; x=1484853655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hawXd98pPENIXHhY7c0Wpljg7lOpVcgWbby9x9aA6aM=; b=e4fR5LVxgTAiePfkC1+k5hBgMFFiulvNwZQe9xUKGgakzLeimmTdGrSx RxYsB2V66QN+z1dIhTQ96PUsstDLFZnHj13o8NSkcrsDQ09rvKMGkZstL TJEd3pyHcE/7wsWuh9LdHb1CxJ553vPRRO9aVyEnV0o8xVppc0YQX3nPA 8/q7RtgphSH6AE557lYF7lGXr/8INfTZs6pveKy+Yj1aNTgae8wIXn/Eu 6rLg8DAEyzVye4hS2ai/IE8X48b7mE8s61YDNkmF94307MxiV/TCbMQ2B 6GYC8Q+TNVKzKlT0EM8YX5FpcdqM0jblvOb8RzIOEkIq08gBTOvyutNVj w==; X-IronPort-AV: E=Sophos;i="5.22,322,1449558000"; d="scan'208";a="9009668" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.184.246.167]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 20 Jan 2016 12:20:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,322,1449561600"; d="scan'208";a="3176854" X-CloudService: Office365 Received: from mail-bn1blp0190.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) ([207.46.163.190]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 20 Jan 2016 11:20:54 -0800 Received: from BY2PR06MB454.namprd06.prod.outlook.com (10.141.220.144) by BY2PR06MB454.namprd06.prod.outlook.com (10.141.220.144) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 19:20:52 +0000 Received: from BY2PR06MB454.namprd06.prod.outlook.com ([10.141.220.144]) by BY2PR06MB454.namprd06.prod.outlook.com ([10.141.220.144]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 19:20:52 +0000 From: "Hodges, Jeff" To: Benjamin Kaduk Thread-Topic: [TLS] Length of a variable-length vector: Could it be an odd multiple? Thread-Index: AQHRTkR4epX27goF9EGhvHqqCgIza58EQ2wAgACKGwD//39KAA== Date: Wed, 20 Jan 2016 19:20:51 +0000 Message-ID: References: <5696B946.3050405@akamai.com> <569FD9A4.4030600@akamai.com> In-Reply-To: <569FD9A4.4030600@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [73.202.80.238] x-microsoft-exchange-diagnostics: 1; BY2PR06MB454; 5:P5F/iblN5PAxk0PLdmy3ZCt1/WbQTkkyNAtVt5F67QOMC76zd5ZJw9tr+sEQQfR3jzYQRoJ7ILK0G3L+BAid9Vw6GaG071asklMKR2t/MPp370lvlNXUcBhgDlGDNUthDf63USd2ok/3Q3uc+neHoA==; 24:vSxZcfoXn09lxlV939pVt+BUyMNsbbSnfdGi1md2Um8phqLHlMM7ayz5t9J22wmwZe8z5bA6h+2+NG4sbrpY8eUBGVpkrMEhBHk7Y2RruFE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB454; x-ms-office365-filtering-correlation-id: 9c3a02bf-5da0-4067-cdd8-08d321cecfe3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2PR06MB454; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB454; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(377454003)(479174004)(76176999)(2906002)(10130500003)(99286002)(101416001)(106116001)(54356999)(106356001)(50986999)(5004730100002)(19580395003)(10630500004)(73692002)(82432001)(11100500001)(19580405001)(86362001)(93886004)(10400500002)(77072002)(10290500002)(10300500001)(36756003)(105586002)(10770500003)(3846002)(66066001)(5008740100001)(6116002)(102836003)(4326007)(1096002)(87936001)(1220700001)(122556002)(40100003)(5002640100001)(110136002)(2900100001)(2950100001)(77096005)(92566002)(4500500003)(189998001)(97736004)(5001960100002)(586003)(81156007)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR06MB454; H:BY2PR06MB454.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4AD4988D3F3A9F4F8716A6C42CC29C8F@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 19:20:51.4477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB454 X-CFilter: Scanned den1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jan 2016 19:20:57 -0000 On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: >>>> I have a question about the even-vs-odd restrictions on the length of >>>> a valid variable-length vector defined in TLS specification after >>>> reading the section 4.3 of RFC 5246 [1] which states that: >>>> "The length of an encoded vector must be an even multiple of the >>>>length >>>> of a single element (for example, a 17-byte vector of uint16 would be >>>> illegal)." >>>> >>> It means "whole-number" as opposed to fractional, i.e., there should >>>not >>> be unused "junk bytes" at the end. >> In case it's helpful, here's a suggested re-write of that quoted >>sentence >> above.. >> >> The length of an encoded variable-length vector must be an >> exact multiple of the length of a single element. For example, >> an encoded 17-byte vector of uint16 would be illegal, and an >> encoded variable-length vector of four 32 byte elements, >> having a ceiling of 2^16-1, will be 130 bytes long overall >> (2 byte length field followed by 128 bytes of data). > >Wouldn't the ceiling more properly be 2^16-4 in that case? hm, I'm not sure -- what would be the rationale? The exact multiple criteria? but 2^16 / 32 =3D 2048 i do have further questions regarding variable-length vectors, and how they are specified, that subsequent discussion will hopefully tease out. thanks,=20 =3DJeffH From nobody Thu Jan 21 06:40:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC761A8893 for ; Thu, 21 Jan 2016 06:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAosEOkHrcPG for ; Thu, 21 Jan 2016 06:40:43 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ED01A888C for ; Thu, 21 Jan 2016 06:40:43 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id s68so16424223qkh.3 for ; Thu, 21 Jan 2016 06:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=g2Ky9knyP55p9oSJVk81hw+ze/wN3rFX1YAREu1QLo0=; b=Tg3zMwsFnFjY6dFBcKOJ3CBRmOzughfMbRq4oDI0XdPaNA8SBntLW3DKHctIzKrheZ MqLObPAJdMSYyjRVr+OEpXOY5Oqf/QXAFSc0CBrkowCJ6psyGBRvmLBhZVXC4fssiZrF HYSWc8ljTJyVOHI0NVSjQwdDdtbEjhl4KgkF8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=g2Ky9knyP55p9oSJVk81hw+ze/wN3rFX1YAREu1QLo0=; b=Yz7DLYyeUUYfohJPMhociFXOdkeAvv0LNTSZJa01hOP557fb6L7hYYcLWEL7xX3eXa z9MAi8vViVHFIsKJ57cHS61SZlRqCHMtIun7umHhtur8pcFAYu0sPBMDhBtzJF9MO47B +aZXRz4vXk+XyNFNl8E2h15NAqnJtNxxQi2lDrseBRFuG+rMD9+7EZLKRw6WUNXKtALd uvYGTpsyZUsAJwd9PlsDBrGs9h9cI53WE1qczKy3/gvBTwSNH6ZUikEHjrsGI+R1Augx BkDfGjgv+6N6C2PIUKdRhax1qd1L7Nw+XIgL37n+RrOisVMiS4EjYm2dBpKMKFJC+GHp 41jQ== X-Gm-Message-State: ALoCoQkFjU2w4+00GTQxr6COHzIjkNQyZ8WCPOI8Nhi73xcC/mOvZYK2SUHry81DFAU4N4axQf0XBz4MiyidKv9WA91jFpC9VA== X-Received: by 10.55.207.217 with SMTP id v86mr52438495qkl.16.1453387242795; Thu, 21 Jan 2016 06:40:42 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id v65sm626160qhc.46.2016.01.21.06.40.42 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:40:42 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 21 Jan 2016 09:40:41 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jan 2016 14:40:45 -0000 All, This is the working group last call for the "False Start" draft = available at http://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/. = Please review the document and send your comments to the list by 5 = February 2016. =20 Thanks, J&S= From nobody Thu Jan 21 18:25:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BCB1B3657 for ; Thu, 21 Jan 2016 18:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLNc9jcxE0Rd for ; Thu, 21 Jan 2016 18:25:02 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798971B3655 for ; Thu, 21 Jan 2016 18:25:02 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-02v.sys.comcast.net with comcast id 8qQJ1s0044vw8ds01qR1nZ; Fri, 22 Jan 2016 02:25:01 +0000 Received: from [IPv6:::1] ([73.170.34.26]) by resomta-po-04v.sys.comcast.net with comcast id 8qR01s00S0ZpzqZ01qR18Z; Fri, 22 Jan 2016 02:25:01 +0000 Message-ID: <56A192FC.4060206@brainhub.org> Date: Thu, 21 Jan 2016 18:25:00 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453429501; bh=wxzNtsJQmpL5FlcQ42UFegeslRyjURfQecpDm9aD33U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ufZLsx8ecxRvKBh4qCrC+9PUvsiR+B3YG9NX0RAawNwoh1uS4UC+5MdNT4ykwQaA8 yDiqemWN92tENF3DnhIDE9dT/BcllskEHOGnIO1vV2P1Ud0JUWOuxeHJYd/RNW025X HdUYcNx4LIxCz0RrD6hEEjJhyMmPwlK1aK9N8RBrfKzcJ+uTX6LdMKsVPR1QEA/OpR FddCpdu7x/qLgiFO4C1JnuV8p3Ej6jIuEInCWsOX+7wZYy/juuja2e5BnupLuIMu2V 0+kyttFefoomcI5AcVuO8lscXI445pA82mzSp5o5GR2o62grl0JvZ3dgqdHnl9SMpF UrOsD2U/w5xew== Archived-At: Subject: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 02:25:05 -0000 Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the following language in sec 4.8.1 > In RSA signing, the opaque vector contains the signature generated > using the RSASSA-PSS signature scheme defined in [RFC3447 ] with MGF1. > The digest used in the mask generation function MUST be the same as > the digest which is being signed (i.e., what appears in > algorithm.signature). The length of the salt MUST be equal to the > length of the digest output. Note that previous versions of TLS used > RSASSA-PKCS1-v1_5, not RSASSA-PSS. The > struct { > SignatureAndHashAlgorithm algorithm; > opaque signature<0..2^16-1>; > } DigitallySigned; defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec A.3.1.1: > enum { > rsa(1), > dsa(2), > ecdsa(3), > rsapss(4), > eddsa(5), > (255) > } SignatureAlgorithm; since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates only. Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as frictionless as possible regarding the upgrade of existing TLS installations to TLS 1.3. We should expect that all TLS 1.3 servers and clients will have support for older versions of TLS on the same node. Ideally, it should be possible to upgrade the software / firmware to add TLS 1.3 support on existing hardware with minimal penalty. Unfortunately, the product I work on, which is responsible for ~15% of Internet traffic, is not compatible with the "frictionless idea" due to the current TLS 1.3 spec [1] mandating PSS in the handshake. The issue here is that these already sold products use 3d party components that can only perform RSA signing with CRT optimization when the padding is PKCS1 1.5. In the best case this means ~2x performance penalty for TLS 1.3. In the worst case the existing server keys cannot do PSS signature if the keys are on FIPS-certified devices. The same issue applies to client TLS authentication with smartcards. Many smartcards cannot do PSS, e.g. [3]. Likewise, it's unclear if PSS is supported by e.g. PKCS#11 libraries of HSM vendors, or the HSM hardware. Other products on the Internet use the same components, so that 15% is a minimum I know of. The current list of FIPS 140 products that support RSA shows twice as many products that support RSASSA-PKCS1_V1_5 than these that support RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS certification with TLS 1.3, factoring client auth and servers. Can support for PSS be added by 3d party vendors? If the limitation is in middleware like PKCS#11 or in firmware/microcode, this is technically possible. This does require an update and the brings version dependency. Further, if the firmware is FIPS 140-2 certified, this type of upgrade will have re-certification cost (more friction). In some cases this is a physical limitation. For example, I know from my experience working on smartcard decryption a few years back that the chips themselves insist on PKCS#1.5 padding for half of the vendors we supported and won't e.g. accept raw or OAEP padding with RSA, e.g. [2]. It is apparent from the specs that [3] does support PSS while [2] doesn't. I prepared the slides on this subject for Yokohama [5]. I believe Eric Rescorla presented these. How much do the members of the WG value the idea of lower hurdles to the deployment of TLS 1.3? Is there desire to add a PKCS#1 1.5 signature fallback, just like there is one already for X.509 certificates in TLS 1.3? The only solution that's available at this point is conditioning TLS 1.3 support on appropriate hardware. For this reason TLS 1.3 it probably won't be enabled by default in the product I work on. I would prefer for TLS 1.3 to be enabled by default and write the code to decide whether it does PSS or falls back to RSA PKCS1 1.5. Thank you. [1] http://tools.ietf.org/html/draft-ietf-tls-tls13-11.html [2] 4.4 has no PSS: http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf [3] 5.0 has PSS: https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf [4] 2x more legacy than PSS: http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html wget http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html $ grep RSASSA-PSS rsanewval.html | wc -l 593 $ grep RSASSA-PKCS1_V1_5 rsanewval.html | wc -l 2005 $ grep RSASSA rsanewval.html | wc -l 2607 [5] https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf https://www.ietf.org/jabber/logs/tls/2015-11-04.html From nobody Fri Jan 22 03:22:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7B21A044E for ; Fri, 22 Jan 2016 03:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UNBKR0t0UGK for ; Fri, 22 Jan 2016 03:22:46 -0800 (PST) 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 4737E1A0439 for ; Fri, 22 Jan 2016 03:22:46 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 24F965375; Fri, 22 Jan 2016 11:14:10 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0MBE9kJ016714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 06:14:10 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 22 Jan 2016 12:14:04 +0100 Message-ID: <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <56A192FC.4060206@brainhub.org> References: <56A192FC.4060206@brainhub.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2014552.nqi3SfhAKr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 11:22:48 -0000 --nextPart2014552.nqi3SfhAKr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote: > Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the= > following language in sec 4.8.1 >=20 > > In RSA signing, the opaque vector contains the signature > > generated > > using the RSASSA-PSS signature scheme defined in [RFC3447=20 > > ] with MGF1. The digest > > used in the mask generation function MUST be the same as the > > digest which is being signed (i.e., what appears in > > algorithm.signature). The length of the salt MUST be equal to > > the > > length of the digest output. Note that previous versions of TL= S > > used > > RSASSA-PKCS1-v1_5, not RSASSA-PSS. >=20 > The >=20 > > struct { > > =20 > > SignatureAndHashAlgorithm algorithm; > > opaque signature<0..2^16-1>; > > =20 > > } DigitallySigned; >=20 > defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec=20 A.3.1.1: > > enum { > > =20 > > rsa(1), > > dsa(2), > > ecdsa(3), > > rsapss(4), > > eddsa(5), > > (255) > > =20 > > } SignatureAlgorithm; >=20 > since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificate= s > only. >=20 >=20 > Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be a= s > frictionless as possible regarding the upgrade of existing TLS > installations to TLS 1.3. We should expect that all TLS 1.3 servers > and clients will have support for older versions of TLS on the same > node. Ideally, it should be possible to upgrade the software / > firmware to add TLS 1.3 support on existing hardware with minimal > penalty. The transition to TLS 1.3 is not urgent matter. Making sure that it is=20= as robust as possible is of higher importance than "making it easy to=20= implement for existing TLS1.2 implementations". That's right there in the charter: https://datatracker.ietf.org/wg/tls/charter/ > The current list of FIPS 140 products that support RSA shows twice as= > many products that support RSASSA-PKCS1_V1_5 than these that support > RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS > certification with TLS 1.3, factoring client auth and servers. You also need a FIPS certified implementation of HKDF. So yes, it most=20= likely will require new certifications. > The only solution that's available at this point is conditioning TLS > 1.3 support on appropriate hardware. For this reason TLS 1.3 it > probably won't be enabled by default in the product I work on. I > would prefer for TLS 1.3 to be enabled by default and write the code > to decide whether it does PSS or falls back to RSA PKCS1 1.5. Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting=20= it off now would be negligent. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2014552.nqi3SfhAKr 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 iQIcBAABCgAGBQJWog78AAoJEJKo0bgB0vX17V4P/0B3uGv8z3aYezDaC8h8ANAi a9AZa0PSUX/VyBGNgLRAZ5DxvdLnOuFjy3ASXQH4BVTu1MZ/2z3K7SikGI4qUIon xbdFQmdDXjWVgWOgjwcmjULw08uGoMD/U0HvQwTKTF7r5Wjrb9uDLzOuLkb+8VIF 5Yu9G+G81BKwCuoAEg+PhgUdAFZ/A/rAvDquOrbHYaHkMGe5zev0EwOkjUkh/plg mbVAdA9cjsNO6rQ3Iq1rNCmLjx++jtJNoUJfh/HGBoSFfLUAOgfQEwTiGrve1QhL RK9F9csreN69Hh61BtUqc0K2gzLM8KDkwCfas7zxS8gZx06N6xiOmUJCYmGFOpZT I927v8sRMBIU3Rpg+vxYs0+T8HPFZnao2Mrcks4k5UrnC7n2DSIQZRVMcTYbxtyX GRmDc8XiAm4GsyLK4/Czc/QARf7dieW4EUxX/2+qOB+ZxBgHV1S+asUm8TEI+twN TO7ZzPVpNOfQjzc/QflLI3qxEYBpoqu6409GevEjk69gnq1KVhYfkW4s0DLUSvwt ftcSr6mrQuq1mkCuxccNs6B5NimedY17k2dWwyFZ4w+ZzfDm+LXwu33rhgSSySEl vpCMiyXARxqGryj0kMsx1sq1Ft3444TVLLZp31nobwPIyx8N7cGPNTBAQSqT0R8G 0BrpAEkQoimt/eDErAMO =tYAu -----END PGP SIGNATURE----- --nextPart2014552.nqi3SfhAKr-- From nobody Fri Jan 22 07:43:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4AB1AD0A2 for ; Fri, 22 Jan 2016 07:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 moh8RI1oV4Xi for ; Fri, 22 Jan 2016 07:43:17 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id DF92D1AD0A1 for ; Fri, 22 Jan 2016 07:43:16 -0800 (PST) Received: (qmail 20364 invoked by uid 0); 22 Jan 2016 15:43:14 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jan 2016 15:43:14 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id 93iv1s00P2UhLwi013iytw; Fri, 22 Jan 2016 08:43:03 -0700 X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7aQ_Q-yQQ-AA:10 a=X7Ea-ya5AAAA:8 a=paVEJOsxBLH6RyIUqZMA:9 a=iWQmlnfbr4Ll8exz:21 a=XvRITpJk_HXMbRZi:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:To:Subject:From; bh=vFSzfutn9MK16EU18ktZKdH20zI6ald2DqdQHrnlS6Q=; b=vqWEUHtCjt8BCXUcLs2xmjFYVmAAjH/mdqxwc7jlNi/OF6VpIZX+bvxTpnivGjOWD3IKcIxmto1xBSa9jPfyO2DK1W/seldVbhCXBejaMoi46gq4abyqia36bLvB4t5F; Received: from [73.202.80.238] (port=45911 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aMdrV-0006dp-1n for tls@ietf.org; Fri, 22 Jan 2016 08:42:57 -0700 From: =JeffH To: IETF TLS WG Message-ID: <56A24DFC.8050702@KingsMountain.com> Date: Fri, 22 Jan 2016 07:42:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 15:43:18 -0000 [ resending from different account - my work addr ends up in spam bucket for many it seems ] On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: >>>> I have a question about the even-vs-odd restrictions on the length of >>>> a valid variable-length vector defined in TLS specification after >>>> reading the section 4.3 of RFC 5246 [1] which states that: >>>> "The length of an encoded vector must be an even multiple of the >>>>length >>>> of a single element (for example, a 17-byte vector of uint16 would be >>>> illegal)." >>>> >>> It means "whole-number" as opposed to fractional, i.e., there should >>>not >>> be unused "junk bytes" at the end. >> In case it's helpful, here's a suggested re-write of that quoted >>sentence >> above.. >> >> The length of an encoded variable-length vector must be an >> exact multiple of the length of a single element. For example, >> an encoded 17-byte vector of uint16 would be illegal, and an >> encoded variable-length vector of four 32 byte elements, >> having a ceiling of 2^16-1, will be 130 bytes long overall >> (2 byte length field followed by 128 bytes of data). > >Wouldn't the ceiling more properly be 2^16-4 in that case? hm, I'm not sure -- what would be the rationale? The exact multiple criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 i do have further questions regarding variable-length vectors, and how they are specified, that subsequent discussion will hopefully tease out. thanks, =JeffH From nobody Fri Jan 22 07:50:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669A61AD0AC for ; Fri, 22 Jan 2016 07:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe4az72odGfn for ; Fri, 22 Jan 2016 07:50:17 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id D36CC1AD0AA for ; Fri, 22 Jan 2016 07:50:16 -0800 (PST) Received: (qmail 8510 invoked by uid 0); 22 Jan 2016 15:50:12 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 22 Jan 2016 15:50:12 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id 93q51s00b2UhLwi013q8fk; Fri, 22 Jan 2016 08:50:11 -0700 X-Authority-Analysis: v=2.1 cv=Zc6OaKlA c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7aQ_Q-yQQ-AA:10 a=48vgC7mUAAAA:8 a=IIwlgDjPnG-Nzxkb1DsA:9 a=6iJWCEDO728CXKkD:21 a=WYTrF23hDb3UX3Ed:21 a=QEXdDO2ut3YA:10 a=5VhdjycbbNEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=fjMUwEYKJqXm1SsmgngJFl1u6AUEm4NjURvyZ9oHbLY=; b=iXDm0h7TMWjJcb+s6u6+3yupZ9hkSi3UUgRS4/P4mVmMOl3bFvsDdtknPuZeFCbTO68oitUDbVbPx8BAvTwAwI3qRUWTeSJuzGZ7K+wkmObHvy+VTTZDykG8W+KREItE; Received: from [73.202.80.238] (port=45997 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aMdyQ-0004P1-Br for tls@ietf.org; Fri, 22 Jan 2016 08:50:06 -0700 To: IETF TLS WG From: =JeffH Message-ID: <56A24FAA.6050409@KingsMountain.com> Date: Fri, 22 Jan 2016 07:50:02 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [TLS] Length of a variable-length vector: zero-length case X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 15:50:19 -0000 wrt https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3 if we have.. opaque foo<0..2^16-1>; ..with a floor length of zero, thus with an instantiation of foo of zero length, we actually will have in terms of encoded bytes on the wire (in hex).. 00 00 ..where this is the 2-byte length field, with length value zero, and a zero-length (ie, absent, empty) vector content, correct ? thanks, =JeffH From nobody Fri Jan 22 08:22:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9201AD36B for ; Fri, 22 Jan 2016 08:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QT4wZZq1WFH for ; Fri, 22 Jan 2016 08:22:49 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7861AD369 for ; Fri, 22 Jan 2016 08:22:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7D5B327EE; Fri, 22 Jan 2016 18:22:47 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Pl1VyjbsBPMS; Fri, 22 Jan 2016 18:22:47 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 11AD1231; Fri, 22 Jan 2016 18:22:47 +0200 (EET) Date: Fri, 22 Jan 2016 18:22:42 +0200 From: Ilari Liusvaara To: "Hodges, Jeff" Message-ID: <20160122162242.GA22338@LK-Perkele-V2.elisa-laajakaista.fi> References: <5696B946.3050405@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Jong-Shian Wu , "tls@ietf.org" Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 16:22:52 -0000 On Wed, Jan 20, 2016 at 06:47:12PM +0000, Hodges, Jeff wrote: > On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > >On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > >> I have a question about the even-vs-odd restrictions on the length of > >> a valid variable-length vector defined in TLS specification after > >> reading the section 4.3 of RFC 5246 [1] which states that: > > >>"The length of an encoded vector must be an even multiple of the length > >>of a single element (for example, a 17-byte vector of uint16 would be > >> illegal)." > >> > > > >It means "whole-number" as opposed to fractional, i.e., there should not > >be unused "junk bytes" at the end. > > In case it's helpful, here's a suggested re-write of that quoted sentence > above.. > > The length of an encoded variable-length vector must be an > exact multiple of the length of a single element. For example, > an encoded 17-byte vector of uint16 would be illegal, and an > encoded variable-length vector of four 32 byte elements, > having a ceiling of 2^16-1, will be 130 bytes long overall > (2 byte length field followed by 128 bytes of data). > > ..assuming I'm correctly understanding variable-length vectors :) The length of length is inferred from the upper limit: - 1-255 bytes => 1 Byte - 256-65535 bytes => 2 Bytes - 65536-16777215 bytes => 3 bytes - 16777216-2^32-1 bytes => 4 bytes (not used anywhere) ... And so on. So yes, 4x32 byte elements in vector with upper limit of 2^16-1 (or 2^16-32 rounded) is 130 bytes total: 2 byte length and 4*32=128 byte value. But I think that all lengths above 255 are either specified to be one byte shy of power of 255 or rounding thereof to integral multiple of elements (the only exception I offhand remember is session IDs in TLS 1.0-1.2, which have maximum length of 32). Then there are vectors with variable length elements. Those can be created by putting in a vector or discriminant/case in the element type (the latter can easily lead to interop problems later). -Ilari From nobody Fri Jan 22 08:51:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4213C1B29D8 for ; Fri, 22 Jan 2016 08:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 6LaO9fxCe8pn for ; Fri, 22 Jan 2016 08:51:33 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 0C20C1A87CD for ; Fri, 22 Jan 2016 08:51:33 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id v14so92949573ykd.3 for ; Fri, 22 Jan 2016 08:51:33 -0800 (PST) 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:content-type; bh=Q8EIV7netRitBQRmvFVWFafV6XdesnHJUZgpTvVQmEA=; b=iELCU8aL+t5j4hixBVh68yusGk11EGfi8YbV08Lx1m9MBr6nZkohK/whPD0PdlKIdF Pw+VWCQS4FbDneZ9lMwgiXohAv0NqoKpkcCOCTXJCpBIS/YlJAp7Uu4fg+EfIIPklqV4 F/kiQ/58wSFq+ueW8GXK/9Ouo7yH3JL4/rUlZ2iQbjbV4s/PSwLxZJF9RREgnknOWxW+ jLs3hxUj98tps4MDwt5dKAApDJJBdN1TAyVMqEvHRi+BrLzeP+LpT/fDcdRFRnrLfFEr khl5Ix2b7oDDvZKUuE7obLs1jJF/GV7Cv6XNGAdttY4Qmesn2ulmjQQ+blR2lzjOH9l8 dp7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q8EIV7netRitBQRmvFVWFafV6XdesnHJUZgpTvVQmEA=; b=YO36ErIFs4zU9ZivoB2ITr2ppAF+SGRVFlAPtvTwISglHAjt5HEa5U9MpPKbbixl+u sHSvEOF+161Wu7UDnsH7cubGEh3G4jHUQaGoovTblerwD8qvb6MNSrJsJ8Qdjl0+t4ue bvZhQaMLB9djNOnPNr/+aFkw+R56EnNNOiu+O0Q3NULBT/V51KUdXkPMAC/Dka1eIvmf 43doUPeZlzLi9cAhUEMnGP7EtKubT90p/92xnLrgEJxB5qHAhJmpWxMl3NM055FKLYXq Q4f68bcrgs1GKXi1wbjIAvGaRfQdwNJDfGIDuNlFnOEe4Lc2umabG4c3h5I+3OgsXRaK 1Rcg== X-Gm-Message-State: AG10YOSZJUn+n0nYCUsFltDx6uRDQTNQPEPqmIBhCmjISLyTUo0slzDUtF/uGSUiWodiTC9RSrm1iY31gGYI8w== X-Received: by 10.37.86.7 with SMTP id k7mr2140462ybb.82.1453481492371; Fri, 22 Jan 2016 08:51:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 22 Jan 2016 08:50:53 -0800 (PST) In-Reply-To: <56A24FAA.6050409@KingsMountain.com> References: <56A24FAA.6050409@KingsMountain.com> From: Eric Rescorla Date: Fri, 22 Jan 2016 08:50:53 -0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=001a114268260a89f50529ef0825 Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Length of a variable-length vector: zero-length case X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 16:51:34 -0000 --001a114268260a89f50529ef0825 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 22, 2016 at 7:50 AM, =JeffH wrote: > wrt https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3 > > if we have.. > > opaque foo<0..2^16-1>; > > ..with a floor length of zero, thus with an instantiation of foo of zero > length, we actually will have in terms of encoded bytes on the wire (in > hex).. > > 00 00 > > ..where this is the 2-byte length field, with length value zero, and a > zero-length (ie, absent, empty) vector content, correct ? Yes. -Ekr > > thanks, > > =JeffH > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114268260a89f50529ef0825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 22, 2016 at 7:50 AM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:
wrt = https://tools.ietf.org/html/draft-iet= f-tls-tls13-11#section-4.3

if we have..

=C2=A0 opaque foo<0..2^16-1>;

..with a floor length of zero, thus with an instantiation of foo of zero le= ngth, we actually will have in terms of encoded bytes on the wire (in hex).= .

=C2=A0 00 00

..where this is the 2-byte length field, with length value zero, and a
zero-length (ie, absent, empty) vector content, correct ?
=
Yes.

-Ekr
=C2=A0
=C2=A0
thanks,

=3DJeffH

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

--001a114268260a89f50529ef0825-- From nobody Fri Jan 22 10:39:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3241B2BCA for ; Fri, 22 Jan 2016 10:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPpZtbeF0jeO for ; Fri, 22 Jan 2016 10:39:29 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D361B2BCB for ; Fri, 22 Jan 2016 10:39:28 -0800 (PST) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-11v.sys.comcast.net with comcast id 96fP1s0045Clt1L016fUoq; Fri, 22 Jan 2016 18:39:28 +0000 Received: from [IPv6:::1] ([73.170.34.26]) by resomta-po-17v.sys.comcast.net with comcast id 96fT1s0020ZpzqZ016fTmA; Fri, 22 Jan 2016 18:39:28 +0000 Message-ID: <56A2775E.5010507@brainhub.org> Date: Fri, 22 Jan 2016 10:39:26 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hubert Kario , tls@ietf.org References: <56A192FC.4060206@brainhub.org> <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com> In-Reply-To: <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453487968; bh=V42tADVCwDFDwAq9QnrQqj/RfEvO9jXUc1riBkL0gRQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hM44U5rBnXq8s7BRwUi6aJh8xPwaVXLInrmwc6J2m77Ymf6W4279ffv1vIPjMn9K1 fDy+ZaAlGertkvWCpKdNJqzMMRegXMEKOrTBYJN1aRuvFhxBGnuM6txr7cs3GfWU2F TE2tpLlvoKZViBrN3Y5EoCFKBGZa2U6kSMU4UPY8FPFMw+qvVM7ToN1RToRGWrxhjX vafe1cmwT2FjinPCQX3cPlWGHJ4CtP9rAG7+0UpWF3f96UFqPIg8JuHd3ZarVV1H1m HJV1vbxOpg1cI3oQmr6Ma2IinDJBwoSvlEC321+5pH0DphZMr0d68HktHI0AA6T5cE rwCm5r7kh0lJA== Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 18:39:32 -0000 On 01/22/2016 03:14 AM, Hubert Kario wrote: > On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote: >> Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the >> following language in sec 4.8.1 >> >>> In RSA signing, the opaque vector contains the signature >>> generated >>> using the RSASSA-PSS signature scheme defined in [RFC3447 >>> ] with MGF1. The digest >>> used in the mask generation function MUST be the same as the >>> digest which is being signed (i.e., what appears in >>> algorithm.signature). The length of the salt MUST be equal to >>> the >>> length of the digest output. Note that previous versions of TLS >>> used >>> RSASSA-PKCS1-v1_5, not RSASSA-PSS. >> >> The >> >>> struct { >>> >>> SignatureAndHashAlgorithm algorithm; >>> opaque signature<0..2^16-1>; >>> >>> } DigitallySigned; >> >> defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec > A.3.1.1: >>> enum { >>> >>> rsa(1), >>> dsa(2), >>> ecdsa(3), >>> rsapss(4), >>> eddsa(5), >>> (255) >>> >>> } SignatureAlgorithm; >> >> since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates >> only. >> >> >> Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as >> frictionless as possible regarding the upgrade of existing TLS >> installations to TLS 1.3. We should expect that all TLS 1.3 servers >> and clients will have support for older versions of TLS on the same >> node. Ideally, it should be possible to upgrade the software / >> firmware to add TLS 1.3 support on existing hardware with minimal >> penalty. > > The transition to TLS 1.3 is not urgent matter. Making sure that it is > as robust as possible is of higher importance than "making it easy to > implement for existing TLS1.2 implementations". > > That's right there in the charter: > https://datatracker.ietf.org/wg/tls/charter/ The issue here is to be able to use existing hardware with TLS 1.3. The CAs got PKCS#1 1.5 exemption under TLS 1.3. I suppose that the reason HS did not get matching capability is it was believed that PSS-only would not be a problem. I noted a few problems with PSS in HS. > >> The current list of FIPS 140 products that support RSA shows twice as >> many products that support RSASSA-PKCS1_V1_5 than these that support >> RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS >> certification with TLS 1.3, factoring client auth and servers. > > You also need a FIPS certified implementation of HKDF. So yes, it most > likely will require new certifications. HKDF is somewhat orthogonal to the this thread. I was pointing out that there are devices, e.g. FIPS PCI cards or smartcard, that "hold" RSA keys. Some of them can only do RSA PKCS#1 1.5 signing with these keys. These devices work with TLS 1.2 and won't work with TLS 1.3. These problems might be fixable if vendors are willing to do so, but observe that for FIPS devices this means more costly and slower re-certification, not just firmware update. Regarding HKDF, note that FIPS 140-2 specifically says that it doesn't certify TLS, SSH, or protocols in general. It certifies crypto primitives. Vendors are free to chose which crypto primitives they certify (and this set is noted on the FIPS certificate). KDFs in TLS are covered by http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf. TLS 1.2 KDF is noted as "TLS KDF" on http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2014.htm . Not many modules claim certification for TLS KDF for current TLS and this may continue to be the case for HKDF in TLS. In our case we do TLS KDF "ourselves" and I think other conceivable implementations can do this too, so this is not an issue in this thread. > >> The only solution that's available at this point is conditioning TLS >> 1.3 support on appropriate hardware. For this reason TLS 1.3 it >> probably won't be enabled by default in the product I work on. I >> would prefer for TLS 1.3 to be enabled by default and write the code >> to decide whether it does PSS or falls back to RSA PKCS1 1.5. > > Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting > it off now would be negligent. You mean for HS only, while leaving it for X.509 certs? More importantly, note that while I understand the intent to increase security by mandating PSS in TLS 1.3, in practice it doesn't work. We/our customers will have to select the highest protocol that works (or is reasonably fast). If the spec is written to mean (TLS1.3 && PSS), if we can't do PSS, we can't do TLS 1.3. There are other desirable security enhancements in TLS 1.3, besides PSS, that would be nice to deploy. From nobody Fri Jan 22 10:48:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB21B2BEA for ; Fri, 22 Jan 2016 10:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmYzwCNUwEgf for ; Fri, 22 Jan 2016 10:48:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id B1C821B2BE7 for ; Fri, 22 Jan 2016 10:48:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9F5C83F404B; Fri, 22 Jan 2016 18:48:21 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 893A43F4071; Fri, 22 Jan 2016 18:48:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453488501; bh=aFMlgMX9M8sPibtl1NrwcjfWioTU0LYqOq1ZXuS5Ug0=; l=1853; h=To:References:From:Date:In-Reply-To:From; b=gkPj9CFAlmmpiw0WU7JU0d7yxbQXOcBXMuYsARyW31SdkNZfKBjbotM4QYHUlbS/s 2CCm3txCbrWXjPfkSCGDlfIy4dEVItr0MbC/nhH6FxZxcfrVAqY09g8XTE5Eay+FlG WWHE4q3ebZ1QcSPRrk/fXVikIvkbYqN1fJt2OR+k= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5A8B4203B; Fri, 22 Jan 2016 18:48:21 +0000 (GMT) To: =JeffH , IETF TLS WG References: <56A24DFC.8050702@KingsMountain.com> From: Benjamin Kaduk Message-ID: <56A27974.8090809@akamai.com> Date: Fri, 22 Jan 2016 12:48:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56A24DFC.8050702@KingsMountain.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 18:48:24 -0000 On 01/22/2016 09:42 AM, =JeffH wrote: > [ resending from different account - my work addr ends up in spam > bucket for many it seems ] > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > >>>> I have a question about the even-vs-odd restrictions on the > length of > >>>> a valid variable-length vector defined in TLS specification after > >>>> reading the section 4.3 of RFC 5246 [1] which states that: > >>>> "The length of an encoded vector must be an even multiple of the > >>>>length > >>>> of a single element (for example, a 17-byte vector of uint16 > would be > >>>> illegal)." > >>>> > >>> It means "whole-number" as opposed to fractional, i.e., there should > >>>not > >>> be unused "junk bytes" at the end. > >> In case it's helpful, here's a suggested re-write of that quoted > >>sentence > >> above.. > >> > >> The length of an encoded variable-length vector must be an > >> exact multiple of the length of a single element. For example, > >> an encoded 17-byte vector of uint16 would be illegal, and an > >> encoded variable-length vector of four 32 byte elements, > >> having a ceiling of 2^16-1, will be 130 bytes long overall > >> (2 byte length field followed by 128 bytes of data). > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > hm, I'm not sure -- what would be the rationale? The exact multiple > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 Ah, I seem to have conflated bits and bytes due to reading too quickly and should have said (2^16-32), as Ilari alluded to with "or rounding thereof to integral multiple of elements". Sorry for the confusion. -Ben From nobody Fri Jan 22 11:14:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591C1B2C62 for ; Fri, 22 Jan 2016 11:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqwd2KGLq4hQ for ; Fri, 22 Jan 2016 11:14:50 -0800 (PST) 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 B74931A6EEC for ; Fri, 22 Jan 2016 11:14:50 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 7D17A3B70B; Fri, 22 Jan 2016 19:14:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0MJEmEL002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 14:14:50 -0500 From: Hubert Kario To: Andrey Jivsov Date: Fri, 22 Jan 2016 20:14:43 +0100 Message-ID: <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <56A2775E.5010507@brainhub.org> References: <56A192FC.4060206@brainhub.org> <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com> <56A2775E.5010507@brainhub.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1774622.zb4aBsOWBs"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 19:14:52 -0000 --nextPart1774622.zb4aBsOWBs Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: > On 01/22/2016 03:14 AM, Hubert Kario wrote: > >> The only solution that's available at this point is conditioning > >> TLS > >> 1.3 support on appropriate hardware. For this reason TLS 1.3 it > >> probably won't be enabled by default in the product I work on. I > >> would prefer for TLS 1.3 to be enabled by default and write the > >> code > >> to decide whether it does PSS or falls back to RSA PKCS1 1.5. > >=20 > > Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not > > cutting it off now would be negligent. >=20 > You mean for HS only, while leaving it for X.509 certs? If we don't do it for HS in TLS first, we'll never get rid of it in=20 X.509 certs. We need to start somewhere, and it's more reasonable to expect that=20 hardware with support for new protocols will get updated for RSA-PSS=20= handling than that libraries and hardware will suddenly start=20 implementing it in droves just in anticipation of the time when CAs=20 _maybe_ will start issuing certificates signed with RSA-PSS. > More importantly, note that while I understand the intent to increase= > security by mandating PSS in TLS 1.3, in practice it doesn't work. We had to wait for XP SP2 to be over 10 years old for the CA's to even=20= _consider_ using anything but SHA-1 for signatures. And most of them di= d=20 that only on explicit request when requesting certificates. If new signature types can't be deployed for new protocols they will=20= never get deployed. There always will be implementations that do the=20= absolute minimum to get interoperability *right now* and not a single=20= extra step. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1774622.zb4aBsOWBs 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 iQIcBAABCgAGBQJWon+jAAoJEJKo0bgB0vX1HfsP/jiN9st335ePQ2eT0K5AjxpN d/9ThqS7sXeodo9vdZRKMol3GdQCF1OtpL9CJ2pHfsY2WxIVODF9Y9uJlCaAUElk LlINPYhZ9XCC1MIh6lRvehdymcNspoVOX4uSpYIPHTviUrv2OwWKhkwKTrXufxcI e2vCrPEekOtowYvgAEO3RglwTSBCut5lP8D/7y50uCw+uMBseE88rPwGMEAgt6M0 CESrLFoBm6wgyIv3ksZD3jxGWWDjk04+8mP8QZk7jGZeniV1p0ibxVhvwN7FMncN qD8ILUkfyzOYzRVpOhcv+fVq6GOsy25q0ieUKttTs2bQpVNDs1WI77SK44ldvvPf q05UJZk2MnN9paW6OQIU3/xZih/HICLP3J9LhzOWRFdgJuDfVThtZ3kjA0u9k3Y9 2mfEYRH4VBGVzaZdbx5sCN3yaJXYiFnhtlQXQpBpReOCK35wNE86oka8NCSTz0oq eYrMaGSkUvr2hAwTync1cbH5iiDQtutwoljnRNzzvcenswfXkay4kcx6COMA1jJ1 +Fh+i92uabCPCsgLkRkxwGB6PXdNJaVDdrB9kl7tFJ8h1JQzfpgagh5uJANC4WQw I6Y02GY9x2aJsMZWBy4TNvZPeKKsj7Uj8B1OUVgrGisK00EN3FVcLZU783uRAaxT Ao1206U62kA2rgZkliJq =yf92 -----END PGP SIGNATURE----- --nextPart1774622.zb4aBsOWBs-- From nobody Fri Jan 22 12:30:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A051E1A8771 for ; Fri, 22 Jan 2016 12:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 oC2exN0bVtML for ; Fri, 22 Jan 2016 12:29:58 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 3E16E1A876E for ; Fri, 22 Jan 2016 12:29:58 -0800 (PST) Received: (qmail 7901 invoked by uid 0); 22 Jan 2016 20:29:54 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jan 2016 20:29:54 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id 9FVd1s00y2UhLwi01FVgbi; Fri, 22 Jan 2016 20:29:52 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7aQ_Q-yQQ-AA:10 a=X7Ea-ya5AAAA:8 a=Knc92pW-D0Lwtjs3h0IA:9 a=04JDf62KHEWFsN2V:21 a=0xHHWwbM4X5NB4-K:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:Cc:To:From; bh=EiVzoWJPBQBxx3NZaRGpaF/C4lDnTWFmn3Prun9yX48=; b=G439yGd140kB45T/c1XZ23VB28D9THnQ3FN+DJRJZUo4nNkQicHdnzN/OPKc3ZdQ2TRAI2jVo+ZVV9S+jSWFktEEydlspADJPN/8iZCATiuyA/Unnwp96MK8UtzgCEXi; Received: from [73.202.80.238] (port=47329 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aMiKy-0002dX-9w; Fri, 22 Jan 2016 13:29:40 -0700 From: =JeffH To: Benjamin Kaduk Message-ID: <56A2912F.6040100@KingsMountain.com> Date: Fri, 22 Jan 2016 12:29:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 20:29:59 -0000 [ fixed pitch font advised here ] > On 01/22/2016 09:42 AM, =JeffH wrote: > > [ resending from different account - my work addr ends up in spam > > bucket for many it seems ] > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > > >>>> I have a question about the even-vs-odd restrictions on the > > length of > > >>>> a valid variable-length vector defined in TLS specification after > > >>>> reading the section 4.3 of RFC 5246 [1] which states that: > > >>>> "The length of an encoded vector must be an even multiple of the > > >>>>length > > >>>> of a single element (for example, a 17-byte vector of uint16 > > would be > > >>>> illegal)." > > >>>> > > >>> It means "whole-number" as opposed to fractional, i.e., there should > > >>>not > > >>> be unused "junk bytes" at the end. > > >> In case it's helpful, here's a suggested re-write of that quoted > > >>sentence > > >> above.. > > >> > > >> The length of an encoded variable-length vector must be an > > >> exact multiple of the length of a single element. For example, > > >> an encoded 17-byte vector of uint16 would be illegal, and an > > >> encoded variable-length vector of four 32 byte elements, > > >> having a ceiling of 2^16-1, will be 130 bytes long overall > > >> (2 byte length field followed by 128 bytes of data). > > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > > > hm, I'm not sure -- what would be the rationale? The exact multiple > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 > > Ah, I seem to have conflated bits and bytes due to reading too quickly > and should have said (2^16-32), as Ilari alluded to with "or rounding > thereof to integral multiple of > elements". hm, but in this case it seems that a variable-length vector declared with a length range of <0..2^16-1> would exactly accommodate up to 2048 32-byte elements.. opaque Foo[32] ; Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048 Foo instances */ ..because it has a zero-based index, as in this example.. opaque Array<0..2^2-1> ; /* should accommodate 2^2 = 4 1-byte elements */ /* Array with 4 elements in memory: [ xx xx xx xx ] indices (hex): 0 1 2 3 3 = 2^2-1 indices (binary): 00 01 10 11 */ ..yes? or am I missing something? thanks, =JeffH From nobody Fri Jan 22 13:27:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41E1A8952 for ; Fri, 22 Jan 2016 13:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-X--KgtOd3l for ; Fri, 22 Jan 2016 13:27:17 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 695041A8951 for ; Fri, 22 Jan 2016 13:27:17 -0800 (PST) Received: (qmail 5767 invoked by uid 0); 22 Jan 2016 21:27:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 22 Jan 2016 21:27:15 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id 9GSw1s0082UhLwi01GSzJk; Fri, 22 Jan 2016 21:27:12 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7aQ_Q-yQQ-AA:10 a=X7Ea-ya5AAAA:8 a=woDKzmowUs0age1bP1AA:9 a=17N5ha09fH-CXec6:21 a=LTotrk_9ZNbJbNYh:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:To:References:Subject; bh=0zXjqIBZJPR9DIJ1bdMTSke5XItlncFNmYqZSsKsCFk=; b=5ZIfkSpbmSgqZh9DU5wYmRSBfckVV90QbXxx62zF0LwCcugDyb33AATDEpnS2p4dpSezG7jEVl/ZO6gzYgk7gREGeCgFaNWZEnkWKvL4hXh3vmRtcSxQD58aSg/9GEcG; Received: from [73.202.80.238] (port=47569 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aMjEQ-0002Q9-LW; Fri, 22 Jan 2016 14:26:58 -0700 References: <56A2912F.6040100@KingsMountain.com> To: Benjamin Kaduk From: =JeffH Message-ID: <56A29E9D.9030305@KingsMountain.com> Date: Fri, 22 Jan 2016 13:26:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A2912F.6040100@KingsMountain.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 21:27:18 -0000 On 01/22/2016 12:29 PM, =JeffH wrote: > [ fixed pitch font advised here ] the below is corrected to use "byte count" rather than "index" or "indicies" (and to ditch the tabs).. > On 01/22/2016 09:42 AM, =JeffH wrote: > > [ resending from different account - my work addr ends up in spam > > bucket for many it seems ] > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > > >>>> I have a question about the even-vs-odd restrictions on the > > length of > > >>>> a valid variable-length vector defined in TLS specification after > > >>>> reading the section 4.3 of RFC 5246 [1] which states that: > > >>>> "The length of an encoded vector must be an even multiple of the > > >>>>length > > >>>> of a single element (for example, a 17-byte vector of uint16 > > would be > > >>>> illegal)." > > >>>> > > >>> It means "whole-number" as opposed to fractional, i.e., there should > > >>>not > > >>> be unused "junk bytes" at the end. > > >> In case it's helpful, here's a suggested re-write of that quoted > > >>sentence > > >> above.. > > >> > > >> The length of an encoded variable-length vector must be an > > >> exact multiple of the length of a single element. For example, > > >> an encoded 17-byte vector of uint16 would be illegal, and an > > >> encoded variable-length vector of four 32 byte elements, > > >> having a ceiling of 2^16-1, will be 130 bytes long overall > > >> (2 byte length field followed by 128 bytes of data). > > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > > > hm, I'm not sure -- what would be the rationale? The exact multiple > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 > > Ah, I seem to have conflated bits and bytes due to reading too quickly > and should have said (2^16-32), as Ilari alluded to with "or rounding > thereof to integral multiple of > elements". hm, but in this case it seems that a variable-length vector declared with a length range of <0..2^16-1> would exactly accommodate up to 2048 32-byte elements.. opaque Foo[32] ; Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048 Foo instances */ ..because it has a zero-based byte count, as in this example.. opaque Array<0..2^2-1> ; /* should accommodate 2^2 = 4 1-byte elements */ /* Array with 4 elements in memory: [ xx xx xx xx ] byte count (hex): 0 1 2 3 3 = 2^2-1 byte count (binary): 00 01 10 11 */ ..yes? or am I missing something? thanks, =JeffH From nobody Fri Jan 22 13:53:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F991A8A4F for ; Fri, 22 Jan 2016 13:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnGj_-y8OPg5 for ; Fri, 22 Jan 2016 13:53:29 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2E1A8A4E for ; Fri, 22 Jan 2016 13:53:29 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF0013F401F; Fri, 22 Jan 2016 21:53:27 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id BF5463F4014; Fri, 22 Jan 2016 21:53:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453499607; bh=ryw910xajQKTucVROlurS/NHI5ZtnnbywKbVg0FjYAM=; l=3157; h=To:References:Cc:From:Date:In-Reply-To:From; b=FAnY6lzrZDevM3zeHp1Xtgdcnq70KB3gcxAFANcGWcQdXWrE2tp26rzH8FgPJMXY1 N2g8LW6PKSpUjG7wtMVmllePxBIAXLSrgpL3kTuHnio/UmFcpHYUOuEmyrsxcOu4S9 1YdpiBIumpBssmS2jLLRR2yUPzs2sBWeje2RTIG0= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 92D0D202F; Fri, 22 Jan 2016 21:53:27 +0000 (GMT) To: =JeffH References: <56A2912F.6040100@KingsMountain.com> <56A29E9D.9030305@KingsMountain.com> From: Benjamin Kaduk Message-ID: <56A2A4D7.9050308@akamai.com> Date: Fri, 22 Jan 2016 15:53:27 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A29E9D.9030305@KingsMountain.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 21:53:31 -0000 On 01/22/2016 03:26 PM, =JeffH wrote: > On 01/22/2016 12:29 PM, =JeffH wrote: >> [ fixed pitch font advised here ] > > the below is corrected to use "byte count" rather than "index" or > "indicies" (and to ditch the tabs).. > > > > On 01/22/2016 09:42 AM, =JeffH wrote: > > > [ resending from different account - my work addr ends up in spam > > > bucket for many it seems ] > > > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > > > >>>> I have a question about the even-vs-odd restrictions on the > > > length of > > > >>>> a valid variable-length vector defined in TLS specification > after > > > >>>> reading the section 4.3 of RFC 5246 [1] which states that: > > > >>>> "The length of an encoded vector must be an even multiple of the > > > >>>>length > > > >>>> of a single element (for example, a 17-byte vector of uint16 > > > would be > > > >>>> illegal)." > > > >>>> > > > >>> It means "whole-number" as opposed to fractional, i.e., there > should > > > >>>not > > > >>> be unused "junk bytes" at the end. > > > >> In case it's helpful, here's a suggested re-write of that quoted > > > >>sentence > > > >> above.. > > > >> > > > >> The length of an encoded variable-length vector must be an > > > >> exact multiple of the length of a single element. For example, > > > >> an encoded 17-byte vector of uint16 would be illegal, and an > > > >> encoded variable-length vector of four 32 byte elements, > > > >> having a ceiling of 2^16-1, will be 130 bytes long overall > > > >> (2 byte length field followed by 128 bytes of data). > > > > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > > > > > hm, I'm not sure -- what would be the rationale? The exact multiple > > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 > > > > Ah, I seem to have conflated bits and bytes due to reading too quickly > > and should have said (2^16-32), as Ilari alluded to with "or rounding > > thereof to integral multiple of > > elements". > > hm, but in this case it seems that a variable-length vector declared > with a length range of <0..2^16-1> would exactly accommodate up to > 2048 32-byte elements.. > > opaque Foo[32] ; > > Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048 > Foo instances */ > > ..because it has a zero-based byte count, as in this example.. > > > opaque Array<0..2^2-1> ; /* should accommodate > 2^2 = 4 1-byte elements */ > > /* > Array with 4 > elements in memory: [ xx xx xx xx ] > byte count (hex): 0 1 2 3 3 = 2^2-1 > > byte count (binary): 00 01 10 11 > > */ > > > ..yes? or am I missing something? You are missing something. The encoded length represents the actual number of bytes that will follow, so that a zero-length array with maximum length 2^16-1 is encoded as just 00 00. So, even though the index into the array starts at zero, the actual length "starts at" 1, just like in C. -Ben From nobody Fri Jan 22 14:26:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBA71A8ADD for ; Fri, 22 Jan 2016 14:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 EaISL_Q5OYPa for ; Fri, 22 Jan 2016 14:26:05 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 0AB741A8ADC for ; Fri, 22 Jan 2016 14:26:04 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id z14so1101939igp.1 for ; Fri, 22 Jan 2016 14:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=nDAGzx/Vc7CJ9nNo4nmplTrzCTaD3OICoN311cb8S6c=; b=izjrH6pgBGGX+oAswa6sme9WGS7BfuP+JNE9VDGRZatUjkzTpKRZUCzBGPw3hJdRal TKvGMkcUlz7IFyFgB5BoM+YwEP9lx+kYSEj4/G9wFktah3xpeCC7mWsxtpxcoORxq7Nn 1qLvuByGEcxiU5ExTk820GkObTrlKUyh9yzzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=nDAGzx/Vc7CJ9nNo4nmplTrzCTaD3OICoN311cb8S6c=; b=VeRUy8EDDnfxIrCW3Ue4Vlb6GjlIt3C2aTF9HQ0Ayc59haX56W7nXbI+3CRzfkI7Dn LDs8LCz5+WzmS9LlVH6HBS+FLTG3hh/Vw8AmPwIT4Au6AftDBBRpAj/LOXTHnkla4JHP g9uIv/dTdyTpVorodxPP6p7a9zjNQmSqxOf1e3lHehEsY3TO1qSzhroFNMCjyz/bDWPX mxh/82YS/1fIkouum4HvVtwWI/5dTWaYwAYjQD93WpDXI8GLRIRq/4X2PH2z9aodbke1 NFA7C5SoIcakR9pL4ZUZ4gyZNc6M7LVEnMiCWHVhG/Fvz31cQtG020fpj4Ozax1Fzlou /QsQ== X-Gm-Message-State: AG10YORsFTWX55cr76oFrY5bm1Y1U9jVSoqRHBzGGljpUIb5ppPBhXiY0bd3pDaoyOZQ/NPn/WxgVLUquYlCXSx/ X-Received: by 10.50.8.106 with SMTP id q10mr5616855iga.67.1453501564290; Fri, 22 Jan 2016 14:26:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 22 Jan 2016 22:25:54 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013c65dc6be44b0529f3b425 Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2016 22:26:07 -0000 --089e013c65dc6be44b0529f3b425 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've put together a pull request with some initial text for this proposal if folks decide to adopt it. https://github.com/tlswg/tls13-spec/pull/404 (I'm sure there's no end of editorial problems. I think this is the first time I've done non-trival spec work.) David On Fri, Jan 15, 2016 at 3:45 PM David Benjamin wrote: > Hi folks, > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. We have > SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all = in > independent registries. NamedGroup is sent in one list, also used for > (EC)DH, while the other two are sent as a pair of (HashAlgorithm, > SignatureAlgorithm) tuples but live in separate registries. > > This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to > be messy to implement. Client certificate keys may be in smartcards via > OS-specific APIs, so a lot of time is spent transiting new preference > shapes across API boundaries in order to discover smartcard bugs. Sometim= es > I think people deploy client certs because they hate me and want to cause > me pain=E2=80=A6 :-) > > Anyway, the new CFRG curves also bind signature curve and hash together. > The current draft represents this as eddsa_ed25519 and eddsa_ed448 > NamedGroups and eddsa SignatureAlgorithm. But this doesn=E2=80=99t captur= e that > EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.) > > I propose we fold the negotiable parameters under one name. Think of how > we=E2=80=99ve all settled on AEADs being a good named primitive with a co= mmon type > signature[1]. Specifically: > > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now > on, NamedGroup is only used for (EC)DH. > > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > instead. (Or maybe a different name to not collide.) u8 is a little tight > to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty. > > 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by > (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401 > becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with > HashAlgorithm from TLS 1.2. Note this does not introduce new > premultiplications on the wire. Just in the spec and registry. > > 4. Deprecate ecdsa_sha256, etc., in favor of new > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_= * > values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although thi= s > introduces new premultiplications, it=E2=80=99s only 9 values with the pr= uned TLS > 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. > > 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and > rsapss_{sha256,sha384,sha512}. These come with the signature algorithm an= d > curve pre-specified. (See [2] at the bottom for full list of allocations.= ) > > Thoughts? > > David > > [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need some m= apping to > a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with > hashAlgorithm SHA-256, maskGenAlgorithm > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14= . > And RSA key generation still has size parameter. Hopefully future things > can look more like Ed25519. > > [2] > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note thi= s > is wire-compatible with TLS 1.2. > - 0x0101 - rsa_pkcs1_md5 > - 0x0201 - rsa_pkcs1_sha1 > - 0x0301 - rsa_pkcs1_sha224 > - 0x0401 - rsa_pkcs1_sha256 > - 0x0501 - rsa_pkcs1_sha334 > - 0x0601 - rsa_pkcs1_sha512 > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but > ignored in TLS 1.3. > > 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to > avoid colliding with existing signature algorithms, but I don=E2=80=99t t= hink > that=E2=80=99s necessary[3]. > - rsapss_sha256 > - rsapss_sha384 > - rsapss_sha512 > - ecdsa_p256_sha256 > - ecdsa_p256_sha384 > - ecdsa_p256_sha512 > - ecdsa_p384_sha256 > - ecdsa_p384_sha384 > - ecdsa_p384_sha512 > - ecdsa_p521_sha256 > - ecdsa_p521_sha384 > - ecdsa_p521_sha512 > - eddsa_ed25519 > - eddsa_ed448 > > 0xfe00-0xffff - reserved for private use, compatible with existing > HashAlgorithm reservation. > > [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7)= , > RSA}, they should ignore it since hash 7 doesn't exist. > --089e013c65dc6be44b0529f3b425 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've put together a pull request with some initial tex= t for this proposal if folks decide to adopt it.

(I'm sure there's no end of editorial proble= ms. I think this is the first time I've done non-trival spec work.)
=
David

On = Fri, Jan 15, 2016 at 3:45 PM David Benjamin <davidben@chromium.org> wrote:
Hi folks,

This is a pro= posal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature = algorithms are spread across the handshake. We have SignatureAlgorithm, Nam= edGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registries= . NamedGroup is sent in one list, also used for (EC)DH, while the other two= are sent as a pair of (HashAlgorithm, SignatureAlgorithm) tuples but live = in separate registries.

This is a lot of moving parts. Signature neg= otiation in TLS 1.2 tends to be messy to implement. Client certificate keys= may be in smartcards via OS-specific APIs, so a lot of time is spent trans= iting new preference shapes across API boundaries in order to discover smar= tcard bugs. Sometimes I think people deploy client certs because they hate = me and want to cause me pain=E2=80=A6 :-)

Anyway, the new CFRG curve= s also bind signature curve and hash together. The current draft represents= this as eddsa_ed25519 and eddsa_ed448 NamedGroups and eddsa SignatureAlgor= ithm. But this doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is il= legal. (Or ECDSA + FF3072.)

I propose we fold the negotiable paramet= ers under one name. Think of how we=E2=80=99ve all settled on AEADs being a= good named primitive with a common type signature[1]. Specifically:
1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now on= , NamedGroup is only used for (EC)DH.

2. Remove HashAlgorithm, Signa= tureAlgorithm, SignatureAndHashAlgorithm as they are. Introduce a new Signa= tureAlgorithm u16 type and negotiate that instead. (Or maybe a different na= me to not collide.) u8 is a little tight to allocate=C2=A0eddsa_ed25519 and= =C2=A0eddsa_ed448 separately, but u16 is plenty.

3. Allocate values = for SignatureAlgorithm wire-compatibly with TLS 1.2 by (ab)using the old (H= ashAlgorithm, SignatureAlgorithm) tuples. 0x0401 becomes rsa_pkcs1_sha256, = etc. Reserve ranges consistently with HashAlgorithm from TLS 1.2. Note this= does not introduce new premultiplications on the wire. Just in the spec an= d registry.

4. Deprecate ecdsa_sha256, etc., in favor of new ecdsa_{= p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* values = are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this introdu= ces new premultiplications, it=E2=80=99s only 9 values with the pruned TLS = 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
=
5. Add new allocations for eddsa_ed25519, eddsa_ed448, and rsapss_{sha2= 56,sha384,sha512}. These come with the signature algorithm and curve pre-sp= ecified. (See [2] at the bottom for full list of allocations.)

Thoug= hts?

David

[1] We=E2=80=99re stuck with RSA-PSS's general= ity, so that'll need some mapping to a subset of X.509's RSA-PSS. W= e'll just not bother with RSA-PSS with hashAlgorithm SHA-256, maskGenAl= gorithm MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerFi= eld 14. And RSA key generation still has size parameter. Hopefully future t= hings can look more like Ed25519.

[2]
0x0000-0x06ff - Reserved ra= nge for TLS 1.2 compatibility values. Note this is wire-compatible with TLS= 1.2.
- 0x0101 - rsa_pkcs1_md5
- 0x0201 - rsa_pkcs1_sha1
- 0x0301 = - rsa_pkcs1_sha224
- 0x0401 - rsa_pkcs1_sha256
- 0x0501 - rsa_pkcs1_s= ha334
- 0x0601 - rsa_pkcs1_sha512
- 0x{01-06}02 - dsa_md5, etc. Ignor= ed in TLS 1.3.
- 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 c= ompatibility but ignored in TLS 1.3.

0x0700-0xfdff - Allo= cate new values here. Optionally avoid 0x??0[0-3] to avoid colliding with e= xisting signature algorithms, but I don=E2=80=99t think that=E2=80=99s nece= ssary[3].
- rsapss_sha256
- rsapss_sha384
- rsapss_sha512
- ecd= sa_p256_sha256
- ecdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p38= 4_sha256
- ecdsa_p384_sha384
- ecdsa_p384_sha512
- ecdsa_p521_sha2= 56
- ecdsa_p521_sha384
- ecdsa_p521_sha512
- eddsa_ed25519
- ed= dsa_ed448

0xfe00-0xffff - reserved for private use, compatible with = existing HashAlgorithm reservation.

[3] If a TLS 1.2 implementation = sees 0x0701 and interprets it as {hash(7), RSA}, they should ignore it sinc= e hash 7 doesn't exist.
--089e013c65dc6be44b0529f3b425-- From nobody Fri Jan 22 16:43:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270E1B2DFD for ; Fri, 22 Jan 2016 16:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 5nuNrh4mFrCI for ; Fri, 22 Jan 2016 16:43:25 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 4D2CD1B2E0B for ; Fri, 22 Jan 2016 16:43:25 -0800 (PST) Received: (qmail 28092 invoked by uid 0); 23 Jan 2016 00:43:21 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 23 Jan 2016 00:43:21 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id 9CjH1s0062UhLwi01CjL8X; Fri, 22 Jan 2016 17:43:21 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7aQ_Q-yQQ-AA:10 a=X7Ea-ya5AAAA:8 a=48vgC7mUAAAA:8 a=IJWUrp6PSUii0mu9BcUA:9 a=qWIPLJvxHmr-F-aF:21 a=-s_J8KhJsfBUT8S0:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:To:From; bh=v1cAU2AXm+7YIDpjd2gcATRBIykWI8SZgWi9upCj4S0=; b=VPjtv/gcx3nlXFBGRoOBSAvi19rqrSD1GYSne96GJu6j86Z7o9h+A+g3wUB1CyqCzVGoeucTBV7xquVFuh/xNBK8OBdalk0rb8O/+UOLBsRKsHDDZu0N/P3Ut1Wd3ZWM; Received: from [73.202.80.238] (port=48512 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aMmIO-0004rY-Vp for tls@ietf.org; Fri, 22 Jan 2016 17:43:17 -0700 From: =JeffH To: IETF TLS WG Message-ID: <56A2CC9F.7070007@KingsMountain.com> Date: Fri, 22 Jan 2016 16:43:11 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:43:27 -0000 ON Fri, 22 Jan 2016 15:53:27 Benjamin Kaduk noted: > On 01/22/2016 03:26 PM, =JeffH wrote: > > On 01/22/2016 12:29 PM, =JeffH wrote: > >> [ fixed pitch font advised here ] > > > > the below is corrected to use "byte count" rather than "index" or > > "indicies" (and to ditch the tabs).. > > > > > > > On 01/22/2016 09:42 AM, =JeffH wrote: > > > > [ resending from different account - my work addr ends up in spam > > > > bucket for many it seems ] > > > > > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > > > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > > > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > > > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: >>>>>>>> I have a question about the even-vs-odd restrictions on the >>>>>>>> length of a valid variable-length vector defined in TLS >>>>>>>> specification after reading the section 4.3 of RFC 5246 >>>>>>>> [1] which states that: "The length of an encoded vector >>>>>>>> must be an even multiple of the length of a single element >>>>>>>> (for example, a 17-byte vector of uint16 would be >>>>>>>> illegal)." >>>>>>>> >>>>>>> It means "whole-number" as opposed to fractional, i.e., there >>>>>>> should not be unused "junk bytes" at the end. >>>>>> >>>>>> In case it's helpful, here's a suggested re-write of that >>>>>> quoted sentence above.. > > > > >> > > > > >> The length of an encoded variable-length vector must be an > > > > >> exact multiple of the length of a single element. For example, > > > > >> an encoded 17-byte vector of uint16 would be illegal, and an > > > > >> encoded variable-length vector of four 32 byte elements, > > > > >> having a ceiling of 2^16-1, will be 130 bytes long overall > > > > >> (2 byte length field followed by 128 bytes of data). > > > > > > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > > > > > > > hm, I'm not sure -- what would be the rationale? The exact multiple > > > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 > > > > > > Ah, I seem to have conflated bits and bytes due to reading too quickly > > > and should have said (2^16-32), as Ilari alluded to with "or rounding > > > thereof to integral multiple of > > > elements". > > > > hm, but in this case it seems that a variable-length vector declared > > with a length range of <0..2^16-1> would exactly accommodate up to > > 2048 32-byte elements.. > > > > opaque Foo[32] ; > > > > Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048 > > Foo instances */ > > > > ..because it has a zero-based byte count, as in this example.. > > > > > > opaque Array<0..2^2-1> ; /* should accommodate > > 2^2 = 4 1-byte elements */ > > > > /* > > Array with 4 > > elements in memory: [ xx xx xx xx ] > > byte count (hex): 0 1 2 3 3 = 2^2-1 > > > > byte count (binary): 00 01 10 11 > > > > */ > > > > > > ..yes? or am I missing something? > > You are missing something. > > The encoded length represents the actual number of bytes that will > follow, so that a zero-length array with maximum length 2^16-1 is > encoded as just 00 00. So, even though the index into the array starts > at zero, the actual length "starts at" 1, just like in C. Ok, thanks, yes, I was confusing byte count with indices. To test my understanding: Given.. opaque Foo[32] ; Foo fooSequence<0..2^16-32> ; ..fooSequence will accommodate up to 2047 Foo instances, and the length prefix of fooSequence will itself be two bytes long, yes? AFAICT, though, from [1] (and prior TLS specs), it seems legit to declare fooSequence like so.. Foo fooSequence<0..2^16-1> ; ..with the expectation that a correct implementation will allow only 2047 Foo instances to be encoded into a fooSequence on the wire, yes ? Also, if one actually needs to be able to accommodate up to _2048_ Foo instances, and can tolerate having the length prefix be three bytes long, then one could declare fooSequence as.. Foo fooSequence<0..2^16>; ..or.. Foo fooSequence<0..2^24-1>; ..yes? thanks again, =JeffH [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3 From nobody Fri Jan 22 16:50:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB51B2E50 for ; Fri, 22 Jan 2016 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcCWQoV11Gb8 for ; Fri, 22 Jan 2016 16:50:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 56D221B2E47 for ; Fri, 22 Jan 2016 16:50:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5220E3F4002; Sat, 23 Jan 2016 00:50:33 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 012CF3F4008; Sat, 23 Jan 2016 00:50:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453510233; bh=a+VzDaB3MFqXI32V8AtXdki1VkIR0p9XHFQe047dEVI=; l=4740; h=To:References:From:Date:In-Reply-To:From; b=riaxxKZIpbVvOWfUUc2hMPKesPpJ/0gA8Dy7kppCnj0B6SKN2l3gqDG42lZtCosuS gN4cOJq3MWVyb7IV0XEgDo0JDr5OtGZIpjHdm9LlNFZ8I0n/5tvFRv+tUn7CREbl1G 1H56iz/e5hGrzhXF+6KHQaNMYjmTsWWyIdGeLSHw= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C6175202C; Sat, 23 Jan 2016 00:50:32 +0000 (GMT) To: =JeffH , IETF TLS WG References: <56A2CC9F.7070007@KingsMountain.com> From: Benjamin Kaduk Message-ID: <56A2CE58.1030904@akamai.com> Date: Fri, 22 Jan 2016 18:50:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A2CC9F.7070007@KingsMountain.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Length of a variable-length vector: Could it be an odd multiple? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 00:50:38 -0000 On 01/22/2016 06:43 PM, =JeffH wrote: > ON Fri, 22 Jan 2016 15:53:27 Benjamin Kaduk noted: > > On 01/22/2016 03:26 PM, =JeffH wrote: > > > On 01/22/2016 12:29 PM, =JeffH wrote: > > >> [ fixed pitch font advised here ] > > > > > > the below is corrected to use "byte count" rather than "index" or > > > "indicies" (and to ditch the tabs).. > > > > > > > > > > On 01/22/2016 09:42 AM, =JeffH wrote: > > > > > [ resending from different account - my work addr ends up in spam > > > > > bucket for many it seems ] > > > > > > > > > > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote: > > > > > >On 01/20/2016 12:47 PM, Hodges, Jeff wrote: > > > > > >> On 1/13/16, 12:53 PM, "Benjamin Kaduk" > wrote: > > > > > >>> On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > >>>>>>>> I have a question about the even-vs-odd restrictions on the > >>>>>>>> length of a valid variable-length vector defined in TLS > >>>>>>>> specification after reading the section 4.3 of RFC 5246 > >>>>>>>> [1] which states that: "The length of an encoded vector > >>>>>>>> must be an even multiple of the length of a single element > >>>>>>>> (for example, a 17-byte vector of uint16 would be > >>>>>>>> illegal)." > >>>>>>>> > >>>>>>> It means "whole-number" as opposed to fractional, i.e., there > >>>>>>> should not be unused "junk bytes" at the end. > >>>>>> > >>>>>> In case it's helpful, here's a suggested re-write of that > >>>>>> quoted sentence above.. > > > > > >> > > > > > >> The length of an encoded variable-length vector must be an > > > > > >> exact multiple of the length of a single element. For example, > > > > > >> an encoded 17-byte vector of uint16 would be illegal, and an > > > > > >> encoded variable-length vector of four 32 byte elements, > > > > > >> having a ceiling of 2^16-1, will be 130 bytes long overall > > > > > >> (2 byte length field followed by 128 bytes of data). > > > > > > > > > > > >Wouldn't the ceiling more properly be 2^16-4 in that case? > > > > > > > > > > hm, I'm not sure -- what would be the rationale? The exact > multiple > > > > > criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875 > > > > > > > > Ah, I seem to have conflated bits and bytes due to reading too > quickly > > > > and should have said (2^16-32), as Ilari alluded to with "or > rounding > > > > thereof to integral multiple of > > > > elements". > > > > > > hm, but in this case it seems that a variable-length vector declared > > > with a length range of <0..2^16-1> would exactly accommodate up to > > > 2048 32-byte elements.. > > > > > > opaque Foo[32] ; > > > > > > Foo fooSequence<0..2^16-1>; /* will accommodate up to 2048 > > > Foo instances */ > > > > > > ..because it has a zero-based byte count, as in this example.. > > > > > > > > > opaque Array<0..2^2-1> ; /* should accommodate > > > 2^2 = 4 1-byte elements */ > > > > > > /* > > > Array with 4 > > > elements in memory: [ xx xx xx xx ] > > > byte count (hex): 0 1 2 3 3 = 2^2-1 > > > > > > byte count (binary): 00 01 10 11 > > > > > > */ > > > > > > > > > ..yes? or am I missing something? > > > > You are missing something. > > > > The encoded length represents the actual number of bytes that will > > follow, so that a zero-length array with maximum length 2^16-1 is > > encoded as just 00 00. So, even though the index into the array starts > > at zero, the actual length "starts at" 1, just like in C. > > Ok, thanks, yes, I was confusing byte count with indices. > > To test my understanding: > > Given.. > > opaque Foo[32] ; > > Foo fooSequence<0..2^16-32> ; > > > ..fooSequence will accommodate up to 2047 Foo instances, and the > length prefix of fooSequence will itself be two bytes long, yes? > Yes. > > AFAICT, though, from [1] (and prior TLS specs), it seems legit to > declare fooSequence like so.. > > Foo fooSequence<0..2^16-1> ; > > ..with the expectation that a correct implementation will allow only > 2047 Foo instances to be encoded into a fooSequence on the wire, yes ? > I believe a correct implementation would do so, yes, though I am not quite enough of a spec lawyer to be able to state that authoritatively. The <0..2^16-32> form is perhaps friendlier to the reader. > > Also, if one actually needs to be able to accommodate up to _2048_ Foo > instances, and can tolerate having the length prefix be three bytes > long, then one could declare fooSequence as.. > > Foo fooSequence<0..2^16>; > > ..or.. > > Foo fooSequence<0..2^24-1>; > > ..yes? Yes. (The latter form might permit an attacker to force a peer to consume a lot of memory processing a request, of course.) -Ben From nobody Sat Jan 23 11:13:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106E21A8FD4 for ; Sat, 23 Jan 2016 11:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXQOwOlgR9r8 for ; Sat, 23 Jan 2016 11:13:41 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0ED11A8F37 for ; Sat, 23 Jan 2016 11:13:40 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id p187so66547805oia.2 for ; Sat, 23 Jan 2016 11:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=967juKGbAiTjGRjOJODP7p5sE2OuR/hFv7mFi9b5P14=; b=n0sZhwABq4dglKcn5Qn7ypKPlNYIpjTEuEjANNHShzfXkgX74SRDmjmZ1caqnbidqo To2B3G+1mB41+an7R51ay8rw7Ey16iov0haCiJdm3Rr8WYEPBNb3/t3Ogt8l5Sqt6Mjc zqxFNTUdhfheig2Tbd1ijh3VWzJpJvWMGttx1MOrHQ9h/JXH02eJil0aAdEw4v/A3m26 Lm3SiJ5uYldrqsqjU4VUpsTAaIYdfX7EjQKDVkrlD2Ci9LD0NiycRsMejlph6TNklvVB p7yERCj56PqU3jk1dbRNPp1EzedshRO21e1bSEojSG/5yfbpSa+jnSYq7c0vpshkCqDO 8ZIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=967juKGbAiTjGRjOJODP7p5sE2OuR/hFv7mFi9b5P14=; b=IUNOFe9Tf/mpBzIjZ7nsKDuQVk/0VjbioZWyuR23wqQjh+EwMecLrsyfLHTX6mJndn bWCrhc7gEmnmccU3LvGGxuUFCeZ1WImZs/VX4/aFoMvO+TTGgSmxU7i22RtQ/VBbkcWh yYU4K3reTMfb7IvJa2/hAayV1+A6W0jIZ2LfXtfJt0A0WvWhFS1vg3THTnk/k7pOYW5A vrav2WjkGjKJ+mF/4oOzmG24U6HEN06CF1gh2kE8z6yQWgzqvEC8P3Y3bVduVtLA8AtK XlYo96oHswEaBa8e+uOQzHLvZ4D4iyhGYyhtXnVvUW5+PmIWDOIkyHYqCIEyUB64+U34 YChA== X-Gm-Message-State: AG10YOSfWtY3cU78SppaK0mze0OYyBqV52RgPdav47AzsZIvpx6H4O/67FqKNfZZ3zSoNkQQTAlnFKGldt1eOw== MIME-Version: 1.0 X-Received: by 10.202.87.77 with SMTP id l74mr7124981oib.96.1453576420156; Sat, 23 Jan 2016 11:13:40 -0800 (PST) Received: by 10.182.196.104 with HTTP; Sat, 23 Jan 2016 11:13:40 -0800 (PST) Date: Sat, 23 Jan 2016 19:13:40 +0000 Message-ID: From: Joseph Birr-Pixton To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:13:42 -0000 Hi, I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. For discussion, here's a pull request with possible language: https://github.com/tlswg/tls13-spec/pull/406 Cheers, Joe From nobody Sat Jan 23 11:59:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8D1ACEDB for ; Sat, 23 Jan 2016 11:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spzDCQfQZz12 for ; Sat, 23 Jan 2016 11:59:16 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF751ACED8 for ; Sat, 23 Jan 2016 11:59:16 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id is5so88427943obc.0 for ; Sat, 23 Jan 2016 11:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0HTWhAWWkmK+so4ajAae2izyFP9umX9N8Ryuwa4K4g=; b=0oiPSHFmPNEnb2e6fuQSxgJyouwiXBTDt5mNO3umxc++tKQGvG8ZHZRST8NPOpLHro oDCuxw70gSkjq8aojoxj7suF2q5yAaFVDgC3gbv1UV3MgiBzxj3iZcmer7NStuXwKn5f DgngEC/UiApwJrRP2Esos/pJiwpOWGdLz4cXc7BmRJ8z1UqyLC4H6PcnuboOniR7pYSg NMfupZ1iey90pn9H83IQG8rjVX75lLxfcO/OK+Tgem90qFap/eZ8WMKvtFeitosx2c1K OZd8s6/3duSHHXEtNgDALwmabI/X/BdOv35+Vcwtbc9QjzuLQP/F5+4OoVOtmXKLwNzY E56A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p0HTWhAWWkmK+so4ajAae2izyFP9umX9N8Ryuwa4K4g=; b=Neyp8bFfZXEcD3PCiV8JPx/EdsY+Zmld/8MEvPb//JtS2PA/+X03vdO2SLODCpk4BO xkPh5I+A7LKYm5Vmzu0BFpu5zD3eWD+lG3kjTC8g3j+rdzIsZtq9uginiRLZPs8xBuqY 9bcNaX75t0CW3u92YVTQKzh8cJzwvZZyRG8W2G+emw+RTqsUNXC9X1xoZPzy/mrZ63Dw CJWi2QK/uYVKLhH7Ud3bKg9nQ0hZNOcsG7WOzqw2TnTWVNEobEpDT3bttIF5JRZsGVUO Cq4eO7ssgUuO6jKeva+w0CH1CFgLrVIjr4IHjbvXuMqI20GRQjNmz1Sz4cMUqVj5F3oH /1zg== X-Gm-Message-State: AG10YOQMu1EN0hKKiaygDk2WzAzV2MjpKLzNPgjRcWCu5im79SFgN9NcsRL9P9mKz8DhRTHAg9xpBEO57ziiLw== MIME-Version: 1.0 X-Received: by 10.182.210.234 with SMTP id mx10mr7466512obc.47.1453579155896; Sat, 23 Jan 2016 11:59:15 -0800 (PST) Received: by 10.182.196.104 with HTTP; Sat, 23 Jan 2016 11:59:15 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 19:59:15 +0000 Message-ID: From: Joseph Birr-Pixton To: Jacob Maskiewicz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:59:18 -0000 Hi, The other benefit is being able to test that a critical code path produces the correct answers. With randomised k, this is not really possible. For instance, you can choose k with the top bit clear without any obvious or externally-testable effects, except effectively publishing your long-term private key after a large number of signatures[1]. Given the history of these things, I would perhaps challenge the assumption that all TLS stacks will have a bug-free, thread-safe, fork-safe, high quality, uncompromised, backdoor-free, unbiased random number generator :) Cheers, Joe [1]: http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf On 23 January 2016 at 19:27, Jacob Maskiewicz wrote: > The main argument I see from the RFC for deterministic ECDSA is computing k > on systems without high quality entropy sources. But any system running a > TLS stack is already going to have a high quality entropy source for > client/server randoms and IVs and such, so what's the benefit of > deterministic ECDSA here? > > -Jake M > > On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" wrote: >> >> Hi, >> >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >> >> For discussion, here's a pull request with possible language: >> >> https://github.com/tlswg/tls13-spec/pull/406 >> >> Cheers, >> Joe >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jan 23 12:16:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DFC1AD0B9 for ; Sat, 23 Jan 2016 12:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V5Jag20jvsV for ; Sat, 23 Jan 2016 12:16:32 -0800 (PST) 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 EE79F1AD0B8 for ; Sat, 23 Jan 2016 12:16:31 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 162E833D239; Sat, 23 Jan 2016 20:16:30 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Joseph Birr-Pixton References: From: Geoffrey Keating Date: 23 Jan 2016 12:16:29 -0800 In-Reply-To: Message-ID: Lines: 60 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: Cc: Jacob Maskiewicz , tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:16:33 -0000 [I guess we're top-posting...] Another benefit is that if it turns out the entropy source is broken, then if client/server random or IV is guessable, that's something that affects one connection and can be addressed for future connections by fixing the entropy source. But if k generation is broken, then that leaks the key permanently and you need to get a new one and revoke the old one, which may be difficult. Perhaps the RFC should say something to that effect? I think there's already a section in the security considerations about random number generators. Joseph Birr-Pixton writes: > Hi, > > The other benefit is being able to test that a critical code path > produces the correct answers. With randomised k, this is not really > possible. For instance, you can choose k with the top bit clear > without any obvious or externally-testable effects, except effectively > publishing your long-term private key after a large number of > signatures[1]. > > Given the history of these things, I would perhaps challenge the > assumption that all TLS stacks will have a bug-free, thread-safe, > fork-safe, high quality, uncompromised, backdoor-free, unbiased random > number generator :) > > Cheers, > Joe > > [1]: http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf > > On 23 January 2016 at 19:27, Jacob Maskiewicz wrote: > > The main argument I see from the RFC for deterministic ECDSA is computing k > > on systems without high quality entropy sources. But any system running a > > TLS stack is already going to have a high quality entropy source for > > client/server randoms and IVs and such, so what's the benefit of > > deterministic ECDSA here? > > > > -Jake M > > > > On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" wrote: > >> > >> Hi, > >> > >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > >> > >> For discussion, here's a pull request with possible language: > >> > >> https://github.com/tlswg/tls13-spec/pull/406 > >> > >> Cheers, > >> Joe > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jan 23 16:17:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B9D1B2C4F for ; Sat, 23 Jan 2016 16:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il85Krf2zNwf for ; Sat, 23 Jan 2016 16:17:32 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3BF1B2C46 for ; Sat, 23 Jan 2016 16:17:32 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l65so25181780wmf.1 for ; Sat, 23 Jan 2016 16:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JE6qt1nwvHqrr4E+N18uh6Ny4T9A6Rs24NPu3Eec20s=; b=JLzOV8kreA8M9XgBIY5rX1Vnjl6idYHOVuyYNcVpz5kpeEJFFItmWhwYdZiOhfrTYr S6vUY3YOL5x0M5Xq22KbhAd8LBOmn9Ofg3v7ZjrNHXkZcoy99S7X4p3UvTzuWXycGRvO PYyob5XuchAJJibgG6o3kmwBlBm021HdFsWE8gblVOhRJuytDlpdB7lLfpfauvqGVh5X OBXtAdCHJuLQNVgrUzxavhEytEsxxWqYFWwKmB47tiwslbFj/9sGMIZrA/RHVAxE0WNs AnB8T4/FN8wfNzg2zP64HZ8OV40t885eg0ZfuFnX+HkToKeqRziFAyfmi9QY98IgiV/4 FucA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JE6qt1nwvHqrr4E+N18uh6Ny4T9A6Rs24NPu3Eec20s=; b=akvPP5cVUN9NVcZICyNBy6aEsTUUHwpQ+ci/BLtDjvN3w70qkZ2BnAnqM9d14vk9TN bTBQbd1mvUWDdJzbUinirPaR2w+YOmSKqvlaqrf/1QcBJYgu+hi88A6VKpt8j0ADnwzt cDlHQoHv4YROMDAQ9hjZNCI7wY10FyEfmZu9+he6CXFvTed7ykXCJZuKoWEh5eUji8Oj 9vJ5dUu4uh3lQfSJlB7wPZSwMlqLDH0kjnjHuB4wvvaJ8Ai28NqHAxAzSdgUoHYAmVbE fLGH5hqHsJuomJ5bd8GjNSXeLtN9ksE+nGiDQ45wI24MSUcwJoHYRAYmWE2DOlgKeoHc GiSg== X-Gm-Message-State: AG10YOS24yH/NIMvS8BC93lHNooh8Ri/9Aw/U/QPvsz5k5FC0G/xHNIaQ2QRoPw+qbDAuQ== X-Received: by 10.194.241.228 with SMTP id wl4mr10139031wjc.11.1453594651075; Sat, 23 Jan 2016 16:17:31 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id w80sm9296692wme.17.2016.01.23.16.17.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Jan 2016 16:17:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Sun, 24 Jan 2016 02:17:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> References: To: Joseph Birr-Pixton X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Jacob Maskiewicz , tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 00:17:35 -0000 Also if the signatures are done in a separate hardware module, that = module is even less likely to have a good random source.=20 And if we make it rely on external input for the random, that=E2=80=99s = a good way of getting it to reveal information about the private key, = whereas keeping the private key secret forever was the whole point of = using a hardware module. So that=E2=80=99s another argument in favor of deterministic signatures. Yoav > On 23 Jan 2016, at 9:59 PM, Joseph Birr-Pixton = wrote: >=20 > Hi, >=20 > The other benefit is being able to test that a critical code path > produces the correct answers. With randomised k, this is not really > possible. For instance, you can choose k with the top bit clear > without any obvious or externally-testable effects, except effectively > publishing your long-term private key after a large number of > signatures[1]. >=20 > Given the history of these things, I would perhaps challenge the > assumption that all TLS stacks will have a bug-free, thread-safe, > fork-safe, high quality, uncompromised, backdoor-free, unbiased random > number generator :) >=20 > Cheers, > Joe >=20 > [1]: = http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2= 014.pdf >=20 > On 23 January 2016 at 19:27, Jacob Maskiewicz = wrote: >> The main argument I see from the RFC for deterministic ECDSA is = computing k >> on systems without high quality entropy sources. But any system = running a >> TLS stack is already going to have a high quality entropy source for >> client/server randoms and IVs and such, so what's the benefit of >> deterministic ECDSA here? >>=20 >> -Jake M >>=20 >> On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" = wrote: >>>=20 >>> Hi, >>>=20 >>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic = ECDSA. >>>=20 >>> For discussion, here's a pull request with possible language: >>>=20 >>> https://github.com/tlswg/tls13-spec/pull/406 >>>=20 >>> Cheers, >>> Joe >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jan 23 16:47:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA97E1B2CDD for ; Sat, 23 Jan 2016 16:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnJec0n2rD0l for ; Sat, 23 Jan 2016 16:47:08 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 680E01B2CDC for ; Sat, 23 Jan 2016 16:47:08 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id e32so85670549qgf.3 for ; Sat, 23 Jan 2016 16:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=b6nTPYB2J078vUBP0TiVxm//DsjAHA80HXuQBHEPkCo=; b=Wt17L1p6GY4D58ckSvDZSwlDPuupUgdoZHIpMsNdLZuwTSsKE5LNuf6G2iFclj3G78 lAqg/QbMInkntkh+//tqKWDg+Kc1uyatj/W7vrkkp4xrbvr1GoocjHho2X1mcmzHXsYI QEgHETqXJhYBVy1rfs9IaEDpHKaqxnwDVyKAfiG0bRTxn6MGYTPPiejJxBc9uhq+6IJc +J1UzbFzcHtkBM8pz6pi1ovzlgqoQKctPpbuYAJrYPC8OymG5UpdjRaw92jS8R/YaxWb yeJR+xbWcmRqEASDhRRmYk/VJGb5XraC+yw8SZTTQ9JMzb5TT0niphKxUgGWXFbvdBeF a2yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=b6nTPYB2J078vUBP0TiVxm//DsjAHA80HXuQBHEPkCo=; b=PlZ2o0kc1HW8qfoSfXHxhwP41ud5bXjU3j3Bv2ufw2BaXQwdPIngrUaCGafP+rPRL+ aiSIFszvYNLHCID34UBaSgqFVcccNaNtSBltqnbFOgoIwQ4kW9ry+RmYQ7eMiIiXaynv n2CcQjwxuRmmzFU+ubbxk5tQxqWmb6VAX81SmpAWfGrcN7oA+0nosnfvtEkUhY8ILnV6 YrFK29dIDYP0YqW1tfOTYiA/U0/xyYVJ1IKh3qXVOkZruQF7xfrejKvjmEWRk5Urx8Mc C9fwKC3BfSL3Mdu10k1fpTENqd/52rpW47aNPbQTCjr4kGd4ZLn2noj+/McBge4OYSJ/ sATg== X-Gm-Message-State: AG10YOShYoKANouYUEY0SHXL30Mia2Nbfd+ikaok72FhUla5Uz+QNUr4QDpd826ORAhWWA== X-Received: by 10.140.95.119 with SMTP id h110mr13023942qge.105.1453596427623; Sat, 23 Jan 2016 16:47:07 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:8579:2304:499a:677a? ([2601:148:c000:1bb4:8579:2304:499a:677a]) by smtp.gmail.com with ESMTPSA id z138sm5897407qhb.7.2016.01.23.16.47.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 16:47:06 -0800 (PST) To: tls@ietf.org References: From: Michael StJohns Message-ID: <56A41F0F.70609@nthpermutation.com> Date: Sat, 23 Jan 2016 19:47:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 00:47:10 -0000 On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote: > Hi, > > I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > > For discussion, here's a pull request with possible language: > > https://github.com/tlswg/tls13-spec/pull/406 > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > Correct me if I'm wrong but: 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY like they would a non-deterministic signature. 2) A receiver of an ECDSA signature cannot determine whether or not the signer did a deterministic signature. 3) A TLS implementation has no way (absent repeating signatures over identical data) of telling whether or not a given signature using the client or server private key is deterministic. All that suggests that this is a completely unenforceable requirement with respect to TLS. The above is a long way of saying that this is a WG overreach on internal security module behavior that is not central, cognizable or identifiable to a TLS implementation. I'd instead recommend you approach the CFRG and offer a internet draft with a target of BCP on the general topic of ECDSA rather than specific guidance for TLS. Mike From nobody Sat Jan 23 16:53:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA641B2CFD for ; Sat, 23 Jan 2016 16:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q85bgCSO7RA for ; Sat, 23 Jan 2016 16:53:40 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 CF70D1B2CF3 for ; Sat, 23 Jan 2016 16:53:39 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so85728314qgf.3 for ; Sat, 23 Jan 2016 16:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=HHw/MuzG4NZzTjybma8yKRS9ZgLOeSvABSxE1jWoM64=; b=RvSN6AD8Gz8CxJZ6YEt2weDdYwO9Ix/aPlWU/OBPQHsBHvn1HY2AlLgUGpyTtXp96t RA46HjDZtj6BH8Pybgl95Dezhxw7cvvnTPQ4sGk97FoT8WbG89qGIzOLCe5j+jBj8ooG nVhI46l9dYmG9qB+v6jem0ZCx5NDm97N/vP+p/fSRTQRUESiZvUW/XDjNOI67elggCor D9sCTloj4dbd0pSJACP32aympw42PcL6D+M+8sAuLECWxDGXPaXBiIgTWRDOhx35uXbI +0Fkj82lBDm4NCngF48rWu+2/JpKj81dbZGI2E3YH9/negaiEBSIOe1INcwAGGjtrJub V7cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HHw/MuzG4NZzTjybma8yKRS9ZgLOeSvABSxE1jWoM64=; b=iEs5Yauya3SrHK4Q+ZXLLB1acKaMzdVD21lZUPtRpwteyltZnYWh/6By9KWc4FMBXq I1r/EQpLjulEZtzaKzSj15RdhblqPvOSCiSfthLoBZ7+9T3SW9BFEQmEHW6N/qFnt2/l tE9oBilGBR/Q9/R5OpXhg9WsnBf66yiampChsOgwIU0RePSqa4Xea0erAQPGbgUEppAB QPhpvef/GKvkfeX8RAf/PA7GBbNeU8kePqmpDF6DnbmVOeIjTy3g7T0AJMljUHza2Zyz OPIZADELE0pqyVMh85cI//lna6td+0/OdpCUswvY1PkP3R8xHK9Mb5VyEOTi0LesnlJ4 0PrQ== X-Gm-Message-State: AG10YORfuEe+d9W73yegvT8vfJ1Bl7KYa9hYEx2zC7PS3L7ZamNKqQ+nGoz8xOE9o1czYA== X-Received: by 10.140.165.7 with SMTP id l7mr13873620qhl.101.1453596819037; Sat, 23 Jan 2016 16:53:39 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:8579:2304:499a:677a? ([2601:148:c000:1bb4:8579:2304:499a:677a]) by smtp.gmail.com with ESMTPSA id s86sm4918619qkl.36.2016.01.23.16.53.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 16:53:38 -0800 (PST) To: tls@ietf.org References: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> From: Michael StJohns Message-ID: <56A42097.5010802@nthpermutation.com> Date: Sat, 23 Jan 2016 19:53:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 00:53:41 -0000 On 1/23/2016 7:17 PM, Yoav Nir wrote: > Also if the signatures are done in a separate hardware module, that module is even less likely to have a good random source. > > And if we make it rely on external input for the random, that’s a good way of getting it to reveal information about the private key, whereas keeping the private key secret forever was the whole point of using a hardware module. > > So that’s another argument in favor of deterministic signatures. > > Yoav I tried to parse the above into meaningful A implies B logic and failed. If you have an HSM, the key that's generating the signature tends to be generated inside the HSM. If your HSM has a bad RNG, then the key generation is going to be a problem well before the signature generation RNG problem kicks in. And to clarify, a key generated inside an HSM tends to use that HSM's signature mechanism, not something in a separate module. I don't think your argument holds. "If we make it rely on external input for the random"??? Isn't that exactly what the RFC uses in the form of the hashed message? Mike > >> On 23 Jan 2016, at 9:59 PM, Joseph Birr-Pixton wrote: >> >> Hi, >> >> The other benefit is being able to test that a critical code path >> produces the correct answers. With randomised k, this is not really >> possible. For instance, you can choose k with the top bit clear >> without any obvious or externally-testable effects, except effectively >> publishing your long-term private key after a large number of >> signatures[1]. >> >> Given the history of these things, I would perhaps challenge the >> assumption that all TLS stacks will have a bug-free, thread-safe, >> fork-safe, high quality, uncompromised, backdoor-free, unbiased random >> number generator :) >> >> Cheers, >> Joe >> >> [1]: http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf >> >> On 23 January 2016 at 19:27, Jacob Maskiewicz wrote: >>> The main argument I see from the RFC for deterministic ECDSA is computing k >>> on systems without high quality entropy sources. But any system running a >>> TLS stack is already going to have a high quality entropy source for >>> client/server randoms and IVs and such, so what's the benefit of >>> deterministic ECDSA here? >>> >>> -Jake M >>> >>> On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" wrote: >>>> Hi, >>>> >>>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >>>> >>>> For discussion, here's a pull request with possible language: >>>> >>>> https://github.com/tlswg/tls13-spec/pull/406 >>>> >>>> Cheers, >>>> Joe >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jan 23 17:00:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61581B2D08 for ; Sat, 23 Jan 2016 17:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqKrdTNiyJAV for ; Sat, 23 Jan 2016 17:00:37 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 7DF761B2D07 for ; Sat, 23 Jan 2016 17:00:37 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id e32so85790313qgf.3 for ; Sat, 23 Jan 2016 17:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=RwuZOAGpPGW2/8Xt6E3+pCj1k+CUpXSmLiYOIPk0pSg=; b=syhyO2AiS8Q+1Isz//6OMEnON/nQZCILtvdu9hZQuF0vqjy1jiKS5QcE77OgB43QSu AC97M7ha+H0/Aldtza5qVYELtamFeGWKm2z0FjD8r4QFCFF81eOObSe2gqLiQNfRUifT irepD+Wl78kxya45pCO4nqG3qJSabDlC73Ujlr3E+yp9/LN/6xrE0SdaCMOKV5C2YsO9 LMwdadOvoul4IF0Olbt5m21JzuJ+sI41abSFpTsXVghYOBOyV5aSL5gtQVBIJCRTNIvY cMZYymHjOEsDYA2tmtB2dW3pw9nRbULk3pgFiy8vyzX0qL7ON8sz0YgCUb496TFYxlkS JuIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RwuZOAGpPGW2/8Xt6E3+pCj1k+CUpXSmLiYOIPk0pSg=; b=jfy82fCsiw5RxJa02keVXETuBzf02quBJng22RRe2FvN7zMxQvZm2pLq+BEBwKDcBq gHR9mEh1GfbCixZNE1OJXzjSK5t6V70UVZ9tcSWJH6YGSWw+Opj+bFA+tJ0SyctEyeTb CqFYrjgMJhn2CBgCIuZ0L6v+qAQAGtE0pjW2GxdHIYG10vGBVPBsai1xRVVEgaPp6KeU DL+zx8xqkPEmYixtdbze3SW3RuPiBOPK0m3+J54UPra5d1k1i75BaU6HBxNmXE37ekXX vH9zE6BjLp+6mWOP1NswcyVqMFRpUasGYWuvmlJ5q4StXKb2M9WdwCPIbvc8kqEAaZ+4 OQYQ== X-Gm-Message-State: AG10YORl9Z6sGvXiO5lv7dpWKBPyWO7VEmkY3ERRacwAbVQcNmBy4Ldas0BQUiRPEsBmOw== X-Received: by 10.140.180.80 with SMTP id b77mr13059004qha.67.1453597236739; Sat, 23 Jan 2016 17:00:36 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:8579:2304:499a:677a? ([2601:148:c000:1bb4:8579:2304:499a:677a]) by smtp.gmail.com with ESMTPSA id z66sm5909152qhc.16.2016.01.23.17.00.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 17:00:36 -0800 (PST) To: tls@ietf.org References: From: Michael StJohns Message-ID: <56A42238.50204@nthpermutation.com> Date: Sat, 23 Jan 2016 20:00:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 01:00:38 -0000 On 1/23/2016 3:16 PM, Geoffrey Keating wrote: > But if k generation is broken, then that > leaks the key permanently and you need to get a new one and revoke the > old one, which may be difficult. I agree that if RNG generation is broken then it breaks k generation. But if RNG generation was broken during key generation, you also have a problem. In your arguments, assuming that the RNG was fine for key generation and broken for signature generation IMHO only applies to software modules (where you have the option of using separate RNGs for different functions). For HSMs with any reasonable amount of good design, if the RNG is bad, the thing just stops working (and there are ALL sorts of tests to ensure that). With respect to a software module, I'd find it easier just to read the key bits out of memory than apply most of the other threats that seem to be creeping into the argument. Later, Mike From nobody Sat Jan 23 21:20:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654071B3D65 for ; Sat, 23 Jan 2016 21:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 AThZ60Tb--tO for ; Sat, 23 Jan 2016 21:20:49 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C41A1B3D64 for ; Sat, 23 Jan 2016 21:20:49 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id is5so93238291obc.0 for ; Sat, 23 Jan 2016 21:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9LX5I4NOHesE/6AeDBfeJwHxqFRaxlSP2qQRo5SnFIk=; b=C4BiCuwcqKnEjCimby92nBEvt0LNRguVWk79yUgs0Oecpn7JxPQVYZ7073FPGxZkAa p9tg4LRg8CO9Sxhsl6kYrYxDaSfIsgbHKD96AIdBdCnDN9jrFELn+yHdmP//S++Vb0Aq 8HPquL/gtHTbfZWXtvU2BP27OqdfUZNdepqsvDYnKx18PfL136HFQ87EQAHnj/4nrNFx WEnNRhcytgK6EA0WwQTwi0yh0P9X0feSKkBZw5wu0xjod0SO6bVrvtsOii9l+cScwLmd l92csIT+TaPeKPc0bO/fP0FqOgOGcZtIv5hY/sEQcOVvBBppFxgFk8keY7Q3BlEEKYZV sY8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9LX5I4NOHesE/6AeDBfeJwHxqFRaxlSP2qQRo5SnFIk=; b=mvmRFXo1LV7PFGRdPZqmORjuLDt31vXDuMdu78k5bydfSagwHvpOHO2ZfLUhr9mOIF zgetOtMqMA4c5tHV3cOKpfHtubzsngzQumgRw4jDcDM2vpibKNRdH2xfzWGQQ5m64AK+ o86TIqISSV9K4dmYCRQ1r4ZABHAyzfan/E39bB18xHg2PKsK00ypWPm3CFoPJ42Cq+CH gI4S0v0ZTK60u0R2byVwP/IP1g2w0IWzJO7g8hy7L8d8hUj54EEFfXmNotUlac+6VQHd Rtvu9lg60KxUU2STBNRPZ8MZMJ2Ms2iMnB88AGCkV7kbMrLM8Zjp/s5YLz4WNrftU2jj HEpA== X-Gm-Message-State: AG10YOQ8vIDb5UO3xHBmp5PjGjcbsVIX/vGFLYWoz8pe9kmd5mUIq3+SOkCX48Dpl/nfVKOBESKXM5Dfmi1pXw== MIME-Version: 1.0 X-Received: by 10.182.120.3 with SMTP id ky3mr8441488obb.17.1453612848700; Sat, 23 Jan 2016 21:20:48 -0800 (PST) Received: by 10.76.3.197 with HTTP; Sat, 23 Jan 2016 21:20:48 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 19:20:48 -1000 Message-ID: From: Brian Smith To: Joseph Birr-Pixton Content-Type: multipart/alternative; boundary=089e01229de07cf9a2052a0d9d77 Archived-At: Cc: "" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 05:20:50 -0000 --089e01229de07cf9a2052a0d9d77 Content-Type: text/plain; charset=UTF-8 Joseph Birr-Pixton wrote: > I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it also includes a random element in the SHA-512 hash. Ed25519 uses SHA-512 instead of HMAC for the same purpose and people seem to think it works fine. Also hashing in some randomness seems like it would help avoid some side channel leakage. Note that most (all the ones I've looked at for more than 5 minutes) open-source ECDSA implementations have side-channel issues of various levels of significance. Anyway, I do think that implementations should do something *like this* to avoid problems when the RNG is bad, but I think prescribing RFC 6979 as the solution is overly-specific, especially when it doesn't even seem to be the best way to accomplish the goal in many cases. Cheers, Brian --089e01229de07cf9a2052a0d9d77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jose= ph Birr-Pixton <jpixton@gmail.com> wrote:
I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.=

What about the way BoringSSL (and Open= SSL, I think) does it? It incorporates all the inputs that RFC6979 does, bu= t using SHA-512 instead of HMAC. And, it also includes a random element in = the SHA-512 hash.

Ed25519 uses SHA-512 instead of = HMAC for the same purpose and people seem to think it works fine.

Also hashing in some randomness seems like it would help av= oid some side channel leakage. Note that most (all the ones I've looked= at for more than 5 minutes) open-source ECDSA implementations have side-ch= annel issues of various levels of significance.

An= yway, I do think that implementations should do something *like this* to av= oid problems when the RNG is bad, but I think prescribing RFC 6979 as the s= olution is overly-specific, especially when it doesn't even seem to be = the best way to accomplish the goal in many cases.

Cheers,
Brian

--089e01229de07cf9a2052a0d9d77-- From nobody Sat Jan 23 23:04:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2E1A9006 for ; Sat, 23 Jan 2016 23:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiN01Wi2_npz for ; Sat, 23 Jan 2016 23:04:31 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12901A9005 for ; Sat, 23 Jan 2016 23:04:31 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id v14so130710862ykd.3 for ; Sat, 23 Jan 2016 23:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=YPAGBcWPq04jmqcsTlUHsVq6f/00w5JeHxnVyVjb/ic=; b=L/2W3jhnN1eD/nNszg2sfbaNK5llRDQIQ2Z4l+cNeKsqaMUW6oPSZpPie/dUCrB7bT FoAaDAf2BctToaVnb6gn60EL/09HOUPz9aooaPfkA0nq6Svj9iOjCilrXpsnXV+RxvGZ zpFYXNk56AClBnCnjMZR/Ng8XXtxzGCYNgfGWSMsisk/vmbduRNQ56/uAtfdXdsIuvUP ehZch5B6EBRDSQiZiMVD7e2oCWNGPYaZVAyedaUjVDuRfu4/eQsdG9eAAK3MBxNsnCc7 DR3gWGXCFQLIhpgeFwiGSAuYd9nX7a61FBF/drudNH1ELU5HDmsWV3hPKUtBejaALZ5D wHDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=YPAGBcWPq04jmqcsTlUHsVq6f/00w5JeHxnVyVjb/ic=; b=iRj4ZcE6eLjZPM2tVQYociKmep7jyYZkgueGDrTmWDH9TElZvNzJ1u4+8WM0ddKA5/ NDNSiDesRo6h91gET2HLY3mr6PknSU0KBv72GZNN+rFoVTHjnFBN9P/Oo5/VphR6gFS1 aa+TjdfPQ0DPXC80033uC6ze7d3G5R3jPS3YSHKNQsEc3pqzk8T8YZrgHyQnQa/J8ynS ebE+FkqyV7fnPtOEudcE1VKE7E+Vft6rwJO0QIhwtEWxH9/zgsr0bllhes0JoA23DrkA 9YY6cWBnKBE7vOup6RboHTu/7j0KDo39ehGepyK20AdP9ZBOx7GLXd84fcJTiRh35zyM sZWA== X-Gm-Message-State: AG10YOQW8APg9XLDUHKP0blNsQVCDE+nOlj25cW80OZ1BsS6UWKP6atRdjP6MA2yB2vgRg== X-Received: by 10.129.137.193 with SMTP id z184mr6301734ywf.257.1453619070922; Sat, 23 Jan 2016 23:04:30 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id u190sm10086372ywd.17.2016.01.23.23.04.30 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 23 Jan 2016 23:04:30 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sun, 24 Jan 2016 02:04:28 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56A41F0F.70609@nthpermutation.com> In-Reply-To: <56A41F0F.70609@nthpermutation.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201601240204.29009.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 07:04:33 -0000 On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote: > 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY > like they would a non-deterministic signature. > 2) A receiver of an ECDSA signature cannot determine whether or not the > signer did a deterministic signature. > 3) A TLS implementation has no way (absent repeating signatures over > identical data) of telling whether or not a given signature using the > client or server private key is deterministic. > > All that suggests that this is a completely unenforceable requirement > with respect to TLS. We can have unverifiable & unenforceable MUSTs. A SHOULD might be more appropriate, however, if we want to acknowledge this limitation to some degree. > The above is a long way of saying that this is a WG overreach on > internal security module behavior that is not central, cognizable or > identifiable to a TLS implementation. As far as I'm concerned, anything that directly affects the security of TLS is not an overreach. Beyond scope of control, yes, but it's not an overreach to lay out how to do things properly that commonly result in vulnerabilities with TLS. Like everything else in an RFC, it can of course be ignored, but I think it's worth it to make an official statement in the spec on how to do things properly. Dave From nobody Sun Jan 24 02:13:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF281B2D65 for ; Sun, 24 Jan 2016 02:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naaZIC1umDKr for ; Sun, 24 Jan 2016 02:13:01 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A241B2D67 for ; Sun, 24 Jan 2016 02:13:01 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b14so39697597wmb.1 for ; Sun, 24 Jan 2016 02:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wY0N5vZsh/dEqFbvOFL1f/QsUVXQ5vY+tz03NjJJX60=; b=xXJ+gAaszWztk4zV096At+sVDjT+B6aGUAdsTy2IfUSnCmBdHbQPLQKe/tvWx5Gjah eANu7SC7ByeztVtUSlb6xKAOSDY8XBOGQKzvsEO+OoHYfRV5OUM0+bHBaTtFgzqu/wru Brv3vu/3rNmm09dZqITNHAmFQgOmsRKHBm6CziQWU6UIT1J159CnZSuH6DLrVyZlXsWf qR/LlKZo7TxYu4fxecpqWv0o/e4Vplgvhhrs47u/db2aefRZkrCkNiVomKByon6v+ZHA WshGvQkqHGERpXq1lzXwuQ1Ab1H7qQN9RmvnouyxQWQmb3GYx87zV6Vt0Cqb3Ras/Er4 q4Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wY0N5vZsh/dEqFbvOFL1f/QsUVXQ5vY+tz03NjJJX60=; b=SLagHKQqSqYt9dtC93USM2KaN/CbzlaTe/rGtx02f6Syj8UKNFra7idh2OR+5dEsE3 LLyLe+kUSH6HnDZvH/fr5efAu8kVUJM9vB7Lvq6zr6/DyCQsuZVC3czfqLxUAjioxCtU oJ/3abaYdnX/+fGukf33Z85KvRWBidsJ9BOrYdobdZRPv2h3Di1clauBsaxjUKQw10Sy pzSia07RDfrhcK5v5eY4slIUTHi9hneXEZfuAD5ifllCqiYftARu2yTKIkvL6kyDmnDZ UG0aohX0Z+51OQ/lwVNKLjAno7DXiQbdZlTOgrL7vmmY7t2HkYcsEtCPAYtbzSfIKu/q apKQ== X-Gm-Message-State: AG10YOSkm8HPU6wzb4ToGXn6x5x7m7SVoOHKm1YKx3H+EuEYwYIn8MVhd1DDPoHpSbV2aQ== X-Received: by 10.194.111.232 with SMTP id il8mr13717339wjb.150.1453630379948; Sun, 24 Jan 2016 02:12:59 -0800 (PST) Received: from [172.24.248.122] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id r4sm13908717wjy.39.2016.01.24.02.12.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 24 Jan 2016 02:12:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56A42097.5010802@nthpermutation.com> Date: Sun, 24 Jan 2016 12:12:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> <56A42097.5010802@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 10:13:03 -0000 Hi, Mike > On 24 Jan 2016, at 2:53 AM, Michael StJohns = wrote: >=20 > On 1/23/2016 7:17 PM, Yoav Nir wrote: >> Also if the signatures are done in a separate hardware module, that = module is even less likely to have a good random source. >>=20 >> And if we make it rely on external input for the random, that=E2=80=99s= a good way of getting it to reveal information about the private key, = whereas keeping the private key secret forever was the whole point of = using a hardware module. >>=20 >> So that=E2=80=99s another argument in favor of deterministic = signatures. >>=20 >> Yoav >=20 > I tried to parse the above into meaningful A implies B logic and = failed. >=20 > If you have an HSM, the key that's generating the signature tends to = be generated inside the HSM. If your HSM has a bad RNG, then the key = generation is going to be a problem well before the signature generation = RNG problem kicks in. And to clarify, a key generated inside an HSM = tends to use that HSM's signature mechanism, not something in a separate = module. >=20 > I don't think your argument holds. >=20 > "If we make it rely on external input for the random"??? Isn't that = exactly what the RFC uses in the form of the hashed message? Yeah, it was way past midnight when I wrote that. Only so much coherence = in those hours. The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or = 521-bit) key. When working as part of a TLS server using regular ECDSA = it would need to generate a random k for each full handshake, and many = such servers routinely handle tens of thousands of such handshakes per = second. So it=E2=80=99s hundreds of kilobytes per second, for an HSM = that has no network input, no I/O of any kind other than the signature = requests, this may be a problem. I=E2=80=99ve seen people claim this in = the past. That last sentence there. If we=E2=80=99re using regular ECDSA, the HSM = can either generate its own k or receive a k from the caller. For our = software=E2=80=99s FIPS certification we had to support both modes to be = able to produce a predictable ECDSA. I don=E2=80=99t know, but I imagine = hardware would be required to support this as well. If you run the HSM = in production with the external random input, you=E2=80=99re making it = possible for an attacker who has compromised the system to discover the = key bits by repeatedly calling the HSM with same k=E2=80=99s for = different inputs. This is negated by using deterministic ECDSA where the = k is a function of the input. Yoav From nobody Sun Jan 24 02:15:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AA51B2D7D for ; Sun, 24 Jan 2016 02:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDhxYOpflHfX for ; Sun, 24 Jan 2016 02:15:36 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 5AECC1B2D7C for ; Sun, 24 Jan 2016 02:15:36 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id u188so33056980wmu.1 for ; Sun, 24 Jan 2016 02:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jJquiyyEVKajuLXa1MMCO5hYesc2Crc4jbVyjTa3snc=; b=cetNTuPv0J069fxZNljN6SIkgZBJRWKKug8Imqmw8pPsYXndCHrrtDXBsU0y7e/IZW lB63jXevmXhkCwIlR6XMNGdmxlFC4phN3mcggjUjVYUrGyjhNEmJwzWPnX5OTHtWZq06 52cQ9bJOcJFQsCH6j2fpMDzlvYggYJf98QghfXmVTjl64ugtqjl0n9KuW2plTreRo1mJ 4sG3R+/1ArcjYKFawx04KZ7bawGU7lQIKdCbuO1LCQxpfOfBO494Yi5R47m8BgEZA5Mp uAaI80XATEFH6e3huBIQ1DIss9n2ytXfoh021ux8YhHyROx0ZigQEs4xJDgrBk7nCfwg o+iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jJquiyyEVKajuLXa1MMCO5hYesc2Crc4jbVyjTa3snc=; b=jmioYdLpHMxgRHzNv7t3ijA6Ojoye8RaFj8RLgyQEUZpvdhYaWl0luuAuq15+R8ofL TdEGLoOCQKbzcgPcX4ZhjuX1jX4CLi2x59xIdB+g+1iI8NyxZFcOsslMRmCMKELS2fwb Ed3h46qHV84PJx1ncoJFI4VxS9ygy/+of6DQqdyHeUHTw5BquLWJVK7DK3t5oTmO/9SQ GM1y4I0zpROXjJb1zOuQEdOc0UplTnnpjy87DrfW8GZ6/T9Mr0YRdqB90/hQXq+q+98p np9lSsyaQIrnNSbVZlmF5DGul4NzgN75ag47NVboAa17ceWGGu01XjC1WRdlxNRihjyo 7psw== X-Gm-Message-State: AG10YOT/xv+k1hpVJSWlmhMcJ7GpGGT8nmSgn6i2yKpXSkbQdVsyAB4cg+rOi0vgaNN9ag== X-Received: by 10.28.30.138 with SMTP id e132mr11789426wme.86.1453630534835; Sun, 24 Jan 2016 02:15:34 -0800 (PST) Received: from [172.24.248.122] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id ka4sm13876515wjc.47.2016.01.24.02.15.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 24 Jan 2016 02:15:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56A41F0F.70609@nthpermutation.com> Date: Sun, 24 Jan 2016 12:15:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56A41F0F.70609@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 10:15:38 -0000 > On 24 Jan 2016, at 2:47 AM, Michael StJohns = wrote: >=20 > On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote: >> Hi, >>=20 >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >>=20 >> For discussion, here's a pull request with possible language: >>=20 >> https://github.com/tlswg/tls13-spec/pull/406 >>=20 >> Cheers, >> Joe >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > Correct me if I'm wrong but: >=20 > 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY = like they would a non-deterministic signature. > 2) A receiver of an ECDSA signature cannot determine whether or not = the signer did a deterministic signature. > 3) A TLS implementation has no way (absent repeating signatures over = identical data) of telling whether or not a given signature using the = client or server private key is deterministic. I might be missing something, but if k is deterministic, do we really = need to send it? Can=E2=80=99t the receiver figure it out the same way = that the sender did? I know that makes it break compatibility, but since this is TLS 1.3 = anyway, that=E2=80=99s not an issue, I think. Yoav From nobody Sun Jan 24 08:25:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA31A1AC1 for ; Sun, 24 Jan 2016 08:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtELlQ8XjLhV for ; Sun, 24 Jan 2016 08:25:02 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 79C931A1ADB for ; Sun, 24 Jan 2016 08:25:02 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id a85so137436938ykb.1 for ; Sun, 24 Jan 2016 08:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1O2MvmgGvneWi6KGUp3xJwdH1VRTMZkmyQBAbjd9Tj8=; b=BpRfsWOGewzAllMB/DJX8Pr6sBzjqXXvEJ0ktoK6UfdE0WaZ6eVWmhENb+6f/v7cA5 LpLn54b2algZ8QaFJApz+PLW/nL3t/dphF0RyrU3V762f5eHtyeDRHnTZdAbCMHc+trO J1WQYXkXaH4wxC7YChr0hhWwlF7Lx2AV3W7x1p4sg9Ebv/C8gppr81E7VSZOoHD5OXwc UF8JhPzUmFEQS0Ttjpdrr9wwlX/1M7ScnPvSvW69Wf3UZA6PyruWW/3tYJ0fhizK9Wk9 mc24lX4OXQYsIJ+VON2lt784DlXzS2/mUf0uZP3J88lll45ctcLMeLw+KZWqSMXckNdX yH0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1O2MvmgGvneWi6KGUp3xJwdH1VRTMZkmyQBAbjd9Tj8=; b=GWfqveNXJJU6swdwZ5rJ9YOLam9BA41iEbSf9O5Zfysp2VMV+Mcjt32JvwA9FIB3R5 YoxdBtG0tfhXi6yRZsiblN5KcvoLVTtTjZFf5Pc6zyI2ovvJG3zPDjOfI6w7owZa1RoH Z63cj3O50gzXqEcWJ/j+rwNOkKwQ/9uyN+RM6idni1Rbk6uOf4a0ZnXhJwW+A/IwE+Gu e2saNvgHE+6JIIKfE2ymH2+VVk+g5xS3PVw0vx7ctfW94lQ/YbMFyUr6z9uQGsLWybdx 6I3T602Ukbax4LzR6dsmTBmlr0bRrY/JOPx6QCgfWn8gIOh39Yu13UpZLxtRb+cByN4Q wDxA== X-Gm-Message-State: AG10YORR3HaUjJibFTqGnLu8+Z11xQ1jsuH9VZuidi0PfaY0gaGx+BCjlrgGNUSYyWfkHrQ3IOC8x61u1YzQ4w== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr6211110ywa.244.1453652701470; Sun, 24 Jan 2016 08:25:01 -0800 (PST) Received: by 10.13.216.150 with HTTP; Sun, 24 Jan 2016 08:25:01 -0800 (PST) In-Reply-To: References: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> <56A42097.5010802@nthpermutation.com> Date: Sun, 24 Jan 2016 08:25:01 -0800 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 16:25:04 -0000 On Sun, Jan 24, 2016 at 2:12 AM, Yoav Nir wrote: > Hi, Mike > >> On 24 Jan 2016, at 2:53 AM, Michael StJohns wro= te: >> >> On 1/23/2016 7:17 PM, Yoav Nir wrote: >>> Also if the signatures are done in a separate hardware module, that mod= ule is even less likely to have a good random source. >>> >>> And if we make it rely on external input for the random, that=E2=80=99s= a good way of getting it to reveal information about the private key, wher= eas keeping the private key secret forever was the whole point of using a h= ardware module. >>> >>> So that=E2=80=99s another argument in favor of deterministic signatures= . >>> >>> Yoav >> >> I tried to parse the above into meaningful A implies B logic and failed. >> >> If you have an HSM, the key that's generating the signature tends to be = generated inside the HSM. If your HSM has a bad RNG, then the key generati= on is going to be a problem well before the signature generation RNG proble= m kicks in. And to clarify, a key generated inside an HSM tends to use th= at HSM's signature mechanism, not something in a separate module. >> >> I don't think your argument holds. >> >> "If we make it rely on external input for the random"??? Isn't that ex= actly what the RFC uses in the form of the hashed message? > > Yeah, it was way past midnight when I wrote that. Only so much coherence = in those hours. > > The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or 52= 1-bit) key. When working as part of a TLS server using regular ECDSA it wou= ld need to generate a random k for each full handshake, and many such serve= rs routinely handle tens of thousands of such handshakes per second. So it= =E2=80=99s hundreds of kilobytes per second, for an HSM that has no network= input, no I/O of any kind other than the signature requests, this may be a= problem. I=E2=80=99ve seen people claim this in the past. Standard conjectures in cryptography imply that counter mode for short messages is indistinguishable from random data. A device with 256 random bits can create a long random key . Maybe the issue is the HSM isn't made by people who know the first thing about cryptography, who believe the widely peddled nonsense about entropy. > > That last sentence there. If we=E2=80=99re using regular ECDSA, the HSM c= an either generate its own k or receive a k from the caller. For our softwa= re=E2=80=99s FIPS certification we had to support both modes to be able to = produce a predictable ECDSA. I don=E2=80=99t know, but I imagine hardware w= ould be required to support this as well. If you run the HSM in production = with the external random input, you=E2=80=99re making it possible for an at= tacker who has compromised the system to discover the key bits by repeatedl= y calling the HSM with same k=E2=80=99s for different inputs. This is negat= ed by using deterministic ECDSA where the k is a function of the input. The whole point of HSMs is to protect keys, by denying the ability to use the API in ways that reveal keys. Providing k along with the message breaks that entirely. > > Yoav > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Jan 24 09:19:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1321A1F70 for ; Sun, 24 Jan 2016 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CdHkSb-JuI5 for ; Sun, 24 Jan 2016 09:19:17 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8A21A1EF7 for ; Sun, 24 Jan 2016 09:19:17 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E357720275 for ; Sun, 24 Jan 2016 12:19:16 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 24 Jan 2016 12:19:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=filippo.io; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=oogGE TEaDOYE6v1kZ7H8lS7BkxU=; b=PRGxo262ksF/W1gTBnwF4wiDQn7EnhKoLGe9I hEDMdgb082ZtQIWqDK6ub/aTsj3YHZWJe4Pwcaa6T4xOIc79IK98dPP8/gnvC1tS XD8Kct+w0FMDaWYEAdPgicfLUqKSWHeuzJPKRYtq7NK28j4Y9SBDICu0HY/JoZRD OQeL2k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=oogGETEaDOYE6v1kZ7H8lS7BkxU=; b=Q5PYt dF1E48rR6Uk/YC17kOxX27y7XFt7WGDseh3bw2gLtMuQn6tBpB1F2b5xDR7dbmpw 6HhI2oY0d5jxYyys7PNM5sRhmLdjGC40+w5J2uzoUQ4b1+nXJNNGgAB0XRtU9+R2 bdHPiyq28srdl9WQXGoky8XndSEU70LduLwXrQ= X-Sasl-enc: lag0bt+c/uXGWGBsw0rbuun8KmauxYn46yI3Ttoj31ek 1453655956 Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D923680147 for ; Sun, 24 Jan 2016 12:19:16 -0500 (EST) Received: by mail-yk0-f174.google.com with SMTP id u68so9234070ykd.2 for ; Sun, 24 Jan 2016 09:19:16 -0800 (PST) X-Gm-Message-State: AG10YORc4Qlzj60GxYu+k/ByQ+21Wcd1PFBLHQdZYljIKJTmj55dAy5xS0WI1Lt2aCspBE0B4LI+wWVYvY0tFg== MIME-Version: 1.0 X-Received: by 10.37.87.65 with SMTP id l62mr6592124ybb.113.1453655956427; Sun, 24 Jan 2016 09:19:16 -0800 (PST) Received: by 10.37.223.87 with HTTP; Sun, 24 Jan 2016 09:19:16 -0800 (PST) In-Reply-To: References: Date: Sun, 24 Jan 2016 17:19:16 +0000 X-Gmail-Original-Message-ID: Message-ID: From: Filippo Valsorda To: Joseph Birr-Pixton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 17:19:19 -0000 Strong support for this. TLS will be deployed with broken implementations and on broken systems. Anything the spec can do to limit or prevent damage is more than appropriate. However, agreed that a SHOULD makes more sense, to avoid having discussions about OpenSSL not being compliant because of a different PRF. I've always been puzzled by pure-random ECDSA deployments anyway. On Sat, Jan 23, 2016 at 7:13 PM, Joseph Birr-Pixton wrote: > Hi, > > I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > > For discussion, here's a pull request with possible language: > > https://github.com/tlswg/tls13-spec/pull/406 > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Jan 24 10:08:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794DA1A1ACA for ; Sun, 24 Jan 2016 10:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8mgjRVy_Bh5 for ; Sun, 24 Jan 2016 10:08:36 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 44AC11A1A7B for ; Sun, 24 Jan 2016 10:08:35 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id 6so93679118qgy.1 for ; Sun, 24 Jan 2016 10:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=5MnTyFJQPTN7T7ZeMbwVJ294yWtJlbHjs833A+yvsx4=; b=z6CUji4z3++dlZJWWMUKwkE6sVjEwuNyWtPTLNFy1BNV1oYk/lnTtr5YOLhrqFqRZf tRPVd7DEPN9nfLikEowrYGSFUR4CjQ6rO8eb7rbeixQTYcBOwMIY+CJe/iVBZ4KQrQfW xxVwZgZv9FcLkwtOUfZJLKVxr3gz9mi/dcdgsQUFOj9PlL9uxcn3V84IXdiKo5MEzJgu gTMPDTHRrfs3nnEtCaTZSWK7UyUC6ddeuVWQbChEQt/P0yL+XFLcfMbZ7F6O7E6rn9Bv VglldzCWdB3hKAWpMSFB6EHLS8LnCXlLqd2xY2vpCR/jl5hJGe+iRP7cPtVQN/gZjnDA MU2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5MnTyFJQPTN7T7ZeMbwVJ294yWtJlbHjs833A+yvsx4=; b=MasxyjWhrfezD1Z+0u8B19iCIUJzad5RP9rhpWy2SH6SoFoqT4bQKXE6uNSdwummDY 8f4M49YVDXT9ZfupnumOGhTID3ImjU9GiHzSXngCwsV3yK7eseD4bHsmBZSrQpfT8gc7 xXSYLMqwba/x3L3ve/zcd3YuCmN6lSWI+8OdMyXgohdRRHLduYbfKfyh955jIuSxY4E5 b5ogVPJNF1/yp1AhZPq4MCquxpuGcLnKrPGvjtwAcYgV7kqt8Wz5DWM8LuRMYxoyNJhS XzKqdMeIlGdTZVad71vDyJ6Rq0eJ0AFVqGc2LfzeM2x+/IsBX5hx/x7J8o334DDNNFlD zpWg== X-Gm-Message-State: AG10YOQc6P7jBQ06r5WyQgMPXJiZmIK87LJP496XaV7od7QvE9tHqJhwvfayfaM/gFMRzg== X-Received: by 10.140.100.141 with SMTP id s13mr16021999qge.25.1453658915065; Sun, 24 Jan 2016 10:08:35 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:49cd:a64a:bc7e:4016? ([2601:148:c000:1bb4:49cd:a64a:bc7e:4016]) by smtp.gmail.com with ESMTPSA id e11sm7234891qkb.39.2016.01.24.10.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 10:08:34 -0800 (PST) To: Yoav Nir References: <56A41F0F.70609@nthpermutation.com> From: Michael StJohns Message-ID: <56A51327.2020406@nthpermutation.com> Date: Sun, 24 Jan 2016 13:08:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 18:08:37 -0000 On 1/24/2016 5:15 AM, Yoav Nir wrote: >> >Correct me if I'm wrong but: >> > >> >1) A receiver of an deterministic ECDSA signature verifies it EXACTLY like they would a non-deterministic signature. >> >2) A receiver of an ECDSA signature cannot determine whether or not the signer did a deterministic signature. >> >3) A TLS implementation has no way (absent repeating signatures over identical data) of telling whether or not a given signature using the client or server private key is deterministic. > I might be missing something, but if k is deterministic, do we really need to send it? Can’t the receiver figure it out the same way that the sender did? > > I know that makes it break compatibility, but since this is TLS 1.3 anyway, that’s not an issue, I think. > > Yoav > Hi Yoav If K is known and the signature is known then the private key is known. The particular method the RFC uses to create the signature is to incorporate the signing private key as part of the input to the pseudo-random generation of K (along with the message). The receiver doesn't have the private key and so can't derive K (which is a *GOOD* thing - see the point above. :-) ) Mike. From nobody Sun Jan 24 10:24:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3881AC423 for ; Sun, 24 Jan 2016 10:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK7E0rNcVEVy for ; Sun, 24 Jan 2016 10:24:54 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 536B51AC422 for ; Sun, 24 Jan 2016 10:24:54 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id o11so94004308qge.2 for ; Sun, 24 Jan 2016 10:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Xb3P0IUbqrAgiqMKaUo/T4XSZngEN7a40HfrFKZwZOg=; b=ipdGNZGRUKrZoCCofGSb/U1KamBHAm60mBWaoJenyshnlOuJ5L/BMlBVH4gjIv5hjh Hvv0Px0snlLdEcqGycO8D0nwJQBLdy5X6U1AdTTvOm6vlBDWnKcc9C6PziRQ0mJQHSzE xLTZnVwTWzimz+8eNwZcT29agHt3brwErK2Z5rkDZP96HdmxO2qlMtpt8MZH9XAN39FQ aSl2+0Z0W8N5wcNtVJEIhhTgYPAEuzBx0MCCeiJANn0bzTnDE1Gk4auK8K0N041VKQ/L N+dDrbwPojMifbOqVh70zRRB2pQ/WNR/5n44j4B1O6mhm59ca53leCCV6Wuv7CDVP1lC EdJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Xb3P0IUbqrAgiqMKaUo/T4XSZngEN7a40HfrFKZwZOg=; b=DcVeyHPQMXrN3DlFphz2dcZTERwe84gVUalAGUdWVSC7xh8SYL31MNNdibvw82oCzC EzaBZBodzIPTIoDDattFQ5YCc5WbiAH35FP90Dh5XthLjVhc3SUpO38XLOx9xvVdt7ZF 64LOFp3J/mwixdL+BNb8iihGVhWlWgxRpsP/SXXtlM8Uc7mtXcFnHESGj2RSnFSs4lSX h+gb7/HwAOU1Xi4WhKRxVnoywUGm90UcQWm90YfwUuaCXSWqbOmjpiJIfEQDycGUxcwM tfo5mfwUhzjL3UWNnjD0Ie0a0cfG2BrZr1X9heW8w7UK6VFnKI3GF+N2xPKIHDa+fdeb BjnQ== X-Gm-Message-State: AG10YOQgNi3irASQoDR1Y1bQLXsf+m25LEreYh76jXBN2DvBYedQrWlnJ/iIW/2v/7kpjQ== X-Received: by 10.140.236.68 with SMTP id h65mr17665646qhc.13.1453659893557; Sun, 24 Jan 2016 10:24:53 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:49cd:a64a:bc7e:4016? ([2601:148:c000:1bb4:49cd:a64a:bc7e:4016]) by smtp.gmail.com with ESMTPSA id c126sm7196736qhc.40.2016.01.24.10.24.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 10:24:53 -0800 (PST) To: Yoav Nir References: <07742742-5517-4A94-9462-E41F4C3EB6FD@gmail.com> <56A42097.5010802@nthpermutation.com> From: Michael StJohns Message-ID: <56A516FA.3060708@nthpermutation.com> Date: Sun, 24 Jan 2016 13:24:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 18:24:56 -0000 On 1/24/2016 5:12 AM, Yoav Nir wrote: > The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or 521-bit) key. When working as part of a TLS server using regular ECDSA it would need to generate a random k for each full handshake, and many such servers routinely handle tens of thousands of such handshakes per second. So it’s hundreds of kilobytes per second, for an HSM that has no network input, no I/O of any kind other than the signature requests, this may be a problem. I’ve seen people claim this in the past. This *really* isn't how most HSMs work. They mostly have TRNGs (True Random Number Generators) aka Hardware RNGs based on noisy diodes or ring oscillators or some such (e.g. no stupid linux like entropy source from keyboard motion or network interrupts). This gets fed into a PRBG construct - something like the ones in SP800-90A. Which does the entropy expansion/extraction to get you pretty much any number of bits you want of good quality randomness in plenty of time to do handshakes. There's actually a cool set of USB devices that provide *very* good TRNG. Take a look at http://ubld.it/products/truerng-hardware-random-number-generator/ or http://ubld.it/ and the drivers (or internal logic) feed what they get from the TRNG into a good PRBG. I've been playing with using them as an augmentation of how I generate keys. If you're stuck on commodity hardware (e.g. intel motherboard) and worried about randomness, there's also this: https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide. Later versions of the intel platform have a TRNG embedded in them as well as an SP800-90A PRBG. One of the things about FIPS and RNGs is that there is a pretty good set of requirements AND tests that can be used to establish just how good of an RNG source you have (and provide pretty good error detection and fail logics). Later, Mike From nobody Sun Jan 24 12:04:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772D91B321E for ; Sun, 24 Jan 2016 12:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHhYHeoO3jfz for ; Sun, 24 Jan 2016 12:04:50 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 5E4381B321C for ; Sun, 24 Jan 2016 12:04:50 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id e32so95692318qgf.3 for ; Sun, 24 Jan 2016 12:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=Vu1nS/FrhbHBiRqMdmMiNrY/RFOJC6v2iyhdhJn/e+w=; b=1PCyznvIQgPaM1NbOX6xibuB/IZWrc8bKoN7NCLiTGs6UbIvCDkjC/DFaLIDAAcOD5 eYXnPXDHp06Yy9HoS47RiSYmFT1q+cr9c75DFiVhG4IgCw4yFEHNTGk5MMPsWM9+dAyh HpHGvBlRY5AoTd77t1VpvGg6sk98VDX3wybYt/2sND+r5xDduF2hCwy2JbP45k+LgdR3 dXectsBHbqXknPwmI35weqjUEnL03ra70Ran1agx6lHjhgMXLVodiOKAZZiJ/pwx6bQR RSI+97fyN090mTNXitEI5jYpwiv+as/C6q2TFKwmNayQpAl7orfcqmG2m2nXgExMG39z sJcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=Vu1nS/FrhbHBiRqMdmMiNrY/RFOJC6v2iyhdhJn/e+w=; b=U9xc1qPpm8OCJGX7gM8itXU0Y/7+Puw6HqfPL2Ov0HJYjp0P80vzwufoSIYBsO1S2E eu1hQ3IoQGuiKxUbB/2Gait85WlsQtYmaiUsU3zZDbK5W3HZdyspYqQX6NI8iY2OZ421 M1u0Jd4maZRLuJYMUWDSXNcL4K0cEuHAYgFX5CfeiWqboJl3DmHn7qsfWE+Ia3o4nGb2 sMG9ZqwVIGuJM8WdMff2eyDrX1fHNa1/2Tfs+33GocRfY77668hv5KDX+WSmt7pM2rZV e0Z8WyqPKUCy1uYwtQ91+niReD5pB1oZxFS6J3uxw1oZKmMmvEmEGwSQQj1XwDV4ERoa jlmw== X-Gm-Message-State: AG10YOTlKjzPGtGavdGMQXRjRu+acfuLErQjSMIiO11Z10KIiCfl9fZuq9gFdcWpahcMgw== X-Received: by 10.140.229.72 with SMTP id z69mr17125598qhb.104.1453665889563; Sun, 24 Jan 2016 12:04:49 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:49cd:a64a:bc7e:4016? ([2601:148:c000:1bb4:49cd:a64a:bc7e:4016]) by smtp.gmail.com with ESMTPSA id z138sm7352469qhb.7.2016.01.24.12.04.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 12:04:49 -0800 (PST) References: <56A42E75.8030108@nthpermutation.com> To: "tls@ietf.org" From: Michael StJohns X-Forwarded-Message-Id: <56A42E75.8030108@nthpermutation.com> Message-ID: <56A52E66.6020202@nthpermutation.com> Date: Sun, 24 Jan 2016 15:04:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A42E75.8030108@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------030508030806090907070307" Archived-At: Subject: [TLS] Fwd: Re: Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jan 2016 20:04:52 -0000 This is a multi-part message in MIME format. --------------030508030806090907070307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry - I hit the wrong "reply to" button. -------- Forwarded Message -------- Subject: Re: Require deterministic ECDSA Date: Sat, 23 Jan 2016 20:52:53 -0500 From: Michael StJohns To: Geoffrey Keating On 1/23/2016 8:05 PM, Geoffrey Keating wrote: > Michael StJohns writes: > >> On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote: >>> Hi, >>> >>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >>> >>> For discussion, here's a pull request with possible language: >>> >>> https://github.com/tlswg/tls13-spec/pull/406 >>> >>> Cheers, >>> Joe >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> Correct me if I'm wrong but: >> >> 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY >> like they would a non-deterministic signature. >> 2) A receiver of an ECDSA signature cannot determine whether or not >> the signer did a deterministic signature. >> 3) A TLS implementation has no way (absent repeating signatures over >> identical data) of telling whether or not a given signature using the >> client or server private key is deterministic. >> >> All that suggests that this is a completely unenforceable >> requirement with respect to TLS. > A test suite can easily determine, if it knows the private key in use > by the implementation under test, whether that implementation is > generating RFC 6979 deterministic signatures or not. That seems to me > an adequate enforcement mechanism. Um.. not really. The actual worked example is FIPS. There are lots of FIPS TLS implementations and they all go through testing (your proposed enforcement mechanism), and there is exactly NO way for one FIPS implementation to ensure that it is talking to another FIPS implementation. The best they can do is limit the offer and acceptance of specific crypto suites. MUST or "Required" in IETF parlance is usually reserved for choices that have to be made to have interoperable products. Neither FIPS nor deterministic ECDSA rise to that level. FIPS at least recognizes that and imposes its requirements on the buyers (US Gov't and US Gov't contractors) who then ask for FIPS capable products. And people who want to sell to the government then make FIPS capable products that ... wait for it... interoperate with non-FIPS products. From 2119: > In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. Or would you argue that I'm misinterpreting the above and the impact of your suggested change? (Um.. in the above "causing harm" has usually been interpreted to mean "harm to the network" - not preventing stupidity in implementation). Later, Mike --------------030508030806090907070307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Sorry - I hit the wrong "reply to" button.


-------- Forwarded Message --------
Subject: Re: Require deterministic ECDSA
Date: Sat, 23 Jan 2016 20:52:53 -0500
From: Michael StJohns <msj@nthpermutation.com>
To: Geoffrey Keating <geoffk@geoffk.org> 


On 1/23/2016 8:05 PM, Geoffrey Keating wrote:
> Michael StJohns <msj@nthpermutation.com> writes:
>
>> On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote:
>>> Hi,
>>>
>>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>>>
>>> For discussion, here's a pull request with possible language:
>>>
>>> https://github.com/tlswg/tls13-spec/pull/406
>>>
>>> Cheers,
>>> Joe
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> Correct me if I'm wrong but:
>>
>> 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY
>> like they would a non-deterministic signature.
>> 2) A receiver of an ECDSA signature cannot determine whether or not
>> the signer did a deterministic signature.
>> 3) A TLS implementation has no way (absent repeating signatures over
>> identical data) of telling whether or not a given signature using the
>> client or server private key  is deterministic.
>>
>>    All that suggests that this is a completely unenforceable
>> requirement with respect to TLS.
> A test suite can easily determine, if it knows the private key in use
> by the implementation under test, whether that implementation is
> generating RFC 6979 deterministic signatures or not.  That seems to me
> an adequate enforcement mechanism.

Um.. not really.   The actual worked example is FIPS.   There are lots 
of FIPS TLS implementations and they all go through testing (your 
proposed enforcement mechanism), and there is exactly NO way for one 
FIPS implementation to ensure that it is talking to another FIPS 
implementation.  The best they can do is limit the offer and acceptance 
of specific crypto suites.

MUST or "Required"  in IETF parlance is usually reserved for choices 
that have to be made to have interoperable products.  Neither FIPS nor 
deterministic ECDSA rise to that level.    FIPS at least recognizes that 
and imposes its requirements on the buyers (US Gov't and US Gov't 
contractors) who then ask for FIPS capable products. And people who want 
to sell to the government then make FIPS capable products that ... wait 
for it... interoperate with non-FIPS products.

>From 2119:
>   In particular, they MUST only be used where it is
>     actually required for interoperation or to limit behavior which has
>     potential for causing harm (e.g., limiting retransmisssions)  For
>     example, they must not be used to try to impose a particular method
>     on implementors where the method is not required for
>     interoperability.

Or would you argue that I'm misinterpreting the above and the impact of 
your suggested change?

(Um.. in the above "causing harm" has usually been interpreted to mean 
"harm to the network" - not preventing stupidity in implementation).

Later, Mike


--------------030508030806090907070307-- From nobody Mon Jan 25 03:42:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A91A8ABC for ; Mon, 25 Jan 2016 03:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypfAk8Y3hVta for ; Mon, 25 Jan 2016 03:42:51 -0800 (PST) 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 5C60E1A8ABB for ; Mon, 25 Jan 2016 03:42:51 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 871ED461D3; Mon, 25 Jan 2016 11:35:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-119.brq.redhat.com [10.34.0.119]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0PBZquu008790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 06:35:54 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 25 Jan 2016 12:35:47 +0100 Message-ID: <1540862.6uNngKyjAe@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <201601240204.29009.davemgarrett@gmail.com> References: <56A41F0F.70609@nthpermutation.com> <201601240204.29009.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2289885.CzIHCMqGrI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 11:42:52 -0000 --nextPart2289885.CzIHCMqGrI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 24 January 2016 02:04:28 Dave Garrett wrote: > On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote: > > 1) A receiver of an deterministic ECDSA signature verifies it > > EXACTLY > > like they would a non-deterministic signature. > > 2) A receiver of an ECDSA signature cannot determine whether or not= > > the signer did a deterministic signature. > > 3) A TLS implementation has no way (absent repeating signatures ove= r > > identical data) of telling whether or not a given signature using > > the > > client or server private key is deterministic. > >=20 > > All that suggests that this is a completely unenforceable > > requirement > > with respect to TLS. >=20 > We can have unverifiable & unenforceable MUSTs. A SHOULD might be mor= e > appropriate, however, if we want to acknowledge this limitation to > some degree. a MUST is only necessary if you are not sure or simply know that your=20= RNG is broken, if you're doing a HSM implementation you know that your=20= RNG is good so you can just use it and while we can have unverifiable MUSTs, it just looks silly if you do= ,=20 especially if the other way of doing things is just as interoperable,=20= and just as secure (if implemented properly) as the mandated one... SHOULD with explanation why it's there is definitely better approach =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2289885.CzIHCMqGrI 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 iQIcBAABCgAGBQJWpgiTAAoJEJKo0bgB0vX16VcP/2VimPaH1dtSgxt423UhDnZu wJJyB1xzu4VYdwhkp3fBAq060DYvw5/mdan7I09m4XgMB2go3WHORmyuR9FFmaPm bCE3+Ga0BpWkhRVbHsfz7kaG88gDWy5T+xcITcZoIMG6i8AYIKLuzE0h2NSnf9pc VnuxvlAtOoudPkn9hDdiWDMuoTYlukXhAlJb1W+V73UdUWUBa23WMdDUK6Gl7+cd tsLQ+1ZztDNO1snyubWq2Ivlti45PLqF5TyHobxogItVtWQy6l6tCxir4JbHrpei 4B5EleOHOCPvUuSNJ99I6s1XweyZf1puEyb/JNJsjc+EcRkeEttOYAPAi5kLMtev PMCHDdBsQZ4YHqMvDvnihukg+4Q5bbOEIQ0QeAaGs6yc8c/Uu56ky6wQQcXr9ml8 RCFMu/Ftds+4fSSsDzIzJpoXY4otWrGzuEnwyHYydrIGChdgV54FNdgUnka/67+C UZywFD9kO0pTDVunabbxz8ZUc2Nx3eDYJ0K3c8xW9LGrhenxGUZEjWxBCO/Ix0ph wHhueYBKjvIvTkHj+wnSQHsLXEf5ggAjZ3xSIBlh99hdWeKJdDIfVl7waJqra98j atUtaGBsNsecitmJnx1Ol8sf0zfAgMgqByEPmNq3d27OToHryLFk+Ku3H3PtaKP+ oU89OKkN83gTXHNIfuEc =NeA7 -----END PGP SIGNATURE----- --nextPart2289885.CzIHCMqGrI-- From jmaskiew@eng.ucsd.edu Sat Jan 23 11:27:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBE1AC3B6 for ; Sat, 23 Jan 2016 11:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 uyJnwqE2TkcD for ; Sat, 23 Jan 2016 11:27:37 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 96E751A92FF for ; Sat, 23 Jan 2016 11:27:37 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id z14so11838976igp.0 for ; Sat, 23 Jan 2016 11:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H1/QdHuGi9xStckkWXd2SrLyN5EKXt6+HXTK8SBooF0=; b=hy5z7k9erLzC2HwVPSkcdWXW3HximYdD7LudLOxrDs5aEGFznk0HLs8wHvQYpCuX0F bjBeKSwIBP/NbSv7okkW7e6x9elDLnKzYhB2/xOg3cIW+lWr+TNXiWo15RDMcQrLqRl+ Cxl5Bho6buWBDtzpNybBXj198k+CYHyVnauxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H1/QdHuGi9xStckkWXd2SrLyN5EKXt6+HXTK8SBooF0=; b=UjyGBYyRRRs9Dk0NWKiqc5PRaghKk2dJfCpPufMe8v3uFGDraPprmCbFpPz6FQAtGn 2jJd64GflxuiW4kQpVSdL7oEYeT7CO/jzQ79inBOJv0GbJxVuLoIf9MQfEa63wbYwUoD 1wZGWlnnUhivGf0tVPR6f1JkTW9fKzOwmzAUw6OTT18WlqdutNrEoUniE0OCmhsZrgFG 1DVVt7522JBnB0h1T8U7cGd2sY+e4f3AIgg6g+DTx/HxuSJDq04bWMp6iMZgdVUciisZ f0sGVdHm5j59aMonQhZEzpztLXSeVpg8sf3/PKLodUfXJ9uAFDAZBNeT2bYWsjSfKEQk b0Eg== X-Gm-Message-State: AG10YORoxmYdtyf6Q0D/gLAdYORysCz2aVYqA2MWv9fGxdwipJaA64RXb0T9SVWY8C2DFyx3sMkI/3yTb3EyM+5F MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr10112356ige.58.1453577256618; Sat, 23 Jan 2016 11:27:36 -0800 (PST) Received: by 10.64.2.194 with HTTP; Sat, 23 Jan 2016 11:27:36 -0800 (PST) Received: by 10.64.2.194 with HTTP; Sat, 23 Jan 2016 11:27:36 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 11:27:36 -0800 Message-ID: From: Jacob Maskiewicz To: Joseph Birr-Pixton Content-Type: multipart/alternative; boundary=047d7bd6b02008ef97052a055450 Archived-At: X-Mailman-Approved-At: Mon, 25 Jan 2016 07:07:26 -0800 Cc: tls@ietf.org Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:28:18 -0000 --047d7bd6b02008ef97052a055450 Content-Type: text/plain; charset=UTF-8 The main argument I see from the RFC for deterministic ECDSA is computing k on systems without high quality entropy sources. But any system running a TLS stack is already going to have a high quality entropy source for client/server randoms and IVs and such, so what's the benefit of deterministic ECDSA here? -Jake M On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" wrote: > Hi, > > I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > > For discussion, here's a pull request with possible language: > > https://github.com/tlswg/tls13-spec/pull/406 > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bd6b02008ef97052a055450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The main argument I see from the RFC for deterministic ECDSA= is computing k on systems without high quality entropy sources. But any sy= stem running a TLS stack is already going to have a high quality entropy so= urce for client/server randoms and IVs and such, so what's the benefit = of deterministic ECDSA here?

-Jake M

On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixt= on" <jpixton@gmail.com>= wrote:
Hi,

I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
For discussion, here's a pull request with possible language:

https://github.com/tlswg/tls13-spec/pull/406

Cheers,
Joe

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--047d7bd6b02008ef97052a055450-- From nobody Mon Jan 25 07:08:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5691B2BCE for ; Mon, 25 Jan 2016 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2a2zNKNVP4o for ; Mon, 25 Jan 2016 07:08:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id C04D51B2BCA for ; Mon, 25 Jan 2016 07:08:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C7AE3433404; Mon, 25 Jan 2016 15:08:39 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B0880433403; Mon, 25 Jan 2016 15:08:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453734519; bh=J7FPD2ghocDOR9YnNL62VAyPsGHk/a+QwlxfXnZ2BNo=; l=260; h=From:To:CC:Date:References:In-Reply-To:From; b=Qq+W9akxDS5qcU1u8Wa1c5gld3dUuP/EmlYlvCgkgV/+foOiQuiCZQytbb3PulHbH F5oWw6YN2vdA6UZfkbLB1/TjZLpG5TUe1WY34zFFch0awcn8kmWbic2aJCeohUxb6u cAeVUTfF0zz0pebSSHOSd7g/DJU/Z7Fk42v1ZEMU= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 98343202C; Mon, 25 Jan 2016 15:08:39 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 25 Jan 2016 09:08:38 -0600 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.1076.000; Mon, 25 Jan 2016 09:08:38 -0600 From: "Salz, Rich" To: Jacob Maskiewicz , Joseph Birr-Pixton Thread-Topic: [TLS] Require deterministic ECDSA Thread-Index: AQHRVhJT9jHjiOXg0EehDwte11nJjZ8J4KoAgAJ3kVA= Date: Mon, 25 Jan 2016 15:08:37 +0000 Message-ID: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 15:08:42 -0000 PiBCdXQgYW55IHN5c3RlbSBydW5uaW5nIGEgVExTIHN0YWNrIGlzIGFscmVhZHkgZ29pbmcgdG8g aGF2ZSBhIGhpZ2ggcXVhbGl0eSBlbnRyb3B5IHNvdXJjZSBmb3IgY2xpZW50L3NlcnZlciByYW5k b21zIGFuZCBJVnMgYW5kIHN1Y2gNCg0KVGhhdCdzIGFzc3VtaW5nIGEgY29uc3RyYWludCB0aGF0 IGlzbid0IGFjY3VyYXRlLg0K From nobody Mon Jan 25 07:19:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5721B2BF8 for ; Mon, 25 Jan 2016 07:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 1F-_rYQq1ORY for ; Mon, 25 Jan 2016 07:19:03 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F861B2BF7 for ; Mon, 25 Jan 2016 07:19:03 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id e32so111220281qgf.3 for ; Mon, 25 Jan 2016 07:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=402qe/EyUzCyV5SaX/84LloOa9hqzq0gmRw+6q20PT0=; b=WBEEsA+hvTEymnKfpTkwf4RbBn00yE5SCx5E/g6uDTEWEC56PH+UssD0fZrRkbPT7G JcDph8FYaxiiM8Su9bXvUWqOZJ7cZA2PFRoqOMEzgGb63wq68lkk2MBtBfV2XmcjArOz StVoQIP/aE4DFkFXSwvt4fhUptfw548Pb1rcVxaYOsh6reFbnZv+kdjNm6nRx2ybh49i +0/XvOKHZh3vNgD3kiD4zAXx3Xp3rdNF9fZlSqyJySeg3y+20crc5rv+Fzg7d+mWnvoO jDc1G8bkMJgRgt67iikcsYK+HU8z3oCT4h0kfNUR9nyx07XeQE6vLmR9EWJHBaijIMW0 FxJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=402qe/EyUzCyV5SaX/84LloOa9hqzq0gmRw+6q20PT0=; b=PPWxWotIdilw+OFThW+T2oR5K/me5vfyU3gCoc4n/ANhQgxAfsju/zmeixVbfKvoUV 9Ibszyu9XZ2UHOGESVjIWfjR0AT6CNRcOkQ3D9LOwdoOUQPezUOdzmld1LjKOnA1aMWF 9EBWC9+juqeNU3TlnU32sbX1cyfh7V3RTmdO2D5dJacPJM/Yu/CxiCMmbtMFNr9dKBLC 2xI99DVXKchUmldy/u9W58YPUl09krvUd+7/qrmmi7eGC+7RhnIfb4JwRN3nqucyYWcB fD2CmlgoWljfXL+C5o554dsN5XsNc/Gaa4dlVghQOJ6gIl02FkvH1vp+bSpP+bT7wV0C ePWQ== X-Gm-Message-State: AG10YORCZZAhiMjauGaaCNsicdGWd+0aICmthI/+ohbv2k04IpAS2j1vGKV/7fpDxQGsVhzYph4r6pakwAfGvA== MIME-Version: 1.0 X-Received: by 10.140.232.78 with SMTP id d75mr22904469qhc.27.1453735142610; Mon, 25 Jan 2016 07:19:02 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Mon, 25 Jan 2016 07:19:02 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2016 07:19:02 -0800 X-Google-Sender-Auth: Ta5ffOugkpbYVfIqk7SylKA78dY Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , Joseph Birr-Pixton Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 15:19:05 -0000 On Sat, Jan 23, 2016 at 9:20 PM, Brian Smith wrote: >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > > What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates > all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it > also includes a random element in the SHA-512 hash. > > Ed25519 uses SHA-512 instead of HMAC for the same purpose and people seem to > think it works fine. > > Also hashing in some randomness seems like it would help avoid some side > channel leakage. Note that most (all the ones I've looked at for more than 5 > minutes) open-source ECDSA implementations have side-channel issues of > various levels of significance. > > Anyway, I do think that implementations should do something *like this* to > avoid problems when the RNG is bad, but I think prescribing RFC 6979 as the > solution is overly-specific, especially when it doesn't even seem to be the > best way to accomplish the goal in many cases. I wrote that design before RFC6979 (or, at least, before I was aware of it). The reason that I included randomness into the mix was because I worried that someone might be depending on the randomised nature of ECDSA signatures and suddenly making them deterministic seemed like a risky thing to do. That's not a problem in TLS. I think that those implementations that care about DPA-level side-channel attacks will probably do their thing no matter what the standard says, so I wouldn't have an objection to putting a "SHOULD" in the spec for RFC 6979. I suspect that adherence would be poor, however. As for using that RFC over what I came up with or anything else: at least RFC 6979 has been written down already. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Jan 25 08:29:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2FE1B2CFE for ; Mon, 25 Jan 2016 08:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoG4BgB81bFI for ; Mon, 25 Jan 2016 08:29:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 985501B2CFD for ; Mon, 25 Jan 2016 08:29:19 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C1A9D433404 for ; Mon, 25 Jan 2016 16:29:18 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AA665433403 for ; Mon, 25 Jan 2016 16:29:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453739358; bh=zk1jCEz5uRvrUMKONZ/8C3WcEY9nhjJUNIXQ1e6C7qk=; l=1427; h=References:To:From:Date:In-Reply-To:From; b=K4lwacrDgJiY3WCFpiKaUSI+a2T4PUQK3PYD/toHhhIs9ohwAtzuEwxIcDG42men7 Vz6yhh3NXsT/W28YqYFfjycTDZu1mt4VpjFuESP0+w+oO2hwVKpnZr2RII1J5QlslA Bg2j2EuJeJ0RBzzZNS+lsFvmkSe4w5SUbrcPvtlY= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 826542038 for ; Mon, 25 Jan 2016 16:29:18 +0000 (GMT) References: <56A192FC.4060206@brainhub.org> <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com> <56A2775E.5010507@brainhub.org> <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> To: tls@ietf.org From: Benjamin Kaduk Message-ID: <56A64D5E.7090104@akamai.com> Date: Mon, 25 Jan 2016 10:29:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:29:22 -0000 On 01/22/2016 01:14 PM, Hubert Kario wrote: > On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: >> On 01/22/2016 03:14 AM, Hubert Kario wrote: >>>> The only solution that's available at this point is conditioning >>>> TLS >>>> 1.3 support on appropriate hardware. For this reason TLS 1.3 it >>>> probably won't be enabled by default in the product I work on. I >>>> would prefer for TLS 1.3 to be enabled by default and write the >>>> code >>>> to decide whether it does PSS or falls back to RSA PKCS1 1.5. >>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not >>> cutting it off now would be negligent. >> You mean for HS only, while leaving it for X.509 certs? > If we don't do it for HS in TLS first, we'll never get rid of it in > X.509 certs. > > We need to start somewhere, and it's more reasonable to expect that > hardware with support for new protocols will get updated for RSA-PSS > handling than that libraries and hardware will suddenly start > implementing it in droves just in anticipation of the time when CAs > _maybe_ will start issuing certificates signed with RSA-PSS. > > Isn't it more a matter of TLS being a consumer of external PKIX infrastructure, the web PKI, etc.? They are out of the reach of the IETF TLS working group; any requirements we attempted to impose would be unenforceable, even if there was an Internet Police (which there is not). -Ben From nobody Mon Jan 25 08:31:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113E61B2CFD for ; Mon, 25 Jan 2016 08:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMVz7a3fI4Xx for ; Mon, 25 Jan 2016 08:30:59 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5876D1B2C58 for ; Mon, 25 Jan 2016 08:30:59 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id v14so166813793ykd.3 for ; Mon, 25 Jan 2016 08:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=d87ijtg1GaurWCHzImPC5hVrTyWhJDFIuipQlnOs2as=; b=MlxVIdmq5di6ulWqHQDEBRMRdpnFgzWmg5YThFcUxoaXglK6BusTZwW2p25lLW9rgx ae/wx1ObqW8XqrACsYI8oHKX6aEVaGYS+4VA65wToq+8p0P/SBa7oryVgES9//YhmGq4 BxsOOK9nh2Q6b3jwXaN/3eG+O8B4b8GIGHITE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=d87ijtg1GaurWCHzImPC5hVrTyWhJDFIuipQlnOs2as=; b=Obuk1zdzdYWLdf5BZvb9a8fOcsX3+LzhurCfxvqbj5QKScScIaqbBnky6s7NCg7va7 FPkR65iUQ7aMSPgcT9hQLxe9ZG8/MYzoXlG9Z5/M4KUvUay3VzEM5NQTgzFQtSts/N0g 53VINoUOBDB7+fZ/s/irI2dnBJSge9k5EY01oB/8qpnTSqeY8bMfYjZkgJUmrJ2voYJi zaiZNsYZlCJMn3sPd4/WnAy8qyq56zNBKEPakC0xzItEfcXYewU37kp4nhDBFNEwLb/r pNVXdurPsRemmPWBOjyaFBPSkgZZYAnHnILdEAubSEBKyNK/+GUpEvxD2sRDLcixW10e XIUQ== X-Gm-Message-State: AG10YOQgldtgQ6sJGBlktYnlAzLoim5aZisV06HmCuuICiXjdJQauwtdabcJaFjblmrz5w== X-Received: by 10.129.4.3 with SMTP id 3mr8822972ywe.342.1453739458589; Mon, 25 Jan 2016 08:30:58 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id x206sm4480694ywc.49.2016.01.25.08.30.57 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 08:30:58 -0800 (PST) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_C82408BA-7DB6-41C3-BBF4-BF1DD3F8C514" Date: Mon, 25 Jan 2016 11:30:56 -0500 References: To: "" Message-Id: <36DF8F22-C022-4865-975C-22292DD42A02@sn3rd.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Fwd: [dns-privacy] Call for Adoption: draft-dgr-dprive-dtls-and-tls-profiles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 16:31:01 -0000 --Apple-Mail=_C82408BA-7DB6-41C3-BBF4-BF1DD3F8C514 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a draft that might be of some interest to the mailing list, but = please send your comments to the DPRIVE mailing list. spt > ---------- Forwarded message --------- > From: Tim Wicinski > > Date: Tue, Jan 12, 2016 at 4:56 PM > Subject: [dns-privacy] Call for Adoption: = draft-dgr-dprive-dtls-and-tls-profiles > To: dns-privacy@ietf.org = > >=20 >=20 > The chairs realized earlier today that we encouraged this draft to be > created, but once it was, we forgot to start a formal Call for = Adoption. > With the feedback already, this document looks ready for adoption = and > being worked on. >=20 > This starts a Call for Adoption for = draft-dgr-dprive-dtls-and-tls-profiles >=20 > The draft is available here: > = https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/ = = >=20 > Please review this draft to see if you think it is suitable for = adoption > by DPRIVE, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. >=20 > This call for adoption ends 26 January 2016 >=20 > Thanks, > tim wicinski > DPRIVE co-chair >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy = --Apple-Mail=_C82408BA-7DB6-41C3-BBF4-BF1DD3F8C514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is a draft that might be of some interest to the mailing = list, but please send your comments to the DPRIVE mailing list.

spt

---------- Forwarded = message ---------
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Tue, Jan 12, = 2016 at 4:56 PM
Subject: [dns-privacy] Call for Adoption: = draft-dgr-dprive-dtls-and-tls-profiles
To: dns-privacy@ietf.org = <dns-privacy@ietf.org>


The chairs realized earlier today that we = encouraged this draft to be
created, but once it was, we forgot to start a formal Call for = Adoption.
  With the feedback already, this document looks ready for adoption = and
being worked on.

This starts a Call for Adoption for = draft-dgr-dprive-dtls-and-tls-profiles

The draft is available here:
https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-= profiles/

Please review this draft to see if you think it is suitable for = adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, = etc.

This call for adoption ends 26 January 2016

Thanks,
tim wicinski
DPRIVE co-chair

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

= --Apple-Mail=_C82408BA-7DB6-41C3-BBF4-BF1DD3F8C514-- From nobody Mon Jan 25 09:31:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBDD1B3798 for ; Mon, 25 Jan 2016 09:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRLj01r7KpJQ for ; Mon, 25 Jan 2016 09:31:16 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 1EBC11B3794 for ; Mon, 25 Jan 2016 09:31:16 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id u68so40303534ykd.2 for ; Mon, 25 Jan 2016 09:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=KOxSeZubhD8T4ADB+2wmRanCTnf9j30Gqcm7YF7+98U=; b=bbV6dxxDR+QovKCXwj9cNi6Ip6GxYrRgfQ2KxxkN9OWGTXaaGd7hPzp/hxpSQvoAZs K38D6t8FtYSi4w490mqyefapc2Ed8cY8g6n3eecyhoowXwbo06qneePa00MBMUncfdVS E1SI3ua16NRcojAbohlNaE9CVXe6CWErmVaSQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=KOxSeZubhD8T4ADB+2wmRanCTnf9j30Gqcm7YF7+98U=; b=PF54NyModA2fuFpjBJ8fXbZJPrB+oHWwhl3bgwRPEeqt3YZYdzYuMMUhO4vO/LO3cl a1bB2WYx/CSXVjMztqod8QHrjBQsowSDOP25MwogbuePzuIN56jtKDXXxaO52lVFZosX FTHtW2h40L595hStS2gIP6t50fYcANOxweUXzRHM25ZOSstjC/4mKcVHQ15cdSkrCi6l HTQAQiixyyodHFqMtMf/njszQ5LObT50+xx+pS7HxhZ0814ZD27KnWTzC21YRy9HsDXS e9GC2trE0Y8hxOizmJO84W+F08Z32A2kOOx6RQK+QGtYLzTF/BuToNe0Cw1xfZXHLhEy 4RQA== X-Gm-Message-State: AG10YOS82vBTS2ZlndCgg4QT23llWShs2O2hv4I7i3HcwQCWTdSvzNURrLXCAeLsSYnm3w== X-Received: by 10.37.97.66 with SMTP id v63mr9687380ybb.71.1453743075386; Mon, 25 Jan 2016 09:31:15 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id v130sm14839809ywe.24.2016.01.25.09.31.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 09:31:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <56A192FC.4060206@brainhub.org> Date: Mon, 25 Jan 2016 12:31:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6AAFF82D-8F1D-4B0C-9E3C-A1FEE5D46748@sn3rd.com> References: <56A192FC.4060206@brainhub.org> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:31:18 -0000 All, Andrey sent this message at the chairs' request to make sure that we = adequately discussed the issue, which we discussed at the last IETF = meeting = (https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf). spt > On Jan 21, 2016, at 21:25, Andrey Jivsov wrote: >=20 > Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the = following language in sec 4.8.1 >=20 >> In RSA signing, the opaque vector contains the signature generated >> using the RSASSA-PSS signature scheme defined in [RFC3447 = ] with MGF1. >> The digest used in the mask generation function MUST be the same = as >> the digest which is being signed (i.e., what appears in >> algorithm.signature). The length of the salt MUST be equal to the >> length of the digest output. Note that previous versions of TLS = used >> RSASSA-PKCS1-v1_5, not RSASSA-PSS. >=20 > The >=20 >> struct { >> SignatureAndHashAlgorithm algorithm; >> opaque signature<0..2^16-1>; >> } DigitallySigned; >=20 > defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec = A.3.1.1: >=20 >> enum { >> rsa(1), >> dsa(2), >> ecdsa(3), >> rsapss(4), >> eddsa(5), >> (255) >> } SignatureAlgorithm; >=20 > since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates = only. >=20 >=20 > Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as = frictionless as possible regarding the upgrade of existing TLS = installations to TLS 1.3. We should expect that all TLS 1.3 servers and = clients will have support for older versions of TLS on the same node. = Ideally, it should be possible to upgrade the software / firmware to add = TLS 1.3 support on existing hardware with minimal penalty. >=20 > Unfortunately, the product I work on, which is responsible for ~15% of = Internet traffic, is not compatible with the "frictionless idea" due to = the current TLS 1.3 spec [1] mandating PSS in the handshake. >=20 > The issue here is that these already sold products use 3d party = components that can only perform RSA signing with CRT optimization when = the padding is PKCS1 1.5. In the best case this means ~2x performance = penalty for TLS 1.3. In the worst case the existing server keys cannot = do PSS signature if the keys are on FIPS-certified devices. >=20 > The same issue applies to client TLS authentication with smartcards. = Many smartcards cannot do PSS, e.g. [3]. >=20 > Likewise, it's unclear if PSS is supported by e.g. PKCS#11 libraries = of HSM vendors, or the HSM hardware. >=20 > Other products on the Internet use the same components, so that 15% is = a minimum I know of. >=20 > The current list of FIPS 140 products that support RSA shows twice as = many products that support RSASSA-PKCS1_V1_5 than these that support = RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS = certification with TLS 1.3, factoring client auth and servers. >=20 > Can support for PSS be added by 3d party vendors? If the limitation is = in middleware like PKCS#11 or in firmware/microcode, this is technically = possible. This does require an update and the brings version dependency. = Further, if the firmware is FIPS 140-2 certified, this type of upgrade = will have re-certification cost (more friction). In some cases this is a = physical limitation. For example, I know from my experience working on = smartcard decryption a few years back that the chips themselves insist = on PKCS#1.5 padding for half of the vendors we supported and won't e.g. = accept raw or OAEP padding with RSA, e.g. [2]. It is apparent from the = specs that [3] does support PSS while [2] doesn't. >=20 > I prepared the slides on this subject for Yokohama [5]. I believe Eric = Rescorla presented these. >=20 > How much do the members of the WG value the idea of lower hurdles to = the deployment of TLS 1.3? Is there desire to add a PKCS#1 1.5 signature = fallback, just like there is one already for X.509 certificates in TLS = 1.3? >=20 > The only solution that's available at this point is conditioning TLS = 1.3 support on appropriate hardware. For this reason TLS 1.3 it probably = won't be enabled by default in the product I work on. I would prefer for = TLS 1.3 to be enabled by default and write the code to decide whether it = does PSS or falls back to RSA PKCS1 1.5. >=20 > Thank you. >=20 > [1] http://tools.ietf.org/html/draft-ietf-tls-tls13-11.html > [2] 4.4 has no PSS: = http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf > [3] 5.0 has PSS: = https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf >=20 > [4] 2x more legacy than PSS: = http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html > wget http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html > $ grep RSASSA-PSS rsanewval.html | wc -l > 593 > $ grep RSASSA-PKCS1_V1_5 rsanewval.html | wc -l > 2005 > $ grep RSASSA rsanewval.html | wc -l > 2607 >=20 > [5] https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf = https://www.ietf.org/jabber/logs/tls/2015-11-04.html >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jan 25 09:35:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3E41B37B8 for ; Mon, 25 Jan 2016 09:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 c6w6HaDIStmS for ; Mon, 25 Jan 2016 09:35:44 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411E31B37B6 for ; Mon, 25 Jan 2016 09:35:44 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id ik10so39339544igb.1 for ; Mon, 25 Jan 2016 09:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=dafEfVT8CmPhKAksvpgVVMhUFTjPUq/pbWywgqQDrKw=; b=eThDf4saGyiF04j2Xr7ZRfsaIWR/FiaEZ9DJMboknh/UPF1Wy0iFjMgmTAyUnD+XvT v1cai8Q8We/q82EhE4R/HoGwSsfHM6L49bVsnEQA8xyr7mDl3uEgoyav+u0rvl4YSFuZ e+Easnkfh5A0gSFEQ1RoieZbNQs17EDbCHa9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=dafEfVT8CmPhKAksvpgVVMhUFTjPUq/pbWywgqQDrKw=; b=Oj0uR1T9w9jEU+sgaOwxOjlvkxlXFOo/zzR//6aHR+VOAUXThkL5oOShu+XPt+vNc+ EpZgTwXd+Ca+Vmc3WFI83KVr2siyeEJDmvw2w+moY+cwIaKfDCalAgOIUd36hE85rJiq bxMJY1DveoGLeUb4o2mOi/m3vsg0vbirBHuGA09hXmTxTZ5TO9oNXG70ImCB66jegfAk uTa2ic5+UNETvutB3UKhjhSmOq8S/XDcon6rjuDfscqddMUOP2rePqPBuIqh/F5d1IEa qKFPcyNKI8fgJgv68Pln//sTLJ/Qh0NpVa7OnqP4YF+E5XjARLVw3Kf57A4C8K4u5yeQ PvFA== X-Gm-Message-State: AG10YOTVLw95JlusPcD3uI+aXzQShIfROwT9vptKBBXBWQRFVgv+X0H1tdz27tZvQV17bzmvadc5C2nTj6quDI9P X-Received: by 10.50.8.106 with SMTP id q10mr17681520iga.67.1453743343579; Mon, 25 Jan 2016 09:35:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 25 Jan 2016 17:35:33 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013c65dc96f30b052a2bff8b Archived-At: Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 17:35:47 -0000 --089e013c65dc96f30b052a2bff8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I'd meant to add this note to the message below and forgot: In putting together the PR, I noticed that eddsa is currently in the draft as always paired with no hash rather than the one it uses internally. So the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur. My bad, I should have looked at that more carefully. I still think this change is worthwhile. If we expect that future signature algorithms look like ed25519, this scheme only gives us 256 values to allocate from and wastes one of the bytes, and it also simplifies and unifies the interface for signature algorithms. The other benefits from incorporating curve preferences into the negotiation also still apply. David On Fri, Jan 22, 2016 at 5:25 PM David Benjamin wrote: > I've put together a pull request with some initial text for this proposal > if folks decide to adopt it. > https://github.com/tlswg/tls13-spec/pull/404 > > (I'm sure there's no end of editorial problems. I think this is the first > time I've done non-trival spec work.) > > David > > > On Fri, Jan 15, 2016 at 3:45 PM David Benjamin > wrote: > >> Hi folks, >> >> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS >> 1.2, signature algorithms are spread across the handshake. We have >> SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all= in >> independent registries. NamedGroup is sent in one list, also used for >> (EC)DH, while the other two are sent as a pair of (HashAlgorithm, >> SignatureAlgorithm) tuples but live in separate registries. >> >> This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to >> be messy to implement. Client certificate keys may be in smartcards via >> OS-specific APIs, so a lot of time is spent transiting new preference >> shapes across API boundaries in order to discover smartcard bugs. Someti= mes >> I think people deploy client certs because they hate me and want to caus= e >> me pain=E2=80=A6 :-) >> >> Anyway, the new CFRG curves also bind signature curve and hash together. >> The current draft represents this as eddsa_ed25519 and eddsa_ed448 >> NamedGroups and eddsa SignatureAlgorithm. But this doesn=E2=80=99t captu= re that >> EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.) >> >> I propose we fold the negotiable parameters under one name. Think of how >> we=E2=80=99ve all settled on AEADs being a good named primitive with a c= ommon type >> signature[1]. Specifically: >> >> 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now >> on, NamedGroup is only used for (EC)DH. >> >> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm a= s >> they are. Introduce a new SignatureAlgorithm u16 type and negotiate that >> instead. (Or maybe a different name to not collide.) u8 is a little tigh= t >> to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty. >> >> 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 b= y >> (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401 >> becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with >> HashAlgorithm from TLS 1.2. Note this does not introduce new >> premultiplications on the wire. Just in the spec and registry. >> >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa= _* >> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although th= is >> introduces new premultiplications, it=E2=80=99s only 9 values with the p= runed TLS >> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate. >> >> 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and >> rsapss_{sha256,sha384,sha512}. These come with the signature algorithm a= nd >> curve pre-specified. (See [2] at the bottom for full list of allocations= .) >> >> Thoughts? >> >> David >> >> [1] We=E2=80=99re stuck with RSA-PSS's generality, so that'll need some = mapping >> to a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with >> hashAlgorithm SHA-256, maskGenAlgorithm >> MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 1= 4. >> And RSA key generation still has size parameter. Hopefully future things >> can look more like Ed25519. >> >> [2] >> 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note >> this is wire-compatible with TLS 1.2. >> - 0x0101 - rsa_pkcs1_md5 >> - 0x0201 - rsa_pkcs1_sha1 >> - 0x0301 - rsa_pkcs1_sha224 >> - 0x0401 - rsa_pkcs1_sha256 >> - 0x0501 - rsa_pkcs1_sha334 >> - 0x0601 - rsa_pkcs1_sha512 >> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3. >> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but >> ignored in TLS 1.3. >> >> 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to >> avoid colliding with existing signature algorithms, but I don=E2=80=99t = think >> that=E2=80=99s necessary[3]. >> - rsapss_sha256 >> - rsapss_sha384 >> - rsapss_sha512 >> - ecdsa_p256_sha256 >> - ecdsa_p256_sha384 >> - ecdsa_p256_sha512 >> - ecdsa_p384_sha256 >> - ecdsa_p384_sha384 >> - ecdsa_p384_sha512 >> - ecdsa_p521_sha256 >> - ecdsa_p521_sha384 >> - ecdsa_p521_sha512 >> - eddsa_ed25519 >> - eddsa_ed448 >> >> 0xfe00-0xffff - reserved for private use, compatible with existing >> HashAlgorithm reservation. >> >> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as >> {hash(7), RSA}, they should ignore it since hash 7 doesn't exist. >> > --089e013c65dc96f30b052a2bff8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I'd meant to add this note to the message below= and forgot:

In putting together the PR, I noticed that = eddsa is currently in the draft as always paired with no hash rather than t= he one it uses internally. So the problem about advertising {sha512, eddsa}= and eddsa_448 doesn't occur. My bad, I should have looked at that more= carefully.

I still think this change is worthwhil= e. If we expect that future signature algorithms look like ed25519, this sc= heme only gives us 256 values to allocate from and wastes one of the bytes,= and it also simplifies and unifies the interface for signature algorithms.= The other benefits from incorporating curve preferences into the negotiati= on also still apply.

David

On Fri, Jan 22, 2016 at 5:25 PM David Benjamin = <davidben@chromium.org> = wrote:
I've pu= t together a pull request with some initial text for this proposal if folks= decide to adopt it.
https://github.com/tlswg/tls13-spec/pull/404

(I'm sure there's no end of editorial problems. I thin= k this is the first time I've done non-trival spec work.)

=
David


On Fri, Jan 15, 2016= at 3:45 PM David Benjamin <davidben@chromium.org> wrote:
Hi folks,

This is a pr= oposal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature= algorithms are spread across the handshake. We have SignatureAlgorithm, Na= medGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registrie= s. NamedGroup is sent in one list, also used for (EC)DH, while the other tw= o are sent as a pair of (HashAlgorithm, SignatureAlgorithm) tuples but live= in separate registries.

This is a lot of moving parts. Signature ne= gotiation in TLS 1.2 tends to be messy to implement. Client certificate key= s may be in smartcards via OS-specific APIs, so a lot of time is spent tran= siting new preference shapes across API boundaries in order to discover sma= rtcard bugs. Sometimes I think people deploy client certs because they hate= me and want to cause me pain=E2=80=A6 :-)

Anyway, the new CFRG curv= es also bind signature curve and hash together. The current draft represent= s this as eddsa_ed25519 and eddsa_ed448 NamedGroups and eddsa SignatureAlgo= rithm. But this doesn=E2=80=99t capture that EdDSA + Ed25519 + SHA-256 is i= llegal. (Or ECDSA + FF3072.)

I propose we fold the negotiable parame= ters under one name. Think of how we=E2=80=99ve all settled on AEADs being = a good named primitive with a common type signature[1]. Specifically:
1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now o= n, NamedGroup is only used for (EC)DH.

2. Remove HashAlgorithm, Sign= atureAlgorithm, SignatureAndHashAlgorithm as they are. Introduce a new Sign= atureAlgorithm u16 type and negotiate that instead. (Or maybe a different n= ame to not collide.) u8 is a little tight to allocate=C2=A0eddsa_ed25519 an= d=C2=A0eddsa_ed448 separately, but u16 is plenty.

3. Allocate values= for SignatureAlgorithm wire-compatibly with TLS 1.2 by (ab)using the old (= HashAlgorithm, SignatureAlgorithm) tuples. 0x0401 becomes rsa_pkcs1_sha256,= etc. Reserve ranges consistently with HashAlgorithm from TLS 1.2. Note thi= s does not introduce new premultiplications on the wire. Just in the spec a= nd registry.

4. Deprecate ecdsa_sha256, etc., in favor of new ecdsa_= {p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* values= are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this introd= uces new premultiplications, it=E2=80=99s only 9 values with the pruned TLS= 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
5. Add new allocations for eddsa_ed25519, eddsa_ed448, and rsapss_{sha= 256,sha384,sha512}. These come with the signature algorithm and curve pre-s= pecified. (See [2] at the bottom for full list of allocations.)

Thou= ghts?

David

[1] We=E2=80=99re stuck with RSA-PSS's genera= lity, so that'll need some mapping to a subset of X.509's RSA-PSS. = We'll just not bother with RSA-PSS with hashAlgorithm SHA-256, maskGenA= lgorithm MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerF= ield 14. And RSA key generation still has size parameter. Hopefully future = things can look more like Ed25519.

[2]
0x0000-0x06ff - Reserved r= ange for TLS 1.2 compatibility values. Note this is wire-compatible with TL= S 1.2.
- 0x0101 - rsa_pkcs1_md5
- 0x0201 - rsa_pkcs1_sha1
- 0x0301= - rsa_pkcs1_sha224
- 0x0401 - rsa_pkcs1_sha256
- 0x0501 - rsa_pkcs1_= sha334
- 0x0601 - rsa_pkcs1_sha512
- 0x{01-06}02 - dsa_md5, etc. Igno= red in TLS 1.3.
- 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 = compatibility but ignored in TLS 1.3.

0x0700-0xfdff - All= ocate new values here. Optionally avoid 0x??0[0-3] to avoid colliding with = existing signature algorithms, but I don=E2=80=99t think that=E2=80=99s nec= essary[3].
- rsapss_sha256
- rsapss_sha384
- rsapss_sha512
- ec= dsa_p256_sha256
- ecdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p3= 84_sha256
- ecdsa_p384_sha384
- ecdsa_p384_sha512
- ecdsa_p521_sha= 256
- ecdsa_p521_sha384
- ecdsa_p521_sha512
- eddsa_ed25519
- e= ddsa_ed448

0xfe00-0xffff - reserved for private use, compatible with= existing HashAlgorithm reservation.

[3] If a TLS 1.2 implementation= sees 0x0701 and interprets it as {hash(7), RSA}, they should ignore it sin= ce hash 7 doesn't exist.
--089e013c65dc96f30b052a2bff8b-- From nobody Mon Jan 25 11:13:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383871B394B for ; Mon, 25 Jan 2016 11:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2JgVjKVzkB8 for ; Mon, 25 Jan 2016 11:13:02 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 D3B181B391D for ; Mon, 25 Jan 2016 11:13:01 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id u188so78779061wmu.1 for ; Mon, 25 Jan 2016 11:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b28IB6DYD0t+bjcbh4srz/NiEvKl0bhFMWr74ixluvU=; b=vHuG1UKnE2FZpMDTNsBsM+iV4AoAvvAGHHMj6rfX6+OfjXyEGu484sYUUELxRDyF11 sYca3vtw2kIYDJNfh9tgP5IQTL4ZEEICCwWX6m3V0FnQECquHMYWtQzuZaIbcii2kKNW H4/HL0yGHp/tfcDZ/b/YLvpCVni9WTC0q+Y3BwMuWNZd9VopH6N1sOSb81EYX6jWLyVD 0kjHItEmv/ctDEplfxKwhqG8Vwlt7EgU3JxEHPq80n6BBqq7tKE1N1SKQqcFF8UvzXkg OKmMj7yzjwE88zSATdYZjXdpq0SQLwDnjEnHdsmDCcqPpIAuTgUuA4Fly26gnCELOdnK JAHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=b28IB6DYD0t+bjcbh4srz/NiEvKl0bhFMWr74ixluvU=; b=gAF1jG4tQBNUVyYNvsPKsRKHw1WCLuWyd3WZo8wdLxuWSVgHC34QTBI6RHdSdPiWlq Gcgod6onvToadhnXO0JM3YB2Fo0S9BGC74PrfbaAyuygkVE4qbkVfey+MNHy96NqZS+g 7mM/K8KYKRNMrsf+O0IW+sIKJWM5XkmguRvSvdQoKtu9ttbKbtOojUaIK+aN/+fyca+f l6abW1LNXN1NdY1H98lLOt7wJukJtkaHBwCCt3vfUvt/2K+WzybHRdYdGLKsiXONXGGM Coc+xsENb7PBDyBTkdmVh3b7R7I021zkIc9iyQcOMTxoNB5Zvn2z8dev5uFJZY1BS15T vxVQ== X-Gm-Message-State: AG10YOTxCcpCzSb940477c6MZXI4/Ntjdi5Ram0WphPV0R40DwIdPIWTMDDdWSq8R6l7uw== X-Received: by 10.28.88.210 with SMTP id m201mr20812003wmb.76.1453749180485; Mon, 25 Jan 2016 11:13:00 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id lh1sm20368019wjb.20.2016.01.25.11.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 11:12:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 25 Jan 2016 21:10:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Jacob Maskiewicz , Joseph Birr-Pixton , "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:13:03 -0000 > On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote: >=20 >> But any system running a TLS stack is already going to have a high = quality entropy source for client/server randoms and IVs and such >=20 > That's assuming a constraint that isn't accurate. Eh. Just s/is/should/ From nobody Mon Jan 25 11:25:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E7D1B38E1 for ; Mon, 25 Jan 2016 11:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWH_Dz5Rqk40 for ; Mon, 25 Jan 2016 11:25:39 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 098C11B374E for ; Mon, 25 Jan 2016 11:25:38 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2AF6D42371B; Mon, 25 Jan 2016 19:25:38 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 15466423702; Mon, 25 Jan 2016 19:25:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453749938; bh=I0B4AKUv1bU+TC/y1kn7Vb5EpWbekA4aklSUlwknJDo=; l=190; h=From:To:CC:Date:References:In-Reply-To:From; b=OyXad7PUPP1bnyQ++NIVSnsgRFfXKLGpkpesNds2ComFRE7ULqpxiGtmnMQtURDni 98nIcsEGwDmn3DOg5rnE9FyjfHaE7HmzETL154cOWZt7eR4/kXvsccay1UMSH0B1zo ZqunT+M9PIieeqbtxE1M/fRZqQgpZ3+qwW5Tjftw= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id F1BB4202E; Mon, 25 Jan 2016 19:25:37 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 25 Jan 2016 13:25:37 -0600 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.1076.000; Mon, 25 Jan 2016 13:25:37 -0600 From: "Salz, Rich" To: Jacob Maskiewicz , Yoav Nir Thread-Topic: [TLS] Require deterministic ECDSA Thread-Index: AQHRVhJT9jHjiOXg0EehDwte11nJjZ8J4KoAgAJ3kVCAAKg+gIAAAzuA//+cWjA= Date: Mon, 25 Jan 2016 19:25:37 +0000 Message-ID: References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" , Joseph Birr-Pixton Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:25:40 -0000 PiBpcy9zaG91bGQsIG9yIHRoZXkncmUgZ29pbmcgdG8gaGF2ZSBvdGhlciBwcm9ibGVtcy4gDQoN ClJlYWxseT8NCg0KU29tZSBoaWdoLXZhbHVlIGRldmljZSB0aGF0IGlzIHJhcmVseSBjb25uZWN0 ZWQtdG8/ICBMaWtlIGEgbWlzc2xlPw0K From nobody Mon Jan 25 11:36:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B9E1A0033 for ; Mon, 25 Jan 2016 11:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmQ-B754RZ8S for ; Mon, 25 Jan 2016 11:36:39 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B91881A0024 for ; Mon, 25 Jan 2016 11:36:39 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 12C2BF991; Mon, 25 Jan 2016 14:36:07 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id E4AA720085; Mon, 25 Jan 2016 14:36:08 -0500 (EST) From: Daniel Kahn Gillmor To: Yoav Nir , Rich Salz In-Reply-To: <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> User-Agent: Notmuch/0.21+72~gd8c4f1c (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 25 Jan 2016 14:36:08 -0500 Message-ID: <87wpqxa1uf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Jacob Maskiewicz , Joseph Birr-Pixton , "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:36:41 -0000 On Mon 2016-01-25 14:10:13 -0500, Yoav Nir wrote: >> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote: >> >>> But any system running a TLS stack is already going to have a high quality entropy source for client/server randoms and IVs and such >> >> That's assuming a constraint that isn't accurate. > > Eh. Just s/is/should/ Remember that keys (whether in HSMs or not) can be moved between implementations. While it seems (hopefully) likely that most keys will usually be used with a TLS stack with a high-quality entropy source, it's also possible that the key gets used occasionally with some other, less sophisticated code or platform. We should be pushing heavily for deterministic ECDSA, even though it's not something we can require via wire protocol at runtime. --dkg From nobody Mon Jan 25 11:43:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5644F1A0060 for ; Mon, 25 Jan 2016 11:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ilvv_E7dffgz for ; Mon, 25 Jan 2016 11:43:32 -0800 (PST) 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 06FE91A0045 for ; Mon, 25 Jan 2016 11:43:32 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C9043461C8; Mon, 25 Jan 2016 19:43:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-27.brq.redhat.com [10.40.204.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0PJhTcm016563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 14:43:30 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 25 Jan 2016 20:43:22 +0100 Message-ID: <3922672.SasYckhRS6@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <56A64D5E.7090104@akamai.com> References: <56A192FC.4060206@brainhub.org> <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> <56A64D5E.7090104@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1958172.aoYIXqU332"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:43:33 -0000 --nextPart1958172.aoYIXqU332 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: > On 01/22/2016 01:14 PM, Hubert Kario wrote: > > On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: > >> On 01/22/2016 03:14 AM, Hubert Kario wrote: > >>>> The only solution that's available at this point is conditioning= > >>>> TLS > >>>> 1.3 support on appropriate hardware. For this reason TLS 1.3 it > >>>> probably won't be enabled by default in the product I work on. I= > >>>> would prefer for TLS 1.3 to be enabled by default and write the > >>>> code > >>>> to decide whether it does PSS or falls back to RSA PKCS1 1.5. > >>>=20 > >>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not > >>> cutting it off now would be negligent. > >>=20 > >> You mean for HS only, while leaving it for X.509 certs? > >=20 > > If we don't do it for HS in TLS first, we'll never get rid of it in= > > X.509 certs. > >=20 > > We need to start somewhere, and it's more reasonable to expect that= > > hardware with support for new protocols will get updated for RSA-PS= S > > handling than that libraries and hardware will suddenly start > > implementing it in droves just in anticipation of the time when CAs= > > _maybe_ will start issuing certificates signed with RSA-PSS. >=20 > Isn't it more a matter of TLS being a consumer of external PKIX > infrastructure, the web PKI, etc.? They are out of the reach of the > IETF TLS working group; any requirements we attempted to impose would= > be unenforceable, even if there was an Internet Police (which there > is not). TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how=20 exactly is creating a side effect of increasing the deployment rate of=20= RSA-PSS _in TLS implementations_ an "overreach"?! =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1958172.aoYIXqU332 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 iQIcBAABCgAGBQJWpnraAAoJEJKo0bgB0vX1PcgP/AxWBxSOHdW9Mo8ORKjYq1A1 x56I1OpA1blU+iNb2vUckGi/kUYEQpzt7gD4mG87qe6WKOrluMVq3qHmoxirPZ8o S7kjNGgC21A8m3j3iYNKtUnkqMQ6RR3bajpvQkaPaO2RjJp6QGHnJLxAZD/azmvz pYqLv40jvsWAXOkFHQg6O+oCR8NweZZ/dYXpBsIY7HLzU0Ap6t6PScXYOuhckt8/ 65OC/yX/TlmkbEyHWIrES5KNsyXf1PM67nbIvtF9Ej7cJqZ1S9IQxtS4a+8oOExV dwmrWLfjY2FQnYqCkc+KAOUWh8u0TxMhQk5L2aFIqesPSpdZw6tBi4bQr+dNMxU0 Sc2owwD1dJaFOoEBJ3gkrE8Vrp41s0VDiPRzELx2IxvnEizzPZG1Kze8FlDDpJu8 Ajhw+yiYW2UxXX9b21i8ZIWtYkvIncdaYAJZAxUeAMEImRPy1w4zS8NzpM0LwTJv D7HRTtQlSaOLSR02T4iyaFRAaBGJDzK5gxMhmdIheDiZa8N3MQAUtwnsN9Dsl+Gx V83fezr1Dkv872o8BON1WTSzPGO/51ETh1+MswmL0S2MOIf0fmVdMfPc/souTcuH 2NMJuepOpho2Tv28ZLKpSZ61E+qyhs7Sd8XAu2loAfffAuZxpMeFLINWmT1W8len aDGDrNAXNuWaw5J8dVk7 =cnpt -----END PGP SIGNATURE----- --nextPart1958172.aoYIXqU332-- From nobody Mon Jan 25 12:15:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0B1A0103 for ; Mon, 25 Jan 2016 12:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WjX1IYTawva for ; Mon, 25 Jan 2016 12:15:54 -0800 (PST) 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 C29D61A00D7 for ; Mon, 25 Jan 2016 12:15:54 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id o124so94874241oia.3 for ; Mon, 25 Jan 2016 12:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yEZUvCoKaPXKQCDmPNCz4F8Zt6gWkjgy4Nn/BBq9k7M=; b=B0A5FODafCqy/7RHqaDdFnKxJQHc237L4UN4n2fn80s8LhKPvp0i5m6D+0KmbZs6Ta W7NcyK1mTzNk7iqLcCYOjRWE/NrVp7f6tYK+9WYjNrSpLW9/ylPkVhZUbt8sOf4PbkoN 5y39jOXUSZo2QnCNiTv1ruqEX7D1r6rxemP0g9zO2pukSjEHGcpFIV29pt7KR2B6mfvC p0Tab4DgPqg0PfCfXnauZgGZr+bjeQOebyZW3ikgsmoSfkYreJ/SR82f73zxS9pa/Yv5 1Kq0Iq6S4XwOk9bb5/ioT+C0JFy7yAjIWwm2pa8TcOmlnzlYcDoP21muQE2XII6NBLxY 77Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yEZUvCoKaPXKQCDmPNCz4F8Zt6gWkjgy4Nn/BBq9k7M=; b=OMXcFrhXuEyRF2LNK3tiidN8dgGTiCt+t76+H0bthZn2cPuPdq/mZEFiNHteuRYr3g zdhqduRacEK9dpNi2MIRC/ua9E8g/mYAsKZV95T17zwDaoEJEbyuFd9l0ysh3VlHrd2f hL7pnW/il6zFTBbg5gqT40FrABhshygfeHjtggnsM5KiiXQ28rYrD5JI0FBbs+TswsTp uOW/uavyPH3M7f3/enBXiSrwutCSLIJe8oWIboTEQOGUtGmVk2e1s0o3MlFLdiXlmOph SJjc5bQK/usTBHk+AfCSfnFaCnLShHYOL5VsbYeK2xaqV99B973X4D2s4oztR4dG6ndq qZ9g== X-Gm-Message-State: AG10YORdA17+2IudxXSIE1xKrcuIMhQJ2pQlv3j3ZrreZ7SCyHxY182knbQH5/KunPIIsWYSjD04Tkr6rELlXA== MIME-Version: 1.0 X-Received: by 10.202.104.224 with SMTP id o93mr14918586oik.126.1453752954116; Mon, 25 Jan 2016 12:15:54 -0800 (PST) Received: by 10.182.196.104 with HTTP; Mon, 25 Jan 2016 12:15:54 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2016 20:15:54 +0000 Message-ID: From: Joseph Birr-Pixton To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:15:56 -0000 Thanks for the discussion so far on this. I've closed PR 406; it is replaced by: https://github.com/tlswg/tls13-spec/pull/408 to wit: - ECDSA details para says RFC6979 is RECOMMENDED (I've tried to keep this part succinct, but I think it fits next to the X9.62 reference). - Crypto pitfalls section has a new point with a little further discussion, trying to impress upon the reader how badly this goes wrong. Cheers, Joe From nobody Mon Jan 25 12:38:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB001A0196 for ; Mon, 25 Jan 2016 12:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKzBHNTTha23 for ; Mon, 25 Jan 2016 12:38:31 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 5715E1A0193 for ; Mon, 25 Jan 2016 12:38:31 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id k129so176591440yke.0 for ; Mon, 25 Jan 2016 12:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0D/sfDT9v3Gjfy6vqRvalfrSF10iVlvIyhay9DdYXmM=; b=AgApdfUH+p/PCpXBeDlBKkeQTj8z5CGvX6mUEPtyOhgj8n74ZH5dmvb6Pjl4ooJtje CVyCWfwsmExHcHWX7/Gq8IXgxLw1L9t4SNwVdze+b1545ti2GjoDytKFCEnCwGTbBfgt BMJslbJvfbME86uV0PG/OBvtoiKlNek8/+uI3gxeNM6xl+5kCQ6UxaxsCI/eHNqarfS7 2Vyvbc5kHkNM0VtF+hdXUhLzcv5LCG5CLD3tTnUm0Iq2+G0b/paAd0DKqHJel8SvHxaU Ic7MAX8NnPM9+rtYFRg0oqjJiJ8Prb3nvkb01uxXOqB269XZa/hM6YSgphEovazecy3u xLNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0D/sfDT9v3Gjfy6vqRvalfrSF10iVlvIyhay9DdYXmM=; b=MEfUHhv03WTCSpx7dhE4uaNBSgecvlUAT9Ub79jmFAJ4xf/ld7Lh6+3GNXF/NSc3RS K8eckgjmRaMj7JBfTMP7hZjGU5Bq67CrCMhJU0hzATGfU0YQW1AoL+fbjalxStrNbqOQ G27a2U1dF92lv+xCc7cP4f8Ss6XHcPDKaNCWNa2eSxp0Ru6dpvm5X+P/roU30mPNS76B ih9rSJA9FQDa7nPy15YMMWz73OUNfOHfLGTa6w9rtDVl2s9dguVZs6jq5vadeiyB2OCq g8dY/7teCZ3lwfQ01gQxAPW1JT5AgKoQQVsw/rHyAzruFP9tR74lvne7x1B2nsXFDL23 Lf6Q== X-Gm-Message-State: AG10YORI0MIjfMu7jr4V0BN/wmGJT8KqUNor8vWXjmanRyJ6GM90S4Jdz+gq+YuMnOC9J9508xg/OVZiUC7tig== MIME-Version: 1.0 X-Received: by 10.129.45.2 with SMTP id t2mr7633554ywt.182.1453754310640; Mon, 25 Jan 2016 12:38:30 -0800 (PST) Received: by 10.13.216.150 with HTTP; Mon, 25 Jan 2016 12:38:30 -0800 (PST) In-Reply-To: References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> Date: Mon, 25 Jan 2016 12:38:30 -0800 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Joseph Birr-Pixton , Jacob Maskiewicz , "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:38:33 -0000 On Mon, Jan 25, 2016 at 11:25 AM, Salz, Rich wrote: >> is/should, or they're going to have other problems. > > Really? > > Some high-value device that is rarely connected-to? Like a missle? If you can't generate 256 random bits for use as a DH key or a client random, anyone can read the connection if they know what the random number generator actually produced. If you can produce 256 random bits, and the device maker was halfway competent, they should know how to turn 256 random bits into computationally indistinguishable infinite stream of random bits. If your missile maker was not halfway competent at computer security, I can only hope the guidance engineers were of the same caliber. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jan 25 12:42:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539BC1A0197 for ; Mon, 25 Jan 2016 12:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRBHTZx7QnSY for ; Mon, 25 Jan 2016 12:42:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id D709B1A0193 for ; Mon, 25 Jan 2016 12:42:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1BAF2433409; Mon, 25 Jan 2016 20:42:36 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 05AF7433404; Mon, 25 Jan 2016 20:42:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453754556; bh=axJlvgSiw+SL3Tt+51YC7VB5ja3ZTr8M7cJl5x8XaNE=; l=120; h=From:To:CC:Date:References:In-Reply-To:From; b=HIrRZ3TYKCIM34BAVSvckztuBMwbP7n5qzww+tPgaxGtdFht3l0gLSM8QxiIejZT4 eKY+mCxcynwU83uhwvoLuMDGKbWGxRKRB4DWASol9hqcsBLgnFz/TOfpdUKZYZNBC0 RFhxRDYAtR4AtXTBwfoU4pMdo9wDZ6Yv6U3wj+wg= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E058E2027; Mon, 25 Jan 2016 20:42:35 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 25 Jan 2016 14:42:35 -0600 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.1076.000; Mon, 25 Jan 2016 14:42:35 -0600 From: "Salz, Rich" To: Watson Ladd Thread-Topic: [TLS] Require deterministic ECDSA Thread-Index: AQHRVhJT9jHjiOXg0EehDwte11nJjZ8J4KoAgAJ3kVCAAKg+gIAAAzuA//+cWjCAAHkVAP//nHhQ Date: Mon, 25 Jan 2016 20:42:34 +0000 Message-ID: <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Joseph Birr-Pixton , Jacob Maskiewicz , "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:42:38 -0000 QW5kIHlvdXIgbGlnaHRidWxiIG1ha2VyPyAgT3IgeW91ciBzdG92ZSBtYWtlcj8gIE9yIHlvdXIg ZnJpZGdlPyAgQWxsIG9uIGNvbWluZyBJb1Q/DQo= From nobody Mon Jan 25 12:54:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5D1B3978 for ; Mon, 25 Jan 2016 11:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 PPWxl4YK48IB for ; Mon, 25 Jan 2016 11:21:48 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD5C1B396F for ; Mon, 25 Jan 2016 11:21:48 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id mw1so37642914igb.1 for ; Mon, 25 Jan 2016 11:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VBB3BKFRKGCZxrKYJ41cdBqWG7btMGZI0m8DlCOw9BY=; b=WO7W0+h3vpIf9IdwGMd3vpHgy/aEzx8VTJLk4jF1KwcBwQBs4d3kpBwdGJY80B3aOu GD+eYV7zCLV1Icfe+ebg/uu0znL2bGyDZEvljrO+eNOCJAIXU1d/NpL/rK6YQJK9O/l8 +Ilv9EjjvitJsH9bYnw95ZmqIuRilUU5ntV8o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VBB3BKFRKGCZxrKYJ41cdBqWG7btMGZI0m8DlCOw9BY=; b=mlhsde4bvF5R2sjJPWY51WPLNB13+aN6gp54EJudQtyPlK6IR2Kd4N080PRlIbbEtJ bXrLjqZna4ORfdEB58nm60xhjf4fNKz19CzNijQRSA/lBEAgo/+5LTYhx468u1YxFviG Q+BHy2stL8UJcsBEwYIu04LLOM+Zz1rqDm3pesIaJo9AGPK0VX0sUveDmB46/efd7h/P LJ2HxE5dEXhSuVE9XrccmYnaSLn26CxXpE5T1iXOYInpgftdxQlsLXvbY50sfOcDFI0l lOnarIwLUJUsdGCii7r+yDRU1MZUhkffj5pHt2B2XPXUnt2Dkm+bTYF28/Ybtv7nuhFX /BEg== X-Gm-Message-State: AG10YOTbgtN2DkW7YZrzcJdfBzgzhwchd4+ofKJmHcJeKknsVOJ3UoBUFjxBgOyEno7kR0R7N9C0c/C6C8pby4pL MIME-Version: 1.0 X-Received: by 10.50.50.9 with SMTP id y9mr19807017ign.46.1453749707909; Mon, 25 Jan 2016 11:21:47 -0800 (PST) Received: by 10.64.2.194 with HTTP; Mon, 25 Jan 2016 11:21:47 -0800 (PST) Received: by 10.64.2.194 with HTTP; Mon, 25 Jan 2016 11:21:47 -0800 (PST) In-Reply-To: <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> Date: Mon, 25 Jan 2016 11:21:47 -0800 Message-ID: From: Jacob Maskiewicz To: Yoav Nir Content-Type: multipart/alternative; boundary=089e01183d14eece8a052a2d7ab3 Archived-At: X-Mailman-Approved-At: Mon, 25 Jan 2016 12:53:59 -0800 Cc: tls@ietf.org, Joseph Birr-Pixton Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:21:49 -0000 --089e01183d14eece8a052a2d7ab3 Content-Type: text/plain; charset=UTF-8 is/should, or they're going to have other problems. -Jake M --089e01183d14eece8a052a2d7ab3 Content-Type: text/html; charset=UTF-8

is/should, or they're going to have other problems.

-Jake M

--089e01183d14eece8a052a2d7ab3-- From nobody Mon Jan 25 14:58:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926A51A1BA5 for ; Mon, 25 Jan 2016 14:58:02 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=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 8la_satUg-xR for ; Mon, 25 Jan 2016 14:58:00 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 4B4AA1A1BA2 for ; Mon, 25 Jan 2016 14:58:00 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id 17so94444554lfz.1 for ; Mon, 25 Jan 2016 14:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y75/osSMXMlFM52WI3vwIvHIAUc2GnhAO7522NVGJ5A=; b=FBUw9lIT5iTzM+I/XxTXmDGmS6blqCEFibw+Dyan3uJykD7tlQIvRFo8YtxGIOx5GN IwSdvUAwHn669Lpab3mFCDKoSnoCiCIJMNiDt/JFTZb4OUwmSImeihAdmaiy8dKwo0G5 P9vr2Wx1CgnIachCYs90hTyfU7rtKdqrlsy7lwrb0zhb3oIJZA+QO2lRUEIV2596kegx 9lRyhtVQbW1kkR0SBNpuOXf7r7HQ39kzQJzi7k+NJ+LAWmA7bBC5ZL7PtzqaQNQF05q/ iWs/1YikP2W6jwuBh6vyIWI8wuhYL+qh7Ya4BmXk3S5kCscKKVJtWVtsdqBwUGeRwrx+ w/Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y75/osSMXMlFM52WI3vwIvHIAUc2GnhAO7522NVGJ5A=; b=DBwCbEbnoO6eTW8W3To8WD7t5E71yCKEk6c8ma51Ctv5TM7Z8cs0Moii2cZqb0eXor GQ17/3yzTzFKFyKBnF7Y1M7O9T331FW1WnGyWKXH8B7MIpJjs533rrNzwvhhSeR+lJxD KtS0vkEVcQ4Hu45MkgHUm04fUWO1pjpxQ3eMJYADJtejUL/WBOhbaN7e2usF5kegPZYp 7iK8lyTuBl8GEGWDK13fjIx9DF7Xdo2vIIanpwjYShlgi9d2YK9vWSF6Ah+r8WJqYJcM DQvix+j2XlmTB1G6qXMgoqv/L9kCLiaKAQOeemCEsWGKrmzb2qXgzXABzDm6BE9kuWmf 68kg== X-Gm-Message-State: AG10YOS8MWvdUlM81fLBCDoh97n+jAV0qOdd2zEAzK5FOVm+E9S5CA0z9o9pHWGVMNpps4DPAdFSnmh/2YCxBQ== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr7770538lfe.8.1453762678519; Mon, 25 Jan 2016 14:57:58 -0800 (PST) Received: by 10.112.2.104 with HTTP; Mon, 25 Jan 2016 14:57:58 -0800 (PST) In-Reply-To: References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <8737u0gpm5.fsf@latte.josefsson.org> Date: Mon, 25 Jan 2016 14:57:58 -0800 Message-ID: From: Joseph Salowey To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113fbdd40a978c052a3080f2 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 22:58:02 -0000 --001a113fbdd40a978c052a3080f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK We'll ask for early code point assignment for ecdh_x25519 (29), ecdh_x448 (30) On Tue, Jan 19, 2016 at 10:59 AM, Andrei Popov wrote: > Yes, please allocate, esp. 25519. MS will start testing interop soon. > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *David Benjamin > *Sent:* Tuesday, January 19, 2016 10:01 AM > *To:* Joseph Salowey ; Brian Smith > *Cc:* Adam Langley ; Simon Josefsson < > simon@josefsson.org>; tls@ietf.org > *Subject:* Re: [TLS] Correction: early codepoint assignment for > Curve25519, Curve448, Ed25519 and Ed448 > > > > BoringSSL has a pair of implementations ready (in C and in our fork of > Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, = so > 29. It's not currently enabled in any Chrome builds, but I'm expecting to > change this soon. > > > David > > > > On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey wrote: > > Any objections to early allocation for X25519 and X448? Are there > implementers with code ready to test interop? > > > > Thanks, > > > > Joe > > > > On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith wrote= : > > Simon Josefsson wrote: > > Allocating a code point for X25519 could be done and is long overdue > (first draft September 2013). X448 is also stable. Code points for > Ed25519 and Ed448 is more problematic since TLS authentication has > historically had interaction with PKIX certs. I agree with Yoav's > assertion that the curve point verification issue is not big enough to > stall code point allocation. > > > > I agree with this. > > > > Cheers, > > Brian > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --001a113fbdd40a978c052a3080f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK We'll ask for early code point assignment for=C2=A0= 

ecdh_x25519 (29), ecdh_x448 (30)

O= n Tue, Jan 19, 2016 at 10:59 AM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:

Yes, please allocate, esp. 25519. MS = will start testing interop soon.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of David Benjamin
Sent: Tuesday, January 19, 2016 10:01 AM
To: Joseph Salowey <joe@salowey.net>; Brian Smith <brian@briansmith.org>
Cc: Adam Langley <agl@imperialviolet.org>; Simon Josefsson <simon@josefsson.org>;= tls@ietf.org
Subject: Re: [TLS] Correction: early codepoint assignment for Curve2= 5519, Curve448, Ed25519 and Ed448

=C2=A0

BoringSSL has a pair of implementations ready (in C = and in our fork of Go's TLS stack for testing). We're using the val= ue in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrom= e builds, but I'm expecting to change this soon.


David

=C2=A0

On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey <= joe@salowey.net>= ; wrote:

Any objections to early allocation for X25519 and X4= 48?=C2=A0 Are there implementers with code ready to test interop? =C2=A0=

=C2=A0

Thanks,

=C2=A0

Joe

=C2=A0

On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith <brian@briansmith.org= > wrote:

Simon Josefsson <simon@josefsson.org> wrote:

Allocating a code point for X25519 could be done and= is long overdue
(first draft September 2013).=C2=A0 X448 is also stable.=C2=A0 Code points = for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.=C2=A0 I agree with Yoav's=
assertion that the curve point verification issue is not big enough to
stall code point allocation.

=C2=A0

I agree with this.

=C2=A0

Cheers,

Brian

=C2=A0

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


--001a113fbdd40a978c052a3080f2-- From nobody Mon Jan 25 15:11:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96671A1BE9 for ; Mon, 25 Jan 2016 15:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSrYpYJHsia5 for ; Mon, 25 Jan 2016 15:11:07 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 270D91A1BED for ; Mon, 25 Jan 2016 15:11:07 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id CFD0C9A413A for ; Mon, 25 Jan 2016 18:11:06 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id LpTGgyUg4tG6 for ; Mon, 25 Jan 2016 18:09:58 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 496219A4132 for ; Mon, 25 Jan 2016 18:11:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <3922672.SasYckhRS6@pintsize.usersys.redhat.com> Date: Mon, 25 Jan 2016 18:11:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <275D7C71-340A-448D-B0FA-1250AD06AED6@vigilsec.com> References: <56A192FC.4060206@brainhub.org> <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> <56A64D5E.7090104@akamai.com> <3922672.SasYckhRS6@pintsize.usersys.redhat.com> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 23:11:08 -0000 On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote: > On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: >> On 01/22/2016 01:14 PM, Hubert Kario wrote: >>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: >>>> On 01/22/2016 03:14 AM, Hubert Kario wrote: >>>>>> The only solution that's available at this point is conditioning >>>>>> TLS >>>>>> 1.3 support on appropriate hardware. For this reason TLS 1.3 it >>>>>> probably won't be enabled by default in the product I work on. I >>>>>> would prefer for TLS 1.3 to be enabled by default and write the >>>>>> code >>>>>> to decide whether it does PSS or falls back to RSA PKCS1 1.5. >>>>>=20 >>>>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not >>>>> cutting it off now would be negligent. >>>>=20 >>>> You mean for HS only, while leaving it for X.509 certs? >>>=20 >>> If we don't do it for HS in TLS first, we'll never get rid of it in >>> X.509 certs. >>>=20 >>> We need to start somewhere, and it's more reasonable to expect that >>> hardware with support for new protocols will get updated for RSA-PSS >>> handling than that libraries and hardware will suddenly start >>> implementing it in droves just in anticipation of the time when CAs >>> _maybe_ will start issuing certificates signed with RSA-PSS. >>=20 >> Isn't it more a matter of TLS being a consumer of external PKIX >> infrastructure, the web PKI, etc.? They are out of the reach of the >> IETF TLS working group; any requirements we attempted to impose would >> be unenforceable, even if there was an Internet Police (which there >> is not). >=20 > TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how=20 > exactly is creating a side effect of increasing the deployment rate of=20= > RSA-PSS _in TLS implementations_ an "overreach"?! I have been a supporter of PSS for a very long time -- see RFC 4055. We have many algorithm transition issues, but this is one place where we = have seen very little progress. I would like to see support for PSS in = the protocol, even if we need to support PKCS v1.5 for certificate = signatures for a long time. Russ From nobody Mon Jan 25 16:41:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69C11AC3E9 for ; Mon, 25 Jan 2016 16:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 PR8KrNPDBAwb for ; Mon, 25 Jan 2016 16:41:49 -0800 (PST) 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 7017A1AC3E6 for ; Mon, 25 Jan 2016 16:41:49 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 77so169957509ioc.2 for ; Mon, 25 Jan 2016 16:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ej9ko5wvlpJwrjjQnO52g2Gk8zIeQQMvChIp7TWUb+A=; b=HJn86j23e2yVZdn+6/QPInoy5xA25DzC09UVoLoLgHp0HbYr659OFyynM1G0XyejyJ /d/a/VLoqOXxfQ7U3nzo97iBFawSDm0R1DXm1fUPGpBdBtZqzgtsB3lanrgsluqOKAZ1 pJGb5ZfI0ephFeeuUXEcgMAS0NpScWQ8GSztqB/MTvW3FD+9zyOkZDcpNk7zPBuhbAH2 IKqQLociYPOJOgsLQX7oydZEMiU5ak7776RFf6F+25JDRiPelOUXmIY/PiqAnjXm4u02 vP17arjnKS2Bmh5BPk2WlJFpO+K3zDYBc6IJYuxfjMg4wEqjKpo9NGmOmYqXPZATskI6 d89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ej9ko5wvlpJwrjjQnO52g2Gk8zIeQQMvChIp7TWUb+A=; b=WkuN0GiHO+X23nC6ltzlQIGKDu2YGFrYQlJrz65fq2sdJKGfgmq3WMG+znCDuKv6Aq qcS+A8gQ3NCMV7SXc23Z4l31rN5yHFYADR/ZVVxq8fb8r3pKM0AjuDj6dy1F7hQHMeKX VmbK1wm10OSQIDh+Ubpyx5J+zR6osh++cN1YfLf1fKNDZSVCC96dzqbtdvupBGkwx61m KL4kVguYCt7Lvk8yOy4F68A7X8UH11jfY4QCzupIDW3a4YIQ36ApkxFaylN2EahtqcSi epKta3LRl/ygfZqgRupw29IL3Dm4Lvwu8NNu41hRoRbKbzBCX1fhagmYyFYM6mI0TQEV C8sw== X-Gm-Message-State: AG10YOQ6EFMDpCNbxVDwGO1rhb0QdQc+T6TCNGet6WyDzAHE9Ad44m3mxOuJYnSGWTkW+rxvyAkVrmIDXq1HDl/y MIME-Version: 1.0 X-Received: by 10.107.132.231 with SMTP id o100mr20508409ioi.60.1453768908670; Mon, 25 Jan 2016 16:41:48 -0800 (PST) Received: by 10.107.141.12 with HTTP; Mon, 25 Jan 2016 16:41:48 -0800 (PST) In-Reply-To: <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 25 Jan 2016 16:41:48 -0800 Message-ID: From: Bill Cox To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113ebf5463611e052a31f3c8 Archived-At: Cc: Jacob Maskiewicz , Joseph Birr-Pixton , "tls@ietf.org" Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 00:41:50 -0000 --001a113ebf5463611e052a31f3c8 Content-Type: text/plain; charset=UTF-8 Just an off-topic point about the missile example... Thankfully, the Air Force seems to have the sense to follow the KISS rule now and then. I would be shocked to see TLS in the launch flow :) Can you imagine the handshake? Hopefully this humorous rather than poor taste: Command: Here's everything you need in one flight of packets to launch. Missile: Please send a CertificateVerify, and let's do a 1-RTT. I'll just ignore that launch command. Here's my new server-config so you can learn to speak to me properly. I rotate it ever 7 years to provide forward-secrecy. Command: Here's my cert, and another launch command. I was supposed to resend it, right? Let's not tell the application layer that I sent the launch command twice, or that my first flight is replayable. Missile: Symantec, really? What about certificate transparency? Was I supposed to include that first launch command in the handshake hash? :-p I have low expectations for IoT vendors' TRNGs. When deadlines get tight, good engineering on the TRNG is easy to drop. As long as they whiten the output, it is very difficult to detect TRNG flaws, so there is little incentive to put in much engineering. IIRC, the FIPS standard requires vendors to be secretive about their TRNGs. They are not allowed to give us access to the raw data from the entropy source, and cannot show us schematics for their design, making it nearly impossible to differentiate a well designed TRNG from an insecure one. Basically, it is a poor assumption that the TRNG is any good. Sure, it's required for secure crypto, but whatever... Bill --001a113ebf5463611e052a31f3c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just= an off-topic point about the missile example... Thankfully, the Air Force = seems to have the sense to follow the KISS rule now and then.=C2=A0 I would= be shocked to see TLS in the launch flow :) =C2=A0Can you imagine the hand= shake?=C2=A0 Hopefully this humorous rather than poor taste:

Command: Here's = everything you need in one flight of packets to launch.
Missile: Please send a CertificateVerify, and let's do a 1= -RTT.=C2=A0 I'll just ignore that launch command.=C2=A0 Here's my n= ew server-config so you can learn to speak to me properly.=C2=A0 I rotate i= t ever 7 years to provide forward-secrecy.
= Command: Here's my cert, and another launch command.=C2=A0 I was suppos= ed to resend it, right?=C2=A0 Let's not tell the application layer that= I sent the launch command twice, or that my first flight is replayable.
Missile: Symantec, really?=C2=A0 What about c= ertificate transparency?=C2=A0 Was I supposed to include that first launch = command in the handshake hash? =C2=A0:-p
I have low expectations for IoT vendors&= #39; TRNGs.=C2=A0 When deadlines get tight, good engineering on the TRNG is= easy to drop.=C2=A0 As long as they whiten the output, it is very difficul= t to detect TRNG flaws, so there is little incentive to put in much enginee= ring.=C2=A0 IIRC, the FIPS standard requires vendors to be secretive about = their TRNGs.=C2=A0 They are not allowed to give us access to the raw data f= rom the entropy source, and cannot show us schematics for their design, mak= ing it nearly impossible to differentiate a well designed TRNG from an inse= cure one.

Basically, it is a poor assumption that the TRNG is any good.=C2=A0= Sure, it's required for secure crypto, but whatever...

Bill
--001a113ebf5463611e052a31f3c8-- From nobody Mon Jan 25 19:33:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B301B2D6D for ; Mon, 25 Jan 2016 19:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 3Kn-CWlacsyK for ; Mon, 25 Jan 2016 19:33:05 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DD31B2D68 for ; Mon, 25 Jan 2016 19:32:59 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-10v.sys.comcast.net with comcast id ATYs1s00157bBgG01TYztC; Tue, 26 Jan 2016 03:32:59 +0000 Received: from [192.168.2.3] ([76.103.100.237]) by resomta-po-13v.sys.comcast.net with comcast id ATYx1s00D57Jnqc01TYyvs; Tue, 26 Jan 2016 03:32:59 +0000 From: Andrey Jivsov To: tls@ietf.org References: <56A192FC.4060206@brainhub.org> <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> <56A64D5E.7090104@akamai.com> <3922672.SasYckhRS6@pintsize.usersys.redhat.com> <275D7C71-340A-448D-B0FA-1250AD06AED6@vigilsec.com> Message-ID: <56A6E8E9.8090902@brainhub.org> Date: Mon, 25 Jan 2016 19:32:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <275D7C71-340A-448D-B0FA-1250AD06AED6@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453779179; bh=SMlVU7eDAb0D5hUcM6x3IfOLXzoqROAWMPnwQESHF14=; h=Received:Received:From:Subject:To:Message-ID:Date:MIME-Version: Content-Type; b=BcDPJGQhyHoOFaYxhy+JgqaCed1pQOZjxRlkKT5VJe4W88FnZwV/5vK2m5Zyg8JW3 lObOcoEmX6E0AUAatPyzrIoEYGIxgukQ5VA4wk0oW+ErrjF+cmr6dEnSMAfdjHGI4H knS/dkI9vfOannPmA+tGZnUVYPqOKKkCC56ywJl18BaGozcG+0ypt6x3DPqbQI6MQ1 iSQOBahiLBgxIjtp0VjbJYu516H9F2BDF8mLPGXqb/C37gflDByScHWAzLY98eXeFl yRKXfoXSP0wsiGbe3bNmQMBRo5IIdzPs/gtRcW0QWk+jeavN46wYKysp7wRafIq9+/ y3J7mbzgfgi+g== Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 03:33:07 -0000 On 01/25/2016 03:11 PM, Russ Housley wrote: > On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote: > >> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: >>> On 01/22/2016 01:14 PM, Hubert Kario wrote: >>>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: >>>>> On 01/22/2016 03:14 AM, Hubert Kario wrote: >>>>>>> The only solution that's available at this point is conditioning >>>>>>> TLS >>>>>>> 1.3 support on appropriate hardware. For this reason TLS 1.3 it >>>>>>> probably won't be enabled by default in the product I work on. I >>>>>>> would prefer for TLS 1.3 to be enabled by default and write the >>>>>>> code >>>>>>> to decide whether it does PSS or falls back to RSA PKCS1 1.5. >>>>>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not >>>>>> cutting it off now would be negligent. >>>>> You mean for HS only, while leaving it for X.509 certs? >>>> If we don't do it for HS in TLS first, we'll never get rid of it in >>>> X.509 certs. >>>> >>>> We need to start somewhere, and it's more reasonable to expect that >>>> hardware with support for new protocols will get updated for RSA-PSS >>>> handling than that libraries and hardware will suddenly start >>>> implementing it in droves just in anticipation of the time when CAs >>>> _maybe_ will start issuing certificates signed with RSA-PSS. >>> Isn't it more a matter of TLS being a consumer of external PKIX >>> infrastructure, the web PKI, etc.? They are out of the reach of the >>> IETF TLS working group; any requirements we attempted to impose would >>> be unenforceable, even if there was an Internet Police (which there >>> is not). >> TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how >> exactly is creating a side effect of increasing the deployment rate of >> RSA-PSS _in TLS implementations_ an "overreach"?! > I have been a supporter of PSS for a very long time -- see RFC 4055. > > We have many algorithm transition issues, but this is one place where we have seen very little progress. I would like to see support for PSS in the protocol, even if we need to support PKCS v1.5 for certificate signatures for a long time. Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5} with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#1 1.5} were available in both HS and X.509 certs? This should be balanced against the reality that PSS in HS with TLS 1.3 guarantees lower TLS 1.3 adoption as I wrote above. PSS-only in TLS 1.3 HS may make code more complex as well. I am trying to imagine a logic that a TLS 1.3 client supporting smartcard client authentiation would need to implement, assuming mandatory PSS signing in HS, e.g. a case of Firefox + PKCS#11 interface with a smartcard. First, the code should query (attached? logged-in?) smartcard(s) to determine if the key(s) on the smartcard that might be used for client authentication can do PSS signing. PKCS#11 interface lists the PSS capability as CKM_SHA256_RSA_PKCS_PSS mechanism. If no such PSS+hash mechanism is available, the code needs to tag the keys(s) as TLS 1.2-only. When the client connects to a TLS 1.3 server and the server requests client authentication with the non-PSS key, I think this will require protocol dance down to TLS 1.2 (insecure TLS fallback). Alternatively, the client will need to start from TLS 1.2 when it detected such a smartcard, for any server. The underlying reasons why CAs can't sign with PSS v.s. TLS server or client are probably overlapping in many cases: FIPS 140, HSM, hardware. The all-or-nothing approach to PSS sin HS eems inconsistent with traditional feature negotiation in TLS HS. > Russ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jan 26 04:33:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829921B2FDD for ; Tue, 26 Jan 2016 04:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZWQ1FvT9i6M for ; Tue, 26 Jan 2016 04:33:46 -0800 (PST) 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 B91231B2FDF for ; Tue, 26 Jan 2016 04:33:46 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 219927AEBB; Tue, 26 Jan 2016 12:33:45 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-119.brq.redhat.com [10.34.0.119]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0QCXip1009674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 07:33:45 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 26 Jan 2016 13:33:39 +0100 Message-ID: <2364111.L6yuPLgJru@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <56A6E8E9.8090902@brainhub.org> References: <56A192FC.4060206@brainhub.org> <275D7C71-340A-448D-B0FA-1250AD06AED6@vigilsec.com> <56A6E8E9.8090902@brainhub.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6765942.Xm4R95azFF"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 12:33:48 -0000 --nextPart6765942.Xm4R95azFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 25 January 2016 19:32:57 Andrey Jivsov wrote: > On 01/25/2016 03:11 PM, Russ Housley wrote: > > On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote: > >> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: > >>> On 01/22/2016 01:14 PM, Hubert Kario wrote: > >>>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: > >>>>> On 01/22/2016 03:14 AM, Hubert Kario wrote: > >>>>>>> The only solution that's available at this point is > >>>>>>> conditioning > >>>>>>> TLS > >>>>>>> 1.3 support on appropriate hardware. For this reason TLS 1.3 > >>>>>>> it > >>>>>>> probably won't be enabled by default in the product I work on= . > >>>>>>> I > >>>>>>> would prefer for TLS 1.3 to be enabled by default and write > >>>>>>> the > >>>>>>> code > >>>>>>> to decide whether it does PSS or falls back to RSA PKCS1 1.5.= > >>>>>>=20 > >>>>>> Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not= > >>>>>> cutting it off now would be negligent. > >>>>>=20 > >>>>> You mean for HS only, while leaving it for X.509 certs? > >>>>=20 > >>>> If we don't do it for HS in TLS first, we'll never get rid of it= > >>>> in > >>>> X.509 certs. > >>>>=20 > >>>> We need to start somewhere, and it's more reasonable to expect > >>>> that > >>>> hardware with support for new protocols will get updated for > >>>> RSA-PSS > >>>> handling than that libraries and hardware will suddenly start > >>>> implementing it in droves just in anticipation of the time when > >>>> CAs > >>>> _maybe_ will start issuing certificates signed with RSA-PSS. > >>>=20 > >>> Isn't it more a matter of TLS being a consumer of external PKIX > >>> infrastructure, the web PKI, etc.? They are out of the reach of > >>> the > >>> IETF TLS working group; any requirements we attempted to impose > >>> would > >>> be unenforceable, even if there was an Internet Police (which > >>> there > >>> is not). > >>=20 > >> TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how= > >> exactly is creating a side effect of increasing the deployment rat= e > >> of RSA-PSS _in TLS implementations_ an "overreach"?! > >=20 > > I have been a supporter of PSS for a very long time -- see RFC 4055= . > >=20 > > We have many algorithm transition issues, but this is one place > > where we have seen very little progress. I would like to see > > support for PSS in the protocol, even if we need to support PKCS > > v1.5 for certificate signatures for a long time. > Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5} > with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#= 1 > 1.5} were available in both HS and X.509 certs? Because if PKCS#1 1.5 is available for HS, many implementations still=20= won't implement PSS and we won't move one step. OTOH, if the PSS is=20 mandatory, they have a clear need to add this support. 8% of servers in Alexa top 1 million websites still won't sign the=20 Server Key Exchange with anything but SHA-1[1], despite the fact that=20= you need to have an implementation of SHA-256 to implement TLSv1.2 in=20= the first place. > The underlying reasons why CAs can't sign with PSS v.s. TLS server or= > client are probably overlapping in many cases: FIPS 140, HSM, > hardware. The all-or-nothing approach to PSS sin HS eems inconsistent= > with traditional feature negotiation in TLS HS. PSS in X.509 is not usable now because only fraction of clients and=20 servers support it. That's why CA's don't sign certificates with it - t= o=20 minimize support costs and reissue rates (in cases the customer finds=20= out that he needs the "legacy" certificate). 1 - https://securitypitfalls.wordpress.com/2015/12/07/november-2015-sc= an-results/ =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 99/71, 612 45, Brno, Czech Republi= c --nextPart6765942.Xm4R95azFF 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 iQIcBAABCgAGBQJWp2ejAAoJEJKo0bgB0vX1XeIP/iy7S98s5j1wQa0WFOrxqV0p /gJh38O0G8J7M6BHTtFgzPQ72uuCXD/VZKFsZqA2fIQfY3BOBa9V6OZlRMttqlwd MrJU2PPdvGkxAVtCus/xTmEfgR3g2YfPzSCA+GNyUk9+1hL+nkZaTGY1iWZsgtkP si0WGXTeLL3Tk57Lrp+XkuNaxv8At9h8bFaMgTB8QdVZ5jsPBsTUP+XQvUnbOwzh k9FXwVthL45UXiNFJB7x5N7upD/gKubOt0k3ewgvnauvc5DLwujMBNJDIhUxbt3i 5WuZygSLlErRRgJsv9aeYFdcqbrfAHOaIzXyRFo3l6hCrwVNs9j7EMbpKrpvD3qB iPr32z7qCoKkKuEkutFgK70euSKjF4EFAgKq45ztoH0FIsDT8P5bbgLq0gguGL9C 8xTvQT94Gv2qxxsFRNH166tOiHnO4I0jSK0lSWfU65wb5pQAJRWGJGBahcv3Klhj k0YwtkG0Bp6CcUgsy9B/hQ0KZqKB/YHWFaHG5+3OBHV8MH91/WPTsCNuIa8wAr2L eGm6CzGQnt1aLh2vYw0bZbHB3J6RmmiNLsncGcy9pMIWWrXWrb1QhQ+vDElLdYLg CQmGfpRmIn6m7EZixQ7FsvaB9kJxQvlJqegqCal4JQMlRmtTBGn88yMAj9vU+PC8 TPJUDOkF4kTviWChEADG =Wric -----END PGP SIGNATURE----- --nextPart6765942.Xm4R95azFF-- From nobody Tue Jan 26 10:37:58 2016 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 740E71B2B51; Tue, 26 Jan 2016 10:37:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160126183755.22242.79851.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 10:37:55 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-22.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 26 Jan 2016 18:37:55 -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 Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-22.txt Pages : 18 Date : 2016-01-26 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-cached-info-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 14:22:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E90D1B3256 for ; Tue, 26 Jan 2016 14:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSnYilB0krqZ for ; Tue, 26 Jan 2016 14:22:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C131B3253 for ; Tue, 26 Jan 2016 14:22:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97BEBBE47 for ; Tue, 26 Jan 2016 22:21:58 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SeOxdtO6RzL for ; Tue, 26 Jan 2016 22:21:57 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.16.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1373BE3F for ; Tue, 26 Jan 2016 22:21:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453846917; bh=dzaXcKdLVYku1/uMuiAthv8oLryWv+36qxrxeJFyiq8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=vxf/70VBBsHyQCYKry0gecH4kuYBLfjHMU4CG7Bud6A/MoGMVpgE3MLhnw8L8CG5b SZhWZ89FPvyaP1zLXqNfID/GvkVIU+Nc3G+W6920b1TxZmHupI/En17VtLhUYQPA6i hEVJGxbkNpHXs/jwycwPHfnCM1EDSjxDQ07S8P6c= References: <20160126183755.22242.79851.idtracker@ietfa.amsl.com> To: tls@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56A7F184.5000506@cs.tcd.ie> Date: Tue, 26 Jan 2016 22:21:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160126183755.22242.79851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-cached-info-22.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 22:22:03 -0000 Hi all, I plan to send the approval message for this tomorrow but wanted to just check one thing first. In his IESG review [1] Barry Leiba suggested reserving the value zero in the registry created by section 8.2, which makes sense I think as otherwise people will just be puzzled about what to do with zero later on;-) So, I've added a note [2] for the IANA folks to do that as they process this draft. If that's wrong, please yell and I'll fix it before we send this to the RFC editor. If nobody yells, I'll do that tomorrow. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ballot/#barry-leiba [2] https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/writeup/ On 26/01/16 18:37, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Transport Layer Security (TLS) Cached Information Extension > Authors : Stefan Santesson > Hannes Tschofenig > Filename : draft-ietf-tls-cached-info-22.txt > Pages : 18 > Date : 2016-01-26 > > Abstract: > Transport Layer Security (TLS) handshakes often include fairly static > information, such as the server certificate and a list of trusted > certification authorities (CAs). This information can be of > considerable size, particularly if the server certificate is bundled > with a complete certificate chain (i.e., the certificates of > intermediate CAs up to the root CA). > > This document defines an extension that allows a TLS client to inform > a server of cached information, allowing the server to omit already > available information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-cached-info-22 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-22 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jan 26 15:08:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84D71B32E5 for ; Tue, 26 Jan 2016 15:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSH_iKwLaxFQ for ; Tue, 26 Jan 2016 15:08:27 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0210A1B32E3 for ; Tue, 26 Jan 2016 15:08:26 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E53A9433401; Tue, 26 Jan 2016 23:08:25 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CC09A4F0CD; Tue, 26 Jan 2016 23:08:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453849705; bh=72tUeU4c777vReDUDvqXa7zOHKRII94obTROkk6BEKI=; l=1466; h=To:References:From:Date:In-Reply-To:From; b=sFsfTn9Rrgz5BnOoltKwfxAfcl6VPjWVHL2CJ3JdK1fEncduujx/RAfbrkryC1Hwx wqcs01tXFfdzESehT20aAXXcPO5i/pnRnYof9VQ4brtq1dyiRpQvMxptXazMOMynKN kxXsxluYd+Lkki8t85iVXGGkOr87XtcTdr1MgDsw= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 9888B2030; Tue, 26 Jan 2016 23:08:25 +0000 (GMT) To: Hubert Kario , tls@ietf.org References: <56A192FC.4060206@brainhub.org> <35455210.tz7m1zDUF6@pintsize.usersys.redhat.com> <56A64D5E.7090104@akamai.com> <3922672.SasYckhRS6@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: <56A7FC69.1040601@akamai.com> Date: Tue, 26 Jan 2016 17:08:25 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <3922672.SasYckhRS6@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 23:08:29 -0000 On 01/25/2016 01:43 PM, Hubert Kario wrote: > On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: >> On 01/22/2016 01:14 PM, Hubert Kario wrote: >>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: >>> If we don't do it for HS in TLS first, we'll never get rid of it in >>> X.509 certs. We need to start somewhere, and it's more reasonable to >>> expect that hardware with support for new protocols will get updated >>> for RSA-PSS handling than that libraries and hardware will suddenly >>> start implementing it in droves just in anticipation of the time >>> when CAs _maybe_ will start issuing certificates signed with RSA-PSS. >> Isn't it more a matter of TLS being a consumer of external PKIX >> infrastructure, the web PKI, etc.? They are out of the reach of the >> IETF TLS working group; any requirements we attempted to impose would >> be unenforceable, even if there was an Internet Police (which there >> is not). > TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how > exactly is creating a side effect of increasing the deployment rate of > RSA-PSS _in TLS implementations_ an "overreach"?! There seems to be some confusion here; I am saying it would be an overreach for us to insist that the X.509 certs we get use PSS. The best sense I can make out of this statement is that it is a response to a claim that requiring PSS for TLS handshakes would be an overreach (it is not). Am I confused? -Ben From nobody Tue Jan 26 15:48:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3D01A00F4 for ; Tue, 26 Jan 2016 15:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z078T9kk3xDG for ; Tue, 26 Jan 2016 15:48:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537801A00ED for ; Tue, 26 Jan 2016 15:48:23 -0800 (PST) Received: from [192.168.10.131] ([12.147.0.33]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MNdxu-1aQzZT2tx4-007FQ5; Wed, 27 Jan 2016 00:48:18 +0100 To: Stephen Farrell , tls@ietf.org References: <20160126183755.22242.79851.idtracker@ietfa.amsl.com> <56A7F184.5000506@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56A805C5.8050109@gmx.net> Date: Wed, 27 Jan 2016 00:48:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7F184.5000506@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d5bpUDqoAUXEFCeRdEc3hVd2xPJIB43M6" X-Provags-ID: V03:K0:K7PZPT57N1L3rWtmQGfDSfypsB1JgV3avIvKnOL5Mm4xLjqXhjJ 6aHvjz6kF5JdoRWf+45d399ZjpNVrfdD+R5+aXbrIcbAtUBtX0Gf43we5sBtTs9574D1n7Q wXm9BYZdz7nIPlLTdxJVhjBDAFnqIvO+04BgfDwHD45+neBYk1TM32/3pFGZY3VUT2H90c+ OZECbT9nVdZew9B4lMDIw== X-UI-Out-Filterresults: notjunk:1;V01:K0:dfvzRJVESzo=:kCjxD4LeBGQ3W02524vd2c ZAmAKcQIMO+AmEZHiLnNYkuqDRst93x7P4kfb2W8QTHhOeBCjXMIvitK7WnQwemWjKqjHReZT DNWC5p3Vdkv+vxlncgAdcD2IsvDPoYnKGy+6sYfpppD6RW4yPPprPrbjCXF92Fy8xA9WSsqZb hrG8bNUE+xGxXuh+g4goGkIxBCQZ4YUBJsLyR+n2VvyXwCPdhW5ff5UqsX7fyFrg5G7z/H5kI 4f9HgbEwHBb78FMx0JS6KNHVHpAop+toMJS2WG6lrLuI38XDCy3pOY+3em0RaFIKk8tSBCGJ1 xI7xQi9grurIf7Cy7npnACBvabeVF7n4tn2qpiz+4qZZy/yFFArHbL9yXHQoBQ7u01vMzNDfa 9sKgsgTxe3S9pe69f+YkV4g8vOmOdu2poCTLZMI64Ua6TxWtrN8RuN3cpRLskvxSGebza1eb2 9qom8CCZnDAxhx1yUPxsmUsXhMusc4RMGfPhCb3bL0XOm7XUzWBDl9U/jPhruXQk1Vtfy2v8F lnNhq8f5jQmjCiFNDB1spwZbXCH/uPCKFjS9xpeQf02ckTcC7QxiCRSKUjUc2AMo4JhufMJYh 8secPsTBoJuUjhKDmfKx6mswP36pmu70tU7W2ifrZT9xx5/c0D3PQn5RvdlMntRUTfXlrwl8g tC87TNWwTiw8FXzn0HYjLiw9FRp3XzOkLEUz/2BGd9QWrvMG/qTg+u5stgkd73RqCAsKFRWu+ 9S30+MrOwZidK4/5o0YYvYDlBm9N3ocm9DwJQK0IwqOLSbwjK4diVdks0VJ+vXIVsAg1AYmYt 86vvUkLF3WEbAqZi59cuEawMjJY1DDhsBhnE+tDZFKuuwN8jQFEZs7tIt9pa5XML5EcGCW7WP nivN27tI/DUK1OLATzUl04/alyQejGYIDf0lXw6fU= Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-cached-info-22.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jan 2016 23:48:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d5bpUDqoAUXEFCeRdEc3hVd2xPJIB43M6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, thanks for pointing to the review provided by Barry. If you want, I can also issue a version -23 where I change the IANA consideration section to avoid having the value zero unassigned Ciao Hannes On 01/26/2016 11:21 PM, Stephen Farrell wrote: >=20 > Hi all, >=20 > I plan to send the approval message for this tomorrow but > wanted to just check one thing first. In his IESG review [1] > Barry Leiba suggested reserving the value zero in the registry > created by section 8.2, which makes sense I think as otherwise > people will just be puzzled about what to do with zero later > on;-) >=20 > So, I've added a note [2] for the IANA folks to do that as they > process this draft. >=20 > If that's wrong, please yell and I'll fix it before we send > this to the RFC editor. If nobody yells, I'll do that tomorrow. >=20 > Cheers, > S. >=20 > [1] > https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ballot/#bar= ry-leiba > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/writeup= / >=20 > On 26/01/16 18:37, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Transport Layer Security Working Gro= up of the IETF. >> >> Title : Transport Layer Security (TLS) Cached Inform= ation Extension >> Authors : Stefan Santesson >> Hannes Tschofenig=20 >> Filename : draft-ietf-tls-cached-info-22.txt >> Pages : 18 >> Date : 2016-01-26 >> >> Abstract: >> Transport Layer Security (TLS) handshakes often include fairly stat= ic >> information, such as the server certificate and a list of trusted >> certification authorities (CAs). This information can be of >> considerable size, particularly if the server certificate is bundle= d >> with a complete certificate chain (i.e., the certificates of >> intermediate CAs up to the root CA). >> >> This document defines an extension that allows a TLS client to info= rm >> a server of cached information, allowing the server to omit already= >> available information. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tls-cached-info-22 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-cached-info-22 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --d5bpUDqoAUXEFCeRdEc3hVd2xPJIB43M6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWqAXGAAoJEGhJURNOOiAtPSEH/i1KCrVnIFlibB6hcxgqE8c5 l/N5L5QUFNeGxSLqpbym5KPywViuXjCNRqkiWX92MZcUeFvDELqgCby1MRbjRBwy 1zq6AFh0BsH+p+1ObEifBWbrj+deWthNbY5EBHsKoih8ebAark5iVx7uxsCpRwN0 G5p/DVGuicmTCKnQj7bli0jpOibJJyBvfmhksVLhN03mkUAP8D8Ic8QM7XQhAGTL ImzErYNhqeep6sPp1SrMaAl2tgz8qUE1m/IWVTzh5fKKDEX47N8is6LIsn+oIgf8 Tjyhwi9hq4q6qx1Q4l4vHVGPXxxfKVZyg9Th8tBwS13m9WhkxvkKcwzcA3E3zNA= =E0Xs -----END PGP SIGNATURE----- --d5bpUDqoAUXEFCeRdEc3hVd2xPJIB43M6-- From nobody Tue Jan 26 16:46:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADAA1A1A92 for ; Tue, 26 Jan 2016 16:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 8HFaNsSkgUSb for ; Tue, 26 Jan 2016 16:46:25 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BFF1A1A90 for ; Tue, 26 Jan 2016 16:46:24 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id t15so72505550igr.0 for ; Tue, 26 Jan 2016 16:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=9gUlr6CQ8814qqylfXj1XCBtCkth/cAeIw/SjBM7k6M=; b=hxOTzPNSXb3G4Fm1wkKUXH+BrFxV0eELJahPldewebcf7AmLsBpdeyqVX/bdVKqiNE 00aeww43nwlgITcTxivcDdGOx1ioNG6JGJwgMdA+64u71/FOjvDK5UOZZpUv/n/haPgt XVNEo+peV8HPmNv/tdrFa1vNxFfrFHHpFfpso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=9gUlr6CQ8814qqylfXj1XCBtCkth/cAeIw/SjBM7k6M=; b=gVPvc+P/XMonh0b6BTeUrmyfMCdmyRIbet3zjG8HnQXrBPksomL6BLJGMQVOsVttv+ REf57dCM3dkn/RmdLHhI+c6l6ucNB2KCHFdDN6GAVu1M04OBd1lZxXyQGqCIGVF6HdM2 j1enzQYBO5CRRqx/T7IZTbF+kPAq/5bYQnLhvg1Sz9818wq6eOK1KOoZnsSgKgNSa4CQ 2bWpUyfFh2ACQQRUKdqJCm5Mpk6pWs6/YbGPlaRLUStaFjHZyA2nuam6D6Dl3fcGHIBc J0+oAEjZ8jBq+iKRi2W4e/hEFdLn2IRuDFSF7GJtjfFr/6/z/P0ertxz8QJYkJ1j6BRo UrCw== X-Gm-Message-State: AG10YORjcocqNK83PQO+g9gnG8zHkrhDoyKWfDavpvxI3Jv5ioiStJ783TwafPU+TfwqStrvpCC3ZYk7CPhSle/I X-Received: by 10.50.8.106 with SMTP id q10mr24899485iga.67.1453855584072; Tue, 26 Jan 2016 16:46:24 -0800 (PST) MIME-Version: 1.0 From: David Benjamin Date: Wed, 27 Jan 2016 00:46:13 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013c65dca50b01052a4621b1 Archived-At: Subject: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 00:46:26 -0000 --089e013c65dca50b01052a4621b1 Content-Type: text/plain; charset=UTF-8 It's possible I'm reading the draft wrong, so this thread may be a very short one. (t here is in units of RTT, so t=0 is when the client sends ClientHello and t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is when the client receives ServerHello, etc.) Looking at the Zero-RTT exchange here: https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 Is the intention that the client, even in the successful 0-RTT case, send two Finished messages (one at t=0 and one at t=1) and that the server not send application data until receiving the second of these at t=1.5? If so, does this not defeat the purpose of 0-RTT? Although the client now eagerly sends at t=0, it will not see the response until t=2, which is no better than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send until t=1. David --089e013c65dca50b01052a4621b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's possible I'm reading the draft wrong, so this= thread may be a very short one.

(t here is in units of = RTT, so t=3D0 is when the client sends ClientHello and t=3D0.5 is when the = server receives ClientHello and sends ServerHello, t=3D1 is when the client= receives ServerHello, etc.)

Looking at the Ze= ro-RTT exchange here:
https://tlswg.github.io/tls13-spec= /#rfc.section.6.2.2

Is the intention that the client, even in th= e successful 0-RTT case, send two Finished messages (one at t=3D0 and one a= t t=3D1) and that the server not send application data until receiving the = second of these at t=3D1.5? If so, does this not defeat the purpose of 0-RT= T? Although the client now eagerly sends at t=3D0, it will not see the resp= onse until t=3D2, which is no better than the resumption case (in TLS 1.2 o= r 1.3) where the client doesn't send until t=3D1.

David
--089e013c65dca50b01052a4621b1-- From nobody Tue Jan 26 17:28:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774FB1AC3C6 for ; Tue, 26 Jan 2016 17:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0GOl1vXWmba for ; Tue, 26 Jan 2016 17:28:24 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65321AC3CB for ; Tue, 26 Jan 2016 17:28:23 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id mw1so2254000igb.1 for ; Tue, 26 Jan 2016 17:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sSTVhCWu1Zs0gt0n04l3wsbg0yIqCD1JhJ0uMFbmZXU=; b=0OWQAvOANenH2QgMp+2AUOk5UNuSRDlM3NhbtPkkpE/lMOmM4sGjZRMfkGz/vL6yvM /6CHhTm1aW23U3RTIP4sh1t+g8C+UzHKaSDv5XhgHJacK9dRRjaWD939DnxFKCPVq1f+ /Wjz8z2xYKKUVDH2tnJdq8FafXGF8W+ns/h8Fw4p4hgsVr8cWHBkNiICtee1WoX8E1Gg JMMHyhLNSSFIDh4B9pvdXyfFS1uNZUXUoMLYqsPXMfAH3SEVjJK6tNKfLSCKsR/bL+4n Q8IneqTY+rIe9KIWhxKh9wfXI2dpDgNIjPuMWwAAA20tyY5ZjQRF3N1EVNi5ae5R5H8l rTsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sSTVhCWu1Zs0gt0n04l3wsbg0yIqCD1JhJ0uMFbmZXU=; b=cMyCJFLmcxZ1nNMOp29gjktH+z9R8v1MTMGm2fZ0yj23fQjN06/sLiXg4XYpYRg98A 4Xp26AVc6/H+0ReZOKjMcIRe0NcF/3l1G7bwNzX/vZnMwkwHQbhZuAByKPTS+stbwUxM U4VVM4Cg0vgA2Pifee8gaQxSHKwAey+wLVInEtDimFLxRk6TixeT0OQzn8Qpb81eW2Vg 3BJaZRmE4ceV2Q5jut7WYJDJx0FJn643vSCEf5ZEFFWBPLgZFSSyVMU6+hhLSKe3wwSU AU/TxBUCJoySbJOUu/NaUAWLg4f69eqrHLhhCtRIaA/L0pO9LrO1WDGBPUQkHy828V8y xLEQ== X-Gm-Message-State: AG10YOQbkYcCYe/gqY8AaKYVa8eegybi3OTuIFTOa+z+7aBObUFpg9YPluTdtelee+3P9tve6jpC/BsYpn4USA== MIME-Version: 1.0 X-Received: by 10.50.171.200 with SMTP id aw8mr27815031igc.77.1453858103316; Tue, 26 Jan 2016 17:28:23 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 26 Jan 2016 17:28:23 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 12:28:23 +1100 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 01:28:25 -0000 This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402 My understanding is that the server is able to send any data that does not depend on client authentication at t=0.5 and any data that depends on client authentication at either t=0.5 if it successfully consumes the client authentication in the 0-RTT flight, or t=1.5 failing that. On 27 January 2016 at 11:46, David Benjamin wrote: > It's possible I'm reading the draft wrong, so this thread may be a very > short one. > > (t here is in units of RTT, so t=0 is when the client sends ClientHello and > t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is > when the client receives ServerHello, etc.) > > Looking at the Zero-RTT exchange here: > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 > > Is the intention that the client, even in the successful 0-RTT case, send > two Finished messages (one at t=0 and one at t=1) and that the server not > send application data until receiving the second of these at t=1.5? If so, > does this not defeat the purpose of 0-RTT? Although the client now eagerly > sends at t=0, it will not see the response until t=2, which is no better > than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send > until t=1. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jan 26 17:58:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C283D1B3347 for ; Tue, 26 Jan 2016 17:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 6gIRd_IL0JMB for ; Tue, 26 Jan 2016 17:58:52 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEADB1B32DB for ; Tue, 26 Jan 2016 17:58:51 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id t15so73458892igr.0 for ; Tue, 26 Jan 2016 17:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=kbOwUUidN6jmRZ+s7F3ZMVDjp2A4+yjqNwXqqeB5/Lc=; b=JZQ/4a1ZKyhtQo9MpMeNgXlGTJkZJQ3kF40wJcEpuoNXk3f9qiIUNvU3iAcZOnl5g2 PGdCqWX+tqAoFFtcmX2FpXevIhx3+At0bTcrykxPOZpEcEm1QWPjc6PN8qvYwAzd0HzI n45OIfPFbku5EGtmqEtDOmohcSotu7wKYfot0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=kbOwUUidN6jmRZ+s7F3ZMVDjp2A4+yjqNwXqqeB5/Lc=; b=kaPdAA1bqf3J3sSyqO6TZmoz1dS0CqBPmPzj6lNHb4noQS44QyLJaqteiUD1GxHd9k EFEuwtepvdCTKPSWpVQpjWmZT3+6+E92FfzszViK2yUEM9F0zOqnyYBRH1xlsaeJCgVM y3fOqd7GPjS5xTi6UQk1CbOb2uQNfWp1Ue53uzcIURmVxIyFwiyqV8RJCce0nLk7+rgQ MBfWQ14nNEYxQxhq2SwQDjz1NJm+ELo07KN+l5jpyca1ZAPIGU/At71K89GKy3pE8ap0 2kZ2y/l8TQcTYqCuNZ/Y20HT9I/GGx5FxxzWaxVoGjv0kjcQ6+rQa1zLzGE+Xdn9UCU0 4H8w== X-Gm-Message-State: AG10YOQBeXXYI31YRWzUiv2ULmtNuIBc6aTQDJNcoFyhT5uPnaU5MZbIlhYBrhEpBwW4utgoK3ApHuTX5+ZM8GG+ X-Received: by 10.50.13.102 with SMTP id g6mr27924252igc.77.1453859931076; Tue, 26 Jan 2016 17:58:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 27 Jan 2016 01:58:40 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013c66d6bf0cb7052a4724e9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 01:58:53 -0000 --089e013c66d6bf0cb7052a4724e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson wrote: > This is in part why I created: > https://github.com/tlswg/tls13-spec/pull/402 Ah, great. And indeed there is a paragraph I missed: """ At this point, the handshake is complete, and the client and server may exchange application layer data. Application data MUST NOT be sent prior to sending the Finished message. Note that while the server may send application data prior to receiving the client=E2=80=99s Authentication mes= sages, any data sent at that point is of course being sent to an unauthenticated peer. """ In addition to the diagram, there's also some text in 6.3.4.3 which somewhat contradicts this (that's the paragraph I was going off of in writing this mail): """ [...] Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection. This data will be protected under keys derived from the ephemeral secret (see Section 7). """ My understanding is that the server is able to send any data that does > not depend on client authentication at t=3D0.5 and any data that depends > on client authentication at either t=3D0.5 if it successfully consumes > the client authentication in the 0-RTT flight, or t=3D1.5 failing that. > This seems unnecessarily complicated and invites all the context-switching problems of mid-stream client auth in even more situations. If the server needs to send a CertificateRequest (i.e. the client mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but useless because the first authenticated byte of the response is delayed to t=3D1.5. We should just say that 0-RTT accept + CertificateRequest is forbidden. If one really wants to, a la mid-stream[*] auth, send unauthenticated bytes at t=3D0.5 and then authenticated bytes at t=3D1.5, one could just as easil= y use mid-stream auth itself. The server accepts the 0-RTT without a CertificateRequest and, at t=3D0.5, sends the unauthenticated bytes followe= d by a mid-stream CertificateRequest. At t=3D1, the client processes the unauthenticated bytes, sees a mid-stream CertificateRequest, authenticates, which the server receives at t=3D1.5, sends authenticated bytes, received b= y the client at t=3D2. The same data arrives at the same times and we don't increase the state-space. David [*] Mid-stream auth is a serious regression, and I am not endorsing it in any way. But supposing it exists for the purposes of this thread... > On 27 January 2016 at 11:46, David Benjamin wrote= : > > It's possible I'm reading the draft wrong, so this thread may be a very > > short one. > > > > (t here is in units of RTT, so t=3D0 is when the client sends ClientHel= lo > and > > t=3D0.5 is when the server receives ClientHello and sends ServerHello, = t=3D1 > is > > when the client receives ServerHello, etc.) > > > > Looking at the Zero-RTT exchange here: > > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 > > > > Is the intention that the client, even in the successful 0-RTT case, se= nd > > two Finished messages (one at t=3D0 and one at t=3D1) and that the serv= er not > > send application data until receiving the second of these at t=3D1.5? I= f > so, > > does this not defeat the purpose of 0-RTT? Although the client now > eagerly > > sends at t=3D0, it will not see the response until t=3D2, which is no b= etter > > than the resumption case (in TLS 1.2 or 1.3) where the client doesn't > send > > until t=3D1. > > > > David > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --089e013c66d6bf0cb7052a4724e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson <martin.thomson@= gmail.com> wrote:
This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402
=
Ah, great. And indeed there is a paragraph I missed:
"""
At this point, the handshake is co= mplete, and the client and server may exchange application layer data. Appl= ication data MUST NOT be sent prior to sending the Finished message. Note t= hat while the server may send application data prior to receiving the clien= t=E2=80=99s Authentication messages, any data sent at that point is of cour= se being sent to an unauthenticated peer.
"""

In addition to the diagram, there's also some text= in 6.3.4.3 which somewhat contradicts this (that's the paragraph I was= going off of in writing this mail):
"""
[...] Once a side has sent its Finished message and received and validated= the Finished message from its peer, it may begin to send and receive appli= cation data over the connection. This data will be protected under keys der= ived from the ephemeral secret (see Section 7).
"""= ;

My understanding is that the server is able to send any data that does
not depend on client authentication at t=3D0.5 and any data that depends on client authentication at either t=3D0.5 if it successfully consumes
the client authentication in the 0-RTT flight, or t=3D1.5 failing that.
=

This seems unnecessarily complicated and i= nvites all the context-switching problems of mid-stream client auth in even= more situations.

If the server needs to send a Ce= rtificateRequest (i.e. the client mispredicted the 0-RTT Certificate/Certif= icateVerify) but otherwise has a 0-RTT hit, have it reject 0-RTT altogether= . The 0-RTT is already all but useless because the first authenticated byte= of the response is delayed to t=3D1.5. We should just say that 0-RTT accep= t=C2=A0+ CertificateRequest is forbidden.

If one r= eally wants to, a la mid-stream[*] auth, send unauthenticated bytes at t=3D= 0.5 and then authenticated bytes at t=3D1.5, one could just as easily use m= id-stream auth itself. The server accepts the 0-RTT without a CertificateRe= quest and, at t=3D0.5, sends the unauthenticated bytes followed by a mid-st= ream CertificateRequest. At t=3D1, the client processes the unauthenticated= bytes, sees a mid-stream CertificateRequest, authenticates, which the serv= er receives at t=3D1.5, sends authenticated bytes, received by the client a= t t=3D2. The same data arrives at the same times and we don't increase = the state-space.

David

[*= ] Mid-stream auth is a serious regression, and I am not endorsing it in any= way. But supposing it exists for the purposes of this thread...
= =C2=A0
On 27 January 2016 at 11:46, David Benjamin <davidben@chromium.org> wrote:
> It's possible I'm reading the draft wrong, so this thread may = be a very
> short one.
>
> (t here is in units of RTT, so t=3D0 is when the client sends ClientHe= llo and
> t=3D0.5 is when the server receives ClientHello and sends ServerHello,= t=3D1 is
> when the client receives ServerHello, etc.)
>
> Looking at the Zero-RTT exchange here:
> https://tlswg.github.io/tls13-spec/#rfc.s= ection.6.2.2
>
> Is the intention that the client, even in the successful 0-RTT case, s= end
> two Finished messages (one at t=3D0 and one at t=3D1) and that the ser= ver not
> send application data until receiving the second of these at t=3D1.5? = If so,
> does this not defeat the purpose of 0-RTT? Although the client now eag= erly
> sends at t=3D0, it will not see the response until t=3D2, which is no = better
> than the resumption case (in TLS 1.2 or 1.3) where the client doesn= 9;t send
> until t=3D1.
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
--089e013c66d6bf0cb7052a4724e9-- From nobody Tue Jan 26 18:02:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84981B3365 for ; Tue, 26 Jan 2016 18:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 iIkx-EU5RUX7 for ; Tue, 26 Jan 2016 18:02:49 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0E41B3351 for ; Tue, 26 Jan 2016 18:02:49 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id mw1so2680936igb.1 for ; Tue, 26 Jan 2016 18:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=E6dYZvSgcpFb0Qf7zxd2skQo9DXcmSCknP1taE5AALg=; b=jBpugMvatd1cm1dMSK3xt0nV3yu5AMLilMwetHnjHuYXbDiTCbOuL9xUXT5cZJNrHW hcMauNIM0SoPtE+pSVyRoowZBTKvyH1BsAsI7rj8jZhSy2qmcncqP6z5JEedxSdcrHdG hhBQ6dgOfpsyF2vGwZLzdMZnB/YcEbdimgVhA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=E6dYZvSgcpFb0Qf7zxd2skQo9DXcmSCknP1taE5AALg=; b=MBFBGK/yqovzbo6uUv5+2eZ7TbWtS5vRjnTpIHukaPRE2VTYCj5+MkyVCgGUOPf9Iu 9OUAIyZXyCdvbnnZoIYC21lMbzj8ToSfUxNoaAB97LzL/Hrt3kVPyxcnJjspTI8xeV0g m72sa2DlF/4HJFob2y/0D5WE4p9OOn8cb1DUeG+2m6WcavkIV66YpUNHJ4JIKG0Jm5// 7N7HQyumqsCSws8z7BoPRz2eqxHeWmQTw7vW0WxSOectz6/K0K46Q7xoZEJZMLVbBJ5P PTHg2XuZOqV9SdPo01XfF58IzetNLec7KlHbW9CEvqrMB7WlOfcWNIQv1jfSH+5XQqh4 pLMg== X-Gm-Message-State: AG10YORyYouCtREcYA5baqZQTZ2yWOSqeOWpECrQe43vqFfLMDes7+4JtI2p2ygcmsISDNAy2s3EqJSVfuDWJuh1 X-Received: by 10.50.171.200 with SMTP id aw8mr27929953igc.77.1453860168751; Tue, 26 Jan 2016 18:02:48 -0800 (PST) MIME-Version: 1.0 From: David Benjamin Date: Wed, 27 Jan 2016 02:02:39 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e010d9562e9ae6e052a473234 Archived-At: Subject: [TLS] Backwards-compatibility of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 02:02:51 -0000 --089e010d9562e9ae6e052a473234 Content-Type: text/plain; charset=UTF-8 Instead of putting 0-RTT data in a ClientHello extension, the current draft has the client send extra records in the first flight, right? (I see an early_data extension, but it seems only be an indicator. There's also mention of requiring trial decryption which only makes sense if it were appended.) Was there a reason not to put it into an extension? It's uglier, but the current scheme has compatibility risks and may force clients into a fallback dance. Although a TLS 1.3 client won't make 0-RTT handshakes to a service until it's managed to speak TLS 1.3 to it once, services aren't made of one machine. Many services span multiple machines, changes are deployed incrementally, etc. Even single-machine services may need to roll back a change. This kind of statefulness means that one cannot enable 0-RTT on *any* machine until *all* machines in the fleet have enabled TLS 1.3. And TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until all server configs have expired). I would not expect all deployments to get this right. Large companies with TLS experts might, but most people will idly take updates from their operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default. They won't realize fleets must "set" at TLS 1.3 without 0-RTT before enabling TLS 1.3 with 0-RTT. This is the same flavor of problems in session resumption that motivated https://github.com/tlswg/tls13-spec/issues/136. That bug wasn't hypothetical. At the time I filed that issue, https://www.debian.org was two wildly different servers. One spoke up to TLS 1.0 and the other up to TLS 1.2. OpenSSL on the client has some bugs around resumption which gives similar version stickiness effects. Until I reworked the version negotiation code, Chrome + BoringSSL would fail to connect sometimes. Having the 0-RTT data delimited in the ClientHello should hopefully also avoid the trial decryption step on 0-RTT miss which seems kind of silly. David --089e010d9562e9ae6e052a473234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Instead of putting 0-RTT data in a ClientHello extension, = the current draft has the client send extra records in the first flight, ri= ght? (I see an early_data extension, but it seems only be an indicator. The= re's also mention of requiring trial decryption which only makes sense = if it were appended.) Was there a reason not to put it into an extension? I= t's uglier, but the current scheme has compatibility risks and may forc= e clients into a fallback dance.

Although a TLS 1.3 client won&= #39;t make 0-RTT handshakes to a service until it's managed to speak TL= S 1.3 to it once, services aren't made of one machine. Many services sp= an multiple machines, changes are deployed incrementally, etc. Even single-= machine services may need to roll back a change. This kind of statefulness = means that one cannot enable 0-RTT on *any* machine until *all* machines in= the fleet have enabled TLS 1.3. And TLS 1.3 may not be rolled back once 0-= RTT is enabled (at least not until all server configs have expired).
<= div>
I would not expect all deployments to get this right. La= rge companies with TLS experts might, but most people will idly take update= s from their operating system with (hopefully!) TLS 1.3 and 0-RTT enabled b= y default. They won't realize fleets must "set" at TLS 1.3 wi= thout 0-RTT before enabling TLS 1.3 with 0-RTT.

This is the same fla= vor of problems in session resumption that motivated=C2=A0https://github.com/tlswg/tls13-sp= ec/issues/136. That bug wasn't hypothetical. At the time I filed th= at issue,=C2=A0https://www.debian.org=C2=A0was two wildly different servers. One spoke up to TLS 1.0 and the ot= her up to TLS 1.2. OpenSSL on the client has some bugs around resumption wh= ich gives similar version stickiness effects. Until I reworked the version = negotiation code, Chrome + BoringSSL would fail to connect sometimes.
=

Having the 0-RTT data delimited in the ClientHello shou= ld hopefully also avoid the trial decryption step on 0-RTT miss which seems= kind of silly.

David
--089e010d9562e9ae6e052a473234-- From nobody Tue Jan 26 18:11:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E411B33A2 for ; Tue, 26 Jan 2016 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 qcVw3974VsXP for ; Tue, 26 Jan 2016 18:11:49 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 EB88A1B33A0 for ; Tue, 26 Jan 2016 18:11:48 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id v14so224555581ykd.3 for ; Tue, 26 Jan 2016 18:11:48 -0800 (PST) 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:content-type; bh=n/fMokQH0tiFmpyMTrg1C2SrJ5GJALgzgYKwtem4Xx0=; b=ePIm8ATb/hqh5ilxSpmhIcVXYY3UJ5x6Ks/GwSqkfD7ENeFZbMzS8YyM7C/+okMWqp Gf08SGcVmJOqgGssZQmtxS6VGIP1z3nyl9uA+SypSoZlxS+9RoS2rB5kFzc9dlRUzg0Q 8sqrsneIkGx8e2QdrI/TkEjspbs53a6JEUwLEkUk8fNYak+cTbiikfQ4Cv1HgQw6s6hP /d4ZhlZcV4qEqR//REY+Pcmng8gd7Da0EssuXid9VaisejVmvIeYS82a3KB/e0TU7Iql w8KYejPJmiy1xWlI4O6zVvUGCNSDDB4HozEKI+ty5Ky0to8AHpCjZIhlwXtQHf2OVGEi DG4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=n/fMokQH0tiFmpyMTrg1C2SrJ5GJALgzgYKwtem4Xx0=; b=gAmKCZSDeKuDjs1obMNnWu5R8G/U/vFa/v4NVsaYXMOO1jpZENcG1bz6gScKOSpeM5 E21MfJoAmKX4bA8Rg6zGu2yWXjXmJ177BbXTLrPXAIUgx3GBKkVjoshOLjhG8Rq18EUB bbuFs9boOUX7Db2MRx8rD+q4VWhp69UAWEisslEG5PKymZorRge4uc0cMcvdhd8xsHu4 GtYr2kaHvvoaZ7VyCojnW/RG5s3yrUdmzX7IcPjTFXlf+ySFlO82KCi1RATemOTiiYTG a4CG3Wnsvr3ZgiA8DDFEyT8S9K7uciQCL7RPLhTOfv6jpsY+RQ3/Y5MJPeXY+V8BxrNF J0KQ== X-Gm-Message-State: AG10YOTuu3c4n21WZa+2ZLjNpj2W+4X7SIrthfR+M0NgWGPLDzWk5dKIGchYvGq34vCFOL48jZLPbYJIh4Q7qg== X-Received: by 10.129.73.17 with SMTP id w17mr14542973ywa.223.1453860708176; Tue, 26 Jan 2016 18:11:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 26 Jan 2016 18:11:08 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 26 Jan 2016 18:11:08 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114d950610836c052a47533a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards-compatibility of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 02:11:50 -0000 --001a114d950610836c052a47533a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin wrote: > Instead of putting 0-RTT data in a ClientHello extension, the current > draft has the client send extra records in the first flight, right? (I see > an early_data extension, but it seems only be an indicator. There's also > mention of requiring trial decryption which only makes sense if it were > appended.) Was there a reason not to put it into an extension? It's uglier, > but the current scheme has compatibility risks and may force clients into a > fallback dance. > Yes, it means you can't stream 0-RTT data because you have to know it all in advance. We had a number of requests for this. Although a TLS 1.3 client won't make 0-RTT handshakes to a service until > it's managed to speak TLS 1.3 to it once, services aren't made of one > machine. Many services span multiple machines, changes are deployed > incrementally, etc. Even single-machine services may need to roll back a > change. This kind of statefulness means that one cannot enable 0-RTT on > *any* machine until *all* machines in the fleet have enabled TLS 1.3. And > TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until > all server configs have expired). > I don't think this is entirely true: Web clients already fall back on hard failures. But yes, thats the general design. I would not expect all deployments to get this right. Large companies with > TLS experts might, but most people will idly take updates from their > operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default. > Well, I think we're generally encouraging people to have to explicitly enable 0-RTT. -Ekr > They won't realize fleets must "set" at TLS 1.3 without 0-RTT before > enabling TLS 1.3 with 0-RTT. > > This is the same flavor of problems in session resumption that motivated > https://github.com/tlswg/tls13-spec/issues/136. That bug wasn't > hypothetical. At the time I filed that issue, https://www.debian.org was > two wildly different servers. One spoke up to TLS 1.0 and the other up to > TLS 1.2. OpenSSL on the client has some bugs around resumption which gives > similar version stickiness effects. Until I reworked the version > negotiation code, Chrome + BoringSSL would fail to connect sometimes. > > Having the 0-RTT data delimited in the ClientHello should hopefully also > avoid the trial decryption step on 0-RTT miss which seems kind of silly. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114d950610836c052a47533a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
Instead of putting 0-RTT data in a ClientHello extension, the current dr= aft has the client send extra records in the first flight, right? (I see an= early_data extension, but it seems only be an indicator. There's also = mention of requiring trial decryption which only makes sense if it were app= ended.) Was there a reason not to put it into an extension? It's uglier= , but the current scheme has compatibility risks and may force clients into= a fallback dance.

Yes, it means = you can't stream 0-RTT data because you have to know it all in
advance. We had a number of requests for this.

<= br>
Although a TL= S 1.3 client won't make 0-RTT handshakes to a service until it's ma= naged to speak TLS 1.3 to it once, services aren't made of one machine.= Many services span multiple machines, changes are deployed incrementally, = etc. Even single-machine services may need to roll back a change. This kind= of statefulness means that one cannot enable 0-RTT on *any* machine until = *all* machines in the fleet have enabled TLS 1.3. And TLS 1.3 may not be ro= lled back once 0-RTT is enabled (at least not until all server configs have= expired).

I don't think th= is is entirely true: Web clients already fall back on hard failures.
<= div>But yes, thats the general design.

I would not expect all deployments to = get this right. Large companies with TLS experts might, but most people wil= l idly take updates from their operating system with (hopefully!) TLS 1.3 a= nd 0-RTT enabled by default.

W= ell, I think we're generally encouraging people to have to explicitly e= nable 0-RTT.

-Ekr

=C2=A0<= /div>
They won't re= alize fleets must "set" at TLS 1.3 without 0-RTT before enabling = TLS 1.3 with 0-RTT.

This is the same flavor of problems in session r= esumption that motivated=C2=A0https://github.com/tlswg/tls13-spec/issues/= 136. That bug wasn't hypothetical. At the time I filed that issue,= =C2=A0https://www.debi= an.org=C2=A0was two wildly different servers. One spoke up to TLS 1.0 a= nd the other up to TLS 1.2. OpenSSL on the client has some bugs around resu= mption which gives similar version stickiness effects. Until I reworked the= version negotiation code, Chrome + BoringSSL would fail to connect sometim= es.

Having the 0-RTT data delimited in the ClientH= ello should hopefully also avoid the trial decryption step on 0-RTT miss wh= ich seems kind of silly.

David

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


--001a114d950610836c052a47533a-- From nobody Tue Jan 26 18:12:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65101B33A9 for ; Tue, 26 Jan 2016 18:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEa8oV1oyy8K for ; Tue, 26 Jan 2016 18:11:57 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71FC1B33AE for ; Tue, 26 Jan 2016 18:11:56 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id g73so4431524ioe.3 for ; Tue, 26 Jan 2016 18:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IlxAfmOiateykfgvYK3rM4592ULX+CYe39iwSYFdIyA=; b=GQXeFmV6YKnr9BQNalSh8IyeGIqjxz9CVXCd7saeFdKDItvoOpSjJPP/g7tKstvQ2c p/6hiKMu3kb8oZCw05Sml95JCcimb3uVpTwEIHl1pVlG6OqFeyDoSxZAacv+NW/Fu8hx PnptlNK938KOFrkBDb1x/ofsBG23DkoL2DAQayYGIJ+kHlH31B2B54ZJ2lmvbm2YvOSJ 6GfSD0Jxu0s2MMgju6qADcaYrHS4TnY/UgNGK8+QFgDYAXBzYfLZoTdQqlHV8gH08ICx Iyddtj4e0TDd2l936nGhqKNuuwlvk14+wQIevKGFloIkoEb2I02olmvLIHQwQkcUITlA 3iDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IlxAfmOiateykfgvYK3rM4592ULX+CYe39iwSYFdIyA=; b=Hlb0AYq0uhSxbWM4w96FZGa3ZKsgh9UBKzshSHEG/gQewiEqbnYM7ZSY4h1hRl0QuM SZ+ivBCzKiz20HzfcNktHZpLJvRSAfmy4ov4DvPVWDzoT+gOeWfBWSAKoEmG9rqoFZBl xowjavuKBYwQHysxEsiJ6Cqr8HCZMVK9mDd/saKGXV5ZRSAZxkUhtfROPeh/JWFfwyEW 22j5KX7NJ/zyTgespsQba7rmjOQFGGyNrDtSsxqFwhQey5mEHHKOP5xmBW8OiiiXG3at T/BBSVa93mLpbcvBN4Z2U4aGopRqJ+f6wnXPBCRLPIz1t2jlKsM9cu4FW+z3HYzcElAV uyKg== X-Gm-Message-State: AG10YOSRTwZ+VYnlE+WFmNdE6DQXkDYwBPiYSqpUWolBBH3KPb1Lfkfvv4dm0IbSjP7oNnu/hbJDtlE8JUJGPQ== MIME-Version: 1.0 X-Received: by 10.107.16.199 with SMTP id 68mr26511820ioq.100.1453860716243; Tue, 26 Jan 2016 18:11:56 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 26 Jan 2016 18:11:56 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 13:11:56 +1100 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 02:12:02 -0000 On 27 January 2016 at 12:58, David Benjamin wrote: > If the server needs to send a CertificateRequest (i.e. the client > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a > 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but > useless because the first authenticated byte of the response is delayed to > t=1.5. We should just say that 0-RTT accept + CertificateRequest is > forbidden. I believe that is a choice that an implementation could make, rather than have a stipulation in a spec. You are free to simplify in your implementation as much as you like. Refusing 0-RTT and delaying the "completion" of a handshake if you find that you need to send a CertificateRequest (either because you don't have 0-RTT client auth or the 0-RTT client auth is bad/indecipherable) is a pretty good choice. I might even be happy to recommend it to others. But do you have a security property you are looking to preserve? Because otherwise, I think that I might take the optimization. From nobody Tue Jan 26 18:13:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A681B33B1 for ; Tue, 26 Jan 2016 18:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM2X57OT6Oom for ; Tue, 26 Jan 2016 18:13:27 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 49EEF1B33AA for ; Tue, 26 Jan 2016 18:13:27 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id t15so73666491igr.0 for ; Tue, 26 Jan 2016 18:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Iia8+WnBLIy0huYR98AHk1/FvhdJ2O+qrknQQmX2gI=; b=Olv4ldaHkj3qtOP5BnkC5vg4rdf4ZlbXrjUs043/KS7D3nDkPaJr2TtJeuQEw/tNxK 4298XqDq9EJXKb6qm2e2OnnpN5Kx2ansvh12Hjshc5Tx9dpqyxd8ptneMK2Wf4Qs2mgy +Yeecgd3gluLAzoIkGCLJHpyI33pG0I2zCG1iyUFgHTuHXtp3bt8gpLghafNqivRymHt /EM7sQdD0WSDsN3ilqfludmTtvLrKBSmG6fyjfpPwIXyQcDHPehi1gS168er0RR3yvuJ 8q3M4qrVsV0/TWPJUQHYYMMfSaI0JHO0aAvlGpyNV8lG5UHQxSgUwuTWs0KRoZoSn8W0 zevw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+Iia8+WnBLIy0huYR98AHk1/FvhdJ2O+qrknQQmX2gI=; b=SKF9R3wi/+oqT7jZaMJkGAdijJMDsJ3p9DdAdWDfFpkOG3d/7Pgt0iz+zQQ71bbomu sMuLtPM4HHsNg+lxg6NYdaroWHhXkZNezXvOb9NzzLJwLEAJwqZMahNWMQyPtV1cVu/D EMaG/RKCnO6BHMHVb+2weRWnNUyy8Q9l6/+E98Svnoy3A8EkNvWhBNgARIbjEwjjWw7c 8XU9F4vpdGXhkpk3K6geKWb2+UtAK/eFIAb30DpHSMtkJlCB4EuS2Y4MJN96qBFkE5Xx GdCTvEtzBLTf4kgne1RAeC7UidTh1t9oK6+aS2TR5GbUpst69t9MBAunkN+CO7d+ZKmM Q/Aw== X-Gm-Message-State: AG10YOTgtKhLEBbMUEoEre5LEkM/MDUO+7j5Qob0ZfblaY508uClvn1tgExD6jpDZV2hLMSE9qWiTU0qW7Oojg== MIME-Version: 1.0 X-Received: by 10.50.171.200 with SMTP id aw8mr27973397igc.77.1453860806766; Tue, 26 Jan 2016 18:13:26 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 26 Jan 2016 18:13:26 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 13:13:26 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards-compatibility of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 02:13:28 -0000 On 27 January 2016 at 13:11, Eric Rescorla wrote: > Well, I think we're generally encouraging people to have to explicitly > enable 0-RTT. I think that the key point was that you would have to explicitly enable 0-RTT AND that also meant a commitment not to choke on 0-RTT data for at least as long as your 0-RTT configurations were valid. From nobody Tue Jan 26 19:11:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0489D1B34B8 for ; Tue, 26 Jan 2016 19:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ty2sqFLmiqZX for ; Tue, 26 Jan 2016 19:11:16 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3BD1B34B6 for ; Tue, 26 Jan 2016 19:11:16 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id t15so74430657igr.0 for ; Tue, 26 Jan 2016 19:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=n/w9+4u52nHpJZklOqxMVm0wT6EcvMnR54UEQFN0MeE=; b=UjcFYa+PhHICrQd/ZqUoe64aPx7Y6F7FgGsuOQi6qNJhFVcTfIhxVe7/INOJ3iaysw 67wGLpXL8p2F5A9L5z9ldO6uxd8ZWy/cy2cTsMH8zI2QY+TU5gH6DGLgrmX4AQbo8GSr 11ANUrwQXkhpEvvoFzl0im1EwcUcSgmRI3nn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=n/w9+4u52nHpJZklOqxMVm0wT6EcvMnR54UEQFN0MeE=; b=EPJzl7WJGitJgZk7AoTbVyAGl/YLAY3oPwETbDLxlPzd9oxUTjhyGHdkmOUzek930e 9BKlAw51Fpg9ZK2ltGHLUnIM9UpVIT43zSzomAXUsnKSzTf8xUORIj9FPPmfWraFNpNp DETHHqjErrM8GVUQhs6GHS7V4BzZBhlwItkoAZmM7mWH7MFnrH1CMANjXyANJAuojZzD /yNCnEsBUjY31BoQpYU8TzIbtoE7PqZJ1sl7k2QcZcHZvmodymsu85OiQ7cafTNAqD8B JmjAQuAHxjNBh/q7GXQEZBfFkHWuvCuOEhf/dBs0iDBqd0+qB6mk553KJUMfNrCLjNKz tlcg== X-Gm-Message-State: AG10YOToMWdPzd56K2/RShs01KvENLx5EgOE532JmtVRrHBE/oBkqxURNa8OYd55Ykofi78K3Y2B7advusEVbRF0 X-Received: by 10.50.171.200 with SMTP id aw8mr28188104igc.77.1453864275703; Tue, 26 Jan 2016 19:11:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 27 Jan 2016 03:11:05 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e010d9562b51127052a482782 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 03:11:18 -0000 --089e010d9562b51127052a482782 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson wrote: > On 27 January 2016 at 12:58, David Benjamin wrote: > > If the server needs to send a CertificateRequest (i.e. the client > > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a > > 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but > > useless because the first authenticated byte of the response is delayed > to > > t=1.5. We should just say that 0-RTT accept + CertificateRequest is > > forbidden. > > > I believe that is a choice that an implementation could make, rather > than have a stipulation in a spec. You are free to simplify in your > implementation as much as you like. > > Refusing 0-RTT and delaying the "completion" of a handshake if you > find that you need to send a CertificateRequest (either because you > don't have 0-RTT client auth or the 0-RTT client auth is > bad/indecipherable) is a pretty good choice. I might even be happy to > recommend it to others. But do you have a security property you are > looking to preserve? Because otherwise, I think that I might take the > optimization. > Why do you say it's an optimization? They're exactly the same except the simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a combination that's possible with or without my restriction) and the other is a brand new handshake flow to worry about. Original: t = 0 Client sends ClientHello to server with 0-RTT data. t = 0.5 Server acks 0-RTT in ServerHello, adds a CertificateRequest in the middle, sends Finished (and messages in between). t = 0.5 Server sends unauthenticated application data. t = 1 Client receives CertificateRequest, sends Certificate, CertificateVerify, Finished t = 1 Client receives unauthenticated application data t = 1.5 Server receives Certificate, etc., sends authenticated application data. t = 2 Client receives authenticated application data. Simplified: t = 0 Client sends ClientHello to server with 0-RTT data. t = 0.5 Server acks 0-RTT ServerHello, sends Finished (and messages in between) t = 0.5 Server sends mid-stream CertificateRequest t = 0.5 Server sends unauthenticated application data t = 1 Client sends Finished t = 1 Client receives mid-stream CertificateRequest, sends mid-stream Certificate, CertificateVerify t = 1 Client receives unauthenticated application data t = 1.5 Server receives mid-stream Certificate, etc., sends authenticated application data. t = 2 Client receives authenticated application data. I believe all that changes is CertificateRequest now comes after Finished on the server and Finished comes before Certificate on the client. But this way we cut down on the state space. Even if servers are sensible enough to act this way, clients must still accept it if it's in the protocol. That's more cases that everyone must write tests for (BoringSSL has a pretty extensive battery of tests and I intend to continue this practice) and think about in analyzing the protocol. David --089e010d9562b51127052a482782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26= , 2016 at 9:11 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 January 2016 at 12:58, David Benjamin <davidben@chromium.org> wr= ote:
> If the server needs to send a CertificateRequest (i.e. the client
> mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise ha= s a
> 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all b= ut
> useless because the first authenticated byte of the response is delaye= d to
> t=3D1.5. We should just say that 0-RTT accept + CertificateRequest is<= br> > forbidden.


I believe that is a choice that an implementation could make, rather
than have a stipulation in a spec.=C2=A0 You are free to simplify in your implementation as much as you like.

Refusing 0-RTT and delaying the "completion" of a handshake if yo= u
find that you need to send a CertificateRequest (either because you
don't have 0-RTT client auth or the 0-RTT client auth is
bad/indecipherable) is a pretty good choice.=C2=A0 I might even be happy to=
recommend it to others.=C2=A0 But do you have a security property you are looking to preserve?=C2=A0 Because otherwise, I think that I might take the=
optimization.

Why do you say it's a= n optimization? They're exactly the same except the simplified one redu= ces to normal 0-RTT + mid-stream CertificateRequest (a combination that'= ;s possible with or without my restriction) and the other is a brand new ha= ndshake flow to worry about.

Original:
t =3D 0 =C2=A0C= lient sends ClientHello to server with 0-RTT data.
t =3D 0.5 Serv= er acks 0-RTT in ServerHello, adds a CertificateRequest in the middle, send= s Finished (and messages in between).
t =3D 0.5 Server sends unau= thenticated application data.
t =3D 1 Client receives Certificate= Request, sends Certificate, CertificateVerify, Finished
t =3D 1 C= lient receives unauthenticated application data
t =3D 1.5 Server = receives Certificate, etc., sends authenticated application data.
t =3D 2 Client receives authenticated application data.

Simplified:
t =3D 0 =C2=A0Client sends ClientHello to= server with 0-RTT data.
t =3D 0.5 Server acks 0-RTT ServerHello,= sends Finished (and messages in between)
t =3D 0.5 Server sends = mid-stream CertificateRequest
t =3D 0.5 Server sends unauthen= ticated application data
t =3D 1 Client sends Finished
= t =3D 1 Client receives mid-stream CertificateRequest, sends mid-stream Cer= tificate, CertificateVerify
t =3D 1 Client receives unauthent= icated application data
t =3D 1.5 Server receives mid-stream Cert= ificate, etc., sends authenticated application data.
t =3D 2 Clie= nt receives authenticated application data.

= I believe all that changes is CertificateRequest now comes after Finished o= n the server and Finished comes before Certificate on the client.

But this way we cut down on the state space. Even if servers are sensibl= e enough to act this way, clients must still accept it if it's in the p= rotocol. That's more cases that everyone must write tests for (BoringSS= L has a pretty extensive battery of tests and I intend to continue this pra= ctice) and think about in analyzing the protocol.

David
--089e010d9562b51127052a482782-- From nobody Tue Jan 26 19:30:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7231B34F3 for ; Tue, 26 Jan 2016 19:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 TyOvK3arZGbv for ; Tue, 26 Jan 2016 19:30:39 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E7D1B34F2 for ; Tue, 26 Jan 2016 19:30:39 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id z14so72217852igp.0 for ; Tue, 26 Jan 2016 19:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=r0HimeNGOPk4RIXqHmFb2wpRk+6rpaQtDfIhN/M9yik=; b=mw2/2B1MKKQGbw0W9dvu6X3e92fexC8kpGf8mvaYh4Lb8lnmGbRoZRxpNHYyfR2Bwi xNnMnP5C5GtVrpH0zK0yZTh1YWnxQc548zK86U2ri086HYUHl1j77z3Brn46ab+WR2xF Oqhp8kZJPGbbDRrAgRkzv5+rlEGfSCWHRXjew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=r0HimeNGOPk4RIXqHmFb2wpRk+6rpaQtDfIhN/M9yik=; b=DhhCFpSzl2LfRYng45ynRWa1iU/b9rWXT8+eAQGGDAyA4XHIjFWp4iTVUWF4ZH1SEH FapCSn82KpMIoSB5G/M6geYyUAM4llSCT20qspinwmEB6IyrlaIDs80Zgb7HUPh6w76o pCdbczmzjUrGVGYJj4vfx8HgcJMac+UFwIcoUpL/URM+XHmEZ10+OcYaXTpzqALpAgNP jtuzrtwHYt6+MbIaGYUxxA54d5faYJ2dm6qJE9EzdCGWqLNfsq2NH7vIj7KXhWcy8Lj6 kxFLO5iasstngN2KjhoFAu8dZxoVy6NskmCTY0TPernallp5z+uO3TxWUALN4Gf77FDm 1QZA== X-Gm-Message-State: AG10YOQ4qY7shhypfjjwrO419rWM1PTT48Tp/iIekP0m2Sy94p4yhkirNlG+Gb6GK4DQnPh0zOLOvXhi21XQS3fw X-Received: by 10.50.90.180 with SMTP id bx20mr25430262igb.67.1453865438370; Tue, 26 Jan 2016 19:30:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 27 Jan 2016 03:30:29 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7bea3d2801b3c0052a486d84 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards-compatibility of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 03:30:41 -0000 --047d7bea3d2801b3c0052a486d84 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla wrote: > On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin > wrote: > >> Instead of putting 0-RTT data in a ClientHello extension, the current >> draft has the client send extra records in the first flight, right? (I see >> an early_data extension, but it seems only be an indicator. There's also >> mention of requiring trial decryption which only makes sense if it were >> appended.) Was there a reason not to put it into an extension? It's uglier, >> but the current scheme has compatibility risks and may force clients into a >> fallback dance. >> > > Yes, it means you can't stream 0-RTT data because you have to know it all > in > advance. We had a number of requests for this. > Hrm, that's fair. I don't see any way to have both that and avoid this statefulness problem, so I guess we have to pick one. And then the other will want some scary warnings in the spec. > Although a TLS 1.3 client won't make 0-RTT handshakes to a service until >> it's managed to speak TLS 1.3 to it once, services aren't made of one >> machine. Many services span multiple machines, changes are deployed >> incrementally, etc. Even single-machine services may need to roll back a >> change. This kind of statefulness means that one cannot enable 0-RTT on >> *any* machine until *all* machines in the fleet have enabled TLS 1.3. And >> TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until >> all server configs have expired). >> > > I don't think this is entirely true: Web clients already fall back on hard > failures. > But yes, thats the general design. > We've been trying to get rid of these sorts of fallbacks as they tend to cause problems. (The version fallback, notably, has not exactly been a success story...) Though it does sound like I may need a 0-RTT-less fallback then. (Or at least to explicit invalidate the 0-RTT cache on connection error.) > I would not expect all deployments to get this right. Large companies with >> TLS experts might, but most people will idly take updates from their >> operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default. >> > > Well, I think we're generally encouraging people to have to explicitly > enable 0-RTT. > At the TLS level, of course. But, at the HTTP level, popular HTTP servers will no doubt enable it for GETs or so. People will be taking updates to those too. David --047d7bea3d2801b3c0052a486d84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26= , 2016 at 9:11 PM Eric Rescorla <ekr@rtf= m.com> wrote:
On Tue, Jan 26, 20= 16 at 6:02 PM, David Benjamin <davidben@chromium.org> wr= ote:
Instead of putting = 0-RTT data in a ClientHello extension, the current draft has the client sen= d extra records in the first flight, right? (I see an early_data extension,= but it seems only be an indicator. There's also mention of requiring t= rial decryption which only makes sense if it were appended.) Was there a re= ason not to put it into an extension? It's uglier, but the current sche= me has compatibility risks and may force clients into a fallback dance.
=

Yes, it means you can&= #39;t stream 0-RTT data because you have to know it all in
advanc= e. We had a number of requests for this.

Hrm, that's fair. I don't see any way to have= both that and avoid this statefulness problem, so I guess we have to pick = one. And then the other will want some scary warnings in the spec.
=C2=A0
Although a TLS 1.3 client won't make 0-RTT hands= hakes to a service until it's managed to speak TLS 1.3 to it once, serv= ices aren't made of one machine. Many services span multiple machines, = changes are deployed incrementally, etc. Even single-machine services may n= eed to roll back a change. This kind of statefulness means that one cannot = enable 0-RTT on *any* machine until *all* machines in the fleet have enable= d TLS 1.3. And TLS 1.3 may not be rolled back once 0-RTT is enabled (at lea= st not until all server configs have expired).

I don't think this is entirely true: Web = clients already fall back on hard failures.
But yes, thats the ge= neral design.

We= 9;ve been trying to get rid of these sorts of fallbacks as they tend to cau= se problems. (The version fallback, notably, has not exactly been a success= story...) Though it does sound like I may need a 0-RTT-less fallback then.= (Or at least to explicit invalidate the 0-RTT cache on connection error.)<= /div>
=C2=A0
I would not expect all deployments to get this r= ight. Large companies with TLS experts might, but most people will idly tak= e updates from their operating system with (hopefully!) TLS 1.3 and 0-RTT e= nabled by default.

Well, I think we're generally encouraging people to have to explicit= ly enable 0-RTT.

At= the TLS level, of course. But, at the HTTP level, popular HTTP servers wil= l no doubt enable it for GETs or so. People will be taking updates to those= too.

David
--047d7bea3d2801b3c0052a486d84-- From nobody Tue Jan 26 19:32:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782E21B34F8 for ; Tue, 26 Jan 2016 19:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ4US6zCm_tM for ; Tue, 26 Jan 2016 19:32:33 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321261B34F6 for ; Tue, 26 Jan 2016 19:32:33 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id g73so5996749ioe.3 for ; Tue, 26 Jan 2016 19:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bQNbfH0039MOd4QrsEzEcT4+MimtTuz8qQk/bCPMQEk=; b=ZVr5x7aGu5s6YpJGWCpmR5u4/26LjF6RGYhNQoS+O2lSEwgHeqeXJjtwxWkJj+MNwd BRYLwt/9tAkRP5gr891hf6y5Zzny2IHOPd27f6cU+x11K4quqHfjY+48dOGik574EVRf HWDx1DrprAexoL/12ctTQiK4MAnnSgLjjpmC9Ol7++kLuS2ML/N/D4qCJxSTq+tj9bKv QPZwKs43hWrCgMdfSCa3jCSYdlU8p2kG7ArekeccYUQNleRUv9pIk4pWrtTfJZgF7dkE jf3u3r47U2obLZyxADP59gRsTpmiHJqIArnyRLtMeRT5HTV7cixzHuNTSlBZERgIyzru VpDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bQNbfH0039MOd4QrsEzEcT4+MimtTuz8qQk/bCPMQEk=; b=dsZEd7yaL5J7M6GamvzMxFYj208N0vaS1Sc+q8ptI5G0M3mqPqugqSB7rnjgsI6C/i w6NjuRkvhkkRVskeFJhHTxEny9sa6OjtW8lCOaSoVYGEMsstQxwpSx9Sgn/A/PwaFzeD OyZJMhVx2M0EBFvCB5bfp7CmI2wBCIAWSoseIG5ETqgyBAHS1OLqS3A4d7r3cQTBDo5T aJIdyy2D2diQiFrj5JAFXBJHJBfGWPGX+1Fe5lKFJdiQQJthJDZFDNd35CPW+k4Q+Pwm XoqXLBzsSWL9FrMTf7hawBIaVJrLOk35tpLDW03x/D2FNl4q7bqchxW0X6XwCuknAbX/ prSA== X-Gm-Message-State: AG10YOQi3/E2x0FAaZ/GiiYB/xc35/0oPpSKRkTYOGjZOOiiLGXHLdoUvH+aEgbWwoTZJkcmiICAumFpiUWaNQ== MIME-Version: 1.0 X-Received: by 10.107.16.199 with SMTP id 68mr26787819ioq.100.1453865552565; Tue, 26 Jan 2016 19:32:32 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 26 Jan 2016 19:32:32 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 14:32:32 +1100 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 03:32:34 -0000 On 27 January 2016 at 14:11, David Benjamin wrote: > Why do you say it's an optimization? They're exactly the same except the > simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a > combination that's possible with or without my restriction) and the other is > a brand new handshake flow to worry about. I get your point, but I don't see that as a simplification. In my mind, post-handshake client authentication doesn't happen. Or, I don't see it being commonplace. From nobody Tue Jan 26 19:51:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A841A21A6 for ; Tue, 26 Jan 2016 19:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKZSXn8X5MPk for ; Tue, 26 Jan 2016 19:51:40 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46671A212D for ; Tue, 26 Jan 2016 19:51:39 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 77so6253957ioc.2 for ; Tue, 26 Jan 2016 19:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PLBAvPMI5uGte1uemXTYTJOoEHcgBXE5H5nspguqPjc=; b=Ru23t641sBxDZIx2kjtWynAxDXe1YouVF1DKykBBkfnmw5Ba4kfTsVTWvbhqlv6mXR A9DTiI/DPGxc4gv4ONh2LyGf5GzPZxcMglqXRyWzS+nZHQ+3Hg8u1+zPxDBEkoXJKPzk xLItzJxYowuxhAs+pqmfYPRfti6nWMDv9RKaSgu0VxJ5ZPU8PurkDQqxCxdOqq+L4Wcv Imyc4+TT1bivWOGKaYqdonmAy5qB5khhnY7awnhKhHWCdNii8/fUeTSMzhgNuxZy4DLb cMCi8gXUM2Q8BcmgZM7GNAL5ahD+oflkSoG/zR6jn0mE+W9ZjhL2rexPVnp0SDG2a5tq iyog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PLBAvPMI5uGte1uemXTYTJOoEHcgBXE5H5nspguqPjc=; b=SDA1R3W2iWjydGkWOXTJp9+zkkqYlIE7eRa0KhcGRDvsR/Vb+z3GE+koxO43fozZOn MIRPUOfu4y7UKdQ/Tb/0OH41YcmppdzKO8KuSGVddjX4UhV1yDS5pE3ncXBuyI7zCXOD X9hOwEELsD9pmsMIWzzfLTnWCHlFwUYIpCJsg7NfJQubTXSxxTMW8JUzaPFUsjTikZvW xWpI+JPawIaQAva5uA5FfUY4qMo4lm4eOLEJ9+U4G3YCEfEc6c9jHoOehBOJvxYBCDI3 wt97oCbR8vaoFXdtY1jaqqD0ViGWI6mnXZxfm5g2rTWj2D0nAahVcoNwXnuoGWjiXzsZ FCxw== X-Gm-Message-State: AG10YOQh4B4WDg7S3TrVxWLrEEU+O7YLVzyhnOXsURdWioKomCYn+y770Dg3g4RV6Y7euE3T3paNAcrQfCFXAA== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr27472094iod.190.1453866699088; Tue, 26 Jan 2016 19:51:39 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 26 Jan 2016 19:51:39 -0800 (PST) Date: Wed, 27 Jan 2016 14:51:39 +1100 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 03:51:42 -0000 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon cipher suites. I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 From nobody Tue Jan 26 22:45:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D491ACEAD for ; Tue, 26 Jan 2016 22:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UzNEUP9Rkvo for ; Tue, 26 Jan 2016 22:45:39 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A0A1ACEAE for ; Tue, 26 Jan 2016 22:45:39 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id p63so10966631wmp.1 for ; Tue, 26 Jan 2016 22:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YqPwd3B2BucbG3C2giCM6uj1NiFcbMMbIa79zdZURVs=; b=pmKtRalxuKqIANKuGmEPnbGjWM/9MRx1h7sB1RywcFQd8UvDnvq1htbIlw5eK1S+GW ysZmDnBT1ZT09Pav7Pc9csRO15RHnkX0DulJVP+RsyhKQgqhfgvG5XhXRNFbPmU8Q/H6 3dZPHD9la+8o6YljJY27B1p11N+uHsTt9oUEHvcv/lt227NJRQ1Rds0yqW/XQ1Xlj8V2 OFw2A24+5U82i5bR7mN8p9vgmAhqbyXwu6E6/IL/t4r8cYHi+L7f16sh3Sw3piARp36I BE41v2WJeFg1DkPX9Msp1Gixw2Wo7+b93zp+e+LfaN8QV9uGZJcfk2IJX314VKtJJAVf nDww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=YqPwd3B2BucbG3C2giCM6uj1NiFcbMMbIa79zdZURVs=; b=WJCVXuIFjp/HT+Lzp8ElOSK38xJDkvZ1+Zjm2S5AeJWYbQ6E6t0p7kMzMgn2FIDX8m dkEuKQ7i4l0xchb4emJFIq1AUsczb0Sz3bk/4DgsIh4yO3ciuh5RFmYk7mpXzxvfvsRm JcNCZKYa+mA9Bwt93hiGD7G5XjLeJY0i8ciboG1f13Q7dy3LXMbyD2mLya4kIYiUbJ76 pKw+Uc1QKy8czpedKTujIrpJEal76qjTP0+mjfjMGtPskSFiy/hstYlAkZ7lWY9m8IRq 8T51buM/2nhUX6q7cRWx5duTDW2KxUuKW8X0JKvRE/6v/Dmuc3TA0SQSI0SqbMCYWl+c K6UA== X-Gm-Message-State: AG10YOQ0dAiSO94dwQF42KdXl55IbxAWVT71EgwpW59b+rIu2wGO7K5pOnI9jvJFTFcQXQ== X-Received: by 10.194.123.103 with SMTP id lz7mr15267560wjb.140.1453877138017; Tue, 26 Jan 2016 22:45:38 -0800 (PST) Received: from [10.4.101.58] ([80.179.9.115]) by smtp.gmail.com with ESMTPSA id js8sm4584471wjc.37.2016.01.26.22.45.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 22:45:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Wed, 27 Jan 2016 08:40:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A0FC1C9-D956-4FDB-8A1C-4ACA6A0A9BC1@gmail.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 06:45:41 -0000 > On 27 Jan 2016, at 5:51 AM, Martin Thomson = wrote: >=20 > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. >=20 > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 Quoting: > My view: just because DH_anon is confused, doesn't mean we can't fix = it for ECDH(E). OTOH RFC 4492 has been around for a while. Renaming the label now could = cause confusion. Another point to consider is that we=E2=80=99re = deprecating all the fixed ECDH ciphersuites, so now all ECDH is ECDHE. So, I don=E2=80=99t know=E2=80=A6 Yoav From nobody Wed Jan 27 00:13:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8D1B35A5 for ; Wed, 27 Jan 2016 00:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MOaKS6Q4f9D for ; Wed, 27 Jan 2016 00:13:37 -0800 (PST) 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 254411B359F for ; Wed, 27 Jan 2016 00:13:37 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 9C85F1C5F59; Wed, 27 Jan 2016 08:13:36 +0000 (UTC) Received: from dhcp-10-40-2-235.brq.redhat.com (dhcp-10-40-2-235.brq.redhat.com [10.40.2.235]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0R8DYjA000959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jan 2016 03:13:35 -0500 Message-ID: <1453882414.26912.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson , "tls@ietf.org" Date: Wed, 27 Jan 2016 09:13:34 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 08:13:38 -0000 On Wed, 2016-01-27 at 14:51 +1100, Martin Thomson wrote: > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. > > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 My understanding of DH_anon and ECDH_anon is that they were made to be used with static keys so even though anonymous one could verify that he connected to the same server by checking the server's keys. I don't believe anyone actually implemented that mode (I'm mostly speculating) and most of the anon usage is with ephemeral keys, thus this proposal makes sense. However if the name is changed to underline the ephemeral part, it would be nice to document the change of the intended purpose of these ciphersuites. regards, Nikos From nobody Wed Jan 27 01:39:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0661B379B; Wed, 27 Jan 2016 01:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1iQiAq8FruC; Wed, 27 Jan 2016 01:39:30 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DDA11B3794; Wed, 27 Jan 2016 01:39:28 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-6c-56a8904e04e5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.F5.02707.E4098A65; Wed, 27 Jan 2016 10:39:26 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Wed, 27 Jan 2016 10:39:25 +0100 To: IETF AVTCore WG , "tls@ietf.org" From: Magnus Westerlund Message-ID: <56A8904D.10307@ericsson.com> Date: Wed, 27 Jan 2016 10:39:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM2K7pa7fhBVhBr9nq1m87FnJbvHpfBej A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyWk+sZCz4z1Yx95BFA+ND1i5GDg4JAROJ/S+Euxg5 gUwxiQv31rN1MXJxCAkcZpT4+usWK4SznFFixsGfjCBVIgKOEvs/r2IHsdkELCRu/mhkA7GF BRwkfn7dygxi8wpoSsz7OgGsnkVAVeL62fesILaoQIzExc4jTBA1ghInZz5hATmCWcBe4sHW MpAws4C8RPPW2WBjhAS0JRqaOlgnMPLNQtIxC6FjFpKOBYzMqxhFi1OLk3LTjYz0Uosyk4uL 8/P08lJLNjECw+rglt8GOxhfPnc8xCjAwajEw2twaHmYEGtiWXFl7iFGCQ5mJRFe8cgVYUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5D/IvChMSSE8sSc1OTS1ILYLJMnFwSjUwWs9Tmqvp3LRq D9f23xlBog8/vFrqtscw8fa7xTYPC1iXXPStfCLRX3Pnx785k6YvNJihtMLuyNvZz9c0zEy1 zP3z9qGivoFnqtT1+e+MnN7NnRV9wOYhT9aXA5fcpq8sXP7YxtnB0Nf/rlv7W8V/0v+ORHBM 1Ui8+W6Se99HJQfXzwUZU+L6IpVYijMSDbWYi4oTAQ6XPsYnAgAA Archived-At: Subject: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 09:39:31 -0000 AVTCORE and TLS, TLS WG, you are included in this WG last call, as this document affects the TLS ContentType IANA registry. This email starts a two week WG last call, that ends on the 10th of February. The intended status of this document is standards track (Proposed Standard). The document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jan 27 06:12:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E01B2E8D for ; Wed, 27 Jan 2016 06:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 3xLBQeKGbcXl for ; Wed, 27 Jan 2016 06:12:39 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0991B2E8C for ; Wed, 27 Jan 2016 06:12:38 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id 1so19887121ion.1 for ; Wed, 27 Jan 2016 06:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZNPS0Cp41N9EOTzrel1ZeLWSGv47ijQ2OO4K2hM088=; b=LxnTK2uxszF6BvCEgp0DK3nvt83E6yNTW89Kz1q5zOpyeboxYXlcEZcEKeh/R8EtgR WLNF9U/q09hBo0ZOpeSq8evVIY7UTx7jDIMWzgCsM9MkScqCk/LLVhEy/riL74PfHXdG pqx35vOtHPzrQ7cGlci9Qh8pNS2/703INcNGiOTwo469yNjlaXa00iMcBPVn5YG705dz 6OWKWzVCrD35fHmDAedCETM43oDaMpfDOHf2JZMwmpKv8tW28UI2kxG+ynxOpswcDvs7 48uX2dAfgZkDP9+t9pPpnWSWZA6vdN0rSrQndn9JaLjwNC9MMywszHTh4SVfhZdH4iJ7 vHcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YZNPS0Cp41N9EOTzrel1ZeLWSGv47ijQ2OO4K2hM088=; b=korX2Dx83WKGT2+lIEXQTni2IhQB+mDbZPVxh1Rm5Ht88ndmGXx5lVFtcLQ05FePqw luaFU3PkG9/y1RCxlaHP/3Qcq0DW9MItgRIiVvzotbhPy4OamCnZyvvQUoS8uB1/TXON u+Rg/hI7OXr2I4C2dB0glpk496XfNilg+jENCpivXSfASvNx/+HKCrRcJkh/3JIIjKRH sYoDX/hvRmMib+0QMS7Syrig0GL35iVoSRHpR+992p8jS/FGc8MY//J9TkZy+eNmg2k6 y3+vedyjY2O5CN04yP6GVvoXXPrYI4ooc3J+onlCHes2UgM/F3icY1N+J89ynQqTp5w6 1v2Q== X-Gm-Message-State: AG10YOQM3hn8DmjRACHjzwLwkqQ4Bz/qOewc0jOJBVqHENjU3VdD4p05HM0Ck+WxtaIhWNQFN3JHjnUaNGO51gRS MIME-Version: 1.0 X-Received: by 10.107.132.231 with SMTP id o100mr29553677ioi.60.1453903958155; Wed, 27 Jan 2016 06:12:38 -0800 (PST) Received: by 10.107.141.12 with HTTP; Wed, 27 Jan 2016 06:12:38 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 06:12:38 -0800 Message-ID: From: Bill Cox To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ebf54f6fd3d052a5164e0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 14:12:40 -0000 --001a113ebf54f6fd3d052a5164e0 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson wrote: > > I get your point, but I don't see that as a simplification. In my > mind, post-handshake client authentication doesn't happen. Or, I > don't see it being commonplace. The use case described to me was for a higher level of authentication, such as when accessing a source-code repository at work, similar to proving that you still possess a security key now and then. I am not sure why FIDO does not fit this use case better, though. I have a feeling this is a legacy use case of client certificates, and is being included to avoid having to transition a lot of legacy client-cert based systems to FIDO. The CertificateVerify message is still listed as an option in the 0-RTT client's first flight at t = 0. Is this a mistake? I have not heard that anyone wants to do this, as there is no possibility of a traditional proof-of-possession in the first flight. However, with QUIC-like strike registers, a reasonably accurate timestamp in the handshake, and a secure clock on the client, you can approximate a proof-of-possession. This seems like a lot of trouble for a first-flight CertificateVerify, but if someone wants to do this, it could stay in the spec. If CertficateVerify is to remain in the 0-RTT first flight, there needs to be some way to provide a timestamp in the handshake hash. Is there a way to do this now? The TLS 1.2 timestamp in the client random seems to have been removed. Bill --001a113ebf54f6fd3d052a5164e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 26, 2016 at 7:32 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:

I get your point, but I don't see that as a simplification.=C2= =A0 In my
mind, post-handshake client authentication doesn't happen.=C2=A0 Or, I<= br> don't see it being commonplace.

The use= case described to me was for a higher level of authentication, such as whe= n accessing a source-code repository at work, similar to proving that you s= till possess a security key now and then.=C2=A0 I am not sure why FIDO does= not fit this use case better, though.=C2=A0 I have a feeling this is a leg= acy use case of client certificates, and is being included to avoid having = to transition a lot of legacy client-cert based systems to FIDO.
=
The CertificateVerify message is still listed as an option i= n the 0-RTT client's first flight at t =3D 0.=C2=A0 Is this a mistake?= =C2=A0 I have not heard that anyone wants to do this, as there is no possib= ility of a traditional proof-of-possession in the first flight.=C2=A0 Howev= er, with QUIC-like strike registers, a reasonably accurate timestamp in the= handshake, and a secure clock on the client, you can approximate a proof-o= f-possession.=C2=A0 This seems like a lot of trouble for a first-flight Cer= tificateVerify, but if someone wants to do this, it could stay in the spec.= =C2=A0 If CertficateVerify is to remain in the 0-RTT first flight, there ne= eds to be some way to provide a timestamp in the handshake hash.=C2=A0 Is t= here a way to do this now?=C2=A0 The TLS 1.2 timestamp in the client random= seems to have been removed.

Bill
--001a113ebf54f6fd3d052a5164e0-- From nobody Wed Jan 27 07:09:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EBC1B2F65 for ; Wed, 27 Jan 2016 07:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIjQ1fhqDLgX for ; Wed, 27 Jan 2016 07:09:02 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 6D90D1B2F61 for ; Wed, 27 Jan 2016 07:09:02 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id v14so243679943ykd.3 for ; Wed, 27 Jan 2016 07:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PZJd3bnoupsfrzP2jznPKcdgnHZGnRpXbBCriEXgJXE=; b=y3g2NMkfN03P4EZLj2oiGmqysZ/lRtla1RLP2XjiiIQjPnsKGmTaECFatkwWdMFeuY RG9aJ9uya6F1yTlA5rNa0csqhokfJEoi2Zy16zZl4hSxh7KYNnjF6kEojEfoMGMQ0jH/ AdB4vmvmzvvV84Xv7nQGMk2WW4BsIQx4O3gbeF47J5+QJP8Ce2rD5TBdRE5HI2ZGF83K iwX09QtuValxerLf8ZoVnkzHgyp6OCGGE9tv6VpKZof1wWwegqOevxIet77I1rSFq6OI AzTjS3FfRx+arhYgbvc8sYFTiZTwrHThgjy5KcM5s2WQWdm4vlLSgGxx2SrhQlEZo2/0 qUXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PZJd3bnoupsfrzP2jznPKcdgnHZGnRpXbBCriEXgJXE=; b=Aetl6gvvkG3NmlhQTeLmsIfhlgWcuoNdOo6s7H5CMiNpEcJcDwBfFjRA+/0Cp+mviY rx2dmQYNBqAlXaXL5CW9XcwNLi/Fhw92rkRZqJOBQaZ93bGYOlFZL6hwR1TW4s536hBI cs4FxjiRS8IVi6bL5T5gwq6ZIvwctjk1eLirpuFdqanAkEbtd47mIRXguFQmUjTec0UI AoAaz6NZnJmY8xH+g+AafRw7PcKNq842sVrfM40zebLVY3sNexLy9O3KMsuR32kJaRVy UVR0WRiOL9U24yrTAxKRmWrk/t0CAJep8kNnyexkL1YYqmxAyYrTmmM+fQQ1MIhbYN7a jj+g== X-Gm-Message-State: AG10YORRI9Rqt3vBUdS9OTbqpud3p6kxc7lATq1PJctNWXcDLfOn8gE3V/HYu+gIpwvF5OR+B+CGYDigvvhoaQ== MIME-Version: 1.0 X-Received: by 10.129.123.134 with SMTP id w128mr14670223ywc.345.1453907341489; Wed, 27 Jan 2016 07:09:01 -0800 (PST) Received: by 10.13.216.150 with HTTP; Wed, 27 Jan 2016 07:09:01 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 07:09:01 -0800 Message-ID: From: Watson Ladd To: Bill Cox Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 15:09:04 -0000 On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox wrote: > On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson > wrote: >> >> >> I get your point, but I don't see that as a simplification. In my >> mind, post-handshake client authentication doesn't happen. Or, I >> don't see it being commonplace. > > > The use case described to me was for a higher level of authentication, such > as when accessing a source-code repository at work, similar to proving that > you still possess a security key now and then. I am not sure why FIDO does > not fit this use case better, though. I have a feeling this is a legacy use > case of client certificates, and is being included to avoid having to > transition a lot of legacy client-cert based systems to FIDO. All certificate based authentication over HTTP is currently done by renegotiation, when the client chooses to access a protected resource a Renegotiation Request is sent, leading to the client certificate being provided in the second handshake. It's true that FIDO will be a better solution (currently unfinished), but when changing TLS stacks to work with TLS 1.3 we need to support this case, without requiring changes to application code below this. > > The CertificateVerify message is still listed as an option in the 0-RTT > client's first flight at t = 0. Is this a mistake? I have not heard that > anyone wants to do this, as there is no possibility of a traditional > proof-of-possession in the first flight. However, with QUIC-like strike > registers, a reasonably accurate timestamp in the handshake, and a secure > clock on the client, you can approximate a proof-of-possession. This seems > like a lot of trouble for a first-flight CertificateVerify, but if someone > wants to do this, it could stay in the spec. If CertficateVerify is to > remain in the 0-RTT first flight, there needs to be some way to provide a > timestamp in the handshake hash. Is there a way to do this now? The TLS > 1.2 timestamp in the client random seems to have been removed. All 0-RTT data is replayable, but I don't see what replaying a authenticated replayable connection gets you. > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Jan 27 07:18:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C611B2FB6 for ; Wed, 27 Jan 2016 07:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LXkZE26j5q7 for ; Wed, 27 Jan 2016 07:17:57 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6001A1B2FB3 for ; Wed, 27 Jan 2016 07:17:57 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u0RFHmCK013159; Wed, 27 Jan 2016 10:17:48 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Nikos Mavrogiannopoulos , Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] ECDH_anon Thread-Index: AdFZFeVfmsLQSQMYSkuJskrHUeu4xQ== Date: Wed, 27 Jan 2016 15:17:55 +0000 Message-ID: <20160127151803.17788998.50067.47728@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1096376150==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1507310008 definitions=main-1601270250 Archived-At: Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 15:17:59 -0000 --===============1096376150== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable IMHO it's not a good idea to re-purpose existing cipher-suites and alter th= eir observed behavior. Likewise for the name overloading.=C2=A0 Anon =C2=A0=E2=80=8E!=3D Ephemeral, despite some similarities.=C2=A0 My apologies if I'm missing the point or the frame of a larger issue. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Nikos Mavrogiannopoulos Sent: Wednesday, January 27, 2016 03:13 To: Martin Thomson; tls@ietf.org Subject: Re: [TLS] ECDH_anon =E2=80=8E On Wed, 2016-01-27 at 14:51 +1100, Martin Thomson wrote: > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. >=20 > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 My understanding of DH_anon and ECDH_anon is that they were made to be used with static keys so even though anonymous one could verify that he connected to the same server by checking the server's keys. I don't believe anyone actually implemented that mode (I'm mostly speculating) and most of the anon usage is with ephemeral keys, thus this proposal makes sense. However if the name is changed to underline the ephemeral part, it would be nice to document the change of the intended purpose of these ciphersuites. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============1096376150== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDEyNzE1MTgwMVowLwYJKoZIhvcNAQkEMSIEIMwKliTserlK VPjh46drJr3XQPWUJubBFKBJOW5wNsKjMAsGCSqGSIb3DQEBCwSCAQAJ1Pnx51XBB9u4pNx9zpCE Of/q1Y2J8TCUxsFjTXxMDhcW6Lwu4p2CB34XYdUyPlJmSYwc2ElI/2gKaCcMMLsdfSa9Gc4aOIP8 cPuzIDeTLCPh9Rc86k3TWH/yOa8+Wtp4js/9jg0jfM1VFyy7hCRY3B50pXFwbA1Ys0LD8ugFgAjO tTDaYkXkiWAshQRvqejy295L0vpZiDrwa7249ORSIaPL7sQ+mk5K+ZAUDU/mzBj4LzaMFjumhANj 8suiRLxVBK2xwGpCwUQ4be0I3cnJN20cf9cjTLwjsfAQEZd8i4q7qX1yQ126tPgdZvKEQ4lFp51j RfwY76hVBoxPRojiAAAAAAAA --===============1096376150==-- From nobody Wed Jan 27 08:13:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8CE1A8A3E for ; Wed, 27 Jan 2016 08:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 HCZrFD75v07j for ; Wed, 27 Jan 2016 08:13:12 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E899E1A8A3A for ; Wed, 27 Jan 2016 08:13:11 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id h5so14903336igh.0 for ; Wed, 27 Jan 2016 08:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f6G19Y6GXsX4txBrJJJBC4VZXEt7x7rQj2ewSYIlgMs=; b=b+Jhp98w+axe+MMceLtHv+sK3AIZBYnvyPl06nvG5qYRTtLRycbf3IF1lZnDdZ1v19 yGmv+dwOAwEx8vS3jnzBH9vGoYGsWJyAeZ+MYhDFXYEoEC+TwQ773d4Y9Pv6a3AQ6tUH 7vlQDTP4r6Ukk24c9hohq9l+4dfW/ht1hz7/W67mFPB6cRLB7jrpZNymHJJTqiNU5q4S XzNhtVBSjc/Fm6Mn/j3iVZVKcek/aVS9mm+PykgHmMP5rZk+lRvHYUp3buYp86/f+1ow +kNdIm8MyNPx6LSv0X9j8pf4BOc527kMz8xdLB8sqVlmeW9IW87Dfw/yMyKI9nGX595L kCww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f6G19Y6GXsX4txBrJJJBC4VZXEt7x7rQj2ewSYIlgMs=; b=gcu4S/Q7eOGJ6rV6rZf/LfbFk8RzAnZHIAufObV7hSBUTNTJr9Bx9VdbE3Op+1C6zC HMdR53jeU78AE8/AJB1N4uoUiOtGd6NtYx/Kwu6BUqKwGqPzDAF707lV2GXEXgEZbSSg k45ZRrEQIGSZXXIr93xPmFXei968FjdNt+qRxxKcG78RadIGFWCVAF/lhvkIn8GWQmGh y3wE4dmhPiHwEbM47wzPf1kW/+sSH+ECF8RNdxbH7FWGQkMNp0L5wK6Kpf9zMTCwIC8G yKgIlLRx/VwVxNsL8uo0guqjLbaQGFFMTXvFvp4SkhdyXEQGAtw+IY9Re4/uuV6hEjxg 1lpA== X-Gm-Message-State: AG10YOTIMNVnDw8x4aJhTqSfXOtGYOvotE97Q8cHaO8C5FQPq0pJN5Rog3TiTVUmOQhopS5AKhKIp37ohicV7Zuu MIME-Version: 1.0 X-Received: by 10.50.61.209 with SMTP id s17mr29789681igr.40.1453911191317; Wed, 27 Jan 2016 08:13:11 -0800 (PST) Received: by 10.107.141.12 with HTTP; Wed, 27 Jan 2016 08:13:11 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 08:13:11 -0800 Message-ID: From: Bill Cox To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bdc14e6185080052a531417 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 16:13:15 -0000 --047d7bdc14e6185080052a531417 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 27, 2016 at 7:09 AM, Watson Ladd wrote: > > All certificate based authentication over HTTP is currently done by > renegotiation, when the client chooses to access a protected resource > a Renegotiation Request is sent, leading to the client certificate > being provided in the second handshake. It's true that FIDO will be a > better solution (currently unfinished), but when changing TLS stacks > to work with TLS 1.3 we need to support this case, without requiring > changes to application code below this. > Thanks for the explanation. That makes sense. > > All 0-RTT data is replayable, but I don't see what replaying a > authenticated replayable connection gets you. > I do not either. However, a 0-RTT CertificateVerify from the client is not as secure as a regular CertificateVerify. I doubt anyone has a use case for it in the near-term, and with FIDO coming in the future, I would recommend removing it from the 0-RTT first-flight diagram. There, did I actually suggest something useful for TLS 1.3? It will make my day if so... :) Bill --047d7bdc14e6185080052a531417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 27, 2016 at 7:09 AM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:

All certificate based authentication over HTTP is currently done by<= br> renegotiation, when the client chooses to access a protected resource
a Renegotiation Request is sent, leading to the client certificate
being provided in the second handshake. It's true that FIDO will be a better solution (currently unfinished), but when changing TLS stacks
to work with TLS 1.3 we need to support this case, without requiring
changes to application code below this.

Thanks for the explanation.=C2=A0 That makes sense.

All 0-RTT data is replayable, but I don't see what replaying a authenticated replayable connection gets you.

I do not either.=C2=A0 However, a 0-RTT CertificateVerify from the c= lient is not as secure as a regular CertificateVerify.=C2=A0 I doubt anyone= has a use case for it in the near-term, and with FIDO coming in the future= , I would recommend removing it from the 0-RTT first-flight diagram.
<= div>
There, did I actually suggest something useful for TLS 1= .3?=C2=A0 It will make my day if so... :)

Bill
--047d7bdc14e6185080052a531417-- From nobody Wed Jan 27 09:45:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8533A1AD070 for ; Wed, 27 Jan 2016 09:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOwNtZeFasT0 for ; Wed, 27 Jan 2016 09:45:01 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 0AFCA1AD06D for ; Wed, 27 Jan 2016 09:45:01 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id z14so86325905igp.0 for ; Wed, 27 Jan 2016 09:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5k/OjWysm907k+IzfVke6k8EnDZpn9LVZB3drGFjJak=; b=N8ImPwUOcbDwCB+XDcOOECnNrvwDPOADChGcgqKq7qrtK6U9GvOQHydT38kU8Hve0t CbGd4C0dFMndqTKGqrsfcx3gaJaAsOM0Vg9LnPX0nT/3JFdlW2lsvBCKQUOrWXOfYPfC M1t7RAvBNhFF7G9ikAKzpdSnPElWAhUzgY3ZOhkQnWZRqHX03k+3jEjYyosSoQ+9XHoA S1MaDFk6UnI3AHZkR6G3R0Bqj/GlUKOVAPl7yoaHLJwWSosTbmVO+TDM9xYPTMx4PmYX rS/I54Fi/89TafET1YLlMdufonMFIqCClLAlUTD2cd4f09Umy0snTKbB3xx5io/ibM6C cAAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5k/OjWysm907k+IzfVke6k8EnDZpn9LVZB3drGFjJak=; b=Gs2P1Dw9UlQtxbhJTuOTHigfvrhginXnw1t2azIG0m6apijPJclNcWRvQ+fgksk95Y cXdOTbyqE4HR9Q7yxLE62GB3Sx4DULO09CL2abD9seJag0XUwHqoW691VLwjAf+bFMBd PJkGb8KbkEV8OmXg3SZx/uG2BUSTkzxxi71RlbPil0i8rwowsYqFX5IJ1fcLKnfPmQu+ 357Ur5LBa2vCIBPl9PctmldBKRl9m6Z7hniK52NigojO8Afc5iSuoHdFH8iJW45hYHKX i/CWE4jJKdo7Hu2ZJ6Tdpwm/gR7NLuuTcV2B+sA2pgOAQbEHDTRjnVVpc4jIPhHSGQyu ay7A== X-Gm-Message-State: AG10YOTBZ1lZ6ddR6BAEwZuLe9vj5PRzyhiuU+VFbaULYtGHaBxEDQPtd5IgAPPYWwqwldiUbcvT/MyXn0OSdw== MIME-Version: 1.0 X-Received: by 10.50.171.200 with SMTP id aw8mr32257117igc.77.1453916700344; Wed, 27 Jan 2016 09:45:00 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 27 Jan 2016 09:45:00 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Jan 2016 04:45:00 +1100 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 17:45:02 -0000 On 28 January 2016 at 02:09, Watson Ladd wrote: > All 0-RTT data is replayable, but I don't see what replaying a > authenticated replayable connection gets you. If the 0-RTT flight includes actions (especially non-idempotent ones) that only apply if the authentication is correct, then you get authenticated replayable actions. e.g., "please pay Watson $10, my certificate authenticates this request" From nobody Wed Jan 27 09:47:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7243A1AD0BB for ; Wed, 27 Jan 2016 09:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoadNabEUf4p for ; Wed, 27 Jan 2016 09:47:40 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89831AD0B9 for ; Wed, 27 Jan 2016 09:47:39 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id h5so16866807igh.0 for ; Wed, 27 Jan 2016 09:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EQDAOuwK94IUtuA9ttn/btVTU+SDVpcuqpCveZ4eqiE=; b=QRiZNT8NhHkie3wKSabjKRT1T5/i8lwLIDeucOm+7mtBuyDwEhHcdFnm2NOUA5Cud1 xb6XDE4686Q2kO2uK8Iekrrw/RvNN77IdVVXqkPQ9CKLRVw/sATdSzGYYUuISV8Ptlsx RbC8LbdaYxyrgKkEtn4++YX3Ngz2MgDR9OqpFLiyNMU8X7NoIhVeWgvhaH9LqWvH6hH7 2/oXOHoDamkv78n9CKt7G2vlIBwRzXfcUqr96722WVQdLvrY2tT9YRUVMxSDrYgpToTj wCVx07hEXG6u+BEAvUBbVUcqwTTqAxtr71ttXoeKOZbxSubhjyJaWL3EdRD7m6opan9Z E/cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EQDAOuwK94IUtuA9ttn/btVTU+SDVpcuqpCveZ4eqiE=; b=MT0s3PsfYECo/8Zlbrc3IGPnZkNUbQKYHa2bujlzRMemNDObF+gIN+MbQoIwoFfaXF T+eccxDf5v+q6XkL7lxVBpS72bIwd/vzPBMF1+THzA/Xzmdz6udcmLWMqsrPrLXGfnuv jhRfqgnIuI4VW+6QOgmF6uJhS9Oq6jstkDUMV8iZXgkYLogTbpZyVSZK8fs55/64/YJm IuudqRZDBdzr6S+Jd74i6FkwLjIzYPUAov54BYpRHjkDqZvJFUegwF0ACw2gW2G+JuiT 6+8WAOdmUCyvR/GqwNrFtjm2cgrHeaVOatrJv5cFqc7cX9/3S4ue/4x4CnYIpd5+1AyA rnIg== X-Gm-Message-State: AG10YOQRzPFTglVZLGCYGCwT6iSLj9pdWQbVd7yUQaH5Cdrehw0DSEcXhr6Bo4QXHF/cv9PKCqhrw5zyjYoeuQ== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr32197294igt.94.1453916859110; Wed, 27 Jan 2016 09:47:39 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 27 Jan 2016 09:47:39 -0800 (PST) In-Reply-To: <20160127151803.17788998.50067.47728@ll.mit.edu> References: <20160127151803.17788998.50067.47728@ll.mit.edu> Date: Thu, 28 Jan 2016 04:47:39 +1100 Message-ID: From: Martin Thomson To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 17:47:41 -0000 On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL wrote: > Anon =E2=80=8E!=3D Ephemeral, despite some similarities. >From a protocol perspective, they are the same. The distinction at the protocol level between ECDH_RSA (for example) and ECDH_anon is that ECDH_anon requires a ServerKeyShare message in the same way that ECDHE_RSA does. I agree that Nikos' point is a good one, but we've implementations of ECDHE_ that provide a stable value for their ephemeral key (unfortunately, that's the default mode in NSS). From nobody Wed Jan 27 09:57:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DD61AD2DF for ; Wed, 27 Jan 2016 09:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3_fr4cLip3d for ; Wed, 27 Jan 2016 09:57:49 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 71DCE1AD2EE for ; Wed, 27 Jan 2016 09:57:49 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u0RHverd037906; Wed, 27 Jan 2016 12:57:40 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Martin Thomson Thread-Topic: [TLS] ECDH_anon Thread-Index: AdFZFeVfmsLQSQMYSkuJskrHUeu4xQAPtPaA//+u94A= Date: Wed, 27 Jan 2016 17:57:47 +0000 Message-ID: References: <20160127151803.17788998.50067.47728@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3536744257_103185366" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1507310008 definitions=main-1601270292 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 17:57:51 -0000 --B_3536744257_103185366 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 1/27/16, 12:47 , "Martin Thomson" wrote: >On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL > wrote: >> Anon =E2=80=8E!=3D Ephemeral, despite some similarities. > >From a protocol perspective, they are the same. If you mean that you cannot distinguish between the two on the wire - I agree. >The distinction at the protocol level between ECDH_RSA (for example) and >ECDH_anon is >that ECDH_anon requires a ServerKeyShare message in the same way that >ECDHE_RSA does. The distinction is in what you can do with the exchange. >I agree that Nikos' point is a good one, but we've implementations of >ECDHE_ that provide a stable value for their ephemeral key >(unfortunately, that's the default mode in NSS). But that is BAD (and it=E2=80=99s gotta change ;). It=E2=80=99s like implementations th= at always generate random number =E2=80=9C0=E2=80=9D (no smileys - I=E2=80=99ve seen those). --B_3536744257_103185366 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgpvmLQCRj8FDOJgl3QbdDF5iIMr5agLxkiO1VH4vCOd8wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMTI3MTc1NzM3WjANBgkqhkiG9w0BAQEFAASC AQBSAeUqRjbrwhIwD79IylAe40szKOKBP+j8D8gX9VDTLeVneHJPy78znBErn6eFBbu4fVWA kHMXrqPAHu86+5a18PGYi8/zw34bCEXjaVm0SGOyM/dKFR6ZfCXgzthyqWCKoAvIb1DaZknf p3hhcJ3jwAUiu0HUiPnO9owgkIkAjxA9DJboMkkbIeLIaJ7drKE46Aa8y5UIP+MxnM1VQqHq BxvP3JlZ4G3AnbcNkt2OeOEtetTpknZlFprqF8IanHA4UQUizC0Py05QID845DEf1IY6FE6a 1xFMjMFkEU/RRO7DJ3fwrGkd3vxZlpAPbT1/yaoxI9+f0dDGpNJfOTNP --B_3536744257_103185366-- From nobody Wed Jan 27 09:58:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D11AD35C for ; Wed, 27 Jan 2016 09:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9Z0D6e6_sek for ; Wed, 27 Jan 2016 09:58:28 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E2C1AD350 for ; Wed, 27 Jan 2016 09:58:28 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id a85so503485ykb.1 for ; Wed, 27 Jan 2016 09:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eQ5KCChSKoyiQ4A9KLIE3Lu+1CgSYWiZFqGcm71+Q7M=; b=gUNfuO8qOqem0E4U+tGMTmvT9bvZhqzkBR0ItlQwlXyj+eNMZ7MD7vfHPWbiEJ/QXd 0lQNP6TFmJe746i63QgLNyCiTP3u4i++jZ7IDgFuloClb3SseGwhr3xQEyH+mhtSgpa8 O/FczYExxHHCJCdg5dJaFyc2ZsZ47hNbWCSPq2KNiFvyerbCw2xmXR9HQXYfKQVVPoRQ qy2zSpg+5/l8dxsTrTGjN3M+gS0TxwU5n+O9mqfjFNtN8UWFjdX1WL99DHYECK3ATO16 lu1YgON6Fni7LdODup8z2Aw85mICx4bqlmsUHczdtNYoMRqZu5sOwJaGN0VtjZkoIWW3 8tfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eQ5KCChSKoyiQ4A9KLIE3Lu+1CgSYWiZFqGcm71+Q7M=; b=mt5RWbGe8X836Em114XLGjnPCE5szIgrXYZjoUYGaw/W7vLx1Q0P+5njdul+HFFeSB NJWLZ+gk20HSwdp2sOWoyx/XxMFbFiwW1cVyBVHRe6/J2V65+4V0iP9lxFWpL6DZ7woc QTe/FODD0CkE8To96Hb4JYUGitd0GWR0EMcllEZinmvrnHVWtTTMdMMf583XmYMBEAnh hVIkohSDAy3oX7S78sTtIxJQKsKWibJcI/eFyHuDDaDmxXn23Ij5ke3qPqP2igGnRJSL sKfexwHPGNbMXEey8vFxz7Jz7I3e4AtdzpvtsO6U2YQ1gmQyR5DgkZ9AqMnnDjZpFSic Uu7A== X-Gm-Message-State: AG10YOSpmcKffxLuRfbjXhMpFBuj+BAAGSGrBtIUL1ExbGuyHkGfE5NH+SkQchq8rxhl4dUq+cE5eUQNkuhpHg== MIME-Version: 1.0 X-Received: by 10.129.49.201 with SMTP id x192mr15320573ywx.8.1453917507708; Wed, 27 Jan 2016 09:58:27 -0800 (PST) Received: by 10.13.245.130 with HTTP; Wed, 27 Jan 2016 09:58:27 -0800 (PST) Received: by 10.13.245.130 with HTTP; Wed, 27 Jan 2016 09:58:27 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 09:58:27 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11421f70947194052a548c9e Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 17:58:30 -0000 --001a11421f70947194052a548c9e Content-Type: text/plain; charset=UTF-8 On Jan 27, 2016 9:45 AM, "Martin Thomson" wrote: > > On 28 January 2016 at 02:09, Watson Ladd wrote: > > All 0-RTT data is replayable, but I don't see what replaying a > > authenticated replayable connection gets you. > > If the 0-RTT flight includes actions (especially non-idempotent ones) > that only apply if the authentication is correct, then you get > authenticated replayable actions. > > e.g., "please pay Watson $10, my certificate authenticates this request" We already know non-idempotent actions cannot be put into 0 RTT. --001a11421f70947194052a548c9e Content-Type: text/html; charset=UTF-8


On Jan 27, 2016 9:45 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 28 January 2016 at 02:09, Watson Ladd <watsonbladd@gmail.com> wrote:
> > All 0-RTT data is replayable, but I don't see what replaying a
> > authenticated replayable connection gets you.
>
> If the 0-RTT flight includes actions (especially non-idempotent ones)
> that only apply if the authentication is correct, then you get
> authenticated replayable actions.
>
> e.g., "please pay Watson $10, my certificate authenticates this request"

We already know non-idempotent actions cannot be put into 0 RTT.

--001a11421f70947194052a548c9e-- From nobody Wed Jan 27 10:00:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D901ACEA7 for ; Wed, 27 Jan 2016 10:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GnlDdE511Tv for ; Wed, 27 Jan 2016 10:00:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2E1AD37C for ; Wed, 27 Jan 2016 10:00:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0F50D433405; Wed, 27 Jan 2016 18:00:22 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id ECAA9433402; Wed, 27 Jan 2016 18:00:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453917621; bh=CWjA8klTVBUuFIZalmVtWLQQQWDf2QLcQ4aacuZ8Ku0=; l=334; h=From:To:CC:Date:References:In-Reply-To:From; b=TYuFMRfBUFbI5GdMgDiHNXFeYzGdB3Bw9WegQSIkTYAUEY1IYUnm6PWFgk08PQBzr pUWylsjP8Bs1XjNJcCpnc6GbhbL7IOf4JHZfMfBfHyTE4lrZ3rodQSY8jWEMwd6uAy cvQguQ+U4DZtB/a2QRF+YSRnaQxiHQC5ohIbKPlY= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E8E8B2030; Wed, 27 Jan 2016 18:00:21 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 27 Jan 2016 13:00:21 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 27 Jan 2016 10:00:21 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 27 Jan 2016 13:00:20 -0500 From: "Salz, Rich" To: Watson Ladd , Martin Thomson Thread-Topic: [TLS] 0-RTT, server Application Data, and client Finished Thread-Index: AQHRWJwzpseUkxx6aUyxZ7UgGUjD558O5p+AgAAIdgCAAAO1AIAAEIeAgAAF/gCAALLXAIAAD8GAgAArlQCAAAPCgP//rHwQ Date: Wed, 27 Jan 2016 18:00:20 +0000 Message-ID: <3b1040842cbc49cc825df0405cc1290a@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 18:00:25 -0000 PiBlLmcuLCAicGxlYXNlIHBheSBXYXRzb24gJDEwLCBteSBjZXJ0aWZpY2F0ZSBhdXRoZW50aWNh dGVzIHRoaXMgcmVxdWVzdCINCg0KV2UgYWxyZWFkeSBrbm93IG5vbi1pZGVtcG90ZW50IGFjdGlv bnMgY2Fubm90IGJlIHB1dCBpbnRvIDAgUlRULg0KDQpzL2Nhbm5vdC9zaG91bGQgbm90LyAgVGhp cyBtaWdodCBoZWxwIHByZXZlbnQgcHJvYmxlbXMuICBNaWdodC4gIEkgZG9uJ3Qga25vdyBpZiBp dCdzIHdvcnRoIGl0Lg0K From nobody Wed Jan 27 10:39:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1511B2AF2 for ; Wed, 27 Jan 2016 10:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU4fZ9Ed88zb for ; Wed, 27 Jan 2016 10:38:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158F41B2AEB for ; Wed, 27 Jan 2016 10:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GmTEduxhuHYv/YqfkSOWCkkHr6p1o434+U7+TA81Rm0=; b=IPsPSI6SiIOlLyDnTjau6mHVicIMWfd2GP+xUyfkXKA1ck3bEMRsOM1WgJDuPhUOyJbvlhBd95dVZNuulbXrCNZZK5DAcS1mPZB8E1yPEo4IvJ0pc9R72AZ4Wi/7/Rdj+1bl4FfOLI3f57gc25JaOK9FsQLKp+8noPpyxjSZMyQ= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 18:38:36 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0390.016; Wed, 27 Jan 2016 18:38:36 +0000 From: Andrei Popov To: Bill Cox , Martin Thomson Thread-Topic: [TLS] 0-RTT, server Application Data, and client Finished Thread-Index: AQHRWJwv+0HdYQ8oH0m7Wu7McZFM2Z8Oks2AgAAIdgCAAAO1AIAAEIeAgAAF/gCAALLYAIAASSRg Date: Wed, 27 Jan 2016 18:38:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: 7b72c66e-1f97-4a1a-db1a-08d32749114b x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:OJk1RNorXt1NB2UmiXAi3hjSSvFNoJJosYETBDBfVmsCbsM26dY4OnDrorcX5WL3hnj5jFSyEf9jEbQ1FvTKtB+QRp7g/JMvgB5kyh+QTh5jDgQbC4Bc7Nwf36B/XEWb86QUCNlkmA/pgeLe3Y8XeA==; 24:uh5qRMFA1E+dI77CbrHWNJHkquAQS/lXyr0LSMlRyLyDkb6d3+46x0iGGrge+JkzOGtO3jFB8qMmR4OC+B7S1jr6sQc5PreL/pR1nPPOHM8= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(24454002)(377454003)(93886004)(2906002)(122556002)(40100003)(1096002)(586003)(5008740100001)(102836003)(1220700001)(6116002)(3470700001)(92566002)(4326007)(5001960100002)(790700001)(3280700002)(5001770100001)(97736004)(81156007)(8990500004)(5004730100002)(5005710100001)(5002640100001)(10400500002)(10290500002)(86612001)(87936001)(11100500001)(86362001)(19625215002)(2950100001)(10090500001)(2900100001)(5003600100002)(77096005)(19300405004)(189998001)(15975445007)(19580405001)(19580395003)(76576001)(50986999)(76176999)(54356999)(99286002)(106356001)(101416001)(105586002)(74316001)(106116001)(16236675004)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13968A662C564ACB3C33779E8CD90BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 18:38:36.2995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 18:39:00 -0000 --_000_BLUPR03MB13968A662C564ACB3C33779E8CD90BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBDZXJ0aWZpY2F0ZVZlcmlmeSBtZXNzYWdlIGlzIHN0aWxsIGxpc3RlZCBhcyBhbiBv cHRpb24gaW4gdGhlIDAtUlRUIGNsaWVudCdzIGZpcnN0IGZsaWdodCBhdCB0ID0gMC4gIElzIHRo aXMgYSBtaXN0YWtlPyAgSSBoYXZlIG5vdCBoZWFyZCB0aGF0IGFueW9uZSB3YW50cyB0byBkbyB0 aGlzLCBhcyB0aGVyZSBpcyBubyBwb3NzaWJpbGl0eSBvZiBhIHRyYWRpdGlvbmFsIHByb29mLW9m LXBvc3Nlc3Npb24gaW4gdGhlIGZpcnN0IGZsaWdodC4NCkkgYWdyZWUgd2l0aCB0aGlzOiBjbGll bnQgYXV0aCBpbiAwLVJUVCBpcyByZXBsYXlhYmxlLCB1bmxlc3MgdGhlIHNlcnZlciB0YWtlcyBl eHRyYW9yZGluYXJ5IHN0ZXBzIChRVUlDLWxpa2Ugc3RyaWtlIHJlZ2lzdGVycywgZGF0YWJhc2Ug b2YgY2xpZW50IG5vbmNlcywgZXRjLikgTm8gcGxhbnMgdG8gaW1wbGVtZW50LCBhdCBsZWFzdCBm b3Igbm93Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjcsIDIwMTYgNjoxMyBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+DQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gMC1SVFQs IHNlcnZlciBBcHBsaWNhdGlvbiBEYXRhLCBhbmQgY2xpZW50IEZpbmlzaGVkDQoNCk9uIFR1ZSwg SmFuIDI2LCAyMDE2IGF0IDc6MzIgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIGdl dCB5b3VyIHBvaW50LCBidXQgSSBkb24ndCBzZWUgdGhhdCBhcyBhIHNpbXBsaWZpY2F0aW9uLiAg SW4gbXkNCm1pbmQsIHBvc3QtaGFuZHNoYWtlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBkb2Vzbid0 IGhhcHBlbi4gIE9yLCBJDQpkb24ndCBzZWUgaXQgYmVpbmcgY29tbW9ucGxhY2UuDQoNClRoZSB1 c2UgY2FzZSBkZXNjcmliZWQgdG8gbWUgd2FzIGZvciBhIGhpZ2hlciBsZXZlbCBvZiBhdXRoZW50 aWNhdGlvbiwgc3VjaCBhcyB3aGVuIGFjY2Vzc2luZyBhIHNvdXJjZS1jb2RlIHJlcG9zaXRvcnkg YXQgd29yaywgc2ltaWxhciB0byBwcm92aW5nIHRoYXQgeW91IHN0aWxsIHBvc3Nlc3MgYSBzZWN1 cml0eSBrZXkgbm93IGFuZCB0aGVuLiAgSSBhbSBub3Qgc3VyZSB3aHkgRklETyBkb2VzIG5vdCBm aXQgdGhpcyB1c2UgY2FzZSBiZXR0ZXIsIHRob3VnaC4gIEkgaGF2ZSBhIGZlZWxpbmcgdGhpcyBp cyBhIGxlZ2FjeSB1c2UgY2FzZSBvZiBjbGllbnQgY2VydGlmaWNhdGVzLCBhbmQgaXMgYmVpbmcg aW5jbHVkZWQgdG8gYXZvaWQgaGF2aW5nIHRvIHRyYW5zaXRpb24gYSBsb3Qgb2YgbGVnYWN5IGNs aWVudC1jZXJ0IGJhc2VkIHN5c3RlbXMgdG8gRklETy4NCg0KVGhlIENlcnRpZmljYXRlVmVyaWZ5 IG1lc3NhZ2UgaXMgc3RpbGwgbGlzdGVkIGFzIGFuIG9wdGlvbiBpbiB0aGUgMC1SVFQgY2xpZW50 J3MgZmlyc3QgZmxpZ2h0IGF0IHQgPSAwLiAgSXMgdGhpcyBhIG1pc3Rha2U/ICBJIGhhdmUgbm90 IGhlYXJkIHRoYXQgYW55b25lIHdhbnRzIHRvIGRvIHRoaXMsIGFzIHRoZXJlIGlzIG5vIHBvc3Np YmlsaXR5IG9mIGEgdHJhZGl0aW9uYWwgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBpbiB0aGUgZmlyc3Qg ZmxpZ2h0LiAgSG93ZXZlciwgd2l0aCBRVUlDLWxpa2Ugc3RyaWtlIHJlZ2lzdGVycywgYSByZWFz b25hYmx5IGFjY3VyYXRlIHRpbWVzdGFtcCBpbiB0aGUgaGFuZHNoYWtlLCBhbmQgYSBzZWN1cmUg Y2xvY2sgb24gdGhlIGNsaWVudCwgeW91IGNhbiBhcHByb3hpbWF0ZSBhIHByb29mLW9mLXBvc3Nl c3Npb24uICBUaGlzIHNlZW1zIGxpa2UgYSBsb3Qgb2YgdHJvdWJsZSBmb3IgYSBmaXJzdC1mbGln aHQgQ2VydGlmaWNhdGVWZXJpZnksIGJ1dCBpZiBzb21lb25lIHdhbnRzIHRvIGRvIHRoaXMsIGl0 IGNvdWxkIHN0YXkgaW4gdGhlIHNwZWMuICBJZiBDZXJ0ZmljYXRlVmVyaWZ5IGlzIHRvIHJlbWFp biBpbiB0aGUgMC1SVFQgZmlyc3QgZmxpZ2h0LCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdheSB0 byBwcm92aWRlIGEgdGltZXN0YW1wIGluIHRoZSBoYW5kc2hha2UgaGFzaC4gIElzIHRoZXJlIGEg d2F5IHRvIGRvIHRoaXMgbm93PyAgVGhlIFRMUyAxLjIgdGltZXN0YW1wIGluIHRoZSBjbGllbnQg cmFuZG9tIHNlZW1zIHRvIGhhdmUgYmVlbiByZW1vdmVkLg0KDQpCaWxsDQo= --_000_BLUPR03MB13968A662C564ACB3C33779E8CD90BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNjk0NDY2MjA7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yNDc3MDUwNTQgMTk1OTE1 MzYwMCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5UaGUgQ2VydGlmaWNhdGVWZXJpZnkgbWVzc2FnZSBpcyBzdGlsbCBsaXN0 ZWQgYXMgYW4gb3B0aW9uIGluIHRoZSAwLVJUVCBjbGllbnQncyBmaXJzdCBmbGlnaHQgYXQgdCA9 IDAuJm5ic3A7IElzIHRoaXMgYSBtaXN0YWtlPyZuYnNwOyBJIGhhdmUgbm90IGhlYXJkIHRoYXQg YW55b25lIHdhbnRzIHRvIGRvIHRoaXMsIGFzIHRoZXJlIGlzIG5vIHBvc3NpYmlsaXR5IG9mIGEg dHJhZGl0aW9uYWwgcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KIGluIHRoZSBmaXJzdCBmbGlnaHQuPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdp dGggdGhpczogY2xpZW50IGF1dGggaW4gMC1SVFQgaXMgcmVwbGF5YWJsZSwgdW5sZXNzIHRoZSBz ZXJ2ZXIgdGFrZXMgZXh0cmFvcmRpbmFyeSBzdGVwcyAoUVVJQy1saWtlIHN0cmlrZSByZWdpc3Rl cnMsIGRhdGFiYXNlIG9mIGNsaWVudCBub25jZXMsIGV0Yy4pDQogTm8gcGxhbnMgdG8gaW1wbGVt ZW50LCBhdCBsZWFzdCBmb3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5CaWxsIENveDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEph bnVhcnkgMjcsIDIwMTYgNjoxMyBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0 O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gMC1SVFQsIHNlcnZlciBBcHBsaWNhdGlv biBEYXRhLCBhbmQgY2xpZW50IEZpbmlzaGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAyNiwgMjAxNiBhdCA3OjMyIFBNLCBN YXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CkkgZ2V0IHlvdXIgcG9pbnQsIGJ1dCBJIGRvbid0IHNlZSB0aGF0IGFzIGEgc2ltcGxpZmljYXRp b24uJm5ic3A7IEluIG15PGJyPg0KbWluZCwgcG9zdC1oYW5kc2hha2UgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIGRvZXNuJ3QgaGFwcGVuLiZuYnNwOyBPciwgSTxicj4NCmRvbid0IHNlZSBpdCBiZWlu ZyBjb21tb25wbGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1c2UgY2FzZSBkZXNjcmliZWQgdG8gbWUgd2FzIGZvciBh IGhpZ2hlciBsZXZlbCBvZiBhdXRoZW50aWNhdGlvbiwgc3VjaCBhcyB3aGVuIGFjY2Vzc2luZyBh IHNvdXJjZS1jb2RlIHJlcG9zaXRvcnkgYXQgd29yaywgc2ltaWxhciB0byBwcm92aW5nIHRoYXQg eW91IHN0aWxsIHBvc3Nlc3MgYSBzZWN1cml0eSBrZXkgbm93IGFuZCB0aGVuLiZuYnNwOyBJIGFt IG5vdCBzdXJlIHdoeSBGSURPIGRvZXMgbm90IGZpdA0KIHRoaXMgdXNlIGNhc2UgYmV0dGVyLCB0 aG91Z2guJm5ic3A7IEkgaGF2ZSBhIGZlZWxpbmcgdGhpcyBpcyBhIGxlZ2FjeSB1c2UgY2FzZSBv ZiBjbGllbnQgY2VydGlmaWNhdGVzLCBhbmQgaXMgYmVpbmcgaW5jbHVkZWQgdG8gYXZvaWQgaGF2 aW5nIHRvIHRyYW5zaXRpb24gYSBsb3Qgb2YgbGVnYWN5IGNsaWVudC1jZXJ0IGJhc2VkIHN5c3Rl bXMgdG8gRklETy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIENlcnRpZmljYXRlVmVyaWZ5IG1lc3NhZ2UgaXMgc3RpbGwgbGlzdGVkIGFz IGFuIG9wdGlvbiBpbiB0aGUgMC1SVFQgY2xpZW50J3MgZmlyc3QgZmxpZ2h0IGF0IHQgPSAwLiZu YnNwOyBJcyB0aGlzIGEgbWlzdGFrZT8mbmJzcDsgSSBoYXZlIG5vdCBoZWFyZCB0aGF0IGFueW9u ZSB3YW50cyB0byBkbyB0aGlzLCBhcyB0aGVyZSBpcyBubyBwb3NzaWJpbGl0eSBvZiBhIHRyYWRp dGlvbmFsIHByb29mLW9mLXBvc3Nlc3Npb24NCiBpbiB0aGUgZmlyc3QgZmxpZ2h0LiZuYnNwOyBI b3dldmVyLCB3aXRoIFFVSUMtbGlrZSBzdHJpa2UgcmVnaXN0ZXJzLCBhIHJlYXNvbmFibHkgYWNj dXJhdGUgdGltZXN0YW1wIGluIHRoZSBoYW5kc2hha2UsIGFuZCBhIHNlY3VyZSBjbG9jayBvbiB0 aGUgY2xpZW50LCB5b3UgY2FuIGFwcHJveGltYXRlIGEgcHJvb2Ytb2YtcG9zc2Vzc2lvbi4mbmJz cDsgVGhpcyBzZWVtcyBsaWtlIGEgbG90IG9mIHRyb3VibGUgZm9yIGEgZmlyc3QtZmxpZ2h0IENl cnRpZmljYXRlVmVyaWZ5LA0KIGJ1dCBpZiBzb21lb25lIHdhbnRzIHRvIGRvIHRoaXMsIGl0IGNv dWxkIHN0YXkgaW4gdGhlIHNwZWMuJm5ic3A7IElmIENlcnRmaWNhdGVWZXJpZnkgaXMgdG8gcmVt YWluIGluIHRoZSAwLVJUVCBmaXJzdCBmbGlnaHQsIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgd2F5 IHRvIHByb3ZpZGUgYSB0aW1lc3RhbXAgaW4gdGhlIGhhbmRzaGFrZSBoYXNoLiZuYnNwOyBJcyB0 aGVyZSBhIHdheSB0byBkbyB0aGlzIG5vdz8mbmJzcDsgVGhlIFRMUyAxLjIgdGltZXN0YW1wIGlu IHRoZQ0KIGNsaWVudCByYW5kb20gc2VlbXMgdG8gaGF2ZSBiZWVuIHJlbW92ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbGw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BLUPR03MB13968A662C564ACB3C33779E8CD90BLUPR03MB1396namp_-- From nobody Wed Jan 27 11:10:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735491B2FC3 for ; Wed, 27 Jan 2016 11:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSx_mKLTKQIJ for ; Wed, 27 Jan 2016 11:09:58 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7D91B2FBF for ; Wed, 27 Jan 2016 11:09:57 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id n5so43434739wmn.1 for ; Wed, 27 Jan 2016 11:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VetUB5sEOdgj2ngiLczZUiQ8/gpn3jTVAQ31BIpG1iY=; b=KUHVJs3au2W5gc275Nru1KtmUv5bjdtYz+56t1jy8bAgQdJkUkkRMaVOX6HXgrEPqr /rilh4pCnTvd0yFyiNdtvJDmLsQm34ZoNddFE69AxLt2Vana9OSy5iZfD3hJhwwi7Yj1 GOCIJFKyX0jNBKcH6it7oCTuageAnVjkhUHM6O4NwXFHHShWqd2mOd+B/Z+EniSZ7HQA tRgJ1WJ5zXne29G2ph6HPyf/VmI0V+BTDak+t1VVw5m9mOENnfPhX+4yzmkM+Et/ulyN 0Uj1MxR9i1xwnfUpFIBO/RUw6mAUYgycNAEbPD/HuAzYcOx3o3sbijplSA6ydoiiYqK1 vx6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=VetUB5sEOdgj2ngiLczZUiQ8/gpn3jTVAQ31BIpG1iY=; b=E7XWVOrhSVw8D0sWk2AqHy8TW3k1DGweOXY77eD2guiCwzJLaJ8iJ7K72zoMLnyFRX xpsCbVLfHRkLeVHCkxOGYg2g+MaNTy+k5zr6Ml/vmRLODVLUN5cgdjBWYlqTZwthvH5Q +rHp463p8VdU0vNfazdIwz0DkCkAg6/4vNkVlDmdTknK8N3bLJ7GTmTasQwA4/bND6pi 0IRqCNu+xfXFeqfNgh3coMN3921mbZYkPRrkBoWKwSEKtHVOo0TgXFxH3Fwx8fWLIzLZ ZUgylOJFrpYO0RQ+OL4gZOFXrBzyu2FZKYfuID577oCZwuxYh7KTBleX9+BObwCIocP0 N4Qw== X-Gm-Message-State: AG10YOQYmm9uoD3Tggo8BLStxEW2aWpJSp1HoRIjqqYxs7p5jBj/7yo9IlAo3tWc28LONA== X-Received: by 10.28.90.133 with SMTP id o127mr34256305wmb.101.1453921796319; Wed, 27 Jan 2016 11:09:56 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 17sm8964659wmy.15.2016.01.27.11.09.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jan 2016 11:09:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F496EB6F-34EA-4AF9-AFB5-7CBFF0DFC8D9" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Wed, 27 Jan 2016 21:09:53 +0200 Message-Id: References: To: Andrei Popov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 19:09:59 -0000 --Apple-Mail=_F496EB6F-34EA-4AF9-AFB5-7CBFF0DFC8D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Jan 2016, at 8:38 PM, Andrei Popov = wrote: >=20 > =C3=98 The CertificateVerify message is still listed as an option in = the 0-RTT client's first flight at t =3D 0. Is this a mistake? I have = not heard that anyone wants to do this, as there is no possibility of a = traditional proof-of-possession in the first flight. > I agree with this: client auth in 0-RTT is replayable, unless the = server takes extraordinary steps (QUIC-like strike registers, database = of client nonces, etc.) No plans to implement, at least for now. To clarify: by =E2=80=9Cno plans to implement=E2=80=9D, do you mean no = plans to implement 0-RTT, or no plans to implement client authentication = with 0-RTT? Thanks Yoav --Apple-Mail=_F496EB6F-34EA-4AF9-AFB5-7CBFF0DFC8D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 27 Jan 2016, at 8:38 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  The = CertificateVerify message is still listed as an option in the 0-RTT = client's first flight at t =3D 0.  Is this a mistake?  I have = not heard that anyone wants to do this, as there is no possibility of a = traditional proof-of-possession in the first flight.
I = agree with this: client auth in 0-RTT is replayable, unless the server = takes extraordinary steps (QUIC-like strike registers, database of = client nonces, etc.) No plans to implement, at least for now.

To clarify: by =E2=80=9Cno plans to implement=E2=80=9D= , do you mean no plans to implement 0-RTT, or no plans to implement = client authentication with 0-RTT?

Thanks

Yoav


= --Apple-Mail=_F496EB6F-34EA-4AF9-AFB5-7CBFF0DFC8D9-- From nobody Wed Jan 27 11:29:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D01B3025 for ; Wed, 27 Jan 2016 11:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 xPOHXXnG_W7U for ; Wed, 27 Jan 2016 11:28:57 -0800 (PST) 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 659E51B3023 for ; Wed, 27 Jan 2016 11:28:57 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id f81so30330010iof.0 for ; Wed, 27 Jan 2016 11:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=3fSW1Ze2JuhrOU6qVT70tpiq71iM5CAbNC5E+egGKEs=; b=YuUF2KyXe1O6dwgiUeLjoMdORq07udI20YbAPB5lcb9a/zyfbrGj9gyXZXDEBktTIk Vw2M/1UYZZXH0yyKjnzlZDZ8jFDT7iHnGrxn9wcuIjcaDBalSmU5zAwJCBurtjq8CN0c NKmGV+bo72WzZ/ajMZQRlb3YwCFxv5k7DkhgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=3fSW1Ze2JuhrOU6qVT70tpiq71iM5CAbNC5E+egGKEs=; b=fzATMRm9vfLk09jsP55OwzqP4k/6nsIsjGA9O6dax7/u3jGyE6mpPBZUPRsbmEpIli FTEtdlUwtbqIn9ZH7OesO7ilMOxmZtcWqxTUQwdroxSRA4vOOWd7OeVZaNqrsBzLtiuH SqRP405fB8TgVyw3Ykq4ZtWCS71QDngdWYo1Ckz8qvdECsCAnTH+MrzhR6fHaUGEmtVN kwSoUWjzjmZ/LzLD/jrtgHLocpaSLa50ZLkTrIFw2aZ4ckbquuLNHlW1RNfmiWUwxN8V WbOG3y/Xu7KceKXqZy6typjRMc6LI+3hCEGX6dW8dmwMVM0wNV2pYtD5a0A0qCnGLG// KwCQ== X-Gm-Message-State: AG10YOReeLvgFRGaGZ6Ki2mZ33tLvToqQWbiUmBPGlhY1lHxWFldKRtQrVybPaPVotwG/A/zzb2PIiSaFvLXI7Oy X-Received: by 10.107.10.65 with SMTP id u62mr29785131ioi.120.1453922936550; Wed, 27 Jan 2016 11:28:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 27 Jan 2016 19:28:47 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ecd442a41fa052a55d0af Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 19:28:58 -0000 --001a113ecd442a41fa052a55d0af Content-Type: text/plain; charset=UTF-8 On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson wrote: > On 27 January 2016 at 14:11, David Benjamin wrote: > > Why do you say it's an optimization? They're exactly the same except the > > simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a > > combination that's possible with or without my restriction) and the > other is > > a brand new handshake flow to worry about. > > I get your point, but I don't see that as a simplification. In my > mind, post-handshake client authentication doesn't happen. Or, I > don't see it being commonplace. > I certainly hope it doesn't become commonplace either! :-) But the only cases where this flow is useful (server sends non-zero unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5) has all the same pitfalls of mid-stream auth (specifically that the stream's authentication switches partway through), so I don't see what avoiding mid-stream auth is supposed to gain. David --001a113ecd442a41fa052a55d0af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 26= , 2016 at 10:32 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 January 2016 at 14:11, David Benjamin <davidben@chromium.org>= wrote:
> Why do you say it's an optimization? They're exactly the same = except the
> simplified one reduces to normal 0-RTT + mid-stream CertificateRequest= (a
> combination that's possible with or without my restriction) and th= e other is
> a brand new handshake flow to worry about.

I get your point, but I don't see that as a simplification.=C2=A0 In my=
mind, post-handshake client authentication doesn't happen.=C2=A0 Or, I<= br> don't see it being commonplace.

I c= ertainly hope it doesn't become commonplace either! :-)

<= /div>
But the only cases where this flow is useful (server sends non-ze= ro unauthenticated bytes at t=3D0.5 before the authenticated bytes at t=3D1= .5) has all the same pitfalls of mid-stream auth (specifically that the str= eam's authentication switches partway through), so I don't see what= avoiding mid-stream auth is supposed to gain.

Dav= id
--001a113ecd442a41fa052a55d0af-- From nobody Wed Jan 27 11:44:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488281B304E for ; Wed, 27 Jan 2016 11:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpaQWl7tVXPe for ; Wed, 27 Jan 2016 11:44:19 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 18E941B304B for ; Wed, 27 Jan 2016 11:44:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 0BF7E2532; Wed, 27 Jan 2016 21:44:18 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id CJfkseefKLes; Wed, 27 Jan 2016 21:44:17 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C0D57285; Wed, 27 Jan 2016 21:44:17 +0200 (EET) Date: Wed, 27 Jan 2016 21:44:17 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 19:44:21 -0000 On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson > wrote: > > > > I get your point, but I don't see that as a simplification. In my > > mind, post-handshake client authentication doesn't happen. Or, I > > don't see it being commonplace. > > But the only cases where this flow is useful (server sends non-zero > unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5) has > all the same pitfalls of mid-stream auth (specifically that the stream's > authentication switches partway through), so I don't see what avoiding > mid-stream auth is supposed to gain. I don't think the two situations have the same problems: - "Server 0-RTT" has _recipient_ identity change. - "Dynamic reauth" has _sender_ identity change. You have more concrete examples of things going wrong with "server 0-RTT"? Because I have major problems coming up with troublesome cases. -Ilari From nobody Wed Jan 27 12:13:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242871A9087 for ; Wed, 27 Jan 2016 12:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI32AHWFBnl9 for ; Wed, 27 Jan 2016 12:13:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2531A9086 for ; Wed, 27 Jan 2016 12:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0BigIZWgOzHDEpibze7artdW7+cp+kquJDRc7upRzw4=; b=WkJMu8HyLxCceIFYSxt2uMB97sjDEjxEdlB1CFd6KeAV0ZCFSDmiXAVLdHEMAJsgmS0c0OXXYPAw/pLVRQADnCI4L1sfZxFVjajOc7Yx8caFpohqSLWOU1fwnbJEMDUo79h6UmzTpSZoufb+z/8M4m6DxaNaPpTk9OSWRXFRmFk= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 20:13:29 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0390.016; Wed, 27 Jan 2016 20:13:29 +0000 From: Andrei Popov To: Yoav Nir Thread-Topic: [TLS] 0-RTT, server Application Data, and client Finished Thread-Index: AQHRWJwv+0HdYQ8oH0m7Wu7McZFM2Z8Oks2AgAAIdgCAAAO1AIAAEIeAgAAF/gCAALLYAIAASSRggAAJ6YCAABEXEA== Date: Wed, 27 Jan 2016 20:13:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-ms-office365-filtering-correlation-id: a33ca52a-c926-484c-63b5-08d32756524e x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:iNJMmPY5X8aKzZLcvvh+Van7CJKAzMie5fn/DYUgo4nVrYPdRW/MoDT+iNdeC7jwkrN8QsJGHMyeKTiy/wTHzrnUSVOioCpVtNApw3PDkaK/soMH49pwpj0cbRk2CuwyfG9il61fbVHLVDo7HetMKQ==; 24:nEbEZdHTpq7X0jsW3xTQUptfGUL0NWfEpJoveKxmCYpp5NPwvUfPmpMHXTAhvSKwmDCfWU1ftkXEqH3j6rcRV5tzVSrn54xC2NsIMndL/ac= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(24454002)(86362001)(87936001)(19625215002)(3280700002)(5003600100002)(2906002)(74316001)(86612001)(33656002)(40100003)(11100500001)(189998001)(19580395003)(97736004)(92566002)(81156007)(122556002)(19300405004)(8990500004)(10290500002)(10400500002)(5005710100001)(105586002)(99286002)(106116001)(106356001)(19580405001)(93886004)(50986999)(76576001)(19609705001)(54356999)(76176999)(101416001)(5004730100002)(4326007)(5002640100001)(2950100001)(10090500001)(77096005)(586003)(5008740100001)(102836003)(2900100001)(6116002)(790700001)(110136002)(15975445007)(1096002)(16236675004)(1220700001)(3470700001)(5001960100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13967A702492A5582CA3FD768CD90BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 20:13:28.8255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2016 20:13:56 -0000 --_000_BLUPR03MB13967A702492A5582CA3FD768CD90BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gcGxhbnMgdG8gaW1wbGVtZW50IGNsaWVudCBhdXRoIGluIDAtdGggUlRULg0KDQpDaGVlcnMs DQoNCkFuZHJlaQ0KDQpGcm9tOiBZb2F2IE5pciBbbWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb21d DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjcsIDIwMTYgMTE6MTAgQU0NClRvOiBBbmRyZWkg UG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IEJpbGwgQ294IDx3YXl3YXJk Z2Vla0Bnb29nbGUuY29tPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT47IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIDAtUlRULCBzZXJ2ZXIgQXBwbGlj YXRpb24gRGF0YSwgYW5kIGNsaWVudCBGaW5pc2hlZA0KDQoNCk9uIDI3IEphbiAyMDE2LCBhdCA4 OjM4IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQo+ICBUaGUgQ2VydGlmaWNhdGVW ZXJpZnkgbWVzc2FnZSBpcyBzdGlsbCBsaXN0ZWQgYXMgYW4gb3B0aW9uIGluIHRoZSAwLVJUVCBj bGllbnQncyBmaXJzdCBmbGlnaHQgYXQgdCA9IDAuICBJcyB0aGlzIGEgbWlzdGFrZT8gIEkgaGF2 ZSBub3QgaGVhcmQgdGhhdCBhbnlvbmUgd2FudHMgdG8gZG8gdGhpcywgYXMgdGhlcmUgaXMgbm8g cG9zc2liaWxpdHkgb2YgYSB0cmFkaXRpb25hbCBwcm9vZi1vZi1wb3NzZXNzaW9uIGluIHRoZSBm aXJzdCBmbGlnaHQuDQpJIGFncmVlIHdpdGggdGhpczogY2xpZW50IGF1dGggaW4gMC1SVFQgaXMg cmVwbGF5YWJsZSwgdW5sZXNzIHRoZSBzZXJ2ZXIgdGFrZXMgZXh0cmFvcmRpbmFyeSBzdGVwcyAo UVVJQy1saWtlIHN0cmlrZSByZWdpc3RlcnMsIGRhdGFiYXNlIG9mIGNsaWVudCBub25jZXMsIGV0 Yy4pIE5vIHBsYW5zIHRvIGltcGxlbWVudCwgYXQgbGVhc3QgZm9yIG5vdy4NCg0KVG8gY2xhcmlm eTogYnkg4oCcbm8gcGxhbnMgdG8gaW1wbGVtZW504oCdLCBkbyB5b3UgbWVhbiBubyBwbGFucyB0 byBpbXBsZW1lbnQgMC1SVFQsIG9yIG5vIHBsYW5zIHRvIGltcGxlbWVudCBjbGllbnQgYXV0aGVu dGljYXRpb24gd2l0aCAwLVJUVD8NCg0KVGhhbmtzDQoNCllvYXYNCg0KDQo= --_000_BLUPR03MB13967A702492A5582CA3FD768CD90BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ObyBwbGFucyB0byBp bXBsZW1lbnQgY2xpZW50IGF1dGggaW4gMC10aCBSVFQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFlvYXYgTmlyIFttYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjcsIDIwMTYgMTE6MTAgQU08YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSZndDs7IE1hcnRp biBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyB0bHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIDAtUlRULCBzZXJ2ZXIgQXBwbGljYXRpb24g RGF0YSwgYW5kIGNsaWVudCBGaW5pc2hlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI3IEphbiAyMDE2LCBhdCA4OjM4IFBNLCBBbmRyZWkgUG9w b3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlRoZSBDZXJ0aWZpY2F0ZVZlcmlmeSBtZXNz YWdlIGlzIHN0aWxsDQogbGlzdGVkIGFzIGFuIG9wdGlvbiBpbiB0aGUgMC1SVFQgY2xpZW50J3Mg Zmlyc3QgZmxpZ2h0IGF0IHQgPSAwLiZuYnNwOyBJcyB0aGlzIGEgbWlzdGFrZT8mbmJzcDsgSSBo YXZlIG5vdCBoZWFyZCB0aGF0IGFueW9uZSB3YW50cyB0byBkbyB0aGlzLCBhcyB0aGVyZSBpcyBu byBwb3NzaWJpbGl0eSBvZiBhIHRyYWRpdGlvbmFsIHByb29mLW9mLXBvc3Nlc3Npb24gaW4gdGhl IGZpcnN0IGZsaWdodC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggdGhp czogY2xpZW50IGF1dGggaW4gMC1SVFQgaXMgcmVwbGF5YWJsZSwgdW5sZXNzIHRoZSBzZXJ2ZXIg dGFrZXMgZXh0cmFvcmRpbmFyeSBzdGVwcyAoUVVJQy1saWtlIHN0cmlrZSByZWdpc3RlcnMsIGRh dGFiYXNlIG9mIGNsaWVudCBub25jZXMsIGV0Yy4pDQogTm8gcGxhbnMgdG8gaW1wbGVtZW50LCBh dCBsZWFzdCBmb3Igbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGNsYXJpZnk6IGJ5IOKAnG5v IHBsYW5zIHRvIGltcGxlbWVudOKAnSwgZG8geW91IG1lYW4gbm8gcGxhbnMgdG8gaW1wbGVtZW50 IDAtUlRULCBvciBubyBwbGFucyB0byBpbXBsZW1lbnQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHdp dGggMC1SVFQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB13967A702492A5582CA3FD768CD90BLUPR03MB1396namp_-- From nobody Thu Jan 28 09:36:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8081A8BBD for ; Thu, 28 Jan 2016 09:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 zkKY0zWHoVUZ for ; Thu, 28 Jan 2016 09:36:33 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DDE1A8BB7 for ; Thu, 28 Jan 2016 09:36:32 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id z14so18609653igp.0 for ; Thu, 28 Jan 2016 09:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=vz3kGQuGevCq5IHE9PIac6DSp+357vX2FLHQ0rlnbAU=; b=EnlEk2gZVGfBbjiGfOeKuPzg3yk8Hb0XKU3Rtl0PcOXTd+Gy3NZa5hzLTFVnS5EZA5 CcEvh76COhoBb9gfYH1bEDqIQrSEvDMbP2nsEzenIxBnsZFvyMGIwM9nPHXRvOROg5E3 C335+e7T9Hselu/Roq+5/G73zV4N2LN7hgpTE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=vz3kGQuGevCq5IHE9PIac6DSp+357vX2FLHQ0rlnbAU=; b=HyQzYDBcQmc4wOXnAKxHRV+nl9WvJmOHpyjsu3eoEfQslIVOAgE8PV1jy9h7kc4NY0 OYTeqE3kbzxioyGCedyebRmu8CLk5dRXjy7LuohWBP/TmHBtbcqTre+tpifUMWEE1OPh k0XnfyZ3Nn41I+tyqHZF9T2totRNUwBksae3uye4lpvGjuUNSOSGRCG7ckJ/MqTLN5q8 qcjhj28ab6IoV5+vxJEpPREwXekLHam54GWg8f/eyuh5z/J+w7Od+EfiOwKbVJGIsZ7H X3yDCuRzLYxYjdd9TTuSoO/4v0OBKoyhGv16VTDFpme9SJfmAcpvkmvjcSoj6s6h9Myb PNaQ== X-Gm-Message-State: AG10YOSybcR2rF+TtFgfx7zJhowt0lpyFEEamL3slrR7JJck1OMdq0+1jqwHKheT7q0cnt4zzR0had3mhVUokfJs X-Received: by 10.50.13.102 with SMTP id g6mr4951385igc.77.1454002592177; Thu, 28 Jan 2016 09:36:32 -0800 (PST) MIME-Version: 1.0 References: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Thu, 28 Jan 2016 17:36:22 +0000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e013c66d602b051052a685ca9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2016 17:36:34 -0000 --089e013c66d602b051052a685ca9 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara wrote: > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > martin.thomson@gmail.com> > > wrote: > > > > > > I get your point, but I don't see that as a simplification. In my > > > mind, post-handshake client authentication doesn't happen. Or, I > > > don't see it being commonplace. > > > > But the only cases where this flow is useful (server sends non-zero > > unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5) > has > > all the same pitfalls of mid-stream auth (specifically that the stream's > > authentication switches partway through), so I don't see what avoiding > > mid-stream auth is supposed to gain. > > I don't think the two situations have the same problems: > - "Server 0-RTT" has _recipient_ identity change. > - "Dynamic reauth" has _sender_ identity change. > > You have more concrete examples of things going wrong with "server > 0-RTT"? Because I have major problems coming up with troublesome > cases. The client also has some 0-RTT data which, in the server 0-RTT case, the server reports was accepted and processed. That all is associated with the first identity rather than the second. So I believe we have sender identity change in both cases. David --089e013c66d602b051052a685ca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 27= , 2016 at 2:44 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrot= e:
> On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <martin.thomson@gmail.com>= ;
> wrote:
> >
> > I get your point, but I don't see that as a simplification.= =C2=A0 In my
> > mind, post-handshake client authentication doesn't happen.=C2= =A0 Or, I
> > don't see it being commonplace.
>
> But the only cases where this flow is useful (server sends non-zero > unauthenticated bytes at t=3D0.5 before the authenticated bytes at t= =3D1.5) has
> all the same pitfalls of mid-stream auth (specifically that the stream= 's
> authentication switches partway through), so I don't see what avoi= ding
> mid-stream auth is supposed to gain.

I don't think the two situations have the same problems:
- "Server 0-RTT" has _recipient_ identity change.
- "Dynamic reauth" has _sender_ identity change.

You have more concrete examples of things going wrong with "server
0-RTT"? Because I have major problems coming up with troublesome
cases.

The client also has some 0-RTT data = which, in the server 0-RTT case, the server reports was accepted and proces= sed. That all is associated with the first identity rather than the second.= So I believe we have sender identity change in both cases.

<= /div>
David
--089e013c66d602b051052a685ca9-- From nobody Thu Jan 28 11:09:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1BD1B2F88 for ; Thu, 28 Jan 2016 11:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5C5ebK5Ly-j for ; Thu, 28 Jan 2016 11:09:13 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DCF861B2F87 for ; Thu, 28 Jan 2016 11:09:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1C398597; Thu, 28 Jan 2016 21:09:11 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id aGAWbuA6-CM3; Thu, 28 Jan 2016 21:09:10 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BB7B3285; Thu, 28 Jan 2016 21:09:10 +0200 (EET) Date: Thu, 28 Jan 2016 21:09:09 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160128190909.GA11429@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jan 2016 19:09:15 -0000 On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote: > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara > wrote: > > > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > > martin.thomson@gmail.com> > > > > I don't think the two situations have the same problems: > > - "Server 0-RTT" has _recipient_ identity change. > > - "Dynamic reauth" has _sender_ identity change. > > > > You have more concrete examples of things going wrong with "server > > 0-RTT"? Because I have major problems coming up with troublesome > > cases. > > > The client also has some 0-RTT data which, in the server 0-RTT case, the > server reports was accepted and processed. That all is associated with the > first identity rather than the second. So I believe we have sender identity > change in both cases. The 0-RTT being sent under different identity than the application data does involve sending identity change, but what does it have to do with "server 0-RTT"? The client could do that (and run into trouble with badly designed protocols) without "server 0-RTT". -Ilari From nobody Fri Jan 29 11:56:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DDA1B32AB for ; Fri, 29 Jan 2016 11:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 vjgdLmmc7Rua for ; Fri, 29 Jan 2016 11:56:04 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC341B32AA for ; Fri, 29 Jan 2016 11:56:04 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g73so101479121ioe.3 for ; Fri, 29 Jan 2016 11:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=UWqi2ZWA4iQo7MaL8XuR0vD36q6sW92DGu6hC4Ff3m0=; b=lv/apkjC3UWE87HyQw48DMTtkMa9sXUJy0JVhFJxL/IwZMbjf2hnTYZj4t0f6S7Xn3 ZNBRQn3P0KCmSP1UfcDjKw3rPFkZrRHToOE9h07HlWK5kpkLKb+vP6DQQ/NGOhVIwjoV MhFArNDiEdAudGJ6y/7UDcxBd6FN2X9Eo34P0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=UWqi2ZWA4iQo7MaL8XuR0vD36q6sW92DGu6hC4Ff3m0=; b=iy4AEOMrVM2ryNm7WFjPQd3KjI69mnKchMJe53aHWFMbuMcLhIVxpPGIc31+nSQMZs yN+ZSyd4zdz7lfadFqb0HtHPUDHWE98cxmL2pZVKbL3b0XvSPPTCAGsWPTVXMnNzF391 qsbewoeJqjfOudsvNREWuoTHMLZgvIR0MRCGzwwN/SX+qZa00GtAIYa9V5BE8mjTDNKH 2dGjIxm8isu0kjvWWOKoice8KgKp5Y104hskb+TLsCLIg69EIM0CqQz0/loDI92J+w9Z mRuUUV+a+omIhqFl9/810UJF0jUhPZE34oEA0ipfFx0wfvCIdCRk+DpafIklmfcTA2K9 aiNg== X-Gm-Message-State: AG10YOTRqMpZHy4sCGdBc2jLG6NEaRr2qd+IUJZccDgXna60fWKNsIlTTbIEwxnDKwWsx8W7vuBh4Tqxo0AFNBlK X-Received: by 10.107.136.200 with SMTP id s69mr602338ioi.120.1454097363629; Fri, 29 Jan 2016 11:56:03 -0800 (PST) MIME-Version: 1.0 References: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> <20160128190909.GA11429@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160128190909.GA11429@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Fri, 29 Jan 2016 19:55:53 +0000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113eccdad4347d052a7e6ce8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 19:56:06 -0000 --001a113eccdad4347d052a7e6ce8 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara wrote: > On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote: > > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > > > martin.thomson@gmail.com> > > > > > > I don't think the two situations have the same problems: > > > - "Server 0-RTT" has _recipient_ identity change. > > > - "Dynamic reauth" has _sender_ identity change. > > > > > > You have more concrete examples of things going wrong with "server > > > 0-RTT"? Because I have major problems coming up with troublesome > > > cases. > > > > > > The client also has some 0-RTT data which, in the server 0-RTT case, the > > server reports was accepted and processed. That all is associated with > the > > first identity rather than the second. So I believe we have sender > identity > > change in both cases. > > The 0-RTT being sent under different identity than the application data > does involve sending identity change, but what does it have to do with > "server 0-RTT"? The client could do that (and run into trouble with > badly designed protocols) without "server 0-RTT". > Perhaps I misunderstood you. I read "dynamic reauth" in your message above as the post-handshake auth mechanism. You said that "server 0-RTT" has recipient identity change and "dynamic reauth" has sender identity change. My claim is that "server 0-RTT" also has sender identity change, since that seemed to be the question you were asking. Did you mean something else? Yes, by forbidding CertificateRequest on 0-RTT hit, we are not removing anything post-handshake auth can't do. That's largely my point. It is identical in both how it works in good or bad) and how early each message arrives (see https://www.ietf.org/mail-archive/web/tls/current/msg19159.html for comparison). I hope the more reasonable protocols without legacy burdens will declare that post-handshake auth is forbidden and only allow initial-handshake client auth or none at all, as SPDY and HTTP/2[*] did to renego in TLS 1.2. Yet it's not obvious CertificateRequest on a 0-RTT hit is equivalent to post-handshake auth and should be allowed or forbidden together. Also, although servers can choose never to do this, clients that implement post-handshake auth (like HTTP apparently) can't. This figures into the client API the TLS stack exposes. Despite being in the handshake, this flow should be exposed via post-handshake auth's API. This is weird, but handshake-negotiated properties otherwise have nice assumptions like being constant throughout the connection, should the client's stream depend on it. Consider ALPN. If a server wishes to pick a different ALPN value from the 0-RTT-predicted one, it must reject 0-RTT because that data's wrong anyway. I think the same should be true of in-handshake client auth. Since there is zero benefit to a using this handshake flow over already existing alternative (this handshake flow is not an optimization), I don't see how it can be worth this (or any) complexity. David [*] Sadly, HTTP's legacy burdens caught up to us. Although I see draft-thomson-http2-client-certs-01 has picked up again, so maybe HTTP/2 won't use post-handshake auth? Doesn't matter; new multiplexed protocol without such legacy would best forbid post-handshake auth. --001a113eccdad4347d052a7e6ce8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 28= , 2016 at 2:09 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrot= e:
> On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>
> > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> > mar= tin.thomson@gmail.com>
> >
> > I don't think the two situations have the same problems:
> > - "Server 0-RTT" has _recipient_ identity change.
> > - "Dynamic reauth" has _sender_ identity change.
> >
> > You have more concrete examples of things going wrong with "= server
> > 0-RTT"? Because I have major problems coming up with trouble= some
> > cases.
>
>
> The client also has some 0-RTT data which, in the server 0-RTT case, t= he
> server reports was accepted and processed. That all is associated with= the
> first identity rather than the second. So I believe we have sender ide= ntity
> change in both cases.

The 0-RTT being sent under different identity than the application data
does involve sending identity change, but what does it have to do with
"server 0-RTT"? The client could do that (and run into trouble wi= th
badly designed protocols) without "server 0-RTT".

Perhaps I misunderstood you. I read "dynamic reau= th" in your message above as the post-handshake auth mechanism. You sa= id that "server 0-RTT" has recipient identity change and "dy= namic reauth" has sender identity change. My claim is that "serve= r 0-RTT" also has sender identity change, since that seemed to be the = question you were asking. Did you mean something else?

=
Yes, by forbidding CertificateRequest on 0-RTT hit, we are not removin= g anything post-handshake auth can't do. That's largely my point. I= t is identical in both how it works in good or bad) and how early each mess= age arrives (see=C2=A0https://www.ietf.org/mail-archive/web/tls/current/ms= g19159.html=C2=A0for comparison).

I hope the m= ore reasonable protocols without legacy burdens will declare that post-hand= shake auth is forbidden and only allow initial-handshake client auth or non= e at all, as SPDY and HTTP/2[*] did to renego in TLS 1.2. Yet it's not = obvious CertificateRequest on a 0-RTT hit is equivalent to post-handshake a= uth and should be allowed or forbidden together.

A= lso, although servers can choose never to do this, clients that implement p= ost-handshake auth (like HTTP apparently) can't. This figures into the = client API the TLS stack exposes. Despite being in the handshake, this flow= should be exposed via post-handshake auth's API. This is weird, but ha= ndshake-negotiated properties otherwise have nice assumptions like being co= nstant throughout the connection, should the client's stream depend on = it. Consider ALPN. If a server wishes to pick a different ALPN value from t= he 0-RTT-predicted one, it must reject 0-RTT because that data's wrong = anyway. I think the same should be true of in-handshake client auth.
<= div>
Since there is zero benefit to a using this handshake fl= ow over already existing alternative (this handshake flow is not an optimiz= ation), I don't see how it can be worth this (or any) complexity.
=

David

[*] Sadly, HTTP's legacy burden= s caught up to us. Although I see draft-thomson-http2-client-certs-01 has p= icked up again, so maybe HTTP/2 won't use post-handshake auth? Doesn= 9;t matter; new multiplexed protocol without such legacy would best forbid = post-handshake auth.
--001a113eccdad4347d052a7e6ce8-- From nobody Fri Jan 29 12:53:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2181B339B for ; Fri, 29 Jan 2016 12:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlBQQCiaQJKU for ; Fri, 29 Jan 2016 12:53:00 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A738F1B33B8 for ; Fri, 29 Jan 2016 12:52:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id C664B5AD; Fri, 29 Jan 2016 22:52:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 9HyRZzKkbViT; Fri, 29 Jan 2016 22:52:57 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1815B230D; Fri, 29 Jan 2016 22:52:57 +0200 (EET) Date: Fri, 29 Jan 2016 22:52:55 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160129205255.GA20364@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160127194416.GA10603@LK-Perkele-V2.elisa-laajakaista.fi> <20160128190909.GA11429@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Jan 2016 20:53:02 -0000 On Fri, Jan 29, 2016 at 07:55:53PM +0000, David Benjamin wrote: > On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara > wrote: > > Perhaps I misunderstood you. I read "dynamic reauth" in your message above > as the post-handshake auth mechanism. You said that "server 0-RTT" has > recipient identity change and "dynamic reauth" has sender identity change. > My claim is that "server 0-RTT" also has sender identity change, since that > seemed to be the question you were asking. Did you mean something else? No, it doesn't: The server auth block comes before the data sent, and this block authenticates the sender (which is the server). > Yes, by forbidding CertificateRequest on 0-RTT hit, we are not removing > anything post-handshake auth can't do. That's largely my point. It is > identical in both how it works in good or bad) and how early each message > arrives (see https://www.ietf.org/mail-archive/web/tls/current/msg19159.html > for comparison). Also, there are some subtle attacks on TLS that only fail on client Finished, so client auth block is needed. > I hope the more reasonable protocols without legacy burdens will declare > that post-handshake auth is forbidden and only allow initial-handshake > client auth or none at all, as SPDY and HTTP/2[*] did to renego in TLS 1.2. > Yet it's not obvious CertificateRequest on a 0-RTT hit is equivalent to > post-handshake auth and should be allowed or forbidden together. That actually also depends on what kind of data is sent in 0-RTT. Some protocols might be unsafe in general case, but have restricted subset that is safe in 0-RTT. E.g. protocol banners (e.g. HTTP/2 prelude/SETTINGS) are in general safe. HTTP/2 also has other stuff that could be sent (e.g. preflights or any requests with user privilege). Or protocol could say that anything in 0-RTT is permanently locked to authority it was sent with (including possibly anonymous authority). IIRC, 0-RTT data is explicitly distinct from normal data. > Also, although servers can choose never to do this, clients that implement > post-handshake auth (like HTTP apparently) can't. This figures into the > client API the TLS stack exposes. Despite being in the handshake, this flow > should be exposed via post-handshake auth's API. This is weird, but > handshake-negotiated properties otherwise have nice assumptions like being > constant throughout the connection, should the client's stream depend on > it. Consider ALPN. If a server wishes to pick a different ALPN value from > the 0-RTT-predicted one, it must reject 0-RTT because that data's wrong > anyway. I think the same should be true of in-handshake client auth. IIRC, there is no indication of assumed ALPN for 0-RTT... Also, 0-RTT data is also separate on client side. So in-handshake 1RTT auth is quite different for client than post-handshake auth. Also, I think there should be a way for client to request Certificate- Request, even without valid configuration. This is needed for M2M applications (and some interactive protocols as well). > [*] Sadly, HTTP's legacy burdens caught up to us. Although I see > draft-thomson-http2-client-certs-01 has picked up again, so maybe HTTP/2 > won't use post-handshake auth? Doesn't matter; new multiplexed protocol > without such legacy would best forbid post-handshake auth. Well, considering that they have no choice with TLS 1.2, I presume they will also go that way with TLS 1.3. -Ilari From nobody Sun Jan 31 21:56:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7E01ACDBF for ; Sun, 31 Jan 2016 21:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWIhf94RaY_7 for ; Sun, 31 Jan 2016 21:56:16 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 93B091ACDBB for ; Sun, 31 Jan 2016 21:56:16 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9E48710224056; Sun, 31 Jan 2016 21:56:15 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 31 Jan 2016 21:56:16 -0800 (PST) Message-ID: In-Reply-To: References: <20160127151803.17788998.50067.47728@ll.mit.edu> Date: Sun, 31 Jan 2016 21:56:16 -0800 (PST) From: "Dan Harkins" To: "Martin Thomson" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Feb 2016 05:56:18 -0000 On Wed, January 27, 2016 9:47 am, Martin Thomson wrote: > On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL > wrote: >> Anon ‎!= Ephemeral, despite some similarities. > >>From a protocol perspective, they are the same. The distinction at > the protocol level between ECDH_RSA (for example) and ECDH_anon is > that ECDH_anon requires a ServerKeyShare message in the same way that > ECDHE_RSA does. So? A static-static, static-ephemeral, and ephemeral-ephemeral all look the same from a protocol perspective too but they are very different and have very different properties. Dan. > I agree that Nikos' point is a good one, but we've implementations of > ECDHE_ that provide a stable value for their ephemeral key > (unfortunately, that's the default mode in NSS). > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Jan 31 22:00:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A121ACDD1 for ; Sun, 31 Jan 2016 22:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AN1li6cLdak for ; Sun, 31 Jan 2016 22:00:52 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA921ACDD0 for ; Sun, 31 Jan 2016 22:00:52 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id f81so145473514iof.0 for ; Sun, 31 Jan 2016 22:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Io1CriKIRogvdMbGsfpOtPsLBFkOiFkqOKJ3ZCwGoos=; b=dXv1tNjv0PNhQwW/oSGgeIn9nyLzsAj10aoIYF1GAi4X61YnilaeX0VXsmP2wYyLqj cL/vMKgkNtFgGCAUJcSpvihKFeL3YwuNqh2fiOdkS+lGbqYaEvj1fxTcswkRNipGetCz 0nqrZfk831WqM2AwkHAnxRU3U/zpqSA+pIhkflcnbhU4BbcUi4p/xZLBfZexAJsQ7QzX 26BmSXyy1TiVoFYQRpBXRw/gUJzU807ERl3nRk5AQK4ywgdkEfBVYHfbnAa0OxqFh8Cn FTcg0EBaESFp5fhr5TAO0zcKseGUhbRpjFGfNwIfAt2Um6kGvya3I0hjj/5b1Xl2cZV0 l4Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Io1CriKIRogvdMbGsfpOtPsLBFkOiFkqOKJ3ZCwGoos=; b=RhkDb2aXK/gjJgXWbP5pkVLw1e+1CmKj3bIB1FBzF3/WOrbQKqH2kHqmPbW0PzXkda oGy/7+53KYz00SWIhmnnnvbBDs7JzqA07Fb7rvwCiMMJw0IM33NUmUYljYpEH6BHzD64 qLfdcKbOswZUfagN8CQEEYlX0y/I6S8JtVl/W1QaoKQsBBQPImAK1f8rndyW0UP4ghzz 0x9T4qlHGMcYs01vkuOIe35mFZP/qTkbTrFOADOacEykeXs3MShZQGQOFhMdmpEGUjv8 X+dyNDggxrNWQfFkG8fhjahqW4G1ySUBPtxFDrPWAJgXnviOntIOYtnuQr9kYAEQtUUb KXXw== X-Gm-Message-State: AG10YOSunHTiAQdxhJHMGubSZSRxmEKAtDg3JNZoM130bct+EigvZ5pjgwD5ngmxNGWMIAVNp+ERzxPg9WZGqg== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr4040522ioq.100.1454306452115; Sun, 31 Jan 2016 22:00:52 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 31 Jan 2016 22:00:52 -0800 (PST) In-Reply-To: References: <20160127151803.17788998.50067.47728@ll.mit.edu> Date: Mon, 1 Feb 2016 17:00:52 +1100 Message-ID: From: Martin Thomson To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Feb 2016 06:00:54 -0000 On 1 February 2016 at 16:56, Dan Harkins wrote: >>>From a protocol perspective, they are the same. The distinction at >> the protocol level between ECDH_RSA (for example) and ECDH_anon is >> that ECDH_anon requires a ServerKeyShare message in the same way that >> ECDHE_RSA does. > > So? A static-static, static-ephemeral, and ephemeral-ephemeral > all look the same from a protocol perspective too but they are > very different and have very different properties. If a tree falls in the forest and no one deletes the private key, is it static or ephemeral.