From nobody Fri Jul 1 04:49:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BD12B05A for ; Fri, 1 Jul 2016 04:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvlsPFjD8BJe for ; Fri, 1 Jul 2016 04:49:35 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD0812B029 for ; Fri, 1 Jul 2016 04:49:32 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id s63so97908176ioi.3 for ; Fri, 01 Jul 2016 04:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=HszI4laKJVvJs63se0jJti/p6JXWU2nC/TZ7PtXz6dA=; b=NU4B8QelXwebhqj+dk77ktdSUnuPEB4c9fsDqY8oaPHCTuvYLdMTjbWr4iTtmIaZ+1 0W6UNbPRMlRXTCxQ5jlc9PbyBDysjjEzaUVbn8d3Bh/sYc2wnxb/zfChpinL37NENWra praeqErahpwQurV0BM5n0qtwipYa85X3GeaYrUglgWheYXmhg4FmzaPNmge+6LAxg2TZ XjByE1L4I2IACUukG0fjzstCUIQ06nCSxoyc2iAAzEM+UMSvjeEQOQm6M1FvpxOXTTqZ WjSd56wqFGHytsWrjhp/s8HPLiB8AKztADAHlW2JE4hlCISSedQFzybLu51tVansklNw TAfA== 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; bh=HszI4laKJVvJs63se0jJti/p6JXWU2nC/TZ7PtXz6dA=; b=lDmzGq/bJmpHKowLKeRNiknXmGULeBV0qZdzE0cHcPntcbDsKJL5Q1B00xfT9V2SCf rIuO9SdOAwkqKbliniAtAYm+RlgjjWXIpFwpMQBjXsKotOpOp/YxGa93dS2rnqZnQVZF TUfWQTmEiC2UrQntPGu53XmOv1nUcZQxaNrrtrgUjo7rhpLal9zs4hflQK1XcMKA0hdk 6SojHeR4aLdwtHQcB+WcrA6jBsPRsiysfJJEA5vZ9N9mrOuxhe0XWoxw7lW6ctOdnBAN 3dIh5BBQ4PWuzz1Ws5WqAUWHMEXRhwkom5H52wf0QiloaCe32y3z4Aax0mYmCzY2qOz5 B3ng== X-Gm-Message-State: ALyK8tJ4XVEkNvkfzZklbb+rv2LPwPdAzidF/DElMBq8UjFbK+CkmBd468JSrG0OM8Jrmo9SxUtPkqR0qxvARQ== X-Received: by 10.107.188.131 with SMTP id m125mr20985539iof.1.1467373772015; Fri, 01 Jul 2016 04:49:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.116.142 with HTTP; Fri, 1 Jul 2016 04:49:31 -0700 (PDT) From: Debapriyay Mukhopadhyay Date: Fri, 1 Jul 2016 17:19:31 +0530 Message-ID: To: TLS@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07724a6f0e020536919480 Archived-At: Subject: [TLS] How to offload modular exponentiation to Octeon II Crypto Coprocessor X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:49:37 -0000 --94eb2c07724a6f0e020536919480 Content-Type: text/plain; charset=UTF-8 Hi, First of all, I beg apology if my post is not suitable for this group. Is it possible to offload modular exponentiation required in RSA and Diffie-Hellman to Hardware (Crypto Co-processor) that comes with Octeon II platform. In some document, I have seen that Octeon II platform do support that. But, I am not getting how to do that. What macros to be used etc? Can anyone please provide me with some pointer that would be really helpful. Thanks. Regards Debapriyay Mukhopadhyay --94eb2c07724a6f0e020536919480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0 =C2=A0First of all, I beg apology if my pos= t is not suitable for this group.

=C2=A0 =C2=A0Is it possible to offload modula= r exponentiation required in RSA and Diffie-Hellman to =C2=A0 =C2=A0 =C2=A0= =C2=A0 Hardware (Crypto Co-processor) that comes with Octeon II platform.<= /span>

=C2=A0 In some document, I have seen that = Octeon II platform do support that. But, I am not getting how to do that. W= hat macros to be used etc?

Can anyone please provid= e me with some pointer that would be really helpful.

Regards

De= bapriyay Mukhopadhyay

--94eb2c07724a6f0e020536919480-- From nobody Sun Jul 3 16:02:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D612B04A for ; Sun, 3 Jul 2016 16:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efzePH-6GXB3 for ; Sun, 3 Jul 2016 16:02:45 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B52C12B025 for ; Sun, 3 Jul 2016 16:02:45 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v77so28069506ywg.0 for ; Sun, 03 Jul 2016 16:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GirZi/2IVgBxG4vezChAWEOhxTxOynQS7tDh1HgWE3A=; b=ipY1mvRq91PHZMf+05RvVYDGivm55OMAEpyAJo8ZbZcb9H0E+tvDj5ndcjCNixrsEp 5F8A9YDLBp0Qroloe1EFyz9SFantkpQ8p6xMZZQz+2aXYJwgUy23dS1NBOYtYF3R3R2y MBACXX2zexzWisoL/SYvP2Pt2S4RF+zXBEiWilLMVHLq2FZowv/mrqtlR0n2AZbgB5Wc EVA6ZYSslknEeGUUICHbkfSmQoyFUX3h7bC6agxpj7Gyiczk6XDHPYuEUvhZfbOI1di/ xYHwIetphtbcq/2IclQJGINApY1nJTJD8H9rSppBkJFqsKnwdti9pqkkT7E2doCdUcsY KS6A== 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; bh=GirZi/2IVgBxG4vezChAWEOhxTxOynQS7tDh1HgWE3A=; b=hqsRZlr3l6fISh90fi8Dnzh+Vx5sUgdUezmS27GMu9qeXV/CQjtJUHo2bdsepj5vLK XLwlADQN+jT7fz5FDoPI7jTgK5bQlQWj311R+R3ih7NNR/cvZd8tDrPLO176MVAZIWXU MNQCExAxNGRmO0kQpDGiZ/dCLthahbhwlNQHHD2LbdboCK8N0p+GNAsiglOcxO8+k9EN WnxEakv5Cxd8lb/adlJvc3a49/rjPhSanXn/R3zodlW26qP1Ywe+imrY0Nugi7GFFFHJ fo+tf6L/61a59iwyYk3X1PJ6SV/LSjcWn2omvUD5y+L8kM7RfUL60rAGmP7ZlYXkrKhr WmXg== X-Gm-Message-State: ALyK8tL59viGO2yVc/hukyeCNf1j348Fk66sozyZ7JfPAC1+7ChWRsCICRik8msDgTOgSpBMzuSGRuyp9ZnmLg== X-Received: by 10.129.83.3 with SMTP id h3mr5102147ywb.276.1467586964704; Sun, 03 Jul 2016 16:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Sun, 3 Jul 2016 16:02:05 -0700 (PDT) From: Eric Rescorla Date: Sun, 3 Jul 2016 16:02:05 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d7484b580f50536c337c4 Archived-At: Subject: [TLS] PR 508: Move downgrade sentinel to end X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2016 23:02:47 -0000 --001a114d7484b580f50536c337c4 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/508 David Benjamin has suggested moving the downgrade sentinel to the end of the server random to avoid breaking tlsdate. This seems reasonable, as the only real argument against is that conformant TLS 1.3 servers will have only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in the top 32 bytes), as opposed to 24 if they randomize the first 32 bytes. OTOH, those bytes will be more unique over time (because they are guaranteed not to repeat for a very long time after the second has passed), so intuitively this seems like a wash. Barring any objections I'll merge this PR on Wednesday -Ekr --001a114d7484b580f50536c337c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/508

David Be= njamin has suggested moving the downgrade sentinel to the end of the server= random to avoid breaking tlsdate. This seems reasonable, as the only real = argument against is that conformant TLS 1.3 servers will have only 20 bytes= of entropy when doing TLS 1.2 compat (if they put the time in the top 32 b= ytes), as opposed to 24 if they randomize the first 32 bytes. OTOH, those b= ytes will be more unique over time (because they are guaranteed not to repe= at for a very long time after the second has passed), so intuitively this s= eems like a wash.

Barring any objections I'll = merge this PR on Wednesday

-Ekr




--001a114d7484b580f50536c337c4-- From nobody Sun Jul 3 17:52:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A982712D1A2 for ; Sun, 3 Jul 2016 17:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVgDbUldrePm for ; Sun, 3 Jul 2016 17:52:02 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348BF12B062 for ; Sun, 3 Jul 2016 17:52:02 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id b72so29163441ywa.3 for ; Sun, 03 Jul 2016 17:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUdfyiuT/fbZdUeZMcG5h8WQasIBBcxdFd9zqP1lhMo=; b=fAPMZ/dMepL2Qk2Vzfvt1TviR8gbtPp0P8ZhIE9YLDMs+OsGMkzXkzsRtaXq8FhuRf IHbH/p+P6Go1v6bZxh2SzJJqrEnFbwSXKdi0M+tfOk3ZGcVdlmPoyUuBxCcsQmlMa6et ys1pr0BMpbPjQN76CAUvaSnJ/hWl8QiGjn1tMvug4lbnVBBuwQIyXx1VfN1tKXLS8cNM 89ObvtWnsemVEg1x7xirmrz+2cZCpaAhDFziE1tAEjKXH9euylGgF6I4keH+qZ3GdKeU Ebu4WisVsdNzToxFNQ1V9/5ZlB2xqAvA9OOLG/uQ3ClXXlNha29zTh87YYE8UoEgnJgQ OAJQ== 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; bh=VUdfyiuT/fbZdUeZMcG5h8WQasIBBcxdFd9zqP1lhMo=; b=UyKdLyTp4GDzhyqZ5eYRsLoMYGCfl+oYKQDLR3wM6WyDpW4R7eqq44Fbf5HX7o9UaB 1ZnvhoN2U7Gxv6JYo9gvLe8rn8PoSdDusYWjG4nyY8KYQYVXBdK222+0PA2uGuZD9ttQ EhK84tY4VDNXJ1PPFgKvyz8UPH1opkMwLk1BU99G6cuXBde3Rza0wubBITylKnWXhcPy XAhJ26GUjtaTIP+YVw/Q8VuDthsnO7FReiwjqJYcDnfXv2yoK/VGwkfjZlbc9MZPOlgL sGvFFse4K4mOQYImQzQZUxoIbVrzDaR9dpEVbxpn7i85YD6wAesLc0s+LgTqNQf722B1 fC+A== X-Gm-Message-State: ALyK8tKKB+JpKXAxVixUvbbqEdYhbQT20JmaHkzOKn3CTbhpEWx4MoEqWA+kkrNb69K6h4nDLynLh6LlydLgiw== X-Received: by 10.37.3.202 with SMTP id 193mr5554340ybd.130.1467593521388; Sun, 03 Jul 2016 17:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Sun, 3 Jul 2016 17:51:21 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 3 Jul 2016 17:51:21 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a11c03a4e84acb40536c4be98 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:52:05 -0000 --001a11c03a4e84acb40536c4be98 Content-Type: text/plain; charset=UTF-8 I'm not seeing a lot of enthusiasm for this option either. Do any of the people who were in favor of #1 or #2 want to say they prefer some variant of this proposal? -Ekr On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla wrote: > Nobody seems super-excited about either Option 1 or Option 2, so it's > at least worth noting that there's one of the options I claimed was > rejected earlier, namely separately encrypting the content type in > roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for > Doug/Felix for prompting me on this. > > > NOTE: I don't promise any of the below is secure, though it probably > can be made so with enough work. Actually doing so is an exercise > for the reader. > > > The basic idea is as follows: > > 1. In each direction generate a separate "content_type_key" > 2. Separately encrypt the content type from the rest of the record > using the content_type_key. > 3. On the receiving side, first decrypt the content type and then use > that to determine what key to decrypt the record. > > The trivial version of this is just to AEAD encrypt the content type > separately, but this has unacceptable bandwidth and CPU properties, so > is probably not viable. However, there are more efficient designs, > which can get the overhead down to modest levels (<= 1 byte of > expansion and <=1/16 of a block computation/record). > > The obvious construction is to use the content_type_key to compute a > per-record masking value (effectively an ad hoc stream cipher) and > then use that to encrypt the content type (or potentially just a key > type bit) without integrity (though you might later protect it in the > additional data block under the main key). This gives you an > encryption function without expansion. If you have a mask function > which outputs one block at a time, you can use pieces of the block for > each record (e.g., for record N you use byte N/16) [1] > > > Obvious objections to this: > 1. This isn't integrity protected. This is probably the most serious > complaint and has the potential to actually leak information about > the content type unless you're careful [2], even if you eventually > integrity protect this information. > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > > 3. Maybe it doesn't get the whole job done, especially wrt the fact > that we're not rekeying the app data after client auth. > > 4. It's gross. Yes, yes it is. > > > I'm not really in love with this idea, but I did want people to know > that maybe we don't *have* to choose between option 1 and option 2 > in case that changes people's opinions. > > -Ekr > > > [0] Note, I'm specifically not trying to protect length here. That > might be attractive, but my sense is that for the reasons Kenny > indicates it's harder to get right and I'm generally pretty skeptical > of length hiding in TLS given that we already have added padding. > > [1] There are some subtleties about not breaking the record format. > If we don't care, then we can strip the first three bytes and then > steal a bit from the length to use for "key type" (the length will > never hage the high bit set). If we do care, then we could use the > key bit to toggle between "app data" and "handshake" in the dummy > record type byte. > > [2] Naively, if you try encrypting the whole content type, some > transformations on the encrypted value will produce invalid types, > which leaks information if the receiver sends an alert. > > > On Fri, Jun 17, 2016 at 1:18 PM, Hugo Krawczyk > wrote: > >> I am abstaining on the choice of alternative 1 and 2 since I do not >> understand >> enough the engineering considerations and ramifications of the different >> choices. Also, I have not put any thought into the privacy issues related >> to >> hiding content type and I certainly did not do any formal analysis of >> these >> aspects. >> >> I do want to say that from a cryptographic design and analysis point of >> view, >> key separation is of great importance. It allows to have more modular >> analysis >> and design, and prove composability properties of protocols and >> applications. >> I believe it has significant practical advantages particularly with >> respect to >> "maintaining" a protocol, namely, making sure that changes and extensions >> to a >> protocol are secure and do not jeopardize its security. The more modular >> the >> design the easier it is to reason about changes and additions to the >> protocol >> (and for a protocol like TLS, future changes and adaptations to different >> settings are unavoidable). >> >> As for the specific cryptographic considerations in TLS 1.3, I would have >> "fought" greatly to preserve key separation at the level of the basic >> handshake >> protocol (three first flights). It guarantees that the application key is >> *fresh* at its first use for protecting application data. Freshness means >> that >> the key can serve any purpose for which a shared random secret key can be >> used. >> (In contrast, a non-fresh key, e.g. one used during the handshake itself, >> can >> only be used with applications that are aware of how exactly the key was >> used >> in the handshake.) Since my understanding is that the current >> base-handshake >> specification does preserve the freshness of the application key, I am >> happy >> with that design. >> >> The issue of using the application key to protect post-handshake messages >> is >> more involved. First, post-handshake client authentication authenticates >> ("a >> posteriori") the application key but only after this key has already been >> used. >> In this sense this mechanism cannot possibly achieve key freshness for the >> application key. The best one can hope for is that this >> post-authentication >> authenticates the key without jeopardizing its use in the particular >> application >> it is intended for, namely, protecting TLS record layer data. Luckily, >> this can >> be proved. So now the question is whether using the application key to >> encrypt >> the very messages that provide post-handshake authentication (e.g., >> client's >> signature) may lower the security of this key. The answer is that it does >> not. >> That is, the security of the key for protecting record layer data is not >> jeopardized by using it to encrypt post-handshake messages. >> >> I feel moderately confident about the above paragraph as I have been >> working on >> the analysis of client authentication, including (encrypted) >> post-handshake >> authentication. On the other hand, I have not studied the effects of >> encrypting >> other post-handshake messages such as New Ticket or re-keying messages so >> I >> don't have an "educated conclusion" here. I do expect that there are >> analytical >> advantages for not using the application key for encrypting these >> messages but I >> cannot say for sure. >> >> In all, it is good and prudent practice (not just theory) to enforce key >> separation wherever possible, and I would be happier if there was no >> instance >> where the application key is applied to non-application data. But I also >> know >> that one has to weigh other engineering considerations and in this case >> the >> trade-off does not seem obvious to me. Hence, as said, I abstain. >> >> Hugo >> >> >> On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey wrote: >> >>> For background please see [1]. >>> >>> Please respond to this message indicating which of the following options >>> you prefer by Monday June, 20, 2016 >>> >>> 1. Use the same key for handshake and application traffic (as in the >>> current draft-13) >>> >>> or >>> >>> 2. Restore a public content type and different keys >>> >>> Thanks, >>> >>> J&S >>> >>> >>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html >>> >>> _______________________________________________ >>> 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 >> >> > --001a11c03a4e84acb40536c4be98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not seeing a lot of enthusiasm for this option eit= her.

Do any of the people who were in favor of #1 or #2 = want to say they prefer some variant of this proposal?

-Ekr


On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <ekr@rtfm= .com> wrote:
Nobody seems super-excited about either Option 1 or Option 2, so it= 's
at least worth noting that there's one of the options = I claimed was
rejected earlier, namely separately encrypting the = content type in
roughly the manner suggested by DKG, Ilari, and K= enny. Thanks for
Doug/Felix for prompting me on this.
<= br>

NOTE: I don't promise any of the below is = secure, though it probably
can be made so with enough work. Actua= lly doing so is an exercise
for the reader.

<= div>
The basic idea is as follows:

1= . In each direction generate a separate "content_type_key"
<= div>2. Separately encrypt the content type from the rest of the record
=C2=A0 =C2=A0using the content_type_key.
3. On the receivin= g side, first decrypt the content type and then use
=C2=A0 =C2=A0= that to determine what key to decrypt the record.

= The trivial version of this is just to AEAD encrypt the content type
<= div>separately, but this has unacceptable bandwidth and CPU properties, so<= /div>
is probably not viable. However, there are more efficient designs= ,
which can get the overhead down to modest levels (<=3D 1 byt= e of
expansion and <=3D1/16 of a block computation/record).

The obvious construction is to use the content_type_= key to compute a
per-record masking value (effectively an ad hoc = stream cipher) and
then use that to encrypt the content type (or = potentially just a key
type bit) without integrity (though you mi= ght later protect it in the
additional data block under the main = key). This gives you an
encryption function without expansion. If= you have a mask function
which outputs one block at a time, you = can use pieces of the block for
each record (e.g., for record N y= ou use byte N/16) [1]


Obvious objec= tions to this:
1. This isn't integrity protected. This is pro= bably the most serious
complaint and has the potential to actuall= y leak information about
the content type unless you're caref= ul [2], even if you eventually
integrity protect this information= .

2. It's odd to just use a piece of the AEAD = cipher (the encryption
function), especially if we ever had a rea= lly non-composite cipher.
This can be alleviated by using HKDF-Ex= pand to produce the stream
of bits.

3. M= aybe it doesn't get the whole job done, especially wrt the fact
that we're not rekeying the app data after client auth.
4. It's gross. Yes, yes it is.

I'm not really in love with this idea, but I did want peop= le to know
that maybe we don't *have* to choose between optio= n 1 and option 2
in case that changes people's opinions.

-Ekr


[0] Note,= I'm specifically not trying to protect length here. That
mig= ht be attractive, but my sense is that for the reasons Kenny
indi= cates it's harder to get right and I'm generally pretty skeptical
of length hiding in TLS given that we already have added padding.<= /div>

[1] There are some subtleties about not breaking t= he record format.
If we don't care, then we can strip the fir= st three bytes and then
steal a bit from the length to use for &q= uot;key type" (the length will
never hage the high bit set).= If we do care, then we could use the
key bit to toggle between &= quot;app data" and "handshake" in the dummy
record= type byte.

[2] Naively, if you try encrypting the= whole content type, some
transformations on the encrypted value = will produce invalid types,
which leaks information if the receiv= er sends an alert.


On Fri,= Jun 17, 2016 at 1:18 PM, Hugo Krawczyk <hugo@ee.technion.ac.il&g= t; wrote:
I am abstainin= g on the choice of alternative 1 and 2 since I do not understand
enough th= e engineering considerations and ramifications of the different
choices. A= lso, I have not put any thought into the privacy issues related to
hiding = content type and I certainly did not do any formal analysis of these=
aspec= ts.=C2=A0

I do want to say that from a cryptographic design and anal= ysis point of view,
key separation is of great importance. It allows to ha= ve more modular analysis
and design, and prove composability properties of= protocols and applications.
I believe it has significant practical advant= ages particularly with respect to
= "maintaining" a protocol, name= ly, making sure that changes and extensions to a
protocol are secure and d= o not jeopardize its security. The more modular the
design the easier it = is to reason about changes and additions to the protocol
(and for a protoc= ol like TLS, future changes and adaptations to different
settings are unav= oidable).

As for the specific cryptographic considerations in TLS 1.= 3, I would have
"fought" greatly to preserve key separation at t= he level of the basic handshake
protocol (three first flights). It guarant= ees that the application key is=C2=A0
*fresh* at its first use for protect= ing application data. Freshness means that
the key can serve any purpose f= or which a shared random secret key can be used.
(In contrast, a non-fresh= key, e.g. one used during the handshake itself, can
only be used with app= lications that are aware of how exactly the key was used=C2=A0
=
in the hand= shake.) Since my understanding is that the current base-handshake
specific= ation does preserve the freshness of the application key, I am happy=
with = that design.

The issue of using the application key to protect post-= handshake messages is
more involved. First, post-handshake client authen= tication authenticates ("a
posteriori") the application key but = only after this key has already been used.
In this sense this mechanism ca= nnot possibly achieve key freshness for the
application key. The best one = can hope for is that this post-authentication
authenticates the key withou= t jeopardizing its use in the particular application
it is intended for, n= amely, protecting TLS record layer data. Luckily, this can
be proved. So n= ow the question is whether using the application key to encrypt
the very m= essages that provide post-handshake authentication (e.g., client's
sig= nature) may lower the security of this key. The answer is that it does not.=
jeopardized by using it to encrypt post-handshake messages.

I feel = moderately confident about the above paragraph as I have been working on
t= he analysis of client authentication, including (encrypted) post-handshake<= /font>
authentication. On the other hand, I have not studied the effects of encry= pting
other post-handshake messages such as New Ticket or re-keying messag= es so I
don't have an "educated conclusion" here. I do expec= t that there are analytical
advantages for not using the application key f= or encrypting these messages but I
cannot say for sure.

=
In all, it = is good and prudent practice (not just theory) to enforce key
<= div class=3D"gmail_default">separation w= herever possible, and I would be happier if there was no instance
where th= e application key is applied to non-application data. But I also know
that= one has to weigh other engineering considerations and in this case the
tr= ade-off does not seem obvious to me. Hence, as said, I abstain.

Hugo


On Mon, Jun 13, 2016 at 3:00 PM= , Joseph Salowey <joe@salowey.net> wrote:
For background please see = [1].

Please respond to this message indicating whi= ch of the following options you prefer by Monday June, 20, 2016=C2=A0

1. Use the same key for handshake and application = traffic (as in the current draft-13)

or

2. Restore = a public content type and different keys

Thanks,

<= font face=3D"arial, helvetica, sans-serif">J&S



_______________________________________________
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



--001a11c03a4e84acb40536c4be98-- From nobody Sun Jul 3 18:01:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B612D1AD for ; Sun, 3 Jul 2016 18:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LZMbyeuY4Av for ; Sun, 3 Jul 2016 18:01:05 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCD112B02B for ; Sun, 3 Jul 2016 18:01:05 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id b72so29255252ywa.3 for ; Sun, 03 Jul 2016 18:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FI25pf4Pk0ar93+3I6aIz9UFs2pMOGYjSTQSiIygPU8=; b=mI1SUtWxA/XFCKRY6Sd4k251AUD6RObBN+PsM7DOMTZ5xESx6Scoyg3VtdXKdJyIyr JgC5wvKN6mGlUutFKi1vwCTH7zlp3MgoV6EPaG9alINDMGkuwE0JQHAOx3AcTrwUmPyU c25maLzs8JwqgGP1AMRhaKgrkcApjczkIcLKnbO5pPck6o5hzavgOtRrwn9eDeghIwSe D8qVn5Fe05YDymMi/2zT/rAorhhF4yMS943EapLRVhCdpEkhpUM75j5XfPLy5/cskscR cbn/uoF2a6Ns0hesccf6GvQUehuimA+doUCmHkfWy1fIQYq3XUBNG0nM9Ja0tdZkeose Qazw== 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; bh=FI25pf4Pk0ar93+3I6aIz9UFs2pMOGYjSTQSiIygPU8=; b=bdLkFhB0tjRvo6SL+gcTgOui6i9GKZcvhmFkNdwF/46BUDfKp3tM+upl5Rfw9NQBTk oInAg29xnFrvH6KP+8HtllBqIr6V+y8chcCbjONIfFEBYP5GD0T/GvsDreQUug2Etcc7 RRT0DtmWS/pOs8HQzVcduMWEEprJehCGRtS4TcuvXFdoF7DnOvswSori8GmeFiOBjGgX t3Z8KEwaH67OjibXfYFPMVWfPy4CW/DWsDen46Rlkkq7uuLMZwpJW7IoIFjO+0zOmDs3 jpo7rZhfwP+SqRwAS9oZ99CyJkidKTNp+9TWu6OX0mfDlYlTga8SQvZui2PhYol0ypmx hpoA== X-Gm-Message-State: ALyK8tI441dmN7kLvGc2do4Ae8eKfMM759Cn09hNcll/Ft0rya4SbdktK8YApChIKCcGf9RFRqDlEB4i0CMHkg== X-Received: by 10.129.52.84 with SMTP id b81mr6247900ywa.8.1467594064935; Sun, 03 Jul 2016 18:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Sun, 3 Jul 2016 18:00:25 -0700 (PDT) In-Reply-To: References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> <20160626163416.GA24381@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 3 Jul 2016 18:00:25 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11406f0aea430e0536c4ded2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 01:01:07 -0000 --001a11406f0aea430e0536c4ded2 Content-Type: text/plain; charset=UTF-8 I believe that this is the right design. The primary proposed use for EncryptedExtensions in the 0-RTT flight is for EncryptedSNI. However, I don't believe that they are actually that useful in this case because the design constraints for EncryptedSNI are intended to allow the client to encrypt the SNI to a gateway but encrypt the traffic to the hidden server, which means that you want the SNI to be protected with gateway keys, not the terminal traffic keys. This design still allows two fairly elegant EncryptedSNI designs: - Stuff a self-encrypted value of the SNI into the ticket label (due to Cedric Fournet). - Establish a ticket to the gateway server and then encrypt the ClientHello that is destined for the hidden server in the 0-RTT early data flight to the gateway, which deciphers it and passes it to the hidden server, which responds with the ServerHello (due to Martin Thomson) Both of these are more flexible than SNI in EE. Absent strong objections, I intend to merge this PR on Wednesday. -Ekr On Sun, Jun 26, 2016 at 6:33 PM, Martin Thomson wrote: > On 27 June 2016 at 02:34, Ilari Liusvaara > wrote: > > That's the reason it is XOR'd currently, but the XOR probably will > > be changed to ADD32 to break correlation-to-parent (which is really > > nasty privacy-wise) in case of ticket reuse. > > Let's not make that probably. I've updated the PR. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11406f0aea430e0536c4ded2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that this is the right design.
The primary proposed use for EncryptedExtensions in the 0-RTT = flight is for
EncryptedSNI. However, I don't believe that the= y are actually that useful in
this case because the design constr= aints for EncryptedSNI are intended to
allow the client to encryp= t the SNI to a gateway but encrypt the traffic to
the hidden serv= er, which means that you want the SNI to be protected with
gatewa= y keys, not the terminal traffic keys.

This design= still allows two fairly elegant EncryptedSNI designs:

=
- Stuff a self-encrypted value of the SNI into the ticket label (due t= o Cedric
=C2=A0 Fournet).
- Establish a ticket to t= he gateway server and then encrypt the ClientHello
=C2=A0 that is= destined for the hidden server in the 0-RTT early data flight to the
=
=C2=A0 gateway, which deciphers it and passes it to the hidden server,= which
=C2=A0 responds with the ServerHello (due to Martin Thomso= n)

Both of these are more flexible than SNI in EE.=

Absent strong objections, I intend to merge this = PR on Wednesday.
-Ekr





<= br>
On Sun, Jun 26, 2016 at 6:33 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
On 27 June 2016 at 02:34, Ilari Liusvaar= a <ilariliusvaara@welho.com<= /a>> wrote:
> That's the reason it is XOR'd currently, but the XOR probably = will
> be changed to ADD32 to break correlation-to-parent (which is really > nasty privacy-wise) in case of ticket reuse.

Let's not make that probably.=C2=A0 I've updated the PR.

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

--001a11406f0aea430e0536c4ded2-- From nobody Sun Jul 3 18:22:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6892F12D1B2 for ; Sun, 3 Jul 2016 18:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_SJGQlFplpU for ; Sun, 3 Jul 2016 18:22:30 -0700 (PDT) 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 77E2F12D1AD for ; Sun, 3 Jul 2016 18:22:30 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id e3so53716364qkd.0 for ; Sun, 03 Jul 2016 18:22:30 -0700 (PDT) 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:cc :mime-version:content-transfer-encoding:message-id; bh=1NhArcsenCV/nzfpJWNSSquutI7o3GeaqOLT+Fj4mo0=; b=Hi8vK2bXlgRDGIGMzYSKWg4HcFX4wlz57ZcHTodNVf3DHl6L5RvriVuBJnSrUXUvCA yXfEmj+BGM5W6sYiFwlAs5VnS1H4kJGu0uGCE8cBBBCiR5DTZoaTDm5E/JnOtZn8imYK 0XcdAdF6Qo8jI967ldmcC0yAR/6fSWVopGseDrj+HNe267/nBaOwhvmEWlo5ObQm8kRO JAK5n1rB0Qw4gQbZn1n4thdij5tQt5gJz9j2bjokO7KtlxdPHdQ8NlFeKzVrRQUiHbNv zqGJuZ7Z1WyNso79J4EPMvVbBSxYDsUi58f3geYuXTHUCYZ8dkXPtf7IbAtBSrheoqJY P72g== 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:references :in-reply-to:cc:mime-version:content-transfer-encoding:message-id; bh=1NhArcsenCV/nzfpJWNSSquutI7o3GeaqOLT+Fj4mo0=; b=VBetdTUozGL8MxMcaQyxuggpkWc1zBUTdvL9gRplv+KmsfisFK+j9ygOzN4P1aoM9l e7AW5DIAb8etk5sNIKMcaI3LfWmqO6bgDljiCUtSSTB0z++i7z026e05kw6uVx5sTzWU ksqqCpwMWCQoIi4MCuBWvrNFXWSqr0VxcupW9xzU7EZzUq03T28N3fAxmR7PPeGxYuLg scP2YYr/j2dRbdVsY6YhWkozD0cjWuWrI75rq6IYjq5Hni0MiF/osfc3DxP96dZTxe15 J8bO/PQRgTRE3xSOdYX8ktXP4Lcepw5L2hwbM6vYr2Gags8+PIi0A0GatKEX9qPNL7D7 7KyQ== X-Gm-Message-State: ALyK8tKZ5rHRSZ5vlH+Qu3T8pwqdX0okgHuCx7P4DvhuvUrTyssEd8JFY5KkF6xudjp4Tw== X-Received: by 10.55.3.18 with SMTP id 18mr13163803qkd.154.1467595349672; Sun, 03 Jul 2016 18:22:29 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id o2sm2010894qkd.0.2016.07.03.18.22.28 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 03 Jul 2016 18:22:29 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 3 Jul 2016 21:22:27 -0400 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: <201607032122.28045.davemgarrett@gmail.com> Archived-At: Subject: [TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 01:22:32 -0000 On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote: > This seems reasonable, as the > only real argument against is that conformant TLS 1.3 servers will have > only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in > the top 32 bytes), as opposed to 24 if they randomize the first 32 bytes. to correct the typo: 32 bits / 4 bytes; total size of random is 32 bytes / 256 bits > OTOH, those bytes will be more unique over time (because they are > guaranteed not to repeat for a very long time after the second has passed), > so intuitively this seems like a wash. Under the "Reevaluate handshake contents" part of the current TLS WG charter [0], we have the question: "Are bigger randoms required?". Did the WG ever fully discuss this and come to a decision? Adding a supplemental entropy extension would be trivial, if we wanted to do so. (I see there was consideration of doing so a while ago [1].) Amending the TLS 1.3 spec to add it as a requirement would be easy, but would it be useful? If we want to allow 2 hacks in the current random value that reduce the entropy, then adding some entropy back in an extension makes some sense. (If this was already settled at some point, please just point me to wherever that was. I might've just forgotten. ;) Dave [0] https://datatracker.ietf.org/wg/tls/charter/ [1] https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02 From nobody Mon Jul 4 03:21:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBED012B058 for ; Mon, 4 Jul 2016 03:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWTqZD0IH3AO for ; Mon, 4 Jul 2016 03:21:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A3B3712B022 for ; Mon, 4 Jul 2016 03:21:25 -0700 (PDT) Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LorB9-1bmS8e0Vo3-00gsV8 for ; Mon, 04 Jul 2016 12:21:23 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <577A38A2.2090209@gmx.net> Date: Mon, 4 Jul 2016 12:21:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fLq3xHdWKEc0mvP6gbqJbLHfodL9fT38x" X-Provags-ID: V03:K0:wB7VU2TSki15YoNW+Hl1tDCex47MvF3reH0lHF18bj47/ZiRQOC JfpzNV9/fXS4DfbeaVlBLsGF6bputs4suq4AZoO0cz1/eIBE9dimL/7mx7kxlOw0HyEcoEw MG3FNGmg6deew6lULE7xV8wIfwV1p8H5g1+WqDnB34IwHh3cxcm1LyElXT3BTh7N2/QiNU0 EBvTQmTn+p8dOzVJQSeWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:p3FfT9EbzS4=:bKS8HYWRO5M68cIUB3ZufJ ydb1T3vESR6OlGg6DJ8WBu6BOkQE/VjLz1EMvjdazA0sNUcOtFBMl/QJaOxWwbmq+/lj0fcOs dmWpk+Cd07oEXwE2u3qLc9ZGe0JWhmxg71CcPlQW1ymvBr+wO88i4VSQLyplUBjNDdfP0JHpo hBcCJOInOPGNtllYkB97gj9VU+2lmi9CO9HKrVzyqFSE3pk/XhHMzvd/AYJ+eivRxAveGgetY BoRtPSTz6mzHysasrB98BaW38xcIK4vIxhhgWmDtjjL0GX+4KXjrgFnFV0mUtwZHg2EqRlujj 8XS2flzvzoyYG5jD+Y4+EzeE5PipkVIu81rXPssLR1XmMYpSRkLpvgE4j6Nn+Egz/f+8tj8zK rd4X5M57eYy2ZZ3IErkD3G7kD+pWYUUzL7thYuPvmn2SrmRvcPeO4y2HPfeJ5K9VokI7a7IgD nDvdkf4qHhFcVtY0c9mz1O3cf1hM2hC6YR4HqYsX0mf71qxen9q8iS43m8IOhNCQx/Iz82SRW X6os3BY88IPqTdwv5YPVMIYlG7ZeiIwXsumZPjZIGFbC6Uaf1GjecVLW4ZhySxTii8TEn8OPX zy6ms6vyUrsb4p8AIzXhmgW39laToXqvlYPDSSHbraPUcTCH+ChngtI4yoXEtEhDrjB0IWgV/ jT+Vxq5CLPnDqzgdSUgbgUlnJdNeIugV61jGXMHD+IRZ8Qt6W+fbIVtwVgHz6zXCF3y4fiYZy aVBXAb8QaG7eTonM5RC1EPf6LMfBVHtiILIYiW9P+izp+QXXN52ncbxyj3Y= Archived-At: Subject: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:21:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fLq3xHdWKEc0mvP6gbqJbLHfodL9fT38x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document and you can find the result at https://github.com/tlswg/tls13-spec/pull/5= 12 I have worked on a prototype implementation of DTLS 1.3 and if someone else has something working by the time of the Hackathon in Berlin please let me know. Ciao Hannes --fLq3xHdWKEc0mvP6gbqJbLHfodL9fT38x 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 iQEcBAEBCgAGBQJXejikAAoJEGhJURNOOiAtzEkIAKHHQa178jmTVYDEalO5vqM3 pTECNyQEPg78qqi65L+3bjuEqLA2kKyXB986kUf7VBUAZO9dDrIr6QhbLcA+1oTh 5uI2a5Jck1pLy2tyl2RbTU4O/6NDXLzdZixdIr0cQuVzJoIpE+lvb7SqwC8IIk4v vjjAGuNO89GKesgCpTl3ISaW6Vu1cluYgqGqhZzdiHcG88/lvYS+qq0KfvjSsJJ9 Qe6tPzGtJieHNee14C8GC/is/s9T+Hu+nLoRQ1pZ8IFjiNLxDxZrlfiZh8F6IXFx 0OqIXvijXzi0NNd34hGt9trMju4QloO5mQAbhFwOkfoKBpzIpJGGV5JUSgAfLt8= =RKAH -----END PGP SIGNATURE----- --fLq3xHdWKEc0mvP6gbqJbLHfodL9fT38x-- From nobody Mon Jul 4 05:46:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4B12D0CA for ; Mon, 4 Jul 2016 05:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KfaMMZ8fDhf for ; Mon, 4 Jul 2016 05:46:05 -0700 (PDT) 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 F40EE12D0C4 for ; Mon, 4 Jul 2016 05:46:04 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f126so102410677wma.1 for ; Mon, 04 Jul 2016 05:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=qKar9nLDbBVuFO5C1Tq7qSWnDAih+fB2wpe6wP255eI=; b=ac801mA6j5Y0CG2xe9aHt4EhLq85I0Tbd+6JYb6SnkHJ6VkoTd5msWIQDBmMk1ucIx ZJqN7tFp3RR3Ypfdxz4Hsf8UguZ2qLiWCR3hoBOtVvrQl6eCvJYuog474eKlrmn8lFKv jGUyJgjfywDbrYQ/AHcq9D21lXVvpt8KqEq5VJ5fqGlsz5+OiggarZdemybTXzG21cUu fBZWAdy9EXVtR+6x60fLGoTOkuCIZB4wJSIxsgdoAh+23Xj61tIBGq73qsNzsEPBaGmA oZxK7ObAmRqkGlNbSVzIkjH1JsqWTe9sIu1o1L1X58mg0WsIFc8EJANhocLfyAFURfL6 MLDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=qKar9nLDbBVuFO5C1Tq7qSWnDAih+fB2wpe6wP255eI=; b=ZRwU3Cbs4/59UlHxfO2gMTb8kZu4s6dHaevFj/JtNyGVzHvZiSHWr8mh0+Z9B/jIZA Dfpr5H2ZeIEcNXKGw2U78J9R2lzVcEpDoig4AAV1usYrhL9epI9DEIQEbPRGGbLK7a6S REqlpYAbmrZmozCRDQstyRKGWHr+1ilZxxuiSh0ZZHW1fq1Tdb0kGXUAmLqRd4pyznxa 5vKrkXAFU0vuwsXHjMuzt8pjJrXLhwc5G2N1L4ap7H+PNpxA2qzwXxd2amV5w5UcZBLq m+8zrCy8v0GGGi/PT2j3FlKONhZstfiw4FxRp3ypBaMbaavO8pC5xqbrpOqClGSNNcFh 2+cA== X-Gm-Message-State: ALyK8tIFena033xkUsYkGHpwAc+fSY9trIMgOjehvdSu9C1C1WuZymCWxQ0LFeC9YJD03g== X-Received: by 10.194.81.138 with SMTP id a10mr11909379wjy.53.1467636363200; Mon, 04 Jul 2016 05:46:03 -0700 (PDT) Received: from [172.24.249.249] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id hf7sm4033842wjc.48.2016.07.04.05.46.01 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 05:46:02 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> Date: Mon, 4 Jul 2016 15:46:00 +0300 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] PR #23 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:46:07 -0000 Hi Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80=99ve = submitted a PR. https://github.com/tlswg/rfc4492bis/pull/23 If there are no objections, I will accept it and submit version -08 this = Friday. Thanks Yoav From nobody Mon Jul 4 05:51:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6812D0F7 for ; Mon, 4 Jul 2016 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-if8EuthaCG for ; Mon, 4 Jul 2016 05:51:32 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 696F912D108 for ; Mon, 4 Jul 2016 05:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 241E4586E; Mon, 4 Jul 2016 15:51:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 6r5zom2Yrnvj; Mon, 4 Jul 2016 15:51:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id CB704287; Mon, 4 Jul 2016 15:51:30 +0300 (EEST) Date: Mon, 4 Jul 2016 15:51:28 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160704125128.GA4287@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> <20160626163416.GA24381@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:51:35 -0000 On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote: > I believe that this is the right design. > > The primary proposed use for EncryptedExtensions in the 0-RTT flight is for > EncryptedSNI. However, I don't believe that they are actually that useful in > this case because the design constraints for EncryptedSNI are intended to > allow the client to encrypt the SNI to a gateway but encrypt the traffic to > the hidden server, which means that you want the SNI to be protected with > gateway keys, not the terminal traffic keys. > > This design still allows two fairly elegant EncryptedSNI designs: > > - Stuff a self-encrypted value of the SNI into the ticket label (due to > Cedric Fournet). Just beware of replay on the server side (figured out recently why encrypted SNI is actually so nontrivial...) > - Establish a ticket to the gateway server and then encrypt the ClientHello > that is destined for the hidden server in the 0-RTT early data flight to > the > gateway, which deciphers it and passes it to the hidden server, which > responds with the ServerHello (due to Martin Thomson) > > Both of these are more flexible than SNI in EE. This seems to assume that the final server supports TLS 1.3 + that TLS 1.3 has hidden record types... At least if one wants to avoid double encrypt/ decrypt. Extending to case where the final server is TLS 1.2 (or if TLS 1.3 removes hidden record types) and not doing full second encryption/decryption seems at least a bit harder.. -Ilari From nobody Mon Jul 4 06:24:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52D12B01E for ; Mon, 4 Jul 2016 06:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7t_NLC96EL7 for ; Mon, 4 Jul 2016 06:24:45 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3067012B055 for ; Mon, 4 Jul 2016 06:24:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 720627F51 for ; Mon, 4 Jul 2016 16:24:43 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id XPVpiKd3RxXf for ; Mon, 4 Jul 2016 16:24:43 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1DD6CC4 for ; Mon, 4 Jul 2016 16:24:43 +0300 (EEST) Date: Mon, 4 Jul 2016 16:24:41 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160704132441.GB4287@LK-Perkele-V2.elisa-laajakaista.fi> References: <201607032122.28045.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201607032122.28045.davemgarrett@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:24:48 -0000 On Sun, Jul 03, 2016 at 09:22:27PM -0400, Dave Garrett wrote: > On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote: > > OTOH, those bytes will be more unique over time (because they are > > guaranteed not to repeat for a very long time after the second has passed), > > so intuitively this seems like a wash. > > Under the "Reevaluate handshake contents" part of the current TLS WG > charter [0], we have the question: "Are bigger randoms required?". Did > the WG ever fully discuss this and come to a decision? I haven't seen a discussion. And my own opinion is "definitely not". However, shortening the randoms is different thing. And what makes this even nastier is that this isn't about what TLS 1.3 needs, but what TLS 1.2 needs. What does TLS 1.2 actually expect out of ClientRandom and ServerRandom? I think for ClientRandom, TLS 1.2 wants "Globally unique nonce". And for ServerRandom, "Nonce unique w.r.t. server key". TLS 1.3 has these a lot weaker: The "Globally unique nonce" from client is now the entiere ClientHello (and corresponding server nonce is the entiere ServerHello). If using DHE-type key exchange, both include short-lived public keys. (This actually comes from TLS 1.3 not using randoms for anything, causing some additional headache for contexts where privsep is needed). > Adding a > supplemental entropy extension would be trivial, if we wanted to > do so. Unfortunately, this only concerns TLS 1.2 mode on server-to-client direction, which is just about the nastiest case. - Can't stuff it in base ServerHello - Can't stuff it in any existing extension (I think at least some TLS clients do check that all lengths match exactly). - Can't stuff it in any new extension (not supported!) > (I see there was consideration of doing so a while ago [1].) BTW: The intended purpose of that extended-random was apparently to make exploiting DUAL_EC_DRBG easier (AFAICT, cuts down bruteforcing from 32 to 16 bits). The reasons stated for longer-than-256-bit randoms in that draft was likely to be cryptographically pretty bogus. -Ilari From nobody Mon Jul 4 06:28:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB512D122 for ; Mon, 4 Jul 2016 06:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ1pIoFc6kzw for ; Mon, 4 Jul 2016 06:28:17 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 541E312D11F for ; Mon, 4 Jul 2016 06:28:17 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i12so39576589ywa.1 for ; Mon, 04 Jul 2016 06:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tzoELGHnxYsm0JOxq9IfJVlcXQKy9Y7Ww25T4/DpKyc=; b=fzV/F3QsIcXfYekenVCo2HwMWKezR0wIi5sVmYZRfwZc5JIQmyU7GX0HHlAS4bIdKU ZKuGz2R9kepJUpLPVNBUUnjFeEKssMDzV3Q0qYWktWn580beMcMtYv86Dsg0UsO5B06l lE8YLIzj+oCNNWT/hvzDJMFOxNcFoWQ9eP/LdBtdbo3w3cpRwaMn1zVVanzetuxRo+mN xhPSousstk9ktj35FGhUUAQSMnWLRQPaCkWPUtB6B4smsMkl5qWlcb0LKXXmzjXpxNrh YyGAyNBH9BvjrB/G4vcxZZMEJ8o+3tVSmuHQqXvbIqgT5nohwn+6SoCHOGC2eAYKGAxj CJnA== 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; bh=tzoELGHnxYsm0JOxq9IfJVlcXQKy9Y7Ww25T4/DpKyc=; b=PTWg+YRgiKU9W1/aYWYTp/fa9IV9VB+4GVXLzAhGzpMr29c6W4u6ZgiQu2otcFYWJk ljNoKcgb0Zs7wSS6qQTqR8ldH3HdaLHrsOOS8Udb2DCZ0Ns3JYSxdGGuzjsZZYQQQXVL AXwNxva5eWr4EwkYWgnJPGLg/xZ+1en/btEN8+EF9X5FPJgw7iZ0lZS/jfrtVWQsZaZ7 ZJX4QOJNcZv7L0cYnuMTJq51NYClXncLhR3GemIjz8cJ1bg0CWnUXAoN3IQ78vlSQu4u aSg7FZ4WKG/eMj0dSu93xXa7tJ/Js4nkg+7GlHWPR1MC5jMlFUnpAirHyAHMH6OCBCHM TI6g== X-Gm-Message-State: ALyK8tIIc46IhQvBcekJ9kmWKv4fXtP31lrCN5x71rjj7drx2DCEXg8PZKWzT/HC9nIUC1gP+4fpMHr6Vlg/pQ== X-Received: by 10.129.52.84 with SMTP id b81mr7732544ywa.8.1467638896654; Mon, 04 Jul 2016 06:28:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Mon, 4 Jul 2016 06:27:37 -0700 (PDT) In-Reply-To: <577A38A2.2090209@gmx.net> References: <577A38A2.2090209@gmx.net> From: Eric Rescorla Date: Mon, 4 Jul 2016 06:27:37 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11406f0a1800810536cf4ff3 Archived-At: Cc: "" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:28:18 -0000 --001a11406f0a1800810536cf4ff3 Content-Type: text/plain; charset=UTF-8 Thank you. I will examine the PR ASAP. NSS already implements the obvious extrapolation of TLS 1.3 to DTLS and we are planning to start testing it in Firefox WebRTC shortly: https://bugzilla.mozilla.org/show_bug.cgi?id=1284103 -Ekr On Mon, Jul 4, 2016 at 3:21 AM, Hannes Tschofenig wrote: > Hi all, > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > and you can find the result at > https://github.com/tlswg/tls13-spec/pull/512 > > I have worked on a prototype implementation of DTLS 1.3 and if someone > else has something working by the time of the Hackathon in Berlin please > let me know. > > Ciao > Hannes > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11406f0a1800810536cf4ff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you. I will examine the PR ASAP.

= NSS already implements the obvious extrapolation of TLS 1.3 to DTLS and we<= /div>
are planning to start testing it in Firefox WebRTC shortly:
=

<= /div>
-Ekr


On Mon, Jul 4, 2016 at 3:21 AM, Hannes Tschofenig <= span dir=3D"ltr"><hannes.tschofenig@gmx.net> wrote:
Hi all,

I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document
and you can find the result at https://github.com/tlswg/= tls13-spec/pull/512

I have worked on a prototype implementation of DTLS 1.3 and if someone
else has something working by the time of the Hackathon in Berlin please let me know.

Ciao
Hannes


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


--001a11406f0a1800810536cf4ff3-- From nobody Mon Jul 4 06:30:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317F112D131 for ; Mon, 4 Jul 2016 06:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUp7NKotpbr8 for ; Mon, 4 Jul 2016 06:30:49 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 5444F12D11F for ; Mon, 4 Jul 2016 06:30:49 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v77so39820434ywg.0 for ; Mon, 04 Jul 2016 06:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aPCwoVSRmluDXgYwiREqwBYavNbIcGUu6fg6GcSe+eU=; b=mNNeGlhFZ2D9AjB5sqti3gTJfOU0Zas/tJAlIsMfH4gX2YI83j6XnXJmQzum6fgmz4 OxuVttaLif1vFYnpiyS63U3UOAEbJi6KyzKTnMFOcOHtJ/xTZ1/iYYfGRGXTJan9UDw2 uDIzLOTbs4BGUknE4VA8l6ACE0wh8GpGNi+LtQz5ctDfscUCScb4yuF9a8zGEM+OSUWy 8jHybkqqILXT+Pu/5iWa2Ik8QTTFB7PSghZkGfId9CX18KNqNsMAR3fEXc9UjG/nNSGY Zzce5om58+A2/cOGRy49YdbAY9lOMC/ZAabdzO4RB0Gmso5dHitix4FrYRlOnacGXZOg EYjA== 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; bh=aPCwoVSRmluDXgYwiREqwBYavNbIcGUu6fg6GcSe+eU=; b=Lulhr+9ICaTt5oKl+m8UjtmsNkiMxG2fZrOaiS/8fpshLbhRcDq7xeLYgKi6T1eQl7 VxetzbjKGnQuAWuKRLvMnIB6qgTxKOjsWaFFGa66mkXiPiPWaNfNkIPGKnrpw8b2gfE1 /Q1Ek217PFdPBKLA59VeOQTeCDr+6VJFnAIf9awcFAQRtdBKliMTnPFc8mIFUbuDMqbL cXSQ8XBRxHmootqzyEK3k/UNGo+fj4LIMHL7bcm/p4JA++A7J2UxHjmWZu2UlMwXEPSt Qz3rfrN3xVEkrKyqtpuZT20NM0AKwCNinRm3qN+3xYkSK5W+RbHC/dM4re5AA27/grBU Ws2Q== X-Gm-Message-State: ALyK8tLoKm79E4hrpwanHyulWtAm0Z9c0Jt54rqHtIgV3zHKdKMepbkcjBK3nswdevfhDdVd9aN/dgB5OpOlnw== X-Received: by 10.129.46.87 with SMTP id u84mr8078629ywu.214.1467639048646; Mon, 04 Jul 2016 06:30:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Mon, 4 Jul 2016 06:30:09 -0700 (PDT) In-Reply-To: <20160704125128.GA4287@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> <20160626163416.GA24381@LK-Perkele-V2.elisa-laajakaista.fi> <20160704125128.GA4287@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 4 Jul 2016 06:30:09 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114140ba2765080536cf5899 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:30:55 -0000 --001a114140ba2765080536cf5899 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 4, 2016 at 5:51 AM, Ilari Liusvaara wrote: > On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote: > > I believe that this is the right design. > > > > The primary proposed use for EncryptedExtensions in the 0-RTT flight is > for > > EncryptedSNI. However, I don't believe that they are actually that > useful in > > this case because the design constraints for EncryptedSNI are intended to > > allow the client to encrypt the SNI to a gateway but encrypt the traffic > to > > the hidden server, which means that you want the SNI to be protected with > > gateway keys, not the terminal traffic keys. > > > > This design still allows two fairly elegant EncryptedSNI designs: > > > > - Stuff a self-encrypted value of the SNI into the ticket label (due to > > Cedric Fournet). > > Just beware of replay on the server side (figured out recently why > encrypted SNI is actually so nontrivial...) > > > - Establish a ticket to the gateway server and then encrypt the > ClientHello > > that is destined for the hidden server in the 0-RTT early data flight > to > > the > > gateway, which deciphers it and passes it to the hidden server, which > > responds with the ServerHello (due to Martin Thomson) > > > > Both of these are more flexible than SNI in EE. > > This seems to assume that the final server supports TLS 1.3 + that TLS 1.3 > has hidden record types... At least if one wants to avoid double encrypt/ > decrypt. > Yes. Extending to case where the final server is TLS 1.2 (or if TLS 1.3 removes > hidden record types) and not doing full second encryption/decryption seems > at least a bit harder.. Agreed. I am happy to punt the first case, and I don't sense enthusiasm for removing the second case. -Ekr > > > > -Ilari > --001a114140ba2765080536cf5899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 4, 2016 at 5:51 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote:
> I believe that this is the right design.
>
> The primary proposed use for EncryptedExtensions in the 0-RTT flight i= s for
> EncryptedSNI. However, I don't believe that they are actually that= useful in
> this case because the design constraints for EncryptedSNI are intended= to
> allow the client to encrypt the SNI to a gateway but encrypt the traff= ic to
> the hidden server, which means that you want the SNI to be protected w= ith
> gateway keys, not the terminal traffic keys.
>
> This design still allows two fairly elegant EncryptedSNI designs:
>
> - Stuff a self-encrypted value of the SNI into the ticket label (due t= o
> Cedric Fournet).

Just beware of replay on the server side (figured out recently why encrypted SNI is actually so nontrivial...)

> - Establish a ticket to the gateway server and then encrypt the Client= Hello
>=C2=A0 =C2=A0that is destined for the hidden server in the 0-RTT early = data flight to
> the
>=C2=A0 =C2=A0gateway, which deciphers it and passes it to the hidden se= rver, which
>=C2=A0 =C2=A0responds with the ServerHello (due to Martin Thomson)
>
> Both of these are more flexible than SNI in EE.

This seems to assume that the final server supports TLS 1.3 + that T= LS 1.3
has hidden record types... At least if one wants to avoid double encrypt/ decrypt.

Yes.

=
Extending to case where the final = server is TLS 1.2 (or if TLS 1.3 removes
hidden record types) and not doing full second encryption/decryption seems<= br> at least a bit harder..

Agreed. I am happy = to punt the first case, and I don't sense enthusiasm for
remo= ving the second case.

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


-Ilari

--001a114140ba2765080536cf5899-- From nobody Mon Jul 4 07:03:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7612B055 for ; Mon, 4 Jul 2016 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8ZIcxVcUgRe for ; Mon, 4 Jul 2016 07:03:16 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3957F12D0D9 for ; Mon, 4 Jul 2016 07:03:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 72A488620 for ; Mon, 4 Jul 2016 17:03:14 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id hzuVDogSTQpC for ; Mon, 4 Jul 2016 17:03:14 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1F7CA27B for ; Mon, 4 Jul 2016 17:03:14 +0300 (EEST) Date: Mon, 4 Jul 2016 17:03:12 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577A38A2.2090209@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:03:18 -0000 On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote: > Hi all, > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > > I have worked on a prototype implementation of DTLS 1.3 and if someone > else has something working by the time of the Hackathon in Berlin please > let me know. Taking a look: - The version field is described as identical to TLS 1.3 version field. What value is there actually? FCFE (wasn't that how "DTLS 1.0" was encoded on wire)? - Length and payload is is described as identical to version (which seems pretty odd...) - The PR talks about "rehandshake". I believe that concept no longer exists in TLS 1.3. - KeyUpdate does not work in DTLS. Might just use epochs for similar purpose, and reserve first few epochs for special purposes. - One could allow epochs to wrap (sequence number arithmetic). Won't cause nonce reuse due to different keys. - The PMTU section talks about block padding and compression. Neither exists anymore (there is padding, but the minimum expansion is exactly known, e.g. the 30 bytes for most ciphersuites). - The full handshake protocol is only run once. After that, there's only rekeying, new tickets and dynamic reauth. - There's special case with cookies: DTLS 1.3 ClientHello getting rejected with HelloVerifyRequest. I think the correct reaction is for client to send a DTLS 1.3 ClientHello without 0-RTT data, containing the cookie sent now in legacy cookie field (NOT the extension). - According to TLS 1.3 rules, handshakes rejected using HelloRetryRequest use the Cookie extension for cookie transmitback, not the legacy cookie field (the cookie might not even fit into that field!) - If handshake is rejected using HelloRetryRequest, according to the TLS 1.3 rules, the first ClientHello and HelloRetryRequest ARE included in handshake hashes. - Is the DTLS 1.2 written as 0303 on the wire? I seem to remember it would be FCFC (but I could be wrong about that)? If it is not 0303, then DTLS 1.3 is not going to be 0304... - In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT handshake messages are). This brings all sorts of "fun" with message reordering and loss. - The handshake retransmit scheme doesn't seem to work that well with post-handshake auth, and even less well with session tickets. -Ilari From nobody Mon Jul 4 07:06:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E81512D0C1 for ; Mon, 4 Jul 2016 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcqGgN61mSR1 for ; Mon, 4 Jul 2016 07:06:29 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5D41212B055 for ; Mon, 4 Jul 2016 07:06:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5036B7BBB; Mon, 4 Jul 2016 17:06:28 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id q76Cfwh8VyhP; Mon, 4 Jul 2016 17:06:27 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DBB9721C; Mon, 4 Jul 2016 17:06:27 +0300 (EEST) Date: Mon, 4 Jul 2016 17:06:25 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi> References: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] PR #23 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:06:32 -0000 On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: > Hi > > Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR. > > https://github.com/tlswg/rfc4492bis/pull/23 > > If there are no objections, I will accept it and submit version -08 this Friday. While scanning through, I noticed that the Ed25519 and Ed448 "curves" are still there. I think negotiating those should be done the same way as in TLS 1.3 (those would then appear as hash=7 signature=3/4 IIRC). -Ilari From nobody Mon Jul 4 07:59:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CA412D124 for ; Mon, 4 Jul 2016 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6Yci7yQc3Ah for ; Mon, 4 Jul 2016 07:59:11 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 BAE1D12D0F9 for ; Mon, 4 Jul 2016 07:59:10 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id r201so119001364wme.1 for ; Mon, 04 Jul 2016 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LH5DzTKeFZZzfrQL/0yR1fMESPufk7hfZexlkGSLwbQ=; b=Xd2TeF4NDpePovjU4mmvas86tpgR+cLUWQk1Zt/HkEPGM8U5LtpL9hDN8Bc2X6wY/m +TczNzK0G/bmyvjdQdOl2X7H6uViIf1McAly+hxBJ/EV2jbL5utyKev4KmnoqUKqFSOX L/IJcHQ+MgQaDOwF3ElxtFnv0GVXm9lpLRhGmt//XhYKakvibjOaJdOm/meSDiVnA1EQ ODzROzKGhmLhXKxSDuidmzjUcVl+A66B3CiUR+e58PUfT7SKumXzHo33X6lvAHreHnsO 4vlnh0IUjjek0LC22HIpzxdnISUyl+D2BQpPfBj2dWHgjao8yxURG/Crf8jEWHKRepvv IL5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LH5DzTKeFZZzfrQL/0yR1fMESPufk7hfZexlkGSLwbQ=; b=gXxC/D39KcD6fBsxFzpQj7deQ0TwZ6AzW2u4n3+LqaS1Y67bdwj8X2sFUcJMRRtAMa 43Xbmu++bROcS3FQDEUbNKtj5oj5ZHoHik5yK5gWgbUoablhPU/lN7GDC9jshaD2mtDS gpcCLa5lxHUAL9wXwp6jAV7A7KGJV0VRCBaqoMYANtogU/OvJzEq2BmNsk60kEPD3LlX 570ZhWSmnuOodrAbgFPagklh088+jycBcQywe7q6YftS158naO9rNeUuDOglZzZjPJbm uHBRU8wP9fPCICJDRkMZ8j3+Vg3/SkbdrG42VLP3Ykhp2bO1Q32c7K7iChWUQa7CEzPc SpOw== X-Gm-Message-State: ALyK8tK0X814UApOZtxHBfDlDL6SNlGfy9/yQZnsIn+6AVs9Vaz6OinJj1IU04wK7NgIBA== X-Received: by 10.194.236.195 with SMTP id uw3mr12856240wjc.149.1467644349254; Mon, 04 Jul 2016 07:59:09 -0700 (PDT) Received: from [172.24.249.249] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 12sm2952477wmj.19.2016.07.04.07.59.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 07:59:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 4 Jul 2016 17:59:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] PR #23 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:59:13 -0000 > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara = wrote: >=20 > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: >> Hi >>=20 >> Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80=99ve = submitted a PR. >>=20 >> https://github.com/tlswg/rfc4492bis/pull/23 >>=20 >> If there are no objections, I will accept it and submit version -08 = this Friday. >=20 > While scanning through, I noticed that the Ed25519 and Ed448 "curves" > are still there. I think negotiating those should be done the same way > as in TLS 1.3 (those would then appear as hash=3D7 signature=3D3/4 = IIRC). IMO this makes it very complex. TLS 1.3 replaces the old = signature_algorithms extension that had pairs of signature = algorithm/hash algorithm with one that has 16-bit values. It changes things for ECDSA as well. We=E2=80=99re not going to change = ECDSA in TLS 1.2. So if we wanted to adopt that we would still interpret = 0x04,0x03 as ECDSA (with whatever curve) along with SHA-256, while = 0x07,0x03 would be Ed25519, not ECDSA with some unknown hash function = 0x07. Seems strange to me, but I=E2=80=99ll make whatever changes the group = wants. Yoav From nobody Mon Jul 4 09:12:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C725B12D1AE for ; Mon, 4 Jul 2016 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4-zvC9KlWNW for ; Mon, 4 Jul 2016 09:12:17 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FAC12D18C for ; Mon, 4 Jul 2016 09:12:17 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id s63so155005931ioi.3 for ; Mon, 04 Jul 2016 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WNR31xpe18Xw4j+9JkZpytZ3R31wGtya8Ijdl5MTCgw=; b=gL/t4F/sa+X30vTLQgmzxTl3VnW7Z79dHgLvppgeYwSmZb/kNnT0i8jM6904CaKtmv pFVLtvm8CLz7NKuz/tAWyeD37Z5ezNyB/2rO4jwp+QZsZ4Mcy0evjFN2ypy7oEfNPzhG ulevVnqIdlVvfV33sgFdpTd8QX/9Y4e05muSw= 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; bh=WNR31xpe18Xw4j+9JkZpytZ3R31wGtya8Ijdl5MTCgw=; b=KXaynehA45RV63zzgi02eNXFGGP7VPLIcqvpVxdKejFG+zX7E3hT1lO9gL3nr8Cmkm aOZM4d/lTEX2ifdO4jZu/WGNp71kXqPv3PE2eWG61JkKcbI5UA1W9Tf1shXvfXzFlhtz Rh26cW3EPr2v7VmtsjbgRFGI7jJ6Vr9a4E5Cozb8TQnX1cCoAFbH3ya5pySSEE5ShOic a4KZuztdu+w5rxZRpjtZUwZhdArdfTICd9IZIW8cLWuHRs5XiSFiSu/c8f/YUO2CLrM8 355js/ulFqBzAiAW3AQ/TSxF/0rG3u+s6Ev1fuV131NLo6mWCKz2iUFo1lFNse2A4s/a P2vQ== X-Gm-Message-State: ALyK8tLXoemo8AFQbyFpFLPlAYzI/zA6LlUjgR3OqaW+bJsEzXZwhSc3OTeUdmrViYGxhu8Ra3N1+Y/UgmuYoptp X-Received: by 10.107.13.82 with SMTP id 79mr10509084ion.97.1467648736683; Mon, 04 Jul 2016 09:12:16 -0700 (PDT) MIME-Version: 1.0 References: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Mon, 04 Jul 2016 16:12:06 +0000 Message-ID: To: Yoav Nir , Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113fdb5e9b36c80536d19911 Archived-At: Cc: "" Subject: Re: [TLS] PR #23 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:12:20 -0000 --001a113fdb5e9b36c80536d19911 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara > wrote: > > > > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: > >> Hi > >> > >> Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80=99ve = submitted > a PR. > >> > >> https://github.com/tlswg/rfc4492bis/pull/23 > >> > >> If there are no objections, I will accept it and submit version -08 > this Friday. > > > > While scanning through, I noticed that the Ed25519 and Ed448 "curves" > > are still there. I think negotiating those should be done the same way > > as in TLS 1.3 (those would then appear as hash=3D7 signature=3D3/4 IIRC= ). > > IMO this makes it very complex. TLS 1.3 replaces the old > signature_algorithms extension that had pairs of signature algorithm/hash > algorithm with one that has 16-bit values. > > It changes things for ECDSA as well. We=E2=80=99re not going to change EC= DSA in > TLS 1.2. So if we wanted to adopt that we would still interpret 0x04,0x03 > as ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 would = be > Ed25519, not ECDSA with some unknown hash function 0x07. > > Seems strange to me, but I=E2=80=99ll make whatever changes the group wan= ts. > Oops, I think I agreed to backport this at IETF 95 and completely forgot. Sorry about that! My bad. Although, thinking about it now, I'm not sure if we should bother. As you mention, it's weird since ECDSA still needs to be interpreted in the 1.2 style, despite being spelled in the 1.3 way. We'd also end up with the new scheme being defined in two places. It seems better to get X25519 / X448 out the door first as that has no prerequisites. X25519 in TLS already has running code today. Chrome ships it, and Google servers have it enabled. The 1.1.0 release of OpenSSL is also slated to have support. Ed25519 / Ed448, on the other hand, don't even have an embedding in X.509 yet (though hopefully the main question remaining will get resolved in curdle soon). Then there's the timeline for draft-irtf-cfrg-eddsa, which I'm not familiar with. New signature schemes also depend on CAs being willing to sign them which, for the web PKI, I expect will not be fast. Say= ing new signature schemes are only defined for 1.3 and up seems reasonable enough to me, though I suppose it depends on how the timelines for all the other drafts end up looking. David --001a113fdb5e9b36c80536d19911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 4,= 2016 at 7:59 AM Yoav Nir <ynir.i= etf@gmail.com> wrote:

> On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wro= te:
>
> On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote:
>> Hi
>>
>> Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80= =99ve submitted a PR.
>>
>> https://github.com/tlswg/rfc4492bis/pull/23<= br> >>
>> If there are no objections, I will accept it and submit version -0= 8 this Friday.
>
> While scanning through, I noticed that the Ed25519 and Ed448 "cur= ves"
> are still there. I think negotiating those should be done the same way=
> as in TLS 1.3 (those would then appear as hash=3D7 signature=3D3/4 IIR= C).

IMO this makes it very complex. TLS 1.3 replaces the old signature_algorith= ms extension that had pairs of signature algorithm/hash algorithm with one = that has 16-bit values.

It changes things for ECDSA as well. We=E2=80=99re not going to change ECDS= A in TLS 1.2. So if we wanted to adopt that we would still interpret 0x04,0= x03 as ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 woul= d be Ed25519, not ECDSA with some unknown hash function 0x07.

Seems strange to me, but I=E2=80=99ll make whatever changes the group wants= .

Oops, I think I agreed to backport th= is at IETF 95 and completely forgot. Sorry about that! My bad.
Although, thinking about it now, I'm not sure if we should= bother. As you mention, it's weird since ECDSA still needs to be inter= preted in the 1.2 style, despite being spelled in the 1.3 way. We'd als= o end up with the new scheme being defined in two places.

It seems better to get X25519 / X448 out the door first as that has no = prerequisites. X25519 in TLS already has running code today. Chrome ships i= t, and Google servers have it enabled. The 1.1.0 release of OpenSSL is also= slated to have support.

Ed25519 / Ed448, o= n the other hand, don't even have an embedding in X.509 yet (though hop= efully the main question remaining will get resolved in curdle soon). Then = there's the timeline for draft-irtf-cfrg-eddsa, which I'm not famil= iar with. New signature schemes also depend on CAs being willing to sign th= em which, for the web PKI, I expect will not be fast.=C2=A0Saying new signature schemes are only defined for 1.3 and u= p seems reasonable enough to me, though I suppose it depends on how the tim= elines for all the other drafts end up looking.

=
David
--001a113fdb5e9b36c80536d19911-- From nobody Mon Jul 4 11:23:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5560F128E19 for ; Mon, 4 Jul 2016 11:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCMV_q9e6Wip for ; Mon, 4 Jul 2016 11:23:37 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D53128E18 for ; Mon, 4 Jul 2016 11:23:37 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a66so125095336wme.0 for ; Mon, 04 Jul 2016 11:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gj1Y3NVNecWP2/GrpJwJiebFJxiaPdOkigk0ukFaP4w=; b=n+P4znwpM1MS9t//sbs+TMxU4enbMjuo9nnt/93nE27B/A53M4Yaj8NndQg4WVSYlI XDVB8BrgzxjIRwt27NBFljfoycnT7msHU7LEVIU5EI5Fgu+TFhD26EXaths/fhhqXD7r eQVX1FK6/R8NIQhRpnGVK+rgig+WDZA9kH9AGYGf/Z7YX+1Mwkfjbad6bVzpSFd8lgMQ YucTpWe1HiGJNxSEQGlJUhegHqPZFm36jWoBrV8ln8LKGhQeljO33MSSp/VT3KPj7blE jR0Csv213c4CqN6lmgntojQrbktsVWGhxNA2gy4+Lu4ZR6DZLKJ1vBuMYAYtXwI7txS9 ne1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Gj1Y3NVNecWP2/GrpJwJiebFJxiaPdOkigk0ukFaP4w=; b=hQMTPH1gxDSiBHeII74znbIzOeY9DJsFheoKdmA5FlUPBHz4eNqZz7cb24z25K2tqT wY2FuvlLooBZ84V6g0+MqPdRGszDNdxijWOfmW9dNOQYbakrV/CExfTEqAmuXsoiZp8+ KfOq3G4cu1w1X/Ty3gfKErkksc2JlzbktSSVDyG1e0u3gOp1++isxACUAOUOCelNS5zF J08BgmdZ5IjjgM+3Vmili4rQsP40Oh5jRxKFcQI7EgFyVFaBn6pxHzyT8W7I/sAUnOOH sJIKGrnG5/i7LkTwg1WMa1fySkkXF9l195vcKCt5deb3mHOA4SIOgIbd3KMsYqPRcKxn 3PIg== X-Gm-Message-State: ALyK8tKRiv2ScFijR9CiiyMlOgEhIxu0hrVZ7SPGhp2lr3HUFcJ8oQhQFKzXxhKvWQYtLQ== X-Received: by 10.28.157.199 with SMTP id g190mr12722826wme.2.1467656615571; Mon, 04 Jul 2016 11:23:35 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id zj2sm3404101wjb.25.2016.07.04.11.23.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 11:23:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E85DF5C-9DA0-4005-93F6-00499D691A15" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 4 Jul 2016 21:23:32 +0300 Message-Id: References: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com> <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi> To: David Benjamin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] PR #23 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:23:39 -0000 --Apple-Mail=_9E85DF5C-9DA0-4005-93F6-00499D691A15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Jul 2016, at 7:12 PM, David Benjamin = wrote: >=20 > On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir > wrote: >=20 > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara > wrote: > > > > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: > >> Hi > >> > >> Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80=99ve= submitted a PR. > >> > >> https://github.com/tlswg/rfc4492bis/pull/23 = > >> > >> If there are no objections, I will accept it and submit version -08 = this Friday. > > > > While scanning through, I noticed that the Ed25519 and Ed448 = "curves" > > are still there. I think negotiating those should be done the same = way > > as in TLS 1.3 (those would then appear as hash=3D7 signature=3D3/4 = IIRC). >=20 > IMO this makes it very complex. TLS 1.3 replaces the old = signature_algorithms extension that had pairs of signature = algorithm/hash algorithm with one that has 16-bit values. >=20 > It changes things for ECDSA as well. We=E2=80=99re not going to change = ECDSA in TLS 1.2. So if we wanted to adopt that we would still interpret = 0x04,0x03 as ECDSA (with whatever curve) along with SHA-256, while = 0x07,0x03 would be Ed25519, not ECDSA with some unknown hash function = 0x07. >=20 > Seems strange to me, but I=E2=80=99ll make whatever changes the group = wants. >=20 > Oops, I think I agreed to backport this at IETF 95 and completely = forgot. Sorry about that! My bad. >=20 > Although, thinking about it now, I'm not sure if we should bother. As = you mention, it's weird since ECDSA still needs to be interpreted in the = 1.2 style, despite being spelled in the 1.3 way. We'd also end up with = the new scheme being defined in two places. >=20 > It seems better to get X25519 / X448 out the door first as that has no = prerequisites. X25519 in TLS already has running code today. Chrome = ships it, and Google servers have it enabled. The 1.1.0 release of = OpenSSL is also slated to have support. >=20 > Ed25519 / Ed448, on the other hand, don't even have an embedding in = X.509 yet (though hopefully the main question remaining will get = resolved in curdle soon). Then there's the timeline for = draft-irtf-cfrg-eddsa, which I'm not familiar with. New signature = schemes also depend on CAs being willing to sign them which, for the web = PKI, I expect will not be fast. Saying new signature schemes are only = defined for 1.3 and up seems reasonable enough to me, though I suppose = it depends on how the timelines for all the other drafts end up looking. The CFRG draft is not the limiting factor. We=E2=80=99re waiting for = draft-ietf-curdle-pkix-00.=20 But honestly, I don=E2=80=99t think anyone is going to be issuing EdDSA = certificates any time soon. The commercial CAs have just recently = starting using ECDSA, and even for local CAs you generally don=E2=80=99t = use a new algorithm until every relying party in your environment = supports it. Yoav --Apple-Mail=_9E85DF5C-9DA0-4005-93F6-00499D691A15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Jul 2016, at 7:12 PM, David Benjamin <davidben@chromium.org> wrote:

On Mon, Jul 4, 2016 at = 7:59 AM Yoav Nir <ynir.ietf@gmail.com> wrote:

> = On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
> On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir = wrote:
>> Hi
>>
>> Based on an email exchange with Nikos = Mavrogiannopoulos, I=E2=80=99ve submitted a PR.
>>
>> https://github.com/tlswg/rfc4492bis/pull/23
>>
>> If there are no objections, I = will accept it and submit version -08 this Friday.
>
> While scanning through, I noticed that the Ed25519 and = Ed448 "curves"
> are still there. I think negotiating = those should be done the same way
> as in TLS 1.3 = (those would then appear as hash=3D7 signature=3D3/4 IIRC).

IMO this makes it very complex. TLS 1.3 = replaces the old signature_algorithms extension that had pairs of = signature algorithm/hash algorithm with one that has 16-bit values.

It changes things for ECDSA as well. We=E2=80=99= re not going to change ECDSA in TLS 1.2. So if we wanted to adopt that = we would still interpret 0x04,0x03 as ECDSA (with whatever curve) along = with SHA-256, while 0x07,0x03 would be Ed25519, not ECDSA with some = unknown hash function 0x07.

Seems strange = to me, but I=E2=80=99ll make whatever changes the group wants.

Oops, I think I agreed to backport this at IETF 95 and = completely forgot. Sorry about that! My bad.

Although, thinking about it now, I'm = not sure if we should bother. As you mention, it's weird since ECDSA = still needs to be interpreted in the 1.2 style, despite being spelled in = the 1.3 way. We'd also end up with the new scheme being defined in two = places.

It seems better to get X25519 / = X448 out the door first as that has no prerequisites. X25519 in TLS = already has running code today. Chrome ships it, and Google servers have = it enabled. The 1.1.0 release of OpenSSL is also slated to have = support.

Ed25519 / Ed448, on the other hand, don't even have an = embedding in X.509 yet (though hopefully the main question remaining = will get resolved in curdle soon). Then there's the timeline for = draft-irtf-cfrg-eddsa, which I'm not familiar with. New signature = schemes also depend on CAs being willing to sign them which, for the web = PKI, I expect will not be fast. Saying new signature schemes are only defined for 1.3 and up = seems reasonable enough to me, though I suppose it depends on how the = timelines for all the other drafts end up = looking.

The CFRG draft is not the limiting factor. = We=E2=80=99re waiting for draft-ietf-curdle-pkix-00. 

But honestly, I don=E2=80=99= t think anyone is going to be issuing EdDSA certificates any time soon. = The commercial CAs have just recently starting using ECDSA, and even for = local CAs you generally don=E2=80=99t use a new algorithm until every = relying party in your environment supports it.

Yoav

= --Apple-Mail=_9E85DF5C-9DA0-4005-93F6-00499D691A15-- From nobody Mon Jul 4 12:52:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D4312B036 for ; Mon, 4 Jul 2016 12:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLQ9A34zPW37 for ; Mon, 4 Jul 2016 12:52:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 6763012D103 for ; Mon, 4 Jul 2016 12:45:41 -0700 (PDT) Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1bTOtD3PyI-011REi; Mon, 04 Jul 2016 21:45:38 +0200 To: Ilari Liusvaara , tls@ietf.org References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577ABCE2.9050409@gmx.net> Date: Mon, 4 Jul 2016 21:45:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mawu5nNkdNFNh07IM9jsap6c5v9GUXj7t" X-Provags-ID: V03:K0:bWT03j6ijfIqG/LUYI/tgJ283pbGxLeIrbExghvAT657rc/dB/i p8rznHhRc2ITjpC2I8LdQ+rHzUNq0GdJnGS345C4q+xpVb2UWz8Fg5RwmiOpa3g8ITqBJDu Xp2MjGQUmvzAC5SrWXai/XCISG3DKJ9CTBWbcPGwb71qe0q7AmtO+kUOjl8fBaNYK6va82l S0xARpswULlYqPZXw4e9g== X-UI-Out-Filterresults: notjunk:1;V01:K0:3c5KNXewKgg=:0fJjlhVpmh+VtlOzsFp5pU ZTV/Oj/HOoDMCcoOinnFfVydE/6WCFR1t+4u69Yj/UwE1xC8VlRpHCuZ2XvI1cdxO93/MpI/h F1rGcQu3auAs/g37lQRtkuccxeUblva7MeuaOFmi34hHGY6R+JKm0VINmaCOYVmQ5NSivgf0r WQRiuxWSRIq+R8xxSVYR2uHqM+uAmyGLc/ABiVX45Bkq/dI4piTTzTAVQpRKKZZ/E7fcrMfNJ ZhtAH4EteEFw27WRMUxYfeuUbzRU/7rJ8Pq8FWJVGb78zXlMbgUS7Sg0PnGqSlToYkn5AgHGj DyNWR1RYri2ObcIMJNQFFYFsbbMP+Ew26BdXKNuPp6I6TuD2FVh9XQxZISz6XK9d/MFdI9/lU RwDdQ0h8O3oOXXpydo/fTdKe9Z8ru2xApYz3waXrUe4zJ2xM1EQAgeouOeWg1B4SBhsdl0yBn Hr5i/NC7q/2E/BxbwfzbdJC54sqPQCjEZJr6V1pwYPw7eiRNZ/OKtqZbZXM43kmcOxzfWHbtk PRPBGbwROm/QhcUOH/jWg8LEdBbwCQx++bfPd3FTrGG7FI/8SyniLUosPxtJYUGy6ZzQEPMV+ 1nZyHAodd6ToufJsxVNVAGS7H/nXQCHh5uybL1xuxdRxzoNhj72gc/gB1fKjPh1P6nhKKobLQ m/jM4HGIo4Nmnek9xOBk1iUDpKwn6CE7bAKzMPppbPvxL3441rAhkmIisvGD0O1REpAymU1lq UTeaJKVy2vnSi1PfcQZJ3vOP5PQGC6TeDVlK92qko/3CTpywfRj2sDpGUf8= Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:52:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mawu5nNkdNFNh07IM9jsap6c5v9GUXj7t Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ilari, thanks for your super quick response. On 07/04/2016 04:03 PM, Ilari Liusvaara wrote: > On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote: >> Hi all, >> >> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document= >> and you can find the result at https://github.com/tlswg/tls13-spec/pul= l/512 >> >> I have worked on a prototype implementation of DTLS 1.3 and if someone= >> else has something working by the time of the Hackathon in Berlin plea= se >> let me know. >=20 > Taking a look: >=20 > - The version field is described as identical to TLS 1.3 version field.= > What value is there actually? FCFE (wasn't that how "DTLS 1.0" was > encoded on wire)? For the record layer TLS 1.3 says that the version field is deprecated and ignored. I guess the same approach applies to DTLS 1.3. So, it probably doesn't matter what is really is. In DTLS 1.2 the version value was 254.253. For the client_version and server_version in the handshake I thought it would be fine to just re-use the TLS 1.3 version number. > - Length and payload is is described as identical to version (which > seems pretty odd...) Copy-and-paste mistake. Fixed. > - The PR talks about "rehandshake". I believe that concept no longer > exists in TLS 1.3. Updated the text and referred to the KeyUpdate where applicable. > - KeyUpdate does not work in DTLS. Might just use epochs for similar > purpose, and reserve first few epochs for special purposes. Could you explain in more detail why you think a key update does not work with DTLS? > - One could allow epochs to wrap (sequence number arithmetic). Won't > cause nonce reuse due to different keys.=20 I have no preference regarding this issue. > - The PMTU section talks about block padding and compression. Neither > exists anymore (there is padding, but the minimum expansion is > exactly known, e.g. the 30 bytes for most ciphersuites). Deleted sentence you mentioned. > - The full handshake protocol is only run once. After that, there's > only rekeying, new tickets and dynamic reauth. How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen.= > - There's special case with cookies: DTLS 1.3 ClientHello getting > rejected with HelloVerifyRequest. I think the correct reaction > is for client to send a DTLS 1.3 ClientHello without 0-RTT data, > containing the cookie sent now in legacy cookie field (NOT the > extension). > - According to TLS 1.3 rules, handshakes rejected using > HelloRetryRequest use the Cookie extension for cookie > transmitback, not the legacy cookie field (the cookie might not > even fit into that field!) Regarding the issue of where to send the cookie in the ClientHello there are two options. The first option is to use the cookie extension, and the second option is to use the DTLS 1.2 style where the cookie is placed in the ClientHello directly (without using an extension). My (weak) preference is to use the cookie extension also in the ClientHello. My main reason was the length mismatch between the DTLS 1.2 cookie extension (which is now in the legacy_cookie filed) and the cookie extension. The cookie extension has a max length of 2^16-1 bytes and the legacy_cookie extension only 2^8-1 bytes long. If the design of the ClientHello uses the legacy_cookie extension then the server has to take care that the cookie size does not exceed the 2^8-1 bytes. > - If handshake is rejected using HelloRetryRequest, according to > the TLS 1.3 rules, the first ClientHello and HelloRetryRequest > ARE included in handshake hashes. Fixed it but I am not sure that's a good idea unless the cookie carries that state information. With 255 bytes that's going to be difficult... > - Is the DTLS 1.2 written as 0303 on the wire? I seem to remember > it would be FCFC (but I could be wrong about that)? If it is > not 0303, then DTLS 1.3 is not going to be 0304... Are you referring to the version field? > - In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT > handshake messages are). This brings all sorts of "fun" with > message reordering and loss. That's certainly something to take a closer look at. I haven't implemented that part yet .... > - The handshake retransmit scheme doesn't seem to work that > well with post-handshake auth, and even less well with > session tickets. Why do you think so? Of course, unreliable transports creates inconvenience; is it that what you are referring to? Ciao Hannes >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --mawu5nNkdNFNh07IM9jsap6c5v9GUXj7t 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 iQEcBAEBCgAGBQJXerziAAoJEGhJURNOOiAti0IIAIwt9VeDMV1XF7viR/bMfxjQ aOKew93/wp7aevaKrsZ2YgNO2DvESY7kq7eTwqmSnuFMYrVsUoyW/5xEpEVG9o60 DZfBIL1w1jnT+sMDUW77eiSiySQ0kKnyEQAG73rmXcAdS6sltv8eSga50V0Vro5S Kg+/SvmWpW1mY3Fx6RIADY8jEUP8JBrF3AHjgEGp5oZoZlYfGBTk5ZRDEPMCU5Nt OVZL6z78yihWplUBFmczxYar+OPVTgCsd3nELG5HV5gjYWEYh/9bQ5sKnDRo8OfE KovDsIQJwODWLf9jTFId1u3QBvhM03Uu9hTcUGZrgFCYSUjXeaf4i6n02r90jNM= =O09p -----END PGP SIGNATURE----- --mawu5nNkdNFNh07IM9jsap6c5v9GUXj7t-- From nobody Mon Jul 4 12:54:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E648912B054 for ; Mon, 4 Jul 2016 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOXLQzuiK7Q8 for ; Mon, 4 Jul 2016 12:54:20 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D9D12B036 for ; Mon, 4 Jul 2016 12:54:20 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u64JsJwM026365 for ; Mon, 4 Jul 2016 15:54:19 -0400 Date: Mon, 4 Jul 2016 15:54:19 -0400 (EDT) From: Nikos Mavrogiannopoulos To: tls Message-ID: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> In-Reply-To: <577A38A2.2090209@gmx.net> References: <577A38A2.2090209@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.51.93] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: DTLS 1.3 Thread-Index: qXFm9j8wvxAxmyrQ4sJeMSuFMa9pIg== Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:54:22 -0000 ----- Original Message ----- > Hi all, > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > > I have worked on a prototype implementation of DTLS 1.3 and if someone > else has something working by the time of the Hackathon in Berlin please > let me know. May I recommend a more radical approach for DTLS? My experience with servers handling DTLS traffic from various clients is that the clients change IPs (while roaming) and incoming ports (due to firewall state timeout), making impossible for the server to map the encrypted incoming packets from unknown IP/port combinations to any particular handler (i.e., handling process/thread or logical handler). That is because an independently received DTLS record packet has no session identifying information. For that I'd like to propose the DTLS record format to include at least a 3-byte identifier which will allow servers to recognize streams coming from unknown sources. That would be similar to the SPI field in the ESP packets. That is, a format similar to: struct { ContentType type; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint24 id; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; where id is sent by the server to the client either via an extension, or by simply assuming that the client will copy and keep the ID seen at the server packets (it doesn't really matter that this ID is unprotected as it doesn't contribute nor affect the security in any way). regards, Nikos From nobody Mon Jul 4 13:46:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1EC12B017 for ; Mon, 4 Jul 2016 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IywGu5xlpnwE for ; Mon, 4 Jul 2016 13:46:08 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id CC2FD12D11A for ; Mon, 4 Jul 2016 13:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 1D8A58013 for ; Mon, 4 Jul 2016 23:46:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id OcscYk_yMWMO for ; Mon, 4 Jul 2016 23:46:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9032828E for ; Mon, 4 Jul 2016 23:46:05 +0300 (EEST) Date: Mon, 4 Jul 2016 23:46:03 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577ABCE2.9050409@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:46:10 -0000 On Mon, Jul 04, 2016 at 09:45:38PM +0200, Hannes Tschofenig wrote: > Hi Ilari, > > thanks for your super quick response. > > On 07/04/2016 04:03 PM, Ilari Liusvaara wrote: > > On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote: > >> Hi all, > >> > >> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > >> and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > >> > >> I have worked on a prototype implementation of DTLS 1.3 and if someone > >> else has something working by the time of the Hackathon in Berlin please > >> let me know. > > > > Taking a look: > > > > - The version field is described as identical to TLS 1.3 version field. > > What value is there actually? FCFE (wasn't that how "DTLS 1.0" was > > encoded on wire)? > > For the record layer TLS 1.3 says that the version field is deprecated > and ignored. I guess the same approach applies to DTLS 1.3. So, it > probably doesn't matter what is really is. In DTLS 1.2 the version value > was 254.253. Oh, it was that. Then I presume DTLS 1.0 was 254,255 (yup, checked the RFC). > For the client_version and server_version in the handshake I thought it > would be fine to just re-use the TLS 1.3 version number. I think that is not a good idea, and one should follow the pattern (which would give 254,252 for ClientHello/ServerHello). But for record version, reusing previous versions (either 254,255 or 254,253) should be fine. > > - KeyUpdate does not work in DTLS. Might just use epochs for similar > > purpose, and reserve first few epochs for special purposes. > > Could you explain in more detail why you think a key update does not > work with DTLS? That message is not idempotent (nor has it timely ACK). > > - The full handshake protocol is only run once. After that, there's > > only rekeying, new tickets and dynamic reauth. > > How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen. Well, certainly the main handshake only runs once per connection. > > - There's special case with cookies: DTLS 1.3 ClientHello getting > > rejected with HelloVerifyRequest. I think the correct reaction > > is for client to send a DTLS 1.3 ClientHello without 0-RTT data, > > containing the cookie sent now in legacy cookie field (NOT the > > extension). > > - According to TLS 1.3 rules, handshakes rejected using > > HelloRetryRequest use the Cookie extension for cookie > > transmitback, not the legacy cookie field (the cookie might not > > even fit into that field!) > > Regarding the issue of where to send the cookie in the ClientHello there > are two options. The first option is to use the cookie extension, and > the second option is to use the DTLS 1.2 style where the cookie is > placed in the ClientHello directly (without using an extension). > > My (weak) preference is to use the cookie extension also in the > ClientHello. My main reason was the length mismatch between the DTLS 1.2 > cookie extension (which is now in the legacy_cookie filed) and the > cookie extension. The cookie extension has a max length of 2^16-1 bytes > and the legacy_cookie extension only 2^8-1 bytes long. If the design of > the ClientHello uses the legacy_cookie extension then the server has to > take care that the cookie size does not exceed the 2^8-1 bytes. I think the obvious way is: - Cookies from HelloVerifyRequest go to legacy cookie field. - Cookies from HelloRetryRequest go to extension cookie field. If you don't do the first, you can't downnegotiate successfully. And if you don't do the second, you would have to have special case with cookie sizes (since HRR can transmit >255 byte cookie, which would be too big for legacy cookie). > > - If handshake is rejected using HelloRetryRequest, according to > > the TLS 1.3 rules, the first ClientHello and HelloRetryRequest > > ARE included in handshake hashes. > > Fixed it but I am not sure that's a good idea unless the cookie carries > that state information. With 255 bytes that's going to be difficult... Well, it can be larger than 255 bytes. And barring client sending large 0-RTT context (what are those anyway???), one can fit it into very few bytes (<16 should be possible with blank context). > > - Is the DTLS 1.2 written as 0303 on the wire? I seem to remember > > it would be FCFC (but I could be wrong about that)? If it is > > not 0303, then DTLS 1.3 is not going to be 0304... > > Are you referring to the version field? Yeah, CH/SH version field. And DTLS was FEFD... > > - In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT > > handshake messages are). This brings all sorts of "fun" with > > message reordering and loss. > > That's certainly something to take a closer look at. I haven't > implemented that part yet .... Yeah, I haven't really taken a closer look at it either... > > - The handshake retransmit scheme doesn't seem to work that > > well with post-handshake auth, and even less well with > > session tickets. > Why do you think so? Of course, unreliable transports creates > inconvenience; is it that what you are referring to? DTLS assumes handshake messages are reliable, and that reliability is implemented via handshake messages ACKing one another. - Session tickets have no ACK at all. - CertificateRequest can have very slow ACK. - KeyUpdate has no real ACK (and isn't idempotent either). -Ilari From nobody Mon Jul 4 13:51:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8B12D124 for ; Mon, 4 Jul 2016 13:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQQO93F8uzmn for ; Mon, 4 Jul 2016 13:51:17 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3712D11A for ; Mon, 4 Jul 2016 13:51:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id F3E578029 for ; Mon, 4 Jul 2016 23:51:16 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id rFZGROe-nj4h for ; Mon, 4 Jul 2016 23:51:16 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8BC3C2316 for ; Mon, 4 Jul 2016 23:51:16 +0300 (EEST) Date: Mon, 4 Jul 2016 23:51:14 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160704205114.GB4837@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:51:19 -0000 On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > Hi all, > > > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > > and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > > > > I have worked on a prototype implementation of DTLS 1.3 and if someone > > else has something working by the time of the Hackathon in Berlin please > > let me know. > > May I recommend a more radical approach for DTLS? My experience with servers > handling DTLS traffic from various clients is that the clients change IPs (while > roaming) and incoming ports (due to firewall state timeout), making impossible > for the server to map the encrypted incoming packets from unknown IP/port combinations > to any particular handler (i.e., handling process/thread or logical handler). That > is because an independently received DTLS record packet has no session identifying > information. I think in DTLS 1.2, that was meant to be handled at lower layer (of course, often there isn't such layer even when needed). > For that I'd like to propose the DTLS record format to include at least a > 3-byte identifier which will allow servers to recognize streams coming from unknown > sources. That would be similar to the SPI field in the ESP packets. That is, > a format similar to: One can't change the headers in ClientHello/ServerHello and expect to remain backwards compatible. And how would that identifier be assigned? 0 in ClientHello, then copy whatever the server sends? -Ilari From nobody Mon Jul 4 13:56:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358FC12D124 for ; Mon, 4 Jul 2016 13:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5xftGvLsOhq for ; Mon, 4 Jul 2016 13:56:42 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE0312D126 for ; Mon, 4 Jul 2016 13:56:41 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id i12so47042164ywa.1 for ; Mon, 04 Jul 2016 13:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3r5b5e8/RmXxQRKziPwJNpAvbNYgpfzy65aLPgCcEwI=; b=DH+04QjWuin4uhZqE93kc6eG5UlbhVV2e6GwH1UiOU/KAt0wj0PkgrceTxY7OXHdQq dvZVvFYgKNM+82PYpvqpp2CfJnsNnht5lDvvmznVdcv70Z49pXhCMb6JKI4Iw7N9K0Hj VGsqKsg8jztVVhmJ0LPiL+jS7nK8wOPM/k9KD0WLL+zS82dmif91DglkEJet5OSwcbLg kFO+od+zNfLt9ywUzw5SVmohv94mAFWHNF6UPzdALWahhHyl05ePaU8ePpEvj2boQrAg HXIEVzrM9hMcYDpWSNmqRlk1Ee8d+vUZ2+0UzpUuB1OA5qu1CbS8qQaOOKWqDc0TBHmH InWQ== 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; bh=3r5b5e8/RmXxQRKziPwJNpAvbNYgpfzy65aLPgCcEwI=; b=VsmZktZo/9+JDP/UcQDP1R2E8VWm3l0gMjvKCHzf9CVDJT48BltAElbrNzROqfJJx1 Bd/+91d9r+VUFTZN78uDV1b8i6arP1mqQQPCCAHJSRWcQ/6Mb+eLfRwSzVtqJmhEx+Hd VZoUiL+Op92H9JlnEUZuU3hpcvDMnRx2oymJrA/i9Rx6/12iXxfN1VqvfLcuEQyNucko LICogGi1oeeGuawtwQzsdRfJREk3l1xhxd1JOoeUeiUTAzVBtKGioL1P4GZfS95nIBFM JHgjBvTRXzdpJpUr4MjxXKUykT0KO4NDe0jJJQFM8SM0XMOiwx+UpQ5uM8sDpLFHUubM qpjg== X-Gm-Message-State: ALyK8tJ7dmZwabxHHXXWAe4NhuLvybNjVAXyGGM/xcsrsIyTMIa3hednaKtAv/LFO96VqzTIhcAwi6yIRibZxg== X-Received: by 10.37.70.2 with SMTP id t2mr5948230yba.82.1467665801262; Mon, 04 Jul 2016 13:56:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Mon, 4 Jul 2016 13:56:01 -0700 (PDT) In-Reply-To: <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 4 Jul 2016 13:56:01 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113c53ecbbe8af0536d59294 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:56:44 -0000 --001a113c53ecbbe8af0536d59294 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 4, 2016 at 1:46 PM, Ilari Liusvaara wrote: > On Mon, Jul 04, 2016 at 09:45:38PM +0200, Hannes Tschofenig wrote: > > Hi Ilari, > > > > thanks for your super quick response. > > > > On 07/04/2016 04:03 PM, Ilari Liusvaara wrote: > > > On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote: > > >> Hi all, > > >> > > >> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > > >> and you can find the result at > https://github.com/tlswg/tls13-spec/pull/512 > > >> > > >> I have worked on a prototype implementation of DTLS 1.3 and if someone > > >> else has something working by the time of the Hackathon in Berlin > please > > >> let me know. > > > > > > Taking a look: > > > > > > - The version field is described as identical to TLS 1.3 version field. > > > What value is there actually? FCFE (wasn't that how "DTLS 1.0" was > > > encoded on wire)? > > > > For the record layer TLS 1.3 says that the version field is deprecated > > and ignored. I guess the same approach applies to DTLS 1.3. So, it > > probably doesn't matter what is really is. In DTLS 1.2 the version value > > was 254.253. > > Oh, it was that. Then I presume DTLS 1.0 was 254,255 (yup, checked the > RFC). > > > For the client_version and server_version in the handshake I thought it > > would be fine to just re-use the TLS 1.3 version number. > > I think that is not a good idea, and one should follow the pattern (which > would give 254,252 for ClientHello/ServerHello). > > But for record version, reusing previous versions (either 254,255 or > 254,253) should be fine. > > > > - KeyUpdate does not work in DTLS. Might just use epochs for similar > > > purpose, and reserve first few epochs for special purposes. > > > > Could you explain in more detail why you think a key update does not > > work with DTLS? > > That message is not idempotent (nor has it timely ACK). > > > > - The full handshake protocol is only run once. After that, there's > > > only rekeying, new tickets and dynamic reauth. > > > > How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen. > > Well, certainly the main handshake only runs once per connection. > > > > - There's special case with cookies: DTLS 1.3 ClientHello getting > > > rejected with HelloVerifyRequest. I think the correct reaction > > > is for client to send a DTLS 1.3 ClientHello without 0-RTT data, > > > containing the cookie sent now in legacy cookie field (NOT the > > > extension). > > > - According to TLS 1.3 rules, handshakes rejected using > > > HelloRetryRequest use the Cookie extension for cookie > > > transmitback, not the legacy cookie field (the cookie might not > > > even fit into that field!) > > > > Regarding the issue of where to send the cookie in the ClientHello there > > are two options. The first option is to use the cookie extension, and > > the second option is to use the DTLS 1.2 style where the cookie is > > placed in the ClientHello directly (without using an extension). > > > > My (weak) preference is to use the cookie extension also in the > > ClientHello. My main reason was the length mismatch between the DTLS 1.2 > > cookie extension (which is now in the legacy_cookie filed) and the > > cookie extension. The cookie extension has a max length of 2^16-1 bytes > > and the legacy_cookie extension only 2^8-1 bytes long. If the design of > > the ClientHello uses the legacy_cookie extension then the server has to > > take care that the cookie size does not exceed the 2^8-1 bytes. > > I think the obvious way is: > > - Cookies from HelloVerifyRequest go to legacy cookie field. > - Cookies from HelloRetryRequest go to extension cookie field. > > If you don't do the first, you can't downnegotiate successfully. And > if you don't do the second, you would have to have special case with > cookie sizes (since HRR can transmit >255 byte cookie, which would be > too big for legacy cookie). > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send HRR. > > - The handshake retransmit scheme doesn't seem to work that > > > well with post-handshake auth, and even less well with > > > session tickets. > > Why do you think so? Of course, unreliable transports creates > > inconvenience; is it that what you are referring to? > > DTLS assumes handshake messages are reliable, and that reliability is > implemented via handshake messages ACKing one another. > > - Session tickets have no ACK at all. > DTLS 1.3 should add an ACK, IMO. > - CertificateRequest can have very slow ACK. > - KeyUpdate has no real ACK (and isn't idempotent either). > Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch instead. -Ekr > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113c53ecbbe8af0536d59294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 4, 2016 at 1:46 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Mon, Jul 04, 2016 at 09:45:38PM +0200, Hannes Tschofenig wrote:=
> Hi Ilari,
>
> thanks for your super quick response.
>
> On 07/04/2016 04:03 PM, Ilari Liusvaara wrote:
> > On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote= :
> >> Hi all,
> >>
> >> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3= document
> >> and you can find the result at https://git= hub.com/tlswg/tls13-spec/pull/512
> >>
> >> I have worked on a prototype implementation of DTLS 1.3 and i= f someone
> >> else has something working by the time of the Hackathon in Be= rlin please
> >> let me know.
> >
> > Taking a look:
> >
> > - The version field is described as identical to TLS 1.3 version = field.
> >=C2=A0 =C2=A0What value is there actually? FCFE (wasn't that h= ow "DTLS 1.0" was
> >=C2=A0 =C2=A0encoded on wire)?
>
> For the record layer TLS 1.3 says that the version field is deprecated=
> and ignored. I guess the same approach applies to DTLS 1.3. So, it
> probably doesn't matter what is really is. In DTLS 1.2 the version= value
> was 254.253.

Oh, it was that. Then I presume DTLS 1.0 was 254,255 (yup, checked t= he
RFC).

> For the client_version and server_version in the handshake I thought i= t
> would be fine to just re-use the TLS 1.3 version number.

I think that is not a good idea, and one should follow the pattern (= which
would give 254,252 for ClientHello/ServerHello).

But for record version, reusing previous versions (either 254,255 or
254,253) should be fine.

> > - KeyUpdate does not work in DTLS. Might just use epochs for simi= lar
> >=C2=A0 =C2=A0purpose, and reserve first few epochs for special pur= poses.
>
> Could you explain in more detail why you think a key update does not > work with DTLS?

That message is not idempotent (nor has it timely ACK).

> > - The full handshake protocol is only run once. After that, there= 's
> >=C2=A0 =C2=A0only rekeying, new tickets and dynamic reauth.
>
> How TLS 1.3/DTLS 1.3 is used in specific environments remains to be se= en.

Well, certainly the main handshake only runs once per connection.
> > - There's special case with cookies: DTLS 1.3 ClientHello get= ting
> >=C2=A0 =C2=A0rejected with HelloVerifyRequest. I think the correct= reaction
> >=C2=A0 =C2=A0is for client to send a DTLS 1.3 ClientHello without = 0-RTT data,
> >=C2=A0 =C2=A0containing the cookie sent now in legacy cookie field= (NOT the
> >=C2=A0 =C2=A0extension).
> > - According to TLS 1.3 rules, handshakes rejected using
> >=C2=A0 =C2=A0HelloRetryRequest use the Cookie extension for cookie=
> >=C2=A0 =C2=A0transmitback, not the legacy cookie field (the cookie= might not
> >=C2=A0 =C2=A0even fit into that field!)
>
> Regarding the issue of where to send the cookie in the ClientHello the= re
> are two options. The first option is to use the cookie extension, and<= br> > the second option is to use the DTLS 1.2 style where the cookie is
> placed in the ClientHello directly (without using an extension).
>
> My (weak) preference is to use the cookie extension also in the
> ClientHello. My main reason was the length mismatch between the DTLS 1= .2
> cookie extension (which is now in the legacy_cookie filed) and the
> cookie extension. The cookie extension has a max length of 2^16-1 byte= s
> and the legacy_cookie extension only 2^8-1 bytes long. If the design o= f
> the ClientHello uses the legacy_cookie extension then the server has t= o
> take care that the cookie size does not exceed the 2^8-1 bytes.

I think the obvious way is:

- Cookies from HelloVerifyRequest go to legacy cookie field.
- Cookies from HelloRetryRequest go to extension cookie field.

If you don't do the first, you can't downnegotiate successfully. An= d
if you don't do the second, you would have to have special case with cookie sizes (since HRR can transmit >255 byte cookie, which would be too big for legacy cookie).

IMO we shou= ld just forbid HVR for DTLS 1.3. I.e., you should just send
HRR.<= /div>


> > - The handshake retransmit scheme doesn't seem to work that > >=C2=A0 =C2=A0well with post-handshake auth, and even less well wit= h
> >=C2=A0 =C2=A0session tickets.
> Why do you think so? Of course, unreliable transports creates
> inconvenience; is it that what you are referring to?

DTLS assumes handshake messages are reliable, and that reliability i= s
implemented via handshake messages ACKing one another.

- Session tickets have no ACK at all.

D= TLS 1.3 should add an ACK, IMO.

=C2=A0
- CertificateRequest can have very slow ACK.
- KeyUpdate has no real ACK (and isn't idempotent either).

Yes, I think we should remove KeyUpdate for DTLS 1.= 3 and just use epoch instead.

-Ekr

<= /div>



-Ilari

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

--001a113c53ecbbe8af0536d59294-- From nobody Mon Jul 4 14:07:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2537512D536 for ; Mon, 4 Jul 2016 14:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6twcuGMmrd9 for ; Mon, 4 Jul 2016 14:07:30 -0700 (PDT) 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 E69D512D158 for ; Mon, 4 Jul 2016 14:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B5F0BE2C; Mon, 4 Jul 2016 22:07:28 +0100 (IST) 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 tyK3ZD2QIZ8b; Mon, 4 Jul 2016 22:07:26 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7014BBE25; Mon, 4 Jul 2016 22:07:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467666446; bh=cLKLMkwwgAorNdgP2etobmymAgziEKMm9n8gzs9AVzM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=abqOHx/rqeEsnrScgTzZDlLXrbNiUJwe8ZoTcodE6oJLQ8drvFrmlKHywmKh7swjX wpAlJmu5NwNucHWLA/xUoQX5EuOhC9aIV09Si6LI9iHpx+HZZnNTRQPZZ7sgZo8nHZ gklMiUOQytPX1NF0fJr6pbOIYsZozVOUOWq2gZis= To: Nikos Mavrogiannopoulos , tls References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577AD00E.1000103@cs.tcd.ie> Date: Mon, 4 Jul 2016 22:07:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080509080405000201000403" Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:07:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080509080405000201000403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: >=20 > where id is sent by the server to the client either via an extension, o= r > by simply assuming that the client will copy and keep the ID seen at th= e > server packets (it doesn't really matter that this ID is unprotected as= > it doesn't contribute nor affect the security in any way). Does that id need to be static? If so, then it'd act as an additional way to track a user roaming over different IP and ports. That'd be a pity. If such an id is useful, maybe there's a way to allow it to change as well, in a way predictable for the server. S. --------------ms080509080405000201000403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDQy MTA3MjZaMC8GCSqGSIb3DQEJBDEiBCDSDSUfE+Ejw/UAtLJ1npjaJodLs/6wCoI3fjQlUF+Q gDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAHJKoOifjA8VDBFhiAjMlvFyjN2z/bmVlTUnPrCW77d1IHKlDFWS4F tomVtO6ohcl2yS/IOuat1LbmF6ws3XxnR9OnYHnFrWFOaugbajkjWqquhTv4NmnM25NuqlYO nE96soqyS10gTKR3PJcnsn8gS/vhKgVjNNjE0d4u/9ra5air5xBs2HjB600iW6BZ6ZP7XPJX fuBKVXrDOs4Q3oCA/Q1n1nVBfcW3dUDdNPwGkg69Xfjq4jJUhSDVjjug+wlT40wXpA4FkBIf MFFLSsKYeUuwNKl9opoK2DqBR1UrT/+tWH/p7Y5uLnTz1qp6uyXBsbeifXxKWk11RTfpQUtw AAAAAAAA --------------ms080509080405000201000403-- From nobody Mon Jul 4 14:09:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400D12D53A for ; Mon, 4 Jul 2016 14:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yimZGYHsFLbE for ; Mon, 4 Jul 2016 14:09:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3B62112B036 for ; Mon, 4 Jul 2016 14:09:34 -0700 (PDT) Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MIu7d-1bIGNT1Tlx-002XkB; Mon, 04 Jul 2016 23:09:26 +0200 To: Nikos Mavrogiannopoulos , tls References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <577AD087.9000603@gmx.net> Date: Mon, 4 Jul 2016 23:09:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hL5HLB9Wp2Ekm6pwqweulOwoHEWhRHK6K" X-Provags-ID: V03:K0:UJjOq9G1IzFwZk+5JqJ/2/jft68Jz9EwRjzCOPBpYmm3gpXsRzN pGfcMMBXzsFjsKkvs2oRks0hCnvYnzdppNQrRS9VJTM+uA4FvoA1kx7rVVLGmoSa34KNcdl vH4vspjFf8sZLsmmiL7y+7KS+JY7IYb0ACUvOIM+jw1Fg32Dv+wMV4OsifweuIXcwTr3bly 89bN+LX4CcYOneIXXw1hg== X-UI-Out-Filterresults: notjunk:1;V01:K0:j8LuHA5n54U=:JeggfDvOE+r0EX4OaIH9k7 7wFmliCEpk1s84FpA1dzcz/Q3Vqe2CGU06cOG8u1LKv+JgGlas0qpyjv46i/QapaACKk0qqe/ LQ7vS2f5H2L+hpQLPWSt5ffiKZM+RmxL1p4peXTkaxhsisbuFJ18HE4dcOkQPaAgV9IKUPUJ2 WlDBTVAhtNxlJMnCyt2HIIBiccAeyvxM/03C4oUJ1h+SkIyYX9/t09XAr8kclAi1qDaX7SmVx fa4aQ6JNKoLTKq5tCpwR0NrvmAOkpfcG2/VzVOQT6hJVua1IVG28KSQwY4SXt6YL6yWEfHOsj WPXlRTRK3xwuZ29SAjrJC9iwTykNz2goqPzZzamQCLspGfZKl9ry1319VMKnCVQu3WiZGzzhY 9fEiesdDGbyOto6OvLyavCfd5EZ2wU7IL53asebMyt7chVQsFS7Or/2mvUxhd6Ch1s6HiR44m UiSQstpmyV4kpZY/XCDQxstWdJ8oLVV54r81KoE2sM1tWFc2IWPVCC0C7TP0C1sOh+4qizVhg iTPwQKHKH7KDIv4UtWkojHeYkus/PFALkEkbyvDM6106w64FKDoIhis5yf/W3G3IIEl46Ys+f NK4DArlSiJcfdzI7FojAY1YTaaJktNMwnBLWi61MeCU1zdjWYnf0MJUmrG/WIQDc6FvWA+wQ/ 3QyTm8Hiel5HYmjkfoKon59jrfN4sSQDpEs78hOY+joma+SBNzlSmW1QfFqC/MDD8kpXGaWgX Hf4e8C8Gr3Q7cwmaF+pOg0V2H/Gz9zfbb5Xn9PATUqeEVgXQR7kBPhKfD/I= Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:09:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hL5HLB9Wp2Ekm6pwqweulOwoHEWhRHK6K Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Nikos, when it comes to optimizing the record layer then it basically boils down to the question about how middleboxes react to this type of change. In the IoT context the story is a bit easier since there greenfield deployments with new radio technologies where these types of middleboxes are not yet there. For those environments more radical changes, as you and Thomas mentioned, are probably useful. Ciao Hannes On 07/04/2016 09:54 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> Hi all, >> >> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document= >> and you can find the result at https://github.com/tlswg/tls13-spec/pul= l/512 >> >> I have worked on a prototype implementation of DTLS 1.3 and if someone= >> else has something working by the time of the Hackathon in Berlin plea= se >> let me know. >=20 > May I recommend a more radical approach for DTLS? My experience with se= rvers > handling DTLS traffic from various clients is that the clients change I= Ps (while > roaming) and incoming ports (due to firewall state timeout), making imp= ossible > for the server to map the encrypted incoming packets from unknown IP/po= rt combinations > to any particular handler (i.e., handling process/thread or logical han= dler). That > is because an independently received DTLS record packet has no session = identifying > information. >=20 > For that I'd like to propose the DTLS record format to include at least= a > 3-byte identifier which will allow servers to recognize streams coming = from unknown > sources. That would be similar to the SPI field in the ESP packets. Tha= t is, > a format similar to: >=20 > struct { > ContentType type; > ProtocolVersion record_version =3D { 3, 1 }; /* TLS v1.x *= / > uint24 id; > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; >=20 > where id is sent by the server to the client either via an extension, o= r > by simply assuming that the client will copy and keep the ID seen at th= e > server packets (it doesn't really matter that this ID is unprotected as= > it doesn't contribute nor affect the security in any way). >=20 > regards, > Nikos >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --hL5HLB9Wp2Ekm6pwqweulOwoHEWhRHK6K 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 iQEcBAEBCgAGBQJXetCHAAoJEGhJURNOOiAt+GYH/j1he1JLkjBkfWAd1uEEu/ug ybF3znDtCiB4WnY0UAcDvCepChTRPxfez5TvqXwJ9NzdqoNm3q5L88Xr+mCziDuS mW13A4nnFTxoYF4jKY4s86IHyNRvAQBL6TS1Gs8HPHmDE/p7hX7j5OZ4J5YkiGmj J+7vMtjKkLWWu+Rztg8rM7ZcVwg0DEvhKzVkTVNPp/NC69Po1LZnRKi4SuOgR55y 1vGP/gvnac6rRegglhtKtFwSuqcy+IA00nxGORoPxGKLD6mm3pX31ewSEgReK8jz qMNt+rY+MkjnTDLUcCc4mzGnwoANnaJZN3+Ro1R22J+HFKu1rZautxv3K0Dqj5E= =Z/xw -----END PGP SIGNATURE----- --hL5HLB9Wp2Ekm6pwqweulOwoHEWhRHK6K-- From nobody Mon Jul 4 14:18:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2E212B036 for ; Mon, 4 Jul 2016 14:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRwjBnIlgX5t for ; Mon, 4 Jul 2016 14:18:10 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A95112B02F for ; Mon, 4 Jul 2016 14:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DA46A7E0F; Tue, 5 Jul 2016 00:18:07 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id DOLyQG4vj4Fx; Tue, 5 Jul 2016 00:18:07 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6DCAEC4; Tue, 5 Jul 2016 00:18:07 +0300 (EEST) Date: Tue, 5 Jul 2016 00:18:05 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:18:12 -0000 On Mon, Jul 04, 2016 at 01:56:01PM -0700, Eric Rescorla wrote: > On Mon, Jul 4, 2016 at 1:46 PM, Ilari Liusvaara > wrote: > > I think the obvious way is: > > > > - Cookies from HelloVerifyRequest go to legacy cookie field. > > - Cookies from HelloRetryRequest go to extension cookie field. > > > > If you don't do the first, you can't downnegotiate successfully. And > > if you don't do the second, you would have to have special case with > > cookie sizes (since HRR can transmit >255 byte cookie, which would be > > too big for legacy cookie). > > > > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send > HRR. Yes, DTLS 1.3 servers can't send HVR, but that doesn't mean DTLS 1.3 clients can't receive HVR (and then need to handle it somehow). And if downnegotiation is to be possible, then that way should be compatible with DTLS 1.2 (sticking the cookie into legacy cookie field and clearing the hash should be compatbile enough). > > > - The handshake retransmit scheme doesn't seem to work that > > > > well with post-handshake auth, and even less well with > > > > session tickets. > > > Why do you think so? Of course, unreliable transports creates > > > inconvenience; is it that what you are referring to? > > > > DTLS assumes handshake messages are reliable, and that reliability is > > implemented via handshake messages ACKing one another. > > > > - Session tickets have no ACK at all. > > > > DTLS 1.3 should add an ACK, IMO. Yeah, not going to work without. And I presume something might be needed for dynamic reauth too... > > - CertificateRequest can have very slow ACK. > > - KeyUpdate has no real ACK (and isn't idempotent either). > > > > Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch > instead. How many special epochs we need? 0 => Unencrypted messages 1 => 0-RTT control messages (just one finished[1]!) 2 => 0-RTT data messages 3 => primary handshake 4 => application data 5-N => rekey connection Would that be enough? Reserving epochs would clearly expose the 0-RTT records and the handshake through. Would solve the reordering with 0-RTT tho. And can epochs wrap around (this would not cause problems with nonce reuse, since keys are not going to match)? [1] Whereas in TLS 1.3 that finished seems pointless (you have a MAC to check anyway), now in DTLS if there are no 0-RTT handshake messages, there is no guarantee that any 0-RTT message is received, resulting no MAC to check. -Ilari From nobody Tue Jul 5 01:29:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6636612B013 for ; Tue, 5 Jul 2016 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wbE8V3xGZPC for ; Tue, 5 Jul 2016 01:29:25 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 477D912D0B4 for ; Tue, 5 Jul 2016 01:29:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 4C15C45C4; Tue, 5 Jul 2016 11:29:23 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id geydTCT9W2Wf; Tue, 5 Jul 2016 11:29:23 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 02CAB2315; Tue, 5 Jul 2016 11:29:23 +0300 (EEST) Date: Tue, 5 Jul 2016 11:29:20 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160705082920.GA9700@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:29:27 -0000 On Mon, Jul 04, 2016 at 01:56:01PM -0700, Eric Rescorla wrote: > > DTLS 1.3 should add an ACK, IMO. Some quick napkin^Wtext editor sketch: Handshake message type: acknowledge - DTLS 1.3 only, not TLS 1.3. - No retransmissions (transmitted once per trigger) - Triggered if a complete flight is received with: * session_ticket message by client * certificate_request message by client and the client can't quickly produce the authentication block[1] * finished message by server. - Contents: * Enumerated type: + SESSION_TICKET_RECEIVED + CERTIFICATE_REQUEST_IN_PROGRESS + CLIENT_FINISHED_RECEIVED * req_context: Certificate request context (CERTIFICATE_REQUEST_IN_PROGRESS only). The certficate_request case could occur during the handshake, it then would kill the server retransmit timer if received, having only the client hold the retransmit (after it has finished assembling the authentication block). This design can probably be improved quite a bit. [1] Including block that rejects the request. -Ilari From nobody Tue Jul 5 01:42:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D32812D18F for ; Tue, 5 Jul 2016 01:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDGSuUHGEgbT for ; Tue, 5 Jul 2016 01:42:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 8725312D188 for ; Tue, 5 Jul 2016 01:42:11 -0700 (PDT) Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ltqb7-1bU13z3XUr-011A9E; Tue, 05 Jul 2016 10:42:07 +0200 To: Ilari Liusvaara , Eric Rescorla References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577B72E0.4090102@gmx.net> Date: Tue, 5 Jul 2016 10:42:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DQLvE1C8FAINHTKUdj2mXRFUxOXHVfJ3b" X-Provags-ID: V03:K0:Po8QtaWN5HiTE7Rtntl4ROdGLmNxpEoNzFA5JEmeeo4rRFuMHS2 H6v9uiKKOHG/UWuQpc0UaPd0phrjzgxOhQV+SE2i/bdKP37y2fXUlKVTDVqEVG9KgyWILHc e4eb2SviK3Njuu0vWnlAAWsEcb/FQri1i0a0eYWxFA+uh3h6siokaryFxOsq6r7BEesKrkh e/jx0nR9CFtUum8xbi1Rg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lRWP9Tk2dq0=:v1rtgnE3YFGOyUE8Fooflz xdVtv+5zKYk6bYC6HiUC8/A/pQawvQnQQAg4NQH9Ga32VhrBgpL5OT3kZ81aPtYG4/RmPBBio QMWplKxCK8Ol9CnTqyODHOGyiROiPVj+U9gD6udSZP0Eqb/2RHB1ASxgH4IkxTB6uFcoFkiuD 4G/KbkbyddTm8TBcNNJ9dKcc/vzzsI45vQxIIZj9Y4yxVSoKqYPoV2zzNdJla0lHwra0NWZBL a0i+XVQnmEOC+MN9XrtS9143gjcZ5IiAb069e6TnE8pfTmsZZoPuhuU3AqzwSI7XMHQ8a8Mz2 iTTCC5JjCi/WEm0JzJsw2HGES4ai6JznFuGcwd25EaYYwKdzfiLKAoUn8qbHKE41YYSu/55FS 3UkcmFc02p1hbzhzHXUIsIkacECrEQiLTELyIB9eKvZmnwM5WM7mBowh31dm0Eh4BLqaVDEjJ fuUl1fc9hi3OF9MUTVxA8LjwRmnDLhsjwjvrSkApRyrP+MmSmhfE+mPxk998K57IIS0luD4Xb xbOzZH+6Wk8YttdkX26eQnUNR73zH1+mf99toYuO0ypfgi9BM+TU1pSv/ETy69ZaI/LgKR6Pn vIro0NXvegHcqx6K7Y1qvKdvHadzLeA9qyCLwx3RTgNdIJv3Zf0kZJvrVdkPqU+VyXUvOEtCe ZF/MOnI5grh1JHMRnTa1IGtrOTx9nq6xNp8XEs1KPMcyL3ENIoSABb3YEE94kmObfA1FAPnKH 5yKdTqaTblE3xWN+e9lQWywXtK4tQjCt0eBK5QETU541j2IT8eAMWQhBTDo= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:42:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DQLvE1C8FAINHTKUdj2mXRFUxOXHVfJ3b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ilari, On 07/04/2016 11:18 PM, Ilari Liusvaara wrote: >> > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just se= nd >> > HRR. > Yes, DTLS 1.3 servers can't send HVR, but that doesn't mean DTLS 1.3 > clients can't receive HVR (and then need to handle it somehow). >=20 > And if downnegotiation is to be possible, then that way should be > compatible with DTLS 1.2 (sticking the cookie into legacy cookie > field and clearing the hash should be compatbile enough). >=20 Consider the following three cases: * Client supports DTLS 1.2 / 1.3 but the server supports only DTLS 1.2. If the client starts the exchange with DTLS 1.3 then the server could return a HelloVerifyRequest as defined in DTLS 1.2 and the exchange can continue. For the client it is not a problem to deal with the HVR since it supports both stacks. * Client supports only DTLS 1.3 and server supports DTLS 1.2/1.3. Here the client starts with a DTLS 1.3 exchange and the server will only reply with a HelloRetryRequest as defined in TLS 1.3. It should bother dealing with the DTLS 1.2 functionality when interacting with a DTLS 1.3 client. * Client supports only DTLS 1.2 and the server supports DTLS 1.2/1.3. In this case, the client starts with the regular ClientHello and the server will determine based on the version that it has to proceed with DTLS 1.2. I believe that this could work fine. Ciao Hannes --DQLvE1C8FAINHTKUdj2mXRFUxOXHVfJ3b 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 iQEcBAEBCgAGBQJXe3LgAAoJEGhJURNOOiAteTgIAIKzRLVglZjNMiYb+AoV2fkC DQZvJwewVQAfOnMO56uUb6g0OMmbnkytosrRftOjisJWyiNISA2Db70/16bFGC55 yVKKVnR9gZ1mqrjNPEYsONyZap3uHNKdcC0TCf4tvYKRGcsly41cWjERNPSIPKWD yi1rv57AXp18CvVPNtN3GnWasR3sXhGQQ8loC3TdvIfpv6awwlZVoUlWliK7yGAv Pf0iA+ejz70AlCIQtsV1zTigUHyc4kqS7Nbrhz9Ds7BTKEwezkx85niPQAsroIPJ 4HEOR+JMUP6j5ybwM8U3Zm7y/NW4tKNWLF35b+V9MMetooymmrWTUIjSMS5LoKs= =b/Kh -----END PGP SIGNATURE----- --DQLvE1C8FAINHTKUdj2mXRFUxOXHVfJ3b-- From nobody Tue Jul 5 01:59:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B5912D0BA for ; Tue, 5 Jul 2016 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95oO7H1cIbxA for ; Tue, 5 Jul 2016 01:59:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 B7BEF12D0AB for ; Tue, 5 Jul 2016 01:59:11 -0700 (PDT) Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MBnSJ-1bBnDw3rE7-00Am8b; Tue, 05 Jul 2016 10:59:08 +0200 To: Eric Rescorla , Ilari Liusvaara References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577B76DE.9080003@gmx.net> Date: Tue, 5 Jul 2016 10:59:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m1hDxRWCLWJkvKunBpto3LdG1CoL6XMwT" X-Provags-ID: V03:K0:N4W142P1m2IJAK8oQU+lpnfEYBtsA/80c1mFz+ynyMFi0dYCBx1 jxE+YxtjwnVOn1IEm/qZBZDYZ7aapy22ozkJJbC7tRkXeZ82uSuPp4I7LCwuGi7TkWaqrPU z19LUjEfJIuvLD0k03xv0dtJwwaaJbMGImbw9t/+N/5zLYy9U/7mWPodSSqujyJgi9qGgtz hVSN9J8afqxpvkhvJ+y+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:8hJxGr1ccC0=:6FpQuvSO9KCOYVobD/JkQi 3Gp7zyHVuTGOEmZ6EFN0L3zm+SvKeAcqY5TUoiIxBgQ2FbIryb3oFeUZ0VfyDRfC21jo4CZBW JlaJ1v9emOcwBlH9LssXNvm8jrNmCQJqhumTwOCx4jtyROLFXmXbPxbQt3sah00FkZ4vMVlop EynkTOF4e5PtsnwJp2ZUiFWwIgf0wgBaGwlgKK5Xz9uUbcw2ij9W1PYTRaCO9BP2IBSTw+kYT nHqv6o0VXzCCpFlAYwtnta7wHYlSI2MOV/lL1xIKUOsTUz++mShWZ11px9d6ogTgb1lhu9BTf 0JWAVkp7aXEisGwG5qiTGgJJ1n/OTrFFXpmDpIY+4uB8fcHVdYzgjseqy1XLZ/91pyPqLlLrR zrT0eYDtrOP9MKo2RPHIgdIdShQTPBLiRl0n1AvafRtTkqkR2X5PHSAEyKEGQ4U5Mo0c+iwbE +oC5jEKug+l3w/JSn4HH+Ll3O0dvO0ZvADrB0Dxma3LQ9KDTMBUUTlxGnsvMB6uN21RQxg7s0 7rTqczXqG0YKt882b/jBtgmk38iB+LQ6y0+Xuj4Wm88s04eMaTp4rkWnn2PYhBlA6j01xM5CB zG5jqUdhm/Ov8ZgbkX1xQKqwzNGdLDs1p64ePdZieARqAzX2/d0qvmsZpUDdYXJAQlBbAfi3y mK8oCZixErVh3DxYYG2QnJdi2tP1p7p+yPCW+18tuc3WH+KLAN/vW6AUbxHuTmRxu1fK4y0tX YwTjRrYl7rcu8JYwEbI7+ygOdmk2B2iOR5t2CuFhLUcE5vj/Vabrf8+BSQE= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:59:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m1hDxRWCLWJkvKunBpto3LdG1CoL6XMwT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ekr, ~snip~ > I think the obvious way is: >=20 > - Cookies from HelloVerifyRequest go to legacy cookie field. > - Cookies from HelloRetryRequest go to extension cookie field. >=20 > If you don't do the first, you can't downnegotiate successfully. An= d > if you don't do the second, you would have to have special case wit= h > cookie sizes (since HRR can transmit >255 byte cookie, which would = be > too big for legacy cookie). >=20 >=20 > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send > HRR. That makes sense to me. Btw, Section 11 "IANA Considerations" says that the Cookie extension is encrypted in the HelloRetryRequest message. I wonder whether this is a mistake particularly in the combination where the server returns the cookie as part of the incorrect key share (and therefore does not yet have a key to create the EncryptedExtension). The table should also say that the cookie is also contained in the ClientHello (in clear, unless it is a 0-RTT handshake). >=20 >=20 > > > - The handshake retransmit scheme doesn't seem to work that > > > well with post-handshake auth, and even less well with > > > session tickets. > > Why do you think so? Of course, unreliable transports creates > > inconvenience; is it that what you are referring to? >=20 > DTLS assumes handshake messages are reliable, and that reliability = is > implemented via handshake messages ACKing one another. >=20 > - Session tickets have no ACK at all. >=20 >=20 > DTLS 1.3 should add an ACK, IMO. Sounds reasonable. >=20 > =20 >=20 > - CertificateRequest can have very slow ACK. > - KeyUpdate has no real ACK (and isn't idempotent either). >=20 >=20 > Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch= > instead. Ok. Ciao Hannes >=20 > -Ekr >=20 >=20 >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --m1hDxRWCLWJkvKunBpto3LdG1CoL6XMwT 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 iQEcBAEBCgAGBQJXe3beAAoJEGhJURNOOiAt03cH/1NHeMOdkgxSRo3Oh68S7X/O QtK4EtxNOb57hv81zfikd69HQvy1dG1RKgU2PhpmZ7DQt2FmNBNj0cl0vvesrzFG FOHfhFj1lT/KTh09EqPh1uCn0NPawAKNox+WJj6tlz9nkGkYCV1JHxxfevFKXnGh diN7qxY+WfkiM3mPBZBlHbAqFP9cla07de4x+wwjuf2J18xTJx+rSy3IK4W6SY7o 3nCwU6Nw+xqC6a52MttjUkctuMHgLTRJbJp4sFvdPFpzahHdgOOgpuS2g3khY+Lz A8TLnnl/Hj5mNttcdQbkfeGVI3F4T3nXVvQ1sWMD5RLXpjM0myX2aEfrqKjCO2E= =4K4Y -----END PGP SIGNATURE----- --m1hDxRWCLWJkvKunBpto3LdG1CoL6XMwT-- From nobody Tue Jul 5 03:55:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1B312D0C9 for ; Tue, 5 Jul 2016 03:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5iWOXsSr95H for ; Tue, 5 Jul 2016 03:55:02 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id DEE3612D1BD for ; Tue, 5 Jul 2016 03:54:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5A269237; Tue, 5 Jul 2016 13:54:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id BaGzTryCUDhf; Tue, 5 Jul 2016 13:54:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9134C21C; Tue, 5 Jul 2016 13:54:52 +0300 (EEST) Date: Tue, 5 Jul 2016 13:54:49 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Message-ID: <20160705105449.GB9700@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> <577B72E0.4090102@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577B72E0.4090102@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:55:04 -0000 On Tue, Jul 05, 2016 at 10:42:08AM +0200, Hannes Tschofenig wrote: > > Consider the following three cases: > > * Client supports DTLS 1.2 / 1.3 but the server supports only DTLS 1.2. > > If the client starts the exchange with DTLS 1.3 then the server could > return a HelloVerifyRequest as defined in DTLS 1.2 and the exchange can > continue. For the client it is not a problem to deal with the HVR since > it supports both stacks. > > * Client supports only DTLS 1.3 and server supports DTLS 1.2/1.3. > > Here the client starts with a DTLS 1.3 exchange and the server will only > reply with a HelloRetryRequest as defined in TLS 1.3. It should bother > dealing with the DTLS 1.2 functionality when interacting with a DTLS 1.3 > client. > > * Client supports only DTLS 1.2 and the server supports DTLS 1.2/1.3. > > In this case, the client starts with the regular ClientHello and the > server will determine based on the version that it has to proceed with > DTLS 1.2. > > I believe that this could work fine. There are two more cases if server-side fallback is possible. One that can't work at all (fallback below minimum supported version) and another where the server has to be careful what cookie field it uses. -Ilari From nobody Tue Jul 5 06:47:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8912D591 for ; Tue, 5 Jul 2016 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.142 X-Spam-Level: X-Spam-Status: No, score=-4.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXpRKfGXgsBH for ; Tue, 5 Jul 2016 06:47:30 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E8912D58E for ; Tue, 5 Jul 2016 06:47:30 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u65DlTMp021118; Tue, 5 Jul 2016 09:47:29 -0400 Date: Tue, 5 Jul 2016 09:47:28 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Message-ID: <1668071051.2739941.1467726448720.JavaMail.zimbra@redhat.com> In-Reply-To: <20160704205114.GB4837@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <20160704205114.GB4837@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.36.6.111] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922) Thread-Topic: DTLS 1.3 Thread-Index: kqW46FNUGkTH9sRKr9Wepej+JcYubA== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:47:32 -0000 ----- Original Message ----- > On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote: > > ----- Original Message ----- > > > Hi all, > > > > > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > > > and you can find the result at > > > https://github.com/tlswg/tls13-spec/pull/512 > > > > > > I have worked on a prototype implementation of DTLS 1.3 and if someone > > > else has something working by the time of the Hackathon in Berlin please > > > let me know. > > > > May I recommend a more radical approach for DTLS? My experience with > > servers > > handling DTLS traffic from various clients is that the clients change IPs > > (while > > roaming) and incoming ports (due to firewall state timeout), making > > impossible > > for the server to map the encrypted incoming packets from unknown IP/port > > combinations > > to any particular handler (i.e., handling process/thread or logical > > handler). That > > is because an independently received DTLS record packet has no session > > identifying > > information. > > I think in DTLS 1.2, that was meant to be handled at lower layer (of course, > often there isn't such layer even when needed). I'm not sure that is discussed at DTLS 1.2 protocol at all. It is mostly ignored as a problem. In the most unreliable layers (including UDP), this cannot be handled at the lower layer without introducing another layer. > > For that I'd like to propose the DTLS record format to include at least a > > 3-byte identifier which will allow servers to recognize streams coming from > > unknown > > sources. That would be similar to the SPI field in the ESP packets. That > > is, > > a format similar to: > One can't change the headers in ClientHello/ServerHello and expect to remain > backwards compatible. Why would these headers need to change? The ClientHello will be sent under DTLS 1.0 and if the server see that the client supports the version with the new format, it will reply using the new fields. The protocol's design can cope with such changes. > And how would that identifier be assigned? 0 in ClientHello, then copy > whatever the server sends? If the procedure above is followed the client will copy whatever it sees from the server's hello packet. regards, Nikos From nobody Tue Jul 5 06:49:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A6612D550 for ; Tue, 5 Jul 2016 06:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBvl5UvZBbkM for ; Tue, 5 Jul 2016 06:49:49 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDBD12D534 for ; Tue, 5 Jul 2016 06:49:48 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u65DngVc017845; Tue, 5 Jul 2016 09:49:43 -0400 Date: Tue, 5 Jul 2016 09:49:42 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Stephen Farrell Message-ID: <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> In-Reply-To: <577AD00E.1000103@cs.tcd.ie> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.36.6.111] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922) Thread-Topic: DTLS 1.3 Thread-Index: hwiR+/ROjGrMljGLLw8CO14IYEcFvw== Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:49:50 -0000 ----- Original Message ----- > On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: > > > > where id is sent by the server to the client either via an extension, or > > by simply assuming that the client will copy and keep the ID seen at the > > server packets (it doesn't really matter that this ID is unprotected as > > it doesn't contribute nor affect the security in any way). > > Does that id need to be static? If so, then it'd act as an > additional way to track a user roaming over different IP and > ports. That'd be a pity. If such an id is useful, maybe there's > a way to allow it to change as well, in a way predictable for > the server. Could be, but I don't have a use case for such a switch nor can think something obvious, what do you have in mind? regards, Nikos From nobody Tue Jul 5 07:24:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C442312D5BF for ; Tue, 5 Jul 2016 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLoC8phqJLdY for ; Tue, 5 Jul 2016 07:24:07 -0700 (PDT) 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 9B4C712D596 for ; Tue, 5 Jul 2016 07:24:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 616A7BE32; Tue, 5 Jul 2016 15:24:04 +0100 (IST) 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 bzGQVrlrAQid; Tue, 5 Jul 2016 15:24:03 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E8F2BDCC; Tue, 5 Jul 2016 15:24:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467728643; bh=36KrAAlQoYcTqqMeP4DFUsdr+pBmT/2DvuUTSaE4HA8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=R+oUfWC7J144qOGc/Q0ODS5nJ1C/W+6DmqArO5TfbZQuD3W/YVzLGPPZqdWpwU5X2 DJu45oDKIacHNnD6nqwiPqdudP3bNpLwl+Asb5fhYZmAc8KWw9miOi/s7C0vwNAV3Z vmq4NIQVFWrstrH+C7r5hqWTHQoaPzy2ZUD+KkBE= To: Nikos Mavrogiannopoulos References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577BC302.5050000@cs.tcd.ie> Date: Tue, 5 Jul 2016 15:24:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070603020008060603040709" Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:24:10 -0000 This is a cryptographically signed message in MIME format. --------------ms070603020008060603040709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/07/16 14:49, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: >>> >>> where id is sent by the server to the client either via an extension,= or >>> by simply assuming that the client will copy and keep the ID seen at = the >>> server packets (it doesn't really matter that this ID is unprotected = as >>> it doesn't contribute nor affect the security in any way). >> >> Does that id need to be static? If so, then it'd act as an >> additional way to track a user roaming over different IP and >> ports. That'd be a pity. If such an id is useful, maybe there's >> a way to allow it to change as well, in a way predictable for >> the server. >=20 > Could be, but I don't have a use case for such=20 Hmm. I'd hope we can all share a use case of bring more privacy-friendly where possible and of not introducing changes that are privacy-unfriendly unless absolutely unavoidable. Adding a new identifier that doesn't change despite changes in client IP address etc. seems like it fails if one has the "use case" above in mind. Actually, the above is not really a use-case, but is nonetheless something on which I think we ought be able to agree so not all changes need to correspond to some use or abuse case:-) > a switch nor can think something > obvious, what do you have in mind? I've no specific proposal. If it were the case that a new cleartext identifier is wanted, then there could be ways in which that can be modified (e.g. a hash-chain based on something known to both client and server but not sent in clear) so that the server can know then next "N" ids to be expected but an observer can't use these to re-identify a client. S. >=20 > regards, > Nikos >=20 --------------ms070603020008060603040709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDUx NDI0MDJaMC8GCSqGSIb3DQEJBDEiBCCPzWWyJTd93egFmkqF3mlsQVbGk9nGfU056iZhI5At pTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB0cLg2h0wYnXPwP90dQYXq7wJdF3T6Loi0IPf+hA4uvDXBbNeYLep6 prD0lW91fIC8cLEzyh2lMXC/EBRU2WYIKGmIXt2rNC0WkjVrv8MYJIVRwMxJdALNSQy6SByo /60Jk9QjqNguoEE6yf7NqigPE4826u3zYYRNqvUl3jMCTL4vU8DVeQGiKnajcenZa8kvBcAT cgDx2ssTcsYZaH0shZlOu97wRZdElJbeTPxcJdzmUoFpLjNqG93/eMWU/Q3C3QKKiR8/JeRw K+E01XuiqJAjZU+wycG2w/GB3V94x4dyfTjBkJcVyzQAg9QDm6dsPD/jJ4hFMDzgxNiClH9F AAAAAAAA --------------ms070603020008060603040709-- From nobody Tue Jul 5 09:28:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96F12D635; Tue, 5 Jul 2016 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXP8wdB6a9VF; Tue, 5 Jul 2016 09:27:56 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC31C12D640; Tue, 5 Jul 2016 09:27:49 -0700 (PDT) Received: from [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3] (unknown [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 57672207C7; Tue, 5 Jul 2016 18:27:47 +0200 (CEST) To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> From: Marc Petit-Huguenin Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Date: Tue, 5 Jul 2016 09:27:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd" Archived-At: Subject: Re: [TLS] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: multipart/mixed; boundary="kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i" From: Marc Petit-Huguenin To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, We just published version -10. See below for some comments. On 06/28/2016 07:35 AM, Magnus Westerlund wrote: > Authors and WGs, >=20 > In my review for the publication writeup I did spot some issues in the = draft. Please consider the following issues: >=20 > 1. Abstract: With the addition of the ZRTP the abstract should benefit = from being updated. The ZRTP protocol being possible to multiplex is miss= ing as well as that there are now 4 issues. Fixed. >=20 > 2. Abstract contains [ref] to RFC 5764. This is an ID nit. Fixed. >=20 > 3. Section 1. The introduction is not explicitly saying that it updates= RFC 5764. I think that can be put as a sentence after: >=20 > This is achieved by > modifying the IANA registries with instructions for coordination > between the protocols at risk. We incorporated this in that sentence and also added it into the abstract= =2E >=20 > 4. Reference ID-nits: >=20 > =3D=3D Outdated reference: A later version (-31) exists of > draft-ietf-mmusic-sdp-bundle-negotiation-23 Fixed. >=20 > 5. Section 2: >=20 > ID-nits complains about the modified boilerplate for the RFC2119 text. = First of all one usually don't cut down the list to only the used ones. T= he requirement on all caps ones I am very divided about. I do have a pref= erence for unmodified boilerplate, this as I otherwise have to explain in= the write-up the ID-nit. Fixed. >=20 > 6. Section 6: >=20 > In order to prevent future documents from assigning values from the > unused range to a new protocol, this document modifies the RFC 5764 > demultiplexing algorithm to properly account for TURN channels by > allocating the values from 64 to 79 for this purpose. >=20 > I think this text fails to be explicit about that this restricts the TU= RN Channel space to a more limited set of possible channels when the TURN= client does the channel binding request. Thus affecting the TURN channel= allocation algorithm in the client implementations, at least when used i= n combination of muxing. Fixed. >=20 > Based on this and the fact that this specification changes the IANA reg= istrations performed by RFC5766, I think this document to have "Updates" = for RFC5766 also. So please add that in header, abstract and introduction= =2E Based on our understanding and looking at other RFCs, just updating an IA= NA registry does not imply a update to the core specification, so we did = not made that change. >=20 > 7. Updates RFC5389: >=20 > Looking at the impact also on the STUN protocol I would also think that= this requires and "Updates" also for RFC 5389. >=20 Based on the argument above, we do not think that this warrants an "Updat= es" status. >=20 > 8. Section 10.3: >=20 > The IANA registry name is not the correct one. The IANA page says that = the registry name is: >=20 > Traversal Using Relays around NAT (TURN) Channel Numbers > http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#t= urn-channel >=20 > Please update. Fixed. >=20 > 9. Section 12.2: >=20 > The reference to ZRTP [RFC6189] is likely in the wrong category, at the= same time moving this to a normative one creates a downref. I guess it o= ne that has to be accepted in this case. I suggest that you move it to th= e normative references. We are keeping it informative for now, but we will forward the discussion= with the AD to the mailing-list as requested. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i-- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd 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 iQIcBAEBCAAGBQJXe9/6AAoJECnERZXWan7E8JwQAMkUHV3c2Q1MK8TWsMTs/q5q r4eb5gLyaoxSV6x9ufYs42lJ3j6hr7t3GabA5ANFFI1tOx+eN3iMwTgH/2ylugoE fnyGgbal/vZ6pEj01goPALATYSk0m6KtFwS7+QPVvNoEan6oHbLA5iH5oc73FY8x B5cBFq89Do1ATeTKEX0a0FeSZmE5r4N4xrsjZpnMBXt1Unm+1SG0Ku24PJHCbEWN Tx68bmLODh+65pTVUzewDOo3urSlwjxStVqf/jQHh4fx/tDnxGH8c8cGMSW18jl/ PuanYrAv7pg0rMdhQMkeEs5Y6UaInE3B3zADdXEET0QSw6U4oiXVvzP8GH/QC8Ml z4zNDEcDn+wlPMWcmwOhrVtqbuUAcdHlMB4oynOzcVZpKciXvIpDlKKWJXdo9ERU l4/GCog8yq0HgQ2Mv5mGLHO3x5CIs+zgKFvAz6uWK3Qq4i12Wgxga+aJt3OFgwAn qvaMVuAr4ajUkYzF8iHJpXqUD15E48MvYHm4ps6ExtHhXcWqBUv8FxxGixTDZWAX lj5K6jpYdSddwY6nMc3BMS1XZrCX2TBmTaCm9MZWQjqRao0IEdVehfAh4+D1eeUb nUgIzFjjyQ73kZ2FHkyXBm6FYxAuXSI5MU9H1kjh78KDvUlGTStjb0azCrBNWG0c 0hmVb/kE0WTHDCIYklcY =qxAO -----END PGP SIGNATURE----- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd-- From nobody Wed Jul 6 01:47:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657FD12D0FB; Wed, 6 Jul 2016 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFpXJPbtanj1; Wed, 6 Jul 2016 01:47:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F54C12D0A4; Wed, 6 Jul 2016 01:47:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ea-577cc59ce276 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.00.18043.C95CC775; Wed, 6 Jul 2016 10:47:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.294.0; Wed, 6 Jul 2016 10:47:23 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: Date: Wed, 6 Jul 2016 10:47:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2K7lu6cozXhBu86tCxe9qxktzjwcSqz xbcLtRZTlz9msfh0vovR4sPaC2wObB5LlvxkCmCM4rJJSc3JLEst0rdL4Mp4vWQLa8Fa4Yq5 X7uZGxhv83cxcnJICJhIPFvxgR3CFpO4cG89WxcjF4eQwBFGibcL1kA5yxglbvX9Aari4BAW CJE4vj8JJC4i8I9R4uPGmywg3UIC9hK/djYyg9hsAhYSN380soHYvEDxnZMmgNksAioSE1cf AbNFBWIkGm8fZoeoEZQ4OfMJ2BxOAQeJ4z83sIDsYgbqfbC1DCTMLCAv0bx1NjPEKm2JhqYO 1gmMArOQdM9C6JiFpGMBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCAPbjlt9UOxoPP HQ8xCnAwKvHwLvhaHS7EmlhWXJl7iFGCg1lJhFfwUE24EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsbk35xzJsUsUmXvqnhYwLbwa8nSCSl/ebr+cWSG nXkre/3qfvc7sQlOm4/pzJLdtszO+Lzdttccrg7LFn6NZTb/MDcwtXun2uyIsBlsLHHra8JV f5iaZlY+iGZ4sYsnBhhnirbz9BsbefaqOGhfYmVl6/h0Lu7c7SNxN344TA5++HvZJ/uV35VY ijMSDbWYi4oTAU6aP69UAgAA Archived-At: Subject: Re: [TLS] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:47:29 -0000 Hi, The call has now ended. The authors have updated the document to address the issues I raised. The writeup has been uploaded and I have requested publication. If anyone has late feedback, please provide it. We will address it at the latest at the end of the IETF last call, most likely earlier. Cheers Magnus Westerlund Chair AVTCORE WG and Document Shepherd. Den 2016-06-28 kl. 15:04, skrev Magnus Westerlund: > WGs, > > I as WG chair earlier made a mistake in failing to include the relevant > WGs in our previous WG last call. Thus I would like to make a one week > confirmation call on the content of > draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > > TRAM WG: Please check that you are okay with the restrictions and > updates to the TURN channel allocations as well as STUN Method > restrictions. > > TLS WG: I believe you are satisfied with the impact on the TLS IANA > registry after previous discussions, but you are welcome to confirm this. > > ICE: For your information as this impacts protocol mechanism your are > dependent on. > > MMUSIC: For your information due to some notes in regards to BUNDLE and > RFC7345. > > Please provide any feedback by 5th of July. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jul 6 05:34:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F5712D76E for ; Wed, 6 Jul 2016 05:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVe1MG1yX8rB for ; Wed, 6 Jul 2016 05:34:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 6A5E512B05A for ; Wed, 6 Jul 2016 05:34:14 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LuwiT-1bTbkZ09yr-0106KR; Wed, 06 Jul 2016 14:34:10 +0200 To: Ilari Liusvaara , Eric Rescorla References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577CFABF.4020502@gmx.net> Date: Wed, 6 Jul 2016 14:34:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RSsJmXhDD192kOctqW8n4sv65Xpb6XWtR" X-Provags-ID: V03:K0:u6UQld6iZZNKyOYbWT83xULXwZdlQgDamiGMIcIpMiy1KpqHjGF 6W4qaVnBuWLzGVUmRJrFQmb6KGG8W0Dby6kVCQ0dxtszS8Mqp/trwoZoeoc0HPT7LnsL2DJ 0VDl+VLLAI1gpfcMZFMe9Em7CaLDi1QIXY3nqui2NkMGCK7AptpDWzCFzR8kh9PDuNbHAJN yZmiJc+j0zEHWuq3gxKpQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kePC0JGfv8M=:2Y9buOhdFVUAqy8Ye2YuYZ 3aTH1yEpVRG9M5ryqZDITNn6YMwP70yBzfLqG9friqSpAji4e1jKSFMT5A5EmWx59BXD6xkFq e4tCCtVqOnHMdapJ29IFEmtJS2/CkCqddCjO5zajoMdYVpv7Ku2zELozUrkDTpOXjLNIRqCLO s7CGEV4JhZaDjh8s6Yher4HulnFa9h55+/cBIDKNFH2BuY54wuaGz6nD4Sl+6WoUtpaHexWZc 98lHgIuGdP6OLyFgTLfbqQu5JcGoCH6vDRoO1rC8PTz9tNPpgvtxF9BZCZ9V4nDGkrfhh0L0I L65En9VRJrr6oULDsuhuz+DR1+GSLt69HM6Wzmh4K6+G14FjanKxPUM+3aTfijhQiFUIfWGGM 5jmvVHJI4byN550w30r9H/BZmluo5WMyAAKCseVlFTc0F5L7H2eHSej8fvZGorkdHVIs53xZR kAe0gKnqI/6Z7XA/VUF5sBZJIvuQXdtyGk01mZshZwEcUqj8k6j5nhgno54rjcDbp1121xnLd TYrxXmFcXHFzvW5n7imvq1CckgTW2ZTFLUyYTMI0BWcb5A7FsbtrAkIdZU+VDY4Dg2i/4Cql0 /u+Vvn67f7e+247x9mUsnjzU2ZrSUWDFkr1zE+BMhunPbGOTY1iwb0B0LHOMIlcenGRTbpoTl YWC6WPRM2r9b1AZFZBzG22p7mbJlCUG7MgY7rt6gJZK5n8YzHuWYelFWZ8YG6YiXNprORp0Om P+8lwuXcZBxofhVpUSb4UHZWD8cMJxlkgxhbHnLjlKGQWFp1eLjceNna10M= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:34:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RSsJmXhDD192kOctqW8n4sv65Xpb6XWtR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ilari, Hi Ekr, a few remarks inline: ~snip~ >>>> - The handshake retransmit scheme doesn't seem to work that >>>>> well with post-handshake auth, and even less well with >>>>> session tickets. >>>> Why do you think so? Of course, unreliable transports creates >>>> inconvenience; is it that what you are referring to? >>> >>> DTLS assumes handshake messages are reliable, and that reliability is= >>> implemented via handshake messages ACKing one another. >>> >>> - Session tickets have no ACK at all. >>> >> >> DTLS 1.3 should add an ACK, IMO. > =20 > Yeah, not going to work without. And I presume something might be > needed for dynamic reauth too... I was wondering about one design decision regarding the ack. If we don't use the epoch instead of the KeyUpdate then there is only one other message that does not have an ack, namely the NewSessionTicket message. (I might be worthwhile to think about why the server can send it at any time and why it isn't sent as part of the regular handshake instead. This would make the issue with acks potentially go away.) The post-handshake authentication with the CertificateRequest comes with an ack (even though it may be delayed), namely Certificate, CertificateVerify, and Finished (and in case of a decline with a certificate and a finished). Would it be worthwhile to ack them as well due to the potential delay caused by user interaction? Let us say that we provide an ack for the NewSessionTicket message then it is sufficient to specify a very simple ack, namely one that is defined as: struct {} Ack; If we also ack the post-handshake authentication then it is necessary to include some identifier in the Ack message to indicate which message is acked. What are your thoughts about this? > =20 >>> - CertificateRequest can have very slow ACK. >>> - KeyUpdate has no real ACK (and isn't idempotent either). >>> >> >> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoc= h >> instead. I believe that using epoch for updating the cryptographic keys is pretty much like a key update. Essentially, we are talking about taking the epoch value from the incoming packet and then figuring out what security context is applicable. Correct? An alternative design would be to require the receiver of a KeyUpdate to return a KeyUpdate as well. This would then constitute a flight. Wouldn't this be better? >=20 > How many special epochs we need? >=20 > 0 =3D> Unencrypted messages > 1 =3D> 0-RTT control messages (just one finished[1]!) > 2 =3D> 0-RTT data messages > 3 =3D> primary handshake > 4 =3D> application data > 5-N =3D> rekey connection I guess you want to introduce these different epoch values and associate them with different phases during the handshake since the TLS 1.3 key derivation is more sophisticated than the TLS 1.2 version. Is this correct? Ciao Hannes --RSsJmXhDD192kOctqW8n4sv65Xpb6XWtR 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 iQEcBAEBCgAGBQJXfPrAAAoJEGhJURNOOiAtrCUH/i6mtuNr2H/ICkP8E6XELKeM Plpv+u4Kybl3RFoWuKsf5vU0UW6pcC2Vz9TuH2WozbENni9BmpTD6SbCLZBaC3E/ tIlJ4IwosucJCHl+ATIDO8fzmChzSXSuONEb3VEKrhlu4dH2v2RnXgNN+9b77Gng wvrwrc+smJdoX/FC4sQRwcAVvHWMzQni9uGIrCNfWoVFug75UOh4Lw8XldeJQPby yjlOzh3OgRE4P+Jgzuo42XO6TJZFF+xSUCaqjnEC+ysyu8a0kipY1DwQuiuGyBX5 4puan/tdjudvJ5ON4Sf4A02T+GYseitKPsJLQchLL8kVm4Dn8WJ1lgTLm18jJm8= =/wfv -----END PGP SIGNATURE----- --RSsJmXhDD192kOctqW8n4sv65Xpb6XWtR-- From nobody Wed Jul 6 07:47:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4EC12D140 for ; Wed, 6 Jul 2016 07:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-Hs28w13vMC for ; Wed, 6 Jul 2016 07:47:12 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4280F12D0D3 for ; Wed, 6 Jul 2016 07:47:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3198D7E77 for ; Wed, 6 Jul 2016 17:47:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 9eZuSnYv-Fil for ; Wed, 6 Jul 2016 17:47:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D05D0C4 for ; Wed, 6 Jul 2016 17:47:10 +0300 (EEST) Date: Wed, 6 Jul 2016 17:47:08 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> <577CFABF.4020502@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577CFABF.4020502@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:47:14 -0000 On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote: > > I was wondering about one design decision regarding the ack. > > If we don't use the epoch instead of the KeyUpdate then there is only > one other message that does not have an ack, namely the NewSessionTicket > message. (I might be worthwhile to think about why the server can send > it at any time and why it isn't sent as part of the regular handshake > instead. This would make the issue with acks potentially go away.) Being part of regular handshake is problematic, since those are assumed to be tickets, and as such one needs the dynamic PSK key. But the dynamic PSK key includes the entiere handshake up to Client Finished. And this can't really be changed (or things start going badly wrong). So the minimum time to send some tickets is 4th flight, whereas normal handshake is only 3 flights. > The post-handshake authentication with the CertificateRequest comes with > an ack (even though it may be delayed), namely Certificate, > CertificateVerify, and Finished (and in case of a decline with a > certificate and a finished). Would it be worthwhile to ack them as well > due to the potential delay caused by user interaction? > > Let us say that we provide an ack for the NewSessionTicket message then > it is sufficient to specify a very simple ack, namely one that is > defined as: struct {} Ack; > > If we also ack the post-handshake authentication then it is necessary to > include some identifier in the Ack message to indicate which message is > acked. Certificate requests have context identifiers... > I believe that using epoch for updating the cryptographic keys is pretty > much like a key update. Essentially, we are talking about taking the > epoch value from the incoming packet and then figuring out what security > context is applicable. Correct? Yeah. > An alternative design would be to require the receiver of a KeyUpdate to > return a KeyUpdate as well. This would then constitute a flight. > Wouldn't this be better? I don't think this works, because KeyUpdate is not idempotent (causes problems if reply is lost) and worse yet, because of potential desyncs with the main data flow (IP packet reordering!). > > How many special epochs we need? > > > > 0 => Unencrypted messages > > 1 => 0-RTT control messages (just one finished[1]!) > > 2 => 0-RTT data messages > > 3 => primary handshake > > 4 => application data > > 5-N => rekey connection > > I guess you want to introduce these different epoch values and associate > them with different phases during the handshake since the TLS 1.3 key > derivation is more sophisticated than the TLS 1.2 version. > > Is this correct? Each listed one essentially corresponds to one key connection can use: - Unencrypted (CH/SH/HRR) - 0-RTT handshake key (Finished) - 0-RTT data key (0-RTT appdata) - Handshake key (Encrypted Extensions to Client Finished) - Application key from initial traffic_secret_0. - Application key from traffic_secret_N (N>0). -Ilari From nobody Wed Jul 6 10:24:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADCD12D0DB for ; Wed, 6 Jul 2016 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAgc06abhCKg for ; Wed, 6 Jul 2016 10:24:02 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FC312D094 for ; Wed, 6 Jul 2016 10:24:02 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id f89so119803946qtd.2 for ; Wed, 06 Jul 2016 10:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IVVDNCMc+lKaa3SoTM/KddFLR+p4uttm/CE7SVg0NrU=; b=1IDjDBZRk9U8X0XU3bNZW+ToEYZjNteZiZPR8isfJwjBcxrtKM02tGr6HP2ZurQP1E KoyRHstuTx/kDDdy+iqD8Wi/fQ4sKQySoeaGqZV1IshkZN/QBTW9FnQY9WKSTkJP4Pqy b2BGlhU4NAkr+7TtShAKEgCnOkcIndWoI8AXt61qTkZ0ZF7wKrSEwRRPnUvXAxFGP2KV K4T2ZbaTokNBVQvAObZfaRU+Biz45ytkPoC67lNwrhkR2qWrGMJNAZlrZYzn5db+1tty 6P4fMlsAMitBysyV77zsV9IaJSoxbSAudu26WXayu3U0SrbvtakIqL104PCYy2Fs4qzs UOKw== 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; bh=IVVDNCMc+lKaa3SoTM/KddFLR+p4uttm/CE7SVg0NrU=; b=PhElxMcXs+0+fGMUvHAhwqqW26OQNpK4Gnyh3hKMPj5ZYkA6qCGWywN4xpvvhXWE86 YKzcr7YrBNN3PACCr5yRJbJwT1WPQG4/a0hbS8nIne/w/XzxPTbXr1NCz+IcTj1ciyLW +0zpcp2zLBiJMe0deSRhdWSvI1zHSogi8fgp95a5Fx2Xn+bGe39DDWrmJxLZG1F3oOEU n87QfPLS0jr7Tk70lGYWlz7Z7M5vFmF7Cksta1zAn56SUKgU2lV3pS0YgvOWdabZXmKw 3t5Q5UHbxVExPK7fC4EjUdKDuBTLQLlcB6Zn4P/DDNHc5w8gKl2AhcKNKBUsHM4pVXZn fn8g== X-Gm-Message-State: ALyK8tKYSd1INwNtrDg+1rOUxQXHJo0mipOyzWi24NTLQ7wL65rvZlAFsRH0HmDwwuQ8RlJyuRWU6VkzvZAnXQ== X-Received: by 10.200.47.107 with SMTP id k40mr35260681qta.86.1467825841280; Wed, 06 Jul 2016 10:24:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.181.134 with HTTP; Wed, 6 Jul 2016 10:23:41 -0700 (PDT) In-Reply-To: <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> From: Joseph Salowey Date: Wed, 6 Jul 2016 09:23:41 -0800 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a113d81cadcc1670536fad571 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:24:04 -0000 --001a113d81cadcc1670536fad571 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think we ever call consensus on this topic. It looks like there is rough consensus to move forward with RSA-PSS as the MUST implement algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5. During the discussion it also seemed that it is realistic that we may want to add additional types in the future. We may want better separation of signature types of certificates and certificate verify. Cheers, J&S On Wed, Mar 9, 2016 at 2:05 AM, Hubert Kario wrote: > On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote: > > On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote: > > > No, I said that we have no reason to believe that quantum computers > > > won't follow exponential increase in number of qbits they can > > > handle, > > > with the highest increase not exceeding doubling every year, but > > > more > > > likely doubling every two years (as every other technological > > > development did till now). > > > > There's reason to be skeptical of such analogies. Moore's law was > > neither a theorem nor a law of nature. It was an observation about > > progress in feature-size shrink of silicon transistors. It is far > > from clear that evolution of silicon fabrication is a relevant model. > > That's why I'm not saying that it will be exactly like Moore's law. > > My point is, that processes which have super-exponential growth are the > exception, not the rule (if they exist at all). And you would be hard > pressed to find any process in history that experienced exponential > growth over a long time span and be at the same time vastly faster than > the Moore's law. > -- > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113d81cadcc1670536fad571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't= think we ever call consensus on this topic. =C2=A0It looks like there is rough consensus to move forward with RSA-PS= S as the MUST implement algorithm for certificate verify in TLS 1.3 and not= allow PKCS-1.5. =C2=A0 During the discussion it also seemed that it is rea= listic that we may want to add additional types in the future.=C2=A0 We may= want better separation of signature types of=C2=A0certificates=C2=A0and certificate verify. =C2=A0

Cheers,

J&S<= /div>

On Wed, M= ar 9, 2016 at 2:05 AM, Hubert Kario <hkario@redhat.com> wrot= e:
On Tuesday 08 March 2= 016 18:41:32 Viktor Dukhovni wrote:
> On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > No, I said that we have no reason to believe that quantum compute= rs
> > won't follow exponential increase in number of qbits they can=
> > handle,
> > with the highest increase not exceeding doubling every year, but<= br> > > more
> > likely doubling every two years (as every other technological
> > development did till now).
>
> There's reason to be skeptical of such analogies.=C2=A0 Moore'= s law was
> neither a theorem nor a law of nature.=C2=A0 It was an observation abo= ut
> progress in feature-size shrink of silicon transistors.=C2=A0 It is fa= r
> from clear that evolution of silicon fabrication is a relevant model.<= br>
That's why I'm not saying that it will be exactly like Moore= 's law.

My point is, that processes which have super-exponential growth are the
exception, not the rule (if they exist at all). And you would be hard
pressed to find any process in history that experienced exponential
growth over a long time span and be at the same time vastly faster than
the Moore's law.
--
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

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


--001a113d81cadcc1670536fad571-- From nobody Wed Jul 6 10:27:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271E212D1CB for ; Wed, 6 Jul 2016 10:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgkKoHkQRLg5 for ; Wed, 6 Jul 2016 10:27:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07A312D5A8 for ; Wed, 6 Jul 2016 10:27:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C7D0A300541 for ; Wed, 6 Jul 2016 13:27:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UzdN--VviXiG for ; Wed, 6 Jul 2016 13:27:23 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 63BD23004EE for ; Wed, 6 Jul 2016 13:27:23 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_306D9E5B-C87B-421D-8246-746F1E4D1CBF" Message-Id: <65544CC0-B59E-430B-A3C0-08F105CBFCFA@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 6 Jul 2016 13:27:28 -0400 References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> To: IETF TLS In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:27:32 -0000 --Apple-Mail=_306D9E5B-C87B-421D-8246-746F1E4D1CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support a MUST for RSA_PSS for certificate verify, and it does seem = like a good idea to be algorithm agile. Russ On Jul 6, 2016, at 1:23 PM, Joseph Salowey wrote: > I don't think we ever call consensus on this topic. It looks like = there is rough consensus to move forward with RSA-PSS as the MUST = implement algorithm for certificate verify in TLS 1.3 and not allow = PKCS-1.5. During the discussion it also seemed that it is realistic = that we may want to add additional types in the future. We may want = better separation of signature types of certificates and certificate = verify. =20 >=20 > Cheers, >=20 > J&S >=20 > On Wed, Mar 9, 2016 at 2:05 AM, Hubert Kario = wrote: > On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote: > > On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote: > > > No, I said that we have no reason to believe that quantum = computers > > > won't follow exponential increase in number of qbits they can > > > handle, > > > with the highest increase not exceeding doubling every year, but > > > more > > > likely doubling every two years (as every other technological > > > development did till now). > > > > There's reason to be skeptical of such analogies. Moore's law was > > neither a theorem nor a law of nature. It was an observation about > > progress in feature-size shrink of silicon transistors. It is far > > from clear that evolution of silicon fabrication is a relevant = model. >=20 > That's why I'm not saying that it will be exactly like Moore's law. >=20 > My point is, that processes which have super-exponential growth are = the > exception, not the rule (if they exist at all). And you would be hard > pressed to find any process in history that experienced exponential > growth over a long time span and be at the same time vastly faster = than > the Moore's law. > -- > 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 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_306D9E5B-C87B-421D-8246-746F1E4D1CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support a MUST for RSA_PSS for certificate verify, and it does seem like = a good idea to be algorithm = agile.

Russ


On = Jul 6, 2016, at 1:23 PM, Joseph Salowey <joe@salowey.net> wrote:

I don't think = we ever call consensus on this topic.  It looks like there is rough consensus to = move forward with RSA-PSS as the MUST implement algorithm for = certificate verify in TLS 1.3 and not allow PKCS-1.5.   During the = discussion it also seemed that it is realistic that we may want to add = additional types in the future.  We may want better separation of = signature types of certificates and certificate verify. =  

Cheers,

J&S

On Wed, Mar 9, 2016 = at 2:05 AM, Hubert Kario <hkario@redhat.com> wrote:
On Tuesday 08 March 2016 = 18:41:32 Viktor Dukhovni wrote:
> On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > No, I said that we have no reason to believe that quantum = computers
> > won't follow exponential increase in number of qbits they = can
> > handle,
> > with the highest increase not exceeding doubling every year, = but
> > more
> > likely doubling every two years (as every other = technological
> > development did till now).
>
> There's reason to be skeptical of such analogies.  Moore's law = was
> neither a theorem nor a law of nature.  It was an observation = about
> progress in feature-size shrink of silicon transistors.  It is = far
> from clear that evolution of silicon fabrication is a relevant = model.

That's why I'm not saying that it will be exactly like Moore's = law.

My point is, that processes which have super-exponential growth are = the
exception, not the rule (if they exist at all). And you would be = hard
pressed to find any process in history that experienced exponential
growth over a long time span and be at the same time vastly faster = than
the Moore's law.
--
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

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


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

= --Apple-Mail=_306D9E5B-C87B-421D-8246-746F1E4D1CBF-- From nobody Wed Jul 6 10:40:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD16D12D5AA for ; Wed, 6 Jul 2016 10:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg1uNo82iPtX for ; Wed, 6 Jul 2016 10:40:14 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E91112D528 for ; Wed, 6 Jul 2016 10:40:14 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m2so120261831qtd.1 for ; Wed, 06 Jul 2016 10:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y+750lHL0e9SukotIbJWMWN8ysz8nBrNiBAKZcmwdIQ=; b=wi2XEUOQ7Dl5ObfX1gAucbMPxRVVKsqKJ0opzRVD6Q0Jsd4+DfUK2vRmrEhrKOMSBG /vbZGevg/FB2+wPCdxl08MuC3tTNfcMxsZpDwp3j4rDtt/V8wAhPgZG7fmuO+bCLqpzA DhKN/0iu0tl17B6Ck2aBxFNNw7ZXooV6EFyKWL+KJI9S6DkSO++5LhG0vuRbuooYggEf SVkMtvw7juXsy0vQYG4K3LF50NOXPyrP4u6oII8vhHO/elLqLraBrgZYR5pP5N/86/2U LImnoa/Cy8TMEixLhVd8v9VMDlAsAL30+nmMvfl0ofGXG9Cf5krQucR1uYRArmqfw/7x 1E7w== 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; bh=Y+750lHL0e9SukotIbJWMWN8ysz8nBrNiBAKZcmwdIQ=; b=nG9dOvRhG2otOAhknyUQtCdtw6s2Yao1jdHdxn9jjzNSPHowl2b5ap2rLutXvwsxsW JbKyPvvqWWzYAN7JCDLadNhv1XCsOjr5bX6kbDr9DSB7InSIyHAo53gIv5u2SvwtRm52 fYAMtmTL2GmGL01//lfL8AOqBKeDWVXqN8cvhbKEHGczCefOSrQ9dAea6I+8h+vTNTcD o7F4HBf22gkz15sQy47FTVZJUgjsrUrrqX0zWMfUSyYMGULkiN7H7x3T0n5uPRMrWyNY XW1Ij/96YVLMb0vK9fnce9M7XkFSGeuD7ss2UMGQE9UqAbe1kqhLjEOzCLH9iDcoBFYs nDiQ== X-Gm-Message-State: ALyK8tK0L7gCIOt4hlIyeCB6QtftXt4qVCSqknmhwjBl99DQbJhUTFbGP3E0syBoi9g+KvDq/yxjRET05EVbaw== X-Received: by 10.200.52.157 with SMTP id w29mr35919503qtb.99.1467826812999; Wed, 06 Jul 2016 10:40:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.181.134 with HTTP; Wed, 6 Jul 2016 10:39:53 -0700 (PDT) From: Joseph Salowey Date: Wed, 6 Jul 2016 09:39:53 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11444b06c7fb7a0536fb0fb9 Archived-At: Subject: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:40:17 -0000 --001a11444b06c7fb7a0536fb0fb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are the unenviable position of calling consensus between three choices [0]: - Option 1 - use the same key for both handshake and applications messages. - Option 2 - restore a public content type and different keys. - Option 3 - separately encrypting the content type. At this point the consensus is rough. The first option we would broadly characterize as supported by the implementers because they can=E2=80=99t see the harm in using the same key = but opposed by the cryptographers because it makes the proofs harder making mistakes easier to miss. The second option as supported by researchers/cryptographers because it cleanly separates the keys used but opposed by the implementers because it=E2=80=99s unnecessarily complex. In general, privacy advocates do not s= upport this option either. The third was not really discussed at all and it=E2=80=99s not clear what i= s the impact to security proofs or implementations. As we see it the privacy concerns are somewhat of a moving target, however not encrypting the content type seems worse for privacy than encrypting it. We are looking to eliminate option 2 and choose 1 or 3. If you are in favor of option 2 then we need to know if option 1 meets your needs, if option 3 is better than option 1, or if you feel that the only viable option is option 2. J&S [0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA --001a11444b06c7fb7a0536fb0fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are the unenviable position of calling consensus betwee= n three choices [0]:

- Option 1 - use the same key for both handshak= e and applications messages.
- Option 2 - restore a public content type = and different keys.
- Option 3 - separately encrypting the content type.=

At this point the consensus is rough.

The first option we wo= uld broadly characterize as supported by the implementers because they can= =E2=80=99t see the harm in using the same key but opposed by the cryptograp= hers because it makes the proofs harder making mistakes easier to miss. =C2= =A0

The second option as supported by researchers/cryptographers be= cause it cleanly separates the keys used but opposed by the implementers be= cause it=E2=80=99s unnecessarily complex.=C2=A0 In general, privacy advocat= es do not support this option either.

The third was not really discu= ssed at all and it=E2=80=99s not clear what is the impact to security proof= s or implementations. =C2=A0

As we see it the privacy concerns are s= omewhat of a moving target, however not encrypting the content type seems w= orse for privacy than encrypting it.

We are looking to eliminate opt= ion 2 and choose 1 or 3.=C2=A0 If you are in favor of option 2 then we need= to know if option 1 meets your needs, if option 3 is better than option 1,= or if you feel that the only viable option is option 2.

J&S
=
[0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8l= RreqBuiNA
--001a11444b06c7fb7a0536fb0fb9-- From nobody Wed Jul 6 10:45:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142D212D0DB for ; Wed, 6 Jul 2016 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFEpWw-bJWhN for ; Wed, 6 Jul 2016 10:45:42 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 2861612D0AA for ; Wed, 6 Jul 2016 10:45:42 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t127so321305362qkf.1 for ; Wed, 06 Jul 2016 10:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=Vv8FfKO1YSpbgB3D+k7d6OEBOv6+c1NempRopri6SsY=; b=DIXE8dTZK6Mo1Up7RglJB7oGIFl+JpHSr1D/o/ymQ2C3E73oio7Ppkv3dZi0nYQv4N Lh7twWwgCNv7iQjapjQ/1OJznsoWrekMXRRigTox5tZVzCnNjjCeVpnnTT8+GszaRpUX sRuN75V3aB83x523PkXd66p2g1JIQ1TTsa6Lo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=Vv8FfKO1YSpbgB3D+k7d6OEBOv6+c1NempRopri6SsY=; b=ODyO1NUZOuYk65MLLq+YillA5PWrVPi2v3vub1MOF1q9VQIocw5bvw5ZBrtZhQw507 nkMI7Y688O1Rsx/6h2NCc4/yyn0/dZzIqLlQUzuNuelULW/rUjAnYAXEEvUMSTZb7gyJ P3tHXyVqtLQ9KDdDSpH9uNOZ4B7disjp/m+08Cs+8Fsbgj5aoOLbCFSB43eQgN+To7hD H9rKMNoFQ1xqzgPTwE9UXTsViUdpajSYni2BFuEGjgl5OV3oh0bwziEzNB1pRB+hX/AK cP9TSqbrra0fV0TtEoN4/1MWQ4TfVNkFNe07xHJ5vsswm3I2DnbOrGltbFRyIJSwSCJj HeUA== X-Gm-Message-State: ALyK8tKDWxOX6UdgIlQ8uBdMrcq3D//6HtcWE5EDX8lP2jkReEEAQIucQiGVg/da8hYVmA== X-Received: by 10.233.235.5 with SMTP id b5mr30142378qkg.83.1467827141188; Wed, 06 Jul 2016 10:45:41 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id g15sm1918827qtc.17.2016.07.06.10.45.40 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 10:45:40 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7E71298A-1B25-452A-BDC0-DCC5616CDF98@sn3rd.com> Date: Wed, 6 Jul 2016 13:45:39 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] confirming AUTH48 changes to draft-ietf-tls-cached-info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:45:44 -0000 Anirudh noted [0] that existing implementation practices in TLS stacks = may lead to additional complexity when implementing TLS cached info on = the server side. The main issue is that the server needs to prepare the = ServerHello (and list the CachedInfo extension) saying which payloads = will subsequently modify. However, most implementations create each = message somewhat independently and so it is not clear whether a = certificate message, for example, will indeed contain the full payload = or the fingerprint at the time of creating the ServerHello. We need the WG to verify an AUTH48-proposed change to s4 of cached-info = [1]. Please let us know whether you agree with the following changes by = 14 July. The proposed changes can be seen in the diff: http://www.tschofenig.priv.at/Diff_rfc7924-before_after.pdf Cheers, J&S [0] https://www.ietf.org/mail-archive/web/tls/current/msg19493.html [1] https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ From nobody Wed Jul 6 12:26:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB98512D5C9 for ; Wed, 6 Jul 2016 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTzEFBuSuFGe for ; Wed, 6 Jul 2016 12:26:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9268F12D5D2 for ; Wed, 6 Jul 2016 12:25:21 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lg5kl-1bf5uR49Vr-00pdoj; Wed, 06 Jul 2016 21:25:17 +0200 To: Ilari Liusvaara , tls@ietf.org References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> <577CFABF.4020502@gmx.net> <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577D5B1B.1030609@gmx.net> Date: Wed, 6 Jul 2016 21:25:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3tWAPXq5HgqH8DBSnasVMFXcL93i7fDqu" X-Provags-ID: V03:K0:W+8ckchNhMW4J30HCquchrBI3sRJdqC6dZMSfgkirZwNfNyQ7Ud WmaSvjyeS5Kugek32/j464XOW3nVujgzkGwDuRSFsKsMRoeQXTI9gvGahWzhVG9muiIweW2 2cnmmg5+2A1mtDGpGTn3EQVoI2koCWaQKu132+2g+kf+A5U5rJ5kz6nd/LFVOfhXO2ZGl6L hXl19hpeeAy17ZtFlSZGg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lZYKklt2JQE=:yRSupFNXrIOBQO1kyUbtDy Jj/0plzk2rtlGBh5Tz/ejG7LbewuwU/pU2kKVK9f3N/9Vnh2Yb4eCnh32xYhr4tkYHu7pxnCp DcPNrGBwtkVmp+rO7CQUeO3EMr/l5XrYsf17yfqoja9JsAwC0DPw8yuB4z2weQN31/DrntFi6 KJ9buBoiZF4GFFVC/hSbYxUrjwTxHvjhYPh40SSviVZAYATIl0HDmg8jp5Ad0V2PXonPx+B3j 7c8oAeG9qgyiANRFlncunKoTDSps4dC+lnPgM1q6ZsgdkulLPWWFEXifKXeDubkc5k6jw33xz tlKc3Zh7Y8SVNnaEM7Iuir7tflQBY18aJlfMmse+6IVr0gb4sbN+bCPdE1aHUHocTAeOvsMBY eCchBr045FvRW9d7EdduWEx8ERzDeNPfuPa2U4vFqvjDb7vOzqqfEjDrkUdDh7bVEP0mjly8b 0NA9v/uZbZ9lYv5cOITOAmFgKmzJms1Slk40EmXRE+PfJNW/TAIDVeeOu5M8RGniepAViFIbZ Fe9tIXCNMRm9wiwf0I0TazfpSpqAC7SqPFbelEFuQhNCGypC96tH4K4uQaKVrDqnKepY9r6Fg bP4sPkQk4egO796olJRb1f0FN0lZaJbIEqdYGGJXUs7UoCLIAoJ2qBXagAi0yTwg8y6JjIQJv GnBQuP2QIvyNTLUAA0N/bXm7C6hdQCZ4+FsT7/9vKp6sE0mtTroAUaHv+OOXxtHYx/tG1YMIO 7ZwYvBNtlvNRWASa8pfVjo4GIDtsnH8coq7bUR+ompPmKO7JSYSMDw/J+Ms= Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:26:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3tWAPXq5HgqH8DBSnasVMFXcL93i7fDqu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ilari, a few remarks inline: On 07/06/2016 04:47 PM, Ilari Liusvaara wrote: > On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote: >> >> I was wondering about one design decision regarding the ack. >> >> If we don't use the epoch instead of the KeyUpdate then there is only >> one other message that does not have an ack, namely the NewSessionTick= et >> message. (I might be worthwhile to think about why the server can send= >> it at any time and why it isn't sent as part of the regular handshake >> instead. This would make the issue with acks potentially go away.) >=20 > Being part of regular handshake is problematic, since those are assumed= > to be tickets, and as such one needs the dynamic PSK key. But the dynam= ic > PSK key includes the entiere handshake up to Client Finished. And this > can't really be changed (or things start going badly wrong). >=20 > So the minimum time to send some tickets is 4th flight, whereas normal > handshake is only 3 flights. Was just an idea. The TLS 1.2 ticket mechanism was also transmitted during the handshake. >=20 >> The post-handshake authentication with the CertificateRequest comes wi= th >> an ack (even though it may be delayed), namely Certificate, >> CertificateVerify, and Finished (and in case of a decline with a >> certificate and a finished). Would it be worthwhile to ack them as wel= l >> due to the potential delay caused by user interaction? >> >> Let us say that we provide an ack for the NewSessionTicket message the= n >> it is sufficient to specify a very simple ack, namely one that is >> defined as: struct {} Ack; >> >> If we also ack the post-handshake authentication then it is necessary = to >> include some identifier in the Ack message to indicate which message i= s >> acked. >=20 > Certificate requests have context identifiers... I was more thinking about including the HandshakeType to distinguish the ack for a NewSessionTicket from an ack to a CertificateRequest. >=20 >> I believe that using epoch for updating the cryptographic keys is pret= ty >> much like a key update. Essentially, we are talking about taking the >> epoch value from the incoming packet and then figuring out what securi= ty >> context is applicable. Correct? >=20 > Yeah. > =20 >> An alternative design would be to require the receiver of a KeyUpdate = to >> return a KeyUpdate as well. This would then constitute a flight. >> Wouldn't this be better? >=20 > I don't think this works, because KeyUpdate is not idempotent (causes > problems if reply is lost) and worse yet, because of potential desyncs > with the main data flow (IP packet reordering!). Maybe it should be made idempotent... >=20 >>> How many special epochs we need? >>> >>> 0 =3D> Unencrypted messages >>> 1 =3D> 0-RTT control messages (just one finished[1]!) >>> 2 =3D> 0-RTT data messages >>> 3 =3D> primary handshake >>> 4 =3D> application data >>> 5-N =3D> rekey connection >> >> I guess you want to introduce these different epoch values and associa= te >> them with different phases during the handshake since the TLS 1.3 key >> derivation is more sophisticated than the TLS 1.2 version. >> >> Is this correct? >=20 > Each listed one essentially corresponds to one key connection can use: >=20 > - Unencrypted (CH/SH/HRR) > - 0-RTT handshake key (Finished) > - 0-RTT data key (0-RTT appdata) > - Handshake key (Encrypted Extensions to Client Finished) > - Application key from initial traffic_secret_0. > - Application key from traffic_secret_N (N>0). >=20 Thanks. Makes sense. Ciao Hannes >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --3tWAPXq5HgqH8DBSnasVMFXcL93i7fDqu 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 iQEcBAEBCgAGBQJXfVsbAAoJEGhJURNOOiAtJhsH/3Rnd9ToW47OlN3OaEyG0H/C aMsA5R7sNBEsZVIDzhRC6ZX6IsNlgG+DxnAXGmngcyW+scwNJ4yyNugN0Zd7RVFw 7nE9LOlRjRc3cj2MosMHcfukzIJxwQ+uWilbzldNTgMnTh0N3JtfkMBgQ+JJcPTp tr1UHRTcr81yWu+NjMovpWkf8/cA2kaiB6fKXUgJE40T609/FIh214HtA+cKL6Vf JSYRUkw9Q9qgQfc40Ynl0wz4XVR6/VpwwmCXHTetXkMzra1teKLnVFSFsFp0RWkh nVRrAwXfZoVpQudz85GDizvPGXqXJQnV+Za5Yhzrl7+y64oMD5PaPus7+3qEV+c= =GZfo -----END PGP SIGNATURE----- --3tWAPXq5HgqH8DBSnasVMFXcL93i7fDqu-- From nobody Wed Jul 6 12:35:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862C312D123 for ; Wed, 6 Jul 2016 12:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpoMcJWJ7Nth for ; Wed, 6 Jul 2016 12:34:58 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46712D0CD for ; Wed, 6 Jul 2016 12:34:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id BCA259C4 for ; Wed, 6 Jul 2016 22:34:56 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id gFger-o8y6lL for ; Wed, 6 Jul 2016 22:34:56 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 69034C4 for ; Wed, 6 Jul 2016 22:34:56 +0300 (EEST) Date: Wed, 6 Jul 2016 22:34:54 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160706193454.GB28197@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> <577CFABF.4020502@gmx.net> <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi> <577D5B1B.1030609@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577D5B1B.1030609@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:34:59 -0000 On Wed, Jul 06, 2016 at 09:25:15PM +0200, Hannes Tschofenig wrote: > > > > Being part of regular handshake is problematic, since those are assumed > > to be tickets, and as such one needs the dynamic PSK key. But the dynamic > > PSK key includes the entiere handshake up to Client Finished. And this > > can't really be changed (or things start going badly wrong). > > > > So the minimum time to send some tickets is 4th flight, whereas normal > > handshake is only 3 flights. > > Was just an idea. The TLS 1.2 ticket mechanism was also transmitted > during the handshake. The TLS 1.2 ticket mechanism actually did nasty things to forward secrecy. In TLS 1.2, the ticket happens to be in 4th flight after Client Finished, which avoids most of the problems TLS 1.3 would have with tickets in- handshake. > > Certificate requests have context identifiers... > > I was more thinking about including the HandshakeType to distinguish the > ack for a NewSessionTicket from an ack to a CertificateRequest. Oh yes. I posted a rough sketch of such message, it had a corresponding field... > > I don't think this works, because KeyUpdate is not idempotent (causes > > problems if reply is lost) and worse yet, because of potential desyncs > > with the main data flow (IP packet reordering!). > > Maybe it should be made idempotent... You still have packet reordering even if it is idempotent... -Ilari From nobody Wed Jul 6 13:00:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B68912D1ED for ; Wed, 6 Jul 2016 13:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsciQYlOiPi6 for ; Wed, 6 Jul 2016 13:00:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 05B3312D10F for ; Wed, 6 Jul 2016 13:00:06 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ma1pn-1b0Cdw1Mvn-00LjAA; Wed, 06 Jul 2016 22:00:03 +0200 To: Joseph Salowey , "tls@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577D6342.2050708@gmx.net> Date: Wed, 6 Jul 2016 22:00:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ks9oOICuqi6bvavRF6iVnAm0BvbFmfkBp" X-Provags-ID: V03:K0:1Kpc5PKjC1bFGUDxRLsTjtSXUJRPWLB/uHwWObEp3UTjGCI+qbq 0k4Yn2ctJEEKkpVzCBeNNfQvZo9XrI01YB2M7wkM0ppNOmPSPuh1zo3XbqsfxGUGKShe/Oi hNPHEOM+Nbn5KhLURU+OEl9/w6E2hAYELsfEX3/doX50CgFA2wLI0Wjs2b0lK3MVwJVFLFd +4OLMnhD6gCExnpy/Yspw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Fe2PBzmEPpM=:MLPhau7RsScTsYvjZCnh3s TB/ILiJ3BBKf6x5bgyO+HDfe7KSHAmsqcBdnl3Q9XW+5UcjzOCflOEAOrPeJh9vbycgCUF9SD 6qfvfdWvAUrOXqFvfkLtlB4jwNLIrwQN1lGOJVjQRAEg8dQE7arAcAZP0M+Em4OH0ahhE2bTW PGwKcK5O1AZJDcJkQ0xU/iAfN/g5bSFywyXCQZ1f1oUjkhstDKSJ0NOPddlBcM6kOjSRAU/1U v5F4xxzoG0D9/ZoO2U9zX+0K/IqESSIOeZL1X5fkfGbz0zEzX7+AEcb+g8yZTzs755AY4sAkQ v1P5EDXIM0/OpfXPmH0XlNi4+Pt2POw2HhSfS4woAlhyrDvy3sfpkXwutkbIrya2q7NY/8ggK w4ggc6f5OSCgnicpv/QmdJeGO1zsIbUF5jLsllDV9HhfZrOdocXTMtjgDPbC8jhj9ctvsWn1s 3+U0l1QYryLPZBbzl2rEkC/Pw+XRdcxc5567/VQWmshhmzt0gFuCsepeBVf6OouT8HZf6rBbD 3UR+GTzBDwXbCJHMtSIxV4UoJyzzcyxiqAAMyJUCZJ2mwMG5PQb9xpIFr9YvwHYCfrL3uCeJ+ aGeT5DlUBMTOXPdsxPfbW+cjdmtAD+A+1SHfmYMNQzk1atfBlib/3astDWkZEresd8vSKE7nM HNG673XqpHbv5+cJ1JuvKRuStuJTKyC6bplFtw/kEiM+z1HCCsu9WnTH6/sq9mlwtnX23IJ41 uTR9JkNxgQpPYQT3Cc5VVhpb/10QwP4vjpU4RKu1cz6cNYy3aegFJopdRro= Archived-At: Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:00:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ks9oOICuqi6bvavRF6iVnAm0BvbFmfkBp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Joe, it might be interesting to note that in the context of the DTLS 1.3 discussion with Ilari it appears that the epoch exposes handshake messages (vs. application data) since you need a way to find out what key was used to encrypt the message (and msgs may get re-ordered or lost)= =2E So, I claim that even if you manage to go for option 1 in TLS 1.3 you will most likely have a kind of option 2 in DTLS 1.3 (unless you get rid of the epoch value, which is of course possible). This does not really answer your question but I don't have a strong opinion between #1 and #2. Separately encrypting the content type sounds feels a bit too radical to me. Ciao Hannes On 07/06/2016 07:39 PM, Joseph Salowey wrote: > We are the unenviable position of calling consensus between three > choices [0]: >=20 > - Option 1 - use the same key for both handshake and applications messa= ges. > - Option 2 - restore a public content type and different keys. > - Option 3 - separately encrypting the content type. >=20 > At this point the consensus is rough. >=20 > The first option we would broadly characterize as supported by the > implementers because they can=92t see the harm in using the same key bu= t > opposed by the cryptographers because it makes the proofs harder making= > mistakes easier to miss. =20 >=20 > The second option as supported by researchers/cryptographers because it= > cleanly separates the keys used but opposed by the implementers because= > it=92s unnecessarily complex. In general, privacy advocates do not > support this option either. >=20 > The third was not really discussed at all and it=92s not clear what is = the > impact to security proofs or implementations. =20 >=20 > As we see it the privacy concerns are somewhat of a moving target, > however not encrypting the content type seems worse for privacy than > encrypting it. >=20 > We are looking to eliminate option 2 and choose 1 or 3. If you are in > favor of option 2 then we need to know if option 1 meets your needs, if= > option 3 is better than option 1, or if you feel that the only viable > option is option 2. >=20 > J&S >=20 > [0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBui= NA >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --Ks9oOICuqi6bvavRF6iVnAm0BvbFmfkBp 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 iQEcBAEBCgAGBQJXfWNCAAoJEGhJURNOOiAtZmUH/1tRIcl3upRzIng4PHIbwxm0 AOvbBi1tpZ2iiXfI7VEuy2ABlwqWWn3m/mnykId96b9rUa/XT7a5G8B+93Gv7wva l2q299/1pUdAGvbuQkpvWqUXPjHXMn9qhdt5863GnfSZ5Gak5OUrp08yZco8u3aA MuVti6FtLZObhRUS5Zf7qgcbBAf1xHCjhZkCrdmiVmEn0FjVTwwfEERdWp784wFY DVsy0pOTyOkRW/B1BaJKGgoX23lXDLCCLF3qUmhJoRlI3hfj5oiv73t7H8agTBfm 7f4EmQZjddBCZUzjJPkwIx4j6dTeKjjtupXoj9cjmXih9b5enwcjqd0zYNxxc2w= =yJQe -----END PGP SIGNATURE----- --Ks9oOICuqi6bvavRF6iVnAm0BvbFmfkBp-- From nobody Wed Jul 6 13:09:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3794C12D123 for ; Wed, 6 Jul 2016 13:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA3DM_-yQjAP for ; Wed, 6 Jul 2016 13:09:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 20C2112D1C2 for ; Wed, 6 Jul 2016 13:09:07 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LkfdE-1bt7U01qqa-00aWi6; Wed, 06 Jul 2016 22:09:00 +0200 To: Brian Smith , Dmitry Khovratovich References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577D655A.40802@gmx.net> Date: Wed, 6 Jul 2016 22:08:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w2HSHaHSSD7VHi9eRd8oB8SDOUUJQTCTc" X-Provags-ID: V03:K0:74BsCBNcZcdYbxtOnm8bimHEOqT/gnIl/HAtK2qRTB3tujjqlPZ oi+BT1srJSTS5oZzrtppxcwPcnMxmRxeyG/4qPhfmXWtxShJH9ay0lwTQDYQThYjajMUVWx CO0Mp9Rg5CNavOFBl7VC2XX+tyGQfaVpotIen9TAdD3WRLp01LmKAl7pF4pH9Il1K0CzaOU 3v4K7KJjZdTLYzo1cBb8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:TKH3IM4AlQk=:8zETzPIat/2EdFOS9j+9EM 6faApTtB4PHMc+FSXNHX21Ipjm+ZAYJI5Nq8cxBWVZpLdDkYfb933aKcjSxvB5tbM/cWeqApe BaULMh9MsdhN8Qu4brwYGa5wdHS8W2PLdfQVlcyWFUYbi/MPQT+bHQBelM3K/FAIE6aUHC2M6 thZCT7/EkkIY2PMD5uT+TW0kN3DgE52gwNEkvpbGAe1jnZMKGtxNfmLNfsNSxfzZLPPMPxA97 Zn7/uEKegbucY4iGgUo4LsRc94LoOlFr2EfZ4hRx9vkSi5FuX4cFPthBXtWEcY8e04iL4zt1/ w2I299D/LsExEWoZpGqIm+Ll+FSrT27Ior8LQE6HoqAGFxCWa+xZpaCVE90BqVatdWPjPgMDX E6PSfK4gglH0Bz2470hFCKOdqwXDmw89kuxe+dOiIWGJZlVmiaTvDRavurm9NC+RhLP/okhM7 r4cUWDQsBjFQVKRySy2ut8IfZOpfxRiEaLqpIaY5rNPMEsTq9XmjIQk7X9Ba3M5v4nVqfi77o a73TxW31e6ykZw3Gqn4I0uUCtfAfdLxI2gnf1rwt3sjAoiQfwusKEaHV3+0RHAofD9esFY+g+ eK608RE/YZjSrFqzUjVT8hiCbzDo8rnzAtJTjPv4HCx+5+9ub1yIE33H/4zkYE7ghah7I7iOR 3ruyfDfqgE6uK6MDa1dvnZwUyJKbvsZowSekSkdoPTvAKbXFdo96T8dH5a1SCzscr3MtkDJJV SvOuTk8/UrN5H1tH817YoOpMNSasEwnG5+sKFe3zdONUWRzU/SidhBVypkg= Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:09:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w2HSHaHSSD7VHi9eRd8oB8SDOUUJQTCTc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Brian here on this issue. This is clearly impractical for IoT devices. For many of those devices we are talking about 32 KB (in total). On 06/29/2016 09:25 PM, Brian Smith wrote: > Dmitry Khovratovich wrote: >> It allows cheap and memoryless verification by the server even though = the >> puzzle solving guaranteely requires dozens of MB of RAM from a client >=20 > I feel like this is impractical simply because lots of people are > building HTTPS clients that don't even have dozens of MB of RAM total. > I think we should avoid doing anything that requires the client to > have more than ~16KB of memory total to devote to TLS stuff. > Otherwise, we force the internet to have an architecture where all > small devices require a smart proxy to solve these puzzles for them > and do other things. >=20 > Cheers, > Brian >=20 --w2HSHaHSSD7VHi9eRd8oB8SDOUUJQTCTc 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 iQEcBAEBCgAGBQJXfWVbAAoJEGhJURNOOiAtj48H/0MBObh+a+NGa740G/06arT0 kF6mKKfmu+g2NLrNWRNZkY/ldTk/VvxrEuf6kFZ11QbMtwhvYNX0TExn0LbSn6Ui L2+PuANHsRPQPcJDxdnweoqJmIHacdwjHBzcYHQFIirWWe6cxaFk4qlczIBL9bc/ YlabiiNbR+DoXUxZaP5EqiISGo25MPrboOaxLJHjSZepWpjUwooBdWEQHpb1DUhv 0B8Q5HdPLKCnWCZ5yhVOORe1wAkGT3N7aGuN0zHmx92U3qLxW7Vnk0/B+tz7jllz aLh3/Lltov9OfdS5REWQ2e7eBClqLlmUCsvvHpZ8/1iuhrrXkBlmCanOfZ2Tl14= =Phh8 -----END PGP SIGNATURE----- --w2HSHaHSSD7VHi9eRd8oB8SDOUUJQTCTc-- From nobody Wed Jul 6 13:11:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4D12B018 for ; Wed, 6 Jul 2016 13:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KQAe2AbLR2m for ; Wed, 6 Jul 2016 13:11:28 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E052412D5D7 for ; Wed, 6 Jul 2016 13:11:25 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1E038423982; Wed, 6 Jul 2016 20:11:25 +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 C1E08423979; Wed, 6 Jul 2016 20:11:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1467835884; bh=1EdV4gfUgYtT7/PnsEs6LsQ7dJA0eznn6/e9R8Kdi2Y=; l=61; h=From:To:CC:Date:References:In-Reply-To:From; b=gfSyLVEXa5DnLQqXJuBuquXIQtSbiNoZL2EnCsDgkcR9vjB6+6oTD99wZ59UU2YB4 1AkQdXwCO+X/bE0Vo5rDKGbfBk+wg/M77GivGvr17MBcFTuJO7Zr70hfvSVZ661Z96 jIg57DtgX+m1L/pFnB0gIqfCaicP1mcBnhXP58hg= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BE0701FC88; Wed, 6 Jul 2016 20:11:24 +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.1130.7; Wed, 6 Jul 2016 13:11:24 -0700 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.1130.005; Wed, 6 Jul 2016 16:11:24 -0400 From: "Salz, Rich" To: Hannes Tschofenig , Brian Smith , Dmitry Khovratovich Thread-Topic: [TLS] TLS client puzzles Thread-Index: AQHR0ifFKnoDe2lp9E60Q5XBs1UiDaABFs4AgAsMZgD//72TEA== Date: Wed, 6 Jul 2016 20:11:24 +0000 Message-ID: <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <577D655A.40802@gmx.net> In-Reply-To: <577D655A.40802@gmx.net> 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.40.97] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:11:29 -0000 Do IoT devices generally talk to public-facing web servers? From nobody Wed Jul 6 13:16:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D712D123 for ; Wed, 6 Jul 2016 13:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAUqARYmJ6bS for ; Wed, 6 Jul 2016 13:16:17 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D191E12D1C2 for ; Wed, 6 Jul 2016 13:16:14 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id w59so122551588qtd.3 for ; Wed, 06 Jul 2016 13:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zR3LVS0/H3J/MjwOznMmvbl7klKNkzqdNyDK8u6qLEg=; b=J8IU2Sz/pZBrAGsjA46zGFJJLR0cToYcI1ELKWXfkxS4KshzI29z7PYQcZ5RnMeEQA z7sDjl2K+17zoUT18eTWRW072ZUIZS6n7G1fCT0Vh+t0/TqHEt/zH6xWIfm616ermPT9 Z4S3zYRKdo9AbhaSyWvks8XlUKKL0FGAwzQGM= 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; bh=zR3LVS0/H3J/MjwOznMmvbl7klKNkzqdNyDK8u6qLEg=; b=aq3iwQZ2wYLvVn5Gp4EwK/BZpytyM8jRAU7FpLeigi/dOijKsQbK/dcILk5d2I/wFw NgqEi4jLbYxWsh4eO0afyCXWF+Vxy6TAfuxFbZouTo6r5vnPJWxKO++t15yCMrBIQGLc 3hvyT0L+89lo/sRQPGh+u1P2DvlUsaCSGrhARs1qQUP3LNwv8QuXevkYrDrmA2Kd5LFs YpkMyh3QYxdUWHRgC0SNbgEwjR3GhVHkr1EpkZumGQVD0C18JkaA0g/te/7E/Zj7fiBR t7C+uUiS/2nmip+3yA1mjpWgPK8dRbOepD64vNF/Khl/WpcTbq3tOnvWVaaakNSl+18l b7yg== X-Gm-Message-State: ALyK8tJEMfHK2unUQbnV0xYzzdlJH5g/zhQ+xGkyUpqPhEqB/Z6I7fZp6BdLhRFWMZD19srMnrMYiV9Mw+enqw== X-Received: by 10.200.50.140 with SMTP id z12mr38318348qta.1.1467836173957; Wed, 06 Jul 2016 13:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Wed, 6 Jul 2016 13:16:13 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <577D655A.40802@gmx.net> References: <577D655A.40802@gmx.net> From: Kyle Rose Date: Wed, 6 Jul 2016 16:16:13 -0400 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11375df8bcdfd20536fd3dd9 Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:16:19 -0000 --001a11375df8bcdfd20536fd3dd9 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig wrote: > I agree with Brian here on this issue. This is clearly impractical for > IoT devices. For many of those devices we are talking about 32 KB (in > total). I continue to feel like this is a valid objection to the wrong proposition. I don't think the question is, "Should TLS client puzzles be issued by all TLS servers under load?" but rather, "Would client puzzles be a useful addition to the DDoS toolbox, and appropriate in some cases?" Kyle --001a11375df8bcdfd20536fd3dd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
I agree with Br= ian here on this issue. This is clearly impractical for
IoT devices. For many of those devices we are talking about 32 KB (in
total).=C2=A0
=C2=A0
I continue to feel like th= is is a valid objection to the wrong proposition. I don't think the que= stion is, "Should TLS client puzzles be issued by all TLS servers unde= r load?" but rather, "Would client puzzles be a useful addition t= o the DDoS toolbox, and appropriate in some cases?"

Kyle<= br>
--001a11375df8bcdfd20536fd3dd9-- From nobody Wed Jul 6 13:16:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965F812D143 for ; Wed, 6 Jul 2016 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlNfNwlhJurr for ; Wed, 6 Jul 2016 13:16:18 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE7112D0CD for ; Wed, 6 Jul 2016 13:16:16 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id m127so259320239vkb.3 for ; Wed, 06 Jul 2016 13:16:16 -0700 (PDT) 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; bh=y0XxZqkJmI67U6dBHdXCBzIcHlvs57bU7aBUmpDp26A=; b=ZUu+fEB4LHIj0y319soIwyMRsI1dOiO4DHV+9FiHKQvLDouojzl9Y6RSsYOwE4NB1H yqppial88Xh6NQM0hz6use+zMSgZ5P6zEUX6QTcJOT1nzf/K266Sx6olNfvX3ICrECdp Z1gKYWSSfauzDnMO+6jWnoLhM9Y45eBiN/8rjnTPew07NB32tiOYQmZLCRvHF0wmzh9E q3N3vX4GThngoD6nRNTilwv4hYPOZPYCf+FoEA6TFsCtDD3yKwXL692mXflkmKiTQEwp Wo+S4AWLEkvCGqxJrR2vbg39+6wnGtERM9XbuFZGuvrsKwXLtL+db135bxOCZzpsxnu0 Q8dQ== 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; bh=y0XxZqkJmI67U6dBHdXCBzIcHlvs57bU7aBUmpDp26A=; b=UTHp/h/4b6pXRWMbjabHzUhfb+tDl48x/3j+NlQhvOYWMosKyL12IVLIgLfOMnpoAK 8W4j62/XzYJ0FCNVBr0knAreixl/s4CgTHMeh7P3kj/v8kvhyTjzRBultXIej8BjAwed b145UI3Dq2gqVk5PRsK3j/hc3FEEV3irsp1md3U/2Cc2YcInnXvs/+WBrysdNB26WELu lAAd2S2Bju++k6X8UzmrORTrz0LO+awL3q4k3N+wTnRFXv5SVM25IRfrLOXAORkKhvbi LnzIYv5IF43x+KcANwiO+/SHI2pIU0JMMEtYyf2yRMHPGfby3TBMjjbg9AxkuLyDNNJE tRYA== X-Gm-Message-State: ALyK8tLKwe0VG6O9IKoCejjub48OmC/14cHGX0BQ34e7+7YcE5/tp85xhBlNTtrKbqyNN/U0uj8WoVmIzKUR5g== MIME-Version: 1.0 X-Received: by 10.31.56.69 with SMTP id f66mr10567800vka.135.1467836175795; Wed, 06 Jul 2016 13:16:15 -0700 (PDT) Received: by 10.103.15.2 with HTTP; Wed, 6 Jul 2016 13:16:15 -0700 (PDT) In-Reply-To: <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <577D655A.40802@gmx.net> <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 6 Jul 2016 13:16:15 -0700 Message-ID: From: Tony Arcieri To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a1143f0ecd8ce530536fd3def Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:16:21 -0000 --001a1143f0ecd8ce530536fd3def Content-Type: text/plain; charset=UTF-8 On Wednesday, July 6, 2016, Salz, Rich wrote: > Do IoT devices generally talk to public-facing web servers? > Yes, I'd consider that part of the "Internet" aspect of "Internet of Things" -- Tony Arcieri --001a1143f0ecd8ce530536fd3def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, July 6, 2016, Salz, Rich <rsalz@akamai.com> wrote:
Do Io= T devices generally talk to public-facing web servers?

Yes, I'd consider that part of the &qu= ot;Internet" aspect of "Internet of Things"=C2= =A0


--
Tony Arcieri

--001a1143f0ecd8ce530536fd3def-- From nobody Wed Jul 6 13:16:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCA12D64F for ; Wed, 6 Jul 2016 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MsAUYXL2-_L for ; Wed, 6 Jul 2016 13:16:22 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 4888B12D623 for ; Wed, 6 Jul 2016 13:16:22 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-05v.sys.comcast.net with SMTP id KtF6biKpl3MWRKtF6baOlx; Wed, 06 Jul 2016 20:16:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467836180; bh=BCCpSCBzwJskTVqj6x/kKk4sgLkAivgAbjrwaY8usQ0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L41WeuljGxGvtpbvIL6A3UBShMPuOe6YtpcTYhuYrzJYEnc7RkvNkPnguxuP1tLdi YeyTlGDIsE1xOyh2AXTsySyTd5iU0wktIgx7OSIMypOgVs87opbOXdd7nnCMM/U4hh y2Dr0xUR/hLf4k2OQCN/LD5jDCepeuMLSi7exgZ6Nq2AQjRMSUO7wD7YNax7uDlwVx dspkTMgTTazhh6CwhZVR3C1yZ3NZhXQdkqUCUosLK7C2WJaeLMOXHxGCVEXcK6GFDk h67HqBrRyCD93v9RYdcWBLCce7q+LdK4tFMCcGTskvumQbsehel8u7+FDXUFQPee7L yt/1MY/06Tu6A== Received: from [127.0.0.1] ([76.103.100.237]) by comcast with SMTP id KtF5bdAMZiy0wKtF5bs9SV; Wed, 06 Jul 2016 20:16:20 +0000 Message-ID: <577D6713.9030501@brainhub.org> Date: Wed, 06 Jul 2016 13:16:19 -0700 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 References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNh3WAtFMV17rt6v7s+xq8v0BjOhvhsssxknTJqBshM6p1wI+jhV90sIBexz6uXHSM5KyxvFdjl7vdk/lPOIIkh86rksJHuNhKPlXlOd/ViKW6ra4NfX Oc5RB83Y1wx9qzK/B6rRVZZcoJ34Nj0H9XILhz9NtwmNcWVtk62XEIRp Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:16:29 -0000 On 07/06/2016 10:23 AM, Joseph Salowey wrote: > I don't think we ever call consensus on this topic. It looks like there > is rough consensus to move forward with RSA-PSS as the MUST implement > algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5. > During the discussion it also seemed that it is realistic that we may > want to add additional types in the future. We may want better > separation of signature types of certificates and certificate verify. > > Cheers, > > J&S Was it really the consensus that the group didn't want to allow PKCS-1.5 negotiated for handshake signatures (for certificate verifies)? TLS 1.3 currently allows this agility for other signatures: the signatures in X.509 certificates. Nobody has objections to a MUST implement and MUST prefer RSA-PSS in TLS 1.3. From nobody Wed Jul 6 13:20:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A312D65F for ; Wed, 6 Jul 2016 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeQ4--vNvBff for ; Wed, 6 Jul 2016 13:20:13 -0700 (PDT) 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 610C512D650 for ; Wed, 6 Jul 2016 13:20:13 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MhNk6-1azO8r39cI-00MdGl; Wed, 06 Jul 2016 22:20:00 +0200 To: "Salz, Rich" , Brian Smith , Dmitry Khovratovich References: <577D655A.40802@gmx.net> <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <577D67ED.9090307@gmx.net> Date: Wed, 6 Jul 2016 22:19:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5F1SPoLKOpfTLddSgPWoTLjU7IdiJDmMn" X-Provags-ID: V03:K0:jSOExZN+WTei4NTk9uBxudoM63T76s1GVcrO/uzkDRVG7BbxhtW eorUvqp8T9ccxQagc5DtAxSisigJ0/MO53hbSkv9HMRJIVNqmbhpppIV1XJukAY9Q/KIPvG Y7pOf/Ve/8yzEgoq3t3UiAdEEfXe/FDKsLYB59iJRp2dzTxcX2eWac/PBWh6Vf8G8ET+TLQ nQXQWG3j79eLlgxw8c2Gg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/vKf5AHJEC8=:HYUljcEAn2tb0LLbmrS0ke FGDj/90Lo2LNuP6P0xlZbylQHZB+U2hvIedsWM+eOd6oOlgWq1lkC4DAN5+n2eX4awqIIZxC9 +H60tmDBVLDeDGw963jY2zlcV8yuQzg0RbFxvjDxeO1KZd/wPvTWL9n1v9mEAapLyEHjKOdj0 r8UWVuqkWTX8iMUhllpoGV2p7LOZroSNy1+JPorcnjcEwMpWytcncqcNsERUVeqJDmV9voG3d mhLJR9/jV6cCR/znwMD2+so8CHLmTF1RqmtDkrozlX5oio45iD/TZfdwx5icBHc6cvHLTfmYm 6x6HjA0MJCH+7kpS8bXvPNHTVG1pebfrIeHDEKkVT6mb0ar3RLKFWTGoWLN9BKuwMv9cQ7dD7 8iQ7vdy7oVqe5YaU/0f02vCCcyS//ufWnTXCQJiYs0KppSTelIj4D1zMTDx1mnj8seZVLoVJp kuQhwSDw2vQYrjspTMjG0usk84w0ysCb1AB+GpwvoE5kBIrzErbVFaXom/eANMZq9lhAovMmg FT0S5dkdf/IK+hNwnAahCQ7inC3mh6w0CL/bPZ+AoLosELcCkaKv7Z4xXudlhD8QBJajbTVLy AWkunQeYOdPFRaLW4DUmjU0vZf5ngf7yuOYcFLnh8OgKedD9ln+qg4ySHXQsCIloGHSSlXdLP RxqNiTlEYlgcKkhNJr34NsdmCPASECSz+bHu4uO3gQDRg4GNrDKbqM0mbRakGswnNRhLCvJfy n1jm0ixf+SE/CabibfqS/oWTHRTVyPnPTZXWB0+qSR5hxtQhxIlBiwoD9Es= Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:20:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5F1SPoLKOpfTLddSgPWoTLjU7IdiJDmMn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/06/2016 10:11 PM, Salz, Rich wrote: > Do IoT devices generally talk to public-facing web servers? There are different deployment scenarios, as outlined in this ISOC publication: http://www.internetsociety.org/doc/iot-overview In one frequent deployment model the IoT device connects to the cloud infrastructure to upload sensor data and to wait for commands. This communication would be secured using TLS. You can even play around with such services, if you have spare time. IBM (with Bluemix), Microsoft (with Azure for IoT), ARM (with mbed), and many others are offering such functionality. Ciao Hannes --5F1SPoLKOpfTLddSgPWoTLjU7IdiJDmMn 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 iQEcBAEBCgAGBQJXfWftAAoJEGhJURNOOiAtP+sH/27ZXilM0CIs00sVxBK2pgxe cVgOou6A6hcMVgmLJIdm0e2x9KHxEzyL8t8MGDME6AmBhQV7suX+cCVR/05CngXo JGcMRO+Nhadrnl49Vqilfz2iwObCSjWjlLYPC6MB21qHH8cee0a3kye1+jpPm1LB hTR7AX/EP+jiA2wm8ugxBmgWVmpbNHzY7ZNWIsD40g9doNgN6BGelc/5NW+4Pwgp nDq3I5BNv77wBo0qS7FbhNOE7GWO+KNqSTh2wjJwLMlIhFZNSh7nXfTv+ZFHc4BB CeHowqmNcECrp3JI3BWK9U5ZRcFpf1Heh3zl62lComHk1QfuFf6TiLKPwQ4DFtw= =1wqA -----END PGP SIGNATURE----- --5F1SPoLKOpfTLddSgPWoTLjU7IdiJDmMn-- From nobody Wed Jul 6 13:23:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956C412D662 for ; Wed, 6 Jul 2016 13:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MJGV9ccWg27 for ; Wed, 6 Jul 2016 13:23:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 92C4512D62D for ; Wed, 6 Jul 2016 13:23:28 -0700 (PDT) Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MCLQ1-1bBmfM05T7-009CaJ; Wed, 06 Jul 2016 22:23:25 +0200 To: Kyle Rose References: <577D655A.40802@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <577D68BB.5070605@gmx.net> Date: Wed, 6 Jul 2016 22:23:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0wFI3nHHDKuSjuqIQN16CVGfXP6dvRt3P" X-Provags-ID: V03:K0:soMO03gAI5fuI/j/xZMKZBEhk5DtIoDt+BU1sV8HDuOY2G8NL3w NFVjbj9PcqpzbwMO3+kZKSwzHnS/pfzDeKYVQyi4Q13etgz65kubVsFu/VRvP2qXgF0xs/8 gXJebXxE712TWVgL7VpColElkLuypHOrTu0SOJNBFz63bUHVpm8mZXPAeDtPX97nrA1WJMp KPbWdg8sHFmR7oBs3X5Rg== X-UI-Out-Filterresults: notjunk:1;V01:K0:azgm2GSmfM8=:njtsAxdq1X9W4ez4tdtQi1 qCSywXQ+bqXLBTXL185+03fZWQTlMdf+NxAVH+PNKjHhWql+VEOsywfsBAi8srFr4/EXZ46Gv MGlKS99N4On1Y99oenl26LZkPNzHfNENK2L0+fxSBnGK74SYNbNpaVrsDj+5dwOOOY7HJVhE2 781ezpFx8dj/T/MY7rSQXA40mSs6gK7azkHh5lubx+0khU2Tyx+w9Sjl6qSuuO9FtxQqZE/Pz xrAEnQXMVJSYjjZID/SkMRfLKphVcccLxnOeorkPpzn11qbDL8pxwSVhICf79FyCw0urCs3d9 7a9gu5Kgx3UmaJImfBw6nP4aCodTd0QUFCRftUz/ZIvSqBxFSxy6xRWJIhpRSjOLAibLx64/f 03PtcpKSoLjmJws1MbvUvAkjBaNB9ay+v8b+6592gzeSadIQ3Den+NzUQx3TF3iHehUY9K8L5 Q0h9YpUujHmnBb0UW8dvC7nE6UOSXs99/ENn5s1A/XRbIKvG3j+pMRcBENB3JmiqsF5oylbyw 9zjjhEtvdfvfeAhnR7UUZSxwdpC0HXaGbh93iurKqYUum9L1d+cz5+aI3E/avdslZDXSbywaF 9MRsug64rVFp9+qQ9bY06GYW9GPSFEgTROQPp3r7cXN8XN9JHA6UvrR5DyjJouoEtY2EUuvcV lKPoqOnuHnVfEp7TJPDCQwpfQtiuukCRMPl54jBzmGyb9BtAnWrfkxNFaHksKTYOzfJGM9Tcm 7EhVBCtRu1V/ASzubJ8/wKwsqhCIl7y+oNUbphYIiSuvNHW7dzoR5KYyMuk= Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:23:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0wFI3nHHDKuSjuqIQN16CVGfXP6dvRt3P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kyle, the question for me is whether it will be an effective mechanism when many devices just do not support it (for a number of reasons)? For IoT devices the reason is simple: they don't have MBs of memory. Even the regular puzzle technique has the problem that you have to adjust the puzzle difficulty and what is a piece of cake for a desktop computer kills the battery of an IoT device. (And note that I am not saying that IoT devices aren't used for DDoS attacks.) On 07/06/2016 10:16 PM, Kyle Rose wrote: > On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig > > wrote: >=20 > I agree with Brian here on this issue. This is clearly impractical = for > IoT devices. For many of those devices we are talking about 32 KB (= in > total).=20 >=20 > =20 > I continue to feel like this is a valid objection to the wrong > proposition. I don't think the question is, "Should TLS client puzzles > be issued by all TLS servers under load?" but rather, "Would client > puzzles be a useful addition to the DDoS toolbox, and appropriate in > some cases?" >=20 > Kyle >=20 --0wFI3nHHDKuSjuqIQN16CVGfXP6dvRt3P 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 iQEcBAEBCgAGBQJXfWi7AAoJEGhJURNOOiAtwl8H/RtSasBMYwuiFjN8SjdYh2Yg 5NY2tWv6fWKL9enBWkf2TwSY5Au9yYIHqLN1CwBVbB0MdYFj+E0t0cjJxBe46k80 gYtCxCAWWbU86j5s1danbLY6oa7XnOLPOkZAWHlPySz3zhtl32Bkz+jGi325eM5R pWoov6g1vuLWOuoKv8t+Gs+qur9lzXzpYIyB6YQetMBcECPO+3l29pFv4v6zKdow yepfXzWKJBPaafIKhtPFmUGFcTCDal0rD/fVcks538LgWNOXQDFH1ct2RSlw6OOg GGX5phRVzxYWekNY1q6SxCB3d+LWCDOfqbAIj8zdVUD4VzkGgDiO3EErhMKTfxE= =bIF3 -----END PGP SIGNATURE----- --0wFI3nHHDKuSjuqIQN16CVGfXP6dvRt3P-- From nobody Wed Jul 6 13:34:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9217D12D662 for ; Wed, 6 Jul 2016 13:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvhShVQ3SM8Z for ; Wed, 6 Jul 2016 13:34:39 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F2912D641 for ; Wed, 6 Jul 2016 13:34:38 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id m2so122801563qtd.1 for ; Wed, 06 Jul 2016 13:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cWdyihcuzzyy/Yd9DJuaHUaP077X89+uDXiXyKH/nnI=; b=FX0LiRtBsfZc4v14/DZzedaDOnHlrfj62hN9KHn/JTgqN5nPezPcxOyw6cW9OmY0G7 iI8yJa1OfR7Snrzte9JpEtjwzPw2XbPNwleub7J/poAzpqioJcmggrn1jQx9E3AgYyAg BIIYsjjPYHlim8HshtPuQ0PmDqwDhXzLz2zT4= 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; bh=cWdyihcuzzyy/Yd9DJuaHUaP077X89+uDXiXyKH/nnI=; b=OWTLNiaUtZRP4FJ6isHfgFWKCxrQvHf3ZXRNfj4BV6TD+qiTsIUiL47/Zzs1kgpDI1 HUsQcRczNaaCUOaIz4aAiGv6OmFqxn/0ZBYZb8w2R82Wb/mVOu6H1mW3Mz16xUPrxDBj FT+smieeqGMPJEr2BNZERZY0WedIvi+opK24II1drD/dKCSOZxoeJ+GdmPfSoRO7KYz4 XDm5eyvzZ9wVCCJQf8l5oEGXC7pGZsxRF+6/rptKUl/ZRE4nBt2a2/haiVWsL1qQTbuI JrSxU1G5jVBQonIEZrNjEmBXCit4vZ4PZa/jINMFYMWfQxb2XrdLzWMxyafuA63bKwLc qTqA== X-Gm-Message-State: ALyK8tKNAIKYjvalcgs2UDkSAEnHBNIumfRbAA6LiGTlnSmWw+qNifoiXecKumqBDewLxUjWRKSefqvCWKSVcA== X-Received: by 10.200.39.33 with SMTP id g30mr37857869qtg.16.1467837278055; Wed, 06 Jul 2016 13:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Wed, 6 Jul 2016 13:34:37 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <577D68BB.5070605@gmx.net> References: <577D655A.40802@gmx.net> <577D68BB.5070605@gmx.net> From: Kyle Rose Date: Wed, 6 Jul 2016 16:34:37 -0400 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113724348c02a30536fd7fde Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:34:40 -0000 --001a113724348c02a30536fd7fde Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig wrote: > the question for me is whether it will be an effective mechanism when > many devices just do not support it (for a number of reasons)? For IoT > devices the reason is simple: they don't have MBs of memory. > > Even the regular puzzle technique has the problem that you have to > adjust the puzzle difficulty and what is a piece of cake for a desktop > computer kills the battery of an IoT device. > > (And note that I am not saying that IoT devices aren't used for DDoS > attacks.) > The point I was making earlier was simply that many web properties have client population profiles that are overwhelmingly web browsers, and others that are overwhelmingly IoT devices: client puzzles might be helpful on the former, and useless on the latter. Objections that "IoT devices can't handle client puzzles" doesn't apply to web properties with a web browser client profile: it's like arguing that liver tastes bad when presented with strawberry shortcake: yeah, that might be true... but it's not relevant. Kyle --001a113724348c02a30536fd7fde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
the question= for me is whether it will be an effective mechanism when
many devices just do not support it (for a number of reasons)? For IoT
devices the reason is simple: they don't have MBs of memory.

Even the regular puzzle technique has the problem that you have to
adjust the puzzle difficulty and what is a piece of cake for a desktop
computer kills the battery of an IoT device.

(And note that I am not saying that IoT devices aren't used for DDoS attacks.)

The point I was making earlier was simpl= y that many web properties have client population profiles that are overwhe= lmingly web browsers, and others that are overwhelmingly IoT devices: clien= t puzzles might be helpful on the former, and useless on the latter. Object= ions that "IoT devices can't handle client puzzles" doesn'= ;t apply to web properties with a web browser client profile: it's like= arguing that liver tastes bad when presented with strawberry shortcake: ye= ah, that might be true... but it's not relevant.

Kyle=
--001a113724348c02a30536fd7fde-- From nobody Wed Jul 6 13:58:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF7312D660 for ; Wed, 6 Jul 2016 13:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZA8AXQClot0 for ; Wed, 6 Jul 2016 13:58:09 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c: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 69EF512D63E for ; Wed, 6 Jul 2016 13:57:59 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id d67so1887814vkh.1 for ; Wed, 06 Jul 2016 13:57:59 -0700 (PDT) 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; bh=lclMKXK+OOEKKcSLZK7BK7V/TieVlWw2/Z7d0T9/WI8=; b=TgQ0OzXjHsBilf6g/Z5SsyjmNzg775psT9r/y1KkQYbjys5iSmGQ2Ofz/Z8Aunj3jE 5q6lQZiOPh7LNZFXNTEAQfyIslwgaHI1XXBEJ3GfSmVCP675Bmazch30VvrcBpWlHSok YOnfw65Naw/astQyUl4TxEOIXxkq20Ct4A+O2lu3RQnpDxtii3m6AdtlVxtXPdHQolF2 4wdvsxVkZppMFLuA+VMi72VcvTYIB361r67A62PYnqUuHqSzbIfR4tQPHRXsMxQR1NKv NR5/IY1/E3JQbYpJlHM3ctk2blIVZaoMwto9EYkP2eHdSZqjGpkJ6e7WgvG4ffTSm1t5 /nOQ== 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; bh=lclMKXK+OOEKKcSLZK7BK7V/TieVlWw2/Z7d0T9/WI8=; b=W1ZiWqGCMza4uxraLlssB+izoeMC3HM+tcrNGnQwujvEJi6RhLBGOVuQu8bG8KmyPi IK2kyushsyRv0jd87BHlPCzv1JZI4+wiAoPvDQyayiBkifo5COoBx5sOZBkIEEI/Anx9 dPnxG7KRH188aPn3pxTmEz2OEgYEGEioRVvFDaDLhV6Lyx8O16eCfcGgoNVBCGBnBcc2 l6aqj4b9j5GQHaxF7w8wdmY2C+HcOUdsCaitLmnJUI5FDS+NauskSmlUEcRKszmaC5LY CY/pmxMmk66Lnpjhx/Bx60qdCUDmqqiYT2NfAYhxxcEjZs5YInteJpB/USImUABkTLxU ah+Q== X-Gm-Message-State: ALyK8tIbZBye/JZyzIXxIzLU2dw5V63+TQfaykZkMvdqH7TPg7OmFL4avQ9NkZtDwPhEzkqRKA4FmzxHx8A1LA== MIME-Version: 1.0 X-Received: by 10.176.6.131 with SMTP id g3mr10594155uag.29.1467838678543; Wed, 06 Jul 2016 13:57:58 -0700 (PDT) Received: by 10.103.15.2 with HTTP; Wed, 6 Jul 2016 13:57:58 -0700 (PDT) In-Reply-To: <577D6713.9030501@brainhub.org> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> <577D6713.9030501@brainhub.org> Date: Wed, 6 Jul 2016 13:57:58 -0700 Message-ID: From: Tony Arcieri To: Andrey Jivsov Content-Type: multipart/alternative; boundary=94eb2c1246aa05b7f40536fdd3d7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:58:11 -0000 --94eb2c1246aa05b7f40536fdd3d7 Content-Type: text/plain; charset=UTF-8 On Wednesday, July 6, 2016, Andrey Jivsov wrote: > Was it really the consensus that the group didn't want to allow PKCS-1.5 > negotiated for handshake signatures (for certificate verifies)? > Based on my read of this thread: yes. The consensus seems to be to disallow PKCS #1 signatures in TLS 1.3. -- Tony Arcieri --94eb2c1246aa05b7f40536fdd3d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, July 6, 2016, Andrey Jivsov <crypto@brainhub.org> wrote:
Was it really the consensus that the group didn't want to allow PKC= S-1.5
negotiated for handshake signatures (for certificate verifies)?

Based on my read of this thread: yes. The = consensus seems to be to disallow=C2=A0PKCS #1 signatures=C2=A0in TLS 1.3.


--
Tony Arcieri

--94eb2c1246aa05b7f40536fdd3d7-- From nobody Wed Jul 6 14:11:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1445312D10E for ; Wed, 6 Jul 2016 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30_mlJsGjc8u for ; Wed, 6 Jul 2016 14:11:44 -0700 (PDT) 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 B72CD12B04E for ; Wed, 6 Jul 2016 14:11:43 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id z126so125997408wme.0 for ; Wed, 06 Jul 2016 14:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HoEGTsoy31TnTsE0aBdYKG6zbcefcWsZF7tnAEc+OOw=; b=MuV9iTzEYuO34u9zwjYZX08vOPN1l+D0GMQ//l4EWkpkaiaZYyuxUvKbZrQyNB621Q VWf6J6AH7l+TJE9uCjHRvkivQnVWOVtlvKEn0wjkdqRBr5MhPBKC6MHET9+Rbfn1uSyj aIS+6indQ0qAB7kLZmcZIIXn5q1UIekMu/cQddKlMdQ6HKNsYuQ1HIOaogyT6VVci6ZH hLToVT0eJnHefMaRjIlUuop1LB4sTiVsLIEGwfnUAV/7wfdicQIJrnTYKyCmVAZBWKNV NNOqYJY76fSSGUokuGr7gd6t8CIrAwSG41zqphRhn9M+FV+pTB5o5CPhACVXHFc81iXu QXUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HoEGTsoy31TnTsE0aBdYKG6zbcefcWsZF7tnAEc+OOw=; b=FfE0JMcme51TxFP1qnXwVSE8WLP1lCsyhMqn32CoeBiz19lqe/vKYrncneVRzY6hU1 0Xyg9oxaK56FB3u+SXi0xENrhpU254fJf+M4WYbtTRxMEz24VaIe7kDOecm0iP57sWz5 TkvFalrq41QKJO9LklrLXJV1CKrH33F/tMJ0Q7OwBzl3uBT85QUJ+Uc0zonYt7NyoMJ9 nCnqPwvSkgmgW89r19IDS4ycBLBdr2dUivfKOHkNlHZ1GGiSPyt0+gQ/QRF/Z9nWXU/2 qqq/7/dV6VWJ2GWtVi3HITvDjfxoVpoS4S+p7zXFxpNpWCSHY9lP1apQQGH0fwaxg7mE edYQ== X-Gm-Message-State: ALyK8tJ255vodafeiW50NhAIkNbP8FzI7EnJmJH7GDAZKsffTthCrzh7XHNkTsEwMHJEnw== X-Received: by 10.28.18.203 with SMTP id 194mr24063696wms.75.1467839502044; Wed, 06 Jul 2016 14:11:42 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k6sm4660279wjz.28.2016.07.06.14.11.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 14:11:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Thu, 7 Jul 2016 00:11:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:11:46 -0000 Hi, Joe > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote: >=20 > We are the unenviable position of calling consensus between three = choices [0]: >=20 > - Option 1 - use the same key for both handshake and applications = messages. > - Option 2 - restore a public content type and different keys. > - Option 3 - separately encrypting the content type. >=20 > At this point the consensus is rough. >=20 > The first option we would broadly characterize as supported by the = implementers because they can=E2=80=99t see the harm in using the same = key but opposed by the cryptographers because it makes the proofs harder = making mistakes easier to miss. =20 >=20 > The second option as supported by researchers/cryptographers because = it cleanly separates the keys used but opposed by the implementers = because it=E2=80=99s unnecessarily complex. In general, privacy = advocates do not support this option either. >=20 > The third was not really discussed at all and it=E2=80=99s not clear = what is the impact to security proofs or implementations. =20 >=20 > As we see it the privacy concerns are somewhat of a moving target, = however not encrypting the content type seems worse for privacy than = encrypting it. >=20 > We are looking to eliminate option 2 and choose 1 or 3. If you are in = favor of option 2 then we need to know if option 1 meets your needs, if = option 3 is better than option 1, or if you feel that the only viable = option is option 2. I will re-iterate my opposition to option 2. Some occurrences on = non-application data records within a TLS session are initiated by user = action or application state. Best example is when the user sees a login = page and clicks the button that says =E2=80=9CLog in with = certificates=E2=80=A6=E2=80=9D causing (in TLS 1.2) a HelloRequest to be = send and a renegotiation with client certificates, or (in TLS 1.3) a = CertificateRequest to be sent followed by the client sending a = certificate. This is not some theoretical weakness. This is real = information disclosure. With TLS 1.2 you can look at the Wireshark = screen, point to the handshake record in the middle of the TCP flow and = know that this is where the user pressed the button. Of options 1 and 3, I can see that #3 is theoretically better, but the = design seems too baroque to me. I hope it can be done without adding a = whole new block operation to each record, and I prefer the simplicity of = #1, but I=E2=80=99m not really opposed to #3. IIRC there were some = cryptographers who were concerned about #1. We haven=E2=80=99t heard = from them that #3 solves their issue, have we? Yoav From nobody Wed Jul 6 15:19:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC91D12D0C3 for ; Wed, 6 Jul 2016 15:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud1fwHmwa_Ff for ; Wed, 6 Jul 2016 15:19:44 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF2A12D79A for ; Wed, 6 Jul 2016 15:19:40 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h190so7198143ith.1 for ; Wed, 06 Jul 2016 15:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcvP2RZuKimMvtJtAayF0s93nSqK8U3YaPIsAsWG/kQ=; b=DFWuKXwa3kB8A5xzqbAY/g7TEdjX84NkNvg0+8WJjjQ2f96sTLqzSC/b5RLy5dylEe QVOb0vAe/Eec2fCMg3p4dNGW2CLXAUbrXtu4rLUQje5FrfWiFyz9cu10qniy1iqZ9Bil OCa5mYFdhI9KEdFwoThgzoyYgSUD6/065+9AE= 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; bh=xcvP2RZuKimMvtJtAayF0s93nSqK8U3YaPIsAsWG/kQ=; b=E3zJ9lyKT/UPhBIv78sV04XMdt9vJYlfrHubMaSd7OmI6f0aVMO98nMxGlm5YN57KJ nl8fP5XuK5jjiaLls+rdq9pozhcUd7uivPMFzY64xkxF5PLBsjkzkEtxD0Wh5N1iQAGQ qSsYzuNKd1dNokiZD+1HSoj5ZptyGt/4FaysSQzO2sK3/SOmdYqMmMbruD9OHjkhl2rk 4DK/lKZMMCSg3gQD3QqHY6MFYb0a31JXW8of7A4FIGlCmpSC0I+9byJ7I9bRsRRuFv5s VZitOxd/R8AjDMDMwyGPzI1mjHCN5ibBSOyYWngh7v0yyluPidfxOOPCbya0zpj1A4gY XGNA== X-Gm-Message-State: ALyK8tIOzdegrrx7hK0I5EqzKekG1BuiPgs80KVHWULQRqyxC8KA+CAJdq0r0Mv+JYbAOmCzqOTT1eDlkQn7gIhi X-Received: by 10.36.13.19 with SMTP id 19mr22643449itx.76.1467843579904; Wed, 06 Jul 2016 15:19:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 06 Jul 2016 22:19:29 +0000 Message-ID: To: Yoav Nir , Joseph Salowey Content-Type: multipart/alternative; boundary=001a113f87342b07430536fef712 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:19:50 -0000 --001a113f87342b07430536fef712 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote: > Hi, Joe > > > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote: > > > > We are the unenviable position of calling consensus between three > choices [0]: > > > > - Option 1 - use the same key for both handshake and applications > messages. > > - Option 2 - restore a public content type and different keys. > > - Option 3 - separately encrypting the content type. > > > > At this point the consensus is rough. > > > > The first option we would broadly characterize as supported by the > implementers because they can=E2=80=99t see the harm in using the same ke= y but > opposed by the cryptographers because it makes the proofs harder making > mistakes easier to miss. > > > > The second option as supported by researchers/cryptographers because it > cleanly separates the keys used but opposed by the implementers because > it=E2=80=99s unnecessarily complex. In general, privacy advocates do not= support > this option either. > > > > The third was not really discussed at all and it=E2=80=99s not clear wh= at is the > impact to security proofs or implementations. > > > > As we see it the privacy concerns are somewhat of a moving target, > however not encrypting the content type seems worse for privacy than > encrypting it. > > > > We are looking to eliminate option 2 and choose 1 or 3. If you are in > favor of option 2 then we need to know if option 1 meets your needs, if > option 3 is better than option 1, or if you feel that the only viable > option is option 2. > > I will re-iterate my opposition to option 2. Some occurrences on > non-application data records within a TLS session are initiated by user > action or application state. Best example is when the user sees a login > page and clicks the button that says =E2=80=9CLog in with certificates=E2= =80=A6=E2=80=9D causing > (in TLS 1.2) a HelloRequest to be send and a renegotiation with client > certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by > the client sending a certificate. This is not some theoretical weakness. > This is real information disclosure. With TLS 1.2 you can look at the > Wireshark screen, point to the handshake record in the middle of the TCP > flow and know that this is where the user pressed the button. > > Of options 1 and 3, I can see that #3 is theoretically better, but the > design seems too baroque to me. I hope it can be done without adding a > whole new block operation to each record, and I prefer the simplicity of > #1, but I=E2=80=99m not really opposed to #3. IIRC there were some crypto= graphers > who were concerned about #1. We haven=E2=80=99t heard from them that #3 s= olves > their issue, have we? > I'm also curious which post-handshake messages are the problem. If we were to rename "post-handshake handshake messages" to "post-handshake bonus messages" with a distinct bonus_message record type, where would there still be an issue? (Alerts and application data share keys and this seems to have been fine.) For post-handshake client auth, is draft-bishop-httpbis-http2-additional-certs-01 still the plan for HTTP/2? It seems to me that, whatever we do for the HTTP/1.1 + TLS 1.3 case, we need to solve certificate auth hosted in application data anyway. So we don't gain anything overall for HTTP if these messages share fate with handshake vs. application data. And, as you note, this is where the information disclosure is particularly bad. The KeyUpdate messages themselves seem so inconsequential that I likewise can't imagine key separation is particularly important. But I don't understand the proof-related concerns, so perhaps I'm confused. NewSessionTicket I am willing to buy should share fate with the handshake and not application data. Though it still doesn't seem worth the complexity tradeoff to me. (With the caveat I, again, don't actually understand the proof-related concerns.) David --001a113f87342b07430536fef712 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6,= 2016 at 2:11 PM Yoav Nir <ynir.i= etf@gmail.com> wrote:
Hi, Jo= e

> On 6 Jul 2016, at 8:39 PM, Joseph Salowey <joe@salowey.net> wrote:
>
> We are the unenviable position of calling consensus between three choi= ces [0]:
>
> - Option 1 - use the same key for both handshake and applications mess= ages.
> - Option 2 - restore a public content type and different keys.
> - Option 3 - separately encrypting the content type.
>
> At this point the consensus is rough.
>
> The first option we would broadly characterize as supported by the imp= lementers because they can=E2=80=99t see the harm in using the same key but= opposed by the cryptographers because it makes the proofs harder making mi= stakes easier to miss.
>
> The second option as supported by researchers/cryptographers because i= t cleanly separates the keys used but opposed by the implementers because i= t=E2=80=99s unnecessarily complex.=C2=A0 In general, privacy advocates do n= ot support this option either.
>
> The third was not really discussed at all and it=E2=80=99s not clear w= hat is the impact to security proofs or implementations.
>
> As we see it the privacy concerns are somewhat of a moving target, how= ever not encrypting the content type seems worse for privacy than encryptin= g it.
>
> We are looking to eliminate option 2 and choose 1 or 3.=C2=A0 If you a= re in favor of option 2 then we need to know if option 1 meets your needs, = if option 3 is better than option 1, or if you feel that the only viable op= tion is option 2.

I will re-iterate my opposition to option 2. Some occurrences on non-applic= ation data records within a TLS session are initiated by user action or app= lication state. Best example is when the user sees a login page and clicks = the button that says =E2=80=9CLog in with certificates=E2=80=A6=E2=80=9D ca= using (in TLS 1.2) a HelloRequest to be send and a renegotiation with clien= t certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by= the client sending a certificate. This is not some theoretical weakness. T= his is real information disclosure. With TLS 1.2 you can look at the Wiresh= ark screen, point to the handshake record in the middle of the TCP flow and= know that this is where the user pressed the button.

Of options 1 and 3, I can see that #3 is theoretically better, but the desi= gn seems too baroque to me. I hope it can be done without adding a whole ne= w block operation to each record, and I prefer the simplicity of #1, but I= =E2=80=99m not really opposed to #3. IIRC there were some cryptographers wh= o were concerned about #1. We haven=E2=80=99t heard from them that #3 solve= s their issue, have we?

I'm also cu= rious which post-handshake messages are the problem. If we were to rename &= quot;post-handshake handshake messages" to "post-handshake bonus = messages" with a distinct bonus_message record type, where would there= still be an issue? (Alerts and application data share keys and this seems = to have been fine.)

For post-handshake client auth= , is draft-bishop-httpbis-http2-additional-certs-01 still the plan for HTTP= /2? It seems to me that, whatever we do for the HTTP/1.1=C2=A0+ TLS 1.3 cas= e, we need to solve certificate auth hosted in application data anyway. So = we don't gain anything overall for HTTP if these messages share fate wi= th handshake vs. application data. And, as you note, this is where the info= rmation disclosure is particularly bad.

The KeyUpd= ate messages themselves seem so inconsequential that I likewise can't i= magine key separation is particularly important. But I don't understand= the proof-related concerns, so perhaps I'm confused.

NewSessionTicket I am willing to buy should share fate with the han= dshake and not application data. Though it still doesn't seem worth the= complexity tradeoff to me. (With the caveat I, again, don't actually u= nderstand the proof-related concerns.)

David
=
--001a113f87342b07430536fef712-- From nobody Wed Jul 6 17:31:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6870012B022 for ; Wed, 6 Jul 2016 17:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGcD69IRkrXW for ; Wed, 6 Jul 2016 17:31:09 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977B412D121 for ; Wed, 6 Jul 2016 17:24:49 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id e3so2269100qkd.0 for ; Wed, 06 Jul 2016 17:24:49 -0700 (PDT) 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-transfer-encoding:message-id; bh=j4dS4PYc4NYPNJSRye+SgL/ffo/Ol+CPvL7sFB/Zfxk=; b=FGlpc4sigjGtRCCIJ5anPUK/y0+IlTujqCm16lpXx7CUsWOIq77/StfxiQZBMrhW0A 8f8kedZwDgYUAmNVAefkOmy0ZLpFqw2du33RSGL/mVM5ptB6fpvupO2Y1rRA7NsMepfJ AeEml7Ul8nX6hi07jSeOoXPssfPjgu7JtAjQ8V+QRTX/lWurvnVM0fW1nnL+oL5lrc4U LAww5Doe8+n7qmYkphVsq8bLf9bCsTo1peqWFhwgdF7/SfYaDTferBhp/CS0vuTKh8qo Ul2FFHtnwYZpKHIN2viJdrsXcjrvz7EJAdK8VCmq9n6L+/M6otLByp3fBBieFmbd35Bb BxVQ== 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-transfer-encoding:message-id; bh=j4dS4PYc4NYPNJSRye+SgL/ffo/Ol+CPvL7sFB/Zfxk=; b=Znp7N7vA3Ed9z3Q1iCpPK/GfGyE1S3PdakzsHNjtHoNwgZM4LD0LkPnRtCT7I6i/je OEjvzotc34bYHI4mm1HU7WgjXCszBkrY4sIL4CH+UODwIGau+QYRnvYtg+LAhbJ7i+gM ccZJNoOv62KudbeczWnOtDDV+x3aEvnxlAfmvDupjTYL1soWuoSjWk3y+eikJOjBgrW/ y/tuMD5wlKXcNseXb7B3RaN1IDwzxFBRC4Kuoq/A6cBJemmu//8B5Wdu1FbRS+VRqobS EEYyg/+iyPqIGCp2e3s4yChiAXcKLFBCZkgwLZrgyqulskttL6eqGxKKq04jlpmKfzz5 wOyQ== X-Gm-Message-State: ALyK8tJOOOczsM3hAK0jgNq9KOt02zcMacB//tBiS/qKxbCjfhxFD+vrVwTptj9eTwwqJA== X-Received: by 10.55.101.212 with SMTP id z203mr33238856qkb.147.1467851088726; Wed, 06 Jul 2016 17:24:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id f53sm2758363qtf.25.2016.07.06.17.24.48 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Jul 2016 17:24:48 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 6 Jul 2016 20:24:46 -0400 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: <201607062024.46745.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:31:10 -0000 On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > I'm also curious which post-handshake messages are the problem. If we were > to rename "post-handshake handshake messages" to "post-handshake bonus > messages" with a distinct bonus_message record type, where would there > still be an issue? (Alerts and application data share keys and this seems > to have been fine.) Recasting all the post-handshake handshake messages as not something named "handshake" does make a degree of sense, on its own. (bikeshedding: I'd name it something more descriptive like "secondary negotiation" messages or something, though.) Even if this doesn't directly help with the issue at hand here, does forking these into a new ContentType sound like a useful move, in general? Dave From nobody Wed Jul 6 17:33:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9166E12B022 for ; Wed, 6 Jul 2016 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8HpBQUWJRy4 for ; Wed, 6 Jul 2016 17:33:22 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9099112B054 for ; Wed, 6 Jul 2016 17:33:22 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id s7so315380qkf.2 for ; Wed, 06 Jul 2016 17:33:22 -0700 (PDT) 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-transfer-encoding:message-id; bh=po58ROMwOlcEzGvw0+RlJhZz1pVOGWds8e8G4V0EoU0=; b=Dg2Ghjk1bhVxe87bBelZ3TJhPjoOW31z3q8k++hry/a3QyQ9lDcSlB1PovXYmrTQHW TA6rrMJQPwxQfaOfjFU1eNRV/PAvMXDH0AWpZgQswxdHhyCH2N8gKRGFe16YCDxsRsno /Rqjg1xPh3wnAIA2nYFs1aIECk21+5sXxZJeEgr2SdWX827WFcUU58Y1tW4FcW6xcrMs n8yROLDY9c/8oJjOPsHFm5UR1K7WiG7PU3DUi0cUUh7nyJpqXyZITjGeB4v5wcoahXUS eVVKTc4rEnhmZxPx373sJ0sISSZWQbBhrxDUyoi2wgo5CZXtR2UMRVMhk7OoZZXo4Z2w iDig== 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-transfer-encoding:message-id; bh=po58ROMwOlcEzGvw0+RlJhZz1pVOGWds8e8G4V0EoU0=; b=PwrFPJWw2Q+qMPKPfvtQohn2Dw+7ZiwNHrDaAkb1/S39II59kCruNJFuRohxCRiYqm I6tSrfIL1SmUjkz9iIr+rSRKYToa20t48PYD7SJTBXU8F3VaqnObYmhgO6gVfMWRvqqY L8TJlREEpIuClkP/GfQc7OXjeUvoLeyJmDolUx+3WRTDa3K//PZZIAOQSjxqdsAcBT9O +w3R2XfW0D1JHjWvURqKKQ6MPYObF0YwPgUhzqTg5/Yuv2qMwTSK8uLLbzj6ngx6wdiG a2qBQE7iY7vEqPcQ56ROfnfEsfJmDx+5bibz0RN/oakR7YUcJEYwuOz/xI+paadPo62Z k64A== X-Gm-Message-State: ALyK8tJAMg2Vwe0S6jVAryEhiGl0+IVSaWkYDw+vj/YhXHzhOgqaiinr1n460kstZhtkzQ== X-Received: by 10.55.111.66 with SMTP id k63mr34430459qkc.22.1467851601615; Wed, 06 Jul 2016 17:33:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id k54sm2620869qtk.44.2016.07.06.17.33.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Jul 2016 17:33:20 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 6 Jul 2016 20:33:19 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <577D68BB.5070605@gmx.net> In-Reply-To: <577D68BB.5070605@gmx.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201607062033.19870.davemgarrett@gmail.com> Archived-At: Cc: Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:33:24 -0000 On Wednesday, July 06, 2016 04:23:23 pm Hannes Tschofenig wrote: > (And note that I am not saying that IoT devices aren't used for DDoS > attacks.) For that matter, I feel like IoT is a larger DDoS risk in the long-term than other arenas. A botnet of bazillions of little widgets with Internet access and no updates and distributed widely would be an even greater PITA to deal with than we've had in the past. IoT being currently incapable of attempting to use this system almost feels like a feature, rather than a bug. Dave From nobody Wed Jul 6 17:39:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88812B054 for ; Wed, 6 Jul 2016 17:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpoom0VT0J0L for ; Wed, 6 Jul 2016 17:39:44 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 59AA012B00D for ; Wed, 6 Jul 2016 17:39:44 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l125so2340745ywb.2 for ; Wed, 06 Jul 2016 17:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUECvPz3QWcKikUKteQxVnUqlSE3PRRQ+hpsRPnphzc=; b=CImGjBRc+YWJM8pqFMw9lUpit/tnLh2K329ajc2Wyq6VWtGLuVU7xKmHqnOl0gC1s7 EgpvIO5wDLLrop467Fn2ujCBxNG5rHtKORiMJ5M9Kc30mmMnMBf3Bang2JHaiYiCRFEq /V8J3qoocw6tmny6aLuxmUBkH5GEEAKOOsZlThvrzB92EHJ9UZXlRyvBUYVDbmiTAEYn XVd8N1p5yFGQP++FJGtbgug1mJG7Q1BpZCG9MiiYZauN9/DlkwFiDNiW4iBWfzn1I2Uo rF4R2KAB3yj1aKCTQvq2u01U6+N7nYi8FCekgFjnlK7gXRsnrfWuYtt0D+ciuFicL/J+ KJAw== 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; bh=VUECvPz3QWcKikUKteQxVnUqlSE3PRRQ+hpsRPnphzc=; b=Or2rsFR2TYipRBfgXSpTS3MGmBWlz/s6vT1DzYayYD7/UHSo6if9nxDjJ2iSDImd39 H7QKYG6P0GfTELvcbiE97qO8jP/giZwngal2mD/BP22OzSFQJHcfvWuzYwlhQ7VHviTK /3BvlZksIeNejekPVijHml4Cq1RcGtq3Pl8QvSjgLBQoGPrQ0SZZ7RYgLcmVs9meKmal F51lR4EF1RlHUlXE4+dknE81Mdg/KSstzPbUgWU4URZPVUnSnlUGr34JtUfVktCU/wym JV/+U8aM+x4noZfCSZuJKyWb8gvap6+kHFSvU9a0kGfXParAf6h5QKmehdY21Htwi+Xi 9qlg== X-Gm-Message-State: ALyK8tID26OuyBiWzKXduViSOwl4hbVEXrsQTx/2eCnK4jQV8U3at8VCy7kwwysjoPb1/BuQxGP3iTsgvuo0JQ== X-Received: by 10.13.199.68 with SMTP id j65mr18076313ywd.289.1467851983562; Wed, 06 Jul 2016 17:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.211 with HTTP; Wed, 6 Jul 2016 17:39:04 -0700 (PDT) In-Reply-To: <201607062024.46745.davemgarrett@gmail.com> References: <201607062024.46745.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 6 Jul 2016 17:39:04 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114dfc4a105bf0053700ec5f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:39:46 -0000 --001a114dfc4a105bf0053700ec5f Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett wrote: > On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > > I'm also curious which post-handshake messages are the problem. If we > were > > to rename "post-handshake handshake messages" to "post-handshake bonus > > messages" with a distinct bonus_message record type, where would there > > still be an issue? (Alerts and application data share keys and this seems > > to have been fine.) > > Recasting all the post-handshake handshake messages as not something named > "handshake" does make a degree of sense, on its own. (bikeshedding: I'd > name it something more descriptive like "secondary negotiation" messages or > something, though.) Even if this doesn't directly help with the issue at > hand here, does forking these into a new ContentType sound like a useful > move, in general? I'm not sure what this would accomplish. -Ekr > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dfc4a105bf0053700ec5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.= com> wrote:
On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If= we were
> to rename "post-handshake handshake messages" to "post-= handshake bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this se= ems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something= named "handshake" does make a degree of sense, on its own. (bike= shedding: I'd name it something more descriptive like "secondary n= egotiation" messages or something, though.) Even if this doesn't d= irectly help with the issue at hand here, does forking these into a new Con= tentType sound like a useful move, in general?

<= div>I'm not sure what this would accomplish.

-= Ekr
=C2=A0


Dave

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

--001a114dfc4a105bf0053700ec5f-- From nobody Wed Jul 6 17:45:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653E212D114 for ; Wed, 6 Jul 2016 17:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 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=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPrXPtcdtk3w for ; Wed, 6 Jul 2016 17:45:40 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B122E12D77E for ; Wed, 6 Jul 2016 17:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1467852339; x=1499388339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mHbNxQul2xnF1HfgQspT4TyIsKFsQaH4gYRiY61d3xE=; b=MW7lwzdBFBikA/6ovGfKn1mpvj2Dt2nM698Hc+XsYArDRb0R0d3tLYxO KWeAaEvgMHAur/Mubu7IXQOvS0vx61Zn3VI/jxA6cTW3gceRtGxz3Atb3 JhWAOq+RQ2sCdjzqEOj/Lj4IGyxMG+flaq0JXib23tg0u8egRA4ulGfJ2 M1cLBbEA3JiTbB7Nf+b8SD3OYXkQPJzwMQpFPsNvf8C/mSFh1Z/IteeEP msGAzMmcLODkjCJ5mw/S0TWFn4Ub05zv1zZ00WIDXvfvEoFbmW0q3hjjE TpLxpOlA5M2agMjgjZ3l57Du7BxsMQ9CIdHMIno6tPIHf53i/gRojqXEq g==; X-IronPort-AV: E=Sophos;i="5.28,322,1464609600"; d="scan'208";a="95395592" 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; 07 Jul 2016 12:45:21 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 7 Jul 2016 12:45:21 +1200 From: Peter Gutmann To: "Salz, Rich" , Hannes Tschofenig , Brian Smith , "Dmitry Khovratovich" Thread-Topic: [TLS] TLS client puzzles Thread-Index: AQHR0ifMhSMRr2YtRkOoLYY2KZ+m9qAACpUAgAsMZgCAAACuAIABFQW1 Date: Thu, 7 Jul 2016 00:45:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CBD223@uxcn10-5.UoA.auckland.ac.nz> References: <577D655A.40802@gmx.net>, <8ae7ab124e3f432b85bc6f876f3e1cbd@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <8ae7ab124e3f432b85bc6f876f3e1cbd@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: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:45:42 -0000 Salz, Rich writes:=0A= =0A= >Do IoT devices generally talk to public-facing web servers?=0A= =0A= Yes, in large quantities. Public web servers are often the only channel th= ey=0A= have to the outside world (apart from direct access on the LAN segment they= 're=0A= on, but that's often only for admin stuff).=0A= =0A= (This, incidentally, is one of the reasons why I'm pushing for TLS-LTS.=0A= There's a huge, and growing, amount of embedded stuff out there that needs = a=0A= long-term stable protocol that can be baked into it to talk to its C&C serv= ers=0A= securely. Some of the alternatives that are being dreamed up are... scary.= =0A= They make WEP look good).=0A= =0A= Peter.=0A= From nobody Wed Jul 6 17:49:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA66012B02F for ; Wed, 6 Jul 2016 17:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIz9BpnF_QsI for ; Wed, 6 Jul 2016 17:49:11 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74A012B00D for ; Wed, 6 Jul 2016 17:49:11 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f6so9127580ith.0 for ; Wed, 06 Jul 2016 17:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yyQ50iUfBQpU+3ypTPLpZ0EH7Qca/ddkM2JabIA/OWo=; b=CilyFVJ1PR8r2V+iEhiF49DiksHvS5O9RlYrZhQnYPwl3FJ1O2esq+kfEtz2dCW7lJ fA/a0Xva5bA65zy5LOIpL4U8D8Udybu7SNffqKixvNVbojgR2m1xKhJuTeGZEeM3yqb7 yjdbL+S9ByHhwfZlFD2HtHA9C0cLnn/BQbaA8= 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; bh=yyQ50iUfBQpU+3ypTPLpZ0EH7Qca/ddkM2JabIA/OWo=; b=lCtctOQ+92Rw52q0NEqFD6jFthUe4or88/ZtWOalcEjoDIrz/3mWsPZLdaaDrjtz5d 80DvGO4hW8+z4phUXUl0s+NTpyTqFzxHC7Bw0OkOIuvLD16tnDUhhY9DhSRPFgE0Vim7 qV66Y9AgfdFKuzzkRu7pSw51uRk2BMQTMBFeGUUN2R1cwYWpNseL9SIN2ahWgKtadVe3 32h6y7zSyHdt5L2N6PPVpclEjo/IUUxykIhI3JQNUFvWVNGu9+hSyi0XxGfK9ZhhES3T Nsnv1CjhE7zPftNQWFspxYYyo+E1hlsK/+mZcQ1Nn4itTAdBL8wGg3vHrMvWzF0ZPUei IFVA== X-Gm-Message-State: ALyK8tJH7euMy6OVbqsSx6v+5ZKBs/2pFWoNy6VVt63OqJNBKWhyqoQM44AXv1vdd6MX3lU8CE3xrtjpoN6C9AP5 X-Received: by 10.36.227.67 with SMTP id d64mr22928185ith.18.1467852550958; Wed, 06 Jul 2016 17:49:10 -0700 (PDT) MIME-Version: 1.0 References: <201607062024.46745.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Thu, 07 Jul 2016 00:49:00 +0000 Message-ID: To: Eric Rescorla , Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c111adae244ad0537010d28 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:49:14 -0000 --94eb2c111adae244ad0537010d28 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett > wrote: > >> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >> > I'm also curious which post-handshake messages are the problem. If we >> were >> > to rename "post-handshake handshake messages" to "post-handshake bonus >> > messages" with a distinct bonus_message record type, where would there >> > still be an issue? (Alerts and application data share keys and this >> seems >> > to have been fine.) >> >> Recasting all the post-handshake handshake messages as not something >> named "handshake" does make a degree of sense, on its own. (bikeshedding: >> I'd name it something more descriptive like "secondary negotiation" >> messages or something, though.) Even if this doesn't directly help with the >> issue at hand here, does forking these into a new ContentType sound like a >> useful move, in general? > > > I'm not sure what this would accomplish. > Me neither. To clarify, I mention this not as a suggestion, but to motivate asking about the type of message. If the only reason the proofs want them in the handshake bucket rather than the application data bucket is that they say "handshake" in them then, sure, let's do an inconsequential re-spelling and move on from this problem. But presumably something about the messages motivate this key separation issue and I'd like to know what they are. David --94eb2c111adae244ad0537010d28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6,= 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
On Wednesday= , July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If= we were
> to rename "post-handshake handshake messages" to "post-= handshake bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this se= ems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something= named "handshake" does make a degree of sense, on its own. (bike= shedding: I'd name it something more descriptive like "secondary n= egotiation" messages or something, though.) Even if this doesn't d= irectly help with the issue at hand here, does forking these into a new Con= tentType sound like a useful move, in general?

<= /div>
I'm not sure what this would accomplish.
<= /div>

Me neither. To clarify, I mention this = not as a suggestion, but to motivate asking about the type of message. If t= he only reason the proofs want them in the handshake bucket rather than the= application data bucket is that they say "handshake" in them the= n, sure, let's do an inconsequential re-spelling and move on from this = problem.

But presumably something about the messag= es motivate this key separation issue and I'd like to know what they ar= e.

David
--94eb2c111adae244ad0537010d28-- From nobody Wed Jul 6 19:09:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2DD12D093 for ; Wed, 6 Jul 2016 19:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XpEPQUvDcMu for ; Wed, 6 Jul 2016 19:09:32 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 0A17712B01C for ; Wed, 6 Jul 2016 19:09:32 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id m127so3340330vkb.3 for ; Wed, 06 Jul 2016 19:09:31 -0700 (PDT) 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; bh=S4yiaAWvvfbUGeTVthZkAuNzAk6WKnsyJB42k2tduv0=; b=neU9vuumlkriMIb1E9PwSKOlk4dcK2/o8vA3Gv9VY/ft+WUFeNTGdDIP5KVEaOPQYK mE6ll3yNpDr4xc42MvAm534m6DBmDafEBqi6hYGzQxsKLdQwsmwSUsLRDgpnl0GbLUba 3uynHiLTdYl8NrGIIvtvdvH8+RXN7X0poDmlTShhtuc+nb359iVdNOzVtfc6MLlkGMOE WWHk/avrbyCYQmK3mtXkwecdm9qWQj8VmwyqwJi6LxUVtBqk40gKTte9dEEIxou0ImhW DIh1k0B8dELlmT+36an0MqEPQKfV26LuXP+50t6F17wnf71/Dcu4Jvjz2DusqGkY0OW2 ut6g== 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; bh=S4yiaAWvvfbUGeTVthZkAuNzAk6WKnsyJB42k2tduv0=; b=M/ffrN4SfhXWxALpgX0TCeDsguHu741tfEFiDNkZbONg9+6EJKz7cAcCwvxXayzYGg BATy9wb6LW7jpMHJRYY9X2lqaBG/3CTNzp5Nwfj7vCbNaJLx4/1kKFJjN/jtcrvlVadV zQlm8ia7jNL+sYYZtlmQtXX0DvUhNetTHwyPJYivnlpb6GRWeL8MCa8yxB3oilgrdW8E sS32nwyB6RTUpB8o/QnGIrlb9UcSPKcXWDlRVbomUPky830Hy08HFWCDZfwZTSNnQaV9 7PC1u/v/C1exZSCua7nWHly5nWrfeYzpZHHICc+8McdTkopDvGOuIe19cwQ597pwr1uu zQFQ== X-Gm-Message-State: ALyK8tIm8nj2suuzLHq8poyMObkSd6+sM3c5bJumZNXzyrJS/m/i7aoDUfStr7bcJ+Rc/p1rpHQfSFijLbm2cg== X-Received: by 10.159.33.201 with SMTP id 67mr7567452uac.90.1467857371096; Wed, 06 Jul 2016 19:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Wed, 6 Jul 2016 19:09:30 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Wed, 6 Jul 2016 19:09:30 -0700 Message-ID: To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 02:09:33 -0000 On Sun, Jun 19, 2016 at 3:51 AM, Aaron Zauner wrote: > Hi, > >> On 06 Jun 2016, at 21:05, Peter Gutmann wrote: >> >> TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or >> less stabilised, incorporating all the feedback I've had for it (there's only >> one open question still remaining), so I'd like to request that it now be >> adopted as a WG item. >> >> I'd also like to request an early/temporary assignment for an extension ID, to >> provide something a bit more usable than the much-overloaded 0x42 that's >> currently being used. > > Although I appreciate the effort, I have to agree with previous comments: we're working on TLS 1.3 -- I do not support the adoption of this draft. What is wrong with simply following all of the dictates in UTA? This draft asks embedded vendors to implement even more logic to achieve what could be done without anything but configuration changes. It's not a profile, but a new protocol. > > Aaron > > _______________________________________________ > 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 Jul 6 22:10:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8CD12B006 for ; Wed, 6 Jul 2016 22:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SktxTObTRFS for ; Wed, 6 Jul 2016 22:10:25 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 B347012D0E7 for ; Wed, 6 Jul 2016 22:10:24 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a66so17188194wme.0 for ; Wed, 06 Jul 2016 22:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=puDRR3vUOmg04/oR9suMAgyX8iL1wo503YuRCBaJ0LU=; b=1FAWl3VbJtoB1cWhqxj21JsIy51u4PeI4eN73tpPtQWUtnSOdO2EzTYfRPgAmE2DpF ChSOK3H1fq6n+vqN/AQD4aVrfMQ0JdztuhgoMl8HDXtbvf0851QBfSOiueyUPLQAenO1 b68makl5Ew+RAEMmhzYiyF11X1rukLPHaiyLknZhsTFxA444P+slR+5cwOWPJMIpuCFT 3NMQlvbHj1n7P/plIjtaKd2E13e1L8LFswaxqtHu5IU6Zf4w2N5n3qsORwFtFRH2kzzx smW2gaeYwdznsQWNJSQyftQn9AOBUEtK9Xft25ckcjqeBU+NdLlehRjFYJTvCCcUrXi4 /Biw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=puDRR3vUOmg04/oR9suMAgyX8iL1wo503YuRCBaJ0LU=; b=ULnqQWUmInpQw5RA8vJboJyeP5YcX4NwDzCOYta3Pg0mFvTSLTonct0jGWhKFhFtY8 eYaCWxhlz3kl2uIYavVcVL6dZqnicM0QSDxTGmHXyDVJCLM7pDHBkOlJ/JRLOQPeDYi0 /3mqEdcWpeMvixrVF5AZET8h+qbxdZv6MJ0cDl7kROOtejqkfmGBQ+z9BTe7P9N5dQMW l53QN2obCUpCYdX5xTQa6YFzgBvNATDutxYZ4cy85bFh1dTwT1v10M+TWP2sKqOZDK2g 2PVY/T/RHscFJF5a1FpcI/91NFkn6WICmTRJeZ8Miuc84pggOSY6vJkraSuKpPoIv1qk CE/w== X-Gm-Message-State: ALyK8tJ6Xh4YoM+vn25nd/wyViOHfTUxE71ckxC3/LHwv+vK+J8ktTeNnmLm6wFUU+AvWQ== X-Received: by 10.194.220.234 with SMTP id pz10mr14182049wjc.142.1467868223175; Wed, 06 Jul 2016 22:10:23 -0700 (PDT) Received: from macbook-pro.local (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id r127sm1125902wmf.21.2016.07.06.22.10.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 22:10:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Thu, 7 Jul 2016 07:10:20 +0200 Message-Id: <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> References: <201607062024.46745.davemgarrett@gmail.com> To: David Benjamin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 05:10:26 -0000 --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If we are left with 1 or 3, the miTLS team would prefer 1. On the cryptographic side, Hugo has a recent (draft) paper that seems to = provide some more justification for (1), at least for client authentication.=20 I know this is a bit off-topic, but the miTLS team would also like to = get rid of 0-RTT ClientFinished=20 if that is the only message left in the 0-RTT encrypted handshake = flight. That should remove another Handshake/Data key separation from the protocol, leaving only 3 = keys: 0-RTT data, 1-RTT handshake, and 1-RTT data.=20 Best, -Karthik > On 07 Jul 2016, at 02:49, David Benjamin = wrote: >=20 > On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla > wrote: > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett > wrote: > On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > > I'm also curious which post-handshake messages are the problem. If = we were > > to rename "post-handshake handshake messages" to "post-handshake = bonus > > messages" with a distinct bonus_message record type, where would = there > > still be an issue? (Alerts and application data share keys and this = seems > > to have been fine.) >=20 > Recasting all the post-handshake handshake messages as not something = named "handshake" does make a degree of sense, on its own. = (bikeshedding: I'd name it something more descriptive like "secondary = negotiation" messages or something, though.) Even if this doesn't = directly help with the issue at hand here, does forking these into a new = ContentType sound like a useful move, in general? >=20 > I'm not sure what this would accomplish. >=20 > Me neither. To clarify, I mention this not as a suggestion, but to = motivate asking about the type of message. If the only reason the proofs = want them in the handshake bucket rather than the application data = bucket is that they say "handshake" in them then, sure, let's do an = inconsequential re-spelling and move on from this problem. >=20 > But presumably something about the messages motivate this key = separation issue and I'd like to know what they are. >=20 > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If we are left with 1 or 3, the miTLS team would prefer = 1.

On the = cryptographic side, Hugo has a recent (draft) paper that seems to = provide
some more justification for (1), at least = for client authentication. 

I know this is a bit off-topic, but the miTLS team would also = like to get rid of 0-RTT ClientFinished 
if = that is the only message left in the 0-RTT encrypted handshake flight. = That should remove
another Handshake/Data key = separation from the protocol, leaving only 3 keys: 0-RTT data,
1-RTT handshake, and 1-RTT data. 

Best,
-Karthik


On = 07 Jul 2016, at 02:49, David Benjamin <davidben@chromium.org> wrote:

On = Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 6, 2016 at = 5:24 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On = Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If = we were
> to rename "post-handshake handshake messages" to "post-handshake = bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this = seems
> to have been fine.)

Recasting all the post-handshake handshake messages as not = something named "handshake" does make a degree of sense, on its own. = (bikeshedding: I'd name it something more descriptive like "secondary = negotiation" messages or something, though.) Even if this doesn't = directly help with the issue at hand here, does forking these into a new = ContentType sound like a useful move, in general?

I'm not sure what this would = accomplish.

Me neither. To = clarify, I mention this not as a suggestion, but to motivate asking = about the type of message. If the only reason the proofs want them in = the handshake bucket rather than the application data bucket is that = they say "handshake" in them then, sure, let's do an inconsequential = re-spelling and move on from this problem.

But presumably something about the = messages motivate this key separation issue and I'd like to know what = they are.

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

= --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5-- From nobody Thu Jul 7 00:27:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138C12D0CA for ; Thu, 7 Jul 2016 00:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf5TVxu-lnxX for ; Thu, 7 Jul 2016 00:27:06 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8894712D08E for ; Thu, 7 Jul 2016 00:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AD649519E; Thu, 7 Jul 2016 10:27:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 2ybVDVMQLSS7; Thu, 7 Jul 2016 10:27:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 208512315; Thu, 7 Jul 2016 10:27:04 +0300 (EEST) Date: Thu, 7 Jul 2016 10:27:01 +0300 From: Ilari Liusvaara To: Karthikeyan Bhargavan Message-ID: <20160707072701.GA28712@LK-Perkele-V2.elisa-laajakaista.fi> References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 07:27:09 -0000 On Thu, Jul 07, 2016 at 07:10:20AM +0200, Karthikeyan Bhargavan wrote: > If we are left with 1 or 3, the miTLS team would prefer 1. Yeah, me too. > On the cryptographic side, Hugo has a recent (draft) paper that seems > to provide some more justification for (1), at least for client > authentication. Personally, I would be very surprised if (1) the way it is used in -13 turned out broken, unless the application did very odd things (that would likely render security of 2 or 3 questionable as well). But perhaps there is some very nontrivial way to screw up using just one key, a way that doesn't involve rather obvious mistakes, e.g. - Encryption failing basic security notions. - Context-sensitive messages. - Rather obviously disclosing or leaking keys. - Broken channel muxing. - Applications carelessly doing raw read/write. For the above, either nothing obvious comes up with draft-13 designs or using multiple keys wouldn't really help. For DTLS, I noticed that there might be issues with replay of handshake messages (key separation obivously wouldn't help here). Fortunately, all messages that are in DTLS seem to be idempotent... As extra safety measure, one could require handshake messages to be always be replay- checked (turning replay checking off would only turn it off for appdata messages and leave it on for handshake messages). > I know this is a bit off-topic, but the miTLS team would also like > to get rid of 0-RTT ClientFinished if that is the only message left > in the 0-RTT encrypted handshake flight. That should remove another > Handshake/Data key separation from the protocol, leaving only 3 keys: > 0-RTT data, 1-RTT handshake, and 1-RTT data. Oh yeah, that message is sure annoying to handle... And in (Stream)TLS, it is supposed to provode a MAC. Isn't there going to be sending at least one encrypted 0-RTT data record (if only warning alert 1)? Seems like that would provode a MAC. Things are quite a bit different in DTLS tho: Since there is no reliability for any appdata, without Finished there might not be a MAC available even in case of 0-RTT being accepted. Based on some quick thinking, I don't expect the previous to be a problem, given that if 0-RTT keys are wrong, all the other keys are almost certainly (within collision margins) wrong too, triggering an abort on next encrypted record. > > On 07 Jul 2016, at 02:49, David Benjamin wrote: > > > > On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla > wrote: > > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett > wrote: > > On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > > > I'm also curious which post-handshake messages are the problem. > > > If we were to rename "post-handshake handshake messages" to > > > "post-handshake bonus messages" with a distinct bonus_message > > > record type, where would there still be an issue? (Alerts and > > > application data share keys and this seems to have been fine.) That wouldn't really help: It isn't distinction between main-handshake and post-handshake messages that is the problem (those are key-separated anyway!), but distinction between post-handshake and appdata messages (or lack thereof). > > Me neither. To clarify, I mention this not as a suggestion, but > > to motivate asking about the type of message. If the only reason > > the proofs want them in the handshake bucket rather than the > > application data bucket is that they say "handshake" in them then, > > sure, let's do an inconsequential re-spelling and move on from this > > problem. > > > > But presumably something about the messages motivate this key > > separation issue and I'd like to know what they are. What I think the issue here actually is: If you are going to use the encryption key used for application data for _anything_ else (such as using it to encrypt any sort of "control" messages) you have to be careful that the uses "don't step on another's toes". And then when doing security proofs, you need to also prove that the uses don't interfere with each other. There has obviously been some very bad communication here, so the above understanding might not be correct... -Ilari From nobody Thu Jul 7 01:13:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE87512D5A9 for ; Thu, 7 Jul 2016 01:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKkOSYTw8VdO for ; Thu, 7 Jul 2016 01:13:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672E112D56D for ; Thu, 7 Jul 2016 01:13:56 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A3273C049E16; Thu, 7 Jul 2016 08:13:55 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u678DhiQ021050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jul 2016 04:13:54 -0400 Message-ID: <1467879217.3426.17.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Farrell Date: Thu, 07 Jul 2016 10:13:37 +0200 In-Reply-To: <577BC302.5050000@cs.tcd.ie> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> 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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 07 Jul 2016 08:13:56 +0000 (UTC) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:13:58 -0000 On Tue, 2016-07-05 at 15:24 +0100, Stephen Farrell wrote: > it doesn't contribute nor affect the security in any way). > > > Does that id need to be static? If so, then it'd act as an > > > additional way to track a user roaming over different IP and > > > ports. That'd be a pity. If such an id is useful, maybe there's > > > a way to allow it to change as well, in a way predictable for > > > the server. > > Could be, but I don't have a use case for such  > Hmm. I'd hope we can all share a use case of bring more > privacy-friendly where possible and of not introducing > changes that are privacy-unfriendly unless absolutely > unavoidable. Thank you, now I understand your concern. However, I would like to point that a static identifier does not make the situation any worse than we have today. DTLS over UDP (or any other layer) is not anonymous, and DTLS as a protocol it was never meant to be. Moreover, any method to have a dynamic identifier should be of complexity that would make such an approach reasonable for a server to calculate without state (the problem this identifier solves is that a server doesn't know to which client this session belongs on receipt of a packet, thus it would have to calculate any dynamic identifiers without any state). regards, Nikos From nobody Thu Jul 7 02:37:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682012B037 for ; Thu, 7 Jul 2016 02:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha0LoGGrCxGi for ; Thu, 7 Jul 2016 02:37:37 -0700 (PDT) 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 9473B12B013 for ; Thu, 7 Jul 2016 02:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A922BE38; Thu, 7 Jul 2016 10:37:36 +0100 (IST) 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 llW1Ma5Zrh_N; Thu, 7 Jul 2016 10:37:35 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BBF70BE2F; Thu, 7 Jul 2016 10:37:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467884255; bh=SmG7kGFQ66GT4YgyxgQEA2Z91EuFT4YmJuC7kyohmGI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OgwivVLnf+GGgaClPlfb3L7ZPKAEcQ8pgcqyHLOa/ubTMJuee7GlzRnVb1Loh9KNY Dtyf/u2TONDGn+oj5pWSOukXeXTKObiAWZiv8S25u6JUHvPcNWP8mDkLa9HbF3DB7J qloFPb8yHMAbNd+A/i2/E7H9VaeiuFLvaCOvxDy4= To: Nikos Mavrogiannopoulos References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577E22DE.2060805@cs.tcd.ie> Date: Thu, 7 Jul 2016 10:37:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1467879217.3426.17.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050100040604060801050505" Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:37:39 -0000 This is a cryptographically signed message in MIME format. --------------ms050100040604060801050505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just on this one thing... On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: > does not make the situation any worse > than we have today. I don't accept that is the correct goal. That form of argument is what lead to us standardising the HTTP Forwarded header field, which IMO was a disimprovement. (An argument I lost in the end in that case [1], but 'twas close, and back in 2012 so might go the other way today;-) I would argue that the correct goal is to make things better whenever possible, with that being especially important for protocols like (D)TLS on which many other things depend. I do agree that any scheme developed would need to meet the state management requirements of servers. I'm not convinced those requirements call for a new super-cookie though:-) S. [1] https://datatracker.ietf.org/doc/rfc7239/ballot/ --------------ms050100040604060801050505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDcw OTM3MzRaMC8GCSqGSIb3DQEJBDEiBCAJRblP5MrJ+fdEts3McgbPVeVeMT+zAZqwSR8O3WsE vjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBfBO9LM4jjNordLLfEkQEGfuFQ9DrfwBykgKJisRlPsUeXHZ4RYlk9 gwwnMv6doIwSNdDRc1bXZXwRpA/RbbH/Z+/v/hPQQ2x6xVfoQ8OVlQgz9NimnEgJxtSXjtbg YbcFqEBytixkpM0+B/lEecufLNPKbMMsq0zucg0QzzOVvXSa8njVYKivWIb9Rr1TF6BJHH2H WTToLU+IEBwOb6NYshQFgOcF+gvs0hpmkE1By2H2o+HuyTMu+jWBwEunsbljwEJ21jfQOdjx rfPMNUwTP2jT59et75yEo/f07sHBO8+jftfNORQx9NcjMQeB7s5Wsvp7SqWFQYQ4L4vYuchU AAAAAAAA --------------ms050100040604060801050505-- From nobody Thu Jul 7 03:10:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2AC12D66C for ; Thu, 7 Jul 2016 03:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamsap-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mWyWs9zFE1P for ; Thu, 7 Jul 2016 03:10:43 -0700 (PDT) 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 31B4012D5F7 for ; Thu, 7 Jul 2016 03:10:43 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r190so1934394wmr.0 for ; Thu, 07 Jul 2016 03:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamsap-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4olV9z92W9v7x0DJZHhXK6taxa9jjbx5Zyf+8Taofo=; b=MUev47Ou5YWCu1qAoKY5s3DpgtuZFxOtXUeoy0kf6HqX7u0HMTwGR4FxPRh7eZCUFe 9BpCMxLMc1xkc8Navku1p2VTEVV+UxmJ6kyxfvyQ4Ne96GSTvnw37lYPIhO101aZ21KK 2b5/3tmoN0LDk05aenrtfhsNs+sOlJUoX9Ix3F0zqAi02oLIJfI1Easgn/IgPQk+S3Lo gft46g5q+cKu6hkh00Y7rrZeB8+8OsqSDzzfHWbtNZ1ZnAagRsFF2UjESN2v2ThpD8uW fGZhI9ntnVocxzxSrT/6w0m3OWMTYGlOe5iRce4Ug2cL6Symf+wMUoqW9UOTUSCCHPi2 T/Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4olV9z92W9v7x0DJZHhXK6taxa9jjbx5Zyf+8Taofo=; b=fU3IeVVxwVF2RQXcM0pyOcY/q1/JF8ET5ur78jZyYKZmiyta8jFf7j2n8MIvXgJpwU 1MqoKWkMfjPfyVHkSH2yQbrDIhM2bXGHhVP+fWqj4KuPT3Ga1rnLcECJ1GLtrHDdxFzG X63ijNU3mq2LhBSLkPBYIOtc5OFC2DW42ZhecKQrBNmSO5dwN4odxGjSdYqUTJR1LtEQ Oq2N1z/LcCLuzKgFNte37m9oMpuEmp11HIC6d4k6JmlqZ9VrKv9ZhYPY5IF3ngoD6ewn 3Ns6T0prJOVbpe7PIA2sdkuXmh8aAAPWujKRjIMRV3vt/GTvTDiCrnxZp89zzBWi0iDT s2ug== X-Gm-Message-State: ALyK8tJ+G5T58GKDo6Ft9LcCPtndJXsDBPmU9/MB/1wlg75mribMI5xHP5ZGBewCiq7qgA== X-Received: by 10.28.10.196 with SMTP id 187mr2113273wmk.48.1467886241661; Thu, 07 Jul 2016 03:10:41 -0700 (PDT) Received: from [192.168.18.6] ([90.207.136.117]) by smtp.gmail.com with ESMTPSA id k6sm1901503wjz.28.2016.07.07.03.10.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 03:10:40 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Mike Copley In-Reply-To: <577E22DE.2060805@cs.tcd.ie> Date: Thu, 7 Jul 2016 11:10:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DEA7608-2ABF-45FA-A290-112E4462FF8F@lamsap.org> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:10:45 -0000 On 7/07/2016, at 10:37 am, Stephen Farrell = wrote: > On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >> does not make the situation any worse >> than we have today. >=20 > I don't accept that is the correct goal. That form of > argument is what lead to us standardising the HTTP > Forwarded header field, which IMO was a disimprovement. > (An argument I lost in the end in that case [1], but > 'twas close, and back in 2012 so might go the other > way today;-) >=20 > I would argue that the correct goal is to make things > better whenever possible, with that being especially > important for protocols like (D)TLS on which many > other things depend. >=20 > I do agree that any scheme developed would need to > meet the state management requirements of servers. > I'm not convinced those requirements call for a new > super-cookie though:-) What about making it an optional value, with clients that don=92t need = such behaviour specifying an all-zero value? I have a use case where I = control both clients and servers and would like to automatically and = simply deal with changing IPs/ports on both sides, and would much rather = have this functionality built into DTLS than having to somehow preface = the DTLS packet with this ID added. If we were to go down this route, I would ask that there is a mechanism = for an endpoint (server or client) to verify the legitimacy of the = IP/port change before handing the data to an upper layer. E.g. Recipient = (server or client) receives the ID from a new source (Initiator), sends = an encrypted challenge to the new source/initiator, and the initiator = replies with an encrypted challenge response at which point the = recipient can validate and adjust its return path. Regards, Mike From nobody Thu Jul 7 03:44:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0025D12D745 for ; Thu, 7 Jul 2016 03:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjkqJy7jcWwS for ; Thu, 7 Jul 2016 03:44:39 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 858C112D74A for ; Thu, 7 Jul 2016 03:44:38 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id b72so10675015ywa.3 for ; Thu, 07 Jul 2016 03:44:38 -0700 (PDT) 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; bh=8Gprtve30Qg5Pah95gVT88KuYhQzTvbawqz9PyckQUo=; b=G8W65Y/MYkKPuq44xuBDoBGx3yFVoaW4vQNHxGfwLrcXUVHQfXMdFF1zE/D5NfSytj 5hby+9pDszLeVs95L7iJvQTBairSHxqNzE5BP1NXLzJ9kSNzRuas7NAtkT7GGVrkyLvp 3UMZ8Z+x7qzWxyG8a4/oNSz7rUlFXivhx0njyuggfYRwax3mEvLDYedttUpQ6xVjER88 48QYxOIMs+wMW9TfQ0t16TGwZdLzrOl9wbctaeigvIb4QtW8loj3wmY3XkfLFyT8/a/5 TQHld3JfOItfuzxx/uCbtyhT9fTHdGNrpiAYZcAdZpQOav6vmz4bxGZTY4VlGPqiIPoT 9+Ag== 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; bh=8Gprtve30Qg5Pah95gVT88KuYhQzTvbawqz9PyckQUo=; b=TGdpaQFcQLK3oVKLxLQbUaRs4NWHvluy0aVATUJKdePw3xXDZWqp19BSChMH9y0uPa Agn2XwaNCpB+1HmiXlKGO1Rdi6NjQrFij3n5lpQiaYZunLwjD7vmLnsRgTWFoI3S8ZhE 2KLrpoZVK9poPvOZHHJ4QjgNOcu86P+krzoAa1r2dbALRzhleChIaBr3X2a1kgVH7GBC DhIvOsiYmQabQVQ+yca6lNIdN7jHTXLopMMtErbHGDFCGLk9DdfP7Pms6H5eKq471KeY LUR/sthd9/xL7UZQa/zBKHaApMQVzORil47//yVXk3ObHnWdLxoQCfe49XSXzyOTaz+m mgDA== X-Gm-Message-State: ALyK8tJjz/4oPNjbLy0xUIDoCoR2JB3Bg3mDR561hoRZoHtOVSpuvZtjKYxHTCLYBZXgqT5YPMHWV1mAHJgArA== X-Received: by 10.129.72.13 with SMTP id v13mr185447ywa.152.1467888277704; Thu, 07 Jul 2016 03:44:37 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.101.68 with HTTP; Thu, 7 Jul 2016 03:44:08 -0700 (PDT) In-Reply-To: <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> From: Hugo Krawczyk Date: Thu, 7 Jul 2016 06:44:08 -0400 X-Google-Sender-Auth: iw30-_f2-Z6wnxaJRrUAbDDWi9c Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a114dd09e5cd9400537095ffe Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:44:43 -0000 --001a114dd09e5cd9400537095ffe Content-Type: text/plain; charset=UTF-8 I do not have an objection to option 1 if re-phrased as Option 1 - use the same key for protecting both *post*-handshake and applications messages.. I believe this is what was intended by that option anyway. Let me clarify. I understand the question as relating *only* to post-handshake messages and not to the main handshake (three initial flights). For the latter we have key separation in the sense that none of these main-handshake messages is encrypted under the application key but rather under dedicated handshake keys. This should not be changed as it provides key indistinguishability to the application key, a desirable design and analysis (=proof) modularity property. On the other hand, for post-handshake messages, and particularly for encrypting post-handshake client authentication messages, preserving key indistinguishability is not relevant since at the time of post-handshake client authentication, the application key has already lost its indistinguishability by the mere fact that the key was used to encrypt application data. Key indistinguishability is the main reason to insist in key separation and this principle does not apply here anymore hence removing the objection to 1. I'd note that the best one could hope for in the post-handshake setting is that as a result of post-handshake client authentication the application key becomes a secure mutually-authenticated key for providing "secure channels" security. As pointed out by others in previous posts I have an analysis showing that this delayed mutual authentication guarantee is achieved even if one uses the application key to encrypt the post-handshake messages. I have circulated a preliminary version of the paper among cryptographers working on TLS 1.3 and I will post a public copy next week so this can be scrutinized further. Hugo On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > If we are left with 1 or 3, the miTLS team would prefer 1. > > On the cryptographic side, Hugo has a recent (draft) paper that seems to > provide > some more justification for (1), at least for client authentication. > > I know this is a bit off-topic, but the miTLS team would also like to get > rid of 0-RTT ClientFinished > if that is the only message left in the 0-RTT encrypted handshake flight. > That should remove > another Handshake/Data key separation from the protocol, leaving only 3 > keys: 0-RTT data, > 1-RTT handshake, and 1-RTT data. > > Best, > -Karthik > > > On 07 Jul 2016, at 02:49, David Benjamin wrote: > > On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: > >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett >> wrote: >> >>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >>> > I'm also curious which post-handshake messages are the problem. If we >>> were >>> > to rename "post-handshake handshake messages" to "post-handshake bonus >>> > messages" with a distinct bonus_message record type, where would there >>> > still be an issue? (Alerts and application data share keys and this >>> seems >>> > to have been fine.) >>> >>> Recasting all the post-handshake handshake messages as not something >>> named "handshake" does make a degree of sense, on its own. (bikeshedding: >>> I'd name it something more descriptive like "secondary negotiation" >>> messages or something, though.) Even if this doesn't directly help with the >>> issue at hand here, does forking these into a new ContentType sound like a >>> useful move, in general? >> >> >> I'm not sure what this would accomplish. >> > > Me neither. To clarify, I mention this not as a suggestion, but to > motivate asking about the type of message. If the only reason the proofs > want them in the handshake bucket rather than the application data bucket > is that they say "handshake" in them then, sure, let's do an > inconsequential re-spelling and move on from this problem. > > But presumably something about the messages motivate this key separation > issue and I'd like to know what they are. > > David > _______________________________________________ > 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 > > --001a114dd09e5cd9400537095ffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= I do not have an objection to option 1 i= f re-phrased as=C2=A0
Option 1 - use the same key for protecting both *post= *-handshake and applications messages..=C2=A0

I believe this is what was intended by that option anyw= ay.=C2=A0Let me clari= fy.

I understand the question as relating *only* to post-handshake m= essages and not
to the main handshake (three initial flights). For the lat= ter we have key
separation in the sense that none of these main-handshake = messages is encrypted
under the application key but rather under dedicat= ed handshake keys. This should
not be changed as it provides key indisting= uishability to the application key, a
desirable design and analysis (=3Dpr= oof) modularity property.

On the other hand, for post-handshake mess= ages, and particularly for encrypting
post-handshake client authentication= messages, preserving key
indistinguishability is not relevant since at th= e time of post-handshake
client authentication, the application key has al= ready lost its indistinguishability
by the mere fact that the key was used= to encrypt application data. Key
= indistinguishability is the main reason = to insist in key separation and this
principle does not apply here anymore= hence removing the objection to 1.

I'd note that the best one c= ould hope for in the post-handshake setting is that
as a result of post-h= andshake client authentication the application key becomes
a secure mutual= ly-authenticated key for providing "secure channels" security.
A= s pointed out by others in previous posts I have an analysis showing that t= his
delayed mutual authentication guarantee is achieved even if one uses t= he
application key to encrypt the post-handshake messages. I have circulat= ed a
preliminary version of the =C2=A0paper among cryptographers working o= n TLS 1.3=C2=A0
and =C2=A0I will post a public copy next week so this can be scrutinized furthe= r.

Hugo

<= /div>

On Thu= , Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <karthik.bhargav= an@gmail.com> wrote:
If we are left with 1 or 3, the miTLS team wo= uld prefer 1.

On the cryptographic side, Hugo has a rece= nt (draft) paper that seems to provide
some more justification fo= r (1), at least for client authentication.=C2=A0

I know = this is a bit off-topic, but the miTLS team would also like to get rid of 0= -RTT ClientFinished=C2=A0
if that is the only message left in the= 0-RTT encrypted handshake flight. That should remove
another Han= dshake/Data key separation from the protocol, leaving only 3 keys: 0-RTT da= ta,
1-RTT handshake, and 1-RTT data.=C2=A0

Best,
-Karthik


On 07 Jul 2016, at 02:49= , David Benjamin <davidben@chromium.org> wrote:

On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemg= arrett@gmail.com> wrote:
On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If= we were
> to rename "post-handshake handshake messages" to "post-= handshake bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this se= ems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something= named "handshake" does make a degree of sense, on its own. (bike= shedding: I'd name it something more descriptive like "secondary n= egotiation" messages or something, though.) Even if this doesn't d= irectly help with the issue at hand here, does forking these into a new Con= tentType sound like a useful move, in general?

<= /div>
I'm not sure what this would accomplish.
<= /div>

Me neither. To clarify, I mention this = not as a suggestion, but to motivate asking about the type of message. If t= he only reason the proofs want them in the handshake bucket rather than the= application data bucket is that they say "handshake" in them the= n, sure, let's do an inconsequential re-spelling and move on from this = problem.

But presumably something about the messag= es motivate this key separation issue and I'd like to know what they ar= e.

David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

=

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


--001a114dd09e5cd9400537095ffe-- From nobody Thu Jul 7 04:53:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92B712D190 for ; Thu, 7 Jul 2016 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4OtzRZWcBIz for ; Thu, 7 Jul 2016 04:53:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7441412D122 for ; Thu, 7 Jul 2016 04:53:01 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB24696F8; Thu, 7 Jul 2016 11:53:00 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u67BqwcN004461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jul 2016 07:53:00 -0400 Message-ID: <1467892378.3426.41.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Farrell Date: Thu, 07 Jul 2016 13:52:58 +0200 In-Reply-To: <577E22DE.2060805@cs.tcd.ie> References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> 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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 07 Jul 2016 11:53:01 +0000 (UTC) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:53:04 -0000 On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: > Hiya, > > Just on this one thing... > > On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: > > > >  does not make the situation any worse > > than we have today. > I don't accept that is the correct goal. That form of > argument is what lead to us standardising the HTTP > Forwarded header field, which IMO was a disimprovement. > (An argument I lost in the end in that case [1], but > 'twas close, and back in 2012 so might go the other > way today;-) > I would argue that the correct goal is to make things > better whenever possible, with that being especially > important for protocols like (D)TLS on which many > other things depend. > I do agree that any scheme developed would need to > meet the state management requirements of servers. > I'm not convinced those requirements call for a new > super-cookie though:-) I understand your point, I'm not fully convinced by that argumentation. I may be wrong of course, but I'll try to explain my point. Indeed putting privacy first should be a goal of TLS/DTLS, but to the extent it covers the protocol goals. What you propose is to make a stream anonymous, untrackable. However, that (anonymity or untrackability of the stream) was never a stated goal of TLS/DTLS. In fact TLS is by definition trackable over TCP and one can see in the clear the IPs of the two peers communicating. That doesn't change by switching to DTLS, except for unfortunate situations of routers losing state and client roaming, which current servers cannot easily cope with, and that's the problem I attempt to address. I think the principle of doing one simple thing and doing it well, applies to protocols as well. TLS and DTLS provide a layer of confidentiality and authenticity. Anonymity, untrackability can be provided by other protocols focused on that such as TOR. regards, Nikos From nobody Thu Jul 7 04:57:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFFA126FDC for ; Thu, 7 Jul 2016 04:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK0VrY0Z1zDH for ; Thu, 7 Jul 2016 04:57:11 -0700 (PDT) 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 F144B12D122 for ; Thu, 7 Jul 2016 04:57:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7855FBE51; Thu, 7 Jul 2016 12:57:08 +0100 (IST) 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 sDkDHDNW-Yor; Thu, 7 Jul 2016 12:57:07 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BAF58BE4D; Thu, 7 Jul 2016 12:57:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467892627; bh=dgP7GallhBtyqxwbzHUqxRh3Asj3r8EVNjwEa5wIMN0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A/QtzzeHBVE6neELpiHr0NtBu18yeUffSgForP5QT6q5ovMgVAtn0ie3uGPQMu3DT Xe+kP8Nh1P+Mz7I38TEf+wbCHCLH4fkRJEqSSwU3C9I+FZk9ntese/tqSUpyPbs0ef H5GaPf3HB+MJLTH43qgkHgyuvlId3s0CF+6JqKJ4= To: Nikos Mavrogiannopoulos References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577E4392.6060408@cs.tcd.ie> Date: Thu, 7 Jul 2016 12:57:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1467892378.3426.41.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040402050208060902080100" Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:57:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040402050208060902080100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote: > On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: >> Hiya, >> >> Just on this one thing... >> >> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >>> >>> does not make the situation any worse >>> than we have today. >> I don't accept that is the correct goal. That form of >> argument is what lead to us standardising the HTTP >> Forwarded header field, which IMO was a disimprovement. >> (An argument I lost in the end in that case [1], but >> 'twas close, and back in 2012 so might go the other >> way today;-) >> I would argue that the correct goal is to make things >> better whenever possible, with that being especially >> important for protocols like (D)TLS on which many >> other things depend. >> I do agree that any scheme developed would need to >> meet the state management requirements of servers. >> I'm not convinced those requirements call for a new >> super-cookie though:-) >=20 > I understand your point, I'm not fully convinced by that argumentation.= > I may be wrong of course, but I'll try to explain my point. Indeed > putting privacy first should be a goal of TLS/DTLS, but to the extent > it covers the protocol goals. What you propose is to make a stream > anonymous, untrackable.=20 Totally wrong, sorry. What I propose is not adding new ways to allow a network observer to track a tls client using the same tls session over multiple transport layer connections, unless that is really unavoidable. Exaggerating my argument is not useful. Not is it at all convincing. S. > However, that (anonymity or untrackability of > the stream) was never a stated goal of TLS/DTLS. In fact TLS is by > definition trackable over TCP and one can see in the clear the IPs of > the two peers communicating. That doesn't change by switching to DTLS, > except for unfortunate situations of routers losing state and client > roaming, which current servers cannot easily cope with, and that's the > problem I attempt to address. >=20 > I think the principle of doing one simple thing and doing it well, > applies to protocols as well. TLS and DTLS provide a layer of > confidentiality and authenticity. Anonymity, untrackability can be > provided by other protocols focused on that such as TOR. >=20 > regards, > Nikos >=20 >=20 --------------ms040402050208060902080100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDcx MTU3MDZaMC8GCSqGSIb3DQEJBDEiBCBePBGleHbhy5Ix+I/VYYh6B4VWWCWe2mkTBtnk6Ih8 MTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBc6DKbDY7l/nc5lwEwTDuDVbVJ8lH0puzuMxFBU6n8nbEMnI67PCuQ ldoZnACE6mnqY5aZStGEN4Rg6Mr1GvSKx1nK6cUpM8SWbgFU3WdfTPNX1/pKs1g0JPtbSVTY dyQ0Ysee10lapNy8oIp5Tlr/tRq+vn9/jepQjmIRWSLXaOlil3r84CNUy4Vs6ffWxNdnjYRE WsoQ4ggMkblAzyRIBeJ82/8PTPZBjciX9ppqlpI/RoMXEPdbgjnC/rfXHVDYdztHZmvheJPR 1yqSadBdsPO9EGdtpAmBlM12FnU4WR/gXajabPMFKzc/v1G4kHOVuCOy/ZNZFh9kEbxhdSJb AAAAAAAA --------------ms040402050208060902080100-- From nobody Thu Jul 7 10:08:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803A412D0E4 for ; Thu, 7 Jul 2016 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxszAW93lXeY for ; Thu, 7 Jul 2016 10:08:05 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 940F812D09A for ; Thu, 7 Jul 2016 10:08:04 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id f7so13129011vkb.3 for ; Thu, 07 Jul 2016 10:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7ExuyDnGZYowFkOv5W9+G9sk1IZyvvvwCbvJnpd/1mE=; b=cBbF0qtOEsb0Fp6GiXKlKQcEbMUk1fXvq+u0yQ54C/nBlLYa6dwE4WVp83WnTX1v94 mntGSPJvcqWoUlwSqKp66s6e607FhzykgkKc4522ZUekm1ztlwxMR7W5YnHCkjlNN8xS x9+9fIBDr+7umkVo7DdSHctGJalbfSP50s+rmcilOqzzEoFu79jAbY0fGm4HwCDVhi54 MQx68b7Rs7mm03Ko0lQGoh9UgwMwKNAnRA603QuKpfLr7gdD5xwWRY3T9wSkQ6L5NZBA LPhN+MIM2nJ3VOm9bAj0e30OYT75sG2pfmnUMHHEIVlSb/jXiau68WTuDzHgahHXw+2J kx3A== 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; bh=7ExuyDnGZYowFkOv5W9+G9sk1IZyvvvwCbvJnpd/1mE=; b=X2W+E71WqJbv8xoEUBmkritCKo6lfxze0Wyp+qFJlCGGPtaqJ8hOt/gIZx/g1x3IIs ATqbapWRWx7APDct5LmsxhH4HCjcjTRl4dFC4Ejy/6XnsQMDFwCJfK/R8rGWGUVmy0QB rsqnVcWm9RVhVzfpSHAtTz9e6d01xPyU0FF4YE/rJHRyLlgMK4baFY+sov4nOtbhLgO7 aQC/VAo1YBtPHk8xH6l+wkBoq0F9KBUnCMCgQo57clFFCIR/ScOGSqCq8AvJUSAmzptk 2PTeAr/iuk6PQKWrmbej0hmHLvSyUo+sTw9DDgGofRmijmwCmD7/xRIkcrF3RGS9JyAN XIPg== X-Gm-Message-State: ALyK8tLVkOMcZ3MpXbPS/bKs/Th27huhGLWGSXlSPQXOiL9/NFMcDR4OK6VI43FDEId81HvDWugCqORwkJmDAsRz X-Received: by 10.159.32.227 with SMTP id 90mr590216uaa.85.1467911283389; Thu, 07 Jul 2016 10:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.83.194 with HTTP; Thu, 7 Jul 2016 10:08:02 -0700 (PDT) In-Reply-To: References: <577D655A.40802@gmx.net> From: Bill Cox Date: Thu, 7 Jul 2016 10:08:02 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c0b76ea9bfcdb05370eba0b Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:08:06 -0000 --94eb2c0b76ea9bfcdb05370eba0b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 1:16 PM, Kyle Rose wrote: > On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> I agree with Brian here on this issue. This is clearly impractical for >> IoT devices. For many of those devices we are talking about 32 KB (in >> total). > > > I continue to feel like this is a valid objection to the wrong > proposition. I don't think the question is, "Should TLS client puzzles be > issued by all TLS servers under load?" but rather, "Would client puzzles be > a useful addition to the DDoS toolbox, and appropriate in some cases?" > > Kyle > I agree, and I think it is clear that client puzzles can be a useful addition to the DDoS defense toolbox. However, most of this can be handled at the higher levels above TLS, or possibly as a custom extension that does not complicate TLS. The most similar effort I know of is one I work on: token binding. Rather than bake it into TLS, we're using the custom extension API. If there were a separate effort to standardize client puzzles, similar to what we are doing with token binding, I would be interested in participating. Bill --94eb2c0b76ea9bfcdb05370eba0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 6, 2016 at 1:16 PM, Kyle Rose <krose@krose.org> wrote:=
O= n Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig <hannes.tschofeni= g@gmx.net> wrote:
I agree with Brian here on this issue.= This is clearly impractical for
IoT devices. For many of those devices we are talking about 32 KB (in
total).=C2=A0
=C2=A0
I continue to feel = like this is a valid objection to the wrong proposition. I don't think = the question is, "Should TLS client puzzles be issued by all TLS serve= rs under load?" but rather, "Would client puzzles be a useful add= ition to the DDoS toolbox, and appropriate in some cases?"

Kyle

I agree, and I think it is clear that client puzzles = can be a useful addition to the DDoS defense toolbox.=C2=A0 However, most o= f this can be handled at the higher levels above TLS, or possibly as a cust= om extension that does not complicate TLS.

The mos= t similar effort I know of is one I work on: token binding.=C2=A0 Rather th= an bake it into TLS, we're using the custom extension API.=C2=A0 If the= re were a separate effort to standardize client puzzles, similar to what we= are doing with token binding, I would be interested in participating.

Bill
--94eb2c0b76ea9bfcdb05370eba0b-- From nobody Thu Jul 7 12:29:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7568412D1DD for ; Thu, 7 Jul 2016 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvqnsTG9m8uO for ; Thu, 7 Jul 2016 12:29:14 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 5804B12D17A for ; Thu, 7 Jul 2016 12:29:14 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id b72so22958310ywa.3 for ; Thu, 07 Jul 2016 12:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=iC05CogrxNasYOCxHgYf/EoAWvxQBu98/0+rrPDct/U=; b=NNWFrgZh7geEjXrFPE8X0f+nE6lxpsi7ACI2wnyouScVENvfc7LPUWiy5+/3/TB3R9 ponohElbrmtkXUndY9xF2HIUil2jKzttqYpYehhEgCjX7x79v+px1h5yUKWoqGDKw3v2 MKiP8poLBkE/iuV4ryL3WvnYZkeVNIQW/Sz8Hs7p+qvI0+/bR+6SCRFgKok1T+sAEgCg QXLzwCQR6GTk3D8lqbraQph3qRtS4AHauS4UiDMW6jvXFhuZdl4m2ahj0fpYkzsbQdMk Uedq9WeyZtu5xtS46ExLOqC5HtW44RfgrhgEL09j8JkdqIBsVSSqmoLQNSeAkAPJGa5e uORg== 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; bh=iC05CogrxNasYOCxHgYf/EoAWvxQBu98/0+rrPDct/U=; b=CZNB5Fa8Q7neT98fsQJqiFPUTloBZ8wlm7aaOmGPC9Qidm2mqSZaWlGgHcaxUqXF4/ D7fVDt2PT/9pTuPph8q0BoEfOwWv2ayVmieafhGyR+wLSCd/db8M9rZPGXRqJJVvjHtz zRDP4/099dfRw7/0rFVfSdFPR2fc9qEAaXHJ5SQizN67STMOwzX09yDophJLAPXImlP1 PLZtCCQdRX9zlAfVAZSSAUrfgV2ZWni0jd/KPKi2lJ01QmTX58ZCwDqytIY9ZgpoS/pR Mo9S7LyD7BIRpvWXLdfkwM8eM9QyktUWEj7E58Et7c9VJNt9I0E7GTfvGisOLBXJOgH6 /C3w== X-Gm-Message-State: ALyK8tL+fmD2xHr9hCkYULrZOCJdS/Dgf7x3C4TqWrz3/cz1Y/oSEv+fncw8kbt5UvsMyRDd+KfEbFTYsPD7XQ== X-Received: by 10.129.46.87 with SMTP id u84mr1869155ywu.214.1467919753382; Thu, 07 Jul 2016 12:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Thu, 7 Jul 2016 12:28:33 -0700 (PDT) From: Eric Rescorla Date: Thu, 7 Jul 2016 12:28:33 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114140ba75be55053710b30c Archived-At: Subject: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:29:16 -0000 --001a114140ba75be55053710b30c Content-Type: text/plain; charset=UTF-8 We've talked several times about designing some sort of TLS delegation mechanism. A few of us got together and put together some initial thoughts about the options at: https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt The general idea here is to have some mechanism for allowing what are effectively end-entities to issue short-lived credentials that allow other entities to act on their behalf (e.g., for CDN use cases). Comments welcome. In terms of the security analysis, it's obviously very important that this mechanism not present a risk to existing TLS servers. The mechanism designed here is intended to be future safe in that sense, though perhaps we've missed something. I also wanted to clarify a couple points about attacks where the certificate that signs the delegated credential is also used for ordinary TLS operation (which generally is a practice that's pretty scary). As noted above it's important that existing certs not be usable this way, but maybe future certs would be. 1. It's important to construct the delegated credential in such a way that you can't use a TLS server as a signing oracle. If you choose "option 2" where you define a new structure, then it's probably sufficient to use the TLS 1.3 "context-including" digitally-signed production proposed by AGL. If you you choose "option 1" where the delegated credential is an X.509 cert, then you'd need to make some rules about fixing portions of the cert that the TLS client can't control. 2. If you're concerned about attacks like those of Jager et al. which exploit RSA decryption, what's important is that the attacker not be able to get the server to do TLS 1.2-style static RSA with the key. Playing with the usage bits definitely makes it harder to configure the server this way (because it's likely to cause bustage) but may not be enough, because sufficiently busted clients and server might be willing to use them that way anyway. In the next rev, we'll update the draft to make these points more clearly. -Ekr --001a114140ba75be55053710b30c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've talked several times about designing some sort o= f TLS delegation
mechanism. A few of us got together and put together s= ome initial thoughts
about the options at:
<= div>
The general idea here is to have some mechanism for allo= wing what
are effectively end-entities to issue short-lived crede= ntials that allow other
entities to act on their behalf (e.g., fo= r CDN use cases).
Comments welcome.

= In terms of the security analysis, it's obviously very important that t= his mechanism
not present a risk to existing TLS servers. The mec= hanism designed here is
intended to be future safe in that sense,= though perhaps we've missed something.

I also= wanted to clarify a couple points about attacks where the certificate that= signs the delegated credential is also used for ordinary TLS operation (wh= ich generally is a practice that's pretty scary). As noted above it'= ;s important that existing certs not be usable this way, but maybe future c= erts would be.

1. It's important to construct = the delegated credential in such a way that you can't use a TLS server = as a signing oracle. If you choose "option 2" where you define a = new structure, then it's probably sufficient to use the TLS 1.3 "c= ontext-including" digitally-signed production proposed by AGL. If you = you choose "option 1" where the delegated credential is an X.509 = cert, then you'd need to make some rules about fixing portions of the c= ert that the TLS client can't control.

2. If y= ou're concerned about attacks like those of Jager et al. which exploit = RSA decryption, what's important is that the attacker not be able to ge= t the server to do TLS 1.2-style static RSA with the key. Playing with the = usage bits definitely makes it harder to configure the server this way (bec= ause it's likely to cause bustage) but may not be enough, because suffi= ciently busted clients and server might be willing to use them that way any= way.

In the next rev, we'll update the draft t= o make these points more clearly.

-Ekr
<= br>


--001a114140ba75be55053710b30c-- From nobody Thu Jul 7 12:47:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901C112D5C7 for ; Thu, 7 Jul 2016 12:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypDdimLIlqLi for ; Thu, 7 Jul 2016 12:47:41 -0700 (PDT) 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 B672012D523 for ; Thu, 7 Jul 2016 12:47:40 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f126so223022628wma.1 for ; Thu, 07 Jul 2016 12:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dOboAVTm80uSOBoCyrlcLGUxQDosn5j4sc3CVbLQEYE=; b=gQXZGXLP7HutlQuDklmU+1ba9hMKVbpIT3DXbedJ5mgUtfYg+rvPwBuxwR2XGDuvzx u8dx2DMcQKhrMz+Y06/NTtN3d+sKv+XxKRXzVruKirarCgsZnLrSYZHc+QbJXwGLxCOm ThsZPdg2mLmb0FQtDnKou2dbzjXhADefp1KQZoTTqqBQdqpmtbGdsRjSt9pZwkiIoJ7x 8wmpZCw3Ni6Z4PBI13BCx6TwW1dN6LAf1OLFpmesUoTF+e/wUho/4oRFgqEJLy2g8aKY OQia1aeW+PrmVoiU0Hnm5DvdD6IXK9QbuFBf1D4nYrEe5aHr2m1FwVpw0QxILWLL+KfC rOhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dOboAVTm80uSOBoCyrlcLGUxQDosn5j4sc3CVbLQEYE=; b=URFr4WffYQkQqXFuVvcYHqRB8kFTQg/KQjXpCLApr5XDyox7aGXnwKYyuCO1hIpINn ULnxnH11rPVDIapMnQtgKHOBVmX5MfIG0ecjP9W8yPe0teBDQPFksrNpY2ux919JS/SN Z8tpOJsOWVljfLYZcmeWp4Kp1Pjjw7LkNKD1e4LrSVhB5qixHiWn7QL6yA0haW2AhOzl +kCrURnntzWjaOnPojii2klJZXMbTtIUMy6LVeUWir2zvbFnSutqoQjwo4GJCQk+ycyh Ajpu6+YAtp48Gfa5Mo5gBwFMPE+0JjkuEVCS9bOkvicztdBs8fNP6oZr/L+75vKtKR0a iMPQ== X-Gm-Message-State: ALyK8tI7RSa5lgSoMJghHPST7tDCnmvS7IMzluxSvBjnYbtC2VEFmj86hJbG/kiGL+4RIg== X-Received: by 10.194.133.161 with SMTP id pd1mr1795451wjb.16.1467920859243; Thu, 07 Jul 2016 12:47:39 -0700 (PDT) Received: from [192.168.0.111] (host20-53-static.240-95-b.business.telecomitalia.it. [95.240.53.20]) by smtp.gmail.com with ESMTPSA id a4sm4439396wjq.40.2016.07.07.12.47.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jul 2016 12:47:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Douglas Stebila In-Reply-To: Date: Thu, 7 Jul 2016 21:47:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:47:43 -0000 With Hugo's analysis of the secure channel-like security afforded even = when the application key is used to encrypt non-application data, and as = C=C3=A9dric pointed out to me the application key will be used to = encrypt non-application data like certain alert messages; so I think = option 1 is a reasonable choice, and option 3 would not recover the = composability property we hoped it might. Douglas > On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk = wrote: >=20 > I do not have an objection to option 1 if re-phrased as=20 > Option 1 - use the same key for protecting both *post*-handshake and = applications messages..=20 >=20 > I believe this is what was intended by that option anyway. Let me = clarify. >=20 > I understand the question as relating *only* to post-handshake = messages and not > to the main handshake (three initial flights). For the latter we have = key > separation in the sense that none of these main-handshake messages is = encrypted > under the application key but rather under dedicated handshake keys. = This should > not be changed as it provides key indistinguishability to the = application key, a > desirable design and analysis (=3Dproof) modularity property. >=20 > On the other hand, for post-handshake messages, and particularly for = encrypting > post-handshake client authentication messages, preserving key > indistinguishability is not relevant since at the time of = post-handshake > client authentication, the application key has already lost its = indistinguishability > by the mere fact that the key was used to encrypt application data. = Key > indistinguishability is the main reason to insist in key separation = and this > principle does not apply here anymore hence removing the objection to = 1. >=20 > I'd note that the best one could hope for in the post-handshake = setting is that > as a result of post-handshake client authentication the application = key becomes > a secure mutually-authenticated key for providing "secure channels" = security. > As pointed out by others in previous posts I have an analysis showing = that this > delayed mutual authentication guarantee is achieved even if one uses = the > application key to encrypt the post-handshake messages. I have = circulated a > preliminary version of the paper among cryptographers working on TLS = 1.3=20 > and I will post a public copy next week so this can be scrutinized = further. >=20 > Hugo >=20 >=20 > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan = wrote: > If we are left with 1 or 3, the miTLS team would prefer 1. >=20 > On the cryptographic side, Hugo has a recent (draft) paper that seems = to provide > some more justification for (1), at least for client authentication.=20= >=20 > I know this is a bit off-topic, but the miTLS team would also like to = get rid of 0-RTT ClientFinished=20 > if that is the only message left in the 0-RTT encrypted handshake = flight. That should remove > another Handshake/Data key separation from the protocol, leaving only = 3 keys: 0-RTT data, > 1-RTT handshake, and 1-RTT data.=20 >=20 > Best, > -Karthik >=20 >=20 >> On 07 Jul 2016, at 02:49, David Benjamin = wrote: >>=20 >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett = wrote: >> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >> > I'm also curious which post-handshake messages are the problem. If = we were >> > to rename "post-handshake handshake messages" to "post-handshake = bonus >> > messages" with a distinct bonus_message record type, where would = there >> > still be an issue? (Alerts and application data share keys and this = seems >> > to have been fine.) >>=20 >> Recasting all the post-handshake handshake messages as not something = named "handshake" does make a degree of sense, on its own. = (bikeshedding: I'd name it something more descriptive like "secondary = negotiation" messages or something, though.) Even if this doesn't = directly help with the issue at hand here, does forking these into a new = ContentType sound like a useful move, in general? >>=20 >> I'm not sure what this would accomplish. >>=20 >> Me neither. To clarify, I mention this not as a suggestion, but to = motivate asking about the type of message. If the only reason the proofs = want them in the handshake bucket rather than the application data = bucket is that they say "handshake" in them then, sure, let's do an = inconsequential re-spelling and move on from this problem. >>=20 >> But presumably something about the messages motivate this key = separation issue and I'd like to know what they are. >>=20 >> David >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 7 14:46:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CB612D68D for ; Thu, 7 Jul 2016 14:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7AlzODbnPp7 for ; Thu, 7 Jul 2016 14:46:09 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B1812D532 for ; Thu, 7 Jul 2016 14:37:00 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id e3so26491922qkd.0 for ; Thu, 07 Jul 2016 14:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WX8VgbfzhuuTR3F6QsHr2XiKZh25NGHvQXgke+jUf5E=; b=JYgQfYWH3phYW9O5mMJuyTgTUZemXPjcON5w7uRujGvfCwQT6Hdj/V7ubYd1HivXdm WJv8T3QhBMCiKF60FfJ9bFnzJ1fqoaiVRyfX3cAME9U5j+XhKLICDqXnAp/e1WteC0Qe t6ZSLsf6qDRf9bDR8AzrKJBJeKY2ukYCiIzDY= 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; bh=WX8VgbfzhuuTR3F6QsHr2XiKZh25NGHvQXgke+jUf5E=; b=lsFOzb0Vn+WvvcT6MA8B5zqfxBx5A2tUZaoRT3sKM3ZDQvMLxNqwezBXewo75Cf6Fb TwxSz4LMg0YLW7Nsf3/Eq4wtRsOeiYTBt30bhNKkavc3i10nLBF1cw3Gw6Z7UIIEFYKA TeVpvcrbxbxRiixUd6uA3ve8EhJl0AV3ueItdem5NNUZqP70q9D+TSRgxDu8e6MUnRP0 JjJty/BuudfdGEJLc2GdH+dTWgoWwGytSfzVRaj9B3LewLI9x+OVQFjpinIXbFs9zgTN ZTvbwwp083ejbk4IfUtwcm6I9LGt2pAIAwYvNgVGF2wNUgSU0yypL/IWI7W2EsrrHfUX ESgg== X-Gm-Message-State: ALyK8tKeeynz2xZvVc5/Q70enUblabcRD+CZ+oDIXhUZEVnU00L2wFQOngQGwiAUhhkJNGifd35ic5yUyDcUfg== X-Received: by 10.55.70.22 with SMTP id t22mr2992198qka.171.1467927419858; Thu, 07 Jul 2016 14:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Thu, 7 Jul 2016 14:36:58 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:698e:3f64:370a:ec8b] In-Reply-To: References: <577D655A.40802@gmx.net> From: Kyle Rose Date: Thu, 7 Jul 2016 17:36:58 -0400 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114ab99c6ae36a0537127c70 Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:46:10 -0000 --001a114ab99c6ae36a0537127c70 Content-Type: text/plain; charset=UTF-8 > I agree, and I think it is clear that client puzzles can be a useful > addition to the DDoS defense toolbox. However, most of this can be handled > at the higher levels above TLS, or possibly as a custom extension that does > not complicate TLS. > A custom extension is a promising approach: this is what Erik Nygren proposed in nygren-tls-client-puzzles-00 following discussions with some IETF folks and Akamai colleagues. That draft has expired and doesn't reference any of the recent work on memory-hard puzzles, but it might be a good starting point. Except at the pre-TLS stage for applications that use STARTTLS-style mechanisms, I'm not sure how this could work at levels above TLS: the primary attack targeted by client puzzles would be a client doing almost no work in order to force the server to do expensive crypto, which means it must be engaged prior to the handshake. Kyle --001a114ab99c6ae36a0537127c70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
I agree, and I think it = is clear that client puzzles can be a useful addition to the DDoS defense t= oolbox.=C2=A0 However, most of this can be handled at the higher levels abo= ve TLS, or possibly as a custom extension that does not complicate TLS.

A custom extension is = a promising approach: this is what Erik Nygren proposed in nygren-tls-clien= t-puzzles-00 following discussions with some IETF folks and Akamai colleagu= es. That draft has expired and doesn't reference any of the recent work= on memory-hard puzzles, but it might be a good starting point.

Exce= pt at the pre-TLS stage for applications that use STARTTLS-style mechanisms= , I'm not sure how this could work at levels above TLS: the primary att= ack targeted by client puzzles would be a client doing almost no work in or= der to force the server to do expensive crypto, which means it must be enga= ged prior to the handshake.
=C2=A0
Kyle

--001a114ab99c6ae36a0537127c70-- From nobody Thu Jul 7 15:13:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A062F12D14D for ; Thu, 7 Jul 2016 15:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKeQM7bJeiSh for ; Thu, 7 Jul 2016 15:13:28 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B82DA12D100 for ; Thu, 7 Jul 2016 15:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 52B4684AC; Fri, 8 Jul 2016 01:13:27 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id C7L3K5V_XxqJ; Fri, 8 Jul 2016 01:13:27 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDD482310; Fri, 8 Jul 2016 01:13:26 +0300 (EEST) Date: Fri, 8 Jul 2016 01:13:24 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160707221324.GA13128@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:13:31 -0000 On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote: > We've talked several times about designing some sort of TLS delegation > mechanism. A few of us got together and put together some initial thoughts > about the options at: > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt > > The general idea here is to have some mechanism for allowing what > are effectively end-entities to issue short-lived credentials that allow > other entities to act on their behalf (e.g., for CDN use cases). > Comments welcome. > > In terms of the security analysis, it's obviously very important that this > mechanism > not present a risk to existing TLS servers. The mechanism designed here is > intended to be future safe in that sense, though perhaps we've missed > something. - I think most browsers ignore KeyUsage presently, allowing the broken RSA key exchange even when KeyUsage does not permit it. And as for server side, I don't think many server products check the certificate they try to load, just serve it mostly blindly. - I would definitely use TLS 1.3 signature construct for digitally-signed instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready mentioned it below). Also, instead of extension one way that came to mind would be a new CertficateType, where Cert#0 is the delgated credential and Cert#1 is X.509 EE cert, and then comes the normal CA certs. Dunno which would be better. I also checked if one could do some funky stuff with credential lifetime notation to limit the lifetime. Nothing came up (apart for using 16-bit count in decaseconds (das) only allowing presenting lifetimes up to 7 days, 14 hours, 2 minutes and 30 seconds). :-> Also, what is the ServerNameList for? As far as I see, the delegated credential structure only contains one name. Or was it supposed to have multiple, but there was a typo in definition? Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already have a algorithm field? Also, doesn't digitally-signed "eat" all the fields inside? So if you want to actually transfer the data, you need the actual fields the second time? -Ilari From nobody Thu Jul 7 15:20:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8900D12D8CD for ; Thu, 7 Jul 2016 15:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrgSGSO9yMVm for ; Thu, 7 Jul 2016 15:20:10 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 A841012D635 for ; Thu, 7 Jul 2016 15:20:10 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so26446860ywb.2 for ; Thu, 07 Jul 2016 15:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0xFXH7ryjPCipjsFDtlkO+23aAhtK0rugkBVImzTfIw=; b=0oEKTmsEXugwPpMDQ4j1eQv7Ez5eG2jIMlir7IKMb5kgzOc0qEyimo2H/BK7m5FP77 DNxB8i93Rxen61dZsYjMzKICkftvohYQa3Rb/aj4hFO76vnzMZS9A10LuJx4f8IK1hpA UFRq0TUec8lHk78zsT2bBH5GIGpqdj/sy0zxTX/ond7zQkgGNKrtW8tEeCRHFfYqOU7H glOCTJaNgmdRazQaDl3rf4HdprhMxovf7MYDUSJZzSZP+Iz+Oyaiuc6bFzByxEGb7bER +COh1av9y8XtSuJtK+/kR30H+QUxyld/3ZWMM8qhCysfeez8USJnBaDja5qO3Uq4F65e xsqw== 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; bh=0xFXH7ryjPCipjsFDtlkO+23aAhtK0rugkBVImzTfIw=; b=GS7cl5LWmNRVaCAuFgoytSslp+GK/dgWQC9f2QMyYZAA/Sg4qjeBbLOtdWYaTBWhI9 2fyclFbQdl8iSyUAovssZ2wRQjzV9Xk0Vci+kS/Oq05edV+tvv2tZFQxSjDI2Ae23u9+ 1Xrlz0JQob7bJt2zjjUG4d2cmFwEzVPpAVPd5kOuIb37tl7q6kmZFwhgA7E+kNEp6o20 M5mV3E4gyYVrgegKXGTMb5G9AhwCN40fhLeTVYDIlNoxYBD98BoE/6UiGsJAze5cecO1 6INaX8sJBZxSJ1SWqvNU5BqwuFzP6SdKCRTD0qjHtf2HPcyXF9gCbddhZL848hRA0m/L 8JsA== X-Gm-Message-State: ALyK8tJlDvgbDUGmH5pwfs7IQqao15iQxqoh7GkGzOzn/CG3Yogh/FurJ6zsVz81D9DRNYJqfpxP6VfbyR7Flw== X-Received: by 10.129.55.76 with SMTP id e73mr2407363ywa.16.1467930009882; Thu, 07 Jul 2016 15:20:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Thu, 7 Jul 2016 15:19:30 -0700 (PDT) In-Reply-To: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 7 Jul 2016 15:19:30 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1144002ccb851305371316aa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:20:12 -0000 --001a1144002ccb851305371316aa Content-Type: text/plain; charset=UTF-8 On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara wrote: > On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote: > > We've talked several times about designing some sort of TLS delegation > > mechanism. A few of us got together and put together some initial > thoughts > > about the options at: > > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt > > > > The general idea here is to have some mechanism for allowing what > > are effectively end-entities to issue short-lived credentials that allow > > other entities to act on their behalf (e.g., for CDN use cases). > > Comments welcome. > > > > In terms of the security analysis, it's obviously very important that > this > > mechanism > > not present a risk to existing TLS servers. The mechanism designed here > is > > intended to be future safe in that sense, though perhaps we've missed > > something. > > - I think most browsers ignore KeyUsage presently, allowing the broken RSA > key exchange even when KeyUsage does not permit it. And as for server > side, > I don't think many server products check the certificate they try to > load, > just serve it mostly blindly. > This is my sense as well. That text in the document probably needs to be rewritten. > Also, what is the ServerNameList for? As far as I see, the delegated > credential structure only contains one name. Or was it supposed to have > multiple, but there was a typo in definition? > > Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already > have a algorithm field? > > Also, doesn't digitally-signed "eat" all the fields inside? So if you > want to actually transfer the data, you need the actual fields the second > time? All good catches. This was supposed to be more evocative than definitive, and we probably would have been better not providing any definition at all :) -Ekr > > -Ilari > --001a1144002ccb851305371316aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delega= tion
> mechanism. A few of us got together and put together some initial thou= ghts
> about the options at:
> https://www.ietf.org/id/draft-rescorl= a-tls-subcerts-00.txt
>
> The general idea here is to have some mechanism for allowing what
> are effectively end-entities to issue short-lived credentials that all= ow
> other entities to act on their behalf (e.g., for CDN use cases).
> Comments welcome.
>
> In terms of the security analysis, it's obviously very important t= hat this
> mechanism
> not present a risk to existing TLS servers. The mechanism designed her= e is
> intended to be future safe in that sense, though perhaps we've mis= sed
> something.

- I think most browsers ignore KeyUsage presently, allowing the brok= en RSA
=C2=A0 key exchange even when KeyUsage does not permit it. And as for serve= r side,
=C2=A0 I don't think many server products check the certificate they tr= y to load,
=C2=A0 just serve it mostly blindly.

Th= is is my sense as well. That text in the document probably needs to be
rewritten.

=C2=A0
Also, what is the ServerNameList for? As far as I see, the delegated
credential structure only contains one name. Or was it supposed to have
multiple, but there was a typo in definition?

Also why "SignatureScheme algorithm;" ... Doesn't digitally-s= igned already
have a algorithm field?

Also, doesn't digitally-signed "eat" all the fields inside? S= o if you
want to actually transfer the data, you need the actual fields the second time?

All good catches. This was supposed t= o be more evocative than definitive, and
we probably would have b= een better not providing any definition at all :)

= -Ekr
=C2=A0

-Ilari

--001a1144002ccb851305371316aa-- From nobody Thu Jul 7 17:08:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535FF12D8E6 for ; Thu, 7 Jul 2016 17:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnewhRqNpCTC for ; Thu, 7 Jul 2016 17:08:13 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0499112D11B for ; Thu, 7 Jul 2016 17:08:12 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id w59so16830613qtd.3 for ; Thu, 07 Jul 2016 17:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EKZTO93WJKuN/31Ob8Mg6gcTDrIJ40IYFPopx4KR4jE=; b=FxKCcdHujcaxEVPkB/F70HNZ2a1yLVfT8VZG+u84r3bNL9UtCcQSH5ZW/w8S3m81uU pwxbdDdAciNFEKabU8VMPOr7PqqDzSJObt8EgL0/t4LY/ou46+4DoV3EqMFwk4PtgAZY ZMFLqWwhyHEFDW+QY+qAjlWAmdb6VWjhaTkE4= 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; bh=EKZTO93WJKuN/31Ob8Mg6gcTDrIJ40IYFPopx4KR4jE=; b=lGaWK1DM9F+Q9djSz0z2GS7xYUE65HZWc3SI01Y/LIZNmC1/5gJP8YcYqe96LzhY7C 6mWKmn1V4Fb+MK94M6dtxXOgfHrOjBKGtBDAJfj79qdEWw4uLEFJZPA3kay0pcvwpX1i EvMyWjXtqvn4gSkT/Fkktq7L9ErWExxusUEG6sMOv2I71GySPgg/k27yBaJGLcWMT/QA m2cHXAVqH5A40+JzfVq2kM6sZm7JeIm8+Um0lFh8+/TlbEoT+rzeqCwwQ5+sxIShr1wl Qfv2SURo1oDsko6zlaCGL+lM60LaUk8U9kEOcDdubt2FLY6v0LaGnD7XMqLFWiqPhU97 2WaQ== X-Gm-Message-State: ALyK8tId5TyjI3J5FmyzorJ0N65xj5Urk3ALUnvIC1GLLFyZVRwZA2JuSdLOjNriai2OqNxvdXnd9xw4siL+1A== X-Received: by 10.200.57.121 with SMTP id t54mr4651419qtb.3.1467936492001; Thu, 07 Jul 2016 17:08:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Thu, 7 Jul 2016 17:08:11 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:713a:86d:a34a:1966] In-Reply-To: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Thu, 7 Jul 2016 20:08:11 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1140bd2628b34f05371499f3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 00:08:16 -0000 --001a1140bd2628b34f05371499f3 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara wrote: > > I also checked if one could do some funky stuff with credential lifetime > notation to limit the lifetime. Nothing came up (apart for using 16-bit > count in decaseconds (das) only allowing presenting lifetimes up to 7 > days, 14 hours, 2 minutes and 30 seconds). :-> > What would it be anchored to if it's not an absolute time? If you anchor the interval to, say, the issue time of the end-entity cert you haven't limited the resolution of the interval in any useful way: it still needs to be able to express intervals that end at or after the expire time. I suppose an implementor could be less likely to screw up if you also include and sign the interval start and require two things: (1) interval start <= now() + fuzz (2) interval length < 7 days Are these really much easier than (1) interval start <= now() +- fuzz <= interval end (2) interval end - interval start < 7 days ? Kyle --001a1140bd2628b34f05371499f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:

I also checked if one could do some funky stuff with credential lifetime notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->

=
What would it be anchored to if it's not an absolute time? I= f you anchor the interval to, say, the issue time of the end-entity cert yo= u haven't limited the resolution of the interval in any useful way: it = still needs to be able to express intervals that end at or after the expire= time. I suppose an implementor could be less likely to screw up if you als= o include and sign the interval start and require two things:

=
(1) interval start <=3D now() + fuzz
(2) interval len= gth < 7 days

Are these really much easier than

=
(1) interval start <=3D now() +- fuzz <=3D interval end
(2) interval end - interval start < 7 days
?

Kyle
--001a1140bd2628b34f05371499f3-- From nobody Thu Jul 7 19:29:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E410612B05B for ; Thu, 7 Jul 2016 19:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekKWCvzD0Knl for ; Thu, 7 Jul 2016 19:29:09 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 C8C82126FDC for ; Thu, 7 Jul 2016 19:29:09 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id v6so44374540vkb.2 for ; Thu, 07 Jul 2016 19:29:09 -0700 (PDT) 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-transfer-encoding; bh=0furfjwqS/k4u4QH9uMjG23Jin43+gfacPNCswP1owM=; b=XMmLkfbaT+aB6lB3N7qdmhx+bcmy68N2pBvGU0hrL+uCrskKO4sbVttbFD5R7iBwZi f03yvUAyYfz8EhLzVTiVlkB6kKw7NFW5nsEifyGNUYf5ljy30v9iDFYEYwKyWcf6p2cs 4TW2SCRYhNwkV1MlvbnoedWAr2KlFmcvI6S8rhDcf4JgTDGIJPQXqIXn2wLt6EuhmTBm ciJEj7K3m8Rln0n+tbmn23v42Svd3Rxuh6laV/9okv/7N3NE1FMom8tKIsOWwTPnh4M8 380mP1nBpOjm/lmPYX7JnKZ5KXtTzysQLKnye+FbZOGfwj8DX6Igzd0QaKrqbDvRfq0z fKLA== 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-transfer-encoding; bh=0furfjwqS/k4u4QH9uMjG23Jin43+gfacPNCswP1owM=; b=WSGZTpnL5KfHzlXj3mRPdqkaE1dFP0WCm3ARSZCWejNFvWzhLnn/tlW86ZVaB3vejg vpsAJ/hHD4FoU7ByAG/TqNipoJqgNomKC50dpFgNHIeT2G5fR+DcE3V79Y4qsuLh9JXB +MjZKO7Za6EqySQOvoL9uQOosCyzHHqv8fvuRNB6PplFF8Hod+jogfN31IVg3jN03Z2k JiiKRNS39vy6HUaFJanG+osAsXazVVj2hhSsYabJTpENMzVv01pB3Bql998yrJZU8asZ lzyFA9ppiopiZZQoYPfgMBQknRXS3nGZ72jtYIGQXhA/7rnm/siZ3jrPH0mmVd5uunHA gNVA== X-Gm-Message-State: ALyK8tKXo04G7wRrF9hcKIro4inOri7XEZYKCclj6r1WFmoj2oW//MZbtlUZfzIwTHwalBf6FTx6TfDWVbzBdg== X-Received: by 10.159.55.204 with SMTP id q70mr1449018uaq.16.1467944948608; Thu, 07 Jul 2016 19:29:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Thu, 7 Jul 2016 19:29:08 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Thu, 7 Jul 2016 19:29:08 -0700 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 02:29:12 -0000 On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote: > > We've talked several times about designing some sort of TLS delegation > mechanism. A few of us got together and put together some initial thought= s > about the options at: > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt > > The general idea here is to have some mechanism for allowing what > are effectively end-entities to issue short-lived credentials that allow = other > entities to act on their behalf (e.g., for CDN use cases). > Comments welcome. > > In terms of the security analysis, it's obviously very important that thi= s mechanism > not present a risk to existing TLS servers. The mechanism designed here i= s > intended to be future safe in that sense, though perhaps we've missed som= ething. > > I also wanted to clarify a couple points about attacks where the certific= ate that signs the delegated credential is also used for ordinary TLS opera= tion (which generally is a practice that's pretty scary). As noted above it= 's important that existing certs not be usable this way, but maybe future c= erts would be. > > 1. It's important to construct the delegated credential in such a way tha= t you can't use a TLS server as a signing oracle. If you choose "option 2" = where you define a new structure, then it's probably sufficient to use the = TLS 1.3 "context-including" digitally-signed production proposed by AGL. If= you you choose "option 1" where the delegated credential is an X.509 cert,= then you'd need to make some rules about fixing portions of the cert that = the TLS client can't control. > > 2. If you're concerned about attacks like those of Jager et al. which exp= loit RSA decryption, what's important is that the attacker not be able to g= et the server to do TLS 1.2-style static RSA with the key. Playing with the= usage bits definitely makes it harder to configure the server this way (be= cause it's likely to cause bustage) but may not be enough, because sufficie= ntly busted clients and server might be willing to use them that way anyway= . How about limit to ECDSA certificates? This eliminates the Bleichenbacher issues. We can also make this opt in via an extension to the EE certificate: since the certificate is not a CA certificate (even if used that way) the extension can be noncritical. As for format we know we have a TLS 1.3 signed structure that doesn't overlap. Option 2 is easy: throw a key and TAI seconds for interval start and end. I hope we won't need more structure then that. Using X509 runs a risk of cross-format issues, and showing there aren't any is likely to be hard. I don't think we can use name constraints here. Yes, they are opt-in and clients can indicate support, but it may well be that a TLS implementation doesn't know if its X509 validation code will support them as it hands the certificate to a system provided validator. (I believe there was a longstanding Chrome on Windows XP bug for a similar reason). Sincerely, Watson > > In the next rev, we'll update the draft to make these points more clearly= . > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Jul 7 20:29:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8616B12D093 for ; Thu, 7 Jul 2016 20:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 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=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqswUDYXXB_4 for ; Thu, 7 Jul 2016 20:29:01 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3646912B03C for ; Thu, 7 Jul 2016 20:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1467948541; x=1499484541; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v22JDF6VjCTRRvyiqoU1y8YUpmZ30zxdRqSwocDfQvo=; b=Nq3hTZVot77JODMIlMaqDsySE0/nq7G3WAWaG+SPyEz6qT39LKMRshl7 RkEiqgaMih0kZZ3BCDN0KYUbRRmYQqRrEmzjY2Ha7RyKCNbb4yWSvqcLs iZRYEh1uNsCfLCRIQVod9N0m98mRBKpBm1nvhx9uPQdiaSeEP3MxG5YdZ Fv+UdLn//x10DI3XScxFo7B3ScVejA/5kbMS6dUncDyUNO3J4iZ7kD6hg MsWE4A2yjVtIVg9knHiMWlducOJlMyg5QlLq3DJ2rXtwecOS76Gly70D9 Z4PkBkvA8j8Ha9bRI/CVqzCwjn/I0cfpX9fbFtn1q106V2HoadEogGkrT w==; X-IronPort-AV: E=Sophos;i="5.28,327,1464609600"; d="scan'208";a="95637560" 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; 08 Jul 2016 15:28:58 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 8 Jul 2016 15:28:58 +1200 From: Peter Gutmann To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] draft-rescorla-tls-subcerts Thread-Index: AQHR2IXg2E2zYiv3ukOGpCbMgJc8F6AN4CtN Date: Fri, 8 Jul 2016 03:28:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CBE3BD@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: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 03:29:06 -0000 Eric Rescorla writes:=0A= =0A= >We've talked several times about designing some sort of TLS delegation=0A= >mechanism. A few of us got together and put together some initial thoughts= =0A= >about the options at:=0A= >https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt=0A= =0A= That's going to be a tricky one. The PKIX standing committee has always=0A= rigidly (and in some cases I'd say rabidly) opposed anything that would all= ow=0A= end users to bypass CAs (in one case the WG chair killed a proposal for=0A= delegated certs with the comment "we don't want to turn X.509 into PGP").= =0A= Admittedly PKIX is now defunct, but there are still enough PKIX members in = the=0A= IETF that it could be tricky getting anything done.=0A= =0A= Another issue is how you're going to do it. You really need to have an EE= =0A= able to use a standard cert to issue short-term certs for high-exposure=0A= environments, so only the high-risk key needs to be online. One of the=0A= proposals for this (which I have a link to, since I wrote it in this case)= =0A= was:=0A= =0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt=0A= =0A= This talks about all of the issues involved.=0A= =0A= The alternative is to use a cert to sign "credentials", whatever form that = may=0A= take. That's going to get ugly since you're now introducing something that= 's=0A= in effect a certificate, but isn't called a certificate (yes, you can whitt= le=0A= it down a bit, but eventually you'll want to add more features, and end up= =0A= reinventing certs). =0A= =0A= I would go for delegated certs, since 99% of the work is already done for y= ou=0A= (formats, data types, how to process them, code to handle them, etc).=0A= =0A= Peter.=0A= =0A= From nobody Thu Jul 7 20:51:25 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 7072712D520; Thu, 7 Jul 2016 20:51:24 -0700 (PDT) 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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708035124.18636.88079.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 20:51:24 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 03:51:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename : draft-ietf-tls-dnssec-chain-extension-01.txt Pages : 12 Date : 2016-07-07 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 21:54:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1A812D1D8 for ; Thu, 7 Jul 2016 21:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbPfkNGr6NG5 for ; Thu, 7 Jul 2016 21:54:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD9612B053 for ; Thu, 7 Jul 2016 21:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8248C300540 for ; Fri, 8 Jul 2016 00:54:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zkOtIQ8PU49A for ; Fri, 8 Jul 2016 00:54:44 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id E944C3002C4; Fri, 8 Jul 2016 00:54:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF71C3BA-8B6B-4F92-8B46-335A219F9BDD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 8 Jul 2016 00:53:54 -0400 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 04:54:52 -0000 --Apple-Mail=_CF71C3BA-8B6B-4F92-8B46-335A219F9BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: I have not had a chance to look at the draft yet, but based on your = cover note you seem to have several requirements in common with RFC = 3820. Russ On Jul 7, 2016, at 3:28 PM, Eric Rescorla wrote: > We've talked several times about designing some sort of TLS delegation > mechanism. A few of us got together and put together some initial = thoughts > about the options at: > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt >=20 > The general idea here is to have some mechanism for allowing what > are effectively end-entities to issue short-lived credentials that = allow other > entities to act on their behalf (e.g., for CDN use cases). > Comments welcome. >=20 > In terms of the security analysis, it's obviously very important that = this mechanism > not present a risk to existing TLS servers. The mechanism designed = here is > intended to be future safe in that sense, though perhaps we've missed = something. >=20 > I also wanted to clarify a couple points about attacks where the = certificate that signs the delegated credential is also used for = ordinary TLS operation (which generally is a practice that's pretty = scary). As noted above it's important that existing certs not be usable = this way, but maybe future certs would be. >=20 > 1. It's important to construct the delegated credential in such a way = that you can't use a TLS server as a signing oracle. If you choose = "option 2" where you define a new structure, then it's probably = sufficient to use the TLS 1.3 "context-including" digitally-signed = production proposed by AGL. If you you choose "option 1" where the = delegated credential is an X.509 cert, then you'd need to make some = rules about fixing portions of the cert that the TLS client can't = control. >=20 > 2. If you're concerned about attacks like those of Jager et al. which = exploit RSA decryption, what's important is that the attacker not be = able to get the server to do TLS 1.2-style static RSA with the key. = Playing with the usage bits definitely makes it harder to configure the = server this way (because it's likely to cause bustage) but may not be = enough, because sufficiently busted clients and server might be willing = to use them that way anyway. >=20 > In the next rev, we'll update the draft to make these points more = clearly. >=20 > -Ekr >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_CF71C3BA-8B6B-4F92-8B46-335A219F9BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Eric:

I have not had a chance to = look at the draft yet, but based on your cover note you seem to have = several requirements in common with RFC = 3820.

Russ


On Jul 7, 2016, at 3:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:

We've talked several times about designing some sort of TLS = delegation
mechanism. A few of us got together and put together some = initial thoughts
about the options at:

The general idea here is to have = some mechanism for allowing what
are effectively end-entities = to issue short-lived credentials that allow other
entities to = act on their behalf (e.g., for CDN use cases).
Comments = welcome.

In terms of the security analysis, = it's obviously very important that this mechanism
not present = a risk to existing TLS servers. The mechanism designed here = is
intended to be future safe in that sense, though perhaps = we've missed something.

I also wanted to = clarify a couple points about attacks where the certificate that signs = the delegated credential is also used for ordinary TLS operation (which = generally is a practice that's pretty scary). As noted above it's = important that existing certs not be usable this way, but maybe future = certs would be.

1. It's important to construct = the delegated credential in such a way that you can't use a TLS server = as a signing oracle. If you choose "option 2" where you define a new = structure, then it's probably sufficient to use the TLS 1.3 = "context-including" digitally-signed production proposed by AGL. If you = you choose "option 1" where the delegated credential is an X.509 cert, = then you'd need to make some rules about fixing portions of the cert = that the TLS client can't control.

2. If you're = concerned about attacks like those of Jager et al. which exploit RSA = decryption, what's important is that the attacker not be able to get the = server to do TLS 1.2-style static RSA with the key. Playing with the = usage bits definitely makes it harder to configure the server this way = (because it's likely to cause bustage) but may not be enough, because = sufficiently busted clients and server might be willing to use them that = way anyway.

In the next rev, we'll update the = draft to make these points more = clearly.

-Ekr


=

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

= --Apple-Mail=_CF71C3BA-8B6B-4F92-8B46-335A219F9BDD-- From nobody Fri Jul 8 01:33:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1161112B01B for ; Fri, 8 Jul 2016 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVswb2wqdHN5 for ; Fri, 8 Jul 2016 01:33:51 -0700 (PDT) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BDA1288B8 for ; Fri, 8 Jul 2016 01:33:51 -0700 (PDT) Received: by mail-qt0-x241.google.com with SMTP id f89so3874748qtd.0 for ; Fri, 08 Jul 2016 01:33:51 -0700 (PDT) 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; bh=wnShyLI8xoOrlY/P7h4b64KA+HVqHArdgaaV8DQRiuI=; b=GcfNGPcEIKugfjTapctH1Eq7U5Feoi6derq8iV8DYIjYjneYBxijsYWUEbKlXcu6eW YvThW0MbMXUeQsTjXr+diOiYw149A0EZi/DUoTLuiRxp06520Hvadw0GN/ou+VcUERp6 jubnQygzyH/Jojc6qy5+vWJARtwbGhR3FmdMEh/wCYVrGOFpB7l4EO05WuYKdArNCRx6 TciO2EpDdWoacfUS3yz2wmPMpxloKmy0xjvzm8PlynGHZkZcE8Jyj7a4jXls9buLYE1D uPgh6qtqodqRWfGi524+ZFynK9H+SEgT6sKixlwPFgCLLnHO/RRWpBX53ohVfTsOqdvl 5sSA== 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; bh=wnShyLI8xoOrlY/P7h4b64KA+HVqHArdgaaV8DQRiuI=; b=dioT3vqRXdN73b05TOt7RpU/wJI0YxZ1AnCmwl/QXIzUQdsK4FW6pUmFXBC2fRolc/ 2t076VsOY5zaghaX1T8eNf6fFzxIZEZbFzw/jChGfBfIn2HS84tJoFoOVBuTXQyGkEO5 B4ezhBUOyuqgSE2iE4LUotttN09zE1t6xRwnHZTE2K007Jy4Chjew6W26An0o1oCfgvM 6U0zxr8oTIuoAgtha5xvlBFhKgvQGfOudQ+nJIsFKR2cbC8A+5UzD1FNE9Gb0lTze/0t w12FRdFZbFpyefodquwx5kpueyvq58+2AOUr54j35xnWrTQ4TBpgTiAaE3iA+c0Gy5YG CWkw== X-Gm-Message-State: ALyK8tKGMV840EBDlJ4wsY4oQXIcPWc/M1xJQuuqmaSwIRnaHCS7wQUsN+82K+rDLYw7CcHYNPMsNEMcUiIrcQ== X-Received: by 10.194.158.41 with SMTP id wr9mr4056922wjb.25.1467966830106; Fri, 08 Jul 2016 01:33:50 -0700 (PDT) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.28.6.130 with HTTP; Fri, 8 Jul 2016 01:33:30 -0700 (PDT) In-Reply-To: References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> From: Cas Cremers Date: Fri, 8 Jul 2016 09:33:30 +0100 X-Google-Sender-Auth: UUaxO5EjnsWyoz4TaWWQdH2M-DU Message-ID: To: Douglas Stebila Content-Type: multipart/alternative; boundary=089e011826b2736fe505371ba96b Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:33:55 -0000 --089e011826b2736fe505371ba96b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, After several discussions (including the ones Douglas points out) I have also come round to option 1 as the preferred way forward. For our symbolic analysis in Tamarin it should not make a big difference anyway. Best, Cas On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila wrote: > With Hugo's analysis of the secure channel-like security afforded even > when the application key is used to encrypt non-application data, and as > C=C3=A9dric pointed out to me the application key will be used to encrypt > non-application data like certain alert messages; so I think option 1 is = a > reasonable choice, and option 3 would not recover the composability > property we hoped it might. > > Douglas > > > > On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk > wrote: > > > > I do not have an objection to option 1 if re-phrased as > > Option 1 - use the same key for protecting both *post*-handshake and > applications messages.. > > > > I believe this is what was intended by that option anyway. Let me > clarify. > > > > I understand the question as relating *only* to post-handshake messages > and not > > to the main handshake (three initial flights). For the latter we have k= ey > > separation in the sense that none of these main-handshake messages is > encrypted > > under the application key but rather under dedicated handshake keys. > This should > > not be changed as it provides key indistinguishability to the > application key, a > > desirable design and analysis (=3Dproof) modularity property. > > > > On the other hand, for post-handshake messages, and particularly for > encrypting > > post-handshake client authentication messages, preserving key > > indistinguishability is not relevant since at the time of post-handshak= e > > client authentication, the application key has already lost its > indistinguishability > > by the mere fact that the key was used to encrypt application data. Key > > indistinguishability is the main reason to insist in key separation and > this > > principle does not apply here anymore hence removing the objection to 1= . > > > > I'd note that the best one could hope for in the post-handshake setting > is that > > as a result of post-handshake client authentication the application key > becomes > > a secure mutually-authenticated key for providing "secure channels" > security. > > As pointed out by others in previous posts I have an analysis showing > that this > > delayed mutual authentication guarantee is achieved even if one uses th= e > > application key to encrypt the post-handshake messages. I have > circulated a > > preliminary version of the paper among cryptographers working on TLS 1= .3 > > and I will post a public copy next week so this can be scrutinized > further. > > > > Hugo > > > > > > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > > If we are left with 1 or 3, the miTLS team would prefer 1. > > > > On the cryptographic side, Hugo has a recent (draft) paper that seems t= o > provide > > some more justification for (1), at least for client authentication. > > > > I know this is a bit off-topic, but the miTLS team would also like to > get rid of 0-RTT ClientFinished > > if that is the only message left in the 0-RTT encrypted handshake > flight. That should remove > > another Handshake/Data key separation from the protocol, leaving only 3 > keys: 0-RTT data, > > 1-RTT handshake, and 1-RTT data. > > > > Best, > > -Karthik > > > > > >> On 07 Jul 2016, at 02:49, David Benjamin wrote= : > >> > >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: > >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett > wrote: > >> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > >> > I'm also curious which post-handshake messages are the problem. If w= e > were > >> > to rename "post-handshake handshake messages" to "post-handshake bon= us > >> > messages" with a distinct bonus_message record type, where would the= re > >> > still be an issue? (Alerts and application data share keys and this > seems > >> > to have been fine.) > >> > >> Recasting all the post-handshake handshake messages as not something > named "handshake" does make a degree of sense, on its own. (bikeshedding: > I'd name it something more descriptive like "secondary negotiation" > messages or something, though.) Even if this doesn't directly help with t= he > issue at hand here, does forking these into a new ContentType sound like = a > useful move, in general? > >> > >> I'm not sure what this would accomplish. > >> > >> Me neither. To clarify, I mention this not as a suggestion, but to > motivate asking about the type of message. If the only reason the proofs > want them in the handshake bucket rather than the application data bucket > is that they say "handshake" in them then, sure, let's do an > inconsequential re-spelling and move on from this problem. > >> > >> But presumably something about the messages motivate this key > separation issue and I'd like to know what they are. > >> > >> David > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e011826b2736fe505371ba96b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

After several discussions (includin= g the ones Douglas points out) I have also come round to option 1 as the pr= eferred way forward. For our symbolic analysis in Tamarin it should not mak= e a big difference anyway.

Best,

Cas=


On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila <dstebila@gmail= .com> wrote:
With Hugo'= s analysis of the secure channel-like security afforded even when the appli= cation key is used to encrypt non-application data, and as C=C3=A9dric poin= ted out to me the application key will be used to encrypt non-application d= ata like certain alert messages; so I think option 1 is a reasonable choice= , and option 3 would not recover the composability property we hoped it mig= ht.

Douglas


> On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>
> I do not have an objection to option 1 if re-phrased as
> Option 1 - use the same key for protecting both *post*-handshake and a= pplications messages..
>
> I believe this is what was intended by that option anyway. Let me clar= ify.
>
> I understand the question as relating *only* to post-handshake message= s and not
> to the main handshake (three initial flights). For the latter we have = key
> separation in the sense that none of these main-handshake messages is = encrypted
> under the application key but rather under dedicated handshake keys. T= his should
> not be changed as it provides key indistinguishability to the applicat= ion key, a
> desirable design and analysis (=3Dproof) modularity property.
>
> On the other hand, for post-handshake messages, and particularly for e= ncrypting
> post-handshake client authentication messages, preserving key
> indistinguishability is not relevant since at the time of post-handsha= ke
> client authentication, the application key has already lost its indist= inguishability
> by the mere fact that the key was used to encrypt application data. Ke= y
> indistinguishability is the main reason to insist in key separation an= d this
> principle does not apply here anymore hence removing the objection to = 1.
>
> I'd note that the best one could hope for in the post-handshake se= tting is that
> as a result of post-handshake client authentication the application ke= y becomes
> a secure mutually-authenticated key for providing "secure channel= s" security.
> As pointed out by others in previous posts I have an analysis showing = that this
> delayed mutual authentication guarantee is achieved even if one uses t= he
> application key to encrypt the post-handshake messages. I have circula= ted a
> preliminary version of the=C2=A0 paper among cryptographers working on= TLS 1.3
> and=C2=A0 I will post a public copy next week so this can be scrutiniz= ed further.
>
> Hugo
>
>
> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrot= e:
> If we are left with 1 or 3, the miTLS team would prefer 1.
>
> On the cryptographic side, Hugo has a recent (draft) paper that seems = to provide
> some more justification for (1), at least for client authentication. >
> I know this is a bit off-topic, but the miTLS team would also like to = get rid of 0-RTT ClientFinished
> if that is the only message left in the 0-RTT encrypted handshake flig= ht. That should remove
> another Handshake/Data key separation from the protocol, leaving only = 3 keys: 0-RTT data,
> 1-RTT handshake, and 1-RTT data.
>
> Best,
> -Karthik
>
>
>> On 07 Jul 2016, at 02:49, David Benjamin <davidben@chromium.org> wrote:
>>
>> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>> > I'm also curious which post-handshake messages are the pr= oblem. If we were
>> > to rename "post-handshake handshake messages" to &q= uot;post-handshake bonus
>> > messages" with a distinct bonus_message record type, whe= re would there
>> > still be an issue? (Alerts and application data share keys an= d this seems
>> > to have been fine.)
>>
>> Recasting all the post-handshake handshake messages as not somethi= ng named "handshake" does make a degree of sense, on its own. (bi= keshedding: I'd name it something more descriptive like "secondary= negotiation" messages or something, though.) Even if this doesn't= directly help with the issue at hand here, does forking these into a new C= ontentType sound like a useful move, in general?
>>
>> I'm not sure what this would accomplish.
>>
>> Me neither. To clarify, I mention this not as a suggestion, but to= motivate asking about the type of message. If the only reason the proofs w= ant them in the handshake bucket rather than the application data bucket is= that they say "handshake" in them then, sure, let's do an in= consequential re-spelling and move on from this problem.
>>
>> But presumably something about the messages motivate this key sepa= ration issue and I'd like to know what they are.
>>
>> David
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--089e011826b2736fe505371ba96b-- From nobody Fri Jul 8 01:34:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F612B043 for ; Fri, 8 Jul 2016 01:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAuZ6U9i3F_j for ; Fri, 8 Jul 2016 01:34:51 -0700 (PDT) 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 AE58B1288B8 for ; Fri, 8 Jul 2016 01:34:51 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0F77DCBB9F4E6; Fri, 8 Jul 2016 08:34:48 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u688Ymb9023497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 08:34:49 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u688YmSi004934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 10:34:48 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:34:48 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Stephen Farrell , Nikos Mavrogiannopoulos Thread-Topic: [TLS] DTLS 1.3 Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgA== Date: Fri, 8 Jul 2016 08:34:47 +0000 Message-ID: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> In-Reply-To: <577E4392.6060408@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <4CCB84AEA4082A48A24CFCF3BFA30274@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:34:54 -0000 Hi Nikos, Stephen, It seems to me that both your views (high resistance to traceability and low resource investment on server side) can be accommodated in a single scheme. Going back to the hash chain proposal that Stephen did a few emails ago on this same thread. If: 1. the length of the hash chain is the shortest between the lengths each peer proposes, and 2. the client is left in complete control of the rollover policy for the session identifier (i.e. deciding when to switch to a new Id), then we would have a lot of flexibility (ranging from one session identifier which lives forever to one session identifier per packet -- that's entirely decided by the client), while at the same time giving the server a voice in determining an upper bound to the resources it needs to reserve per each session. Cheers, t On 07/07/2016 12:57, "TLS on behalf of Stephen Farrell" wrote: >On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote: >> On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: >>> Hiya, >>> >>> Just on this one thing... >>> >>> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >>>> >>>> does not make the situation any worse >>>> than we have today. >>> I don't accept that is the correct goal. That form of >>> argument is what lead to us standardising the HTTP >>> Forwarded header field, which IMO was a disimprovement. >>> (An argument I lost in the end in that case [1], but >>> 'twas close, and back in 2012 so might go the other >>> way today;-) >>> I would argue that the correct goal is to make things >>> better whenever possible, with that being especially >>> important for protocols like (D)TLS on which many >>> other things depend. >>> I do agree that any scheme developed would need to >>> meet the state management requirements of servers. >>> I'm not convinced those requirements call for a new >>> super-cookie though:-) >>=20 >> I understand your point, I'm not fully convinced by that argumentation. >> I may be wrong of course, but I'll try to explain my point. Indeed >> putting privacy first should be a goal of TLS/DTLS, but to the extent >> it covers the protocol goals. What you propose is to make a stream >> anonymous, untrackable. > >Totally wrong, sorry. What I propose is not adding new ways to >allow a network observer to track a tls client using the same >tls session over multiple transport layer connections, unless >that is really unavoidable. > >Exaggerating my argument is not useful. Not is it at all convincing. > >S. > >> However, that (anonymity or untrackability of >> the stream) was never a stated goal of TLS/DTLS. In fact TLS is by >> definition trackable over TCP and one can see in the clear the IPs of >> the two peers communicating. That doesn't change by switching to DTLS, >> except for unfortunate situations of routers losing state and client >> roaming, which current servers cannot easily cope with, and that's the >> problem I attempt to address. >>=20 >> I think the principle of doing one simple thing and doing it well, >> applies to protocols as well. TLS and DTLS provide a layer of >> confidentiality and authenticity. Anonymity, untrackability can be >> provided by other protocols focused on that such as TOR. >>=20 >> regards, >> Nikos >>=20 >>=20 > > From nobody Fri Jul 8 01:51:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B058112D08E for ; Fri, 8 Jul 2016 01:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e6m9kYORila for ; Fri, 8 Jul 2016 01:51:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD11212B006 for ; Fri, 8 Jul 2016 01:51:40 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F0AEA3F729; Fri, 8 Jul 2016 08:44:21 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u688iJ6x016303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jul 2016 04:44:21 -0400 Message-ID: <1467967459.3009.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Date: Fri, 08 Jul 2016 10:44:19 +0200 In-Reply-To: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> 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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 08 Jul 2016 08:44:22 +0000 (UTC) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:51:43 -0000 On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote: > Hi Nikos, Stephen, > > It seems to me that both your views (high resistance to traceability > and > low resource investment on server side) can be accommodated in a > single scheme. > Going back to the hash chain proposal that Stephen did a few emails > ago on > this same thread. If: > 1. the length of the hash chain is the shortest between the lengths > each > peer proposes, and Hi,  How would the hash chain matching work for a server handling multiple clients? regards, Nikos From nobody Fri Jul 8 02:06:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0528A12B04E for ; Fri, 8 Jul 2016 02:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aiWhCFDyeYl for ; Fri, 8 Jul 2016 02:05:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D7012B04D for ; Fri, 8 Jul 2016 02:05:57 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ED72A720BD; Fri, 8 Jul 2016 09:05:55 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6895rBJ031951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jul 2016 05:05:55 -0400 Message-ID: <1467968753.3009.11.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Date: Fri, 08 Jul 2016 11:05:53 +0200 In-Reply-To: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 08 Jul 2016 09:05:56 +0000 (UTC) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:06:00 -0000 On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote: > > How would the hash chain matching work for a server handling > > multiple > > clients? > Sorry, I'm not sure I understand the question.  Are you asking what > happens if there is an Id collision between two separate hash chains? No, my question is much simpler. How would a server handling for example 20000 clients, will figure to which chain a hash of H(x) belongs to? Will it have to iterate through all the chains (client states) and test for matching or there is something more clever than that? regards, Nikos From nobody Fri Jul 8 02:06:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BDD12D52D for ; Fri, 8 Jul 2016 02:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u9DsAsq6Z0n for ; Fri, 8 Jul 2016 02:06:12 -0700 (PDT) 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 4D98712D54C for ; Fri, 8 Jul 2016 01:59:19 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7F05CB285D48F; Fri, 8 Jul 2016 08:59:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u688xHDp012241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 08:59:17 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u688xGk7017727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 10:59:16 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:59:16 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Nikos Mavrogiannopoulos , "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Thread-Topic: [TLS] DTLS 1.3 Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgP//8e2AgAAU6gA= Date: Fri, 8 Jul 2016 08:59:15 +0000 Message-ID: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> In-Reply-To: <1467967459.3009.7.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <6208607B76A8394A9550085155EDD736@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:06:14 -0000 Hi Nikos, On 08/07/2016 09:44, "Nikos Mavrogiannopoulos" wrote: >On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote: >> Hi Nikos, Stephen, >>=20 >> It seems to me that both your views (high resistance to traceability >> and >> low resource investment on server side) can be accommodated in a >> single scheme. >> Going back to the hash chain proposal that Stephen did a few emails >> ago on >> this same thread. If: >> 1. the length of the hash chain is the shortest between the lengths >> each >> peer proposes, and > >Hi, > How would the hash chain matching work for a server handling multiple >clients? Sorry, I'm not sure I understand the question. Are you asking what happens if there is an Id collision between two separate hash chains? If so, in general the nature of the keyed hash used to produce the chain would help keeping the number of collisions low. In case an Id is a dup, the server can spot the condition and signal it back to the client. Cheers, t From nobody Fri Jul 8 02:29:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139D212D121 for ; Fri, 8 Jul 2016 02:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6YeirTxs1ns for ; Fri, 8 Jul 2016 02:29:46 -0700 (PDT) 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 AEA5012D09A for ; Fri, 8 Jul 2016 02:29:46 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E7D40C351879B; Fri, 8 Jul 2016 09:29:42 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u689Ti53023098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 09:29:44 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u689TgD5009357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 11:29:43 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 11:29:42 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Nikos Mavrogiannopoulos , "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Thread-Topic: [TLS] DTLS 1.3 Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgP//8e2AgAAU6gD///EdgIAAF2WA Date: Fri, 8 Jul 2016 09:29:42 +0000 Message-ID: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.com> In-Reply-To: <1467968753.3009.11.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <14EC343322C7384AAEBE8B72FCB28A38@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:29:49 -0000 On 08/07/2016 10:05, "Nikos Mavrogiannopoulos" wrote: >On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote: > >> > How would the hash chain matching work for a server handling >> > multiple >> > clients? >> Sorry, I'm not sure I understand the question. Are you asking what >> happens if there is an Id collision between two separate hash chains? > >No, my question is much simpler. How would a server handling for >example 20000 clients, will figure to which chain a hash of H(x) >belongs to? Will it have to iterate through all the chains (client >states) and test for matching or there is something more clever than >that? Ah! The hash chain would be computed at the end of the handshake, so all L Ids can be put in a hash table that maps them to the same DTLS context. When a data record comes in, its Id can be used to look up the context in O(1). Clearly the server needs to negotiate a sensible L if it doesn't want to blow up. From nobody Fri Jul 8 02:56:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1212D0B4 for ; Fri, 8 Jul 2016 02:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.842 X-Spam-Level: X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ma8s4aLGVJ9 for ; Fri, 8 Jul 2016 02:55:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70D012B004 for ; Fri, 8 Jul 2016 02:55:56 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 942238E360; Fri, 8 Jul 2016 09:55:55 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.63]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u689trxm030133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jul 2016 05:55:54 -0400 Message-ID: <1467971752.3009.22.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Date: Fri, 08 Jul 2016 11:55:52 +0200 In-Reply-To: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.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.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 08 Jul 2016 09:55:55 +0000 (UTC) Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:55:59 -0000 On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote: > > > > How would the hash chain matching work for a server handling > > > > multiple > > > > clients? > > > Sorry, I'm not sure I understand the question.  Are you asking > > > what > > > happens if there is an Id collision between two separate hash > > > chains? > > No, my question is much simpler. How would a server handling for > > example 20000 clients, will figure to which chain a hash of H(x) > > belongs to? Will it have to iterate through all the chains (client > > states) and test for matching or there is something more clever > > than > > that? > Ah! The hash chain would be computed at the end of the handshake, so > all L > Ids can be put in a hash table that maps them to the same DTLS > context. > When a data record comes in, its Id can be used to look up the > context in > O(1). > Clearly the server needs to negotiate a sensible L if it doesn't want > to blow up. As long as both the client and the server are able to notify each other that they only support L=1 I'd be content with it. However, I'd prefer a simple solution and defer the hash chain negotiation for a separate extension, since we cannot foresee how and if such an extension will be used. As we saw with heartbleed any unused complexity is not necessary adding value. regards, Nikos From nobody Fri Jul 8 03:09:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8412D115 for ; Fri, 8 Jul 2016 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYfEn1o38W5f for ; Fri, 8 Jul 2016 03:09:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF96712D107 for ; Fri, 8 Jul 2016 03:09:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3064F4A00; Fri, 8 Jul 2016 13:09:37 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id I8QpFxPiOPFb; Fri, 8 Jul 2016 13:09:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D9C8027F; Fri, 8 Jul 2016 13:09:36 +0300 (EEST) Date: Fri, 8 Jul 2016 13:09:34 +0300 From: Ilari Liusvaara To: Kyle Rose Message-ID: <20160708100934.GA14077@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160707221324.GA13128@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:09:41 -0000 On Thu, Jul 07, 2016 at 08:08:11PM -0400, Kyle Rose wrote: > On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara > wrote: > > > > > I also checked if one could do some funky stuff with credential lifetime > > notation to limit the lifetime. Nothing came up (apart for using 16-bit > > count in decaseconds (das) only allowing presenting lifetimes up to 7 > > days, 14 hours, 2 minutes and 30 seconds). :-> > > > > What would it be anchored to if it's not an absolute time? There is validity start time in there, the relative end time would be relative to that. That is, instead of saying "this is valid from t1 to t2", saying "this is valid from t to t+dt". No real perference either way, it was just an experiment to play with time notations. -Ilari From nobody Fri Jul 8 03:21:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA112D14F for ; Fri, 8 Jul 2016 03:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8yPeXYIyi1e for ; Fri, 8 Jul 2016 03:21:15 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13712D0B3 for ; Fri, 8 Jul 2016 03:21:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AF51D1194; Fri, 8 Jul 2016 13:21:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id DVhHa61hwAw7; Fri, 8 Jul 2016 13:21:13 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4B55421C; Fri, 8 Jul 2016 13:21:13 +0300 (EEST) Date: Fri, 8 Jul 2016 13:21:10 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20160708102110.GB14077@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:21:18 -0000 On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote: > On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote: > > How about limit to ECDSA certificates? This eliminates the > Bleichenbacher issues. We can also make this opt in via an extension > to the EE certificate: since the certificate is not a CA certificate > (even if used that way) the extension can be noncritical. You mean ECDSA legacy signature type (TLS_ECDHE_ECDSA_WITH_* ciphersuites)? There's EdDSA too (and it would meet the above definition)? New extension would need CAs to issue it, and getting them to do that could be, erm... "laborious". > As for format we know we have a TLS 1.3 signed structure that doesn't > overlap. Option 2 is easy: throw a key and TAI seconds for interval > start and end. I hope we won't need more structure then that. Using > X509 runs a risk of cross-format issues, and showing there aren't any > is likely to be hard. Or use POSIX time notation if you can tolerate being off by a second due to leap secods. Then the proposal had server name or server name list. Dunno if those are needed. > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it hands the certificate to a system provided validator. (I > believe there was a longstanding Chrome on Windows XP bug for a > similar reason). The nasty Chrome on WinXP bug I was aware of was that WinXP code couldn't handle certificates that were like "allow all, except .foo". LE X1 intermediate hit that bug, causing lots of trouble, even with WinXP being EoL'd. -Ilari From nobody Fri Jul 8 03:36:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4A12D559 for ; Fri, 8 Jul 2016 03:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGp3GzVD-RIP for ; Fri, 8 Jul 2016 03:36:07 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3233012D7F6 for ; Fri, 8 Jul 2016 03:36:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 559EF1194 for ; Fri, 8 Jul 2016 13:36:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id yc3qkyYysmlS for ; Fri, 8 Jul 2016 13:36:06 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 138EA27B for ; Fri, 8 Jul 2016 13:36:06 +0300 (EEST) Date: Fri, 8 Jul 2016 13:36:03 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160708103603.GC14077@LK-Perkele-V2.elisa-laajakaista.fi> References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:36:09 -0000 On Mon, Jul 04, 2016 at 05:03:12PM +0300, Ilari Liusvaara wrote: > - KeyUpdate does not work in DTLS. Might just use epochs for similar > purpose, and reserve first few epochs for special purposes. Eeh... Epochs have the problem that processing records with epochs far into the future is expensive (even to reject records in failed MAC check). This problem didn't turn out to be trivial... :-/ -Ilari From nobody Fri Jul 8 04:06:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2742D12B02D for ; Fri, 8 Jul 2016 04:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hit_B3iXsDZ3 for ; Fri, 8 Jul 2016 04:06:52 -0700 (PDT) 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 6496812D0A5 for ; Fri, 8 Jul 2016 04:06:51 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id AEE61583558FD; Fri, 8 Jul 2016 11:06:46 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u68B6lWD030589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 11:06:47 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u68B6fL5016969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 13:06:47 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 13:06:46 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Nikos Mavrogiannopoulos , "Fossati, Thomas (Nokia - GB)" , Stephen Farrell Thread-Topic: [TLS] DTLS 1.3 Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgP//8e2AgAAU6gD///EdgIAAF2WA///2kgAABJIYAA== Date: Fri, 8 Jul 2016 11:06:46 +0000 Message-ID: References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com> <577AD00E.1000103@cs.tcd.ie> <367617282.2740434.1467726582647.JavaMail.zimbra@redhat.com> <577BC302.5050000@cs.tcd.ie> <1467879217.3426.17.camel@redhat.com> <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.com> <1467971752.3009.22.camel@redhat.com> In-Reply-To: <1467971752.3009.22.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <5ECB2BF093AB6F4084738A8892780351@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 11:06:54 -0000 Hi Nikos, On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" wrote: >On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote: > >> > > > How would the hash chain matching work for a server handling >> > > > multiple >> > > > clients? >> > > Sorry, I'm not sure I understand the question. Are you asking >> > > what >> > > happens if there is an Id collision between two separate hash >> > > chains? >> > No, my question is much simpler. How would a server handling for >> > example 20000 clients, will figure to which chain a hash of H(x) >> > belongs to? Will it have to iterate through all the chains (client >> > states) and test for matching or there is something more clever >> > than >> > that? >> Ah! The hash chain would be computed at the end of the handshake, so >> all L >> Ids can be put in a hash table that maps them to the same DTLS >> context. >> When a data record comes in, its Id can be used to look up the >> context in >> O(1). >> Clearly the server needs to negotiate a sensible L if it doesn't want >> to blow up. > >As long as both the client and the server are able to notify each other >that they only support L=3D1 I'd be content with it. In the straw man I proposed above, it is sufficient for the server to say L=3D1. In that case the client will trigger a re-handshake when its Id rollover policy says so. >However, I'd prefer >a simple solution and defer the hash chain negotiation for a separate >extension, since we cannot foresee how and if such an extension will be >used. As we saw with heartbleed any unused complexity is not necessary >adding value. I wholeheartedly agree on the implementation simplicity goal. I think the proposal allows both sides to be as simple as they want to. Cheers, t From nobody Fri Jul 8 06:03:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65512D1EA for ; Fri, 8 Jul 2016 06:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn35mBLcYpsz for ; Fri, 8 Jul 2016 06:03:38 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2331F12B03A for ; Fri, 8 Jul 2016 06:03:37 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id n132so8904499qka.0 for ; Fri, 08 Jul 2016 06:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=waGPqy9ugQit7i5LQ/P7eskGcG8twixUF0s52DopdEo=; b=ciaAck0RjDGQZupZwzCCDwAvuX09lLUIglwTg76KkLU2MK+blUKqHM+/P7uyYcwBoU b9Kr1RIFPZh/U9n3RW5KCVoqpxkZ4+5zgds+oCltm1wIdlsIBctoEgG2DYfTGYZ7st61 a1aAjutI0f1EnbPzmOATdj4hSLfDIvKvrL17o= 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; bh=waGPqy9ugQit7i5LQ/P7eskGcG8twixUF0s52DopdEo=; b=Ipo4quChh/5S66uFGXMvPoUd3zKglvCx0ES73qM2RFJDtAwKqkUjnKO5Gdy7x4oufn jje6NxD1XosD7LynTZQ7aT87SmS6Ao1C1vy8Z3QDzlBuM7SIJIm4dsmoSuckA7QNo8y8 GNtegFwvidL8nM5tSGJbJPJYc6YSObwyVK2xEpMa2KUhbSuGquXrYpsPk5RqEsl/X+FD C0o/0hD4864qDBDNTI0gewtEHEEU44Dvb1pmx4p0Ts1vxXxOK+4l5skX175O9FRoWerG ECuLJTfX6PrKOFlWmnu6VvU1Vp1Bn2Q7FsKezzh4JgpXSA0fVpHra5mZxkMdCkE5aQPJ alMg== X-Gm-Message-State: ALyK8tIS2BRX2PHWUY8h1gDL7DxSMR8qcBtOZUlQzHj4avCkR9O/rm7bK+F7OA6jbkRhjcWZIqHOp7ix/QJKnA== X-Received: by 10.55.207.81 with SMTP id e78mr7075424qkj.75.1467983016827; Fri, 08 Jul 2016 06:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.195.1 with HTTP; Fri, 8 Jul 2016 06:03:36 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:713a:86d:a34a:1966] In-Reply-To: <20160708100934.GA14077@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160707221324.GA13128@LK-Perkele-V2.elisa-laajakaista.fi> <20160708100934.GA14077@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Fri, 8 Jul 2016 09:03:36 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1145ae064152ef05371f6e61 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:03:46 -0000 --001a1145ae064152ef05371f6e61 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara wrote: > > There is validity start time in there, the relative end time would > be relative to that. > > That is, instead of saying "this is valid from t1 to t2", saying "this > is valid from t to t+dt". > > No real perference either way, it was just an experiment to play with > time notations. > I think either would be fine, but once we start playing with the units (e.g., decaseconds), we're probably likely to increase errors. The nice thing about (t,dt) is that of the required checks: t <= now now <= t+dt dt <= 7 days the complex case (doing arithmetic on timestamps, for some value of "complex") has a straightforward backup control with no arithmetic and with comparison to a static value: dt <= 604800. With (t1,t2), the 7 day hard limit is the more complex check. That said, anyone hacking on security software probably shouldn't screw this up in either case. I'm even struggling to imagine a system library that could lead to unexpected errors here, given that the values are just epoch times. Kyle --001a1145ae064152ef05371f6e61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:

There is validity start time in there, the relative end time would be relative to that.

That is, instead of saying "this is valid from t1 to t2", saying = "this
is valid from t to t+dt".

No real perference either way, it was just an experiment to play with
time notations.

I think either would be= fine, but once we start playing with the units (e.g., decaseconds), we'= ;re probably likely to increase errors. The nice thing about (t,dt) is that= of the required checks:

t <=3D now
now = <=3D t+dt
dt <=3D 7 days

the complex = case (doing arithmetic on timestamps, for some value of "complex"= ) has a straightforward backup control with no arithmetic and with comparis= on to a static value: dt <=3D 604800. With (t1,t2), the 7 day hard limit= is the more complex check.

That said, anyone hacking on = security software probably shouldn't screw this up in either case. I= 9;m even struggling to imagine a system library that could lead to unexpect= ed errors here, given that the values are just epoch times.
<= br>
Kyle

--001a1145ae064152ef05371f6e61-- From nobody Fri Jul 8 06:26:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAD012D16B for ; Fri, 8 Jul 2016 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnV4EhQd6P92 for ; Fri, 8 Jul 2016 06:25:56 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE9312B048 for ; Fri, 8 Jul 2016 06:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8FE991194; Fri, 8 Jul 2016 16:25:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 6UVhzSwLjSuE; Fri, 8 Jul 2016 16:25:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 52760C4; Fri, 8 Jul 2016 16:25:52 +0300 (EEST) Date: Fri, 8 Jul 2016 16:25:49 +0300 From: Ilari Liusvaara To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160708132549.GA14245@LK-Perkele-V2.elisa-laajakaista.fi> References: <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.com> <1467971752.3009.22.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:25:58 -0000 On Fri, Jul 08, 2016 at 11:06:46AM +0000, Fossati, Thomas (Nokia - GB) wrote: > Hi Nikos, > > On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" wrote: > >On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote: > > > >As long as both the client and the server are able to notify each other > >that they only support L=1 I'd be content with it. > > In the straw man I proposed above, it is sufficient for the server to say > L=1. In that case the client will trigger a re-handshake when its Id > rollover policy says so. The client can't re-handshake. It probably would be able to obtain a new ID to replace the "burned" one. This way the client only needs enough IDs to obtain a new one before all IDs are exhausted. However, turns out this doesn't actually work as well as hoped in practice. The problem is that client can't really change address voluntarily (even if it is behind CGNAT, it probably can't change the outgoing address until CGNAT triggers involuntary rebinding, and client can't react to such rebindings fast enough. So it would be limited to cases where the client has non-NAT connection and is renumbered. And such pretty rarely happens. Given the above, I wonder if just having main and backup ID would be enough: When changing addresses, backup ID becomes main ID, and client asks server for a new ID that becomes the new backup ID. -Ilari From nobody Fri Jul 8 06:50:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB512D685 for ; Fri, 8 Jul 2016 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmk6wkJuLL7s for ; Fri, 8 Jul 2016 06:50:03 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5DE12D6A1 for ; Fri, 8 Jul 2016 06:49:58 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m2so22084810qtd.1 for ; Fri, 08 Jul 2016 06:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LiJXHGoD0WhpG6/6vcBPsU/tjbcFbXHMOJIv5v4WzRM=; b=U+pzXVMAoz6D+J1aaRo1sYqNgDBwWW97Y+k4t5QnY4rphFE6HkL1XEuuhDoB98aiYP PwXQ+5APrttiOKvNpXA2xHDp4oRiujRz64emJleXuI1AV9ieU2OLftv6tE2n3lR09W2A k8ILPqzjSYtEwFwDjajG/jPTveKG3ah4JXVKQ0rNWMOgZ+/jcASiGMfU2CxU7aZZsdl0 qFPvfiIxZ6z27ANHVB+PZD6pLVZenJHeDAMMzwYepa/US9IGL5dgHzhtyMfYWTNr9aN8 fQKBTxacYHdHntf5An5Kr1mXJELNdNcrgJH3RioK9kxQ7HR5v6fXnYVkdEjkqoUEAUip Lw8A== 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; bh=LiJXHGoD0WhpG6/6vcBPsU/tjbcFbXHMOJIv5v4WzRM=; b=ZeQGF70JLoTV1RXuQfDRv1/fkcsExdceEeLdczQkpushQbaG66fA+omRObcsM7Gt9M ujVNRdXyAJEEbIRGy00nMo2KMcgdaTURJIwego2qm4K2mD+ZGjpm4MyD8JVh/VzmSkFE /F4/OPWDvuwG1quG0EkenwQU6sf+wLxifEYgJZAVMo8rhK0wm2HzkMNrWfjtyE4lO9CD kcQPGWWOphfULNU+j2CaaCYUbbOre2fPvd7rYfIdrTNhPuZ2SFjAtX44r32poUHT4sjr jovFSbgTtaE1KQFCpy0wYHRIO1HXhChStgUA7GhtsPD2+5SeTawOaMqYgpt68XaybIbl ET1w== X-Gm-Message-State: ALyK8tJSW/xb0SldkXwXloKhGy3OnNAuKbe9UJ3Uu2C+DFctNh4Ri+Mrg93FkPbhUk0io19pYS6tPN40kSDAPQ== X-Received: by 10.200.51.34 with SMTP id t31mr1952615qta.61.1467985798007; Fri, 08 Jul 2016 06:49:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.181.134 with HTTP; Fri, 8 Jul 2016 06:49:38 -0700 (PDT) In-Reply-To: References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> From: Joseph Salowey Date: Fri, 8 Jul 2016 05:49:38 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a1135729e06a6240537201451 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:50:06 -0000 --001a1135729e06a6240537201451 Content-Type: text/plain; charset=UTF-8 We would like to have all comments in on this by Friday, July 7, 2016. Also, to clarify, Hugo's interpretation is correct: Option 1 - use the same key for protecting both *post*-handshake and applications messages. On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk wrote: > I do not have an objection to option 1 if re-phrased as > Option 1 - use the same key for protecting both *post*-handshake and > applications messages.. > > I believe this is what was intended by that option anyway. Let me clarify. > > I understand the question as relating *only* to post-handshake messages > and not > to the main handshake (three initial flights). For the latter we have key > separation in the sense that none of these main-handshake messages is > encrypted > under the application key but rather under dedicated handshake keys. This > should > not be changed as it provides key indistinguishability to the application > key, a > desirable design and analysis (=proof) modularity property. > > On the other hand, for post-handshake messages, and particularly for > encrypting > post-handshake client authentication messages, preserving key > indistinguishability is not relevant since at the time of post-handshake > client authentication, the application key has already lost its > indistinguishability > by the mere fact that the key was used to encrypt application data. Key > indistinguishability is the main reason to insist in key separation and > this > principle does not apply here anymore hence removing the objection to 1. > > I'd note that the best one could hope for in the post-handshake setting is > that > as a result of post-handshake client authentication the application key > becomes > a secure mutually-authenticated key for providing "secure channels" > security. > As pointed out by others in previous posts I have an analysis showing that > this > delayed mutual authentication guarantee is achieved even if one uses the > application key to encrypt the post-handshake messages. I have circulated a > preliminary version of the paper among cryptographers working on TLS 1.3 > and I will post a public copy next week so this can be scrutinized > further. > > Hugo > > > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > >> If we are left with 1 or 3, the miTLS team would prefer 1. >> >> On the cryptographic side, Hugo has a recent (draft) paper that seems to >> provide >> some more justification for (1), at least for client authentication. >> >> I know this is a bit off-topic, but the miTLS team would also like to get >> rid of 0-RTT ClientFinished >> if that is the only message left in the 0-RTT encrypted handshake flight. >> That should remove >> another Handshake/Data key separation from the protocol, leaving only 3 >> keys: 0-RTT data, >> 1-RTT handshake, and 1-RTT data. >> >> Best, >> -Karthik >> >> >> On 07 Jul 2016, at 02:49, David Benjamin wrote: >> >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: >> >>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett >>> wrote: >>> >>>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >>>> > I'm also curious which post-handshake messages are the problem. If we >>>> were >>>> > to rename "post-handshake handshake messages" to "post-handshake bonus >>>> > messages" with a distinct bonus_message record type, where would there >>>> > still be an issue? (Alerts and application data share keys and this >>>> seems >>>> > to have been fine.) >>>> >>>> Recasting all the post-handshake handshake messages as not something >>>> named "handshake" does make a degree of sense, on its own. (bikeshedding: >>>> I'd name it something more descriptive like "secondary negotiation" >>>> messages or something, though.) Even if this doesn't directly help with the >>>> issue at hand here, does forking these into a new ContentType sound like a >>>> useful move, in general? >>> >>> >>> I'm not sure what this would accomplish. >>> >> >> Me neither. To clarify, I mention this not as a suggestion, but to >> motivate asking about the type of message. If the only reason the proofs >> want them in the handshake bucket rather than the application data bucket >> is that they say "handshake" in them then, sure, let's do an >> inconsequential re-spelling and move on from this problem. >> >> But presumably something about the messages motivate this key separation >> issue and I'd like to know what they are. >> >> David >> _______________________________________________ >> 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 > > --001a1135729e06a6240537201451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We would like to have all comments in on this by Frid= ay, July 7, 2016.

Also, to clarify, Hugo's interpre= tation is correct:

Option= 1 - use the same key for protecting both *post*-handshake and applications= messages.

<= /div>



<= div class=3D"gmail_quote">On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
I do not have an objection to op= tion 1 if re-phrased as=C2=A0
Option 1 - use the same key for protecting bot= h *post*-handshake and applications messages..=C2=A0

I believe this is what was intended by that opti= on anyway.=C2=A0Let m= e clarify.

= I understand the question as relating *o= nly* to post-handshake messages and not
to the main handshake (three initi= al flights). For the latter we have key
separation in the sense that none = of these main-handshake messages is encrypted
under the application key bu= t rather under dedicated handshake keys. This should
not be changed= as it provides key indistinguishability to the application key, a
desirab= le design and analysis (=3Dproof) modularity property.

On the other = hand, for post-handshake messages, and particularly for encrypting
post-ha= ndshake client authentication messages, preserving key
indistinguishabilit= y is not relevant since at the time of post-handshake
client authenticatio= n, the application key has already lost its indistinguishability
by the me= re fact that the key was used to encrypt application data. Key
=
indistinguishability is the main reason to insist in key separation a= nd this
principle does not apply here anymore hence removing the ob= jection to 1.

I'd note that the best one could hope for in the p= ost-handshake setting is that
as a result of post-handsha= ke client authentication the application key becomes
a secure mutually-aut= henticated key for providing "secure channels" security.
As poin= ted out by others in previous posts I have an analysis showing that this
d= elayed mutual authentication guarantee is achieved even if one uses the
ap= plication key to encrypt the post-handshake messages. I have circulated a
preliminary version of the =C2=A0paper among cryptographers working = on TLS 1.3=C2=A0
= and =C2=A0I will post a public copy next week so this can be = scrutinized further.

Hugo


On Thu, Jul 7, 2= 016 at 1:10 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.c= om> wrote:
If we are left with 1 or 3, the miTLS team would prefer= 1.

On the cryptographic side, Hugo has a recent (draft)= paper that seems to provide
some more justification for (1), at = least for client authentication.=C2=A0

I know this is a = bit off-topic, but the miTLS team would also like to get rid of 0-RTT Clien= tFinished=C2=A0
if that is the only message left in the 0-RTT enc= rypted handshake flight. That should remove
another Handshake/Dat= a key separation from the protocol, leaving only 3 keys: 0-RTT data,
<= div>1-RTT handshake, and 1-RTT data.=C2=A0

Be= st,
-Karthik


On 07 Jul 2016, at 02:49, David Benjamin <davidben@chromium.= org> wrote:

On Wed, Jul 6, 2016 at 5:39 PM Eri= c Rescorla <ekr@rtfm.c= om> wrote:
=
On Wed, Jul 6, 2016 a= t 5:24 PM, Dave Garrett <davemgarrett@gmail.com> wrote:=
On Wednesday, July 06, 2016 06:19:= 29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If= we were
> to rename "post-handshake handshake messages" to "post-= handshake bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this se= ems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something= named "handshake" does make a degree of sense, on its own. (bike= shedding: I'd name it something more descriptive like "secondary n= egotiation" messages or something, though.) Even if this doesn't d= irectly help with the issue at hand here, does forking these into a new Con= tentType sound like a useful move, in general?

<= /div>
I'm not sure what this would accomplish.
<= /div>

Me neither. To clarify, I mention this = not as a suggestion, but to motivate asking about the type of message. If t= he only reason the proofs want them in the handshake bucket rather than the= application data bucket is that they say "handshake" in them the= n, sure, let's do an inconsequential re-spelling and move on from this = problem.

But presumably something about the messag= es motivate this key separation issue and I'd like to know what they ar= e.

David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.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


--001a1135729e06a6240537201451-- From nobody Fri Jul 8 06:52:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D1E12D736 for ; Fri, 8 Jul 2016 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0Av-nVwPQQ9 for ; Fri, 8 Jul 2016 06:51:58 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6B312D73B for ; Fri, 8 Jul 2016 06:51:42 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id ib6so6992826pad.3 for ; Fri, 08 Jul 2016 06:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DbxoEpmPEE+wHwRPwefhP7oK9hJA4ISL5cDm6znnLBM=; b=Q7qxLJRWBR4UHKoHMYsIHYCaCYK4NeD6eiyJqQ/ib4Q2Awf0g4aAoDY1czvJ60hZrv lzWDR1ajZK8my1Bf6VJ/mYhzL1LDhg+XkCEQWKk7sxkxAFx8D/l2ZVcEg/7Jfsp6eNDY 88967VQ7T0/FpQ+bP9pnbj5J+DSVG1jHmKETUvCPqWMTZZai6IIrD+pubkpRgeGCmC1z yO3Ce63VT+QS++ffCr/9iXhGleuf7bZYcl/FDBmqoZW75U5qHLLXMn2vDJVOE7FbExTo xAP9YE8X8et8qlT+Y0ZInvK/r32RVRomJvCEDKMz4/mSbr4JyqVtn034pO0qXVF2gMCC iWHw== 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-transfer-encoding; bh=DbxoEpmPEE+wHwRPwefhP7oK9hJA4ISL5cDm6znnLBM=; b=A51L7gGBtt4KunzmDOCREcdrsDcZLF+TAfr0Jjmn+C+jXHQZ8LTsBYbQdifytfvzeE TgMzy0J61f5sAN9o7iTL9+nzJMeQBo7dx23PFGMOY51UmB+woq6TPw4KEib2KiRG7OqA Q/E+UZiXJyXImV8CIcO9RoOKXlMqbWFRxjCPiitb5WCzk43YxjH0CrGG29uT2Nys7rz8 espy6vWyXX8kz6n//DC0mq+UN0ax5MM5u6ig8I0hQBlfhpCSMn5fN5gjNc0TZbzpXgzS BCN6SC6EcEzC9oKtY3gb0NkLSzozYDJkjeROJZaePfsEWZQ7natbY6BOepQfbgeNKgLb 6vYQ== X-Gm-Message-State: ALyK8tIf5gFaoCES0sMCUnqt16p8rSDdor3/DMd/bxorrvEDHeROEQjSUPZhwiOZINij4A== X-Received: by 10.66.189.104 with SMTP id gh8mr10090909pac.125.1467985901881; Fri, 08 Jul 2016 06:51:41 -0700 (PDT) Received: from [10.250.252.18] ([116.212.180.68]) by smtp.gmail.com with ESMTPSA id 4sm5315215pav.33.2016.07.08.06.51.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 06:51:40 -0700 (PDT) References: <20160708134225.32116.37754.idtracker@ietfa.amsl.com> To: "tls@ietf.org" From: Yaron Sheffer X-Forwarded-Message-Id: <20160708134225.32116.37754.idtracker@ietfa.amsl.com> Message-ID: <577FAFE9.7080904@gmail.com> Date: Fri, 8 Jul 2016 19:21:37 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160708134225.32116.37754.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:52:01 -0000 Hi everyone, This draft extends TLS 1.3 to provide pinning of the TLS server using a stateless ticket. This is similar to public-key pinning but not quite, and our goal was to overcome the deployment issues that prevent widespread deployment of HPKP. Version -02 of the draft incorporates learnings from my proof-of-concept implementation at https://github.com/yaronf/mint. Thanks to the authors on the Mint TLS 1.3 implementation from which my code was forked. Best, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-02.txt Date: Fri, 08 Jul 2016 06:42:25 -0700 From: internet-drafts@ietf.org To: Yaron Sheffer A new version of I-D, draft-sheffer-tls-pinning-ticket-02.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-tls-pinning-ticket Revision: 02 Title: TLS Server Identity Pinning with Tickets Document date: 2016-07-08 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-02.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ Htmlized: https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-02 Abstract: Fake public-key certificates are an ongoing problem for users of TLS. Several solutions have been proposed, but none is currently in wide use. This document proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin the server's identity. That is, to ensure the client that it is connecting to the right server even in the presence of corrupt certificate authorities and fake certificates. The main advantage of this solution is that no manual management actions are required. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 8 07:21:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5027112B00F for ; Fri, 8 Jul 2016 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOwGONJSmWIc for ; Fri, 8 Jul 2016 07:21:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AF7CE12D098 for ; Fri, 8 Jul 2016 07:21:34 -0700 (PDT) Received: from [192.168.10.131] ([80.92.118.242]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M8edX-1bXoQ309yd-00wBZ6 for ; Fri, 08 Jul 2016 16:21:32 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <577FB6EA.4070101@gmx.net> Date: Fri, 8 Jul 2016 16:21:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V5NWPdHEftSWTVP5V8J3xPOhIB5BLWuqF" X-Provags-ID: V03:K0:0nq/hjlnB5MfKFSWXkulAMygtPviXtqM1kUunVzjLxtnQQtCPve 5FKCW95eugrP1VEo0vQOqJH1K/jkcHbYm8/8v+2eQ9rsNBqyOvGlYOGlC/F1ov0yhCdU13y UVWVKd1ZGN3ZHgV7OGcqltIgD8zLf5aEmU9tv49v5Zn3OQkvB54Pt2g+b7EKFf31SqhuB5w 7ckRc0C4Rf+vAk+cAQasQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:nQiiTz7feyg=:cip8kfJDJgX9GPWuZhLnDh JkqKga7hPqebZH0UHJWHJkayh4Muf3uOdcwxaWmX3VWrfsiMu02BWGLExAf2Pta3tdu6knGeq lmp2HQXmIsU+do2uvYR2dVy4ptCLwPv91CoAQs9rVkyBUhUw//11qUanE8OwDxd48CNaqzoxE DqcOIYfflaS9ZHJYi0jtFBh9NN4/THK2vw7sBJ1bo7kHM2S4h+IFp1uxbFMhNWsitJPPSHQxp fEw+KaiHu11dLsme4pujKPI2sRCOT/1/Uu86mukjfVI9IBRHmDg9BmG6iLeo7/P7CkATk0H5K HWEJo/DCNJvKlQUqyuN7SVdQoJbmH2bMznk2lqu6qgTtMz6K/AlpDjd08fNmpzcsNEiUYTqEI bDNLcAeSnGgO9rQHMAFCtYKliYTAtJAI5ZLjFeVZvu6+jIMwR7yUVcbdnDlJp7FiFK4jstpXC lBtCZNQtseMqxXCG4M9svNR9m3r4V94gUJRApvpL30GcJ3nyEps6PfNKaeE38UZBcTXmJOTwr hEr4w4dJyZ1on5Gd3g6Ci9VNdzvocQZHy4FE60lUNWS3N3urFyjJ12FCgeBwleKaaIRXMFuY1 QVsbA4qGcLBfqpyc7OG6zIj8cuutiS1HSxFLaBlv/kf1rUQ/ywRHTt5+4PibEjpAaCSO8BYZu UHiqUGIxejCh1kSjTlbBoMEXnsysX1FPdo1jQwLfXRUqd3furO7jLa9nvA80My7coJ475Te04 l6HF/d3pnBc3l1T21xv8/fkoXq9D5qfzn0tVzEqTucpa0FBZLfpMoloB298= Archived-At: Subject: [TLS] DTLS 1.3 rekeying and the use of epoch values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:21:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V5NWPdHEftSWTVP5V8J3xPOhIB5BLWuqF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on the feedback from Ilari this week I have drafted initial text that talks about rekeying and the use of the epoch value. ---- 8.8. Epoch Values and Rekeying A recipient of a DTLS message needs to select the correct keying material in order to process an incoming message. With the possibility of message loss and re-order an identifier is needed to determine which cipher state has been used to protect the record payload. The epoch value fulfills this role in DTLS. In addition to the key derivation steps described in Section 9 triggered by the states during the handshake a sender may want to rekey at any time during the lifetime of the connection and has to have a way to indicate that it is updating its sending cryptographic keys. The following epoch values are reserved and correspond to phases in the handshake and allow identification of the correct cipher state: - epoch value (0) for use with unencrypted messages, namely ClientHello, ServerHello, and HelloRetryRequest. - epoch value (1) for the Finished message protected using the 0-RTT handshake key. - epoch value (2) for 0-RTT 'Application Data' protected using keys derived from the early_traffic_secret. - epoch value (3) for messages protected using keys derived from the handshake_traffic_secret, namely the EncryptedExtensions to the Finished message sent by the client). - epoch value (4) for application data payloads protected using keys derived from the initial traffic_secret_0. - epoch value (5 to 2^16-1) for application data payloads protected using keys from the traffic_secret_N (N>0). Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message. Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a fatal "unexpected_message" alert. For example, client incorrectly uses epoch value 5 when sending application data in a 0-RTT exchange with the first message. A server will not be able to compute the appropriate keys and will therefore have to respond with a fatal alert. Increasing the epoch value by a sender (starting with value 5 upwards) corresponds semantically to rekeying using the KeyUpdate message in TLS 1.3. Instead of utilizing an dedicated message in DTLS 1.3 the sender uses an increase in the epoch value to signal rekeying. Hence, a sender that decides to increment the epoch value (with value starting at 5) MUST send all its traffic using the next generation of keys, computed as described in Section 9.2. Upon receiving a payload with such a new epoch value, the receiver MUST update their receiving keys and if they have not already updated their sending state up to or past the then current receiving generation MUST send messages with the new epoch value prior to sending any other messages. For epoch values lower than 5 the key schedule described in Section 9.1 is applicable. Note that epoch values do not wrap. If a TLS implementation would need to wrap the epoch value, it MUST terminate the connection. ---- Ciao Hannes --V5NWPdHEftSWTVP5V8J3xPOhIB5BLWuqF 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 iQEcBAEBCgAGBQJXf7brAAoJEGhJURNOOiAtsS0H/3X4isx8ORq8E3nxLIx9RZPk PHMBIUjmUf7g/4e6pdKL8Md81PcNnAQDFePcPmNGpI44nCNsBMRWM6p15l0KM1KT zytZbKr3bYJWa+vOOIi4lIjQaaYlB0OtpBo13QdvGRXbZwDgEnjIfX90JAZCh1Pu WGUZC5qqlb1TdSNd4weOjujfrQHA+iuAwCMpsUzVm7NeExvuKjzDzWAsiAtkBxi3 qa+ATk4yLw5w9oGYZZi8lY761JBX1TIIjceu5DjNVm6zUqgkLGDSxZuScAGlpfu0 Xo7VUQtCy8tfIB9ehQjRUI1AyWEv0QdyRT43SCf38lAtUk+mNQYFj6tnT9Qehd8= =xivI -----END PGP SIGNATURE----- --V5NWPdHEftSWTVP5V8J3xPOhIB5BLWuqF-- From nobody Fri Jul 8 08:28:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB912D1DE for ; Fri, 8 Jul 2016 08:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFDqpcRzMGyp for ; Fri, 8 Jul 2016 08:28:32 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DCB12D776 for ; Fri, 8 Jul 2016 08:28:32 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id a5so9227483vkc.2 for ; Fri, 08 Jul 2016 08:28:32 -0700 (PDT) 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; bh=q6OyjEhmr2Y1x1xrmtiJu/hD9XvWh32owdidjqKD6bQ=; b=cuZLo5tJeIkC7itTNt8ARjUsFyfQ/A+dAZ3OB1+ztrjdGyb4WCq3D6dxTVnyjbb9YO 5qZGVMPiRLmkf8DN9UrsCO/1M8AsTrrM3v4hL9LpUtzzXnDm5Ixmm6/DZokdkyn5iWiy C1D4+/WQv184ihHiuvqSfkZBCganfC6Hj55hYbOwVFZiqIFbiwBSNsyCO7U/tbNI3+g3 qcA+DmnNxcvCEncXTqx1UEReSv+cbIMQt+TD+4wiPGxqQk16tr7pMHWXX8dz7cEgOfFA ytGi/RYSw/66tV6KqOyFzPFoCP5XI1QA7skYidY1SWlkhpmaj+H1AYu7wOTERM7BPfju clPA== 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; bh=q6OyjEhmr2Y1x1xrmtiJu/hD9XvWh32owdidjqKD6bQ=; b=IFldC+Z01gIWPxANuN//Gvr82+0n1D3BZNvQMhajxPsZPiUnqJfRuLguCpAWyONMjw G8dG+JX5EUGJcKIC1sJdsTCN0bnB39EGmBfZqkKW3C1rFSu2g5Hpx2UW36Yyb1wbSk/L g6cPxFSst18GCcp5OurBYbg2zIFtANhkXEEtY1Tn9gdyJvfZPUyRhRMM6C0zq6yuWRLy HnJWqI6Gb7UXo3Ux2kbD1qkpd2V8E0h225Mov/b1Gwhg81enmfwfSSpKicXmMyxIKOV5 KgtLNkCi5sx1arZ2BnO1ct/MeuFD16cZ/6CxeHggIELn/NilMI5caqhiKanCGdhUUxmJ iNoQ== X-Gm-Message-State: ALyK8tLwi3TLIJakgcmwiSE5LmFaPI7FdQSAMczb1nh6fXv9JHphSQ8s/1H176zgM9PVXGGN5KvzEu5XCzAgAg== MIME-Version: 1.0 X-Received: by 10.31.108.216 with SMTP id j85mr2896087vki.68.1467991711060; Fri, 08 Jul 2016 08:28:31 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Fri, 8 Jul 2016 08:28:30 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Fri, 8 Jul 2016 08:28:30 -0700 (PDT) In-Reply-To: References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> Date: Fri, 8 Jul 2016 08:28:30 -0700 Message-ID: From: Watson Ladd To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a11478f34789987053721745c Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:28:35 -0000 --001a11478f34789987053721745c Content-Type: text/plain; charset=UTF-8 On Jul 8, 2016 6:50 AM, "Joseph Salowey" wrote: > > We would like to have all comments in on this by Friday, July 7, 2016. > > Also, to clarify, Hugo's interpretation is correct: > > Option 1 - use the same key for protecting both *post*-handshake and applications messages. I don't object to this if 2 is of the table. The only reason this option is reasonable is that we've carefully attempted to ensure keys are separated. I'll submit a PR to add text warning of extensions that don't do this. (Some exist IIRC). > > > > > On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk wrote: >> >> I do not have an objection to option 1 if re-phrased as >> Option 1 - use the same key for protecting both *post*-handshake and applications messages.. >> >> I believe this is what was intended by that option anyway. Let me clarify. >> >> I understand the question as relating *only* to post-handshake messages and not >> to the main handshake (three initial flights). For the latter we have key >> separation in the sense that none of these main-handshake messages is encrypted >> under the application key but rather under dedicated handshake keys. This should >> not be changed as it provides key indistinguishability to the application key, a >> desirable design and analysis (=proof) modularity property. >> >> On the other hand, for post-handshake messages, and particularly for encrypting >> post-handshake client authentication messages, preserving key >> indistinguishability is not relevant since at the time of post-handshake >> client authentication, the application key has already lost its indistinguishability >> by the mere fact that the key was used to encrypt application data. Key >> indistinguishability is the main reason to insist in key separation and this >> principle does not apply here anymore hence removing the objection to 1. >> >> I'd note that the best one could hope for in the post-handshake setting is that >> as a result of post-handshake client authentication the application key becomes >> a secure mutually-authenticated key for providing "secure channels" security. >> As pointed out by others in previous posts I have an analysis showing that this >> delayed mutual authentication guarantee is achieved even if one uses the >> application key to encrypt the post-handshake messages. I have circulated a >> preliminary version of the paper among cryptographers working on TLS 1.3 >> and I will post a public copy next week so this can be scrutinized further. >> >> Hugo >> >> >> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: >>> >>> If we are left with 1 or 3, the miTLS team would prefer 1. >>> >>> On the cryptographic side, Hugo has a recent (draft) paper that seems to provide >>> some more justification for (1), at least for client authentication. >>> >>> I know this is a bit off-topic, but the miTLS team would also like to get rid of 0-RTT ClientFinished >>> if that is the only message left in the 0-RTT encrypted handshake flight. That should remove >>> another Handshake/Data key separation from the protocol, leaving only 3 keys: 0-RTT data, >>> 1-RTT handshake, and 1-RTT data. >>> >>> Best, >>> -Karthik >>> >>> >>>> On 07 Jul 2016, at 02:49, David Benjamin wrote: >>>> >>>> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: >>>>> >>>>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett wrote: >>>>>> >>>>>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >>>>>> > I'm also curious which post-handshake messages are the problem. If we were >>>>>> > to rename "post-handshake handshake messages" to "post-handshake bonus >>>>>> > messages" with a distinct bonus_message record type, where would there >>>>>> > still be an issue? (Alerts and application data share keys and this seems >>>>>> > to have been fine.) >>>>>> >>>>>> Recasting all the post-handshake handshake messages as not something named "handshake" does make a degree of sense, on its own. (bikeshedding: I'd name it something more descriptive like "secondary negotiation" messages or something, though.) Even if this doesn't directly help with the issue at hand here, does forking these into a new ContentType sound like a useful move, in general? >>>>> >>>>> >>>>> I'm not sure what this would accomplish. >>>> >>>> >>>> Me neither. To clarify, I mention this not as a suggestion, but to motivate asking about the type of message. If the only reason the proofs want them in the handshake bucket rather than the application data bucket is that they say "handshake" in them then, sure, let's do an inconsequential re-spelling and move on from this problem. >>>> >>>> But presumably something about the messages motivate this key separation issue and I'd like to know what they are. >>>> >>>> David >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11478f34789987053721745c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 8, 2016 6:50 AM, "Joseph Salowey" <joe@salowey.net> wrote:
>
> We would like to have all comments in on this by Friday, July 7, 2016.=
>
> Also, to clarify, Hugo's interpretation is correct:
>
> Option 1 - use the same key for protecting both *post*-handshake and a= pplications messages.

I don't object to this if 2 is of the table. The only re= ason this option is reasonable is that we've carefully attempted to ens= ure keys are separated. I'll submit a PR to add text warning of extensi= ons that don't do this. (Some exist IIRC).

>
>
>
>
> On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>>
>> I do not have an objection to option 1 if re-phrased as=C2=A0
>> Option 1 - use the same key for protecting both *post*-handshake a= nd applications messages..=C2=A0
>>
>> I believe this is what was intended by that option anyway.=C2=A0Le= t me clarify.
>>
>> I understand the question as relating *only* to post-handshake mes= sages and not
>> to the main handshake (three initial flights). For the latter we h= ave key
>> separation in the sense that none of these main-handshake messages= is encrypted
>> under the application key but rather under dedicated handshake key= s. This should
>> not be changed as it provides key indistinguishability to the appl= ication key, a
>> desirable design and analysis (=3Dproof) modularity property.
>>
>> On the other hand, for post-handshake messages, and particularly f= or encrypting
>> post-handshake client authentication messages, preserving key
>> indistinguishability is not relevant since at the time of post-han= dshake
>> client authentication, the application key has already lost its in= distinguishability
>> by the mere fact that the key was used to encrypt application data= . Key
>> indistinguishability is the main reason to insist in key separatio= n and this
>> principle does not apply here anymore hence removing the objection= to 1.
>>
>> I'd note that the best one could hope for in the post-handshak= e setting is that
>> as a result of post-handshake client authentication the applicatio= n key becomes
>> a secure mutually-authenticated key for providing "secure cha= nnels" security.
>> As pointed out by others in previous posts I have an analysis show= ing that this
>> delayed mutual authentication guarantee is achieved even if one us= es the
>> application key to encrypt the post-handshake messages. I have cir= culated a
>> preliminary version of the =C2=A0paper among cryptographers workin= g on TLS 1.3=C2=A0
>> and =C2=A0I will post a public copy next week so this can be scrut= inized further.
>>
>> Hugo
>>
>>
>> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>= wrote:
>>>
>>> If we are left with 1 or 3, the miTLS team would prefer 1.
>>>
>>> On the cryptographic side, Hugo has a recent (draft) paper tha= t seems to provide
>>> some more justification for (1), at least for client authentic= ation.=C2=A0
>>>
>>> I know this is a bit off-topic, but the miTLS team would also = like to get rid of 0-RTT ClientFinished=C2=A0
>>> if that is the only message left in the 0-RTT encrypted handsh= ake flight. That should remove
>>> another Handshake/Data key separation from the protocol, leavi= ng only 3 keys: 0-RTT data,
>>> 1-RTT handshake, and 1-RTT data.=C2=A0
>>>
>>> Best,
>>> -Karthik
>>>
>>>
>>>> On 07 Jul 2016, at 02:49, David Benjamin <davidben@chromium.org> wrote:
>>>>
>>>> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>
>>>>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com> wrote:<= br> >>>>>>
>>>>>> On Wednesday, July 06, 2016 06:19:29 pm David Benj= amin wrote:
>>>>>> > I'm also curious which post-handshake mes= sages are the problem. If we were
>>>>>> > to rename "post-handshake handshake mess= ages" to "post-handshake bonus
>>>>>> > messages" with a distinct bonus_message = record type, where would there
>>>>>> > still be an issue? (Alerts and application da= ta share keys and this seems
>>>>>> > to have been fine.)
>>>>>>
>>>>>> Recasting all the post-handshake handshake message= s as not something named "handshake" does make a degree of sense,= on its own. (bikeshedding: I'd name it something more descriptive like= "secondary negotiation" messages or something, though.) Even if = this doesn't directly help with the issue at hand here, does forking th= ese into a new ContentType sound like a useful move, in general?
>>>>>
>>>>>
>>>>> I'm not sure what this would accomplish.
>>>>
>>>>
>>>> Me neither. To clarify, I mention this not as a suggestion= , but to motivate asking about the type of message. If the only reason the = proofs want them in the handshake bucket rather than the application data b= ucket is that they say "handshake" in them then, sure, let's = do an inconsequential re-spelling and move on from this problem.
>>>>
>>>> But presumably something about the messages motivate this = key separation issue and I'd like to know what they are.
>>>>
>>>> David
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> http= s://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://= www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.= ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--001a11478f34789987053721745c-- From nobody Fri Jul 8 08:35:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B312D885 for ; Fri, 8 Jul 2016 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8YjVtaIXS_S for ; Fri, 8 Jul 2016 08:35:44 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1986E12D87F for ; Fri, 8 Jul 2016 08:35:36 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f6so6409682ith.0 for ; Fri, 08 Jul 2016 08:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J5WOZmKHN80MfmxxFAjNyTh5xcYn7riFvhAKYbdO8u8=; b=llvdlOvIBM5g9U791D8AqTOnv3X/NSAhQmD1nCTxLPOW8RDat5qvi1vR2HFvesLBRc Vr6w49np73HV3Ep6EXk3V2rENMn/qwe3drJEqwoggupsgllCCsSL/9MjkIxSFyJWe6Nf mv/CYErLOIQWYgBdszAARc3Q/H6LHtjmXk0fA= 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; bh=J5WOZmKHN80MfmxxFAjNyTh5xcYn7riFvhAKYbdO8u8=; b=U6g8tTJ9CBQXlO+Fje/vG+xVd/PAktsPCcHRoVQ2J3uX+cD0VX9AnIPcFfljm8C9pt Lgw9Zl2FwmbKU+InzNj6FvEOc+B+rloSnnK9yZkuAEsxG1WdfZflRva7hPAZw512CxE+ NBPVuRqtrBLc2TXE1PSgEQRVzNemh9ojLii2uSZIKvCd/bEnfnZBSzNLCthNSGU5YDt7 7rQ6Ot4YaXiTa4Ar5qXN7wDtI+WqWJM045cUwR8KrhRkkKmlWfeNKgr47Ii1f8b0cowm mD+iFKCx17tSX0tnG8uIc8ECNw/6cugl9GUZVabOqikQovd16BmUbKusD/dGnS4yoz7L h8hQ== X-Gm-Message-State: ALyK8tKgZ5rcCT+khmWgim5ngnG4T/XuqtRDZzEZF9KhCMoHlriiDYxLyBSAGXaFe3qRZhQ4+Yr+qutRFOcy2V+2 X-Received: by 10.36.61.201 with SMTP id n192mr4079334itn.92.1467992135257; Fri, 08 Jul 2016 08:35:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 08 Jul 2016 15:35:24 +0000 Message-ID: To: Watson Ladd , Eric Rescorla Content-Type: multipart/alternative; boundary=001a11444e94c1a4070537218dad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:35:48 -0000 --001a11444e94c1a4070537218dad Content-Type: text/plain; charset=UTF-8 On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote: > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it hands the certificate to a system provided validator. (I > believe there was a longstanding Chrome on Windows XP bug for a > similar reason). > What are you referring to? I think one would know well enough whether our validators support a given feature. If there's weird cases, one can always decline to advertise if unsure. If you're thinking ECDSA and Chrome/XP, I believe it only got reflected in the cipher list and not sigalgs, but that's just because we never routed that bit through, not because we didn't know if we could do ECDSA. (And by now it's irrelevant since Chrome/XP is no longer supported.) David > Sincerely, > Watson > > > > > In the next rev, we'll update the draft to make these points more > clearly. > > > > -Ekr > > > > > > > > > > _______________________________________________ > > 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 > --001a11444e94c1a4070537218dad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 7,= 2016 at 7:29 PM Watson Ladd <w= atsonbladd@gmail.com> wrote:
I don't think we can use name constraints here. Yes, they are opt-in and clients can indicate support, but it may well be that a TLS
implementation doesn't know if its X509 validation code will support them as it hands the certificate to a system provided validator. (I
believe there was a longstanding Chrome on Windows XP bug for a
similar reason).

What are you referring to? I think one would know well enoug= h whether our validators support a given feature. If there's weird case= s, one can always decline to advertise if unsure.

If you're thinking ECDSA and Chrome/XP, I believe it o= nly got reflected in the cipher list and not sigalgs, but that's just b= ecause we never routed that bit through, not because we didn't know if = we could do ECDSA. (And by now it's irrelevant since Chrome/XP is no lo= nger supported.)

David
=C2=A0
Sincerely,
Watson

>
> In the next rev, we'll update the draft to make these points more = clearly.
>
> -Ekr
>
>
>
>
> _______________________________________________
> 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
--001a11444e94c1a4070537218dad-- From nobody Fri Jul 8 09:25:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBA512D605 for ; Fri, 8 Jul 2016 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDQA2_qEyOFs for ; Fri, 8 Jul 2016 09:25:17 -0700 (PDT) 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 37B9A12D59D for ; Fri, 8 Jul 2016 09:25:14 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2DAE68821709A; Fri, 8 Jul 2016 16:25:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u68GPBvt028277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 16:25:11 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u68GP9pE003428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jul 2016 18:25:10 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 18:25:10 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Ilari Liusvaara , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [TLS] DTLS 1.3 Thread-Index: AQHR1sQr+VI2HyMN6kSrh/Fh10M/0KAJwrEAgAK9LICAABd0AIAAJdUAgAABJwCAAWqLgP//8e2AgAAU6gD///EdgIAAF2WA///2kgAABJIYAAACww+AAAhbEAA= Date: Fri, 8 Jul 2016 16:25:09 +0000 Message-ID: References: <577E22DE.2060805@cs.tcd.ie> <1467892378.3426.41.camel@redhat.com> <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.com> <1467971752.3009.22.camel@redhat.com> <20160708132549.GA14245@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160708132549.GA14245@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <76516F22D8EABA4C9814374AD97044C3@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:25:19 -0000 Hi Ilari, On 08/07/2016 14:25, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" wrote: >However, turns out this doesn't actually work as well as hoped in >practice. The problem is that client can't really change address >voluntarily >(even if it is behind CGNAT, it probably can't change the outgoing address >until CGNAT triggers involuntary rebinding, and client can't react to >such rebindings fast enough. You are right. If client doesn't know that a re-bind has happened and therefore sends data using the same Id, it's trackable. In this case I think the trade-off you are doing is letting the session survive even you are potentially trackable. This is probably Nikos' use case. >So it would be limited to cases where the client has non-NAT connection >and is renumbered. And such pretty rarely happens. My use case is an IoT device that voluntarily (or better, knowingly) migrates its attachment from IP to GSM-SMS and vice-versa and wants to keep the (painfully) negotiated session open. Here the client is in complete control of the situation and can do the Id rollover at the right point in time. From nobody Fri Jul 8 10:46:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36312D124 for ; Fri, 8 Jul 2016 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds1f0xiyGM0R for ; Fri, 8 Jul 2016 10:46:11 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3195D12D5B9 for ; Fri, 8 Jul 2016 10:46:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 9AE43422F; Fri, 8 Jul 2016 20:46:08 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id MTyvXND6n5Bv; Fri, 8 Jul 2016 20:46:08 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4FCDBC4; Fri, 8 Jul 2016 20:46:08 +0300 (EEST) Date: Fri, 8 Jul 2016 20:46:05 +0300 From: Ilari Liusvaara To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20160708174605.GA14566@LK-Perkele-V2.elisa-laajakaista.fi> References: <577E4392.6060408@cs.tcd.ie> <1467967459.3009.7.camel@redhat.com> <1467968753.3009.11.camel@redhat.com> <1467971752.3009.22.camel@redhat.com> <20160708132549.GA14245@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls Subject: Re: [TLS] DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:46:13 -0000 On Fri, Jul 08, 2016 at 04:25:09PM +0000, Fossati, Thomas (Nokia - GB) wrote: > Hi Ilari, > My use case is an IoT device that voluntarily (or better, knowingly) > migrates its attachment from IP to GSM-SMS and vice-versa and wants to > keep the (painfully) negotiated session open. Here the client is in > complete control of the situation and can do the Id rollover at the right > point in time. Hmm.. GSM-SMS... Would 1 backup ID be enough for that (given that it then would have to get another backup ID using SMS (which I presume is pletty unpleasant) for renumbering back into IP)? Or would one preferably have 2? -Ilari From nobody Fri Jul 8 11:58:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15DA12D620 for ; Fri, 8 Jul 2016 11:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nasSmLWFVwz9 for ; Fri, 8 Jul 2016 11:58:14 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 5B49312D0AF for ; Fri, 8 Jul 2016 11:58:14 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so16279531ita.0 for ; Fri, 08 Jul 2016 11:58:14 -0700 (PDT) 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; bh=eKzIfiWg+yPwrshneUlRDGotntXnGFfSDv9HvCpVFGM=; b=IgB9ECrUG2/vRmTZVABNXr+80egix5OAPP+ONCjegPUXAnoty7ulU2PqmE+6DNBKiz Q2a3a9nCf0AbI31boC/jbIAmXjlgyFBxdZ8zP12tuAtXUjlegppUD8eSX0BlaFkbNQ4R dWBggz01O7K/V3wiiJ/7tq/siXO98QKy85VyIrbDQJ1Qjm5XOM08vjwP2aALXWGRrtpd eP8Gqak9Jp5AjZEsWfUZUBlElBjOeaCT7U9P4YtVze7w0n6LA6CPIZPDP4XeYlr9qLzD r/ikkZdt/9R88WdKD+frEIM2iEVaIjrB5wjOFhMRG5179JRGOtpG3Qu8WmMBqiEQThZk 4DxQ== 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; bh=eKzIfiWg+yPwrshneUlRDGotntXnGFfSDv9HvCpVFGM=; b=Bf1gjfVMg33r7d0cXeJNBD6BqDqJPskEcIoK/sVvJjimcK4ZZTkiolAeyLVQaC8p+4 DOb+VWiWuZZujHlao9QPI0EolhCe6OLhcvGZIz1ZPsk2N1PhxCRQDmmLa7sKPiLigdhx RRo2qiU+ZAk1yTMMwgKLWBIIVPfC7pZsnUUvBhgurECGsvjp879N4VDIRTO6CWUa52ZK JnyD9IDpTkZ9YH3iy7yu1Z+EyZAR/K2swoqaY0wnDGUBloN3/XP9EkbtYGq8JCAt6HIL h4iK37HuJt6hthLtlHZCvTSIB6ydpwpZTIGnNBER/5/Pn4bzk9c0FMLD1Zzv5gMNRiwr wMQA== X-Gm-Message-State: ALyK8tJIsEgMd5Ufu69gfmIk9inQHLIYzINYXgBL2Pu4N701v7U27wYARLqAaWms1KbB3AD+e82GPyztRvFqbw== X-Received: by 10.36.137.215 with SMTP id s206mr4974232itd.82.1468004293666; Fri, 08 Jul 2016 11:58:13 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.128.65 with HTTP; Fri, 8 Jul 2016 11:58:12 -0700 (PDT) In-Reply-To: References: <577D655A.40802@gmx.net> From: Erik Nygren Date: Fri, 8 Jul 2016 14:58:12 -0400 X-Google-Sender-Auth: --gy7yqhgK72t3ICsvaSF5rolJQ Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c05e6ec73ed3c05372462ba Archived-At: Cc: Dmitry Khovratovich , "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:58:17 -0000 --94eb2c05e6ec73ed3c05372462ba Content-Type: text/plain; charset=UTF-8 This is also what is still proposed in the -01 version at the top of this thread: https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-01 By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles as an extension mechanism to TLS without requiring changes to the state machine or protocol itself. (Clients indicate support via an extension, and then puzzles are challenged with a HelloRetryRequest extension, and then the ClientHello retry contains the updated extension.) Note that the -01 version still needs some updates to match up to more recent TLS 1.3 drafts. (Some of the specifics may be a little out-of-date and will be updated in the next revision.) Erik On Thu, Jul 7, 2016 at 5:36 PM, Kyle Rose wrote: > > I agree, and I think it is clear that client puzzles can be a useful >> addition to the DDoS defense toolbox. However, most of this can be handled >> at the higher levels above TLS, or possibly as a custom extension that does >> not complicate TLS. >> > > A custom extension is a promising approach: this is what Erik Nygren > proposed in nygren-tls-client-puzzles-00 following discussions with some > IETF folks and Akamai colleagues. That draft has expired and doesn't > reference any of the recent work on memory-hard puzzles, but it might be a > good starting point. > > Except at the pre-TLS stage for applications that use STARTTLS-style > mechanisms, I'm not sure how this could work at levels above TLS: the > primary attack targeted by client puzzles would be a client doing almost no > work in order to force the server to do expensive crypto, which means it > must be engaged prior to the handshake. > > Kyle > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c05e6ec73ed3c05372462ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is also what is still proposed in the -01 v= ersion at the top of this thread:

=C2=A0=C2=A0=C2=A0 https://tools.i= etf.org/html/draft-nygren-tls-client-puzzles-01

By leverag= ing the HelloRetryRequest in TLS 1.3, it provides client puzzles
<= div>as an extension mechanism to TLS without requiring changes to the state= machine
or protocol itself.=C2=A0 (Clients indicate support = via an extension, and then puzzles
are challenged with a Hell= oRetryRequest extension, and then the ClientHello retry
conta= ins the updated extension.)

Note that the -01 version sti= ll needs some updates to match up to more
recent TLS 1.3 draf= ts.=C2=A0 (Some of the specifics may be a little out-of-date
= and will be updated in the next revision.)

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik



On Thu, Jul 7, 2016 at 5:= 36 PM, Kyle Rose <krose@krose.org> wrote:

I agree, and I think it is clear that client puzzles can be a useful= addition to the DDoS defense toolbox.=C2=A0 However, most of this can be h= andled at the higher levels above TLS, or possibly as a custom extension th= at does not complicate TLS.

A custom extension is a promising approach: this is what Er= ik Nygren proposed in nygren-tls-client-puzzles-00 following discussions wi= th some IETF folks and Akamai colleagues. That draft has expired and doesn&= #39;t reference any of the recent work on memory-hard puzzles, but it might= be a good starting point.

Except at the pre-TLS stage for applicati= ons that use STARTTLS-style mechanisms, I'm not sure how this could wor= k at levels above TLS: the primary attack targeted by client puzzles would = be a client doing almost no work in order to force the server to do expensi= ve crypto, which means it must be engaged prior to the handshake.
=C2=A0
Kyle


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


--94eb2c05e6ec73ed3c05372462ba-- From nobody Fri Jul 8 13:40:20 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 2C82312D924; Fri, 8 Jul 2016 13:40:15 -0700 (PDT) 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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708204015.32059.34895.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 13:40:15 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:40:15 -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 of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Authors : Yoav Nir Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-rfc4492bis-08.txt Pages : 32 Date : 2016-07-08 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Digital Signature Algorithm (EdDSA) as new authentication mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 14:18:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668412D595 for ; Fri, 8 Jul 2016 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh5EBaQxNtmp for ; Fri, 8 Jul 2016 14:18:46 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80ADF12D51D for ; Fri, 8 Jul 2016 14:18:45 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id k35so2279754qtc.3 for ; Fri, 08 Jul 2016 14:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0AcGL9K/XROGWBW6cBi2YRe05wMYr1HjIPCEn4Pe3r8=; b=X/uVg4uCwnB5aztB5aUnUikEriMiHTngOj51xvQhsNHD+9ICKfhTket4Maaia3yabY arIZqDXqPtkVwASD8/kmfmp658OUNfmcxkKkAlsmHiKIRfXE2dPaC4bWwH6Icugu2kot tCOP/DWjVaP7q+XZu0PuSpsF9ihyFrEfPVaZVsVWXasclzw4qXiOO2UQSt0fS8LYfsER fxXeNy57ndgU9tyxOfdv8hOEcujKpyRQGzE51pAWPYT5EUt/suQrgn5pcsm5hcWXriC7 0iIxLv5mDWM0OHd2an1c9Jzwj/rTn+JZqCTM7d5vneSDr+1YTdR2owmAj7+OfWYPrsla Vg2Q== 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; bh=0AcGL9K/XROGWBW6cBi2YRe05wMYr1HjIPCEn4Pe3r8=; b=AiVwNkauLPa0BAKs0M8XbBfIbEz9bKTql86snrp2c4halPWr0DIvJC0U14pigI6orE 598H3mM8FRUt0atUMwEkej4pQfw3qLd8uF7J1x+V3MCp0i3KkSbxUxFTggzc/y9fGF/T CF+31eng/OT+rOOvUpcK2A9GpunU1qL8y0eCHaPa8oXTPapUKVrOiLylt8KReaLynMvK EQGFYiS7TajPdF34MChZPmHIXsUIh+GkQbM5KVSv+ZQkAtS7ovgWtCqY4RgQzfWfMpAE ACbVImfvU5RDjnOx0335djRQesgUWb+3dGHVTeAij6sw2zsJKTykisOOwfJQZLYcFSmI +Xcw== X-Gm-Message-State: ALyK8tI6Q9h1ZswyoSX9CRGf1f+fDjUkBEAi9US7J8hWwoVEKOqvJY4Fn3vQwfgF2u5EaTTQ0Jfkp9tar+EAdw== X-Received: by 10.200.51.34 with SMTP id t31mr5043240qta.61.1468012724559; Fri, 08 Jul 2016 14:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.181.134 with HTTP; Fri, 8 Jul 2016 14:18:25 -0700 (PDT) From: Joseph Salowey Date: Fri, 8 Jul 2016 14:18:25 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1135729ef936040537265827 Archived-At: Subject: [TLS] Agenda for TLS at IETF 96 Posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:18:48 -0000 --001a1135729ef936040537265827 Content-Type: text/plain; charset=UTF-8 I just posted an agenda for the Berlin meeting ( https://www.ietf.org/proceedings/96/agenda/agenda-96-tls) Our main focus for the meeting will be TLS 1.3, but I am hopeful that we will have time for some other topics. The specific details of the 1.3 topics will likely change as we get closer to the meeting. Cheers, Joe --001a1135729ef936040537265827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just posted an agenda for the Berlin meeting (https://www.ietf= .org/proceedings/96/agenda/agenda-96-tls)=C2=A0

Our = main focus for the meeting will be TLS 1.3, but I am hopeful that we will h= ave time for some other topics.=C2=A0 The specific details of the 1.3 topic= s will likely change as we get closer to the meeting. =C2=A0

=
Cheers,

Joe
--001a1135729ef936040537265827-- From nobody Sat Jul 9 05:49:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2912D107 for ; Sat, 9 Jul 2016 05:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZvJWAq7N1xN for ; Sat, 9 Jul 2016 05:49:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 EB09C12D0DE for ; Sat, 9 Jul 2016 05:49:53 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l125so57824104ywb.2 for ; Sat, 09 Jul 2016 05:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ixvZ0S3rly5Zpeq+LAjvCz/U4KEszBcwPzwSezMj6KU=; b=INh8R7kloGWegijer9u2FN3bqOdiaFkaUZLtnL+KspWut5louXlIW1rafaKylk6xFD tzyO+DI1mmDR7BcEdHsuAp3+Y0M35OHL7VobHd4Iz6ol53E66ezwPyev5OmV9ZKrhBeX /AB97FM6Unu4cWd+bKbLwNF0MDlmkUKdQo65OSgsmqZKmRGdafsWOfITckWu/xPYndYO x64uD7iO0kgB71PO4Kj9HvEKb6p4C/JnOPY0ImNqZG0qPxpLIdMAXyNbky/KR0ITzQBV 6ldhUiceEKkyXKfeV7sipMLaYeOA23OSpiOcuOivQpHlsqHIuD/ay+Zwekq2UCoDGz/+ cZfA== 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; bh=ixvZ0S3rly5Zpeq+LAjvCz/U4KEszBcwPzwSezMj6KU=; b=VQ1gy9AMc25hDF5VMYKz1ojocWbilWLvIs2YwOXRxjmcmGJcA4EiHCnX06t2yDTQHX 9pC3XB/b2KhDEoz0qGjXjNlBrRIJlOHzkW0PRtqheAl3oVHBj+p0SRycdD69j59T74QL wSxRFFjqAdPK6Q+Q3EiwoO0k/XCK31sQGsW+IUaR15rsql86Oa2DDFMU1Q47aeij7Oan EkQU6I+GZTOo+IHM7ThlDexi+EkI1UNWn13CUY9fSTNcVwc05n5PCp1Gd/DqmMbmK7X6 /3TDdoIyIddM5IMGIzhOmybicdJhRCia3WW/sJZWhC3NhMwKbTLwczw1KMRV2gZ0ol+C fkMQ== X-Gm-Message-State: ALyK8tJ5hjelsi2gaspOkC51hO9LOQAKMn0hSBdbPU04h3CcikCpchPdz4I5rQ3wMbSzj3Iam5S8a5KtLNcddw== X-Received: by 10.37.126.1 with SMTP id z1mr7430542ybc.57.1468068592953; Sat, 09 Jul 2016 05:49:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Sat, 9 Jul 2016 05:49:13 -0700 (PDT) From: Eric Rescorla Date: Sat, 9 Jul 2016 05:49:13 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e1a46fd7ae90537335a13 Archived-At: Subject: [TLS] Issue 472: Remove non-closure warning alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:49:55 -0000 --001a114e1a46fd7ae90537335a13 Content-Type: text/plain; charset=UTF-8 In general, TLS stacks handle warning alerts badly aside from the defined alerts that are explicitly non-fatal ("close_notify", etc.). Many just close the connection so it's not safe to send one. I would suggest that we instead adopt the following semantic: - All alerts mean connection close. - Fatal means that you should report an error to the application (e.g., return -1 in a sockets-style API) and abort immediately. - Warning means that you should report a "normal" end of data (e.g., return 0 in a sockets-style API) except in the case of end_of_early_data and in the case of close_notify, send your own close_notify - Any alerts except the ones specifically listed as "warning" MUST be treated as fatal regardless. This is more or less what people do anyway. If people are in favor of this, I will prepare a PR. -Ekr --001a114e1a46fd7ae90537335a13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general, TLS stacks handle warning alerts badly aside f= rom the defined alerts
that are explicitly non-fatal ("close_notif= y", etc.). Many just close the connection
so it's not sa= fe to send one.

I would suggest that we instead ad= opt the following semantic:

- All alerts mean conn= ection close.
- Fatal means that you should report an error to th= e application
=C2=A0 (e.g., return -1 in a sockets-style API) and= abort immediately.
- Warning means that you should report a &quo= t;normal" end of data
=C2=A0 (e.g., return 0 in a socket= s-style API) except in the case of end_of_early_data
=C2=A0 and i= n the case of close_notify, send your own close_notify
- Any aler= ts except the ones specifically listed as "warning" MUST be treat= ed
=C2=A0 as fatal regardless.

This is m= ore or less what people do anyway.

If people are i= n favor of this, I will prepare a PR.

-Ekr



=C2=A0=C2=A0
=C2= =A0=C2=A0

--001a114e1a46fd7ae90537335a13-- From nobody Sat Jul 9 07:37:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4C112D1A4 for ; Sat, 9 Jul 2016 07:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Kth3ZWDNyX for ; Sat, 9 Jul 2016 07:37:22 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7942612D16B for ; Sat, 9 Jul 2016 07:37:22 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7A6BD423788; Sat, 9 Jul 2016 14:37: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 5F577423771; Sat, 9 Jul 2016 14:37:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468075041; bh=AoNi449Bd5OF7a2ehel/1L0DqzEMB5ZWuM9JsBDbfYc=; l=112; h=From:To:Date:References:In-Reply-To:From; b=FQk6KNXIlfL9HBhcsgUX/syZCwSuzvrNlh6iUtHNojUQaXk69PbJRHCKD71hKKvjE Gs+L43A3Iv8IkhUCh3tV70Rjlqz7/FEX1W6Lqv9+LXklsEnqF3oZy5IqeOjPn1G5e2 YwR33ylmicPmSTH7pKfu4X2ieMUcml9JmvSmdtN8= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5A12C1FC88; Sat, 9 Jul 2016 14:37:21 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 9 Jul 2016 10:37:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 9 Jul 2016 10:37:20 -0400 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Issue 472: Remove non-closure warning alerts Thread-Index: AQHR2eBnoae5M8TG30+h4jPXAwQyyaAQKvmQ Date: Sat, 9 Jul 2016 14:37:20 +0000 Message-ID: <2abfa3b92ff34c7784a59060c8a3c3f8@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.40.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:37:24 -0000 PiBJZiBwZW9wbGUgYXJlIGluIGZhdm9yIG9mIHRoaXMsIEkgd2lsbCBwcmVwYXJlIGEgUFIuDQoN CisxDQoNCg0KwqDCoA0KwqDCoA0KDQo= From nobody Sat Jul 9 09:05:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007512D56C for ; Sat, 9 Jul 2016 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mhLIT2CpAq5 for ; Sat, 9 Jul 2016 09:05:48 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70FA812D1A1 for ; Sat, 9 Jul 2016 09:05:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id BCB79899; Sat, 9 Jul 2016 19:05:46 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id CxM3_IUfYycg; Sat, 9 Jul 2016 19:05:46 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8CD642315; Sat, 9 Jul 2016 19:05:46 +0300 (EEST) Date: Sat, 9 Jul 2016 19:05:43 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Message-ID: <20160709160543.GA21163@LK-Perkele-V2.elisa-laajakaista.fi> References: <577FB6EA.4070101@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <577FB6EA.4070101@gmx.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] DTLS 1.3 rekeying and the use of epoch values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:05:51 -0000 On Fri, Jul 08, 2016 at 04:21:30PM +0200, Hannes Tschofenig wrote: > Hi all, > > based on the feedback from Ilari this week I have drafted initial text > that talks about rekeying and the use of the epoch value. One maybe workable scheme that occurs to me is: Outside special epoches reserved for TLS handshaking itself (the first 4?), Both sides send using the highest epoch they have seen successful deprotection for or one bigger (both sides start at 4 at end of handshake). That would severly limit the frequency of rekeyings in fully asynchronous usage tho (but fully asynchronous usage of UDP or anything similar is probably a Bad Idea). Also, the epoch use window would be sufficiently small to allow epoch number on wire to wrap around (obviously the actual epoch number would not wrap. That is, peer that has seen epoch 65535 (0xFFFF) from peer can send at epoch 65536 (0x0000), which then can be bumped to 65537 (0x0001). -Ilari From nobody Sat Jul 9 11:49:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A562B12D147 for ; Sat, 9 Jul 2016 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDwAz7bGsehj for ; Sat, 9 Jul 2016 11:49:52 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA1812B039 for ; Sat, 9 Jul 2016 11:49:52 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id s93so27185441ioi.3 for ; Sat, 09 Jul 2016 11:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E+iF2ORYaXpQ433UycR63+KvrVi13/GFiTgyCgN1QMo=; b=VLqrV5Hc7TpnVtx8CNoVxg70zuNZF/pgo0mrn6fBSVxrHdRvUPfwVm453UmxzUbtVj DxKyWDUZjZQgTRg7SNFue+iW7mAWkpFYFtTK0xn8/lCL+ZDUN41UTH7jDeLsty7NRT/3 87DmbQziYTG93Pvk101w0REiNuJSb3FptyycY= 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; bh=E+iF2ORYaXpQ433UycR63+KvrVi13/GFiTgyCgN1QMo=; b=lawZVAUEJX6AWqXX4NsCzAqh0wViQ9Zgkde92l0YKijs5psW1sACx5MjKL6+QuRzJf He+ClDuSTW4tIrEYGTCMdI8p6d1fJV2SjX0kmauj6yZQVrAPvfUWqfhQamRCgvEI9UlO ZVBdvxhdi446yEbs/ZirvZ5bPLOD5tZzPHUxlyEiZ8ooDxEK8v8x+GVN9d8/GW+BfEu1 ubvzrfHi5yCDuGCP82ruP/WYjDkeMQMPTjXo/mmbSf0nmz+VfE+b+gKrGOGoJvk497Bf zjvJiytU5lVEB/onQqhIjGzbiWNiHtcKdD1TLodzrGYdYeNB5WjOTDLKz8TG/L8VG09E DI+g== X-Gm-Message-State: ALyK8tLcM949HodAsX09DH05btLt0ISJwlXlL9pybA2nXpLZHlIGDSpeud+chsTPWteu1LLZMsCZvPdYGZn0tnNf X-Received: by 10.107.13.82 with SMTP id 79mr15381472ion.97.1468090191922; Sat, 09 Jul 2016 11:49:51 -0700 (PDT) MIME-Version: 1.0 References: <2abfa3b92ff34c7784a59060c8a3c3f8@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <2abfa3b92ff34c7784a59060c8a3c3f8@usma1ex-dag1mb1.msg.corp.akamai.com> From: David Benjamin Date: Sat, 09 Jul 2016 18:49:41 +0000 Message-ID: To: "Salz, Rich" , Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fdb5e63a1a0053738629f Archived-At: Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:49:54 -0000 --001a113fdb5e63a1a0053738629f Content-Type: text/plain; charset=UTF-8 On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich wrote: > > If people are in favor of this, I will prepare a PR. > > +1 > +1 David --001a113fdb5e63a1a0053738629f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 9,= 2016 at 7:37 AM Salz, Rich <rsalz@akamai.com> wrote:
> If people are in favor of this, I will prepare a PR.

+1

+1

David=C2=A0
--001a113fdb5e63a1a0053738629f-- From nobody Sat Jul 9 13:03:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5D412B05A for ; Sat, 9 Jul 2016 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zRo1TLwJ_RB for ; Sat, 9 Jul 2016 13:03:10 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C9512D0D3 for ; Sat, 9 Jul 2016 13:03:10 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u69JwZRX018830; Sat, 9 Jul 2016 13:03:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=ITDaCzbvNZ+4SEwNhp0FxDFO+VnyQq4bkE3NUtkUuWM=; b=n+KtDFlBx4QdTSMBbWH4tScG/0f6KBaTFABMX+ahE1DghYmIm4V+daEUvaGTQbiCu0HO Ny4zBFI2qfLBWyituLjWf4jtWCL8f17GrYKNPs7SPS9UvAU8LzDiNSIdChUqM8HPCWEB M4wWUEV9ZZjFiqLjnqs6ORIO0hQV4gP43cQ= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 242vxathtv-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 09 Jul 2016 13:03:07 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.129]) by PRN-CHUB11.TheFacebook.com ([fe80::80d:37ff:4b6a:a4fc%12]) with mapi id 14.03.0294.000; Sat, 9 Jul 2016 13:03:05 -0700 From: Subodh Iyengar To: David Benjamin , "Salz, Rich" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Issue 472: Remove non-closure warning alerts Thread-Index: AQHR2eBpGmdkD44mmEWZGIKJTVqB86AQoGMAgABGgoD//58QbQ== Date: Sat, 9 Jul 2016 20:03:05 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E9956564C30@PRN-MBX01-4.TheFacebook.com> References: <2abfa3b92ff34c7784a59060c8a3c3f8@usma1ex-dag1mb1.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E9956564C30PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-09_11:, , signatures=0 Archived-At: Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:03:11 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E9956564C30PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Subodh ________________________________ From: TLS [tls-bounces@ietf.org] on behalf of David Benjamin [davidben@chro= mium.org] Sent: Saturday, July 09, 2016 11:49 AM To: Salz, Rich; Eric Rescorla; tls@ietf.org Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich > wrote: > If people are in favor of this, I will prepare a PR. +1 +1 David --_000_974CF78E8475CD4CA398B1FCA21C8E9956564C30PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1 

Subodh
From: TLS [tls-bounces@ietf.org] on behal= f of David Benjamin [davidben@chromium.org]
Sent: Saturday, July 09, 2016 11:49 AM
To: Salz, Rich; Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts

On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich <rsalz@akamai.com> wrote:
> If people are in favor of this, I will prepare a PR.

+1

+1

David 
--_000_974CF78E8475CD4CA398B1FCA21C8E9956564C30PRNMBX014TheFac_-- From nobody Sun Jul 10 00:37:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764312B017 for ; Sun, 10 Jul 2016 00:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2gsEJtLoS7q for ; Sun, 10 Jul 2016 00:37:20 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E34128874 for ; Sun, 10 Jul 2016 00:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468136238; bh=WkjlTUS1QEUEXSEcea+NqPeXbUtxUET3X3vq5yZoQRE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=d/LdH6kyYpqzb/MtxfgbPPYJ+TKD/YFsmUaxum7kBMsDsTWYrh7eIlcmOK1XE4DXhrL8/FNuuDtuXjWoTLOQwNs90PQrDbKvFRGmGQp5PXJXruGb1uOJQIJa4iDVD4FWJbZgmFWPzSDQa7ijwiwaiZLO3SpoCt6bwlCmh1HQE0/4ka3Fj+S0gz4arGLyblszhXkL3Ds0K5/PA2BaPTX+A9L6iV4C+geCJedLXVwiyvNqX3VgzjzymyP5e7pfQmLZDHyjxlzgVqdak8Bpnz1NQra8CcpA6P1NX5L7PQMpoODYhFr74lHdbVRDLiuaS7XfL36VQKCWUWTa2aUfGU1WfQ== Received: from [98.139.170.180] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2016 07:37:18 -0000 Received: from [98.139.212.198] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2016 07:37:18 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 10 Jul 2016 07:37:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 923014.83837.bm@omp1007.mail.bf1.yahoo.com X-YMail-OSG: So6biaMVM1ltKE9vW8OPaEC7TgbVZ0hgmPWbEJLElY_k2Cct0OjfASZ4oRweU2G XSyx39OrEHoFiMBTy_PnYQx2Nnk_iREyfE3KkcatqG_GIoGcSEo0_yfDXPjebg7GCXGme6ClRHp8 2v7XKAjGcs_wPvLTBzUxHhYe_eHAyqeSaeL7CoXKAK1itS_L8M4DwQ0ftPhJFYLBecTzSa_JSNNE fg0GK_Zx0ydROkzGhpAvPVNn4tlWZ.mvYTCbr6brAxEds9TheG.ts_A3ynOsAd0.PqELHaB7MviV q.ABK96bUWBMKCDeXmO.i464sJk6i25UXhLA8k1yRlRn16ZYXTKLs_G.6ByuQjcctiGic6PgC2aP Z7DjxOhEoBNI.MwMDgJbqTqmnD3bPxuCO_5nst9BLj4shd2w_AQwOneVQa9_rswxuMd2pHB7aZ9u ueC9XSPE2EIBlRiaTl6VbalifNjaEma4SRPUOPURa1VsbjaJ9H0WRHp._cIDEDEifTmppOk7v_Ev veOMGMwxHuUS9Feaik_dQBvC2wgeDVNgw7URMXxxWYbQgX89G Received: from jws106135.mail.bf1.yahoo.com by sendmailws106.mail.bf1.yahoo.com; Sun, 10 Jul 2016 07:37:18 +0000; 1468136238.474 Date: Sun, 10 Jul 2016 07:36:59 +0000 (UTC) From: To: "draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org" , "draft-ietf-dice-profile@tools.ietf.org" Message-ID: <880079020.470300.1468136219291.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_470299_894945123.1468136219286" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: g_e_montenegro@yahoo.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: Sun, 10 Jul 2016 07:37:22 -0000 ------=_Part_470299_894945123.1468136219286 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'm curious as to the relationship between this TLS WG draft and the DICE p= rofile for IoT (currently in Auth48):https://tools.ietf.org/html/draft-ietf= -dice-profile The dice profile uses two TLS ciphershuites TLS_PSK_WITH_AES_128_CCM_8 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0(defined in https://tools.ietf.org/html/rfc6655) TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 =C2=A0=C2=A0=C2=A0=C2=A0(defined in http= s://tools.ietf.org/html/rfc7251) Notice that the DICE profile defines nothing (it has no IANA considerations= ). Instead, it reuses definitions established previously per the references= above. This draft-ietf-tls-ecdhe-psk-aeak =C2=A0claims to also define IoT-friendly= ciphersuites, for example,=C2=A0TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256=20 However, it does not reference the DICE profile draft.=C2=A0 What is the difference between these? thanks, Gabriel=C2=A0=20 On Friday, May 27, 2016 10:19 AM, "internet-drafts@ietf.org" wrote: =20 =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security of the IETF. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : ECDHE= _PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (T= LS) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : John Matts= son =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 Daniel Migault =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-tls-ecd= he-psk-aead-00.txt =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-05-= 27 Abstract: =C2=A0 This document defines several new cipher suites for the Transport =C2=A0 Layer Security (TLS) protocol.=C2=A0 The cipher suites are all based= on =C2=A0 the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key =C2=A0 (ECDHE_PSK) key exchange together with the Authenticated Encryption =C2=A0 with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.=C2=A0 PS= K =C2=A0 provides light and efficient authentication, ECDHE provides perfect =C2=A0 forward secrecy, and AES-GCM and AES-CCM provides encryption and =C2=A0 integrity protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. 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 ------=_Part_470299_894945123.1468136219286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm curious as to the relationship between this TLS WG draft and th= e DICE profile for IoT (currently in Auth48):

The dice profile uses t= wo TLS ciphershuites

TLS_PSK_WITH_AES_128_CCM_8     &nbs=
p;       (defined in https://tools.ietf.org/html/rfc6655)

TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8    &n=
bsp;(defined in https://tools.ietf.org/html/rfc7=
251)

Notice that the DICE= profile defines nothing (it has no IANA considerations). Instead, it reuse= s definitions established previously per the references above.

This draft-ietf-tls-ecd= he-psk-aeak  claims to also define IoT-friendly ciphersuites, for exam= ple, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256

However, it does not reference the= DICE profile draft. 

What is the difference between these?

thanks,

Gabriel 


On Friday, May 27, 2016 10:19 AM, "internet-drafts@ietf.org" <internet= -drafts@ietf.org> wrote:



A New Internet-Dra= ft is available from the on-line Internet-Drafts directories.
This draft= is a work item of the Transport Layer Security of the IETF.

  =       Title          : ECDHE_PSK w= ith AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)        Authors        : John Mat= tsson
                  &nb= sp;       Daniel Migault
    Filename = ;       : draft-ietf-tls-ecdhe-psk-aead-00.txt
 &nbs= p;  Pages          : 7
   = Date            : 2016-05-27

Abstract= :
  This document defines several new cipher suites for the Transp= ort
  Layer Security (TLS) protocol.  The cipher suites are a= ll based on
  the Ephemeral Elliptic Curve Diffie-Hellman with Pre= -Shared Key
  (ECDHE_PSK) key exchange together with the Authentic= ated Encryption
  with Associated Data (AEAD) algorithms AES-GCM a= nd AES-CCM.  PSK
  provides light and efficient authenticatio= n, ECDHE provides perfect
  forward secrecy, and AES-GCM and AES-C= CM provides encryption and
  integrity protection.


The = IETF datatracker status page for this draft is:
https= ://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

There= 's also a htmlized version available at:
https://tools.i= etf.org/html/draft-ietf-tls-ecdhe-psk-aead-00


Please note th= at 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-draft= s/

_______________________________________________
TLS mailin= g list
T= LS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


------=_Part_470299_894945123.1468136219286-- From nobody Sun Jul 10 03:51:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECD512D0FB for ; Sun, 10 Jul 2016 03:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo_i6SvKEAmO for ; Sun, 10 Jul 2016 03:51:22 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id F04F012D0F9 for ; Sun, 10 Jul 2016 03:51:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-49-237-162-110.revip6.asianet.co.th; To: tls@ietf.org References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> From: Peter Dettman Message-ID: <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> Date: Sun, 10 Jul 2016 17:51:06 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 10:51:24 -0000 Hi, I've just implemented these ciphersuites in BouncyCastle TLS, and have a couple of questions: In Section 3., should TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD}; end with ...SHA384 instead? For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 384 bits. requires SHA384 as the PRF, and I don't know what else SHA256 could refer to for an AEAD ciphersuite. I'm also curious whether there is a precedent in other RFCs for an explicit minimum curve bits, or perhaps a de facto implementer's rule? Regards, Pete Dettman On 28/05/2016 12:19 AM, 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 of the IETF. > > Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) > Authors : John Mattsson > Daniel Migault > Filename : draft-ietf-tls-ecdhe-psk-aead-00.txt > Pages : 7 > Date : 2016-05-27 > > Abstract: > This document defines several new cipher suites for the Transport > Layer Security (TLS) protocol. The cipher suites are all based on > the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key > (ECDHE_PSK) key exchange together with the Authenticated Encryption > with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK > provides light and efficient authentication, ECDHE provides perfect > forward secrecy, and AES-GCM and AES-CCM provides encryption and > integrity protection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-00 > > > 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 Sun Jul 10 09:38:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCBB12D0DE for ; Sun, 10 Jul 2016 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38FFtsEGcYjr for ; Sun, 10 Jul 2016 09:38:53 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 9CF7512B005 for ; Sun, 10 Jul 2016 09:38:53 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j17so75151484ywg.0 for ; Sun, 10 Jul 2016 09:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AGZG7Peb1NrHGoGxZPK+fjN4IbTFfJZwhoGf0lJg9Lw=; b=oEsyRSBFf3ykT1b3ooF2ZGyRjGXw8vFLceTmul2RMlcXuC/sg0DlbzqK9WL7KEN3fo ZDxOa7g3p3Z6JiJl9rwJBX2URfcQgV5+KHnyrF78Rw3pX/F29L8MYlE6NM84qDs2upN9 lUDiMCsXLvM7oeqvx+I1ytcVJoCxAK4hGYHA7iT8/2tWOEov/P8ha0TvA/5wbxs9uxSi zDuIkazVDwhbt8G/Yf0+uJnjvT8T43hz3xmnPsf9CtmuIWsYnfSCx8S0tjxNvcHvGxkZ UC4BZSCYNE+UQOUWbZWozDrkClC4OiXaL/XjaH2e8/d2Wn4NmdQfgkdntA7ltuIvSQyr A2VQ== 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; bh=AGZG7Peb1NrHGoGxZPK+fjN4IbTFfJZwhoGf0lJg9Lw=; b=TlAOjA6cf2hzCagjksRC2Qp+sZ4RmM6lWZAEiD6dp8AJ0dudZt4J25NdEuXcRxF75i /ceKCYgVRtW7d05dYQk02GLF+u9kG2YSNLBVZ2MKBn6L0WZePlE8s75g6/M9mY7p0NMt AfWoJVD6bYJYJu97RjI4H+7V0IkUhuwnBHJlJv63f6yIM3TI1qZPbDCgV/XAw9r62a0p fTNE4nweFeRYvnRYK+su3JWbBnMQq9qSbObDMfkA4hAbA8f/UpXRzz7+iPxf/r8YLZG4 crtctHYuYl6sAahUud9foSgKMn8afKGOFxlZUAgm6oKKjrzXBfZ9h4HPvg2403IlGiDH kQCw== X-Gm-Message-State: ALyK8tIIWGU7zWBqjfHkLtqjfljYDu2n2jsIZdKiAOw89DkIDgoptf1XJgnxDyoQne+oOIPO6WBI06XZEM5DXw== X-Received: by 10.129.52.149 with SMTP id b143mr8512438ywa.8.1468168732828; Sun, 10 Jul 2016 09:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Sun, 10 Jul 2016 09:38:13 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E9956564C30@PRN-MBX01-4.TheFacebook.com> References: <2abfa3b92ff34c7784a59060c8a3c3f8@usma1ex-dag1mb1.msg.corp.akamai.com> <974CF78E8475CD4CA398B1FCA21C8E9956564C30@PRN-MBX01-4.TheFacebook.com> From: Eric Rescorla Date: Sun, 10 Jul 2016 09:38:13 -0700 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a114146baca9b3b05374aabc3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 16:38:55 -0000 --001a114146baca9b3b05374aabc3 Content-Type: text/plain; charset=UTF-8 Can be found in: https://github.com/tlswg/tls13-spec/pull/530 On Sat, Jul 9, 2016 at 1:03 PM, Subodh Iyengar wrote: > +1 > > Subodh > ------------------------------ > *From:* TLS [tls-bounces@ietf.org] on behalf of David Benjamin [ > davidben@chromium.org] > *Sent:* Saturday, July 09, 2016 11:49 AM > *To:* Salz, Rich; Eric Rescorla; tls@ietf.org > *Subject:* Re: [TLS] Issue 472: Remove non-closure warning alerts > > On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich wrote: > >> > If people are in favor of this, I will prepare a PR. >> >> +1 >> > > +1 > > David > --001a114146baca9b3b05374aabc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can be found in:

On Sat, = Jul 9, 2016 at 1:03 PM, Subodh Iyengar <subodh@fb.com> wrote:
+1=C2=A0

Subodh
From: TLS [tls-bounces@ietf.org] on behalf of David Benjamin [davidben@chromium.org]
Sent: Saturday, July 09, 2016 11:49 AM
To: Salz, Rich; Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts

On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich <rsalz@akamai.com> wrote:
> If people are in favor of this, I will prepare a PR.

+1

+1

David=C2=A0

--001a114146baca9b3b05374aabc3-- From nobody Mon Jul 11 07:27:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6587C12D1E6 for ; Mon, 11 Jul 2016 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbHC11FZqIjz for ; Mon, 11 Jul 2016 07:27:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75C112D0C9 for ; Mon, 11 Jul 2016 07:27:24 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p74so59201912qka.0 for ; Mon, 11 Jul 2016 07:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=tfjuR/feKxktsLYNPIYBCdt2lN+UqqvutfZBDg4uB1w=; b=fbjf2VUz89eOz4BKFJFYj8YdIthM5PTrFuJJ49Qverde/XyzYrq6EloJFM4VKRJog/ A+nOJqpIGCc27gKc0FH68spbvyY7xI0joLqlyUjijbyILiayMp+4jOCOuVW0Vw1PIeLx 3AOfO8OUad24lLU8p4Dlgep+oFWuqA6FyamnE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=tfjuR/feKxktsLYNPIYBCdt2lN+UqqvutfZBDg4uB1w=; b=A67hDEmBu1Deq8LomiEOe/cZioZ6PiVNecZF2liQmE9HQ/nFBxMt2wiaFUUUZIhEMJ npBcgbChUk1Sy8JpPjy6JU2vtGUJStnb4LpnOzupX3jsxuhT3CBvFmCn/RPiQQXeJx8s IxMjK1ctCsHjNJR7+f0oNdihyOZFpB+rYCMSJC2T2FsxzYhmsRI2Zr8GUfbvXSweNLHU v3NpxolFaM3cHz9iNSonFf/yfhAP9+RctWtEfRaNA9jlsPrsjB/OkoozaFNZfrZVKIA+ GYy3sk4gi6LKO0eoS857h4/fc1Bym+lXG6ahdA2zVjbQuBVI5ydHotB2sWAVHY+c+5rb udEg== X-Gm-Message-State: ALyK8tJnOkeNn38/staACa89sNZU5BoEKu/+P+n7TiX4JIPo+WciMYbg+M+KWaPEBF8KDA== X-Received: by 10.55.203.156 with SMTP id u28mr26370957qkl.116.1468247243556; Mon, 11 Jul 2016 07:27:23 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id q5sm2118239qkd.2.2016.07.11.07.27.22 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 07:27:23 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> Date: Mon, 11 Jul 2016 10:27:21 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:27:27 -0000 Hi, Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 = items we=E2=80=99re looking for WG input on: - Before 12 July, we=E2=80=99d like to know your thoughts about = progressing draft-ietf-tls-pwd (Watson and ekr responded): https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 - Before 14 July, we=E2=80=99d like to know your thoughts on the = proposed AUTH48 proposed changes (nobody has commented on this): https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk spt= From nobody Mon Jul 11 07:35:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3752C12D50D for ; Mon, 11 Jul 2016 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRxSFL1v_CNK for ; Mon, 11 Jul 2016 07:35:22 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 1EE6412D187 for ; Mon, 11 Jul 2016 07:35:22 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o67so28850960qke.1 for ; Mon, 11 Jul 2016 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mJE8YUEfGtoTYoQcUI6lOm+mHpWT9OdBX5xKnoNDOz0=; b=d7G4e4TxVl0dGhuniDNu+KSgu9QkOgmJs1Y7C1OaO6XMxpZEX74SLkWnUQ782mSQkk b7KbchE+2xpDkKa/JCrNx2xKrZ4MLPLOjTw7KGflXREXCMFNe+LyHPa3lfdfYQeVTDzi BGG2piEByqVQ4H6V3KO3kWnD3Jx0K62tzFgl8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mJE8YUEfGtoTYoQcUI6lOm+mHpWT9OdBX5xKnoNDOz0=; b=mePuim36h4+x8Irdz4UkAr9anRvHLgMAFM8DKRyBMdBlqnHxOuH4v+RxkYXxISwEmL 4hzElUCaL23jsvqbEbOAXN59rQFdiR8+63oy1sCBeKwq2U3Fw5l1y+sLrj3mLzQN/ClK jmYFwGdTQVExpS0CbTXuncG9AgaQqW7f2G9hiSJoafrD+FIEYMD0XgyFUa9pUVYIwYXP 1TMYBXMYqXLFAeZuSF0hYf5c0+eEfSgr4ulTmxQMYbiytyVvuJgjBgy7E8drpDGFD53D Hst50DrNDSkc7+UddHjq413aWzm5riQ4ocOuX1BAmM8aWUKF6P02juV2e3JG/7J/aJv9 xK0g== X-Gm-Message-State: ALyK8tI1ksf7VAwbjpf9So8oUnhW0/CQpJtSioGtjToqE7xs2tQiXRdUSMNPRGNdtnHnkQ== X-Received: by 10.55.215.141 with SMTP id t13mr26224362qkt.31.1468247721316; Mon, 11 Jul 2016 07:35:21 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id l32sm2901527qta.23.2016.07.11.07.35.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 07:35:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <880079020.470300.1468136219291.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 11 Jul 2016 10:35:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <880079020.470300.1468136219291.JavaMail.yahoo@mail.yahoo.com> To: g_e_montenegro@yahoo.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-dice-profile@ietf.org, "tls@ietf.org" , draft-ietf-tls-ecdhe-psk-aead@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:35:24 -0000 > On Jul 10, 2016, at 03:36, g_e_montenegro@yahoo.com wrote: >=20 > Hi, >=20 > I'm curious as to the relationship between this TLS WG draft and the = DICE profile for IoT (currently in Auth48): > https://tools.ietf.org/html/draft-ietf-dice-profile >=20 > The dice profile uses two TLS ciphershuites >=20 > TLS_PSK_WITH_AES_128_CCM_8 (defined in = https://tools.ietf.org/html/rfc6655) >=20 > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (defined in = https://tools.ietf.org/html/rfc7251) >=20 > Notice that the DICE profile defines nothing (it has no IANA = considerations). Instead, it reuses definitions established previously = per the references above. >=20 > This draft-ietf-tls-ecdhe-psk-aeak claims to also define IoT-friendly = ciphersuites, for example, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256=20 >=20 > However, it does not reference the DICE profile draft.=20 >=20 > What is the difference between these? There=E2=80=99s might be a relationship between the DICE profile and = this draft in the future. The DICE draft profiles the existing set of cipher suites that are = already defined for IoT; the complete list can be found here: = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 draft-ietf-tls-ecdhe-psk-aead is adding more algorithms to that list. = The DICE profile can be updated later to include these newly defined = cipher suites if that=E2=80=99s what the WG wants to do. Make sense? spt= From nobody Mon Jul 11 07:40:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C119312D1D8 for ; Mon, 11 Jul 2016 07:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fj59gJTzuzZ for ; Mon, 11 Jul 2016 07:40:34 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 6121612D1BD for ; Mon, 11 Jul 2016 07:40:34 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o67so29016555qke.1 for ; Mon, 11 Jul 2016 07:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6mL4+e1ay5UHZHU9uMg6TAEObo2uSNUtKPnzcuuyPac=; b=K+JAiUUdhGUcNN32BSADzofL4ajK4XpHINlA0sj4KSKSBWbWJs/svbsbfeEy9oQtl0 YypaXGc/f6Knvo9YYvfP3f48/MGT4qgNqcRTdnEiBY2RSKE0cGdaDkdsH1Wsgea2ud9Z y4Uud/Av4O5MJnstyxP5GlvtrvRLDlb0nlxms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6mL4+e1ay5UHZHU9uMg6TAEObo2uSNUtKPnzcuuyPac=; b=IcV0XITe0FE4xTyqa6mtkYukmgkC5lPB3X9+iX/ZsQSC9RmtNF0ZwyY9nulpKeKEfR hDOs1G7D1Z/52jWwk9XQ9wQX3/3aVeTDfCI31xuwAi5wMDT+N+d1LcJAwskUVo0pir1D OfRIaw3u+2VcwmFoibXp3sGoP6cPy+psrVBbwKsEr2NqUtPPnjeOBbqVyO/dHOPyierx eyVT/FuvDG7+N1zZSm7g0S3y4a32md6/Wg0pdytmTfGAW+5o3CC08bKwJq3ZGnd74jlw dH4XZObb1CpzvczEAjtTUnxOZwu2gosc798BuCldRlms7689dptciGTdRKDDDxwTbPcY mUpQ== X-Gm-Message-State: ALyK8tL1CNCrT5dC5ZeP4kv5TYOdcvvNbQa2SxdC0ZRqFBI/b/CovmHJUyqg/t0KT2Jx0Q== X-Received: by 10.55.133.197 with SMTP id h188mr25086011qkd.165.1468248033605; Mon, 11 Jul 2016 07:40:33 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id j62sm2466483qtb.35.2016.07.11.07.40.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 07:40:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> Date: Mon, 11 Jul 2016 10:40:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> To: Peter Dettman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:40:36 -0000 I think I can take this bit: On Jul 10, 2016, at 06:51, Peter Dettman = wrote: >=20 > I'm also curious whether there is a precedent in other RFCs for an > explicit minimum curve bits, or perhaps a de facto implementer's rule? I=E2=80=99d be happy to be wrong here. but to my knowledge no there=E2=80=99= s not been an explicit minimum for curve bits. There have however been = similar (at least in my non-cryptographer mind) for RSA key sizes so if = we wanted to define an explicit minimum curve bits then we could. spt From nobody Mon Jul 11 08:07:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AFD12D54D for ; Mon, 11 Jul 2016 08:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJk5lfKPatwU for ; Mon, 11 Jul 2016 08:07:23 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 5113A12D1DE for ; Mon, 11 Jul 2016 08:07:23 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id f7so127348824vkb.3 for ; Mon, 11 Jul 2016 08:07:23 -0700 (PDT) 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-transfer-encoding; bh=Z3u8EI43iuvKnwpgCE8f4jnYZ3ZFzTTOq8ELtk9Xk80=; b=NH45zasnlWweot5su1Zkgs9mqiycag0zLfIJ6fKAi+JMOVmUslLUeqvCUDGrdjtVf7 4ERlTMYncQxLxO10mIv6lyCx7FDnoT9P7eY8TVEs3e4Upbj0qZtilUUvccE7tdT7vnXM yWNBdNwxWyQvOT6b8fgP8+ZHzSrjYiLly6B6rbXzBjhoZLRtUYIA2vkKlMBUywN6nrO1 hyYsdYVz/CvofSVpEZGLBJk8URjeOVwFD7hjIY3d98ycTgv95HInm9gxqj4a59ubPSxM z4HDti2vzzLuiuY1A5PAyVMqm3dRSIvwUj+KFkii43X1hLzknv+7qobyfCKqFgys8aFC z3cg== 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-transfer-encoding; bh=Z3u8EI43iuvKnwpgCE8f4jnYZ3ZFzTTOq8ELtk9Xk80=; b=I0ENsaIqEubx73tqVzKpzepDYdTYc2EI5YteH8p26BxtCNfy1dsX3D/K+X9w1WjEZZ rtsUrUJ5QppKFZ2bB47OHZmWuct5a644X4dRCFwpVqndjd+/pUhqQIbv3hWH536ffR+r TVsBkU2woeiWGs7xPPSg1kFe2xtvC2pghvpY0l/tJvqI6WlXZEz9ZqpARAKlJu0YrWjV Y0liyDQU5YmiPlS2jl2KXwkSEicd3KL7rmIZwjdhmXIbWwOwrr8p+zyl7P43alhMPzvj j8GZpQxGW2PvvhyVXXo0d7RPDjTZBzTnprTrlHc0/UTHLcLYnQyZE4Q5+O9j6HAYsEf0 U8vg== X-Gm-Message-State: ALyK8tLGr21JZNP0qLUuD2Xq0MmtIIJO2zD2dX6vc9kBKIQKanPvQ94hgXkAq21xuGNUo8/znHlSQkkcaRUryA== X-Received: by 10.31.219.197 with SMTP id s188mr8088557vkg.31.1468249642353; Mon, 11 Jul 2016 08:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Mon, 11 Jul 2016 08:07:21 -0700 (PDT) In-Reply-To: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> From: Watson Ladd Date: Mon, 11 Jul 2016 08:07:21 -0700 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:07:28 -0000 On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner wrote: > Hi, > > Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 ite= ms we=E2=80=99re looking for WG input on: > > - Before 12 July, we=E2=80=99d like to know your thoughts about progressi= ng draft-ietf-tls-pwd (Watson and ekr responded): > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 > > - Before 14 July, we=E2=80=99d like to know your thoughts on the proposed= AUTH48 proposed changes (nobody has commented on this): > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk I don't like the AUTH48 changes. I understand the need for changing to MAY, but the proposed method of distinguishing offends my sensibilities. Overloading the length field is just ugly. > > spt > _______________________________________________ > 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 Mon Jul 11 08:35:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9614612D59A for ; Mon, 11 Jul 2016 08:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E7xise5sISH for ; Mon, 11 Jul 2016 08:35:02 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 5850912D563 for ; Mon, 11 Jul 2016 08:35:02 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id b72so95818989ywa.3 for ; Mon, 11 Jul 2016 08:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wp0pGu9T/SQmbEGtT0DPbOVlNDatlXWnJZr/iY+4vFw=; b=OzDOKQ3tebllqB5RkAVEXUcUWk+zEmaAENypYfAKT/txZAWlmCX3i2SU310sQ4IdZK /YFam7oaZqfYJBNY5Jv2mSQ4R9Od+4EdRnm65rNykXwYxgq3Qr3swNGJUjG9n3c2LvyC vsITGsSoKK37jQbMTynOOJKxI8vu2x7yovs5G34XLAfnLen68UhXj0udMUWNyVTP6psq 3KD4t+DstSvEPp45V+YdbfQrO831dEq8xCKzrWVP+3CKW2hoHsqp5uvp6Zpr+dcdyAak mnUcDDnZkq7t3KMVgUT44beNovAl/uER5dIe4hBgV+F/F3NCXE2LCMz0oZvTNmn4iF7H AuGw== 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; bh=Wp0pGu9T/SQmbEGtT0DPbOVlNDatlXWnJZr/iY+4vFw=; b=eHPfKB+N7d/4Xj4a2ObQ66D0QRuXRB0cFdc0k9U4qp4TwwFQVJh9hctPYNjy9CjNlJ iKHiGNqdkiHfJUb9WQu57UQGSKvNxMYKVwsOH3tAq/0S5f0W9O8vvvg7tCmQmE/lwKZA fsBK+CM7HF9yYZW05Vk3cy/eWv7Gu5qAzyv2T048QbKhc8n/6ONY+57j6yksX4dGVVQe SiSsImN9sNcEIi5uqSP2G2mfp0DSWsgTHSyaObXqOyc+7c/CMWfliqMyXuiFjFeoiGAQ kl7T6KDMAGLUcypB6VcJwWQoZXQhdAebI/Us533nqCr2Ul0KG9iKdhl8ZRU4o3dcRnBO vQYg== X-Gm-Message-State: ALyK8tIEN8Tm7KdJ74gxGojLp8g7GVqxa9sg53hQlLO5eZehP9QM2yjInZm2T1my3fJaEUIuzHeJkUoJejzY1g== X-Received: by 10.13.199.68 with SMTP id j65mr14109751ywd.289.1468251301637; Mon, 11 Jul 2016 08:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 11 Jul 2016 08:34:22 -0700 (PDT) In-Reply-To: References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> From: Eric Rescorla Date: Mon, 11 Jul 2016 08:34:22 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114dfc4a469e9805375de52b Archived-At: Cc: "" Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:35:04 -0000 --001a114dfc4a469e9805375de52b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Watson's assessment here. This seems like the wrong design choice. I'm not familiar with OpenSSL's cert selection, but I don't believe that the issue that this change is intended to address applies to NSS, for two reasons: 1. NSS does cert selection during client hello processing [0]. http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#= 9569 2. Unless I misunderstand the design of cached-info, all the server needs to have is the digest of the serialized chain and it could store that at the time that it configures the cert (or first uses it). This seems like quite a small burden. I believe the prior design was superior. -Ekr On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd wrote: > On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner wrote: > > Hi, > > > > Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 i= tems > we=E2=80=99re looking for WG input on: > > > > - Before 12 July, we=E2=80=99d like to know your thoughts about progres= sing > draft-ietf-tls-pwd (Watson and ekr responded): > > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 > > > > - Before 14 July, we=E2=80=99d like to know your thoughts on the propos= ed AUTH48 > proposed changes (nobody has commented on this): > > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk > > I don't like the AUTH48 changes. I understand the need for changing to > MAY, but the proposed method of distinguishing offends my > sensibilities. Overloading the length field is just ugly. > > > > > spt > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dfc4a469e9805375de52b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Watson's assessment here. This seems like= the wrong design choice.

I'm not familiar with Open= SSL's cert selection, but I don't believe that the issue
= that this change is intended to address applies to NSS, for two reasons:

1. NSS does cert selection during client hello proce= ssing [0].

2. Unless I misunderstand the design of cached-info, all the server needs<= /div>
to have is the digest of the serialized chain and it could store = that at the time
that it configures the cert (or first uses it). = This seems like quite a small burden.

I believe th= e prior design was superior.

-Ekr







On Mon, Jul 11, 2016 at 8:07 AM, Wats= on Ladd <watsonbladd@gmail.com> wrote:
On Mon, Jul 11, 2016 at 7:27 AM, Sean Tur= ner <sean@sn3rd.com> wrote:
> Hi,
>
> Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 = items we=E2=80=99re looking for WG input on:
>
> - Before 12 July, we=E2=80=99d like to know your thoughts about progre= ssing draft-ietf-tls-pwd (Watson and ekr responded):
> https://mailarchive.ietf.o= rg/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
>
> - Before 14 July, we=E2=80=99d like to know your thoughts on the propo= sed AUTH48 proposed changes (nobody has commented on this):
> https://mailarchive.ietf.o= rg/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk

I don't like the AUTH48 changes. I understand the need for chang= ing to
MAY, but the proposed method of distinguishing offends my
sensibilities. Overloading the length field is just ugly.

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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

--001a114dfc4a469e9805375de52b-- From nobody Mon Jul 11 09:16:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201CF12D592 for ; Mon, 11 Jul 2016 09:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5ogW7xfv_AD for ; Mon, 11 Jul 2016 09:16:56 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8BA12B03C for ; Mon, 11 Jul 2016 09:16:55 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q83so41245196iod.1 for ; Mon, 11 Jul 2016 09:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=80949/bhDEPy6J0MeJ4+qhZPemoZ2AFFJ9DOAtnoQho=; b=ATJ+ryhM1Vye1uz/iPqOTRvwi0lEfmI0Y3SDr3LB1PCb7Otqxa2JNkQKUqAlY8PlK+ qMFmFUWSbzJDXAIFpgw4Ax7yQ2TRrq4dROwaH1ALFhlXHF7igyPNfLdyjAXfKE0XQ4E/ WWyeFd7+JKO5MTtdQXuS/Y4YSS0CwAe1L0vuk= 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; bh=80949/bhDEPy6J0MeJ4+qhZPemoZ2AFFJ9DOAtnoQho=; b=RUHM0x1wrTOzpr+C9jBPn69LJU4Lsm/FDis1NxI5Fzu4MhUl/waDBnOF1rBN/EGtcE CW8NwRRhBxh7zRauDXDM5lMSI/UBmS7wpVZ2tHCPkoYnkAXdHfFZUL81UAxesg2DUiSA e0fR2KvwyEWxeduR6N8hl+bBfSgbvddHEZ9TaviwHVmXECDBU628Nit8XZu8kf+VU5d3 3nmf80Ypf9IY7f/v0Yefg48JaTyqCW5SLmKG9GOTLTf7QcUqy1qIX7yu2ywHt+d38hvo 18cDXuGyGBwDhTviYVgsI1HzqRa/fRrDWeNK6mE8yjX+uy/ShdBgXrqrRJnxiQnMhGPG 2qXQ== X-Gm-Message-State: ALyK8tJ70T1ZqMiH5ncECxq7i4mbOmfVu37Q+JTJXM3D1JosGIWrq978c7RUUzVCbdIs0dbh+/IizhxCJZ+NqVvQ X-Received: by 10.107.128.25 with SMTP id b25mr14570344iod.110.1468253815028; Mon, 11 Jul 2016 09:16:55 -0700 (PDT) MIME-Version: 1.0 References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> In-Reply-To: From: David Benjamin Date: Mon, 11 Jul 2016 16:16:44 +0000 Message-ID: To: Eric Rescorla , Watson Ladd Content-Type: multipart/alternative; boundary=001a113fb5961624b405375e7b77 Archived-At: Cc: "" Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:16:58 -0000 --001a113fb5961624b405375e7b77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this earlier. In general, we already require one know the certificate chain before sending ServerHello. The cipher suite depends on the leaf key type, so that must be selected already. If there are SCTs to deliver for any intermediates, the server must know which intermediates will be sent. If one wishes to consider intermediates' signature algorithms when selecting a leaf, they must be known too. If there are are other reasons we'd want to allow sending either hash or contents (Caching a long-lived intermediate but sending a new short-lived leaf? Looks like it's all-or-nothing right now. I dunno, I haven't been paying attention to cached-info yet and assume this is well-trodden ground by now.), the length still should not be a distinguisher. If needed, negotiating the extension can tweak the syntax of Certificate message or something. David On Mon, Jul 11, 2016 at 11:35 AM Eric Rescorla wrote: > I agree with Watson's assessment here. This seems like the wrong design > choice. > > I'm not familiar with OpenSSL's cert selection, but I don't believe that > the issue > that this change is intended to address applies to NSS, for two reasons: > > 1. NSS does cert selection during client hello processing [0]. > > http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.= c#9569 > > 2. Unless I misunderstand the design of cached-info, all the server needs > to have is the digest of the serialized chain and it could store that at > the time > that it configures the cert (or first uses it). This seems like quite a > small burden. > > I believe the prior design was superior. > > -Ekr > > > > > > > > > > On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd > wrote: > >> On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner wrote: >> > Hi, >> > >> > Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 = items >> we=E2=80=99re looking for WG input on: >> > >> > - Before 12 July, we=E2=80=99d like to know your thoughts about progre= ssing >> draft-ietf-tls-pwd (Watson and ekr responded): >> > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 >> > >> > - Before 14 July, we=E2=80=99d like to know your thoughts on the propo= sed >> AUTH48 proposed changes (nobody has commented on this): >> > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk >> >> I don't like the AUTH48 changes. I understand the need for changing to >> MAY, but the proposed method of distinguishing offends my >> sensibilities. Overloading the length field is just ugly. >> >> > >> > spt >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> >> _______________________________________________ >> 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 > --001a113fb5961624b405375e7b77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OpenSSL determines which certificate to use during ClientH= ello processing, but it has a mode where, if intermediates were not explici= tly configured and only a leaf, it path-builds right before sending the Cer= tificate message. But I don't see any reason why it can't be change= d to compute this earlier.

In general, we already requir= e one know the certificate chain before sending ServerHello. The cipher sui= te depends on the leaf key type, so that must be selected already.=C2=A0If there are SCTs to deliver for any intermedi= ates, the server must know which intermediates will be sent. If one wishes = to consider intermediates' signature algorithms when selecting a leaf, = they must be known too.
If there are are other = reasons we'd want to allow sending either hash or contents (Caching a l= ong-lived intermediate but sending a new short-lived leaf? Looks like it= 9;s all-or-nothing right now. I dunno, I haven't been paying attention = to cached-info yet and assume this is well-trodden ground by now.), the len= gth still should not be a distinguisher. If needed, negotiating the extensi= on can tweak the syntax of Certificate message or something.

David

On Mon, Jul 11, 2016 at 11:35 AM Eric Rescorla <ekr@rtfm.com> wrote:
I agree with Watson's assessment her= e. This seems like the wrong design choice.

I'm not = familiar with OpenSSL's cert selection, but I don't believe that th= e issue
that this change is intended to address applies to NSS, f= or two reasons:

1. NSS does cert selection during = client hello processing [0].

2. Unless I misunderstand the design o= f cached-info, all the server needs
to have is the digest of the = serialized chain and it could store that at the time
that it conf= igures the cert (or first uses it). This seems like quite a small burden.

I believe the prior design was superior.
=
-Ekr



<= div>





O= n Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Mon, Jul 11= , 2016 at 7:27 AM, Sean Turner <sean@sn3rd.com> wrote:
> Hi,
>
> Just wanted to remind everybody that we=E2=80=99ve got two non-TLS1.3 = items we=E2=80=99re looking for WG input on:
>
> - Before 12 July, we=E2=80=99d like to know your thoughts about progre= ssing draft-ietf-tls-pwd (Watson and ekr responded):
> https://mailarchive.ietf.o= rg/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
>
> - Before 14 July, we=E2=80=99d like to know your thoughts on the propo= sed AUTH48 proposed changes (nobody has commented on this):
> https://mailarchive.ietf.o= rg/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk

I don't like the AUTH48 changes. I understand the need for chang= ing to
MAY, but the proposed method of distinguishing offends my
sensibilities. Overloading the length field is just ugly.

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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

_______________________________________________
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
--001a113fb5961624b405375e7b77-- From nobody Mon Jul 11 09:22:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52CE12D5C4 for ; Mon, 11 Jul 2016 09:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M1QmnMuADGE for ; Mon, 11 Jul 2016 09:22:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3A12D599 for ; Mon, 11 Jul 2016 09:22:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ABC2643346A for ; Mon, 11 Jul 2016 16:22:42 +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 8B21A433403 for ; Mon, 11 Jul 2016 16:22:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468254162; bh=RNqxX9v3VM71pIz3gCElz0kEF2VSzGSnn9TbICQAuLA=; l=10528; h=References:Cc:From:Date:In-Reply-To:From; b=tvtSSG100kfV6OjIuGtqVxYiBcfRvCiKD/+mk6MQ+//hRgcSXwzk0o9uRDOv40z+d yaqsVesxcHymEjrl9qOgYtZgovbYFFMQkzm9H8F3d63OFefb+wcpqWJD2YOhdDqRLP xEbviNQHGF/QkOpAsS7XD8TDBNYwT4zOdO/lXAu0= 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 51DC21FC8C for ; Mon, 11 Jul 2016 16:22:42 +0000 (GMT) References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> Cc: "" From: Benjamin Kaduk Message-ID: <5783C7D2.6040902@akamai.com> Date: Mon, 11 Jul 2016 11:22:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060502000801020608070704" Archived-At: Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:22:46 -0000 This is a multi-part message in MIME format. --------------060502000801020608070704 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I also don't like the AUTH48 changes -- there's no protocol-level reason to weaken the MUST, since a server that can't handle the extra state/processing can just not implement the extension at all. -Ben On 07/11/2016 10:34 AM, Eric Rescorla wrote: > I agree with Watson's assessment here. This seems like the wrong > design choice. > > I'm not familiar with OpenSSL's cert selection, but I don't believe > that the issue > that this change is intended to address applies to NSS, for two reasons: > > 1. NSS does cert selection during client hello processing [0]. > http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#9569 > > > 2. Unless I misunderstand the design of cached-info, all the server needs > to have is the digest of the serialized chain and it could store that > at the time > that it configures the cert (or first uses it). This seems like quite > a small burden. > > I believe the prior design was superior. > > -Ekr > > > > > > > > > > On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd > wrote: > > On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner > wrote: > > Hi, > > > > Just wanted to remind everybody that we’ve got two non-TLS1.3 > items we’re looking for WG input on: > > > > - Before 12 July, we’d like to know your thoughts about > progressing draft-ietf-tls-pwd (Watson and ekr responded): > > > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 > > > > > - Before 14 July, we’d like to know your thoughts on the > proposed AUTH48 proposed changes (nobody has commented on this): > > > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk > > > I don't like the AUTH48 changes. I understand the need for changing to > MAY, but the proposed method of distinguishing offends my > sensibilities. Overloading the length field is just ugly. > > > > > spt > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > 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 --------------060502000801020608070704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I also don't like the AUTH48 changes -- there's no protocol-level reason to weaken the MUST, since a server that can't handle the extra state/processing can just not implement the extension at all.

-Ben

On 07/11/2016 10:34 AM, Eric Rescorla wrote:
I agree with Watson's assessment here. This seems like the wrong design choice.

I'm not familiar with OpenSSL's cert selection, but I don't believe that the issue
that this change is intended to address applies to NSS, for two reasons:

1. NSS does cert selection during client hello processing [0].

2. Unless I misunderstand the design of cached-info, all the server needs
to have is the digest of the serialized chain and it could store that at the time
that it configures the cert (or first uses it). This seems like quite a small burden.

I believe the prior design was superior.

-Ekr









On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <sean@sn3rd.com> wrote:
> Hi,
>
> Just wanted to remind everybody that we’ve got two non-TLS1.3 items we’re looking for WG input on:
>
> - Before 12 July, we’d like to know your thoughts about progressing draft-ietf-tls-pwd (Watson and ekr responded):
> https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
>
> - Before 14 July, we’d like to know your thoughts on the proposed AUTH48 proposed changes (nobody has commented on this):
> https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk

I don't like the AUTH48 changes. I understand the need for changing to
MAY, but the proposed method of distinguishing offends my
sensibilities. Overloading the length field is just ugly.

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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

_______________________________________________
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

--------------060502000801020608070704-- From nobody Mon Jul 11 09:59:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5080F12D5A8 for ; Mon, 11 Jul 2016 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZSrnrBAOgwC for ; Mon, 11 Jul 2016 09:59:34 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898CF128E18 for ; Mon, 11 Jul 2016 09:59:34 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id s63so62796681qkb.2 for ; Mon, 11 Jul 2016 09:59:34 -0700 (PDT) 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-transfer-encoding:message-id; bh=iT+FW5qbqioTSllYebxcvNb7cUWvljBXS/vnO9ctleo=; b=pDbv6ze2xwWLF15AuP7Q6zqIqSnbgSo1wqBCqRVSDh+HrXHGxKPKwq/el0kQbjA/Un 5uBVTDP553v/Yy54rBBsWOkYrzwdmUSGtXaG6s4Or2TQXbcoJ4qCrzck0IIICS6Er16v FVcIdp/loBOw56al7Ac7Mncwzx1XJjdRbI/ixrCgOxHz5Y8GnRKp+mCUdBUv/MswK0X9 3XXEbC6kfMRpvE9op3SrmJmnHPHVoj2LDV32C40bbrdUz4KkMnMFFWdjArT107+/GyKm etJ921Rv/xT7wmikwdgfSdQqRdPDk1wuStnS1YBLAVHpnFGl78lZ5f8DeAI0f3BdBG++ Mb3A== 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-transfer-encoding:message-id; bh=iT+FW5qbqioTSllYebxcvNb7cUWvljBXS/vnO9ctleo=; b=MDKJ8cpJqReEI2XzQ27WIZ44ycW1LJ9E3Blz7nUiUa9aUx8yyuOXvHcZQvbDjCHQ8x oYida83N0mnL7aVq99m59As59F1yaUUxCLqYJghkRZdhg8dYCgMuaob1X2p7EENUSk1h XD1vL1wn+TpkzGaovuPJVSjSKOTLG1WMJNM9SPQXYZaFRmnHq5iVW95BPBSRps5FZHr1 1buTqPiLJGcDkQqgUSc13zKLhSd9wWLPiXovcV2VzJsrjqyhgicoowocDGmn1PcF0zq9 DLGmIUG+nzfbFUuCMXRKf88idcVLHNvbKHHElVxTNUlu8PgfAQjEKuZjIz/YFauBOea6 mjsw== X-Gm-Message-State: ALyK8tKS8Ip1SYPbJ2l1wAyfHuG53gjjtd+hXUmyL344XkxZRLJ26STrrBHQ642eeCw34A== X-Received: by 10.55.22.154 with SMTP id 26mr26645996qkw.193.1468256364396; Mon, 11 Jul 2016 09:59:24 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id f53sm2869980qtf.25.2016.07.11.09.59.23 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jul 2016 09:59:23 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 11 Jul 2016 12:59:21 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> In-Reply-To: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201607111259.22367.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:59:36 -0000 On Monday, July 11, 2016 10:27:21 am Sean Turner wrote: > - Before 12 July, we=E2=80=99d like to know your thoughts about progressi= ng draft-ietf-tls-pwd (Watson and ekr responded): > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 This document defines new cipher suites using obsolete crypto. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-5 : > This memo adds the following ciphersuites: > > CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA =3D ( TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 =3D (TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 =3D (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 =3D (TBD, TBD ); > > Implementations conforming to this specification MUST support the > TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support > TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA, > TLS_ECCPWD_WITH_AES_128_GCM_SHA256, > TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining > ciphersuites. Most of those should not be defined in any new document approved by this WG= , let alone one based on a low entropy secret. In particular, the SHA1 suit= es shouldn't be there, and the CBC suites should be scrapped as well. The s= pec allows for these suites to be negotiated with TLS 1.0-1.1 (hence the CB= C), which should just be dropped to focus on TLS 1.2 & TLS 1.3+. The MTI is= not even supported by TLS 1.3. Don't define new crypto systems using obsol= ete crypto systems. I don't see how we could expect any implementations tha= t don't even support TLS 1.2 to implement something new like this, anyway. = If this draft moves forward in any way, it should be reduced to AES 128/256= GCM/CCM, with possible addition of a ChaCha/Poly suite. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-1.1 : >1.1. The Case for Certificate-less Authentication > > TLS usually uses public key certificates for authentication > [RFC5246]. This is problematic in some cases: > > o Frequently, TLS [RFC5246] is used in devices owned, operated, and > provisioned by people who lack competency to properly use > certificates and merely want to establish a secure connection > using a more natural credential like a simple password. The > proliferation of deployments that use a self-signed server > certificate in TLS [RFC5246] followed by a PAP-style exchange over > the unauthenticated channel underscores this case. [...] If we're setting up new systems to lower the barrier to entry, ACME is the = way to go, not this. Dave From nobody Mon Jul 11 12:08:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E26D12D6A2 for ; Mon, 11 Jul 2016 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEqIr89i6m7H for ; Mon, 11 Jul 2016 12:08:41 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 239BC12D698 for ; Mon, 11 Jul 2016 12:08:41 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id i12so100384661ywa.1 for ; Mon, 11 Jul 2016 12:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=prqOa46+y/U4gOIhD4ne2vDLcDfDcpIrEntFRAU3pXM=; b=qw43tfV7hRB+3lUkwievx+EIePXD4TYhGSviUDm0jW/5gDxuyqdpiqiTjFDQ3N4BOP Izfx4lRPBAOYExBkMJI13f/waVOk7ck8pNZsTuLRKKF3eljYwvz3hD2pKlKnLC2TdniE EkUbVOlqkI0Ja+5NI8nhHFKsRLzUuT2kk04xSq0ZW/Zj8xBaGerdpslWHJbg0P+IFsTe l6tqUO4Yylzbgq5zmpJHigKSSaKypCRPq9qgzWY2YZ0+cvmKw4HUOO9Hzec/3lacTjgK q69+Qgv0wBzqX46mWh5PRjtcX9wwhkxbi16z+Us9dsJ7bQdeoxUCGQ+4W80FrRgS/34M N1yA== 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; bh=prqOa46+y/U4gOIhD4ne2vDLcDfDcpIrEntFRAU3pXM=; b=NBOczkgh05yo8F1TOhcOkkZlpoZVtcK5KfI27oeLIWNsC4evp0ZJsxt1uHlVcE0sSd tDMO8yguPKaRLbSMCedWVvz3B4CW5TVfs8G/oCY59GsfDtQWm0VbZxhl82wIRCC0H1CF z2MWdcPQY+dUvPmHDq2fdXHf1tYgmzzaMv6mTq7AQ4svjipBL3voCCXirbaOB7g0DD6x OUZ7D39FfrAUq8HJ8GAna3HpImhPVhpO3f2RFy0YSdJ4tVqDcWISs9mbXz4bPFa03Bx/ AdzXTUVM7bQU9ch0m7rajYlsQsbyLaDXq/VXGxW2D5AwxQe9+0Q1nuadEQZ8l5cVVaLr oDRg== X-Gm-Message-State: ALyK8tIT7ObftG+KzZ4LDqV+SN/8kcq9fBax8Lw4WTqLNx2D4bFXMRycFcxziEmwBbqOj3OPmGsk6lKHHZuVDQ== X-Received: by 10.13.199.68 with SMTP id j65mr14889556ywd.289.1468264120106; Mon, 11 Jul 2016 12:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 11 Jul 2016 12:08:00 -0700 (PDT) From: Eric Rescorla Date: Mon, 11 Jul 2016 12:08:00 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114dfc4a512736053760e11f Archived-At: Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:08:42 -0000 --001a114dfc4a512736053760e11f Content-Type: text/plain; charset=UTF-8 Folks, I've just submitted draft-ietf-tls-tls13-14.txt and it should show up on the draft repository shortly. In the meantime you can find the editor's copy in the usual location at: http://tlswg.github.io/tls13-spec/ The major changes in this document are: * A big restructure to make it read better. I moved the Overview to the beginning and then put the document in a more logical order starting with the handshake and then the record and alerts. * Totally rewrote the section which used to be called "Security Analysis" and is now called "Overview of Security Properties". This section is still kind of a hard hat area, so PRs welcome. In particular, I know I need to beef up the citations for the record layer section. * Removed the 0-RTT EncryptedExtensions and moved ticket_age into the ClientHello. This quasi-reverts a change in -13 that made implementation of 0-RTT kind of a pain. As usual, comments welcome. -Ekr * Allow cookies to be longer (*) * Remove the "context" from EarlyDataIndication as it was undefined and nobody used it (*) * Remove 0-RTT EncryptedExtensions and replace the ticket_age extension with an obfuscated version. Also necessitates a change to NewSessionTicket (*). * Move the downgrade sentinel to the end of ServerHello.Random to accomodate tlsdate (*). * Define ecdsa_sha1 (*). * Allow resumption even after fatal alerts. This matches current practice. * Remove non-closure warning alerts. Require treating unknown alerts as fatal. * Make the rules for accepting 0-RTT less restrictive. * Clarify 0-RTT backward-compatibility rules. * Clarify how 0-RTT and PSK identities interact. * Add a section describing the data limits for each cipher. * Major editorial restructuring. * Replace the Security Analysis section with a WIP draft. (*) indicates changes to the wire protocol which may require implementations to update. --001a114dfc4a512736053760e11f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just submitt= ed draft-ietf-tls-tls13-14.txt and it should
show up on the draft= repository shortly. In the meantime you
can find the editor'= s copy in the usual location at:


The major changes in this document are:

* A big restructure to make it read better. I moved the Ove= rview
=C2=A0 to the beginning and then put the document in a more= logical
=C2=A0 order starting with the handshake and then the re= cord and
=C2=A0 alerts.

* Totally rewrot= e the section which used to be called "Security
=C2=A0 Analy= sis" and is now called "Overview of Security Properties".
=C2=A0 This section is still kind of a hard hat area, so PRs welcom= e.
=C2=A0 In particular, I know I need to beef up the citations f= or the
=C2=A0 record layer section.

* Re= moved the 0-RTT EncryptedExtensions and moved ticket_age
=C2=A0 i= nto the ClientHello. This quasi-reverts a change in -13 that
=C2= =A0 made implementation of 0-RTT kind of a pain.

A= s usual, comments welcome.
-Ekr



* Allow cookies to be longer (*)

=
* Remove the "context" from EarlyDataIndication as it was un= defined
=C2=A0 and nobody used it (*)

* = Remove 0-RTT EncryptedExtensions and replace the ticket_age extension
=
=C2=A0 with an obfuscated version. Also necessitates a change to
=
=C2=A0 NewSessionTicket (*).

* Move the downg= rade sentinel to the end of ServerHello.Random
=C2=A0 to accomoda= te tlsdate (*).

* Define ecdsa_sha1 (*).

* Allow resumption even after fatal alerts. This matches cu= rrent
=C2=A0 practice.

* Remove non-clos= ure warning alerts. Require treating unknown alerts as
=C2=A0 fat= al.

* Make the rules for accepting 0-RTT less rest= rictive.

* Clarify 0-RTT backward-compatibility ru= les.

* Clarify how 0-RTT and PSK identities intera= ct.

* Add a section describing the data limits for= each cipher.

* Major editorial restructuring.

* Replace the Security Analysis section with a WIP dr= aft.

(*) indicates changes to the wire protocol wh= ich may require implementations
=C2=A0 =C2=A0 to update.

--001a114dfc4a512736053760e11f-- From nobody Mon Jul 11 12:39:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2E12D0EC for ; Mon, 11 Jul 2016 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua3H-7zTZ86B for ; Mon, 11 Jul 2016 12:39:49 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3E712D19E for ; Mon, 11 Jul 2016 12:39:46 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id 38so16097372iol.0 for ; Mon, 11 Jul 2016 12:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=w8v+y1ngR2vrKUl2NtSDhBr+Nk2OmKZCXUZD89a5DWQ=; b=hU/pE96vdAtNkWCxgj+ZEmjw9FNxiYveNZfa8RYyXwGh8wbsA0k5MlMZoqBcOwHwbc 1rSvgHjjGXCM6ipNxc6OIPlnvejOrskwolhQ7+36Y9N7Qo0Rfhnwyb76e7hexLRmXfMd XmR+dljgXi8LXpLZWVibHwshbuTltR2x3avMaM6xG+/Rxa7vc2GaON1nA+uc6UjnTOhi HFj+XynzQu8kF+T0HtKl/UnxsPl47mP0Qb/FbO7SdH1BPFE0G1E/m+7PgdWQqH3vE8JA CaXGmcfmWRrxBWGCXPZ6CpSD9ltxdclEEC58vgMYcVOrncGUCBMc0hqBmKn43R99Tk3P BgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=w8v+y1ngR2vrKUl2NtSDhBr+Nk2OmKZCXUZD89a5DWQ=; b=BQ8o2NDganrp7MbvrAq0WYeT1QpvG6LWvHJq4W68geUo2ixhKUKll+UBnOT3P/iS1m enDW650/JP10+byZPbKJfSpv3bDUp6ubwatP1RN6QInPP0kDPupThgzP0wxL5glt+kfU EALZ+DMHKlUnSnqk/KQq/XcYoSoW5uz58gH71wZYqo0c4LKl8LqhlEsCSGGVEzFZW4aX FwP7IDIbAsNo7cswmIBj2F8w8Grnbt2crP53IYUsAdVW680GMnnQ4hhOvA5suxtm88yw SuqtEkXFgbvS6TGW1nb2qEl5wJJabfm0qPHNrYyqXRHlnVmej64LKzi50RBgqgPdEdH8 +QxA== X-Gm-Message-State: ALyK8tIMi3B6sGWSKjiRp/CiY9M80en70WGAHMlcj+NEhFSJbCHdnPiPO0wu92J16lScvw== X-Received: by 10.107.187.196 with SMTP id l187mr23711314iof.28.1468265985557; Mon, 11 Jul 2016 12:39:45 -0700 (PDT) Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id m70sm8105450itm.1.2016.07.11.12.39.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 12:39:44 -0700 (PDT) From: Douglas Stebila Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 11 Jul 2016 15:39:43 -0400 To: "tls@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:39:50 -0000 Some of the discussions I've had with people about post-handshake client = authentication have raised the question of whether application traffic = secrets should be updated automatically upon post-handshake client = authentication: the thinking being that every change in context should = be accompanied by a change in keying material. I used to think that was = a good idea for TLS 1.3, although it was recently argued to me that if = we view the application traffic secrets as being "internal" to the TLS = protocol, then the change in client authentication status doesn't change = the confidential or integrity properties of the record layer, it just = serves as a "marker" to the application that certain portions of the = application data were associated with certain authentication contexts. = I was convinced that this can be safely accomplished without a change in = application traffic secret key material. But I'm not sure that the same applies to *exporter* keys. Should = exported keying material change as the authentication context changes? Consider a long-lived TLS connection, where different users come and go. = For example, a web browser on a public terminal may have established a = long-lived TLS connection to a particular website, and send subsequent = requests to the same website over the same TLS connection. Now imagine = two users use the terminal one after another: 1: initial handshake on a public terminal 2: [time passes] 3: Alice starts browsing 4: Alice does post-handshake client authentication 5: Alice purchases something 6: Alice hits "logout" at the application layer 7: [time passes] 8: Bob starts using the terminal 9: Bob does post-handshake client authentication 10: Bob purchases something 11: Bob hits "logout" at the application layer TLS 1.3 will tell the application about events 4 and 9. Events 6 and 11 = happen at the application layer rather than the TLS layer (since I don't = think TLS 1.3 has a client-de-authentication option). But putting this = all together, the application will learn all the correct authentication = contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, = 11-onwards is anonymous. Now imagine that we use keying material exporters in on lines 5 and 10: 1: initial handshake on a public terminal 2: [time passes] 3: Alice starts browsing 4: Alice does post-handshake client authentication *5: Alice presses the "export keying material" button 6: Alice hits "logout" at the application layer 7: [time passes] 8: Bob starts using the terminal 9: Bob does post-handshake client authentication *10: Bob presses the "export keying material" button 11: Bob hits "logout" at the application layer Since the exporter master secret is not updated when client = authentication changes, Alice and Bob will export the same keying = material at steps 5 and 10. If the intended goal of this exported key = is for Alice to obtain confidentiality in some other use, this will not = be achieved, since Bob will obtain the same exported key. Now, a proviso is that RFC 5705 allows for the application to mix a = "context value" into the export, which could mitigate this, but that is = optional. So it seems to me like in at least some scenarios, exported keying = material should be associated with authentication context. It is less = clear to me if the same holds true for KeyUpdates. Douglas= From nobody Mon Jul 11 12:41:38 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 8726212D5CF; Mon, 11 Jul 2016 12:41:36 -0700 (PDT) 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.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160711194136.9322.19630.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2016 12:41:36 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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 Jul 2016 19:41:36 -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 of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-14.txt Pages : 116 Date : 2016-07-11 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 11 13:26:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8772412D0E8 for ; Mon, 11 Jul 2016 13:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvXrP4ws8ZvJ for ; Mon, 11 Jul 2016 13:26:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD012D0E4 for ; Mon, 11 Jul 2016 13:26:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 805811FE02C8; Mon, 11 Jul 2016 13:26:41 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Jul 2016 13:26:42 -0700 (PDT) Message-ID: <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> In-Reply-To: <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> Date: Mon, 11 Jul 2016 13:26:42 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" 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] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:26:43 -0000 I'm glad I have to opportunity to make you happy Sean :-) On Mon, July 11, 2016 7:40 am, Sean Turner wrote: > I think I can take this bit: > > On Jul 10, 2016, at 06:51, Peter Dettman > wrote: >> >> I'm also curious whether there is a precedent in other RFCs for an >> explicit minimum curve bits, or perhaps a de facto implementer's rule? > > I'd be happy to be wrong here. but to my knowledge no there's not been > an explicit minimum for curve bits. There have however been similar (at > least in my non-cryptographer mind) for RSA key sizes so if we wanted to > define an explicit minimum curve bits then we could. draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring the curves used provide commensurate strength with the ciphersuite negotiated. Section 10, "Implementation Considerations", says: It is RECOMMENDED that implementations take note of the strength estimates of particular groups and to select a ciphersuite providing commensurate security with its hash and encryption algorithms. A ciphersuite whose encryption algorithm has a keylength less than the strength estimate, or whose hash algorithm has a blocksize that is less than twice the strength estimate SHOULD NOT be used. And I would like to take this opportunity to remind everyone that the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant to dictionary attack and the former is not. regards, Dan. From nobody Mon Jul 11 15:28:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C112B03B for ; Mon, 11 Jul 2016 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ey/aoPmR; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TKbRbvTT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl5ZWg9JumE1 for ; Mon, 11 Jul 2016 15:27:56 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 3C27012B02A for ; Mon, 11 Jul 2016 15:27:56 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6BMPL6s021868; Mon, 11 Jul 2016 15:27:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=hre0gDDnzH5esMQr3bHfMYmdMxqLYbmb6591cTCEMTw=; b=ey/aoPmR/PyfvqsY1k1FWcNnd4UiKqO6qaRcIp8xTKddMqWsi0/6MQUPjojRDnXRE8KO KQZY+s1KoPkJM/OQ8kKU1MByCBz2VxpLfZ9X7F9YpwK+ua9st7zgTZUNx17k556yh4x/ V7ke6IwpRAsU5d8VOufjqnmZ7+K0hySetoE= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 244jaf8rqm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2016 15:27:55 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 11 Jul 2016 18:27:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hre0gDDnzH5esMQr3bHfMYmdMxqLYbmb6591cTCEMTw=; b=TKbRbvTTsHJssUex81s1wE5g+6bZEfAZl4sayJA+tCc0a4BwhW2WwjgDwT2nTmqrSkL/XR0y5FCDeaBWFWpk8IzScpJKu6cSPi4u84dU2eZsAZ0Ppm2mP81khdnb+NVvcW6BjKvWt/2qR5pWUYAtsq0ZAH3WLX4uDkb78hWF2h4= Received: from BL2PR15MB1058.namprd15.prod.outlook.com (10.167.116.154) by BL2PR15MB1058.namprd15.prod.outlook.com (10.167.116.154) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 11 Jul 2016 22:27:52 +0000 Received: from BL2PR15MB1058.namprd15.prod.outlook.com ([10.167.116.154]) by BL2PR15MB1058.namprd15.prod.outlook.com ([10.167.116.154]) with mapi id 15.01.0534.013; Mon, 11 Jul 2016 22:27:52 +0000 From: Anirudh Ramachandran To: "" Thread-Topic: [TLS] Reminders Thread-Index: AQHR28HpJEy/g6oSVkSS1RwlP1cD7KATWg0A Date: Mon, 11 Jul 2016 22:27:52 +0000 Message-ID: <499E2873-99F1-47A9-A7B7-BCA529A1A3C0@fb.com> References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2620:10d:c090:180::1:171e] x-ms-office365-filtering-correlation-id: 840f9ddd-822b-4174-fdf2-08d3a9da98fc x-microsoft-exchange-diagnostics: 1; BL2PR15MB1058; 20:4kODzcUsx1ynpuaO9GvUW2e1+mHQ+aVm7+6JYZfBqcOOjgvB1+ouSbgfzZ4zDxMN0nAXEaH8bNEPNDyvLcOPNzWDah6yhPO3+mxUrzh3CT3uWnO5ti7AmPj/20tSyuP/g/IjIgJx6rbCSIut3xHCKGAlF9Kd1nb2XRDWGnoF1Jo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR15MB1058; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BL2PR15MB1058; BCL:0; PCL:0; RULEID:; SRVR:BL2PR15MB1058; x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(199003)(189002)(12213003)(86362001)(11100500001)(106116001)(4326007)(105586002)(82746002)(101416001)(16236675004)(106356001)(5002640100001)(76176999)(189998001)(97736004)(122556002)(7736002)(87936001)(50986999)(2900100001)(19625215002)(68736007)(36756003)(54356999)(93886004)(10400500002)(3280700002)(19300405004)(81166006)(8676002)(15975445007)(81156014)(99286002)(19580405001)(77096005)(3660700001)(110136002)(102836003)(6116002)(92566002)(8936002)(586003)(2906002)(2950100001)(19580395003)(7846002)(83716003)(33656002)(3826002)(104396002)(42262002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR15MB1058; H:BL2PR15MB1058.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_499E287399F147A9A7B7BCA529A1A3C0fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 22:27:52.1991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR15MB1058 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-11_14:, , signatures=0 Archived-At: Subject: Re: [TLS] Reminders X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:27:58 -0000 --_000_499E287399F147A9A7B7BCA529A1A3C0fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTW9uLCBKdWwgMTEsIDIwMTYgYXQgOToxNiBBTSwgRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVu QGNocm9taXVtLm9yZzxtYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnPj4gd3JvdGU6DQoNCj4g T3BlblNTTCBkZXRlcm1pbmVzIHdoaWNoIGNlcnRpZmljYXRlIHRvIHVzZSBkdXJpbmcgQ2xpZW50 SGVsbG8gcHJvY2Vzc2luZywgYnV0IGl0IGhhcyBhIG1vZGUgd2hlcmUsIGlmIGludGVybWVkaWF0 ZXMgd2VyZSBub3QgZXhwbGljaXRseSBjb25maWd1cmVkIGFuZCBvbmx5IGEgbGVhZiwgaXQgcGF0 aC1idWlsZHMgcmlnaHQgYmVmb3JlIHNlbmRpbmcgdGhlIENlcnRpZmljYXRlIG1lc3NhZ2UuIEJ1 dCBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSBpdCBjYW4ndCBiZSBjaGFuZ2VkIHRvIGNvbXB1 dGUgdGhpcyBlYXJsaWVyLg0KDQpDb3JyZWN0LCBPcGVuU1NMJ3MgbGF0ZSBjb21wdXRhdGlvbiBv ZiB0aGUgY2hhaW4sIHBsdXMgb3RoZXIgZGVzaWduIGRlY2lzaW9ucyAob25lLXN0YXRlLWF0LWEt dGltZSwgc2FtZSBidWZmZXIgZm9yIGV2ZXJ5dGhpbmcsIGV0YykgaXMgdGhlIHJlYXNvbiBJIHBy b3Bvc2VkIHRoZSBjaGFuZ2UuIFNpbmNlIHRoZSBkcmFmdCByZXF1aXJlcyBjYWNoZWQtaW5mbyB0 byBiZSB0aGUgaGFzaCBvZiB0aGUgc2VyaWFsaXplZCBjaGFpbiByYXRoZXIgdGhhbiBpbmRpdmlk dWFsIGNlcnRzLCBpdCBkb2VzIHJlcXVpcmUgdGhlIHNlcmlhbGl6YXRpb24gY29kZSB0byBiZSBy dW4gb3V0c2lkZSBvZiB0aGUgdXN1YWwgc3RhdGUgbWFjaGluZSBjb2RlcGF0aCwgd2hpY2ggaXMg YWxzbyBjdW1iZXJzb21lLg0KDQpUaGUgTUFZIGluc3RlYWQgb2YgTVVTVCBtYWtlcyB0aGUgc2Vy dmVyLXNpZGUgaW1wbGVtZW50YXRpb24gYWxtb3N0IHBsdWctaW4gLSBzZXJpYWxpemF0aW9uIGhh cHBlbnMgYXMgbm9ybWFsIGFuZCB0aGUgc2VyaWFsaXplZCBtZXNzYWdlIGlzIHJlcGxhY2VkIGlm IGl0IG1hdGNoZXMgYSBjYWNoZWQtaW5mby4gVGhlIGNsaWVudCBzaWRlIGltcGxlbWVudGF0aW9u IG9ubHkgc2xpZ2h0bHkgbW9yZSBjb21wbGljYXRlZCAtIGNoZWNrIGZpcnN0IGZvciBhIGxlbmd0 aCBtYXRjaCBhbmQgdGhlbiBhIGNhY2hlZC1pbmZvIG1hdGNoIChuZWVkZWQgYW55d2F5KTsgaWYg ZWl0aGVyIGZhaWwsIHRoZSBjbGllbnQgdHJlYXRzIHRoZSBtZXNzYWdlIGFzIGEgbm9ybWFsIGNl cnRpZmljYXRlLg0KDQpIYXZpbmcgYW5vdGhlciB3YXkgdG8gaW5kaWNhdGUgdGhpcyBiZXNpZGVz IGxlbmd0aCB3b3VsZCBzdWZmaWNlIHRvbywgYnV0IEknbSBmaW5lIHdpdGggbm90IGNoYW5naW5n IHRoZSBkcmFmdCBlaXRoZXIgaWYgdGhhdCdzIHdoYXQgZXZlcnlvbmUgZmVlbHMuDQoNCi0tDQpB bmlydWRoDQo= --_000_499E287399F147A9A7B7BCA529A1A3C0fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <08FB360E9DD3314CBEC4C6AB0AF2EE8F@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3Mzc5MzkxMTA7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgwODc1MzM3NCAt MTg5NDE5MDU4MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28t YmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjojMjIyMjIyO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjExNDUxOTg2 MTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk3MTU0 ODU0IC0xNjY5Njk2NjgyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouMjVpbjsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9y OiMyMjIyMjI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjEuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My4yNWluOw0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQu MjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPk9uIE1vbiwgSnVsIDExLCAyMDE2IGF0IDk6MTYgQU0sIERh dmlkIEJlbmphbWluJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+ZGF2aWRiZW5A Y2hyb21pdW0ub3JnPC9zcGFuPjwvYT4mZ3Q7Jm5ic3A7d3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMyMjIyMjIiPiZndDsg T3BlblNTTCBkZXRlcm1pbmVzIHdoaWNoIGNlcnRpZmljYXRlIHRvIHVzZSBkdXJpbmcgQ2xpZW50 SGVsbG8gcHJvY2Vzc2luZywgYnV0IGl0IGhhcyBhIG1vZGUgd2hlcmUsIGlmIGludGVybWVkaWF0 ZXMgd2VyZSBub3QgZXhwbGljaXRseSBjb25maWd1cmVkIGFuZCBvbmx5IGEgbGVhZiwgaXQgcGF0 aC1idWlsZHMgcmlnaHQgYmVmb3JlDQogc2VuZGluZyB0aGUgQ2VydGlmaWNhdGUgbWVzc2FnZS4g QnV0IEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IGl0IGNhbid0IGJlIGNoYW5nZWQgdG8gY29t cHV0ZSB0aGlzIGVhcmxpZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpB cmlhbDtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMyMjIyMjIiPkNvcnJlY3QsIE9wZW5TU0wncyBsYXRlIGNvbXB1 dGF0aW9uIG9mIHRoZSBjaGFpbiwgcGx1cyBvdGhlciBkZXNpZ24gZGVjaXNpb25zIChvbmUtc3Rh dGUtYXQtYS10aW1lLCBzYW1lIGJ1ZmZlciBmb3IgZXZlcnl0aGluZywgZXRjKSBpcyB0aGUgcmVh c29uIEkgcHJvcG9zZWQgdGhlIGNoYW5nZS4NCiBTaW5jZSB0aGUgZHJhZnQgcmVxdWlyZXMgY2Fj aGVkLWluZm8gdG8gYmUgdGhlIGhhc2ggb2YgdGhlIHNlcmlhbGl6ZWQgY2hhaW4gcmF0aGVyIHRo YW4gaW5kaXZpZHVhbCBjZXJ0cywgaXQgZG9lcyByZXF1aXJlIHRoZSBzZXJpYWxpemF0aW9uIGNv ZGUgdG8gYmUgcnVuIG91dHNpZGUgb2YgdGhlIHVzdWFsIHN0YXRlIG1hY2hpbmUgY29kZXBhdGgs IHdoaWNoIGlzIGFsc28gY3VtYmVyc29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzIyMjIyMiI+VGhlIE1BWSBpbnN0ZWFkIG9mIE1V U1QgbWFrZXMgdGhlIHNlcnZlci1zaWRlIGltcGxlbWVudGF0aW9uIGFsbW9zdCBwbHVnLWluIC0g c2VyaWFsaXphdGlvbiBoYXBwZW5zIGFzIG5vcm1hbCBhbmQgdGhlIHNlcmlhbGl6ZWQgbWVzc2Fn ZSBpcyByZXBsYWNlZCBpZiBpdCBtYXRjaGVzIGENCiBjYWNoZWQtaW5mby4gVGhlIGNsaWVudCBz aWRlIGltcGxlbWVudGF0aW9uIG9ubHkgc2xpZ2h0bHkgbW9yZSBjb21wbGljYXRlZCAtIGNoZWNr IGZpcnN0IGZvciBhIGxlbmd0aCBtYXRjaCBhbmQgdGhlbiBhIGNhY2hlZC1pbmZvIG1hdGNoIChu ZWVkZWQgYW55d2F5KTsgaWYgZWl0aGVyIGZhaWwsIHRoZSBjbGllbnQgdHJlYXRzIHRoZSBtZXNz YWdlIGFzIGEgbm9ybWFsIGNlcnRpZmljYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMjIyMjIyIj5IYXZpbmcgYW5vdGhlciB3YXkg dG8gaW5kaWNhdGUgdGhpcyBiZXNpZGVzIGxlbmd0aCB3b3VsZCBzdWZmaWNlIHRvbywgYnV0IEkn bSBmaW5lIHdpdGggbm90IGNoYW5naW5nIHRoZSBkcmFmdCBlaXRoZXIgaWYgdGhhdCdzIHdoYXQg ZXZlcnlvbmUgZmVlbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFuaXJ1ZGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_499E287399F147A9A7B7BCA529A1A3C0fbcom_-- From nobody Mon Jul 11 16:24:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B412D66B for ; Mon, 11 Jul 2016 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UZvw_x-n5ol for ; Mon, 11 Jul 2016 16:24:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C0212D1D3 for ; Mon, 11 Jul 2016 16:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4B2O4ztNfI7TRGD7GsiOP0EaSv+r2nBnGHblS75xMbo=; b=S+Xeq4AidkeFFtZRwDzyl12Q0Xl80ynFL2j4L/2zdwaaLXT/yWtvhO2ULajhSLYzHp/XF9FjS4B/TK7XWKnChkGFDIMQH4gYWpsgCTgef6+QhZBjli/vZyxqauVLyL5PjgY3YGwoJC0UF9epZNXTFkMw8TmMmn85il7oyDHP3vA= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Mon, 11 Jul 2016 23:24:30 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.022; Mon, 11 Jul 2016 23:24:30 +0000 From: Andrei Popov To: Douglas Stebila , "tls@ietf.org" Thread-Topic: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? Thread-Index: AQHR26wJxPHbdy3C0U+IgpZY4K5NtqAT3JCg Date: Mon, 11 Jul 2016 23:24:30 +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:7::1d2] x-ms-office365-filtering-correlation-id: 87f7089e-76bd-4c9d-f9a2-08d3a9e28245 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:tvhvHxaZVUBYSU24lxcMgr7PgVy1UN20ywUJyev/oFO6a/c75t0ngK6dKbIHXPEA7Wibfm8JZbAgX3Mfc3L0mVCLB2q+8TbbJpiCliHT9179gHKYkeyj7F2qQbzG4lLvH/1fwdGEsqI7hv2V0Y0O3KqKxakgcmQxBPn04ldpGGR76inOlVuyzIvPc/HOhUN7kYBTyXQ9rlax0It1fR1canVqJ7Nec3cDOY/hq3SD9kmi7X6k17TQV6M17kb4m8xygcmIaSXrWIzQjpErANH4K6UvALytuX6YknGOi0/CdHvJ7iwg1267fD7mTshg9V4NfzsPFfb+4cAG7nDaai3PuA==; 5:C4TMDFKqD7RzDPs3aLSVQ5hHn0Mhg2fAIG6fyPK2cP9UlB/v0eKW+DP6PryKj+h9gdLvU98pqHEC1yfy2yhha2U1p6raBqj39pYdgFVCGA4k8vL5XCWx7rI0ocTQKiNBJigUCNohoTPK6AQaHN1pRg==; 24:Rd6mjonny/BNxIADthfSETEyHN1HpfgxbRFOhUeZo8lEdW08n2aNdbYGX9qmsNf6c8sVyaQfRdhCn/xsW2U37dIwx6AIaIp1E8Hto6GRhTU=; 7:7k67t+/2+bt2JKgzeIALQMn4ZI0xuYVs7bRzWrPdLMWWjdVp4qgRmT80iB7LkvFMWz1uNDOSETY7Akvjkxhtplpqm+5CUeyxYPmvq71VMWKQfA23K0z3LmLqNiQ0guKjTYTiBm/e/6ougC7OhNWQs0DGe3VXjBWAPhPj42WGMx1CzGE+5h8qpJOADGz29G+TIKLkQ52EB1m5x7grkX0t5l6kuI6Y2hGt0hZ7AD0NCK6dHKaX8Re+xQCTDxVQVfwc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(5005710100001)(87936001)(5002640100001)(10400500002)(77096005)(33656002)(10290500002)(86612001)(3660700001)(101416001)(97736004)(106116001)(11100500001)(105586002)(10090500001)(9686002)(189998001)(76176999)(5001770100001)(54356999)(68736007)(2906002)(86362001)(76576001)(2900100001)(106356001)(8990500004)(7736002)(81156014)(81166006)(7846002)(5003600100003)(8676002)(102836003)(6116002)(15650500001)(305945005)(8936002)(74316002)(7696003)(92566002)(50986999)(107886002)(19580405001)(19580395003)(99286002)(122556002)(3280700002)(2950100001)(586003)(2501003)(15975445007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.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:99 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 Jul 2016 23:24:30.1117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 23:24:34 -0000 Hi Douglas, As currently defined, post-handshake client auth allows the same client to = present different identities, but not to repudiate a previously presented i= dentity. So in your example, from the TLS perspective, the client is both A= lice and Bob, and therefore I think the same EKM value makes sense. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila Sent: Monday, July 11, 2016 12:40 PM To: tls@ietf.org Subject: [TLS] Should exporter keys be updated with post-handshake authenti= cation and/or KeyUpdate? Some of the discussions I've had with people about post-handshake client au= thentication have raised the question of whether application traffic secret= s should be updated automatically upon post-handshake client authentication= : the thinking being that every change in context should be accompanied by = a change in keying material. I used to think that was a good idea for TLS = 1.3, although it was recently argued to me that if we view the application = traffic secrets as being "internal" to the TLS protocol, then the change in= client authentication status doesn't change the confidential or integrity = properties of the record layer, it just serves as a "marker" to the applica= tion that certain portions of the application data were associated with cer= tain authentication contexts. I was convinced that this can be safely acco= mplished without a change in application traffic secret key material. But I'm not sure that the same applies to *exporter* keys. Should exported= keying material change as the authentication context changes? Consider a long-lived TLS connection, where different users come and go. F= or example, a web browser on a public terminal may have established a long-= lived TLS connection to a particular website, and send subsequent requests = to the same website over the same TLS connection. Now imagine two users us= e the terminal one after another: 1: initial handshake on a public terminal 2: [time passes] 3: Alice starts browsing 4: Alice does post-handshake client authentication 5: Alice purchases something 6: Alice hits "logout" at the application layer 7: [time passes] 8: Bob starts using the terminal 9: Bob does post-handshake client authentication 10: Bob purchases something 11: Bob hits "logout" at the application layer TLS 1.3 will tell the application about events 4 and 9. Events 6 and 11 ha= ppen at the application layer rather than the TLS layer (since I don't thin= k TLS 1.3 has a client-de-authentication option). But putting this all tog= ether, the application will learn all the correct authentication contexts: = 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards i= s anonymous. Now imagine that we use keying material exporters in on lines 5 and 10: 1: initial handshake on a public terminal 2: [time passes] 3: Alice starts browsing 4: Alice does post-handshake client authentication *5: Alice presses the "export keying material" button 6: Alice hits "logout" at the application layer 7: [time passes] 8: Bob starts using the terminal 9: Bob does post-handshake client authentication *10: Bob presses the "export keying material" button 11: Bob hits "logout" at the application layer Since the exporter master secret is not updated when client authentication = changes, Alice and Bob will export the same keying material at steps 5 and = 10. If the intended goal of this exported key is for Alice to obtain confi= dentiality in some other use, this will not be achieved, since Bob will obt= ain the same exported key. Now, a proviso is that RFC 5705 allows for the application to mix a "contex= t value" into the export, which could mitigate this, but that is optional. So it seems to me like in at least some scenarios, exported keying material= should be associated with authentication context. It is less clear to me = if the same holds true for KeyUpdates. Douglas _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 11 18:13:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D179712D6B3 for ; Mon, 11 Jul 2016 18:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZgc6vx6Uc_3 for ; Mon, 11 Jul 2016 18:13:09 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB7D12D735 for ; Mon, 11 Jul 2016 18:13:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 82so1100452qko.3 for ; Mon, 11 Jul 2016 18:13:08 -0700 (PDT) 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-transfer-encoding; bh=0EgxkXLMK3t3I0Hg6yEopt3N75Y+7aiJfWf0nLqWuO8=; b=xYEbB2285S1ahOxGsZ/IIs9PVwbyM3KioXoxB8Dz7lnJL6Hd4q5Q0JM25r/uSZ6z4+ 44mPtr7+PZdA/ArrmJoVeeSb99Y/fJn6p9II9eD3bXjYjgbPidw3ulJ34oMEpT96AfGb d6kMZnhzIY29rZZWiLyn5vQJJWIttdyheo9d5pigKlL5Iq18ilqjFSockhuJ55bhCbAh BXgtHFYgdIR53gE0yWFNjdn+huQ42GgX1ItcI1NAGlqaTnXSJ+3bxshBfoh5wyctJIxg w9rFSsmwDkw9ZcYjwSYzmTyXhEua0U2qeDwRXApz6uHBVAk4t7jUd/altTnwtlnDyB5c 6Qbw== 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-transfer-encoding; bh=0EgxkXLMK3t3I0Hg6yEopt3N75Y+7aiJfWf0nLqWuO8=; b=E/QTAbRIp2ViWwn585rj9x5PVJRm6sITezVl9aq3T7aseXCOdwK2tBkGaYlha/TL9q wjkNhTeRKX1tJ6bGn9WzQSurGDE4kkbysxc6nRkOb62lLTmizsAQ6akcFOgTmXSNqvNy 3AhYxaLDSzkW1YeT06D0SuoBKdBJzYdubcnjQ2PHTc1oEOfsPy/qQ9+TVQ3TFqCcFeV1 hYKZFndkGMEt1ysYGy23Wy/oaP4ea7cLYo9d/sfeUJfPYJvM8gj3Wfac0LSO08MZgZqO 2k3xPXjLwnlde7J8veyhuFsHqjhY2NOzV5QBThOw36xiqMf9aSSWiiRs4+WugmnbJz3S i6ww== X-Gm-Message-State: ALyK8tLiPyA14Kc82jXHI3tM1UIGqcqRGsweJa4xLt17l/PP+7NrtGJXfxC1xhjUgvzAqeIC9L9sVUWYR/CSpw== X-Received: by 10.55.214.77 with SMTP id t74mr29748341qki.80.1468285988007; Mon, 11 Jul 2016 18:13:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Mon, 11 Jul 2016 18:13:07 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 12 Jul 2016 11:13:07 +1000 Message-ID: To: Douglas Stebila Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 01:13:11 -0000 Not taking any position on the question, which I think is a fine thing to ask, but... I'd just like to point out that the example is flawed in the sense that the system permits both users to share state. When Alice logs out, that needs to include any state that might have been accumulated to Alice. This necessarily includes any sessions, including that TLS connection. If we imagine that this is a browser, then you also need to flush caches and remove cookies before the system is usable by another user. There might be operating system level things as well. Machines in internet cafes often create temporary accounts, or even rebuild the entire machine between users for this reason. Back to the question... One challenge with this is that exporters are often used to compare things. For instance, one side signs an exported value, the other validates the signature by independently exporting the same value. Getting different values for a particular exporter will cause some classes of things to fail in subtle ways. On 12 July 2016 at 05:39, Douglas Stebila wrote: > Some of the discussions I've had with people about post-handshake client = authentication have raised the question of whether application traffic secr= ets should be updated automatically upon post-handshake client authenticati= on: the thinking being that every change in context should be accompanied b= y a change in keying material. I used to think that was a good idea for TL= S 1.3, although it was recently argued to me that if we view the applicatio= n traffic secrets as being "internal" to the TLS protocol, then the change = in client authentication status doesn't change the confidential or integrit= y properties of the record layer, it just serves as a "marker" to the appli= cation that certain portions of the application data were associated with c= ertain authentication contexts. I was convinced that this can be safely ac= complished without a change in application traffic secret key material. > > But I'm not sure that the same applies to *exporter* keys. Should export= ed keying material change as the authentication context changes? > > Consider a long-lived TLS connection, where different users come and go. = For example, a web browser on a public terminal may have established a lon= g-lived TLS connection to a particular website, and send subsequent request= s to the same website over the same TLS connection. Now imagine two users = use the terminal one after another: > > 1: initial handshake on a public terminal > 2: [time passes] > 3: Alice starts browsing > 4: Alice does post-handshake client authentication > 5: Alice purchases something > 6: Alice hits "logout" at the application layer > 7: [time passes] > 8: Bob starts using the terminal > 9: Bob does post-handshake client authentication > 10: Bob purchases something > 11: Bob hits "logout" at the application layer > > TLS 1.3 will tell the application about events 4 and 9. Events 6 and 11 = happen at the application layer rather than the TLS layer (since I don't th= ink TLS 1.3 has a client-de-authentication option). But putting this all t= ogether, the application will learn all the correct authentication contexts= : 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards= is anonymous. > > Now imagine that we use keying material exporters in on lines 5 and 10: > > 1: initial handshake on a public terminal > 2: [time passes] > 3: Alice starts browsing > 4: Alice does post-handshake client authentication > *5: Alice presses the "export keying material" button > 6: Alice hits "logout" at the application layer > 7: [time passes] > 8: Bob starts using the terminal > 9: Bob does post-handshake client authentication > *10: Bob presses the "export keying material" button > 11: Bob hits "logout" at the application layer > > Since the exporter master secret is not updated when client authenticatio= n changes, Alice and Bob will export the same keying material at steps 5 an= d 10. If the intended goal of this exported key is for Alice to obtain con= fidentiality in some other use, this will not be achieved, since Bob will o= btain the same exported key. > > Now, a proviso is that RFC 5705 allows for the application to mix a "cont= ext value" into the export, which could mitigate this, but that is optional= . > > So it seems to me like in at least some scenarios, exported keying materi= al should be associated with authentication context. It is less clear to m= e if the same holds true for KeyUpdates. > > Douglas > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 11 19:56:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6293A12D675 for ; Mon, 11 Jul 2016 19:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKK8Qhc-eeHo for ; Mon, 11 Jul 2016 19:56:53 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C9812D595 for ; Mon, 11 Jul 2016 19:56:53 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id w127so2595148ywf.3 for ; Mon, 11 Jul 2016 19:56:53 -0700 (PDT) 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; bh=CYuIIKPxnVneP3tfvtB6aF4BdODFGEEwZlPq7nGfAfQ=; b=hlqefGyv1GTywlEiKMdsqveNdLihH7v/Q+bdendYV98raDQ1wCUlzONbmCW9vsA5C3 0X9b3TyXWQhU5fx4BIQWOppDXjyblSFl0cc5fobNm2jI2a0XDN+4QN90rPLI9SygvnC+ 6FIhI6hp9KQzn4oBQOTrkBw+K9MPJoxhRWCptUHn6Kpqt0Xg9jxJj639XuMPKFBx5imH +cZ5uA5aDna0KV4hYEefeNRLlHT+jHAPsxLcB4uSXkyQhILNQzwCYPAY9DV6SjZ/tkSG fAoETT6PFpbrNyL7I5UCeWUqMqltZLa4iqw5l+QFbkAxxatLcM4OefQkIgX8Mhi5Gq/K +sXw== 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; bh=CYuIIKPxnVneP3tfvtB6aF4BdODFGEEwZlPq7nGfAfQ=; b=eX/bUJ9R9BCv/rdTzScOWO7lhBGeUUAwZxWmcreLkiLLvMJpMGOigNWq6eekwQbEey Hn58OTU8q7wbbFiRCLU/kTFeKW0GkdHscSjTxlAm4J631XKDJJFT5k6OKblr+0zKEZ/I 9nJeaXfqNWOcveH+EPCPzJwbP5vvM7doMyKEsYmpKCmi6Q2Xm7rF/JjtFz8Jp+RhX9S4 8HEeebxX+sdwQfzwLIEYlHzgPxgscp8o3b8nADlREnQHoGx8AH5cnFmf5GPqxRK6LN6A wj0C5nSK8yCvu4ptep7z9yQoKwDBJ5/aLqhADaYoIsmJKlgnK7mtQgkxI49O/kAmmMso bAaQ== X-Gm-Message-State: ALyK8tIBRQhjPRh3qklRDpmm1+Y3yiVpAC9Kx7VndoggUeRxzsH8kLvD4fGJSBiYTXMAlGQwCSs3uxDa5enLmw== X-Received: by 10.129.19.212 with SMTP id 203mr15793333ywt.104.1468292212405; Mon, 11 Jul 2016 19:56:52 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.64.3 with HTTP; Mon, 11 Jul 2016 19:56:22 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Mon, 11 Jul 2016 22:56:22 -0400 X-Google-Sender-Auth: l2mj6jx3UG6AzetwLSWyj2knFuQ Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11429246bf3e690537676b1e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 02:56:56 -0000 --001a11429246bf3e690537676b1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson wrote: > Not taking any position on the question, which I think is a fine thing > to ask, but... > > I'd just like to point out that the example is flawed in the sense > that the system permits both users to share state. When Alice logs > out, that needs to include any state that might have been accumulated > to Alice. This necessarily includes any sessions, including that TLS > connection. > > If we imagine that this is a browser, then you also need to flush > caches and remove cookies before the system is usable by another user. > There might be operating system level things as well. Machines in > internet cafes often create temporary accounts, or even rebuild the > entire machine between users for this reason. > > Back to the question... > One challenge with this is that exporters are often used to compare > things. For instance, one side signs an exported value, the other > validates the signature by independently exporting the same value. > Getting different values for a particular exporter will cause some > classes of things to fail in subtle ways. > =E2=80=8BThis is unrelated to the issue =E2=80=8Bs=E2=80=8B raised by Douglas , but if the exporter *key* is intended for use as a unique session identifier =E2=80=8B(or =E2=80=8Ba sort of "channel binding") then calling it a "key" = is misleading. For example, while a key of 128 bits is perfectly fine (e.g. for AES-128), such length is insufficient as a channel binding string (where resistance to birthday attacks seems necessary). I do not see a note on this in the TLS document or RFC 5705. Hugo > > On 12 July 2016 at 05:39, Douglas Stebila wrote: > > Some of the discussions I've had with people about post-handshake clien= t > authentication have raised the question of whether application traffic > secrets should be updated automatically upon post-handshake client > authentication: the thinking being that every change in context should be > accompanied by a change in keying material. I used to think that was a > good idea for TLS 1.3, although it was recently argued to me that if we > view the application traffic secrets as being "internal" to the TLS > protocol, then the change in client authentication status doesn't change > the confidential or integrity properties of the record layer, it just > serves as a "marker" to the application that certain portions of the > application data were associated with certain authentication contexts. I > was convinced that this can be safely accomplished without a change in > application traffic secret key material. > > > > But I'm not sure that the same applies to *exporter* keys. Should > exported keying material change as the authentication context changes? > > > > Consider a long-lived TLS connection, where different users come and > go. For example, a web browser on a public terminal may have established= a > long-lived TLS connection to a particular website, and send subsequent > requests to the same website over the same TLS connection. Now imagine t= wo > users use the terminal one after another: > > > > 1: initial handshake on a public terminal > > 2: [time passes] > > 3: Alice starts browsing > > 4: Alice does post-handshake client authentication > > 5: Alice purchases something > > 6: Alice hits "logout" at the application layer > > 7: [time passes] > > 8: Bob starts using the terminal > > 9: Bob does post-handshake client authentication > > 10: Bob purchases something > > 11: Bob hits "logout" at the application layer > > > > TLS 1.3 will tell the application about events 4 and 9. Events 6 and 1= 1 > happen at the application layer rather than the TLS layer (since I don't > think TLS 1.3 has a client-de-authentication option). But putting this a= ll > together, the application will learn all the correct authentication > contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, > 11-onwards is anonymous. > > > > Now imagine that we use keying material exporters in on lines 5 and 10: > > > > 1: initial handshake on a public terminal > > 2: [time passes] > > 3: Alice starts browsing > > 4: Alice does post-handshake client authentication > > *5: Alice presses the "export keying material" button > > 6: Alice hits "logout" at the application layer > > 7: [time passes] > > 8: Bob starts using the terminal > > 9: Bob does post-handshake client authentication > > *10: Bob presses the "export keying material" button > > 11: Bob hits "logout" at the application layer > > > > Since the exporter master secret is not updated when client > authentication changes, Alice and Bob will export the same keying materia= l > at steps 5 and 10. If the intended goal of this exported key is for Alic= e > to obtain confidentiality in some other use, this will not be achieved, > since Bob will obtain the same exported key. > > > > Now, a proviso is that RFC 5705 allows for the application to mix a > "context value" into the export, which could mitigate this, but that is > optional. > > > > So it seems to me like in at least some scenarios, exported keying > material should be associated with authentication context. It is less > clear to me if the same holds true for KeyUpdates. > > > > Douglas > > _______________________________________________ > > 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 > --001a11429246bf3e690537676b1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Not t= aking any position on the question, which I think is a fine thing
to ask, but...

I'd just like to point out that the example is flawed in the sense
that the system permits both users to share state.=C2=A0 When Alice logs out, that needs to include any state that might have been accumulated
to Alice.=C2=A0 This necessarily includes any sessions, including that TLS<= br> connection.

If we imagine that this is a browser, then you also need to flush
caches and remove cookies before the system is usable by another user.
There might be operating system level things as well.=C2=A0 Machines in
internet cafes often create temporary accounts, or even rebuild the
entire machine between users for this reason.

Back to the question...
One challenge with this is that exporters are often used to compare
things.=C2=A0 For instance, one side signs an exported value, the other
validates the signature by independently exporting the same value.
Getting different values for a particular exporter will cause some
classes of things to fail in subtle ways.

=E2=80=8BThis is unrelated
=C2=A0to the issue
=E2=80=8Bs=E2=80=8B
raised by Douglas
, but =C2=A0i= f the exporter *key* is intended for use as a unique session identifier=C2=A0
=E2=80=8B(or =E2=80=8Ba sort of "cha= nnel binding") then calling it a "key" is misleading. For ex= ample, while a key of 128 bits is perfectly fine (e.g. for AES-128), such l= ength is insufficient as a channel binding string (where resistance to birt= hday attacks seems necessary). I do not see a note on this in the TLS docum= ent or RFC 5705.

=
Hugo



On 12 July 2016 at 05:39, Douglas Stebila <dstebila@gmail.com> wrote:
> Some of the discussions I've had with people about post-handshake = client authentication have raised the question of whether application traff= ic secrets should be updated automatically upon post-handshake client authe= ntication: the thinking being that every change in context should be accomp= anied by a change in keying material.=C2=A0 I used to think that was a good= idea for TLS 1.3, although it was recently argued to me that if we view th= e application traffic secrets as being "internal" to the TLS prot= ocol, then the change in client authentication status doesn't change th= e confidential or integrity properties of the record layer, it just serves = as a "marker" to the application that certain portions of the app= lication data were associated with certain authentication contexts.=C2=A0 I= was convinced that this can be safely accomplished without a change in app= lication traffic secret key material.
>
> But I'm not sure that the same applies to *exporter* keys.=C2=A0 S= hould exported keying material change as the authentication context changes= ?
>
> Consider a long-lived TLS connection, where different users come and g= o.=C2=A0 For example, a web browser on a public terminal may have establish= ed a long-lived TLS connection to a particular website, and send subsequent= requests to the same website over the same TLS connection.=C2=A0 Now imagi= ne two users use the terminal one after another:
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> 5: Alice purchases something
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> 10: Bob purchases something
> 11: Bob hits "logout" at the application layer
>
> TLS 1.3 will tell the application about events 4 and 9.=C2=A0 Events 6= and 11 happen at the application layer rather than the TLS layer (since I = don't think TLS 1.3 has a client-de-authentication option).=C2=A0 But p= utting this all together, the application will learn all the correct authen= tication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 i= s Bob, 11-onwards is anonymous.
>
> Now imagine that we use keying material exporters in on lines 5 and 10= :
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> *5: Alice presses the "export keying material" button
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> *10: Bob presses the "export keying material" button
> 11: Bob hits "logout" at the application layer
>
> Since the exporter master secret is not updated when client authentica= tion changes, Alice and Bob will export the same keying material at steps 5= and 10.=C2=A0 If the intended goal of this exported key is for Alice to ob= tain confidentiality in some other use, this will not be achieved, since Bo= b will obtain the same exported key.
>
> Now, a proviso is that RFC 5705 allows for the application to mix a &q= uot;context value" into the export, which could mitigate this, but tha= t is optional.
>
> So it seems to me like in at least some scenarios, exported keying mat= erial should be associated with authentication context.=C2=A0 It is less cl= ear to me if the same holds true for KeyUpdates.
>
> Douglas
> _______________________________________________
> 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

--001a11429246bf3e690537676b1e-- From nobody Mon Jul 11 20:14:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF2212D73D for ; Mon, 11 Jul 2016 20:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lml-YU1i-btb for ; Mon, 11 Jul 2016 20:14:05 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DF812B046 for ; Mon, 11 Jul 2016 20:14:05 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l125so2847465ywb.2 for ; Mon, 11 Jul 2016 20:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xqS8DuupRY0HWfiDAR9xqo1JOQTDzOvG4VYl15wLeU0=; b=Sn3CfjFO+YkEvdU7QWKPcAlLfIBdnSVY3AWcAy4qcK9ROZE2+jSJ7kFKeAK0v90NeY XyB4uBoM3g7s7GtTSeKTzZDxhG3QzQXWbSvPEL61tEFA4GMbcpZHXpRORbMeHHmS6PXC OXHOucPqDUecHOEDyotHpVyusN9U1d8b0fYOtaPP21gvAQmZfc02Zl6+JcDwLBuEdrxx NaqNd8qSz1aCaCDLSD51JSqmRwM1SyC0DIXMFlaTxtg0tP3kAeA+p4dGUIBw6nvQDuge 9e9fiIQQkdUHr24shg7X3U+eR9wxpGkUUrp98bQq9qW7F1Xk8uqalDLn0VPRQQG1zNic BD1A== 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; bh=xqS8DuupRY0HWfiDAR9xqo1JOQTDzOvG4VYl15wLeU0=; b=iRBdjC/yyPsQW4UX/l5F07U4iUTVWoYJ6XUfdJtJyFYw4qQiZx6eQSo09lDajzYYPs Rr5Q/Spu2PP+bfFice7H1Yllv7fk7qsFpBDz3XaloDHzIqYqOIcVFEHCdD4sQIM8yRD5 c5PnDMZ2SH3ZknwNHJNTMB+xK+961Czf1IhCj3cjCYBWJvJ9mCrrTZeWI4AzG1JwIbbJ w/iJPPK4m9H2dqysBOG0WgnZGLLPlF1w8oChEErUe6rwxk3jcNlrcWFTKKtMc85JoOsP xUurntOOYZVnWa8JH+jkdWZWW3vvLyw7RsB2NfP789p9L7oUesqYfmTiga4i8bUUjDIb cZvg== X-Gm-Message-State: ALyK8tIE8g322egmVpf8Ib0Y2Fhox7i5AATP70ieoxfBBHqwRatI2Wox2VXkBOwIlPGn6nvUtxUwp/fey9Z/Kg== X-Received: by 10.129.161.129 with SMTP id y123mr9297121ywg.214.1468293244392; Mon, 11 Jul 2016 20:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 11 Jul 2016 20:13:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 11 Jul 2016 20:13:24 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a114f8db2424ae0053767a9cb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 03:14:07 -0000 --001a114f8db2424ae0053767a9cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2016 at 7:56 PM, Hugo Krawczyk wrote: > > > On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson > wrote: > >> Not taking any position on the question, which I think is a fine thing >> to ask, but... >> >> I'd just like to point out that the example is flawed in the sense >> that the system permits both users to share state. When Alice logs >> out, that needs to include any state that might have been accumulated >> to Alice. This necessarily includes any sessions, including that TLS >> connection. >> >> If we imagine that this is a browser, then you also need to flush >> caches and remove cookies before the system is usable by another user. >> There might be operating system level things as well. Machines in >> internet cafes often create temporary accounts, or even rebuild the >> entire machine between users for this reason. >> >> Back to the question... >> One challenge with this is that exporters are often used to compare >> things. For instance, one side signs an exported value, the other >> validates the signature by independently exporting the same value. >> Getting different values for a particular exporter will cause some >> classes of things to fail in subtle ways. >> > > =E2=80=8BThis is unrelated > to the issue > =E2=80=8Bs=E2=80=8B > raised by Douglas > , but if the exporter *key* is intended for use as a unique session > identifier > > =E2=80=8B(or =E2=80=8Ba sort of "channel binding") then calling it a "key= " is misleading. > For example, while a key of 128 bits is perfectly fine (e.g. for AES-128)= , > such length is insufficient as a channel binding string (where resistance > to birthday attacks seems necessary). I do not see a note on this in the > TLS document or RFC 5705. > I filed the following issue so we would remember this: https://github.com/tlswg/tls13-spec/issues/540 -Ekr > Hugo > > >> >> On 12 July 2016 at 05:39, Douglas Stebila wrote: >> > Some of the discussions I've had with people about post-handshake >> client authentication have raised the question of whether application >> traffic secrets should be updated automatically upon post-handshake clie= nt >> authentication: the thinking being that every change in context should b= e >> accompanied by a change in keying material. I used to think that was a >> good idea for TLS 1.3, although it was recently argued to me that if we >> view the application traffic secrets as being "internal" to the TLS >> protocol, then the change in client authentication status doesn't change >> the confidential or integrity properties of the record layer, it just >> serves as a "marker" to the application that certain portions of the >> application data were associated with certain authentication contexts. = I >> was convinced that this can be safely accomplished without a change in >> application traffic secret key material. >> > >> > But I'm not sure that the same applies to *exporter* keys. Should >> exported keying material change as the authentication context changes? >> > >> > Consider a long-lived TLS connection, where different users come and >> go. For example, a web browser on a public terminal may have establishe= d a >> long-lived TLS connection to a particular website, and send subsequent >> requests to the same website over the same TLS connection. Now imagine = two >> users use the terminal one after another: >> > >> > 1: initial handshake on a public terminal >> > 2: [time passes] >> > 3: Alice starts browsing >> > 4: Alice does post-handshake client authentication >> > 5: Alice purchases something >> > 6: Alice hits "logout" at the application layer >> > 7: [time passes] >> > 8: Bob starts using the terminal >> > 9: Bob does post-handshake client authentication >> > 10: Bob purchases something >> > 11: Bob hits "logout" at the application layer >> > >> > TLS 1.3 will tell the application about events 4 and 9. Events 6 and >> 11 happen at the application layer rather than the TLS layer (since I do= n't >> think TLS 1.3 has a client-de-authentication option). But putting this = all >> together, the application will learn all the correct authentication >> contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, >> 11-onwards is anonymous. >> > >> > Now imagine that we use keying material exporters in on lines 5 and 10= : >> > >> > 1: initial handshake on a public terminal >> > 2: [time passes] >> > 3: Alice starts browsing >> > 4: Alice does post-handshake client authentication >> > *5: Alice presses the "export keying material" button >> > 6: Alice hits "logout" at the application layer >> > 7: [time passes] >> > 8: Bob starts using the terminal >> > 9: Bob does post-handshake client authentication >> > *10: Bob presses the "export keying material" button >> > 11: Bob hits "logout" at the application layer >> > >> > Since the exporter master secret is not updated when client >> authentication changes, Alice and Bob will export the same keying materi= al >> at steps 5 and 10. If the intended goal of this exported key is for Ali= ce >> to obtain confidentiality in some other use, this will not be achieved, >> since Bob will obtain the same exported key. >> > >> > Now, a proviso is that RFC 5705 allows for the application to mix a >> "context value" into the export, which could mitigate this, but that is >> optional. >> > >> > So it seems to me like in at least some scenarios, exported keying >> material should be associated with authentication context. It is less >> clear to me if the same holds true for KeyUpdates. >> > >> > Douglas >> > _______________________________________________ >> > 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 > > --001a114f8db2424ae0053767a9cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jul 11, 2016 at 7:56 PM, Hugo Krawczyk <hugo@ee.technion.ac.i= l> wrote:


On Mon, Jul 11, 2= 016 at 9:13 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Not taking any position on the question, wh= ich I think is a fine thing
to ask, but...

I'd just like to point out that the example is flawed in the sense
that the system permits both users to share state.=C2=A0 When Alice logs out, that needs to include any state that might have been accumulated
to Alice.=C2=A0 This necessarily includes any sessions, including that TLS<= br> connection.

If we imagine that this is a browser, then you also need to flush
caches and remove cookies before the system is usable by another user.
There might be operating system level things as well.=C2=A0 Machines in
internet cafes often create temporary accounts, or even rebuild the
entire machine between users for this reason.

Back to the question...
One challenge with this is that exporters are often used to compare
things.=C2=A0 For instance, one side signs an exported value, the other
validates the signature by independently exporting the same value.
Getting different values for a particular exporter will cause some
classes of things to fail in subtle ways.

=E2=80=8BThis is unrelated
=C2=A0to the issue
=E2=80=8Bs=E2=80=8B
raised by Dou= glas
, b= ut =C2=A0if the exporter *key* is intended for use as a unique session iden= tifier
=C2=A0
=E2=80=8B(or =E2=80=8Ba sort of "channel binding&q= uot;) then calling it a "key" is misleading. For example, while a= key of 128 bits is perfectly fine (e.g. for AES-128), such length is insuf= ficient as a channel binding string (where resistance to birthday attacks s= eems necessary). I do not see a note on this in the TLS document or RFC 570= 5.

I filed th= e following issue so we would remember this:

-Ekr


Hugo



On 12 July 2016 at 05:39, Douglas Stebila <dstebila@gmail.com> wrote:
> Some of the discussions I've had with people about post-handshake = client authentication have raised the question of whether application traff= ic secrets should be updated automatically upon post-handshake client authe= ntication: the thinking being that every change in context should be accomp= anied by a change in keying material.=C2=A0 I used to think that was a good= idea for TLS 1.3, although it was recently argued to me that if we view th= e application traffic secrets as being "internal" to the TLS prot= ocol, then the change in client authentication status doesn't change th= e confidential or integrity properties of the record layer, it just serves = as a "marker" to the application that certain portions of the app= lication data were associated with certain authentication contexts.=C2=A0 I= was convinced that this can be safely accomplished without a change in app= lication traffic secret key material.
>
> But I'm not sure that the same applies to *exporter* keys.=C2=A0 S= hould exported keying material change as the authentication context changes= ?
>
> Consider a long-lived TLS connection, where different users come and g= o.=C2=A0 For example, a web browser on a public terminal may have establish= ed a long-lived TLS connection to a particular website, and send subsequent= requests to the same website over the same TLS connection.=C2=A0 Now imagi= ne two users use the terminal one after another:
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> 5: Alice purchases something
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> 10: Bob purchases something
> 11: Bob hits "logout" at the application layer
>
> TLS 1.3 will tell the application about events 4 and 9.=C2=A0 Events 6= and 11 happen at the application layer rather than the TLS layer (since I = don't think TLS 1.3 has a client-de-authentication option).=C2=A0 But p= utting this all together, the application will learn all the correct authen= tication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 i= s Bob, 11-onwards is anonymous.
>
> Now imagine that we use keying material exporters in on lines 5 and 10= :
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> *5: Alice presses the "export keying material" button
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> *10: Bob presses the "export keying material" button
> 11: Bob hits "logout" at the application layer
>
> Since the exporter master secret is not updated when client authentica= tion changes, Alice and Bob will export the same keying material at steps 5= and 10.=C2=A0 If the intended goal of this exported key is for Alice to ob= tain confidentiality in some other use, this will not be achieved, since Bo= b will obtain the same exported key.
>
> Now, a proviso is that RFC 5705 allows for the application to mix a &q= uot;context value" into the export, which could mitigate this, but tha= t is optional.
>
> So it seems to me like in at least some scenarios, exported keying mat= erial should be associated with authentication context.=C2=A0 It is less cl= ear to me if the same holds true for KeyUpdates.
>
> Douglas
> _______________________________________________
> 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


--001a114f8db2424ae0053767a9cb-- From nobody Mon Jul 11 21:16:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144D3128E19 for ; Mon, 11 Jul 2016 21:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD6vNZ5tFCxX for ; Mon, 11 Jul 2016 21:16:32 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 49104128B44 for ; Mon, 11 Jul 2016 21:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id F09FE7E41; Tue, 12 Jul 2016 07:16:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id AlT0Qcj53DQY; Tue, 12 Jul 2016 07:16:27 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id CF327C4; Tue, 12 Jul 2016 07:16:27 +0300 (EEST) Date: Tue, 12 Jul 2016 07:16:24 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160712041624.GA30472@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 04:16:36 -0000 On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: > Folks, > > I've just submitted draft-ietf-tls-tls13-14.txt and it should > show up on the draft repository shortly. In the meantime you > can find the editor's copy in the usual location at: > As usual, comments welcome. > -Ekr Did a readthrough, here's a bunch of comments (didn't check the issues list): ----------------------------------------------------------------------- > ## Zero-RTT Data > > > [[OPEN ISSUE: Should it be possible to combine 0-RTT with the > server authenticating via a signature > https://github.com/tlswg/tls13-spec/issues/443]] One should note that it is not clear what sort of continuity properties should be provoded: - Certificate valid for hostname - The same key as in last time - The same certificate as in last time The last choice obviously limits lifetime of derived PSK to the parent certificate. Also, extension matching is quite different between those three (and the last two are rather different from the current rules, tuned for 0-RTT only being used with PSK. > ## Numbers > > Note that in some cases (e.g., DH parameters) it is necessary to represent > integers as opaque vectors. In such cases, they are represented as unsigned > integers (i.e., additional leading zero octets are not used even if the most > significant bit is set). Well, I think the DH parameters are gone, but DH public keys are still there, and those AFAIK are padded with zeroes. > ### Client Hello > > When this message will be sent: > > > When a client first connects to a server, it is required to send the > ClientHello as its first message. The client will also send a > ClientHello when the server has responded to its ClientHello with a > ServerHello that selects cryptographic parameters that don't match the > client's "key_share" extension. In that case, the client MUST send the same > ClientHello (without modification) except: Should the "ServerHello" be "HelloRetryRequest"? > - Including a new KeyShareEntry as the lowest priority share > (i.e., appended to the list of shares in the "key_share" extension). > > - Removing the EarlyDataIndication {{early-data-indication}} extension > if one was present. Early data is not permitted after HelloRetryRequest. Also, adding cookie extension if that was present in HRR? BTW, with the early_data context and cross-connection cookies gone, I have figured out how to delta-compress the first client_hello and its rejection against to-be-sent second client hello plus connection parameters server selected into 6 bytes(!) of space (not including return-reachability check or MAC). > ### Server Hello > > cipher_suite > : The single cipher suite selected by the server from the list in > ClientHello.cipher_suites. For resumed sessions, this field is > the value from the state of the session being resumed. > [[TODO: interaction with PSK.]] Isn't this the true ciphersuite used on this connection, "resumption" or not? Otherwise you can get into all sorts of crazy situations that WILL be sources of implementation bugs. The idea that it isn't true ciphersuite brings me bad flashbacks about TLS 1.2 ticket "maybe resume" craziness (except this would be even worse). > extensions > : A list of extensions. Note that only extensions offered by the > client can appear in the server's list. In TLS 1.3, as opposed to > previous versions of TLS, the server's extensions are split between > the ServerHello and the EncryptedExtensions {{encrypted-extensions}} > message. The ServerHello MUST only include extensions which are > required to establish the cryptographic context. Currently the only > such extensions are "key_share", "pre_shared_key", and "early_data". > Clients MUST check the ServerHello for the presence of any forbidden > extensions and if any are found MUST terminate the handshake with a > "illegal_parameter" alert. In prior versions of TLS, the extensions > field could be omitted entirely if not needed, similar to > ClientHello. As of TLS 1.3, all clients and servers will send at > least one extension (at least "key_share" or "pre_shared_key"). Hasn't early_data just moved to EncryptedExtensions? ### Hello Retry Request > selected_group > : The mutually supported group the server intends to negotiate and > is requesting a retried ClientHello/KeyShare for. > {:br } What is written into this field if server selects pure-PSK ciphersuite and then decides to reject the ClientHello? Or connections that use pure-PSK just plain can't be rejected for any reason (including IP address verification in DTLS?) > [[NOTE: cipher_suite may disappear. https://github.com/tlswg/tls13-spec/issues/528]] Currently assuming pure-PSK rejections are possible, cipher_suite is needed to tell if the next group field contains anything sane or not... > The > server SHOULD send only the extensions necessary for the client to > generate a correct ClientHello pair (currently no such extensions > exist). As with ServerHello, a > HelloRetryRequest MUST NOT contain any extensions that were not first > offered by the client in its ClientHello. What about cookie? IIRC, it is allowed to be in HRR even without being in CH... > Upon receipt of a HelloRetryRequest, the client MUST first verify that > the selected_group field corresponds to a group which was provided > in the "supported_groups" extension in the original ClientHello. It > MUST then verify that the selected_group field does not correspond > to a group which was provided in the "key_share" extension in the > original ClientHello. If either of these checks fails, then the client > MUST abort the handshake with a fatal "handshake_failure" > alert. Clients SHOULD also abort with "handshake_failure" in response > to any second HelloRetryRequest which was sent in the same connection > (i.e., where the ClientHello was itself in response to a > HelloRetryRequest). > > Otherwise, the client MUST send a ClientHello with an updated KeyShare > extension to the server. The client MUST append a new KeyShareEntry > for the group indicated in the selected_group field to the groups > in its original KeyShare. Again, rejections with cookie aren't spurious, and the cookie needs to be added. ## Hello Extensions > An extension type MUST NOT appear in the ServerHello or HelloRetryRequest > unless the same extension type appeared in the corresponding ClientHello. > If a client receives an extension type in ServerHello or HelloRetryRequest > that it did not request in the associated ClientHello, it MUST abort the > handshake with an "unsupported_extension" fatal alert. Cookie in HRR might not follow that.... > In general, the specification of each extension type needs to describe the > effect of the extension both during full handshake and session resumption. Most > current TLS extensions are relevant only when a session is initiated: when an > older session is resumed, the server does not process these extensions in > ClientHello, and does not include them in ServerHello. However, some > extensions may specify different behavior during session resumption. > [[TODO: update this and the previous paragraph to cover PSK-based resumption.]] I would say that it is a bad idea for any extension to do anything special with "resumption" without very good reasons. In fact, the only non-connection-control extension that is relevant for PSK I know is server_name. Now, ALPN (connection-control by definition!) behaves specially with early_data for darn good reasons (the ALP is locked). This is made worse by the fact that what consistutes "resumption" is not clearly defined (the ALPN rules are related to early_data, not choosing PSK #0!). > ### Signature Algorithms > > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are > encoded in two octets, so SignatureScheme values have been allocated to > align with TLS 1.2's encoding. Some legacy pairs are left unallocated. These > algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or > negotiated by any implementation. In particular, MD5 {{SLOTH}} and SHA-224 > MUST NOT be used. > > * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/signature pairs. > However, the old semantics did not constrain the signing curve. Also, for interoperability, any legal TLS 1.3 meaning of these algorithms must be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything else would be pointless trap. This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those work. Also, even if meaning of the ECDSA codepoints changed, those would not break that rule, since new definition is strict subset of old. > ### Negotiated Groups > > As of TLS 1.3, servers are permitted to send the "supported_groups" > extension to the client. If the server has a group it prefers to the > ones in the "key_share" extension but is still willing to accept the > ClientHello, it SHOULD send "supported_groups" to update the client's > view of its preferences. Clients MUST NOT act upon any information > found in "supported_groups" prior to successful completion of the > handshake, but MAY use the information learned from a successfully > completed handshake to change what groups they offer to a server in > subsequent connections. Are those supposed to be filtered to be subset of ones client advertised or not? E.g. if client didn't indicate support for x448, can the server still send x448? > ### Key Share > > If this extension is not provided in a ServerHello or ClientHello, > and the peer is offering (EC)DHE cipher suites, then the endpoint MUST close > the connection with a fatal "missing_extension" alert. > (see {{mti-extensions}}) Doesn't seem to consistent with the other descriptions of this and pre_shared_key (those are just "MUST NOT select covered ciphersuite if missing"). Of course, in practice, it might be more this (at least that's how I would implement it)... > [[TODO: Recommendation about what the client offers. > Presumably which integer DH groups and which curves.]] Bit crazy algorithm: If you haven't heard of this server before, pick smallest you support, if you have, pick the one it selected the last time. > ### Pre-Shared Key Extension > > Note that although 0-RTT data is encrypted with the first PSK identity, the > server MAY fall back to 1-RTT and select a different PSK identity if multiple > identities are offered. The temporal ordering in messages is actually selecting different PSK and then rejecting 0-RTT. > ### Early Data Indication > > obfuscated_ticket_age > : The time since the client learned about the server configuration that it is > using, in milliseconds. This value is added modulo 2^32 to with the > "ticket_age_add" value that was included with the ticket, see > {{NewSessionTicket}}. This addition prevents passive observers from > correlating sessions unless tickets are reused. Note: because ticket > lifetimes are restricted to a week, 32 bits is enough to represent any > plausible age, even in milliseconds. And the addition also prevents correlating session with its parent, even in case of reuse (this was the reason for switching to addition from XOR). > A server MUST validate that the ticket_age is within a small > tolerance of the time since the ticket was issued (see {{replay-time}}). Good luck with that... Also, requirement that the server MUST proceed with the handshake and reject 0-RTT if that validation fails would be good here... > 0-RTT messages sent in the first flight have the same content types > as their corresponding messages sent in other flights (handshake, > application_data, and alert respectively) but are protected under > different keys. After all the 0-RTT application data messages (if > any) have been sent, an "end_of_early_data" alert of type > "warning" is sent to indicate the end of the flight. > 0-RTT MUST always be followed by an "end_of_early_data" alert. This does not talk about if end_of_early_data alert is encrypted or not (obviously encrypted one won't work if server rejected 0-RTT, unless server trial-decrypts). > If any of these checks fail, the server MUST NOT respond > with the extension and must discard all the remaining first > flight data (thus falling back to 1-RTT). If the client attempts > a 0-RTT handshake but the server rejects it, it will generally > not have the 0-RTT record protection keys and must instead > trial decrypt each record with the 1-RTT handshake keys > until it finds one that decrypts properly, and then pick up > the handshake from that point. Oh, still trial decryption... Got it. > #### Processing Order > > Clients are permitted to "stream" 0-RTT data until they > receive the server's Finished, only then sending the "end_of_early_data" > alert. In order to avoid deadlock, when accepting "early_data", > servers MUST process the client's Finished and then immediately > send the ServerHello, rather than waiting for the client's > "end_of_early_data" alert. I think there was some proposal to dump the Finished. Would simplify implementation. In TLS, there is at least one appdata record with its MAC to be deprotected. That's not true in DTLS. However, even in DTLS, any wrong keys almost certainly cause handshake to immediately blow up as handshake keys won't match up... > #### Replay Properties {#replay-time} > > There are several potential sources of error that make an exact > measurement of time difficult. Variations in client and server clocks > are likely to be minimal, outside of gross time corrections. Network > propagation delays are most likely causes of a mismatch in legitimate > values for elapsed time. Both the NewSessionTicket and ClientHello > messages might be retransmitted and therefore delayed, which might be > hidden by TCP. I don't think variations in clocks are minimal... I wonder what 95% timeskew interval per day is... (Oh, and have fun with leap seconds!) > ### Encrypted Extensions > > The same extension types MUST NOT appear in both the ServerHello and > EncryptedExtensions. If the same extension appears in both locations, > the client MUST rely only on the value in the EncryptedExtensions > block. All server-sent extensions other than those explicitly listed > in {{server-hello}} or designated in the IANA registry MUST only > appear in EncryptedExtensions. Extensions which are designated to > appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients > MUST check EncryptedExtensions for the presence of any forbidden > extensions and if any are found MUST terminate the handshake with an > "illegal_parameter" alert. This seems inconsistent. In implementation, I would write explicit disjoint whitelists of extensions for both (and non-whitelisted one is a fatal error). Explicit whitelisting is safe even on client side, since the extensions are bounded by client-supported ones. > ### Certificate Request > > - The Extended Key Usage extension in a certificate matches the > request when all key purpose OIDs present in the request are also > found in the Extended Key Usage certificate extension. The special > anyExtendedKeyUsage OID MUST NOT be used in the request. How are multiple OIDs represented? Multiple EKU OID/value pairs? > #### Server Certificate Selection > > > - The "server_name" and "trusted_ca_keys" extensions {{RFC6066}} are used to > guide certificate selection. As servers MAY require the presence of the "server_name" > extension, clients SHOULD send this extension, when applicable. I think the certificate should be REQUIRED to match (as in, not be inconsistent with it) server_name, even if not ACK'd. > ### Certificate Verify > > If sent by a server, the signature algorithm MUST be one offered in the > client's "signature_algorithms" extension unless no valid certificate chain can be > produced without unsupported algorithms (see {{signature-algorithms}}). Note that > there is a possibility for inconsistencies here. For instance, the client might > offer an ECDHE_ECDSA cipher suite but omit any ECDSA and EdDSA values from its > "signature_algorithms" extension. In order to negotiate correctly, the server > MUST check any candidate cipher suites against the "signature_algorithms" > extension before selecting them. This is somewhat inelegant but is a compromise > designed to minimize changes to the original cipher suite design. The exception on not having valid value can not work at all. With certificates, even if the EE cert is signed with unknown algorithm, there is a small chance things will work. In contrast, there is absolutely no chance of success if either endpoint tries ot use this fallback. > Note: When used with non-certificate-based handshakes (e.g., PSK), the > client's signature does not cover the server's certificate directly, > although it does cover the server's Finished message, which > transitively includes the server's certificate when the PSK derives > from a certificate-authenticated handshake. {{PSK-FINISHED}} > describes a concrete attack on this mode if the Finished is omitted > from the signature. It is unsafe to use certificate-based client > authentication when the client might potentially share the same > PSK/key-id pair with two different endpoints. In order to ensure > this, implementations MUST NOT mix certificate-based client > authentication with pure PSK modes (i.e., those where the > PSK was not derived from a previous non-PSK handshake). Does this apply to in-handshake or post-handshake auth? I thought in-handshake auth with PSK is not possible. If it is intended to be possible, that's certainly going to be surprising to implementers, and there are probably going to be multiple implementations that outright choke if one tries to send CertificateRequest in (DHE-)PSK mode > ## Record Payload Protection > > length > : The length (in bytes) of the following TLSCiphertext.fragment, which > is the sum of the lengths of the content and the padding, plus one > for the inner content type. The length MUST NOT exceed 2^14 + 256. > An endpoint that receives a record that exceeds this length MUST > generate a fatal "record_overflow" alert. Later the document seems to imply that the limit for for content+type+ padding is in fact 16385 bytes. > ## Per-Record Nonce {#nonce} > > Sequence numbers do not wrap. If a TLS implementation would need to > wrap a sequence number, it MUST either rekey ({{key-update}}) or > terminate the connection. Maybe add requirement that record with sequence number of 2^64-1 MUST be either fatal alert or KeyUpdate. > ## Limits on Key Usage > > For AES-GCM, up to 2^24.5 full-size records may be encrypted on a > given connection while keeping a safety margin of approximately > 2^-57 for Authenticated Encryption (AE) security. For > ChaCha20/Poly1305, the record sequence number will wrap before the > safety limit is reached. I would expand that 2^24.5 to some rough number ("about 24 million"?). And also "will wrap" -> "would wrap". Because such wrapping can't happen (even if endpoint delays KeyUpdate to RSN 2^64-1). > ## Key Schedule > > If a given secret is not available, then the 0-value consisting of > a string of Hash.length zeroes is used. Note that this does not mean skipping > rounds, so if PSK is not in use Early Secret will still be > HKDF-Extract(0, 0). This might cause fun with future key exchange types... > # IANA Considerations > | Extension | Recommended | TLS 1.3 | > |:-----------------------------------------|------------:|----------:| > | max_fragment_length [RFC6066] | Yes | Encrypted | I think this needs to be in ServerHello on server-side, given how low- level it is. > | user_mapping [RFC4681] | Yes | Encrypted | > | client_authz [RFC5878] | No | Encrypted | > | server_authz [RFC5878] | No | Encrypted | These darn things use Supplemental Data messages, would need to define where the data goes. And one can't stick it to extension for user_mapping and client_authz, because those are sent by the client, not the server. > | cookie [[this document]] | Yes | Encrypted/HelloRetryRequest | Isn't that "Client/HelloRetryRequest"? I don't think EncryptedExtensions can have Cookie... > - TLS SignatureScheme Registry: Values with the first byte in the range > 0-254 (decimal) are assigned via Specification Required {{RFC2434}}. > Values with the first byte 255 (decimal) are reserved for Private > Use {{RFC2434}}. This registry SHALL have a "Recommended" column. > The registry [shall be/ has been] initially populated with the values described in > {{signature-algorithms}}. The following values SHALL be marked as > "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, > rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. Should the two registeries shadowed by this closed? > ## Cipher Suites > > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but > are being or will be used for interop testing and therefore are likely to be > assigned. Isn't the RFC already published, so the codepoints are stable? > ## Random Number Generation and Seeding > > To estimate the amount of seed material being produced, add the number of bits > of unpredictable information in each seed byte. For example, keystroke timing > values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure bits > each, even though the total size of the counter value is 16 bits or more. > Seeding a 128-bit PRNG would thus require approximately 100 such timer values. This seems really obsolete. The timers have not been 18.2Hz for years, and applications running on operating systems damn better use OS services for random numbers, given that anything else is fraught with peril. > ## Implementation Pitfalls > > - Have you ensured that all support for SSL, RC4, EXPORT ciphers, and > MD5 (via the "signature_algorithm" extension) is completely removed from > all possible configurations that support TLS 1.3 or later, and that > attempts to use these obsolete capabilities fail correctly? > (see {{backward-compatibility}}) Better to just nuke the code entierely for all versions. "Disabled" code has nasty tendency of coming back to life. > - Do you handle TLS extensions in ClientHello correctly, including > unknown extensions or omitting the extensions field completely? The extensions field can't be omitted in TLS 1.3. And I would consider TLS 1.2 client implementations that send such messages as quite pathological. > Cryptographic details: > > - What countermeasures do you use to prevent timing attacks against > RSA signing operations {{TIMING}}? Also, ECDSA signing operations do have problems with timing attacks. > - When verifying RSA signatures, do you accept both NULL and missing parameters? > Do you verify that the RSA padding > doesn't have additional data after the hash value? {{FI06}} Also, the lengths need to be correct (not verifying this leads to an attack). Best just to treat first length bytes >0x82 or >0x83 as malformed. There is no way to send legimate message with first length byte >0x83 in TLS. > # Overview of Security Properties {#security-analysis} > > [[TODO: This section is still a WIP and needs a bunch more work.]] > > A complete security analysis of TLS is outside the scope of this document. > In this section, we provide an informal description the desired properties > as well as references to more detailed work in the research literature > which provides more formal definitions. > > We cover properties of the handshake separately from those of the record layer. I think properties of the exporter should be covered as well: - Is it intended to generate secret data (yes) - Is it intended to generate connection-unique data (yes) - Are values for different labels/contexts intended to be computationally independent (yes) (The TLS 1.2 exporter without EMS failed the middle requirement, creating security issues in applications that assumed the data was connection-unique. ----------------------------------------------------------------------- -Ilari From nobody Mon Jul 11 22:53:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4B912B032 for ; Mon, 11 Jul 2016 22:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VCLheMdZY1t for ; Mon, 11 Jul 2016 22:53:01 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 5137612B031 for ; Mon, 11 Jul 2016 22:53:01 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i12so4922355ywa.1 for ; Mon, 11 Jul 2016 22:53:01 -0700 (PDT) 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-transfer-encoding:message-id; bh=0T89Pqder249KJ5v44NfsDuxxjO2BbCdVNxOzRAMIIc=; b=IUDpSSLhZLztC4oJO4hzuR7JfT2DSEYVZk3K9N2XEmvMjkhuNwqI6dGHbRYDwBkY3k kuZWjCDIve6IcFw+ckmyjy2WKyLInkmkA0QRJj1QWzL9EbJa/DsYBXD3IE+uwFu1tKFO f035NympyBQk3uJsyy23suhXLQbI9FqIpAgNNO1m1IyPRtHMjXY27ZBZWGFpBf2BCybW /JGPsZ23KJm5Qo9iJzugN6wFWk6+5rvIGMUMOw+lCBu5znkDwV6DS4QAHvQgJ5s5imtA 0LzCTrw+DyZh8FtpEIIuag+VR/BHfiR3pPO581aQe91fup3qIYa3e4Slq7l8ON3ubhhK R+cw== 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-transfer-encoding:message-id; bh=0T89Pqder249KJ5v44NfsDuxxjO2BbCdVNxOzRAMIIc=; b=m6ccAu/dDcJ18xoPlsaSto94FEwlxCVU+QvAsZ8tHS4ARQSX6EArVPFCY8oWKvZDQh N1zD99Mdsy12b67QlxVxgA0HjkK3mG1oA8b00wFec/RO81NbxmsP5NS990X1QP2E0Him m5gvCD1YhmJ+XR0tazX7RsvPgv4biEiEBXIfA/FoAq6yMgMsLloDvsg3GlBpYLKxsjw5 d/UClqIY5+0PrHaT5pWwHRnXO/v5DH7dWkJ+NPN8+tgbKQd6ypzBypRHdmV+xX1eVvDQ 5uxH/iiX/iV4fb9E46vKZlEjD1ONsh/tUTxtomkwXq8KbRZhtD+21872MYRuHtM6lrlQ uJjQ== X-Gm-Message-State: ALyK8tK+n1ctXZiiNV1/IRXzA0pWj5zXNVwdOB0WqZ5whOuESkOFErzHnKMKSgP2LoX02A== X-Received: by 10.129.124.87 with SMTP id x84mr53056ywc.254.1468302780465; Mon, 11 Jul 2016 22:53:00 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id b5sm7410366ywd.8.2016.07.11.22.52.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jul 2016 22:52:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 12 Jul 2016 01:52:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201607120152.58083.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 05:53:03 -0000 Just replying to a few points. On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote: > ### Hello Retry Request > > > selected_group > > : The mutually supported group the server intends to negotiate and > > is requesting a retried ClientHello/KeyShare for. > > {:br } > > What is written into this field if server selects pure-PSK ciphersuite > and then decides to reject the ClientHello? Or connections that use > pure-PSK just plain can't be rejected for any reason (including IP > address verification in DTLS?) The HelloRetryRequest message is not applicable to pure-PSK, which does not use the KeyShare extension at all. PSK has its own separate extension. ((EC)DHE-PSK uses both together) The purpose of HelloRetryRequest is to allow for clients to not send full keys for every single algorithm they support, yet allow the server to still pick from that entire list if it needs to. PSK has no equivalent system; pre-shared keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid PSK identity is selected, the server can use HelloRetryRequest to reject a group in favor of another supported by the client, but it can't reject the suite or identity in this manner. The response to no acceptable PSK identity is either to negotiate another suite or to abort with a fatal alert. See draft 14 section 4.2.5: https://tools.ietf.org/html/draft-ietf-tls-tls13-14#section-4.2.5 > > ## Cipher Suites > > > > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but > > are being or will be used for interop testing and therefore are likely to be > > assigned. > > Isn't the RFC already published, so the codepoints are stable? xiaoyinl fixed the second one of those notes, but that was merged after the checkpoint for draft 14. I'll fix this one to just note for ECDHE PSK AES. > > ## Implementation Pitfalls > > > > - Have you ensured that all support for SSL, RC4, EXPORT ciphers, and > > MD5 (via the "signature_algorithm" extension) is completely removed from > > all possible configurations that support TLS 1.3 or later, and that > > attempts to use these obsolete capabilities fail correctly? > > (see {{backward-compatibility}}) > > Better to just nuke the code entierely for all versions. > > "Disabled" code has nasty tendency of coming back to life. Emphatically agreed, however I worded it this way to be slightly more general. If I said that all that code should be universally gutted, I'd risk more people ignoring it due to the severe status quo bias that is very common. In lieu of modernizing fully and dropping it completely, having these old features disabled via the same compile-time option that enables building of TLS 1.3 would be acceptable, IMO (though, more trouble than it should be worth, and still not ideal at all). Bikeshedding better wordings in this section would not be unwelcome, if you think anything here can be made better. > > - Do you handle TLS extensions in ClientHello correctly, including > > unknown extensions or omitting the extensions field completely? > > The extensions field can't be omitted in TLS 1.3. And I would > consider TLS 1.2 client implementations that send such messages > as quite pathological. Implementations should be expected to handle pathological cases gracefully, even if only to recognize and reject. ;) Dave From nobody Mon Jul 11 23:04:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C6712B019 for ; Mon, 11 Jul 2016 23:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhdWIMLv222B for ; Mon, 11 Jul 2016 23:04:30 -0700 (PDT) Received: from nm37-vm1.bullet.mail.bf1.yahoo.com (nm37-vm1.bullet.mail.bf1.yahoo.com [72.30.238.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A3012B075 for ; Mon, 11 Jul 2016 23:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468303468; bh=FNORVHsmbOPsM3iI21+61bf8MO7v6k7AJ4g0gDsMPtY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=FUNzrvT04EGFGi/sHVRfcxOEp7cg/q13n4HrZ+B5Ej4Q8ALEoxEn6bt9NxZlCFy0xBy3kJc9E8tvQorixO8uiw0i12ueKY/F25/Y2/HnfBLGlRSAFaLkqwZ51u6ruPuUTENJqy/kvyC5o74M+hHfteaUdU+mAPt8eG9VwsgUn/pNjsljBs45kY9nWubDjXYxyn5LshwcfcqMw3CQY0YgfRTGzHikdotFHf0q9+ipn+ZD4AtZNhKbevxYVJqCuavfPM+vdSzhUwDy5riF2m7SZu6kXA2ez7sRCDg2hIwQSzI+kCwgooScB/LCNh0A5qMmEmxcUie6F+tR1uFsRxF+Bg== Received: from [98.139.214.32] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2016 06:04:28 -0000 Received: from [98.139.212.239] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jul 2016 06:04:28 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 12 Jul 2016 06:04:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 633612.65480.bm@omp1048.mail.bf1.yahoo.com X-YMail-OSG: wJsOjEQVM1lps2qBQsN9sa3d0J3vmP92LVGl1FWul1L7hnzgKwobmnFuiLAzjDu EuTiREwykOAi99dHZLUwdu1yr7W3B521_4G4yhTkZxssBWioNurKkeTWRlwHWzgl.Ul7hxlwhmaN MCjbKJChQk2kWvxfSVL6dnTu4EqkIUrJxRzF.uOTjuiNZ5IwCdWTZ24tWVhmeb6YsGlEHb2G.wCQ i0qWbxPRQ2YMOaUEM2kxxaVYuewNSuwosLRavUWktR7ZYtOJQo9Pk6ZaSJJEWJt08sFLBWNNaG5t TbPDsX4loY6.4S3EYhROa11Jjm099XYwaWHKql8tbRyqbihb_tWvdXGNm9RMqNqR1H8upRtck6Gc ZEKzLXKNE0p5kiF2cqTnUnWb_SDsdTMUZct8u5zJFZBhel2k7wSq7.HtHq0qADo53HjLg0TfhoK1 vpj8mUG0jRqEmXarEkiAMXMaFH8.s6wsSvvaNUFXGpLaaIZid6xcJFuQ._NQQGQjx5WDBxNeoiUj qmgplzUdIcj9HQ3cvRrfbYT9B1_BpS46XQ5hkaZm_PkMgJWFxq__58P_D_.L8dAF64NtF1omHNzc sVcm3xCNmjTfMIcpH8ks8FPxfA80SC4jwyYL2SkU- Received: from jws106155.mail.bf1.yahoo.com by sendmailws155.mail.bf1.yahoo.com; Tue, 12 Jul 2016 06:04:28 +0000; 1468303468.175 Date: Tue, 12 Jul 2016 06:04:17 +0000 (UTC) From: To: Sean Turner Message-ID: <1885849647.1554903.1468303457714.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <880079020.470300.1468136219291.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1554902_1561621486.1468303457710" Archived-At: Cc: "draft-ietf-dice-profile@ietf.org" , "tls@ietf.org" , "draft-ietf-tls-ecdhe-psk-aead@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: g_e_montenegro@yahoo.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 Jul 2016 06:04:32 -0000 ------=_Part_1554902_1561621486.1468303457710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sean, That might be a good thing, yes. If so, it would be best to make that relat= ionship explicit with an "Updates: " header note, referencing DICE in this = document, and explaining how it is extending it.=C2=A0 thanks, Gabriel=20 On Monday, July 11, 2016 7:35 AM, Sean Turner wrote: =20 =20 =20 > On Jul 10, 2016, at 03:36, g_e_montenegro@yahoo.com wrote: >=20 > Hi, >=20 > I'm curious as to the relationship between this TLS WG draft and the DICE= profile for IoT (currently in Auth48): > https://tools.ietf.org/html/draft-ietf-dice-profile >=20 > The dice profile uses two TLS ciphershuites >=20 > TLS_PSK_WITH_AES_128_CCM_8=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (defi= ned in https://tools.ietf.org/html/rfc6655) >=20 > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8=C2=A0 =C2=A0 (defined in https://tools= .ietf.org/html/rfc7251) >=20 > Notice that the DICE profile defines nothing (it has no IANA consideratio= ns). Instead, it reuses definitions established previously per the referenc= es above. >=20 > This draft-ietf-tls-ecdhe-psk-aeak=C2=A0 claims to also define IoT-friend= ly ciphersuites, for example, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256=20 >=20 > However, it does not reference the DICE profile draft.=20 >=20 > What is the difference between these? There=E2=80=99s might be a relationship between the DICE profile and this d= raft in the future. The DICE draft profiles the existing set of cipher suites that are already = defined for IoT; the complete list can be found here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa= rameters-4 draft-ietf-tls-ecdhe-psk-aead is adding more algorithms to that list.=C2=A0= The DICE profile can be updated later to include these newly defined ciphe= r suites if that=E2=80=99s what the WG wants to do. Make sense? spt =20 ------=_Part_1554902_1561621486.1468303457710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sean,

That mi= ght be a good thing, yes. If so, it would be best to make that relationship= explicit with an "Updates: " header note, referencing DICE in this documen= t, and explaining how it is extending it. 

thanks,

Gabriel


On Monday, July 11, 2016 7:= 35 AM, Sean Turner <sean@sn3rd.com> wrote:


> On Jul 10, 2016, at 03:36, g_e_montenegro@yahoo.com wrote:
> > Hi,
>
> I'= m curious as to the relationship between this TLS WG draft and the DICE pro= file for IoT (currently in Auth48):
> https://tools.ietf.org/html/draft-ietf-dice-profile
>
> The dice profile uses two TLS ciphershuit= es
>
> TLS_PSK_WITH_AES_128_CCM_= 8            (defined in https://tools= .ietf.org/html/rfc6655)
>
> = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8    (defined in https://= tools.ietf.org/html/rfc7251)
>
= > Notice that the DICE profile defines nothing (it has no IANA considera= tions). Instead, it reuses definitions established previously per the refer= ences above.
>
> This draft-ietf= -tls-ecdhe-psk-aeak  claims to also define IoT-friendly ciphersuites, = for example, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
>= ;
> However, it does not reference the DICE profile d= raft.
>
> What is the differenc= e between these?


There=E2=80=99s= might be a relationship between the DICE profile and this draft in the fut= ure.

The DICE draft profiles the exist= ing set of cipher suites that are already defined for IoT; the complete lis= t can be found here:
https://www.iana.org/assignments/tls-parameters/tls-par= ameters.xhtml#tls-parameters-4

dra= ft-ietf-tls-ecdhe-psk-aead is adding more algorithms to that list.  Th= e DICE profile can be updated later to include these newly defined cipher s= uites if that=E2=80=99s what the WG wants to do.

Make sense?

spt

------=_Part_1554902_1561621486.1468303457710-- From nobody Tue Jul 12 02:00:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80B12D752 for ; Tue, 12 Jul 2016 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX6X20kjB9-C for ; Tue, 12 Jul 2016 02:00:23 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7512D754 for ; Tue, 12 Jul 2016 02:00:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A502F47F4; Tue, 12 Jul 2016 12:00:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id c4p5i23Ptx_y; Tue, 12 Jul 2016 12:00:21 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 677F5C4; Tue, 12 Jul 2016 12:00:21 +0300 (EEST) Date: Tue, 12 Jul 2016 12:00:18 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20160712090018.GB30472@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <201607120152.58083.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201607120152.58083.davemgarrett@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:00:25 -0000 On Tue, Jul 12, 2016 at 01:52:57AM -0400, Dave Garrett wrote: > Just replying to a few points. > > On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote: > > ### Hello Retry Request > > > > > selected_group > > > : The mutually supported group the server intends to negotiate and > > > is requesting a retried ClientHello/KeyShare for. > > > {:br } > > > > What is written into this field if server selects pure-PSK ciphersuite > > and then decides to reject the ClientHello? Or connections that use > > pure-PSK just plain can't be rejected for any reason (including IP > > address verification in DTLS?) > > The HelloRetryRequest message is not applicable to pure-PSK, which > does not use the KeyShare extension at all. PSK has its own separate > extension. ((EC)DHE-PSK uses both together) Yes, rejection because of group mismatch can't occur. However, I don't see any requirement not to reject pure-PSK for cookie check (might be feasible, if the computational and network load is determined "small enough"). > > > ## Cipher Suites > > > > > > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but > > > are being or will be used for interop testing and therefore are likely to be > > > assigned. > > > > Isn't the RFC already published, so the codepoints are stable? > > xiaoyinl fixed the second one of those notes, but that was merged > after the checkpoint for draft 14. I'll fix this one to just note > for ECDHE PSK AES. IIRC, there was merged patch that changed the reference, but not the text. Just checked, seems to still be there in Editor's Copy. -Ilari From nobody Tue Jul 12 06:23:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54EF12DA0B for ; Tue, 12 Jul 2016 06:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDx1bCuzTUCh for ; Tue, 12 Jul 2016 06:22:58 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E844612DA0C for ; Tue, 12 Jul 2016 06:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J9e7OKO6xdNnDPh8B3uc5mU4XsQjgrajFa++8qB0U+E=; b=O1nUPv0rVuHxuMtS5j0nDBi2XCwdhi/OPjiAgkdH2Dc889InAZfWE6lz0k5ir1qt4GX1oHMHJujS0aFDuxpaC5tbeLkz/XnFCCMkfw6UhOkk/IWr60pJ0mlkqEJUooIXxHF+4wujRnhDz+5MC+CW8+aXeeE3MJgZVm4+kvLnAQk= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0172.namprd09.prod.outlook.com (10.255.192.150) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 13:04:11 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 13:04:11 +0000 From: "Dang, Quynh (Fed)" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIA Date: Tue, 12 Jul 2016 13:04:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 37322e57-210d-4a77-b3ba-08d3aa550485 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0172; 6:uD86Wc27yVLJ0oj+AnqKCxplgnvRhGMDfl9VRfN5Mwht7c30CJbpwC1shFFY6fD+NspWLcagWWNYzNg6a2cdyrMKLwpVeUaLeY0hLDBcfJWIV8ZyiHQZdGMggYivgHpyDqQhNWCWA3gziDfzMoWrBJ6nbTpyfnkF3IBJ3kNtnoNtHn3J1UAqTefYFfX+NDdSmY2u4MjsbWsPiCRlCF7Ac3F9+GhEYuUzCNb+O/4prj5wv/6X6GiVHRXaZa4wSDA53jhj6RwNQaR/OZ+KlO7Han61/N7gx5H5c21hS1WWOxYZUmyGYhqbRl/q6/99g3RZcEHMswIqlT9UfJkOowxL7w==; 5:+/7tFuF9WKZmuyxWdSd5eqD5rRu3RbiXI5INnADT6w27i+p8zhc2hjC847B5pC7rRCc/6PyFidb+X2U4A/V0GfAftNucXyuSEmyxJe4ILrda7wDjWMah1LuE/w+naFrJkZbx8LafaI/WJXgY8vNQ/A==; 24:kzK+aTCChVZE7WghEFIOyTmkNoawfOFnULVcLhH+RZugyXD9Yf9uudCaldZDh2AcWzEQzWaKxdOA+Iu8Ps0C6feWKndcD1Gi9roIXLRw1iw=; 7:Gd8oScVwliMR+S+6+K7z1ML74rSJE7cgAyVZ1/MDZtSnyRNS/4hKyS4Qvgr8NwLhFjzZOtLjgKK0Gq5xqnwWUFICEKCoaNIzrKghUpQWyDvdwx7hYN4wyRBcFLOZMWVz9XqxEbWn84NPSBrJ+BYgoHH+8mz8LbdPYaJngS5vUO6vPg+qabLzdBtunqoRS0LAP3/B46J+dqd7iaRy4WFF0r7EXu5H0uSoYHRf1QGpdYVfbMBKSycfv+dIKTmIzHnn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0172; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0172; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0172; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(55674003)(199003)(377454003)(189002)(83506001)(36756003)(7736002)(7846002)(11100500001)(7906003)(5001770100001)(2950100001)(105586002)(66066001)(5002640100001)(68736007)(4001350100001)(97736004)(106356001)(101416001)(77096005)(122556002)(50986999)(76176999)(107886002)(92566002)(2501003)(19617315012)(54356999)(189998001)(8676002)(81156014)(99286002)(3846002)(586003)(87936001)(6116002)(8936002)(102836003)(3280700002)(81166006)(16236675004)(2900100001)(10400500002)(86362001)(15975445007)(19580395003)(19580405001)(106116001)(2906002)(230783001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0172; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3AA5BD627AC0qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 13:04:11.0544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0172 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:23:04 -0000 --_000_D3AA5BD627AC0qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric and all, In my opinion, we should give better information about data limit for AES_G= CM in TLS 1.3 instead of what is current in the draft 14. In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is cal= led confidentiality attack is the known plaintext differentiality attack wh= ere the attacker has/chooses two plaintexts, send them to the AES-encryptio= n oracle. The oracle encrypts one of them, then sends the ciphertext to th= e attacker. After seeing the ciphertext, the attacker has some success pro= bability of telling which plaintext was encrypted and this success probabil= ity is in the column called "Attack Success Probability" in Table 1. This = attack does not break confidentiality. If the attack above breaks one of security goal(s) of your individual syste= m, then making success probability of that attack at 2^(-32) max is enough.= In that case, the Max number of records is around 2^38. Regards, Quynh. Date: Monday, July 11, 2016 at 3:08 PM To: "tls@ietf.org" > Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt Folks, I've just submitted draft-ietf-tls-tls13-14.txt and it should show up on the draft repository shortly. In the meantime you can find the editor's copy in the usual location at: http://tlswg.github.io/tls13-spec/ The major changes in this document are: * A big restructure to make it read better. I moved the Overview to the beginning and then put the document in a more logical order starting with the handshake and then the record and alerts. * Totally rewrote the section which used to be called "Security Analysis" and is now called "Overview of Security Properties". This section is still kind of a hard hat area, so PRs welcome. In particular, I know I need to beef up the citations for the record layer section. * Removed the 0-RTT EncryptedExtensions and moved ticket_age into the ClientHello. This quasi-reverts a change in -13 that made implementation of 0-RTT kind of a pain. As usual, comments welcome. -Ekr * Allow cookies to be longer (*) * Remove the "context" from EarlyDataIndication as it was undefined and nobody used it (*) * Remove 0-RTT EncryptedExtensions and replace the ticket_age extension with an obfuscated version. Also necessitates a change to NewSessionTicket (*). * Move the downgrade sentinel to the end of ServerHello.Random to accomodate tlsdate (*). * Define ecdsa_sha1 (*). * Allow resumption even after fatal alerts. This matches current practice. * Remove non-closure warning alerts. Require treating unknown alerts as fatal. * Make the rules for accepting 0-RTT less restrictive. * Clarify 0-RTT backward-compatibility rules. * Clarify how 0-RTT and PSK identities interact. * Add a section describing the data limits for each cipher. * Major editorial restructuring. * Replace the Security Analysis section with a WIP draft. (*) indicates changes to the wire protocol which may require implementation= s to update. --_000_D3AA5BD627AC0qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Eric and all, 

In my opinion, we should give better information about data limit for = AES_GCM in TLS 1.3 instead of what is current in the draft 14. 

In this paper: http://www.isg.rhul.ac.= uk/~kp/TLS-AEbounds.pdf,  what is called confidentiality attack is= the known plaintext differentiality attack where the attacker has/chooses two plaintexts, send them to the AES-encryption o= racle.  The oracle encrypts one of them, then sends the ciphertext to = the attacker.  After seeing the ciphertext, the attacker has some succ= ess probability of telling which plaintext was encrypted and this success probability is in the column called “= Attack Success Probability” in Table 1.  This attack does not br= eak confidentiality. 

If the attack above breaks one of security goal(s) of your individual = system, then making success probability of that attack at 2^(-32) max is en= ough. In that case, the Max number of records is around 2^38. 


Regards,
Quynh. 



Date: Monday, July 11, 2016 at 3:08= PM
To: "tls@ietf.org" <tls@ietf.= org>
Subject: [TLS] New draft: draft-iet= f-tls-tls13-14.txt

Folks,

I've just submitted draft-ietf-tls-tls13-14.txt and it should
show up on the draft repository shortly. In the meantime you
can find the editor's copy in the usual location at:


The major changes in this document are:

* A big restructure to make it read better. I moved the Overview
  to the beginning and then put the document in a more logical
  order starting with the handshake and then the record and
  alerts.

* Totally rewrote the section which used to be called "Security
  Analysis" and is now called "Overview of Security Pro= perties".
  This section is still kind of a hard hat area, so PRs welcome.<= /div>
  In particular, I know I need to beef up the citations for the
  record layer section.

* Removed the 0-RTT EncryptedExtensions and moved ticket_age
  into the ClientHello. This quasi-reverts a change in -13 that
  made implementation of 0-RTT kind of a pain.

As usual, comments welcome.
-Ekr



* Allow cookies to be longer (*)

* Remove the "context" from EarlyDataIndication as it was un= defined
  and nobody used it (*)

* Remove 0-RTT EncryptedExtensions and replace the ticket_age extensio= n
  with an obfuscated version. Also necessitates a change to
  NewSessionTicket (*).

* Move the downgrade sentinel to the end of ServerHello.Random
  to accomodate tlsdate (*).

* Define ecdsa_sha1 (*).

* Allow resumption even after fatal alerts. This matches current
  practice.

* Remove non-closure warning alerts. Require treating unknown alerts a= s
  fatal.

* Make the rules for accepting 0-RTT less restrictive.

* Clarify 0-RTT backward-compatibility rules.

* Clarify how 0-RTT and PSK identities interact.

* Add a section describing the data limits for each cipher.

* Major editorial restructuring.

* Replace the Security Analysis section with a WIP draft.

(*) indicates changes to the wire protocol which may require implement= ations
    to update.

--_000_D3AA5BD627AC0qdangnistgov_-- From nobody Tue Jul 12 06:50:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC2512DF6D for ; Tue, 12 Jul 2016 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36ai3WEZK2FB for ; Tue, 12 Jul 2016 06:50:28 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F5E12DC06 for ; Tue, 12 Jul 2016 06:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8UnPp5eqlrU5lXT6EpXxQb98b1O5YFiqUKwV0aoMAv4=; b=m7sZFHXJp8Koim01SLERyUJPIZthbM/kpuM/soxnKfxPUs4XuczjytfEsRXR7xJoIu5OOIRF2Dalqxbn2NEcc4SVgUj9GC0tuHnXChV7l2yDvf6QnuUPEq7zPfiHwwjF6BzMvCw8qX+67TrILWSy6YLJsNuQSxCrFp+296RhOkU= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0169.namprd09.prod.outlook.com (10.255.192.147) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 13:17:46 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 13:17:46 +0000 From: "Dang, Quynh (Fed)" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUhSwA Date: Tue, 12 Jul 2016 13:17:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 4176e1ae-6f6f-49b7-83b3-08d3aa56eaa1 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0169; 6:0XvGqATh5kyaufRHrFbBhoE6EiJRs77BD+V2L9/52otYB/jSF1l4+jntr6jkoCClVmMvBFFnys068DX2csNZ4SRE87Xh3xZ+YPPGXn6P7jQxjNzr3sFW4Gw4N9/Pvhnx2UGzOTqdl8cQD1oP4TY751wF85QIKKhUtdpe311l1ueFYRMiwCui4jjRrya/gTPOKtAKYbeaiWBs5qjEwzSb/cRtEbQM7xNfcrg+3hxowOS6JD6WzSXk4FlmncmZt2MUFFPSixrdAxUOS8datbUjyY7oKrxjO3sutF4cVMJTKblyUy2PV9L8jSPkR5QbUMBz98hstyfmQQbLNdys2MLw6Q==; 5:Q7lMqflkl5gb6+xSOjQFu5mhue5xlPVBE/LHiIBMUIhqcgmlogTWlfbuUqw2NZxi3xrSpxGq3D+GoONrfEJedZfKP20bYMl7Lir1V4YTjiIibkuM2XxJ3yR6DnP891HFon6rZzcbrBCycoWxCJor9g==; 24:rvFiTjVpCB5tasvOjkqzwfz7IZlOg+3h/KE1GMvO49iY6RIO4yb6CqI13xKF3hDFT3b3xo1uquG2VkMNbyG92o0cWHSlOYXeKOaAUlT+bVE=; 7:bjR9OnsXnzdaG9o3YNlzdL3GvpkhLrxCfWIbvHSiTenf7UhPwMrs92ap6M+HZTOEo0KbuiqPmtEBx8W2v9K0S5SIeJZsENCfEJXe+PcQcnXwRCGIp50HySQK8dQ/TyeBA7IZZq0zQ9EqIN65fG9n5w4JZF43aliT2mgmlPFdRNL7nlZF4K6XDk8lDtBAO70AocTNzNVuoUkLi+oygpd3KKL1fasKtZyse0T51V/jpXQqcd8lvqySKXlEts2TnlNP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0169; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB0169; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0169; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(55674003)(377454003)(189002)(199003)(7736002)(19617315012)(7846002)(122556002)(87936001)(92566002)(3280700002)(66066001)(3660700001)(16236675004)(81156014)(81166006)(8676002)(86362001)(189998001)(19580405001)(83506001)(19580395003)(107886002)(586003)(102836003)(77096005)(2906002)(8936002)(50986999)(106116001)(2501003)(106356001)(36756003)(105586002)(2900100001)(5002640100001)(10400500002)(2950100001)(6116002)(3846002)(101416001)(11100500001)(97736004)(5001770100001)(68736007)(4001350100001)(230783001)(76176999)(15975445007)(54356999)(7906003)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0169; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3AA662B27B03qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 13:17:46.8004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0169 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:50:32 -0000 --_000_D3AA662B27B03qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric and all, In my opinion, we should give better information about data limit for AES_G= CM in TLS 1.3 instead of what is current in the draft 14. In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is cal= led confidentiality attack is the known plaintext differentiality attack wh= ere the attacker has/chooses two plaintexts, send them to the AES-encryptio= n oracle. The oracle encrypts one of them, then sends the ciphertext to th= e attacker. After seeing the ciphertext, the attacker has some success pro= bability of telling which plaintext was encrypted and this success probabil= ity is in the column called "Attack Success Probability" in Table 1. This = attack does not break confidentiality. If the attack above breaks one of security goal(s) of your individual syste= m, then making success probability of that attack at 2^(-32) max is enough.= In that case, the Max number of records is around 2^38. Regards, Quynh. From: TLS > on behalf of = Eric Rescorla > Date: Monday, July 11, 2016 at 3:08 PM To: "tls@ietf.org" > Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt Folks, I've just submitted draft-ietf-tls-tls13-14.txt and it should show up on the draft repository shortly. In the meantime you can find the editor's copy in the usual location at: http://tlswg.github.io/tls13-spec/ The major changes in this document are: * A big restructure to make it read better. I moved the Overview to the beginning and then put the document in a more logical order starting with the handshake and then the record and alerts. * Totally rewrote the section which used to be called "Security Analysis" and is now called "Overview of Security Properties". This section is still kind of a hard hat area, so PRs welcome. In particular, I know I need to beef up the citations for the record layer section. * Removed the 0-RTT EncryptedExtensions and moved ticket_age into the ClientHello. This quasi-reverts a change in -13 that made implementation of 0-RTT kind of a pain. As usual, comments welcome. -Ekr * Allow cookies to be longer (*) * Remove the "context" from EarlyDataIndication as it was undefined and nobody used it (*) * Remove 0-RTT EncryptedExtensions and replace the ticket_age extension with an obfuscated version. Also necessitates a change to NewSessionTicket (*). * Move the downgrade sentinel to the end of ServerHello.Random to accomodate tlsdate (*). * Define ecdsa_sha1 (*). * Allow resumption even after fatal alerts. This matches current practice. * Remove non-closure warning alerts. Require treating unknown alerts as fatal. * Make the rules for accepting 0-RTT less restrictive. * Clarify 0-RTT backward-compatibility rules. * Clarify how 0-RTT and PSK identities interact. * Add a section describing the data limits for each cipher. * Major editorial restructuring. * Replace the Security Analysis section with a WIP draft. (*) indicates changes to the wire protocol which may require implementation= s to update. --_000_D3AA662B27B03qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Eric and all, 

In my opinion, we should give better information about data limit for = AES_GCM in TLS 1.3 instead of what is current in the draft 14. 

In this paper: http://www.isg.rhul.ac.= uk/~kp/TLS-AEbounds.pdf,  what is called confidentiality attack is= the known plaintext differentiality attack where the attacker has/chooses two plaintexts, send them to the AES-encryption o= racle.  The oracle encrypts one of them, then sends the ciphertext to = the attacker.  After seeing the ciphertext, the attacker has some succ= ess probability of telling which plaintext was encrypted and this success probability is in the column called “= Attack Success Probability” in Table 1.  This attack does not br= eak confidentiality. 

If the attack above breaks one of security goal(s) of your individual = system, then making success probability of that attack at 2^(-32) max is en= ough. In that case, the Max number of records is around 2^38. 


Regards,
Quynh. 

From: TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla = <ekr@rtfm.com>
Date: Monday, July 11, 2016 at 3:08= PM
To: "tls@ietf.org" <tls@ietf.= org>
Subject: [TLS] New draft: draft-iet= f-tls-tls13-14.txt

Folks,

I've just submitted draft-ietf-tls-tls13-14.txt and it should
show up on the draft repository shortly. In the meantime you
can find the editor's copy in the usual location at:


The major changes in this document are:

* A big restructure to make it read better. I moved the Overview
  to the beginning and then put the document in a more logical
  order starting with the handshake and then the record and
  alerts.

* Totally rewrote the section which used to be called "Security
  Analysis" and is now called "Overview of Security Pro= perties".
  This section is still kind of a hard hat area, so PRs welcome.<= /div>
  In particular, I know I need to beef up the citations for the
  record layer section.

* Removed the 0-RTT EncryptedExtensions and moved ticket_age
  into the ClientHello. This quasi-reverts a change in -13 that
  made implementation of 0-RTT kind of a pain.

As usual, comments welcome.
-Ekr



* Allow cookies to be longer (*)

* Remove the "context" from EarlyDataIndication as it was un= defined
  and nobody used it (*)

* Remove 0-RTT EncryptedExtensions and replace the ticket_age extensio= n
  with an obfuscated version. Also necessitates a change to
  NewSessionTicket (*).

* Move the downgrade sentinel to the end of ServerHello.Random
  to accomodate tlsdate (*).

* Define ecdsa_sha1 (*).

* Allow resumption even after fatal alerts. This matches current
  practice.

* Remove non-closure warning alerts. Require treating unknown alerts a= s
  fatal.

* Make the rules for accepting 0-RTT less restrictive.

* Clarify 0-RTT backward-compatibility rules.

* Clarify how 0-RTT and PSK identities interact.

* Add a section describing the data limits for each cipher.

* Major editorial restructuring.

* Replace the Security Analysis section with a WIP draft.

(*) indicates changes to the wire protocol which may require implement= ations
    to update.

--_000_D3AA662B27B03qdangnistgov_-- From nobody Tue Jul 12 07:46:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1024112D8B9 for ; Tue, 12 Jul 2016 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myE03vPlhtH8 for ; Tue, 12 Jul 2016 07:46:21 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E258F12DCCE for ; Tue, 12 Jul 2016 07:00:37 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q83so17178217iod.1 for ; Tue, 12 Jul 2016 07:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9BLU23SrWq9nuBC+5x3/51Vr64RB0cnk5cSw6BimVjM=; b=xKgIgjcIgmvCIMn2URh2QAvOKWHItZ6hrJFMsV9j17GinA8vmgwGhTzcP+pawzmUqE /G/QscYnbEjyRwr1kd57zKeq/viJsaQM2hKpG/RIz+ocaQ6ftuQBY2/uuMZLmXfu/HcN 2Pr+pHs1bGN8esD4et/ZlADtqdOk6kwjOGCEJhEnL/jDyXFUCytsiF094KRNWI2zdRWT kslTWmRDa4yllXPyf+yaKPP3Edc5gqBnqTZO3wp/9ompztPPbbRP2T7v4qzHfjKTTH8B V/BpWJBXoJqOPKozt2+O2JgTgw1G+TWe99+vK5mFlcHQOsBwdQZj3Ei90W9zLN+Q9UbU B3iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9BLU23SrWq9nuBC+5x3/51Vr64RB0cnk5cSw6BimVjM=; b=fU29LTb2yEr6U0nSqDXjiZhlmb8+CEWF42n0LYmtvP4/AwY8kkrCj8t+j/xSItkzJP Zwdn1ggjEteJaUI+y6nw5acQQ6PCc54XdH4SEnZKhBZJeK0v0Qzc89nKQ9DHcdjlBsAv sxLrbEABHSSJ+0T7qTEmqkEviJhxLNa+BCFWVG2m9htBgvDTvjfY0nBXL00OmiOmOeIS EQ0mky89YDgq6elYn/7212hRWXXLAar5oEhbIZ+Ljtkkx0T7ri9k3xO3t9KFO+LbZXu2 XX6OBcmlVYL+1KQl0pZyD+cra0DRsyhuYd0lrKsrAXr1RpZzDuqNgrNpIh1FnJ8mXDBI 9AsA== X-Gm-Message-State: ALyK8tKcvCmAHn5I8vlP6b55wVRJPSt+zwIXQLrIVoqXilAL5OxdHIMaSXKoXjnxM5db3Q== X-Received: by 10.107.44.194 with SMTP id s185mr3458795ios.0.1468332036943; Tue, 12 Jul 2016 07:00:36 -0700 (PDT) Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id p21sm12758750iop.0.2016.07.12.07.00.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 07:00:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Douglas Stebila In-Reply-To: Date: Tue, 12 Jul 2016 10:00:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> References: To: Andrei Popov , Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:46:23 -0000 > On Jul 11, 2016, at 19:24, Andrei Popov = wrote: >=20 > As currently defined, post-handshake client auth allows the same = client to present different identities, but not to repudiate a = previously presented identity. So in your example, from the TLS = perspective, the client is both Alice and Bob, and therefore I think the = same EKM value makes sense. Even if that's how it's defined, we cannot be sure that applications = which use EKM will realize that. We should not underestimate how much = applications may abuse TLS or misunderstand TLS's security properties. > On Jul 11, 2016, at 21:13, Martin Thomson = wrote: >=20 > Back to the question... > One challenge with this is that exporters are often used to compare > things. For instance, one side signs an exported value, the other > validates the signature by independently exporting the same value. > Getting different values for a particular exporter will cause some > classes of things to fail in subtle ways. Agreed, this does create the possibility that the endpoints will export = different values at different times due to unsynchronized context = switches. =20 However, we should compare this failure mode (which might cause two = "partnered" parties to not get the same exporter key) with the failure = mode if we use the same EKM for the whole session (which might cause = more parties than we expect to get the same exporter key). Fail-closed = versus fail-open. Douglas > On 12 July 2016 at 05:39, Douglas Stebila wrote: >> Some of the discussions I've had with people about post-handshake = client authentication have raised the question of whether application = traffic secrets should be updated automatically upon post-handshake = client authentication: the thinking being that every change in context = should be accompanied by a change in keying material. I used to think = that was a good idea for TLS 1.3, although it was recently argued to me = that if we view the application traffic secrets as being "internal" to = the TLS protocol, then the change in client authentication status = doesn't change the confidential or integrity properties of the record = layer, it just serves as a "marker" to the application that certain = portions of the application data were associated with certain = authentication contexts. I was convinced that this can be safely = accomplished without a change in application traffic secret key = material. >>=20 >> But I'm not sure that the same applies to *exporter* keys. Should = exported keying material change as the authentication context changes? >>=20 >> Consider a long-lived TLS connection, where different users come and = go. For example, a web browser on a public terminal may have = established a long-lived TLS connection to a particular website, and = send subsequent requests to the same website over the same TLS = connection. Now imagine two users use the terminal one after another: >>=20 >> 1: initial handshake on a public terminal >> 2: [time passes] >> 3: Alice starts browsing >> 4: Alice does post-handshake client authentication >> 5: Alice purchases something >> 6: Alice hits "logout" at the application layer >> 7: [time passes] >> 8: Bob starts using the terminal >> 9: Bob does post-handshake client authentication >> 10: Bob purchases something >> 11: Bob hits "logout" at the application layer >>=20 >> TLS 1.3 will tell the application about events 4 and 9. Events 6 and = 11 happen at the application layer rather than the TLS layer (since I = don't think TLS 1.3 has a client-de-authentication option). But putting = this all together, the application will learn all the correct = authentication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is = anonymous, 9-10 is Bob, 11-onwards is anonymous. >>=20 >> Now imagine that we use keying material exporters in on lines 5 and = 10: >>=20 >> 1: initial handshake on a public terminal >> 2: [time passes] >> 3: Alice starts browsing >> 4: Alice does post-handshake client authentication >> *5: Alice presses the "export keying material" button >> 6: Alice hits "logout" at the application layer >> 7: [time passes] >> 8: Bob starts using the terminal >> 9: Bob does post-handshake client authentication >> *10: Bob presses the "export keying material" button >> 11: Bob hits "logout" at the application layer >>=20 >> Since the exporter master secret is not updated when client = authentication changes, Alice and Bob will export the same keying = material at steps 5 and 10. If the intended goal of this exported key = is for Alice to obtain confidentiality in some other use, this will not = be achieved, since Bob will obtain the same exported key. >>=20 >> Now, a proviso is that RFC 5705 allows for the application to mix a = "context value" into the export, which could mitigate this, but that is = optional. >>=20 >> So it seems to me like in at least some scenarios, exported keying = material should be associated with authentication context. It is less = clear to me if the same holds true for KeyUpdates. >>=20 >> Douglas >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 12 07:47:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691A112DD03 for ; Tue, 12 Jul 2016 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-anhdAK1j2B for ; Tue, 12 Jul 2016 07:47:49 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0051.outbound.protection.outlook.com [104.47.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EAB12DD14 for ; Tue, 12 Jul 2016 07:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FpSbxBpQmuaY7v2NTwpM5m3iXpg0FhfXLt7kq74BoTI=; b=i7tnhZWPDCqj4jwgML84uhl39BCm1ZIDAUMCbYZpoTIRG8OV6AZ/JAx6aAylDaVYWqbhx/SnBEucLCv4E1hatAi93DbzB7gYr1SEHFKygSa26WmkVeszAsQPxCqF3ptH4TK4dYsb7Ca7iBuNJRJ5YrMy4mXqwOcU7S1DueT4/q0= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1821.eurprd03.prod.outlook.com (10.166.42.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 14:03:57 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 14:03:57 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQA= Date: Tue, 12 Jul 2016 14:03:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 35c8be2f-8011-42fc-5b09-08d3aa5d5e2a x-microsoft-exchange-diagnostics: 1; VI1PR03MB1821; 6:waF5VFffv6Nw/F2rCoGSLGQIJU2D7onb6K16D0zBhUUqNzEMqygJQSnzUICDloyFsEicF8oH77TNRzIY5kdr69Higrjj0L68ZV8Ip+boKsK0kiQczN7L0xlUbtltTAyNpevO7GXMm+UeyUyvQ7eDFFo37plLx3s/aZB7KojVrhZgKMMY0evjEtqp3Wiqk55cV/kd8KsUqhHP0sM8e/Bf0sswI9I3Ibt9rVspHy0v0XKtkTS9D7CMxd+VISmvnzJKG1jsWilKcsa3mfHT3dGF9DssMTuyTT7/bp5z1w2I9K0=; 5:69McAnK5OFBS8wDrFH5excKrzaB97XI/sm+a6wKDKUX6ZqB3hPsAPBoaNa4JoWRoYgJn/qXxDysajO22mzuiY2FpVfGZFSBFnE1pZcxZcYPIPKp01FTAbJL5z00XnyCmiAxKO+xRSRxAUm064iGkzA==; 24:+L1eEIS1BM61FRRJHBwZ7gWxzqlJ1JvVSiO7vVKKmqzEcyhX7pGWtKTcqFXj+ZcF6H1V+w/hDim5DpAibvLpYj+WpG/uLi774ZCBEonKkDU=; 7:TObfFJPdt/hjxu6w5KFubjFBSbPZ3ISRRNcF7gRSF/R1Pd6o3lu3rsmleJcdrF66vwnCROpIRcSQbQ+TiAcDg4VZnIi8AqunLr8B5pbKFKW02oHo0Svsu5Jjj6q7FQbU5ocB5k1mzhEeH3yGqAvN8BW37X4gKvfcRodYh+UT7jkn8tpQTiUni7/5JrAtthIkPHbhstfHf/tl2XCpLpb/pz6gpXOLkweOEy8sgt+Qj9GNltujdpawW+S0Emlkrehu x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1821; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1821; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1821; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(55674003)(87936001)(7736002)(68736007)(66066001)(305945005)(3660700001)(2950100001)(586003)(77096005)(15975445007)(92566002)(8676002)(11100500001)(4001350100001)(5001770100001)(3846002)(102836003)(6116002)(2900100001)(5002640100001)(81166006)(8666005)(76176999)(50986999)(101416001)(19580395003)(2501003)(74482002)(230783001)(97736004)(10400500002)(107886002)(54356999)(122556002)(105586002)(19580405001)(36756003)(8936002)(7846002)(106356001)(106116001)(3280700002)(83506001)(189998001)(86362001)(81156014)(2906002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1821; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5DAFB6F3709FA343A303538267D6C5A9@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 14:03:57.7346 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1821 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:47:52 -0000 SGkgUXV5bmgsDQoNClRoaXMgaW5kaXN0aW5ndWlzaGFiaWxpdHktYmFzZWQgc2VjdXJpdHkgbm90 aW9uIGlzIHRoZSBjb25maWRlbnRpYWxpdHkNCm5vdGlvbiB0aGF0IGlzIGJ5IG5vdyBnZW5lcmFs bHkgYWNjZXB0ZWQgaW4gdGhlIGNyeXB0byBjb21tdW5pdHkuIE1lZXRpbmcNCml0IGlzIHN1ZmZp Y2llbnQgdG8gZ3VhcmFudGVlIHNlY3VyaXR5IGFnYWluc3QgbWFueSBvdGhlciBmb3JtcyBvZiBh dHRhY2sNCm9uIGNvbmZpZGVudGlhbGl0eSwgd2hpY2ggaXMgb25lIG9mIHRoZSBtYWluIHJlYXNv bnMgd2UgdXNlIGl0Lg0KDQpZb3Ugc2F5IHRoYXQgYW4gYXR0YWNrIGluIHRoZSBzZW5zZSBpbXBs aWVkIGJ5IGJyZWFraW5nIHRoaXMgbm90aW9uIGRvZXMNCm5vdCBicmVhayBjb25maWRlbnRpYWxp dHkuIENhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5DQoiY29uZmlkZW50aWFsaXR5Iiwg aW4gYSBwcmVjaXNlIHdheT8gSSBjYW4gdGhlbiB0cnkgdG8gdGVsbCB5b3Ugd2hldGhlcg0KdGhp cyBub3Rpb24gd2lsbCBpbXBseSB5b3Vycy4NCg0KUmVnYXJkcw0KDQpLZW5ueSANCg0KT24gMTIv MDcvMjAxNiAxNDowNCwgIlRMUyBvbiBiZWhhbGYgb2YgRGFuZywgUXV5bmggKEZlZCkiDQo8dGxz LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3Rl Og0KDQo+SGkgRXJpYyBhbmQgYWxsLCANCj4NCj4NCj5JbiBteSBvcGluaW9uLCB3ZSBzaG91bGQg Z2l2ZSBiZXR0ZXIgaW5mb3JtYXRpb24gYWJvdXQgZGF0YSBsaW1pdCBmb3INCj5BRVNfR0NNIGlu IFRMUyAxLjMgaW5zdGVhZCBvZiB3aGF0IGlzIGN1cnJlbnQgaW4gdGhlIGRyYWZ0IDE0Lg0KPg0K Pg0KPkluIHRoaXMgcGFwZXI6IGh0dHA6Ly93d3cuaXNnLnJodWwuYWMudWsvfmtwL1RMUy1BRWJv dW5kcy5wZGYsICB3aGF0IGlzDQo+Y2FsbGVkIGNvbmZpZGVudGlhbGl0eSBhdHRhY2sgaXMgdGhl IGtub3duIHBsYWludGV4dCBkaWZmZXJlbnRpYWxpdHkNCj5hdHRhY2sgd2hlcmUNCj4gdGhlIGF0 dGFja2VyIGhhcy9jaG9vc2VzIHR3byBwbGFpbnRleHRzLCBzZW5kIHRoZW0gdG8gdGhlIEFFUy1l bmNyeXB0aW9uDQo+b3JhY2xlLiAgVGhlIG9yYWNsZSBlbmNyeXB0cyBvbmUgb2YgdGhlbSwgdGhl biBzZW5kcyB0aGUgY2lwaGVydGV4dCB0bw0KPnRoZSBhdHRhY2tlci4gIEFmdGVyIHNlZWluZyB0 aGUgY2lwaGVydGV4dCwgdGhlIGF0dGFja2VyIGhhcyBzb21lIHN1Y2Nlc3MNCj5wcm9iYWJpbGl0 eSBvZiB0ZWxsaW5nIHdoaWNoIHBsYWludGV4dA0KPiB3YXMgZW5jcnlwdGVkIGFuZCB0aGlzIHN1 Y2Nlc3MgcHJvYmFiaWxpdHkgaXMgaW4gdGhlIGNvbHVtbiBjYWxsZWQNCj7igJxBdHRhY2sgU3Vj Y2VzcyBQcm9iYWJpbGl0eeKAnSBpbiBUYWJsZSAxLiAgVGhpcyBhdHRhY2sgZG9lcyBub3QgYnJl YWsNCj5jb25maWRlbnRpYWxpdHkuIA0KPg0KPg0KPklmIHRoZSBhdHRhY2sgYWJvdmUgYnJlYWtz IG9uZSBvZiBzZWN1cml0eSBnb2FsKHMpIG9mIHlvdXIgaW5kaXZpZHVhbA0KPnN5c3RlbSwgdGhl biBtYWtpbmcgc3VjY2VzcyBwcm9iYWJpbGl0eSBvZiB0aGF0IGF0dGFjayBhdCAyXigtMzIpIG1h eCBpcw0KPmVub3VnaC4gSW4gdGhhdCBjYXNlLCB0aGUgTWF4IG51bWJlciBvZiByZWNvcmRzIGlz IGFyb3VuZCAyXjM4Lg0KPg0KPg0KPg0KPg0KPlJlZ2FyZHMsDQo+UXV5bmguIA0KPg0KPg0KPg0K Pg0KPg0KPg0KPkRhdGU6IE1vbmRheSwgSnVseSAxMSwgMjAxNiBhdCAzOjA4IFBNDQo+VG86ICJ0 bHNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQo+U3ViamVjdDogW1RMU10gTmV3IGRyYWZ0OiBk cmFmdC1pZXRmLXRscy10bHMxMy0xNC50eHQNCj4NCj4NCj4NCj5Gb2xrcywNCj4NCj4NCj5JJ3Zl IGp1c3Qgc3VibWl0dGVkIGRyYWZ0LWlldGYtdGxzLXRsczEzLTE0LnR4dCBhbmQgaXQgc2hvdWxk DQo+c2hvdyB1cCBvbiB0aGUgZHJhZnQgcmVwb3NpdG9yeSBzaG9ydGx5LiBJbiB0aGUgbWVhbnRp bWUgeW91DQo+Y2FuIGZpbmQgdGhlIGVkaXRvcidzIGNvcHkgaW4gdGhlIHVzdWFsIGxvY2F0aW9u IGF0Og0KPg0KPg0KPiAgaHR0cDovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLw0KPg0KPg0K PlRoZSBtYWpvciBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgYXJlOg0KPg0KPg0KPiogQSBiaWcg cmVzdHJ1Y3R1cmUgdG8gbWFrZSBpdCByZWFkIGJldHRlci4gSSBtb3ZlZCB0aGUgT3ZlcnZpZXcN Cj4gIHRvIHRoZSBiZWdpbm5pbmcgYW5kIHRoZW4gcHV0IHRoZSBkb2N1bWVudCBpbiBhIG1vcmUg bG9naWNhbA0KPiAgb3JkZXIgc3RhcnRpbmcgd2l0aCB0aGUgaGFuZHNoYWtlIGFuZCB0aGVuIHRo ZSByZWNvcmQgYW5kDQo+ICBhbGVydHMuDQo+DQo+DQo+KiBUb3RhbGx5IHJld3JvdGUgdGhlIHNl Y3Rpb24gd2hpY2ggdXNlZCB0byBiZSBjYWxsZWQgIlNlY3VyaXR5DQo+ICBBbmFseXNpcyIgYW5k IGlzIG5vdyBjYWxsZWQgIk92ZXJ2aWV3IG9mIFNlY3VyaXR5IFByb3BlcnRpZXMiLg0KPiAgVGhp cyBzZWN0aW9uIGlzIHN0aWxsIGtpbmQgb2YgYSBoYXJkIGhhdCBhcmVhLCBzbyBQUnMgd2VsY29t ZS4NCj4gIEluIHBhcnRpY3VsYXIsIEkga25vdyBJIG5lZWQgdG8gYmVlZiB1cCB0aGUgY2l0YXRp b25zIGZvciB0aGUNCj4gIHJlY29yZCBsYXllciBzZWN0aW9uLg0KPg0KPg0KPiogUmVtb3ZlZCB0 aGUgMC1SVFQgRW5jcnlwdGVkRXh0ZW5zaW9ucyBhbmQgbW92ZWQgdGlja2V0X2FnZQ0KPiAgaW50 byB0aGUgQ2xpZW50SGVsbG8uIFRoaXMgcXVhc2ktcmV2ZXJ0cyBhIGNoYW5nZSBpbiAtMTMgdGhh dA0KPiAgbWFkZSBpbXBsZW1lbnRhdGlvbiBvZiAwLVJUVCBraW5kIG9mIGEgcGFpbi4NCj4NCj4N Cj5BcyB1c3VhbCwgY29tbWVudHMgd2VsY29tZS4NCj4tRWtyDQo+DQo+DQo+DQo+DQo+DQo+DQo+ KiBBbGxvdyBjb29raWVzIHRvIGJlIGxvbmdlciAoKikNCj4NCj4NCj4qIFJlbW92ZSB0aGUgImNv bnRleHQiIGZyb20gRWFybHlEYXRhSW5kaWNhdGlvbiBhcyBpdCB3YXMgdW5kZWZpbmVkDQo+ICBh bmQgbm9ib2R5IHVzZWQgaXQgKCopDQo+DQo+DQo+KiBSZW1vdmUgMC1SVFQgRW5jcnlwdGVkRXh0 ZW5zaW9ucyBhbmQgcmVwbGFjZSB0aGUgdGlja2V0X2FnZSBleHRlbnNpb24NCj4gIHdpdGggYW4g b2JmdXNjYXRlZCB2ZXJzaW9uLiBBbHNvIG5lY2Vzc2l0YXRlcyBhIGNoYW5nZSB0bw0KPiAgTmV3 U2Vzc2lvblRpY2tldCAoKikuDQo+DQo+DQo+KiBNb3ZlIHRoZSBkb3duZ3JhZGUgc2VudGluZWwg dG8gdGhlIGVuZCBvZiBTZXJ2ZXJIZWxsby5SYW5kb20NCj4gIHRvIGFjY29tb2RhdGUgdGxzZGF0 ZSAoKikuDQo+DQo+DQo+KiBEZWZpbmUgZWNkc2Ffc2hhMSAoKikuDQo+DQo+DQo+KiBBbGxvdyBy ZXN1bXB0aW9uIGV2ZW4gYWZ0ZXIgZmF0YWwgYWxlcnRzLiBUaGlzIG1hdGNoZXMgY3VycmVudA0K PiAgcHJhY3RpY2UuDQo+DQo+DQo+KiBSZW1vdmUgbm9uLWNsb3N1cmUgd2FybmluZyBhbGVydHMu IFJlcXVpcmUgdHJlYXRpbmcgdW5rbm93biBhbGVydHMgYXMNCj4gIGZhdGFsLg0KPg0KPg0KPiog TWFrZSB0aGUgcnVsZXMgZm9yIGFjY2VwdGluZyAwLVJUVCBsZXNzIHJlc3RyaWN0aXZlLg0KPg0K Pg0KPiogQ2xhcmlmeSAwLVJUVCBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IHJ1bGVzLg0KPg0KPg0K PiogQ2xhcmlmeSBob3cgMC1SVFQgYW5kIFBTSyBpZGVudGl0aWVzIGludGVyYWN0Lg0KPg0KPg0K PiogQWRkIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBkYXRhIGxpbWl0cyBmb3IgZWFjaCBjaXBo ZXIuDQo+DQo+DQo+KiBNYWpvciBlZGl0b3JpYWwgcmVzdHJ1Y3R1cmluZy4NCj4NCj4NCj4qIFJl cGxhY2UgdGhlIFNlY3VyaXR5IEFuYWx5c2lzIHNlY3Rpb24gd2l0aCBhIFdJUCBkcmFmdC4NCj4N Cj4NCj4oKikgaW5kaWNhdGVzIGNoYW5nZXMgdG8gdGhlIHdpcmUgcHJvdG9jb2wgd2hpY2ggbWF5 IHJlcXVpcmUNCj5pbXBsZW1lbnRhdGlvbnMNCj4gICAgdG8gdXBkYXRlLg0KPg0KPg0KPg0KPg0K Pg0KDQo= From nobody Tue Jul 12 08:32:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26E12D13E for ; Tue, 12 Jul 2016 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtIeCrzb34ih for ; Tue, 12 Jul 2016 08:32:41 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0118.outbound.protection.outlook.com [23.103.201.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6780612D85D for ; Tue, 12 Jul 2016 08:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DQxoiSNG08R/Xv+Qi1I4vTwcoWq3E42NO8o9duI+No4=; b=2lxu1uoCIzq/xMYcNxRYTxMH2VYfXfxhv/O3ssfuekya8wUQzRYVc1uDxK2+ziCaXc3EEYe+2+DDcCfVmr5ahEfvryP95akQsBXVDIYopmEGQUOkX1YV8joy9aQ/B8lbDn5s6x3DpGWufKtauPmhVRWYnq3rtJsY52T/leL0Njw= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 15:12:23 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 15:12:21 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAA== Date: Tue, 12 Jul 2016 15:12:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 46d18595-bd05-4eba-15c1-08d3aa66ec54 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0171; 6:kPTWZiH5URUkGDFPnsC589+zf0tyNws8ZoRcWtEh/AfKbLJ3lX6Wpc+PFe51CAtNXMDTelWKZ/Ipi4SziW413Slz1MX/CZ95K41ydXgYf5uJV48gvUPKq2oyFHu7y7YBifFT9bf6rkstm8xS6D8Ua4Ly2mlmgNjMoT1ySVZJwpU2BaRDgT0wjqsaDVFb6mmeR544AYN49lXHTybvm/Tuc9ovMeB0BnXdBgOm01fZb0TGdsRtn+2hjQZ21LSrtUN8Yyp0lAWEOEFw6xlloAYiMvbEKtem59wiD/4gUi0DXacSo5EbhJtVLrZ6FBHoVHorBNuqph1L0bg1Z+9W0DeaRA==; 5:ymXW+K6RHtdFA5URUj37qrYUn4b7QqYAT11JvYII0oDTzKaB87rh3+u74PUYcmd4aQsLVJtpW3PvOzDmDQMXZv/nc+Z9jj+Z9xdxbWN7kKD7jLLKZF4yqEtYn/eZ4v1qEgzLhP0Oq/dvlEubANbcCQ==; 24:WIqxUUUCiyGmH/VqKlU525Yk+Fpy8U8D02bsqjDetPkxc8PW814yQCarz7VrdDuW3mYsC2M7xwxCZ5qDO9gWvwQtw06B3RJx7GvNIlHfxG8=; 7:26dEaxDLmCTp2EhIRYVhboOtCc3e1HxPBlUYKEEkkd16705buDQS4Vj5mPDELZCZQS6bx/bu0Ve1rOo2NTMJ4dolzxJXmB24sWFjDYYO2PFcB5EtHDAkp6lGa8QMBeza162bqVvj1NuBa2aq3fWBSMVV8PVnDgavT1v1WI4pYsYAm3G05cB2SYDdJyHmg1zI8Ycd0iJbLkuczp/BV95IFnxF3xsmA04vmOxeQbjIsvNBgb8RbvH6FbDb7mzgLL0G x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0171; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0171; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0171; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(55674003)(8936002)(3280700002)(36756003)(87936001)(10400500002)(83506001)(230783001)(66066001)(3660700001)(8676002)(19580405001)(2906002)(86362001)(81166006)(81156014)(105586002)(99286002)(7846002)(106356001)(106116001)(2950100001)(68736007)(2900100001)(305945005)(107886002)(7736002)(19580395003)(189998001)(50986999)(54356999)(76176999)(2501003)(101416001)(586003)(92566002)(5001770100001)(102836003)(122556002)(3846002)(5002640100001)(15975445007)(6116002)(77096005)(97736004)(4001350100001)(8666005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0171; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <633DBFEE61137B4BB1707FDD82AEFEDF@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 15:12:21.3930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0171 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:32:43 -0000 Hi Kenny, The indistinguishability-based security notion in the paper is a stronger security notion than the (old) traditional confidentiality notion. (*) Indistinguishability notion (framework) guarantees no other attacks can be better than the indistinguishability bound. Intuitively, you can=B9t attack if you can=B9t even tell two things are different or not. So, being able to say two things are different or not is the minimal condition to lead to any attack. The traditional confidentiality definition is that knowing only the ciphertexts, the attacker can=B9t know any content of the corresponding plaintexts with a greater probability than some value and this value depends on the particular cipher. Of course, the maximum amount of data must not be more than some limit under a given key which also depends on the cipher.=20 For example, with counter mode AES_128, Let=B9s say encrypting 2^70 input blocks with a single key. With the 2^70 ciphertext blocks alone (each block is 128 bits), I don=B9t think one can find out any content of any of the plaintexts. The chance for knowing any block of the plaintexts is 1/(2^128) in this case. I support the strongest indistinguishability notion mentioned in (*) above, but in my opinion we should provide good description to the users. That is why I support the limit around 2^38 records. Regards, Quynh.=20 On 7/12/16, 10:03 AM, "Paterson, Kenny" wrote: >Hi Quynh, > >This indistinguishability-based security notion is the confidentiality >notion that is by now generally accepted in the crypto community. Meeting >it is sufficient to guarantee security against many other forms of attack >on confidentiality, which is one of the main reasons we use it. > >You say that an attack in the sense implied by breaking this notion does >not break confidentiality. Can you explain what you mean by >"confidentiality", in a precise way? I can then try to tell you whether >this notion will imply yours. > >Regards > >Kenny=20 > >On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)" > wrote: > >>Hi Eric and all,=20 >> >> >>In my opinion, we should give better information about data limit for >>AES_GCM in TLS 1.3 instead of what is current in the draft 14. >> >> >>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is >>called confidentiality attack is the known plaintext differentiality >>attack where >> the attacker has/chooses two plaintexts, send them to the AES-encryption >>oracle. The oracle encrypts one of them, then sends the ciphertext to >>the attacker. After seeing the ciphertext, the attacker has some success >>probability of telling which plaintext >> was encrypted and this success probability is in the column called >>=B3Attack Success Probability=B2 in Table 1. This attack does not break >>confidentiality.=20 >> >> >>If the attack above breaks one of security goal(s) of your individual >>system, then making success probability of that attack at 2^(-32) max is >>enough. In that case, the Max number of records is around 2^38. >> >> >> >> >>Regards, >>Quynh.=20 >> >> >> >> >> >> >>Date: Monday, July 11, 2016 at 3:08 PM >>To: "tls@ietf.org" >>Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt >> >> >> >>Folks, >> >> >>I've just submitted draft-ietf-tls-tls13-14.txt and it should >>show up on the draft repository shortly. In the meantime you >>can find the editor's copy in the usual location at: >> >> >> http://tlswg.github.io/tls13-spec/ >> >> >>The major changes in this document are: >> >> >>* A big restructure to make it read better. I moved the Overview >> to the beginning and then put the document in a more logical >> order starting with the handshake and then the record and >> alerts. >> >> >>* Totally rewrote the section which used to be called "Security >> Analysis" and is now called "Overview of Security Properties". >> This section is still kind of a hard hat area, so PRs welcome. >> In particular, I know I need to beef up the citations for the >> record layer section. >> >> >>* Removed the 0-RTT EncryptedExtensions and moved ticket_age >> into the ClientHello. This quasi-reverts a change in -13 that >> made implementation of 0-RTT kind of a pain. >> >> >>As usual, comments welcome. >>-Ekr >> >> >> >> >> >> >>* Allow cookies to be longer (*) >> >> >>* Remove the "context" from EarlyDataIndication as it was undefined >> and nobody used it (*) >> >> >>* Remove 0-RTT EncryptedExtensions and replace the ticket_age extension >> with an obfuscated version. Also necessitates a change to >> NewSessionTicket (*). >> >> >>* Move the downgrade sentinel to the end of ServerHello.Random >> to accomodate tlsdate (*). >> >> >>* Define ecdsa_sha1 (*). >> >> >>* Allow resumption even after fatal alerts. This matches current >> practice. >> >> >>* Remove non-closure warning alerts. Require treating unknown alerts as >> fatal. >> >> >>* Make the rules for accepting 0-RTT less restrictive. >> >> >>* Clarify 0-RTT backward-compatibility rules. >> >> >>* Clarify how 0-RTT and PSK identities interact. >> >> >>* Add a section describing the data limits for each cipher. >> >> >>* Major editorial restructuring. >> >> >>* Replace the Security Analysis section with a WIP draft. >> >> >>(*) indicates changes to the wire protocol which may require >>implementations >> to update. >> >> >> >> >> > From nobody Tue Jul 12 08:43:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7AB12D0ED for ; Tue, 12 Jul 2016 08:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kogzp69ooCTJ for ; Tue, 12 Jul 2016 08:43:15 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 2FB8512D9DD for ; Tue, 12 Jul 2016 08:34:34 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id x130so27106374vkc.0 for ; Tue, 12 Jul 2016 08:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MCaHradSXSTh4/pk6yWYNH2LPr/NRcZ3maR6JSfldUU=; b=dP8F/DvJLsHXGf0N8UYFYoNsOvomgqveS9Lsm+0qPugcmE9YrZASDEpTroGvKYzNNa Q55R/JhnBc15D7U2vod5LqnA1wmU0FEAWYzwqnLQF2MwaXAC7xpxZMUXQGIaClaswL5U KUVhNjq4XiUkknfIxJgjQIy80Eqoaz8/lq16cE7ovIiWM/EsRzzSV5kCg8+ZaYHaGX5J ttRSCV0u+h7H5rZCDfwJWZnrKUsX9KnJfxGjk+nfgdQZF7lXGLU5D6nh4Xm7ayLCcnv2 0izk4OkqJXEPsA9O0gB+7r3/myD/1L9odlaCe4hZuCP2OBhfR5N1QoptmtfmbIx5d2Fs n5Uw== 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; bh=MCaHradSXSTh4/pk6yWYNH2LPr/NRcZ3maR6JSfldUU=; b=Q7YeQU6zaacSkDVQ7ZLa9Xisiylp7t54rCUM7OZ1LqCjJAHA9wmCDkLhOSf0XVv+z4 rM0gd8Yr5oVipaKnyjNRF6oUsKEDlIm2hqvFSjTKARy4U+WW7j4jbdwaom9QBwYLJd4/ ghVfduFuDKhDm04QCK/uvq3EwKe3H+W/Z7y+SQzz/gnj+KE78ONjEOIf4WhwxNq1vEJN YQw/OcdtvlOxDXhfAtcBnJbAQRwmQa9BAgTI+hIjc4zAFQF6gszy3Sy3k1RADDxp9rMl MlYskksW5P5HjnInkKXwNFsf7CCptjrkdmJeCoI0xd/CUNT4N5YSLx4sVwTsdfCmcU8/ Nztg== X-Gm-Message-State: ALyK8tJ2SBtGWbQ5jFXV8R5DuYh6uEp3FAJmV5KPTDWtQGuV7Oh5x3VHYi6X0a7LLNTZHVZF0UXI2fWrGsZJXqzL X-Received: by 10.176.0.56 with SMTP id 53mr1478924uai.113.1468337673093; Tue, 12 Jul 2016 08:34:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.83.194 with HTTP; Tue, 12 Jul 2016 08:34:32 -0700 (PDT) In-Reply-To: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> References: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> From: Bill Cox Date: Tue, 12 Jul 2016 08:34:32 -0700 Message-ID: To: Douglas Stebila Content-Type: multipart/alternative; boundary=001a113db6da6a84ee05377201eb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:43:16 -0000 --001a113db6da6a84ee05377201eb Content-Type: text/plain; charset=UTF-8 IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change. I think most applications currently using EKM will break if the EKM values change after a PSK resume. However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets by 32 bytes, and complicate the state machine. I think this could partially be addressed by enhancing the custom extension APIs found in popular TLS libraries to enable custom extensions to specify state that needs to be remembered on a resume. That, in combination with requiring extensions to be sent and processed in order of extension number, could enable a lot of this complexity to be taken out of the main TLS code, and only connections that actually need such extensions would see the increase in ticket size. Could something like this could work well for channel binding? Bill --001a113db6da6a84ee05377201eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IIRC, in TLS 1.2 the same keys = are used after resumption, and EKM values do not change.=C2=A0 I think most= applications currently using EKM will break if the EKM values change after= a PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will b= loat tickets by 32 bytes, and complicate the state machine.=C2=A0 I think t= his could partially be addressed by enhancing the custom extension APIs fou= nd in popular TLS libraries to enable custom extensions to specify state th= at needs to be remembered on a resume.=C2=A0 That, in combination with requ= iring extensions to be sent and processed in order of extension number, cou= ld enable a lot of this complexity to be taken out of the main TLS code, an= d only connections that actually need such extensions would see the increas= e in ticket size.

Could something like this could work well for channel bind= ing?

B= ill
--001a113db6da6a84ee05377201eb-- From nobody Tue Jul 12 08:48:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E812D7FC for ; Tue, 12 Jul 2016 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gWxAMLNMFht for ; Tue, 12 Jul 2016 08:48:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C150012D1DC for ; Tue, 12 Jul 2016 08:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6738; q=dns/txt; s=iport; t=1468338333; x=1469547933; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CQfMJIxJMImv3DQhjBnlC7eWotzbNPBHLOfuc3RqutY=; b=NO2wrU89zfD0Qb3QMcJZdQIvmEX0iSj8RdtnUDruJnLX+nVeGYuMx6Zp Hd/KfYIySUETmZ4Kjopa+A+MTdws9X8kDbUj0yvWs1Qenc6+HJ+P9hxOS nqlzK43xXjE2YvlYW0gS+jckLHYIP4kegJnSUpq2VxDqj7vmGDNk+md91 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AgCcD4VX/49dJa1cDgiDKFZ8BrkDg?= =?us-ascii?q?XkihXYCgTU4FAEBAQEBAQFlJ4RcAQEDAgEBbBcEAgEIEQMBAQEBJwcnCxQJCAI?= =?us-ascii?q?EARIIDIgcDsAQAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EHhMXMYUjBYgfh?= =?us-ascii?q?iCKXAGGDoJ6hUSBcU6HOYU9hluJOAEeNoIGH4ERO24BAYdgRH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="296202809" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 15:45:32 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6CFjW9f016292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 15:45:32 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 11:45:30 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 11:45:30 -0400 From: "Scott Fluhrer (sfluhrer)" To: "Dang, Quynh (Fed)" , "Paterson, Kenny" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26epuiTmg3+eU0yJfAjoGH7+FKAVB4KAgAAQs4CAABMcgP//w17w Date: Tue, 12 Jul 2016 15:45:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:48:15 -0000 Actually, a more correct way of viewing the limit would be 2^52 encrypted d= ata bytes. To come to the 2^38 record limit, they assume that each record i= s the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take over a yea= r to encrypt that much data... > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed) > Sent: Tuesday, July 12, 2016 11:12 AM > To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >=20 > Hi Kenny, >=20 > The indistinguishability-based security notion in the paper is a stronger > security notion than the (old) traditional confidentiality notion. >=20 >=20 > (*) Indistinguishability notion (framework) guarantees no other attacks c= an > be better than the indistinguishability bound. Intuitively, you can=B9t a= ttack if > you can=B9t even tell two things are different or not. So, being able to = say two > things are different or not is the minimal condition to lead to any attac= k. >=20 > The traditional confidentiality definition is that knowing only the ciphe= rtexts, > the attacker can=B9t know any content of the corresponding plaintexts wit= h a > greater probability than some value and this value depends on the particu= lar > cipher. Of course, the maximum amount of data must not be more than > some limit under a given key which also depends on the cipher. >=20 > For example, with counter mode AES_128, Let=B9s say encrypting 2^70 input > blocks with a single key. With the 2^70 ciphertext blocks alone (each blo= ck is > 128 bits), I don=B9t think one can find out any content of any of the pla= intexts. > The chance for knowing any block of the plaintexts is > 1/(2^128) in this case. >=20 > I support the strongest indistinguishability notion mentioned in (*) abov= e, > but in my opinion we should provide good description to the users. > That is why I support the limit around 2^38 records. >=20 > Regards, > Quynh. >=20 > On 7/12/16, 10:03 AM, "Paterson, Kenny" > wrote: >=20 > >Hi Quynh, > > > >This indistinguishability-based security notion is the confidentiality > >notion that is by now generally accepted in the crypto community. > >Meeting it is sufficient to guarantee security against many other forms > >of attack on confidentiality, which is one of the main reasons we use it= . > > > >You say that an attack in the sense implied by breaking this notion > >does not break confidentiality. Can you explain what you mean by > >"confidentiality", in a precise way? I can then try to tell you whether > >this notion will imply yours. > > > >Regards > > > >Kenny > > > >On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)" > > wrote: > > > >>Hi Eric and all, > >> > >> > >>In my opinion, we should give better information about data limit for > >>AES_GCM in TLS 1.3 instead of what is current in the draft 14. > >> > >> > >>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what > >>is called confidentiality attack is the known plaintext > >>differentiality attack where the attacker has/chooses two plaintexts, > >>send them to the AES-encryption oracle. The oracle encrypts one of > >>them, then sends the ciphertext to the attacker. After seeing the > >>ciphertext, the attacker has some success probability of telling which > >>plaintext was encrypted and this success probability is in the column > >>called =B3Attack Success Probability=B2 in Table 1. This attack does n= ot > >>break confidentiality. > >> > >> > >>If the attack above breaks one of security goal(s) of your individual > >>system, then making success probability of that attack at 2^(-32) max > >>is enough. In that case, the Max number of records is around 2^38. > >> > >> > >> > >> > >>Regards, > >>Quynh. > >> > >> > >> > >> > >> > >> > >>Date: Monday, July 11, 2016 at 3:08 PM > >>To: "tls@ietf.org" > >>Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt > >> > >> > >> > >>Folks, > >> > >> > >>I've just submitted draft-ietf-tls-tls13-14.txt and it should show up > >>on the draft repository shortly. In the meantime you can find the > >>editor's copy in the usual location at: > >> > >> > >> http://tlswg.github.io/tls13-spec/ > >> > >> > >>The major changes in this document are: > >> > >> > >>* A big restructure to make it read better. I moved the Overview > >> to the beginning and then put the document in a more logical > >> order starting with the handshake and then the record and > >> alerts. > >> > >> > >>* Totally rewrote the section which used to be called "Security > >> Analysis" and is now called "Overview of Security Properties". > >> This section is still kind of a hard hat area, so PRs welcome. > >> In particular, I know I need to beef up the citations for the > >> record layer section. > >> > >> > >>* Removed the 0-RTT EncryptedExtensions and moved ticket_age > >> into the ClientHello. This quasi-reverts a change in -13 that > >> made implementation of 0-RTT kind of a pain. > >> > >> > >>As usual, comments welcome. > >>-Ekr > >> > >> > >> > >> > >> > >> > >>* Allow cookies to be longer (*) > >> > >> > >>* Remove the "context" from EarlyDataIndication as it was undefined > >> and nobody used it (*) > >> > >> > >>* Remove 0-RTT EncryptedExtensions and replace the ticket_age > >>extension > >> with an obfuscated version. Also necessitates a change to > >> NewSessionTicket (*). > >> > >> > >>* Move the downgrade sentinel to the end of ServerHello.Random > >> to accomodate tlsdate (*). > >> > >> > >>* Define ecdsa_sha1 (*). > >> > >> > >>* Allow resumption even after fatal alerts. This matches current > >> practice. > >> > >> > >>* Remove non-closure warning alerts. Require treating unknown alerts > >>as > >> fatal. > >> > >> > >>* Make the rules for accepting 0-RTT less restrictive. > >> > >> > >>* Clarify 0-RTT backward-compatibility rules. > >> > >> > >>* Clarify how 0-RTT and PSK identities interact. > >> > >> > >>* Add a section describing the data limits for each cipher. > >> > >> > >>* Major editorial restructuring. > >> > >> > >>* Replace the Security Analysis section with a WIP draft. > >> > >> > >>(*) indicates changes to the wire protocol which may require > >>implementations > >> to update. > >> > >> > >> > >> > >> > > >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 12 08:54:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9208012D08D for ; Tue, 12 Jul 2016 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcW-azaBG4Te for ; Tue, 12 Jul 2016 08:54:02 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 C0FDC12B006 for ; Tue, 12 Jul 2016 08:54:02 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id j17so17860361ywg.0 for ; Tue, 12 Jul 2016 08:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QbbAx9UdcTtR1d1PxlrxJhtnSpzTIrME8RZ8QWK5PYs=; b=l+58LIBopSBmZKmtTk/kRcv15p6+4IhcClW0zxQzm6frnImkXvA3IEBATTYlB02Ayz tqvS9GGlHpNQjCn28Ehgy5J9j9XZ8XdYOWzd/UDmO1TP5uACuwd8NS7HnYaIc6+ASQFd 0LZHWAps6FCC1YayWtO+coCH0tCUMX2tdl2Uofk5Wvwpdsd4Da9QjN/p9/NXO/rdz3dO uq7yURT+Jo/ECaX87GLyNJg5airmcSxBiYZUvGQt+T94OSww2Ws0bKxnbvLV6M7MabH5 h/MzsiLuNLw0C4kxZlUtaQ5MdFWbeOZoPwSaeDbHYSTIzU2YIdVbQ9tt/+l/XjrQsuYG K/bQ== 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; bh=QbbAx9UdcTtR1d1PxlrxJhtnSpzTIrME8RZ8QWK5PYs=; b=kPo36v4Xx1GHyGkUZsjRAvPiY2W1h9dVKm1Wd/12xFVZgO9lDmPEbhMkkbjOkdXfbm qHuekma4GxwC8LJNaODTSerQPH1Rmnsm1J+j3RF9ZkiRWZoANiY7RvzUuqUJZ1SkUkP/ xetJMm/dP/R8XVRz02wRoWs9Oa4inrt+jQj+L7K8EGA9/XxmfRiB+sT5cPXSSDcaAzmI skD7xcI0pUnB0Tm7nh0rC/TVNmw77+DCFMapWe0VSYMWVk9mjGS08zDMgSHlzNLagpln 0pFgn3ToMrDt/C6yIHJag73UPsKLEMz/ufrEhIUH6EX1YIwlAnlansC/Qg1wfm+zXBE2 VAWw== X-Gm-Message-State: ALyK8tLtHmuzHzUd3Ja1aOFo8QSh2BBoaANVQyrQ1WU1kYQwGSMh+MdVLh0iNCqHl7g03sMfitWDiEAVaEHC0Q== X-Received: by 10.13.199.68 with SMTP id j65mr2247765ywd.289.1468338841980; Tue, 12 Jul 2016 08:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 12 Jul 2016 08:53:22 -0700 (PDT) In-Reply-To: References: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> From: Eric Rescorla Date: Tue, 12 Jul 2016 08:53:22 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114dfc4a1648970537724753 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:54:04 -0000 --001a114dfc4a1648970537724753 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 8:34 AM, Bill Cox wrote: > IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values > do not change. > In TLS 1.2, the EKM == MS but the exporter includes the randoms: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length] This means that if you resume, you should get different exported values. -Ekr I think most applications currently using EKM will break if the EKM values > change after a PSK resume. > > However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets > by 32 bytes, and complicate the state machine. I think this could > partially be addressed by enhancing the custom extension APIs found in > popular TLS libraries to enable custom extensions to specify state that > needs to be remembered on a resume. That, in combination with requiring > extensions to be sent and processed in order of extension number, could > enable a lot of this complexity to be taken out of the main TLS code, and > only connections that actually need such extensions would see the increase > in ticket size. > > Could something like this could work well for channel binding? > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dfc4a1648970537724753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 8:34 AM, Bill Cox <waywardgeek@google.com= > wrote:
IIRC, in TLS 1.2 the same keys are used after resumption, and E= KM values do not change.=C2=A0

In TLS 1.2, the EKM =3D=3D MS but the exporter includes the randoms:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRF(Secur= ityParameters.master_secret, label,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SecurityParameters.client_random +
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SecurityParameters.serv= er_random +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0context_value_length + context_value
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)[length]

Thi= s means that if you resume, you should get different exported values.
=

-Ekr



=
I think most a= pplications currently using EKM will break if the EKM values change after a= PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will blo= at tickets by 32 bytes, and complicate the state machine.=C2=A0 I think thi= s could partially be addressed by enhancing the custom extension APIs found= in popular TLS libraries to enable custom extensions to specify state that= needs to be remembered on a resume.=C2=A0 That, in combination with requir= ing extensions to be sent and processed in order of extension number, could= enable a lot of this complexity to be taken out of the main TLS code, and = only connections that actually need such extensions would see the increase = in ticket size.

Could something like this could work well for channel binding= ?
=
Bill

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


--001a114dfc4a1648970537724753-- From nobody Tue Jul 12 08:56:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBDA12D181 for ; Tue, 12 Jul 2016 08:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7hcJa4IXZlF for ; Tue, 12 Jul 2016 08:56:45 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B6B12D17B for ; Tue, 12 Jul 2016 08:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=weXNCWpiqvykR7Mkg34lIj0HiElCSFsN3dizZSc0ZHQ=; b=jNJY/lMlv60IzPRZXLLB1XJ6kf7QQEfCz8Q94Ypxed+knIS3MSXjxzk++dvBSQNElUSmRk72YAcsscqlLhEmdxkKLY4y0ZLEbkXP0yhhulQNxGLiE2r47FSa8EJbOt8trYGO9K1vbUI5YvT39mXU0480Y265nmVy/gXYNkczKQQ= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Tue, 12 Jul 2016 15:56:38 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 15:56:38 +0000 From: Andrei Popov To: Bill Cox , Douglas Stebila Thread-Topic: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? Thread-Index: AQHR26wJxPHbdy3C0U+IgpZY4K5NtqAT3JCggAD3nYCAABpAAIAABckQ Date: Tue, 12 Jul 2016 15:56:38 +0000 Message-ID: References: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [50.46.229.189] x-ms-office365-filtering-correlation-id: fee531b5-f441-4805-eb16-08d3aa6d1c18 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:FOb6blwJYZCX5YSsunqyS6pl0/HsieM/WyavNQanOhuSCFo286V2ekAPwKQzxuAPZElrxxfMZTnswRyQVd16jfAT8H5sYO2A86sm30MUR64fTUrBzfFtQYBsFKGEsEN7EKUvrUB0eap8G1uLgnRCUOmqiHju05dqI1lxfRQ47fbA+Cgs9ntmyBYPVqM6kfbuMmpuopqic9RnjEeaV1t9IwRcCM9DAXg8j0MErf+DKkiDvkFTDd17CvzaRuGa83a9gZx3JJE7pHEPD/itwSquU5AEkumMfxiLaHB14knYnPgVUfJM4F99rGyBjCVY6H79VhH3fD4NEnSlAkl+mSJmaw==; 5:FjT+PeDoMtiw1ozHvo/X+lZpP66a271gECsVjwUZmRZ+0IaphHzP9YzXHgQs8oOInd04kR+SeFa6vRHfDAI5MZLZWpzh3sYdn0HFc5+VfNd2qK2BKKGcvnCxZDcugHDvfE7qLDz+LtHo9WJ6i0Ao2g==; 24:lbmlbDitzGkV5MdUPudz8mf5YXCX7Qe0msGkxFWffeQpUgkoki5u0XCt7chscZTpyskKjY1gLB3lObjX5aTWdao12PPsbgehi5gHU0O5t3w=; 7:aDMfqaL7SxUh/0Rt5PypvSOmguPQG3hlf39BleMDOKLIhbT5mP8bZzfGHAzWvjoqniisrZcz9+QCrR5WS5guJ0POxHXDpnRoG4Blp+ZfrQZmPafoY1imFPjVRQ6sfkL/P+orGp+6Hle7ORIQXuqvOpcMP9yGA6TZnCKSmRmFqy4T0SLv1RguNV2YqW91WiQOf5FfmN6QP4wGOXCmhA+Y/MJhmtE/yBoj8xNDTz+CspJyEWbOb84v5OkfBozldYSn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(586003)(19625215002)(74316002)(15650500001)(19300405004)(15975445007)(66066001)(99286002)(5002640100001)(2950100001)(122556002)(106356001)(19580405001)(2900100001)(106116001)(19580395003)(92566002)(8936002)(9686002)(2420400007)(7736002)(105586002)(7846002)(77096005)(5003600100003)(7696003)(16236675004)(10090500001)(2906002)(97736004)(33656002)(10710500007)(102836003)(50986999)(3280700002)(790700001)(6116002)(4326007)(3660700001)(5001770100001)(10400500002)(5005710100001)(76576001)(68736007)(76176999)(54356999)(8676002)(10290500002)(101416001)(11100500001)(86612001)(189998001)(3846002)(87936001)(93886004)(86362001)(81156014)(81166006)(7110500001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21559FF8FA1DBF9128F7285D8C300CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 15:56:38.7462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:56:48 -0000 --_000_CY1PR03MB21559FF8FA1DBF9128F7285D8C300CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElJUkMsIGluIFRMUyAxLjIgdGhlIHNhbWUga2V5cyBhcmUgdXNlZCBhZnRlciByZXN1bXB0 aW9uLCBhbmQgRUtNIHZhbHVlcyBkbyBub3QgY2hhbmdlLg0KSXMgdGhpcyBjb3JyZWN0PyBFS00g bWl4ZXMgaW4gY2xpZW50IGFuZCBzZXJ2ZXIgcmFuZG9tcywgd2hpY2ggYXJlIGhvcGVmdWxseSBk aWZmZXJlbnQgaW4gZWFjaCByZXN1bXB0aW9uLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9t OiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5 LCBKdWx5IDEyLCAyMDE2IDg6MzUgQU0NClRvOiBEb3VnbGFzIFN0ZWJpbGEgPGRzdGViaWxhQGdt YWlsLmNvbT4NCkNjOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPjsg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IHRsc0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtUTFNdIFNob3VsZCBleHBvcnRlciBrZXlzIGJlIHVwZGF0ZWQgd2l0aCBw b3N0LWhhbmRzaGFrZSBhdXRoZW50aWNhdGlvbiBhbmQvb3IgS2V5VXBkYXRlPw0KDQpJSVJDLCBp biBUTFMgMS4yIHRoZSBzYW1lIGtleXMgYXJlIHVzZWQgYWZ0ZXIgcmVzdW1wdGlvbiwgYW5kIEVL TSB2YWx1ZXMgZG8gbm90IGNoYW5nZS4gIEkgdGhpbmsgbW9zdCBhcHBsaWNhdGlvbnMgY3VycmVu dGx5IHVzaW5nIEVLTSB3aWxsIGJyZWFrIGlmIHRoZSBFS00gdmFsdWVzIGNoYW5nZSBhZnRlciBh IFBTSyByZXN1bWUuDQoNCkhvd2V2ZXIsIGZvcmNpbmcgVExTIDEuMyB0byByZW1lbWJlciBhIDI1 Ni1iaXQgRUtNIHNlZWQgd2lsbCBibG9hdCB0aWNrZXRzIGJ5IDMyIGJ5dGVzLCBhbmQgY29tcGxp Y2F0ZSB0aGUgc3RhdGUgbWFjaGluZS4gIEkgdGhpbmsgdGhpcyBjb3VsZCBwYXJ0aWFsbHkgYmUg YWRkcmVzc2VkIGJ5IGVuaGFuY2luZyB0aGUgY3VzdG9tIGV4dGVuc2lvbiBBUElzIGZvdW5kIGlu IHBvcHVsYXIgVExTIGxpYnJhcmllcyB0byBlbmFibGUgY3VzdG9tIGV4dGVuc2lvbnMgdG8gc3Bl Y2lmeSBzdGF0ZSB0aGF0IG5lZWRzIHRvIGJlIHJlbWVtYmVyZWQgb24gYSByZXN1bWUuICBUaGF0 LCBpbiBjb21iaW5hdGlvbiB3aXRoIHJlcXVpcmluZyBleHRlbnNpb25zIHRvIGJlIHNlbnQgYW5k IHByb2Nlc3NlZCBpbiBvcmRlciBvZiBleHRlbnNpb24gbnVtYmVyLCBjb3VsZCBlbmFibGUgYSBs b3Qgb2YgdGhpcyBjb21wbGV4aXR5IHRvIGJlIHRha2VuIG91dCBvZiB0aGUgbWFpbiBUTFMgY29k ZSwgYW5kIG9ubHkgY29ubmVjdGlvbnMgdGhhdCBhY3R1YWxseSBuZWVkIHN1Y2ggZXh0ZW5zaW9u cyB3b3VsZCBzZWUgdGhlIGluY3JlYXNlIGluIHRpY2tldCBzaXplLg0KDQpDb3VsZCBzb21ldGhp bmcgbGlrZSB0aGlzIGNvdWxkIHdvcmsgd2VsbCBmb3IgY2hhbm5lbCBiaW5kaW5nPw0KDQpCaWxs DQo= --_000_CY1PR03MB21559FF8FA1DBF9128F7285D8C300CY1PR03MB2155namp_ 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 aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3MDk4NDYyMTg7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzU3NDk1OTYy IC0xNjI3NzU3MTYyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7D mDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SUlSQywgaW4gVExTIDEuMiB0aGUg c2FtZSBrZXlzIGFyZSB1c2VkIGFmdGVyIHJlc3VtcHRpb24sIGFuZCBFS00gdmFsdWVzIGRvIG5v dCBjaGFuZ2UuJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklzIHRoaXMgY29ycmVjdD8gRUtN IG1peGVzIGluIGNsaWVudCBhbmQgc2VydmVyIHJhbmRvbXMsIHdoaWNoIGFyZSBob3BlZnVsbHkg ZGlmZmVyZW50IGluIGVhY2ggcmVzdW1wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgQ294IFttYWls dG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBK dWx5IDEyLCAyMDE2IDg6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IERvdWdsYXMgU3RlYmlsYSAmbHQ7 ZHN0ZWJpbGFAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtUTFNdIFNob3VsZCBleHBvcnRlciBrZXlzIGJlIHVwZGF0ZWQgd2l0aCBwb3N0LWhhbmRz aGFrZSBhdXRoZW50aWNhdGlvbiBhbmQvb3IgS2V5VXBkYXRlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JSVJDLCBpbiBUTFMgMS4yIHRoZSBzYW1lIGtleXMg YXJlIHVzZWQgYWZ0ZXIgcmVzdW1wdGlvbiwgYW5kIEVLTSB2YWx1ZXMgZG8gbm90IGNoYW5nZS4m bmJzcDsgSSB0aGluayBtb3N0IGFwcGxpY2F0aW9ucyBjdXJyZW50bHkgdXNpbmcgRUtNIHdpbGwg YnJlYWsgaWYgdGhlIEVLTSB2YWx1ZXMgY2hhbmdlIGFmdGVyIGEgUFNLIHJlc3VtZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwg Zm9yY2luZyBUTFMgMS4zIHRvIHJlbWVtYmVyIGEgMjU2LWJpdCBFS00gc2VlZCB3aWxsIGJsb2F0 IHRpY2tldHMgYnkgMzIgYnl0ZXMsIGFuZCBjb21wbGljYXRlIHRoZSBzdGF0ZSBtYWNoaW5lLiZu YnNwOyBJIHRoaW5rIHRoaXMgY291bGQgcGFydGlhbGx5IGJlIGFkZHJlc3NlZCBieSBlbmhhbmNp bmcgdGhlIGN1c3RvbSBleHRlbnNpb24gQVBJcyBmb3VuZCBpbiBwb3B1bGFyIFRMUyBsaWJyYXJp ZXMgdG8NCiBlbmFibGUgY3VzdG9tIGV4dGVuc2lvbnMgdG8gc3BlY2lmeSBzdGF0ZSB0aGF0IG5l ZWRzIHRvIGJlIHJlbWVtYmVyZWQgb24gYSByZXN1bWUuJm5ic3A7IFRoYXQsIGluIGNvbWJpbmF0 aW9uIHdpdGggcmVxdWlyaW5nIGV4dGVuc2lvbnMgdG8gYmUgc2VudCBhbmQgcHJvY2Vzc2VkIGlu IG9yZGVyIG9mIGV4dGVuc2lvbiBudW1iZXIsIGNvdWxkIGVuYWJsZSBhIGxvdCBvZiB0aGlzIGNv bXBsZXhpdHkgdG8gYmUgdGFrZW4gb3V0IG9mIHRoZSBtYWluIFRMUw0KIGNvZGUsIGFuZCBvbmx5 IGNvbm5lY3Rpb25zIHRoYXQgYWN0dWFsbHkgbmVlZCBzdWNoIGV4dGVuc2lvbnMgd291bGQgc2Vl IHRoZSBpbmNyZWFzZSBpbiB0aWNrZXQgc2l6ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bGQgc29tZXRoaW5nIGxpa2UgdGhpcyBjb3Vs ZCB3b3JrIHdlbGwgZm9yIGNoYW5uZWwgYmluZGluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB21559FF8FA1DBF9128F7285D8C300CY1PR03MB2155namp_-- From nobody Tue Jul 12 09:33:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6505012D550 for ; Tue, 12 Jul 2016 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8AyVw0sCWqI for ; Tue, 12 Jul 2016 09:33:04 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50066.outbound.protection.outlook.com [40.107.5.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2C912D549 for ; Tue, 12 Jul 2016 09:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pO5XCHZu4GzIjTFCO3dwQBGTdCQE4DYq2MymEbf3qIo=; b=vcJ7Fydikwp4SdQxDRFRT8HA18gL/MyIxJpmpju050Ybmu/eLomehX5SQ/5cWRCNDtU7/ncUO4MQUuDaR79ucls3Yq3zegV5Yi86vkmgKC6DipJej8ZWmt1yTouCJZ0yxgRfN4C1nygUazXr/iPXi9YTrlqxGYxqRHk5DZ7VG3M= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 16:33:00 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 16:33:00 +0000 From: "Paterson, Kenny" To: "Scott Fluhrer (sfluhrer)" , "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAACUMAgAAetIA= Date: Tue, 12 Jul 2016 16:33:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 93cad754-6898-4503-ab6c-08d3aa7230a0 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:I1i+unVw7BO9g8kCMuWNy8QDS9oK1qFrNt41L4GdTNFqMEVMauP3OeBO2imZnAfuuNhBRJzzPVG6mxvzbX2LxOe2t07DVdcsrGWhRsUY9vsESYYleaTzGwoWMuNmRavk66UC+rJao/04ehCFPpCf6Iyb645Nx0lyBj3NF/6BFzgmLRbaferopTBakiFGG/FCtITdeobRRKH9OgT+L15dA2cEcDK34D/8N6EY5lJbZqJoACbKchH8khqfPyZ9Gp//PdwtvAJ74uTHfh8/L6UvE8S+kXa4hCPvqvvrn7OlFAg=; 5:0RU3ns+BxZBEQDF076wwOBGQt6Ow/k7Nm5lRWb2VpUjidsExymO1ZkNsXfTf9/vh+RbWh/hlkwGS06XGX9Qku80BdeZXHgFEFNN93yMZv0hEvm5R4TcRmwv0U1UiUG9TAJCxy+R/82TrvJizK6IMxw==; 24:oC9tBczyg1MmTnUUs6GEHHLpcKd/1IfnDAfYHEJ7cB9qVK/GcsnzP20kj9NtPMhdbboQg/cD5aclVgFknXdfmwT/+t1kZV8JjnZIo4DzL3U=; 7:RIMxHHIZXu9oGL7aDegi45rby/27Cnb+iNRQ9tr0rRQBNohw/4MYJ28zfb/aWD2wR8Dy4neMwdgHRwNvoWlLnxiKD2PKyZi5hmVabBxxFyUtC0eKuYmCUclrsmY5QcJ0s4QObQf8KfUsPz7GiCIdbyOlQpoeWWbw/2Ba+Q7e90ehf2jbIeP3i2csA/TSiqO8yZ/EYwH8ao0aHT0ZQiECYmQEnPGhpogKNnByb2BTAaeW0fJ+AH25H4fTccPfQWsQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(55674003)(189002)(199003)(377454003)(13464003)(101416001)(66066001)(305945005)(36756003)(81166006)(8666005)(2950100001)(15975445007)(2900100001)(54356999)(76176999)(50986999)(7736002)(74482002)(8936002)(2501003)(83506001)(7846002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(3846002)(230783001)(106116001)(2906002)(6116002)(68736007)(106356001)(102836003)(87936001)(105586002)(86362001)(3280700002)(107886002)(10400500002)(3660700001)(5001770100001)(97736004)(189998001)(11100500001)(4001350100001)(93886004)(8676002)(5002640100001)(586003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <03E0CE73FCBBAA4B9B08081EAD47F15F@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 16:33:00.6960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:33:07 -0000 VW5mb3J0dW5hdGVseSwgdGhhdCdzIG5vdCBxdWl0ZSB0aGUgcmlnaHQgaW50ZXJwcmV0YXRpb24u IFRoZSBib3VuZHMgb25lDQpvYnRhaW5zIGRlcGVuZCBvbiBib3RoIHRoZSB0b3RhbCBhbW91bnQg b2YgZGF0YSBlbmNyeXB0ZWQgQU5EIHRoZSBudW1iZXINCm9mIGVuY3J5cHRpb24gcXVlcmllcyB0 aGUgYWR2ZXJzYXJ5IGlzIGFsbG93ZWQgdG8gbWFrZSB0byBBRVMtR0NNIHVuZGVyDQp0aGUgKHNp bmdsZSkgdGFyZ2V0IGtleS4NCg0KV2UgYXNzdW1lZCBlYWNoIHJlY29yZCB3YXMgMl4xNCBieXRl cyBpbiBzaXplIHRvIHNpbXBsaWZ5IHRoZSBlbnN1aW5nDQphbmFseXNpcywgYW5kIHRvIGVuYWJs ZSB1cyB0byBmb2N1cyBvbiBob3cgdGhlIHNlY3VyaXR5IGJvdW5kcyB0aGVuIGRlcGVuZA0Kb24g dGhlIG51bWJlciBvZiByZWNvcmRzIGVuY3J5cHRlZC4gU2VlIGVxdWF0aW9uICg1KSBhbmQgVGFi bGUgMiBpbiB0aGUNCm5vdGUgYXQgDQoNCglodHRwOi8vd3d3LmlzZy5yaHVsLmFjLnVrL35rcC9U TFMtQUVib3VuZHMucGRmLg0KDQpJbiBzaG9ydCwgdGhlIHNlY3VyaXR5IGJvdW5kIGRvZXMgbm90 IG5lY2Vzc2FyaWx5IGhvbGQgZm9yIEFOWSAyXjUyDQplbmNyeXB0ZWQgZGF0YSBieXRlcy4gRm9y IGV4YW1wbGUsIGlmIHRoZSBhdHRhY2tlciBlbmNyeXB0ZWQgMl41MiByZWNvcmRzDQpvZiBzaXpl IDEgKCEpIHRoZW4gZXF1YXRpb24gKDUpIHdvdWxkIHRlbGwgdXMgYWxtb3N0IG5vdGhpbmcgdXNl ZnVsIGF0IGFsbA0KYWJvdXQgc2VjdXJpdHkuDQoNCkZpbmFsbHksIHlvdSB3cml0ZSAidG8gY29t ZSB0byB0aGUgMl4zOCByZWNvcmQgbGltaXQsIHRoZXkgYXNzdW1lIHRoYXQNCmVhY2ggcmVjb3Jk IGlzIHRoZSBtYXhpbXVtIDJeMTQgYnl0ZXMiLiBGb3IgY2xhcml0eSwgd2UgZGlkIG5vdCByZWNv bW1lbmQNCmEgbGltaXQgb2YgMl4zOCByZWNvcmRzLiBUaGF0J3MgUXV5bmgncyBwcmVmZXJyZWQg bnVtYmVyLCBhbmQgaXMNCnVuc3VwcG9ydGVkIGJ5IG91ciBhbmFseXNpcy4NCg0KQ2hlZXJzLA0K DQpLZW5ueSANCg0KDQpPbiAxMi8wNy8yMDE2IDE2OjQ1LCAiU2NvdHQgRmx1aHJlciAoc2ZsdWhy ZXIpIiA8c2ZsdWhyZXJAY2lzY28uY29tPiB3cm90ZToNCg0KPkFjdHVhbGx5LCBhIG1vcmUgY29y cmVjdCB3YXkgb2Ygdmlld2luZyB0aGUgbGltaXQgd291bGQgYmUgMl41MiBlbmNyeXB0ZWQNCj5k YXRhIGJ5dGVzLiBUbyBjb21lIHRvIHRoZSAyXjM4IHJlY29yZCBsaW1pdCwgdGhleSBhc3N1bWUg dGhhdCBlYWNoDQo+cmVjb3JkIGlzIHRoZSBtYXhpbXVtIDJeMTQgYnl0ZXMuICBPZiBjb3Vyc2Us IGF0IGEgMUdicHMgcmF0ZSwgaXQnZCB0YWtlDQo+b3ZlciBhIHllYXIgdG8gZW5jcnlwdCB0aGF0 IG11Y2ggZGF0YS4uLg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuZywgUXV5 bmggKEZlZCkNCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTIsIDIwMTYgMTE6MTIgQU0NCj4+IFRv OiBQYXRlcnNvbiwgS2Vubnk7IERhbmcsIFF1eW5oIChGZWQpOyBFcmljIFJlc2NvcmxhOyB0bHNA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbVExTXSBOZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdGxz LXRsczEzLTE0LnR4dA0KPj4gDQo+PiBIaSBLZW5ueSwNCj4+IA0KPj4gVGhlIGluZGlzdGluZ3Vp c2hhYmlsaXR5LWJhc2VkIHNlY3VyaXR5IG5vdGlvbiBpbiB0aGUgcGFwZXIgaXMgYQ0KPj5zdHJv bmdlcg0KPj4gc2VjdXJpdHkgbm90aW9uIHRoYW4gdGhlIChvbGQpIHRyYWRpdGlvbmFsIGNvbmZp ZGVudGlhbGl0eSBub3Rpb24uDQo+PiANCj4+IA0KPj4gKCopIEluZGlzdGluZ3Vpc2hhYmlsaXR5 IG5vdGlvbiAoZnJhbWV3b3JrKSBndWFyYW50ZWVzIG5vIG90aGVyIGF0dGFja3MNCj4+Y2FuDQo+ PiBiZSBiZXR0ZXIgdGhhbiB0aGUgaW5kaXN0aW5ndWlzaGFiaWxpdHkgYm91bmQuIEludHVpdGl2 ZWx5LCB5b3UgY2Fuwrl0DQo+PmF0dGFjayBpZg0KPj4geW91IGNhbsK5dCBldmVuIHRlbGwgdHdv IHRoaW5ncyBhcmUgZGlmZmVyZW50IG9yIG5vdC4gU28sIGJlaW5nIGFibGUgdG8NCj4+c2F5IHR3 bw0KPj4gdGhpbmdzIGFyZSBkaWZmZXJlbnQgb3Igbm90IGlzIHRoZSBtaW5pbWFsIGNvbmRpdGlv biB0byBsZWFkIHRvIGFueQ0KPj5hdHRhY2suDQo+PiANCj4+IFRoZSB0cmFkaXRpb25hbCBjb25m aWRlbnRpYWxpdHkgZGVmaW5pdGlvbiBpcyB0aGF0IGtub3dpbmcgb25seSB0aGUNCj4+Y2lwaGVy dGV4dHMsDQo+PiB0aGUgYXR0YWNrZXIgY2Fuwrl0IGtub3cgYW55IGNvbnRlbnQgb2YgdGhlIGNv cnJlc3BvbmRpbmcgcGxhaW50ZXh0cw0KPj53aXRoIGENCj4+IGdyZWF0ZXIgcHJvYmFiaWxpdHkg dGhhbiBzb21lIHZhbHVlIGFuZCB0aGlzIHZhbHVlIGRlcGVuZHMgb24gdGhlDQo+PnBhcnRpY3Vs YXINCj4+IGNpcGhlci4gT2YgY291cnNlLCB0aGUgbWF4aW11bSBhbW91bnQgb2YgZGF0YSBtdXN0 IG5vdCBiZSBtb3JlIHRoYW4NCj4+IHNvbWUgbGltaXQgdW5kZXIgYSBnaXZlbiBrZXkgd2hpY2gg YWxzbyBkZXBlbmRzIG9uIHRoZSBjaXBoZXIuDQo+PiANCj4+IEZvciBleGFtcGxlLCB3aXRoIGNv dW50ZXIgbW9kZSBBRVNfMTI4LCBMZXTCuXMgc2F5IGVuY3J5cHRpbmcgMl43MCBpbnB1dA0KPj4g YmxvY2tzIHdpdGggYSBzaW5nbGUga2V5LiBXaXRoIHRoZSAyXjcwIGNpcGhlcnRleHQgYmxvY2tz IGFsb25lIChlYWNoDQo+PmJsb2NrIGlzDQo+PiAxMjggYml0cyksIEkgZG9uwrl0IHRoaW5rIG9u ZSBjYW4gZmluZCBvdXQgYW55IGNvbnRlbnQgb2YgYW55IG9mIHRoZQ0KPj5wbGFpbnRleHRzLg0K Pj4gVGhlIGNoYW5jZSBmb3Iga25vd2luZyBhbnkgYmxvY2sgb2YgdGhlIHBsYWludGV4dHMgaXMN Cj4+IDEvKDJeMTI4KSBpbiB0aGlzIGNhc2UuDQo+PiANCj4+IEkgc3VwcG9ydCB0aGUgc3Ryb25n ZXN0IGluZGlzdGluZ3Vpc2hhYmlsaXR5IG5vdGlvbiBtZW50aW9uZWQgaW4gKCopDQo+PmFib3Zl LA0KPj4gYnV0IGluIG15IG9waW5pb24gd2Ugc2hvdWxkIHByb3ZpZGUgZ29vZCBkZXNjcmlwdGlv biB0byB0aGUgdXNlcnMuDQo+PiBUaGF0IGlzIHdoeSBJIHN1cHBvcnQgdGhlIGxpbWl0IGFyb3Vu ZCAyXjM4IHJlY29yZHMuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBRdXluaC4NCj4+IA0KPj4gT24g Ny8xMi8xNiwgMTA6MDMgQU0sICJQYXRlcnNvbiwgS2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVs LmFjLnVrPg0KPj4gd3JvdGU6DQo+PiANCj4+ID5IaSBRdXluaCwNCj4+ID4NCj4+ID5UaGlzIGlu ZGlzdGluZ3Vpc2hhYmlsaXR5LWJhc2VkIHNlY3VyaXR5IG5vdGlvbiBpcyB0aGUgY29uZmlkZW50 aWFsaXR5DQo+PiA+bm90aW9uIHRoYXQgaXMgYnkgbm93IGdlbmVyYWxseSBhY2NlcHRlZCBpbiB0 aGUgY3J5cHRvIGNvbW11bml0eS4NCj4+ID5NZWV0aW5nIGl0IGlzIHN1ZmZpY2llbnQgdG8gZ3Vh cmFudGVlIHNlY3VyaXR5IGFnYWluc3QgbWFueSBvdGhlciBmb3Jtcw0KPj4gPm9mIGF0dGFjayBv biBjb25maWRlbnRpYWxpdHksIHdoaWNoIGlzIG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIHdlIHVz ZQ0KPj5pdC4NCj4+ID4NCj4+ID5Zb3Ugc2F5IHRoYXQgYW4gYXR0YWNrIGluIHRoZSBzZW5zZSBp bXBsaWVkIGJ5IGJyZWFraW5nIHRoaXMgbm90aW9uDQo+PiA+ZG9lcyBub3QgYnJlYWsgY29uZmlk ZW50aWFsaXR5LiBDYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieQ0KPj4gPiJjb25maWRl bnRpYWxpdHkiLCBpbiBhIHByZWNpc2Ugd2F5PyBJIGNhbiB0aGVuIHRyeSB0byB0ZWxsIHlvdSB3 aGV0aGVyDQo+PiA+dGhpcyBub3Rpb24gd2lsbCBpbXBseSB5b3Vycy4NCj4+ID4NCj4+ID5SZWdh cmRzDQo+PiA+DQo+PiA+S2VubnkNCj4+ID4NCj4+ID5PbiAxMi8wNy8yMDE2IDE0OjA0LCAiVExT IG9uIGJlaGFsZiBvZiBEYW5nLCBRdXluaCAoRmVkKSINCj4+ID48dGxzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3RlOg0KPj4gPg0KPj4gPj5I aSBFcmljIGFuZCBhbGwsDQo+PiA+Pg0KPj4gPj4NCj4+ID4+SW4gbXkgb3Bpbmlvbiwgd2Ugc2hv dWxkIGdpdmUgYmV0dGVyIGluZm9ybWF0aW9uIGFib3V0IGRhdGEgbGltaXQgZm9yDQo+PiA+PkFF U19HQ00gaW4gVExTIDEuMyBpbnN0ZWFkIG9mIHdoYXQgaXMgY3VycmVudCBpbiB0aGUgZHJhZnQg MTQuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+SW4gdGhpcyBwYXBlcjogaHR0cDovL3d3dy5pc2cucmh1 bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZiwgIHdoYXQNCj4+ID4+aXMgY2FsbGVkIGNvbmZp ZGVudGlhbGl0eSBhdHRhY2sgaXMgdGhlIGtub3duIHBsYWludGV4dA0KPj4gPj5kaWZmZXJlbnRp YWxpdHkgYXR0YWNrIHdoZXJlICB0aGUgYXR0YWNrZXIgaGFzL2Nob29zZXMgdHdvIHBsYWludGV4 dHMsDQo+PiA+PnNlbmQgdGhlbSB0byB0aGUgQUVTLWVuY3J5cHRpb24gb3JhY2xlLiAgVGhlIG9y YWNsZSBlbmNyeXB0cyBvbmUgb2YNCj4+ID4+dGhlbSwgdGhlbiBzZW5kcyB0aGUgY2lwaGVydGV4 dCB0byB0aGUgYXR0YWNrZXIuICBBZnRlciBzZWVpbmcgdGhlDQo+PiA+PmNpcGhlcnRleHQsIHRo ZSBhdHRhY2tlciBoYXMgc29tZSBzdWNjZXNzIHByb2JhYmlsaXR5IG9mIHRlbGxpbmcgd2hpY2gN Cj4+ID4+cGxhaW50ZXh0ICB3YXMgZW5jcnlwdGVkIGFuZCB0aGlzIHN1Y2Nlc3MgcHJvYmFiaWxp dHkgaXMgaW4gdGhlIGNvbHVtbg0KPj4gPj5jYWxsZWQgwrNBdHRhY2sgU3VjY2VzcyBQcm9iYWJp bGl0ecKyIGluIFRhYmxlIDEuICBUaGlzIGF0dGFjayBkb2VzIG5vdA0KPj4gPj5icmVhayBjb25m aWRlbnRpYWxpdHkuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+SWYgdGhlIGF0dGFjayBhYm92ZSBicmVh a3Mgb25lIG9mIHNlY3VyaXR5IGdvYWwocykgb2YgeW91ciBpbmRpdmlkdWFsDQo+PiA+PnN5c3Rl bSwgdGhlbiBtYWtpbmcgc3VjY2VzcyBwcm9iYWJpbGl0eSBvZiB0aGF0IGF0dGFjayBhdCAyXigt MzIpIG1heA0KPj4gPj5pcyBlbm91Z2guIEluIHRoYXQgY2FzZSwgdGhlIE1heCBudW1iZXIgb2Yg cmVjb3JkcyBpcyBhcm91bmQgMl4zOC4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+ PlJlZ2FyZHMsDQo+PiA+PlF1eW5oLg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ DQo+PiA+Pg0KPj4gPj5EYXRlOiBNb25kYXksIEp1bHkgMTEsIDIwMTYgYXQgMzowOCBQTQ0KPj4g Pj5UbzogInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NCj4+ID4+U3ViamVjdDogW1RMU10g TmV3IGRyYWZ0OiBkcmFmdC1pZXRmLXRscy10bHMxMy0xNC50eHQNCj4+ID4+DQo+PiA+Pg0KPj4g Pj4NCj4+ID4+Rm9sa3MsDQo+PiA+Pg0KPj4gPj4NCj4+ID4+SSd2ZSBqdXN0IHN1Ym1pdHRlZCBk cmFmdC1pZXRmLXRscy10bHMxMy0xNC50eHQgYW5kIGl0IHNob3VsZCBzaG93IHVwDQo+PiA+Pm9u IHRoZSBkcmFmdCByZXBvc2l0b3J5IHNob3J0bHkuIEluIHRoZSBtZWFudGltZSB5b3UgY2FuIGZp bmQgdGhlDQo+PiA+PmVkaXRvcidzIGNvcHkgaW4gdGhlIHVzdWFsIGxvY2F0aW9uIGF0Og0KPj4g Pj4NCj4+ID4+DQo+PiA+PiAgaHR0cDovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLw0KPj4g Pj4NCj4+ID4+DQo+PiA+PlRoZSBtYWpvciBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgYXJlOg0K Pj4gPj4NCj4+ID4+DQo+PiA+PiogQSBiaWcgcmVzdHJ1Y3R1cmUgdG8gbWFrZSBpdCByZWFkIGJl dHRlci4gSSBtb3ZlZCB0aGUgT3ZlcnZpZXcNCj4+ID4+ICB0byB0aGUgYmVnaW5uaW5nIGFuZCB0 aGVuIHB1dCB0aGUgZG9jdW1lbnQgaW4gYSBtb3JlIGxvZ2ljYWwNCj4+ID4+ICBvcmRlciBzdGFy dGluZyB3aXRoIHRoZSBoYW5kc2hha2UgYW5kIHRoZW4gdGhlIHJlY29yZCBhbmQNCj4+ID4+ICBh bGVydHMuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBUb3RhbGx5IHJld3JvdGUgdGhlIHNlY3Rpb24g d2hpY2ggdXNlZCB0byBiZSBjYWxsZWQgIlNlY3VyaXR5DQo+PiA+PiAgQW5hbHlzaXMiIGFuZCBp cyBub3cgY2FsbGVkICJPdmVydmlldyBvZiBTZWN1cml0eSBQcm9wZXJ0aWVzIi4NCj4+ID4+ICBU aGlzIHNlY3Rpb24gaXMgc3RpbGwga2luZCBvZiBhIGhhcmQgaGF0IGFyZWEsIHNvIFBScyB3ZWxj b21lLg0KPj4gPj4gIEluIHBhcnRpY3VsYXIsIEkga25vdyBJIG5lZWQgdG8gYmVlZiB1cCB0aGUg Y2l0YXRpb25zIGZvciB0aGUNCj4+ID4+ICByZWNvcmQgbGF5ZXIgc2VjdGlvbi4NCj4+ID4+DQo+ PiA+Pg0KPj4gPj4qIFJlbW92ZWQgdGhlIDAtUlRUIEVuY3J5cHRlZEV4dGVuc2lvbnMgYW5kIG1v dmVkIHRpY2tldF9hZ2UNCj4+ID4+ICBpbnRvIHRoZSBDbGllbnRIZWxsby4gVGhpcyBxdWFzaS1y ZXZlcnRzIGEgY2hhbmdlIGluIC0xMyB0aGF0DQo+PiA+PiAgbWFkZSBpbXBsZW1lbnRhdGlvbiBv ZiAwLVJUVCBraW5kIG9mIGEgcGFpbi4NCj4+ID4+DQo+PiA+Pg0KPj4gPj5BcyB1c3VhbCwgY29t bWVudHMgd2VsY29tZS4NCj4+ID4+LUVrcg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4qIEFsbG93IGNvb2tpZXMgdG8gYmUgbG9uZ2VyICgqKQ0KPj4gPj4N Cj4+ID4+DQo+PiA+PiogUmVtb3ZlIHRoZSAiY29udGV4dCIgZnJvbSBFYXJseURhdGFJbmRpY2F0 aW9uIGFzIGl0IHdhcyB1bmRlZmluZWQNCj4+ID4+ICBhbmQgbm9ib2R5IHVzZWQgaXQgKCopDQo+ PiA+Pg0KPj4gPj4NCj4+ID4+KiBSZW1vdmUgMC1SVFQgRW5jcnlwdGVkRXh0ZW5zaW9ucyBhbmQg cmVwbGFjZSB0aGUgdGlja2V0X2FnZQ0KPj4gPj5leHRlbnNpb24NCj4+ID4+ICB3aXRoIGFuIG9i ZnVzY2F0ZWQgdmVyc2lvbi4gQWxzbyBuZWNlc3NpdGF0ZXMgYSBjaGFuZ2UgdG8NCj4+ID4+ICBO ZXdTZXNzaW9uVGlja2V0ICgqKS4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4qIE1vdmUgdGhlIGRvd25n cmFkZSBzZW50aW5lbCB0byB0aGUgZW5kIG9mIFNlcnZlckhlbGxvLlJhbmRvbQ0KPj4gPj4gIHRv IGFjY29tb2RhdGUgdGxzZGF0ZSAoKikuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBEZWZpbmUgZWNk c2Ffc2hhMSAoKikuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBBbGxvdyByZXN1bXB0aW9uIGV2ZW4g YWZ0ZXIgZmF0YWwgYWxlcnRzLiBUaGlzIG1hdGNoZXMgY3VycmVudA0KPj4gPj4gIHByYWN0aWNl Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiogUmVtb3ZlIG5vbi1jbG9zdXJlIHdhcm5pbmcgYWxlcnRz LiBSZXF1aXJlIHRyZWF0aW5nIHVua25vd24gYWxlcnRzDQo+PiA+PmFzDQo+PiA+PiAgZmF0YWwu DQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBNYWtlIHRoZSBydWxlcyBmb3IgYWNjZXB0aW5nIDAtUlRU IGxlc3MgcmVzdHJpY3RpdmUuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBDbGFyaWZ5IDAtUlRUIGJh Y2t3YXJkLWNvbXBhdGliaWxpdHkgcnVsZXMuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+KiBDbGFyaWZ5 IGhvdyAwLVJUVCBhbmQgUFNLIGlkZW50aXRpZXMgaW50ZXJhY3QuDQo+PiA+Pg0KPj4gPj4NCj4+ ID4+KiBBZGQgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIGRhdGEgbGltaXRzIGZvciBlYWNoIGNp cGhlci4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4qIE1ham9yIGVkaXRvcmlhbCByZXN0cnVjdHVyaW5n Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiogUmVwbGFjZSB0aGUgU2VjdXJpdHkgQW5hbHlzaXMgc2Vj dGlvbiB3aXRoIGEgV0lQIGRyYWZ0Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PigqKSBpbmRpY2F0ZXMg Y2hhbmdlcyB0byB0aGUgd2lyZSBwcm90b2NvbCB3aGljaCBtYXkgcmVxdWlyZQ0KPj4gPj5pbXBs ZW1lbnRhdGlvbnMNCj4+ID4+ICAgIHRvIHVwZGF0ZS4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gVExTIG1haWxpbmcgbGlzdA0KPj4gVExTQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= From nobody Tue Jul 12 10:04:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6C712D56F for ; Tue, 12 Jul 2016 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Soyao5Ux6lME for ; Tue, 12 Jul 2016 10:04:55 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0100.outbound.protection.outlook.com [23.103.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAB212D1B7 for ; Tue, 12 Jul 2016 10:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xuEfVOQtr0oOEHhqvRU0DTw9GszWRI+6QURiFJr4GKk=; b=Yq7mu8qy0Xk6uKb2NL+SJbPv8C14gStS+COnXbIuYiOzb9borxS+lpZRr8WhmnzM30ZibjHb4FGgzRFeYs5RGFijTZJh0SX/GbwKDl2RKbQzrM7G0A+zzjJdwtclmbopHTQkc+3MLw0m3AEQ1XBi3BLUS4aVwPd7CYz4VoBRpNs= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:04:53 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:04:52 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Scott Fluhrer (sfluhrer)" , "Dang, Quynh (Fed)" , "Eric Rescorla" , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAATFUAgAANRgD//8XVgA== Date: Tue, 12 Jul 2016 17:04:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: ea7e8c3f-7c27-4947-10d7-08d3aa76a454 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0171; 6:PTi6UXt25cjtS1lZoO+dgSMv41Ujq8n4C5t4oOxIOemduCeqolL6GGCSZt1jWIEKvHQEWNK36ANe8oVzhaJKba6ZO2KVHiWaEWHi9MMdaQTW4mvOpoJKg5cwXY3eZS16yR6IvQNeraVBgBVrYr5e2MXBgSDGIp72ubkoSJD0ppznNm7TjJ+fc8OMS7YfcRbclGNaoT3WSgudEke4dbOuyNYCHHoSOQUiI98v2Lac+GHsE6RtxBpfXtAXO4v6BdV/4OhDJlrfEPyDVjlihKKMsbbE2m/zwDMA3wdYAVvOIg0xPxU2lUSD+UM6MpjTTe+4lzQRk/kj2Rjsu5Vvi46+Fw==; 5:yKpNxWPwg00b3NS4wAYNLgLgfP5LeLsVcnL9+kFhMhCBAPvDjMHEZ/wPeBVl3c4wXqsf0YfyP6KwCXhFe1YUSuChSH6oSZGEG/p7idlFrDKBZvZ8pcltmdoTV7ZishcQEFRM/oGiq7i4fVJbsBhHyg==; 24:f7R7OMx662n++ztXRuKIa9W+Wdf7KW8OCqijs5hGzsJZI07zP4FYyvD6RPbS6qKWy4wVugXX/PNEbGsKzPrDPFg/dyFgOqhIudDVj/5mCzA=; 7:B3oz9ik0VPsh8kQ8Yw8Yxl6b89oKh5XsRByj16fU3O0XhfhU723ll9/ue9YiBLJ9jEv1yI/q+3WaCofEYogjHkZn2cQ819ohHuyWimB2cqVZi4QhPbVPdOTkdad31qBpmqhSon4DzFEjq0s/5hZWxBy0eN+QFRDu1moDXI8oUELTp+isXpHpZ4Y4yHd4o/hsBTY44Rl3K5Rq383Gr8iPAr1vgBJggmS8Ia5HbyHu6qRJPbKYTKG0vuzkEYySMkMx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0171; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0171; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0171; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(24454002)(55674003)(8936002)(3280700002)(36756003)(87936001)(10400500002)(97736004)(83506001)(230783001)(66066001)(3660700001)(8676002)(19580405001)(2906002)(86362001)(81166006)(81156014)(105586002)(99286002)(106116001)(106356001)(7846002)(2950100001)(68736007)(2900100001)(107886002)(305945005)(7736002)(19580395003)(189998001)(50986999)(54356999)(76176999)(2501003)(101416001)(586003)(92566002)(5001770100001)(102836003)(122556002)(3846002)(5002640100001)(93886004)(6116002)(77096005)(15975445007)(4001350100001)(8666005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0171; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: <61A52039933E6D4EA1F402FDE4EF707F@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:04:52.4986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0171 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:04:58 -0000 SGkgS2VubnksIA0KDQpPbiA3LzEyLzE2LCAxMjozMyBQTSwgIlBhdGVyc29uLCBLZW5ueSIgPEtl bm55LlBhdGVyc29uQHJodWwuYWMudWs+IHdyb3RlOg0KDQo+VW5mb3J0dW5hdGVseSwgdGhhdCdz IG5vdCBxdWl0ZSB0aGUgcmlnaHQgaW50ZXJwcmV0YXRpb24uIFRoZSBib3VuZHMgb25lDQo+b2J0 YWlucyBkZXBlbmQgb24gYm90aCB0aGUgdG90YWwgYW1vdW50IG9mIGRhdGEgZW5jcnlwdGVkIEFO RCB0aGUgbnVtYmVyDQo+b2YgZW5jcnlwdGlvbiBxdWVyaWVzIHRoZSBhZHZlcnNhcnkgaXMgYWxs b3dlZCB0byBtYWtlIHRvIEFFUy1HQ00gdW5kZXINCj50aGUgKHNpbmdsZSkgdGFyZ2V0IGtleS4N Cj4NCj5XZSBhc3N1bWVkIGVhY2ggcmVjb3JkIHdhcyAyXjE0IGJ5dGVzIGluIHNpemUgdG8gc2lt cGxpZnkgdGhlIGVuc3VpbmcNCj5hbmFseXNpcywgYW5kIHRvIGVuYWJsZSB1cyB0byBmb2N1cyBv biBob3cgdGhlIHNlY3VyaXR5IGJvdW5kcyB0aGVuIGRlcGVuZA0KPm9uIHRoZSBudW1iZXIgb2Yg cmVjb3JkcyBlbmNyeXB0ZWQuIFNlZSBlcXVhdGlvbiAoNSkgYW5kIFRhYmxlIDIgaW4gdGhlDQo+ bm90ZSBhdCANCj4NCj4JaHR0cDovL3d3dy5pc2cucmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRz LnBkZi4NCj4NCj5JbiBzaG9ydCwgdGhlIHNlY3VyaXR5IGJvdW5kIGRvZXMgbm90IG5lY2Vzc2Fy aWx5IGhvbGQgZm9yIEFOWSAyXjUyDQo+ZW5jcnlwdGVkIGRhdGEgYnl0ZXMuIEZvciBleGFtcGxl LCBpZiB0aGUgYXR0YWNrZXIgZW5jcnlwdGVkIDJeNTIgcmVjb3Jkcw0KPm9mIHNpemUgMSAoISkg dGhlbiBlcXVhdGlvbiAoNSkgd291bGQgdGVsbCB1cyBhbG1vc3Qgbm90aGluZyB1c2VmdWwgYXQg YWxsDQo+YWJvdXQgc2VjdXJpdHkuDQo+DQo+RmluYWxseSwgeW91IHdyaXRlICJ0byBjb21lIHRv IHRoZSAyXjM4IHJlY29yZCBsaW1pdCwgdGhleSBhc3N1bWUgdGhhdA0KPmVhY2ggcmVjb3JkIGlz IHRoZSBtYXhpbXVtIDJeMTQgYnl0ZXMiLiBGb3IgY2xhcml0eSwgd2UgZGlkIG5vdCByZWNvbW1l bmQNCj5hIGxpbWl0IG9mIDJeMzggcmVjb3Jkcy4gVGhhdCdzIFF1eW5oJ3MgcHJlZmVycmVkIG51 bWJlciwgYW5kIGlzDQo+dW5zdXBwb3J0ZWQgYnkgb3VyIGFuYWx5c2lzLg0KDQpXaGF0IGlzIHBy b2JsZW0gd2l0aCBteSBzdWdnZXN0aW9uIGV2ZW4gd2l0aCB0aGUgcmVjb3JkIHNpemUgYmVpbmcg dGhlDQptYXhpbXVtIHZhbHVlPw0KDQoNCj4NCj5DaGVlcnMsDQo+DQo+S2VubnkNCg0KUmVnYXJk cywNClF1eW5oLiANCj4gDQo+DQo+DQo+T24gMTIvMDcvMjAxNiAxNjo0NSwgIlNjb3R0IEZsdWhy ZXIgKHNmbHVocmVyKSIgPHNmbHVocmVyQGNpc2NvLmNvbT4NCj53cm90ZToNCj4NCj4+QWN0dWFs bHksIGEgbW9yZSBjb3JyZWN0IHdheSBvZiB2aWV3aW5nIHRoZSBsaW1pdCB3b3VsZCBiZSAyXjUy IGVuY3J5cHRlZA0KPj5kYXRhIGJ5dGVzLiBUbyBjb21lIHRvIHRoZSAyXjM4IHJlY29yZCBsaW1p dCwgdGhleSBhc3N1bWUgdGhhdCBlYWNoDQo+PnJlY29yZCBpcyB0aGUgbWF4aW11bSAyXjE0IGJ5 dGVzLiAgT2YgY291cnNlLCBhdCBhIDFHYnBzIHJhdGUsIGl0J2QgdGFrZQ0KPj5vdmVyIGEgeWVh ciB0byBlbmNyeXB0IHRoYXQgbXVjaCBkYXRhLi4uDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYW5nLCBRdXluaCAoRmVkKQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTIs IDIwMTYgMTE6MTIgQU0NCj4+PiBUbzogUGF0ZXJzb24sIEtlbm55OyBEYW5nLCBRdXluaCAoRmVk KTsgRXJpYyBSZXNjb3JsYTsgdGxzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtUTFNdIE5l dyBkcmFmdDogZHJhZnQtaWV0Zi10bHMtdGxzMTMtMTQudHh0DQo+Pj4gDQo+Pj4gSGkgS2Vubnks DQo+Pj4gDQo+Pj4gVGhlIGluZGlzdGluZ3Vpc2hhYmlsaXR5LWJhc2VkIHNlY3VyaXR5IG5vdGlv biBpbiB0aGUgcGFwZXIgaXMgYQ0KPj4+c3Ryb25nZXINCj4+PiBzZWN1cml0eSBub3Rpb24gdGhh biB0aGUgKG9sZCkgdHJhZGl0aW9uYWwgY29uZmlkZW50aWFsaXR5IG5vdGlvbi4NCj4+PiANCj4+ PiANCj4+PiAoKikgSW5kaXN0aW5ndWlzaGFiaWxpdHkgbm90aW9uIChmcmFtZXdvcmspIGd1YXJh bnRlZXMgbm8gb3RoZXIgYXR0YWNrcw0KPj4+Y2FuDQo+Pj4gYmUgYmV0dGVyIHRoYW4gdGhlIGlu ZGlzdGluZ3Vpc2hhYmlsaXR5IGJvdW5kLiBJbnR1aXRpdmVseSwgeW91IGNhbqn2dA0KPj4+YXR0 YWNrIGlmDQo+Pj4geW91IGNhbqn2dCBldmVuIHRlbGwgdHdvIHRoaW5ncyBhcmUgZGlmZmVyZW50 IG9yIG5vdC4gU28sIGJlaW5nIGFibGUgdG8NCj4+PnNheSB0d28NCj4+PiB0aGluZ3MgYXJlIGRp ZmZlcmVudCBvciBub3QgaXMgdGhlIG1pbmltYWwgY29uZGl0aW9uIHRvIGxlYWQgdG8gYW55DQo+ Pj5hdHRhY2suDQo+Pj4gDQo+Pj4gVGhlIHRyYWRpdGlvbmFsIGNvbmZpZGVudGlhbGl0eSBkZWZp bml0aW9uIGlzIHRoYXQga25vd2luZyBvbmx5IHRoZQ0KPj4+Y2lwaGVydGV4dHMsDQo+Pj4gdGhl IGF0dGFja2VyIGNhbqn2dCBrbm93IGFueSBjb250ZW50IG9mIHRoZSBjb3JyZXNwb25kaW5nIHBs YWludGV4dHMNCj4+PndpdGggYQ0KPj4+IGdyZWF0ZXIgcHJvYmFiaWxpdHkgdGhhbiBzb21lIHZh bHVlIGFuZCB0aGlzIHZhbHVlIGRlcGVuZHMgb24gdGhlDQo+Pj5wYXJ0aWN1bGFyDQo+Pj4gY2lw aGVyLiBPZiBjb3Vyc2UsIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBkYXRhIG11c3Qgbm90IGJlIG1v cmUgdGhhbg0KPj4+IHNvbWUgbGltaXQgdW5kZXIgYSBnaXZlbiBrZXkgd2hpY2ggYWxzbyBkZXBl bmRzIG9uIHRoZSBjaXBoZXIuDQo+Pj4gDQo+Pj4gRm9yIGV4YW1wbGUsIHdpdGggY291bnRlciBt b2RlIEFFU18xMjgsIExldKn2cyBzYXkgZW5jcnlwdGluZyAyXjcwIGlucHV0DQo+Pj4gYmxvY2tz IHdpdGggYSBzaW5nbGUga2V5LiBXaXRoIHRoZSAyXjcwIGNpcGhlcnRleHQgYmxvY2tzIGFsb25l IChlYWNoDQo+Pj5ibG9jayBpcw0KPj4+IDEyOCBiaXRzKSwgSSBkb26p9nQgdGhpbmsgb25lIGNh biBmaW5kIG91dCBhbnkgY29udGVudCBvZiBhbnkgb2YgdGhlDQo+Pj5wbGFpbnRleHRzLg0KPj4+ IFRoZSBjaGFuY2UgZm9yIGtub3dpbmcgYW55IGJsb2NrIG9mIHRoZSBwbGFpbnRleHRzIGlzDQo+ Pj4gMS8oMl4xMjgpIGluIHRoaXMgY2FzZS4NCj4+PiANCj4+PiBJIHN1cHBvcnQgdGhlIHN0cm9u Z2VzdCBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBub3Rpb24gbWVudGlvbmVkIGluICgqKQ0KPj4+YWJv dmUsDQo+Pj4gYnV0IGluIG15IG9waW5pb24gd2Ugc2hvdWxkIHByb3ZpZGUgZ29vZCBkZXNjcmlw dGlvbiB0byB0aGUgdXNlcnMuDQo+Pj4gVGhhdCBpcyB3aHkgSSBzdXBwb3J0IHRoZSBsaW1pdCBh cm91bmQgMl4zOCByZWNvcmRzLg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gUXV5bmguDQo+Pj4g DQo+Pj4gT24gNy8xMi8xNiwgMTA6MDMgQU0sICJQYXRlcnNvbiwgS2VubnkiIDxLZW5ueS5QYXRl cnNvbkByaHVsLmFjLnVrPg0KPj4+IHdyb3RlOg0KPj4+IA0KPj4+ID5IaSBRdXluaCwNCj4+PiA+ DQo+Pj4gPlRoaXMgaW5kaXN0aW5ndWlzaGFiaWxpdHktYmFzZWQgc2VjdXJpdHkgbm90aW9uIGlz IHRoZSBjb25maWRlbnRpYWxpdHkNCj4+PiA+bm90aW9uIHRoYXQgaXMgYnkgbm93IGdlbmVyYWxs eSBhY2NlcHRlZCBpbiB0aGUgY3J5cHRvIGNvbW11bml0eS4NCj4+PiA+TWVldGluZyBpdCBpcyBz dWZmaWNpZW50IHRvIGd1YXJhbnRlZSBzZWN1cml0eSBhZ2FpbnN0IG1hbnkgb3RoZXINCj4+PmZv cm1zDQo+Pj4gPm9mIGF0dGFjayBvbiBjb25maWRlbnRpYWxpdHksIHdoaWNoIGlzIG9uZSBvZiB0 aGUgbWFpbiByZWFzb25zIHdlIHVzZQ0KPj4+aXQuDQo+Pj4gPg0KPj4+ID5Zb3Ugc2F5IHRoYXQg YW4gYXR0YWNrIGluIHRoZSBzZW5zZSBpbXBsaWVkIGJ5IGJyZWFraW5nIHRoaXMgbm90aW9uDQo+ Pj4gPmRvZXMgbm90IGJyZWFrIGNvbmZpZGVudGlhbGl0eS4gQ2FuIHlvdSBleHBsYWluIHdoYXQg eW91IG1lYW4gYnkNCj4+PiA+ImNvbmZpZGVudGlhbGl0eSIsIGluIGEgcHJlY2lzZSB3YXk/IEkg Y2FuIHRoZW4gdHJ5IHRvIHRlbGwgeW91DQo+Pj53aGV0aGVyDQo+Pj4gPnRoaXMgbm90aW9uIHdp bGwgaW1wbHkgeW91cnMuDQo+Pj4gPg0KPj4+ID5SZWdhcmRzDQo+Pj4gPg0KPj4+ID5LZW5ueQ0K Pj4+ID4NCj4+PiA+T24gMTIvMDcvMjAxNiAxNDowNCwgIlRMUyBvbiBiZWhhbGYgb2YgRGFuZywg UXV5bmggKEZlZCkiDQo+Pj4gPjx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcXV5 bmguZGFuZ0BuaXN0Lmdvdj4gd3JvdGU6DQo+Pj4gPg0KPj4+ID4+SGkgRXJpYyBhbmQgYWxsLA0K Pj4+ID4+DQo+Pj4gPj4NCj4+PiA+PkluIG15IG9waW5pb24sIHdlIHNob3VsZCBnaXZlIGJldHRl ciBpbmZvcm1hdGlvbiBhYm91dCBkYXRhIGxpbWl0IGZvcg0KPj4+ID4+QUVTX0dDTSBpbiBUTFMg MS4zIGluc3RlYWQgb2Ygd2hhdCBpcyBjdXJyZW50IGluIHRoZSBkcmFmdCAxNC4NCj4+PiA+Pg0K Pj4+ID4+DQo+Pj4gPj5JbiB0aGlzIHBhcGVyOiBodHRwOi8vd3d3LmlzZy5yaHVsLmFjLnVrL35r cC9UTFMtQUVib3VuZHMucGRmLCAgd2hhdA0KPj4+ID4+aXMgY2FsbGVkIGNvbmZpZGVudGlhbGl0 eSBhdHRhY2sgaXMgdGhlIGtub3duIHBsYWludGV4dA0KPj4+ID4+ZGlmZmVyZW50aWFsaXR5IGF0 dGFjayB3aGVyZSAgdGhlIGF0dGFja2VyIGhhcy9jaG9vc2VzIHR3bw0KPj4+cGxhaW50ZXh0cywN Cj4+PiA+PnNlbmQgdGhlbSB0byB0aGUgQUVTLWVuY3J5cHRpb24gb3JhY2xlLiAgVGhlIG9yYWNs ZSBlbmNyeXB0cyBvbmUgb2YNCj4+PiA+PnRoZW0sIHRoZW4gc2VuZHMgdGhlIGNpcGhlcnRleHQg dG8gdGhlIGF0dGFja2VyLiAgQWZ0ZXIgc2VlaW5nIHRoZQ0KPj4+ID4+Y2lwaGVydGV4dCwgdGhl IGF0dGFja2VyIGhhcyBzb21lIHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgdGVsbGluZw0KPj4+d2hp Y2gNCj4+PiA+PnBsYWludGV4dCAgd2FzIGVuY3J5cHRlZCBhbmQgdGhpcyBzdWNjZXNzIHByb2Jh YmlsaXR5IGlzIGluIHRoZQ0KPj4+Y29sdW1uDQo+Pj4gPj5jYWxsZWQgqfhBdHRhY2sgU3VjY2Vz cyBQcm9iYWJpbGl0ean3IGluIFRhYmxlIDEuICBUaGlzIGF0dGFjayBkb2VzIG5vdA0KPj4+ID4+ YnJlYWsgY29uZmlkZW50aWFsaXR5Lg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PklmIHRoZSBhdHRh Y2sgYWJvdmUgYnJlYWtzIG9uZSBvZiBzZWN1cml0eSBnb2FsKHMpIG9mIHlvdXIgaW5kaXZpZHVh bA0KPj4+ID4+c3lzdGVtLCB0aGVuIG1ha2luZyBzdWNjZXNzIHByb2JhYmlsaXR5IG9mIHRoYXQg YXR0YWNrIGF0IDJeKC0zMikgbWF4DQo+Pj4gPj5pcyBlbm91Z2guIEluIHRoYXQgY2FzZSwgdGhl IE1heCBudW1iZXIgb2YgcmVjb3JkcyBpcyBhcm91bmQgMl4zOC4NCj4+PiA+Pg0KPj4+ID4+DQo+ Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+UmVnYXJkcywNCj4+PiA+PlF1eW5oLg0KPj4+ID4+DQo+Pj4g Pj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+RGF0ZTogTW9uZGF5LCBK dWx5IDExLCAyMDE2IGF0IDM6MDggUE0NCj4+PiA+PlRvOiAidGxzQGlldGYub3JnIiA8dGxzQGll dGYub3JnPg0KPj4+ID4+U3ViamVjdDogW1RMU10gTmV3IGRyYWZ0OiBkcmFmdC1pZXRmLXRscy10 bHMxMy0xNC50eHQNCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PkZvbGtzLA0KPj4+ID4+ DQo+Pj4gPj4NCj4+PiA+PkkndmUganVzdCBzdWJtaXR0ZWQgZHJhZnQtaWV0Zi10bHMtdGxzMTMt MTQudHh0IGFuZCBpdCBzaG91bGQgc2hvdyB1cA0KPj4+ID4+b24gdGhlIGRyYWZ0IHJlcG9zaXRv cnkgc2hvcnRseS4gSW4gdGhlIG1lYW50aW1lIHlvdSBjYW4gZmluZCB0aGUNCj4+PiA+PmVkaXRv cidzIGNvcHkgaW4gdGhlIHVzdWFsIGxvY2F0aW9uIGF0Og0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+ PiAgaHR0cDovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLw0KPj4+ID4+DQo+Pj4gPj4NCj4+ PiA+PlRoZSBtYWpvciBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgYXJlOg0KPj4+ID4+DQo+Pj4g Pj4NCj4+PiA+PiogQSBiaWcgcmVzdHJ1Y3R1cmUgdG8gbWFrZSBpdCByZWFkIGJldHRlci4gSSBt b3ZlZCB0aGUgT3ZlcnZpZXcNCj4+PiA+PiAgdG8gdGhlIGJlZ2lubmluZyBhbmQgdGhlbiBwdXQg dGhlIGRvY3VtZW50IGluIGEgbW9yZSBsb2dpY2FsDQo+Pj4gPj4gIG9yZGVyIHN0YXJ0aW5nIHdp dGggdGhlIGhhbmRzaGFrZSBhbmQgdGhlbiB0aGUgcmVjb3JkIGFuZA0KPj4+ID4+ICBhbGVydHMu DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBUb3RhbGx5IHJld3JvdGUgdGhlIHNlY3Rpb24gd2hp Y2ggdXNlZCB0byBiZSBjYWxsZWQgIlNlY3VyaXR5DQo+Pj4gPj4gIEFuYWx5c2lzIiBhbmQgaXMg bm93IGNhbGxlZCAiT3ZlcnZpZXcgb2YgU2VjdXJpdHkgUHJvcGVydGllcyIuDQo+Pj4gPj4gIFRo aXMgc2VjdGlvbiBpcyBzdGlsbCBraW5kIG9mIGEgaGFyZCBoYXQgYXJlYSwgc28gUFJzIHdlbGNv bWUuDQo+Pj4gPj4gIEluIHBhcnRpY3VsYXIsIEkga25vdyBJIG5lZWQgdG8gYmVlZiB1cCB0aGUg Y2l0YXRpb25zIGZvciB0aGUNCj4+PiA+PiAgcmVjb3JkIGxheWVyIHNlY3Rpb24uDQo+Pj4gPj4N Cj4+PiA+Pg0KPj4+ID4+KiBSZW1vdmVkIHRoZSAwLVJUVCBFbmNyeXB0ZWRFeHRlbnNpb25zIGFu ZCBtb3ZlZCB0aWNrZXRfYWdlDQo+Pj4gPj4gIGludG8gdGhlIENsaWVudEhlbGxvLiBUaGlzIHF1 YXNpLXJldmVydHMgYSBjaGFuZ2UgaW4gLTEzIHRoYXQNCj4+PiA+PiAgbWFkZSBpbXBsZW1lbnRh dGlvbiBvZiAwLVJUVCBraW5kIG9mIGEgcGFpbi4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj5BcyB1 c3VhbCwgY29tbWVudHMgd2VsY29tZS4NCj4+PiA+Pi1Fa3INCj4+PiA+Pg0KPj4+ID4+DQo+Pj4g Pj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQWxsb3cgY29va2llcyB0byBiZSBs b25nZXIgKCopDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBSZW1vdmUgdGhlICJjb250ZXh0IiBm cm9tIEVhcmx5RGF0YUluZGljYXRpb24gYXMgaXQgd2FzIHVuZGVmaW5lZA0KPj4+ID4+ICBhbmQg bm9ib2R5IHVzZWQgaXQgKCopDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBSZW1vdmUgMC1SVFQg RW5jcnlwdGVkRXh0ZW5zaW9ucyBhbmQgcmVwbGFjZSB0aGUgdGlja2V0X2FnZQ0KPj4+ID4+ZXh0 ZW5zaW9uDQo+Pj4gPj4gIHdpdGggYW4gb2JmdXNjYXRlZCB2ZXJzaW9uLiBBbHNvIG5lY2Vzc2l0 YXRlcyBhIGNoYW5nZSB0bw0KPj4+ID4+ICBOZXdTZXNzaW9uVGlja2V0ICgqKS4NCj4+PiA+Pg0K Pj4+ID4+DQo+Pj4gPj4qIE1vdmUgdGhlIGRvd25ncmFkZSBzZW50aW5lbCB0byB0aGUgZW5kIG9m IFNlcnZlckhlbGxvLlJhbmRvbQ0KPj4+ID4+ICB0byBhY2NvbW9kYXRlIHRsc2RhdGUgKCopLg0K Pj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogRGVmaW5lIGVjZHNhX3NoYTEgKCopLg0KPj4+ID4+DQo+ Pj4gPj4NCj4+PiA+PiogQWxsb3cgcmVzdW1wdGlvbiBldmVuIGFmdGVyIGZhdGFsIGFsZXJ0cy4g VGhpcyBtYXRjaGVzIGN1cnJlbnQNCj4+PiA+PiAgcHJhY3RpY2UuDQo+Pj4gPj4NCj4+PiA+Pg0K Pj4+ID4+KiBSZW1vdmUgbm9uLWNsb3N1cmUgd2FybmluZyBhbGVydHMuIFJlcXVpcmUgdHJlYXRp bmcgdW5rbm93biBhbGVydHMNCj4+PiA+PmFzDQo+Pj4gPj4gIGZhdGFsLg0KPj4+ID4+DQo+Pj4g Pj4NCj4+PiA+PiogTWFrZSB0aGUgcnVsZXMgZm9yIGFjY2VwdGluZyAwLVJUVCBsZXNzIHJlc3Ry aWN0aXZlLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQ2xhcmlmeSAwLVJUVCBiYWNrd2FyZC1j b21wYXRpYmlsaXR5IHJ1bGVzLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQ2xhcmlmeSBob3cg MC1SVFQgYW5kIFBTSyBpZGVudGl0aWVzIGludGVyYWN0Lg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+ PiogQWRkIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBkYXRhIGxpbWl0cyBmb3IgZWFjaCBjaXBo ZXIuDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBNYWpvciBlZGl0b3JpYWwgcmVzdHJ1Y3R1cmlu Zy4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4qIFJlcGxhY2UgdGhlIFNlY3VyaXR5IEFuYWx5c2lz IHNlY3Rpb24gd2l0aCBhIFdJUCBkcmFmdC4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4oKikgaW5k aWNhdGVzIGNoYW5nZXMgdG8gdGhlIHdpcmUgcHJvdG9jb2wgd2hpY2ggbWF5IHJlcXVpcmUNCj4+ PiA+PmltcGxlbWVudGF0aW9ucw0KPj4+ID4+ICAgIHRvIHVwZGF0ZS4NCj4+PiA+Pg0KPj4+ID4+ DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPg0KPj4+IA0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gVExTIG1haWxpbmcgbGlzdA0K Pj4+IFRMU0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQo+DQoNCg== From nobody Tue Jul 12 10:05:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302C412D583 for ; Tue, 12 Jul 2016 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MUfmbpE3aJv for ; Tue, 12 Jul 2016 10:05:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0054.outbound.protection.outlook.com [104.47.0.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC07312D5A2 for ; Tue, 12 Jul 2016 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2eSS4n1gOrMyLrNEqu845qedd8WQBTEez1aHJvfN/NQ=; b=VgvqVlZ6C3WmGVVMtOK6NE2n6yag/omFUVznaCnSJyKLzQtRfH670bdaDB4dGShdRWO0I89aLKZ5sQy2cniAP0MkSZa2Jv85LIGC7HXX3Y0Ewh5utQvgCXlQdB0yRMgvYYy73ugx2/Lc3oLWq3HaArR95llC4rG9DYRp9hN04ik= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1821.eurprd03.prod.outlook.com (10.166.42.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 17:05:00 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 17:05:00 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA Date: Tue, 12 Jul 2016 17:05:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 5f2539ce-a964-44e6-16d1-08d3aa76a921 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1821; 6:FdPuSSO+TwjX0LY8UjOGmQ7Ng9n7/ixYGXFBtwp1iweEnEXQzc3MMjzFfs8OHbu1xh+zaQqjKJLMH3G5IHh6I47FTuh2fQWW/vP5jpKxAjoGEDNV/Y0iH57/ZPD2Ox2NzH9aDJ4irqVoRIbGrIUGaOYnvT523tyMmFL4hUSO+w01Zs3/TQfO10r8ZmlOtehBxlkUaXh77X+8PCI2BpINgw+JL4a6TWpH8AZlQ+koZit9SN+5Hnvq1AU2ye/67GWBLVjM8xAnuXBedrjtZlnpT8yQ+1WXRfLTtB9u21MIDD8=; 5:zGzjNZQ2Kz+jUtJPljHXpXdWWTd2kW5jHNxZ9OaBeUr7N9WcfjKQfmSDPTHvmSxlzfFIr8eB7vb4kC0Y4fMLt4/HwMEvIAWVXaAq9z2iX1fLW+lUjzLppYV5yfiZ/Gdf+fVWcA/Yl/QGElwxFeMOoA==; 24:y8kqOFMnTS8a+t+ECaT9NEPFtmfWPchQYFB5L+iQD8NYwYu6mCIeqlRjxVmUhOFROwxGnMjztCBjD6jY82319q2hish6d4S3+iUKu01al0w=; 7:MfuGWlqlsYm+x8KhookBjYOUrIJk8Hd37OPl08ft27F08BPAAExBOh0uCcuey1VF/ewvQBuhVUdS2uBM7TNaCss2oB+rAaStlE6x/UHv/JY8AMgxyEWaDxxPZ+jrLWerDElPhzQRsbgZw+XnqCkBb5MNJmvi91CO5gwgujAzpvdDY/0r+RZ1Btni+rqOaAE/+ijFbbo+z76697Q13nJ79E4F/A/0zQF1+e6zYMsDTLI6P2CMi713yvAY0VcYP5+j x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1821; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1821; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1821; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(55674003)(24454002)(377454003)(87936001)(230783001)(3280700002)(8666005)(7846002)(7736002)(11100500001)(305945005)(3660700001)(93886004)(19580395003)(19580405001)(86362001)(74482002)(92566002)(189998001)(107886002)(4001350100001)(5001770100001)(97736004)(106356001)(106116001)(105586002)(101416001)(50986999)(66066001)(36756003)(54356999)(76176999)(2501003)(83506001)(81156014)(81166006)(2906002)(8936002)(5002640100001)(122556002)(68736007)(102836003)(3846002)(6116002)(10400500002)(586003)(8676002)(2900100001)(15975445007)(2950100001)(77096005)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1821; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <17CB0C1591C78F419CE85D7BC0DE3036@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:05:00.9212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1821 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:05:19 -0000 SGkNCg0KT24gMTIvMDcvMjAxNiAxNjoxMiwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFu Z0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5IaSBLZW5ueSwNCj4NCj5UaGUgaW5kaXN0aW5ndWlzaGFi aWxpdHktYmFzZWQgc2VjdXJpdHkgbm90aW9uIGluIHRoZSBwYXBlciBpcyBhIHN0cm9uZ2VyDQo+ c2VjdXJpdHkgbm90aW9uIHRoYW4gdGhlIChvbGQpIHRyYWRpdGlvbmFsIGNvbmZpZGVudGlhbGl0 eSBub3Rpb24uDQoNCldlbGwsIGluZGVlZCwgSSdtIHNvbWV3aGF0IGF3YXJlIG9mIHRoZSBub3Rp b24gYW5kIGl0cyBlbWVyZ2VuY2Ugb3ZlciB0aGUNCnllYXJzLiBJbmRlZWQsIEkgaGF2ZSBoYWQg dGhlIHZlcnkgcmVhbCBwbGVhc3VyZSBvZiB3cml0aW5nIGEgZmV3IHJlc2VhcmNoDQpwYXBlcnMg dXNpbmcgaW5kaXN0aW5ndWlzaGFiaWxpdHktYmFzZWQgc2VjdXJpdHkgbm90aW9ucyEgUmVzaXN0 aW5nIHRoZQ0KdGVtcHRhdGlvbiB0byBnaXZlIHlvdSBjaGFwdGVyIGFuZCB2ZXJzZSBvbiB5b3Vy IGFuYWx5c2lzIG9mIHRoZSBub3Rpb25zDQphbmQgaG93IHRvIGludGVycHJldCB0aGVtLi4uDQoN Cj4NCj4oKikgSW5kaXN0aW5ndWlzaGFiaWxpdHkgbm90aW9uIChmcmFtZXdvcmspIGd1YXJhbnRl ZXMgbm8gb3RoZXIgYXR0YWNrcw0KPmNhbiBiZSBiZXR0ZXIgdGhhbiB0aGUgaW5kaXN0aW5ndWlz aGFiaWxpdHkgYm91bmQuIEludHVpdGl2ZWx5LCB5b3UgY2Fuwrl0DQo+YXR0YWNrIGlmIHlvdSBj YW7CuXQgZXZlbiB0ZWxsIHR3byB0aGluZ3MgYXJlIGRpZmZlcmVudCBvciBub3QuIFNvLCBiZWlu Zw0KPmFibGUgdG8gc2F5IHR3byB0aGluZ3MgYXJlIGRpZmZlcmVudCBvciBub3QgaXMgdGhlIG1p bmltYWwgY29uZGl0aW9uIHRvDQo+bGVhZCB0byBhbnkgYXR0YWNrLg0KPlRoZSB0cmFkaXRpb25h bCBjb25maWRlbnRpYWxpdHkgZGVmaW5pdGlvbiBpcyB0aGF0IGtub3dpbmcgb25seSB0aGUNCj5j aXBoZXJ0ZXh0cywgdGhlIGF0dGFja2VyIGNhbsK5dCBrbm93IGFueSBjb250ZW50IG9mIHRoZSBj b3JyZXNwb25kaW5nDQo+cGxhaW50ZXh0cyB3aXRoIGEgZ3JlYXRlciBwcm9iYWJpbGl0eSB0aGFu IHNvbWUgdmFsdWUgYW5kIHRoaXMgdmFsdWUNCj5kZXBlbmRzIG9uIHRoZSBwYXJ0aWN1bGFyIGNp cGhlci4NCj5PZiBjb3Vyc2UsIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBkYXRhDQo+bXVzdCBub3Qg YmUgbW9yZSB0aGFuIHNvbWUgbGltaXQgdW5kZXIgYSBnaXZlbiBrZXkgd2hpY2ggYWxzbyBkZXBl bmRzIG9uDQo+dGhlIGNpcGhlci4gDQo+DQo+Rm9yIGV4YW1wbGUsIHdpdGggY291bnRlciBtb2Rl IEFFU18xMjgsIExldMK5cyBzYXkgZW5jcnlwdGluZyAyXjcwIGlucHV0DQo+YmxvY2tzIHdpdGgg YSBzaW5nbGUga2V5LiBXaXRoIHRoZSAyXjcwIGNpcGhlcnRleHQgYmxvY2tzIGFsb25lIChlYWNo DQo+YmxvY2sgaXMgMTI4IGJpdHMpLCBJIGRvbsK5dCB0aGluayBvbmUgY2FuIGZpbmQgb3V0IGFu eSBjb250ZW50IG9mIGFueSBvZg0KPnRoZSBwbGFpbnRleHRzLiBUaGUgY2hhbmNlIGZvciBrbm93 aW5nIGFueSBibG9jayBvZiB0aGUgcGxhaW50ZXh0cyBpcw0KPjEvKDJeMTI4KSBpbiB0aGlzIGNh c2UuDQoNCj5JIHN1cHBvcnQgdGhlIHN0cm9uZ2VzdCBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBub3Rp b24gbWVudGlvbmVkIGluICgqKQ0KPmFib3ZlLCBidXQgaW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQg cHJvdmlkZSBnb29kIGRlc2NyaXB0aW9uIHRvIHRoZSB1c2Vycy4NCg0KT0ssIEkgdGhpbmsgbm93 IHdlIGFyZSBhdCB0aGUgaGVhcnQgb2YgeW91ciBhcmd1bWVudC4gWW91IHN1cHBvcnQgb3VyDQpj aG9pY2Ugb2Ygc2VjdXJpdHkgZGVmaW5pdGlvbiBhbmQgbWV0aG9kIG9mIGFuYWx5c2lzIGFmdGVy IGFsbC4NCg0KQW5kIHdlIGNhbiBhZ3JlZSB0aGF0IGdvb2QgZGVzY3JpcHRpb25zIGNhbiBvbmx5 IGhlbHAuDQoNCj5UaGF0IGlzIHdoeSBJIHN1cHBvcnQgdGhlIGxpbWl0IGFyb3VuZCAyXjM4IHJl Y29yZHMuDQoNCkkgZG9uJ3Qgc2VlIGhvdyBjaGFuZ2luZyAyXjI0LjUgKHdoaWNoIGlzIGluIHRo ZSBjdXJyZW50IGRyYWZ0KSB0byAyXjM4DQpwcm92aWRlcyBhIGJldHRlciBkZXNjcmlwdGlvbiB0 byB1c2Vycy4NCg0KQXJlIHlvdSB3b3JyaWVkIHRoZXkgd29uJ3Qga25vdyB3aGF0IGEgZGVjaW1h bCBpbiB0aGUgZXhwb25lbnQgbWVhbnM/DQoNCk9yLCBtb3JlIHNlcmlvdXNseSwgYXJlIHlvdSBz YXlpbmcgdGhhdCAyXnstMzJ9IGZvciBzaW5nbGUga2V5IGF0dGFja3MgaXMNCmEgYmlnIGVub3Vn aCBzZWN1cml0eSBtYXJnaW4/IElmIHNvLCBjYW4geW91IHNheSB3aGF0IHRoYXQncyBiYXNlZCBv bj8NCg0KQ2hlZXJzLA0KDQpLZW5ueSANCg0KDQo+DQo+UmVnYXJkcywNCj5RdXluaC4gDQo+DQo+ T24gNy8xMi8xNiwgMTA6MDMgQU0sICJQYXRlcnNvbiwgS2VubnkiIDxLZW5ueS5QYXRlcnNvbkBy aHVsLmFjLnVrPiB3cm90ZToNCj4NCj4+SGkgUXV5bmgsDQo+Pg0KPj5UaGlzIGluZGlzdGluZ3Vp c2hhYmlsaXR5LWJhc2VkIHNlY3VyaXR5IG5vdGlvbiBpcyB0aGUgY29uZmlkZW50aWFsaXR5DQo+ Pm5vdGlvbiB0aGF0IGlzIGJ5IG5vdyBnZW5lcmFsbHkgYWNjZXB0ZWQgaW4gdGhlIGNyeXB0byBj b21tdW5pdHkuIE1lZXRpbmcNCj4+aXQgaXMgc3VmZmljaWVudCB0byBndWFyYW50ZWUgc2VjdXJp dHkgYWdhaW5zdCBtYW55IG90aGVyIGZvcm1zIG9mIGF0dGFjaw0KPj5vbiBjb25maWRlbnRpYWxp dHksIHdoaWNoIGlzIG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIHdlIHVzZSBpdC4NCj4+DQo+Pllv dSBzYXkgdGhhdCBhbiBhdHRhY2sgaW4gdGhlIHNlbnNlIGltcGxpZWQgYnkgYnJlYWtpbmcgdGhp cyBub3Rpb24gZG9lcw0KPj5ub3QgYnJlYWsgY29uZmlkZW50aWFsaXR5LiBDYW4geW91IGV4cGxh aW4gd2hhdCB5b3UgbWVhbiBieQ0KPj4iY29uZmlkZW50aWFsaXR5IiwgaW4gYSBwcmVjaXNlIHdh eT8gSSBjYW4gdGhlbiB0cnkgdG8gdGVsbCB5b3Ugd2hldGhlcg0KPj50aGlzIG5vdGlvbiB3aWxs IGltcGx5IHlvdXJzLg0KPj4NCj4+UmVnYXJkcw0KPj4NCj4+S2VubnkgDQo+Pg0KPj5PbiAxMi8w Ny8yMDE2IDE0OjA0LCAiVExTIG9uIGJlaGFsZiBvZiBEYW5nLCBRdXluaCAoRmVkKSINCj4+PHRs cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBxdXluaC5kYW5nQG5pc3QuZ292PiB3cm90 ZToNCj4+DQo+Pj5IaSBFcmljIGFuZCBhbGwsDQo+Pj4NCj4+Pg0KPj4+SW4gbXkgb3Bpbmlvbiwg d2Ugc2hvdWxkIGdpdmUgYmV0dGVyIGluZm9ybWF0aW9uIGFib3V0IGRhdGEgbGltaXQgZm9yDQo+ Pj5BRVNfR0NNIGluIFRMUyAxLjMgaW5zdGVhZCBvZiB3aGF0IGlzIGN1cnJlbnQgaW4gdGhlIGRy YWZ0IDE0Lg0KPj4+DQo+Pj4NCj4+PkluIHRoaXMgcGFwZXI6IGh0dHA6Ly93d3cuaXNnLnJodWwu YWMudWsvfmtwL1RMUy1BRWJvdW5kcy5wZGYsICB3aGF0IGlzDQo+Pj5jYWxsZWQgY29uZmlkZW50 aWFsaXR5IGF0dGFjayBpcyB0aGUga25vd24gcGxhaW50ZXh0IGRpZmZlcmVudGlhbGl0eQ0KPj4+ YXR0YWNrIHdoZXJlDQo+Pj4gdGhlIGF0dGFja2VyIGhhcy9jaG9vc2VzIHR3byBwbGFpbnRleHRz LCBzZW5kIHRoZW0gdG8gdGhlDQo+Pj5BRVMtZW5jcnlwdGlvbg0KPj4+b3JhY2xlLiAgVGhlIG9y YWNsZSBlbmNyeXB0cyBvbmUgb2YgdGhlbSwgdGhlbiBzZW5kcyB0aGUgY2lwaGVydGV4dCB0bw0K Pj4+dGhlIGF0dGFja2VyLiAgQWZ0ZXIgc2VlaW5nIHRoZSBjaXBoZXJ0ZXh0LCB0aGUgYXR0YWNr ZXIgaGFzIHNvbWUNCj4+PnN1Y2Nlc3MNCj4+PnByb2JhYmlsaXR5IG9mIHRlbGxpbmcgd2hpY2gg cGxhaW50ZXh0DQo+Pj4gd2FzIGVuY3J5cHRlZCBhbmQgdGhpcyBzdWNjZXNzIHByb2JhYmlsaXR5 IGlzIGluIHRoZSBjb2x1bW4gY2FsbGVkDQo+Pj7Cs0F0dGFjayBTdWNjZXNzIFByb2JhYmlsaXR5 wrIgaW4gVGFibGUgMS4gIFRoaXMgYXR0YWNrIGRvZXMgbm90IGJyZWFrDQo+Pj5jb25maWRlbnRp YWxpdHkuDQo+Pj4NCj4+Pg0KPj4+SWYgdGhlIGF0dGFjayBhYm92ZSBicmVha3Mgb25lIG9mIHNl Y3VyaXR5IGdvYWwocykgb2YgeW91ciBpbmRpdmlkdWFsDQo+Pj5zeXN0ZW0sIHRoZW4gbWFraW5n IHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgdGhhdCBhdHRhY2sgYXQgMl4oLTMyKSBtYXggaXMNCj4+ PmVub3VnaC4gSW4gdGhhdCBjYXNlLCB0aGUgTWF4IG51bWJlciBvZiByZWNvcmRzIGlzIGFyb3Vu ZCAyXjM4Lg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+UXV5bmguIA0KPj4+ DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+RGF0ZTogTW9uZGF5LCBKdWx5IDExLCAyMDE2 IGF0IDM6MDggUE0NCj4+PlRvOiAidGxzQGlldGYub3JnIiA8dGxzQGlldGYub3JnPg0KPj4+U3Vi amVjdDogW1RMU10gTmV3IGRyYWZ0OiBkcmFmdC1pZXRmLXRscy10bHMxMy0xNC50eHQNCj4+Pg0K Pj4+DQo+Pj4NCj4+PkZvbGtzLA0KPj4+DQo+Pj4NCj4+PkkndmUganVzdCBzdWJtaXR0ZWQgZHJh ZnQtaWV0Zi10bHMtdGxzMTMtMTQudHh0IGFuZCBpdCBzaG91bGQNCj4+PnNob3cgdXAgb24gdGhl IGRyYWZ0IHJlcG9zaXRvcnkgc2hvcnRseS4gSW4gdGhlIG1lYW50aW1lIHlvdQ0KPj4+Y2FuIGZp bmQgdGhlIGVkaXRvcidzIGNvcHkgaW4gdGhlIHVzdWFsIGxvY2F0aW9uIGF0Og0KPj4+DQo+Pj4N Cj4+PiAgaHR0cDovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLw0KPj4+DQo+Pj4NCj4+PlRo ZSBtYWpvciBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgYXJlOg0KPj4+DQo+Pj4NCj4+PiogQSBi aWcgcmVzdHJ1Y3R1cmUgdG8gbWFrZSBpdCByZWFkIGJldHRlci4gSSBtb3ZlZCB0aGUgT3ZlcnZp ZXcNCj4+PiAgdG8gdGhlIGJlZ2lubmluZyBhbmQgdGhlbiBwdXQgdGhlIGRvY3VtZW50IGluIGEg bW9yZSBsb2dpY2FsDQo+Pj4gIG9yZGVyIHN0YXJ0aW5nIHdpdGggdGhlIGhhbmRzaGFrZSBhbmQg dGhlbiB0aGUgcmVjb3JkIGFuZA0KPj4+ICBhbGVydHMuDQo+Pj4NCj4+Pg0KPj4+KiBUb3RhbGx5 IHJld3JvdGUgdGhlIHNlY3Rpb24gd2hpY2ggdXNlZCB0byBiZSBjYWxsZWQgIlNlY3VyaXR5DQo+ Pj4gIEFuYWx5c2lzIiBhbmQgaXMgbm93IGNhbGxlZCAiT3ZlcnZpZXcgb2YgU2VjdXJpdHkgUHJv cGVydGllcyIuDQo+Pj4gIFRoaXMgc2VjdGlvbiBpcyBzdGlsbCBraW5kIG9mIGEgaGFyZCBoYXQg YXJlYSwgc28gUFJzIHdlbGNvbWUuDQo+Pj4gIEluIHBhcnRpY3VsYXIsIEkga25vdyBJIG5lZWQg dG8gYmVlZiB1cCB0aGUgY2l0YXRpb25zIGZvciB0aGUNCj4+PiAgcmVjb3JkIGxheWVyIHNlY3Rp b24uDQo+Pj4NCj4+Pg0KPj4+KiBSZW1vdmVkIHRoZSAwLVJUVCBFbmNyeXB0ZWRFeHRlbnNpb25z IGFuZCBtb3ZlZCB0aWNrZXRfYWdlDQo+Pj4gIGludG8gdGhlIENsaWVudEhlbGxvLiBUaGlzIHF1 YXNpLXJldmVydHMgYSBjaGFuZ2UgaW4gLTEzIHRoYXQNCj4+PiAgbWFkZSBpbXBsZW1lbnRhdGlv biBvZiAwLVJUVCBraW5kIG9mIGEgcGFpbi4NCj4+Pg0KPj4+DQo+Pj5BcyB1c3VhbCwgY29tbWVu dHMgd2VsY29tZS4NCj4+Pi1Fa3INCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Piog QWxsb3cgY29va2llcyB0byBiZSBsb25nZXIgKCopDQo+Pj4NCj4+Pg0KPj4+KiBSZW1vdmUgdGhl ICJjb250ZXh0IiBmcm9tIEVhcmx5RGF0YUluZGljYXRpb24gYXMgaXQgd2FzIHVuZGVmaW5lZA0K Pj4+ICBhbmQgbm9ib2R5IHVzZWQgaXQgKCopDQo+Pj4NCj4+Pg0KPj4+KiBSZW1vdmUgMC1SVFQg RW5jcnlwdGVkRXh0ZW5zaW9ucyBhbmQgcmVwbGFjZSB0aGUgdGlja2V0X2FnZSBleHRlbnNpb24N Cj4+PiAgd2l0aCBhbiBvYmZ1c2NhdGVkIHZlcnNpb24uIEFsc28gbmVjZXNzaXRhdGVzIGEgY2hh bmdlIHRvDQo+Pj4gIE5ld1Nlc3Npb25UaWNrZXQgKCopLg0KPj4+DQo+Pj4NCj4+PiogTW92ZSB0 aGUgZG93bmdyYWRlIHNlbnRpbmVsIHRvIHRoZSBlbmQgb2YgU2VydmVySGVsbG8uUmFuZG9tDQo+ Pj4gIHRvIGFjY29tb2RhdGUgdGxzZGF0ZSAoKikuDQo+Pj4NCj4+Pg0KPj4+KiBEZWZpbmUgZWNk c2Ffc2hhMSAoKikuDQo+Pj4NCj4+Pg0KPj4+KiBBbGxvdyByZXN1bXB0aW9uIGV2ZW4gYWZ0ZXIg ZmF0YWwgYWxlcnRzLiBUaGlzIG1hdGNoZXMgY3VycmVudA0KPj4+ICBwcmFjdGljZS4NCj4+Pg0K Pj4+DQo+Pj4qIFJlbW92ZSBub24tY2xvc3VyZSB3YXJuaW5nIGFsZXJ0cy4gUmVxdWlyZSB0cmVh dGluZyB1bmtub3duIGFsZXJ0cyBhcw0KPj4+ICBmYXRhbC4NCj4+Pg0KPj4+DQo+Pj4qIE1ha2Ug dGhlIHJ1bGVzIGZvciBhY2NlcHRpbmcgMC1SVFQgbGVzcyByZXN0cmljdGl2ZS4NCj4+Pg0KPj4+ DQo+Pj4qIENsYXJpZnkgMC1SVFQgYmFja3dhcmQtY29tcGF0aWJpbGl0eSBydWxlcy4NCj4+Pg0K Pj4+DQo+Pj4qIENsYXJpZnkgaG93IDAtUlRUIGFuZCBQU0sgaWRlbnRpdGllcyBpbnRlcmFjdC4N Cj4+Pg0KPj4+DQo+Pj4qIEFkZCBhIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgZGF0YSBsaW1pdHMg Zm9yIGVhY2ggY2lwaGVyLg0KPj4+DQo+Pj4NCj4+PiogTWFqb3IgZWRpdG9yaWFsIHJlc3RydWN0 dXJpbmcuDQo+Pj4NCj4+Pg0KPj4+KiBSZXBsYWNlIHRoZSBTZWN1cml0eSBBbmFseXNpcyBzZWN0 aW9uIHdpdGggYSBXSVAgZHJhZnQuDQo+Pj4NCj4+Pg0KPj4+KCopIGluZGljYXRlcyBjaGFuZ2Vz IHRvIHRoZSB3aXJlIHByb3RvY29sIHdoaWNoIG1heSByZXF1aXJlDQo+Pj5pbXBsZW1lbnRhdGlv bnMNCj4+PiAgICB0byB1cGRhdGUuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Tue Jul 12 10:12:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7D912D5A1 for ; Tue, 12 Jul 2016 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sK75stf8hmP for ; Tue, 12 Jul 2016 10:12:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0120.outbound.protection.outlook.com [23.103.201.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A42512D100 for ; Tue, 12 Jul 2016 10:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vOcjdHxthvW/R+vlfUQIrjvfmO+3s4a6HHyiNCu1yvc=; b=jFpU4VE9hAIqVC4b7nOynbe+BFL53CR4GbeDyHGik7XeJBm10aFuz3KXQjuAnBNdgXC0cp92GKUcR+tIgw4aJhR0uFVDjwMkqS4+/yFkx2akvhn+F5lVBxlJvbfZr55V16QZy4rR0jFaw4H2FI+7H9Y6cLnek4BdWCyxhDqyYac= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:12:32 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:12:32 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYA= Date: Tue, 12 Jul 2016 17:12:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 0c202b72-50d2-43ac-a3d5-08d3aa77b64e x-microsoft-exchange-diagnostics: 1; BN1PR09MB0171; 6:EWHRdY++dfHmctJ+e0DGQQvDHuSVFrICMPrOTqWEpTq2d9+WfMY6wfGE1Y50vkMxhMxnh+6085XeiUu3tJUgDYD77qay/i+fTIaAKuarVYUytLVQVjGITHW6Yqot2MsWUXXLH8n6GSYzz96a632uYYki+tan5cssVU6+3XZVaD5DGHVxOf6DRzw42IwvWK/F0vU7GoAMaNASkYEf27M+KJPvjHR7huexxI12qYST0Ci/uCtKrViNSLFzYJGYczQrYvkCkSYo8Y77UyqPNV9lgnRdiqhN/hzimU/4w2xjDnbsNdzCJ8iqXxX3b1a2oQnudXzdEu0dlautKOBmqIIfYg==; 5:xQPQF82Wn1MZRfSWVP2ZdmzlphuASZBkOskMo6wEl/kSyU2wesMoNgGY7Psp1rV0vBP0q/nInA750fd8DDrzrPn5dFCykS6bvJMFgU4GFVkh1el29RsY8pihaMMjPtElc2pRv6IFTY98VorhA329TA==; 24:iXbt09v2zy7VErFPYpcXzW/bxg8B2InHdh0kcOlOaqFp8gf/PgQYA9TYzq3NH6gxhKJ/6Rpdvyc9nVsMjOMEKLG1kb59bNpV5DGapVOZ7Xg=; 7:uBizh9EgXxzPRpdL9mqiZ0L5SF3vK/Vbpiv7a8peDYZ+2ReH6jXZoTZaRYcwQj265Ff8uKWXJv/ok4giLxQGmECppH37x4+eiaePH79LzVcJ+1X/GubTEOgAOmYgPE3aF7sr850p4xi4W+mOrBaKcQm7zqOuW/08B9bEpiErmmyU63qDUgDJezEdvVpfUl49h3bKHz7O9vEQP+q/HZWy2zzmaa4arNRP6EPoJbCGHhqK6+LvagBoG1duZM8IDcuO x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0171; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0171; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0171; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(55674003)(8936002)(3280700002)(36756003)(87936001)(10400500002)(97736004)(83506001)(230783001)(66066001)(3660700001)(8676002)(19580405001)(2906002)(86362001)(81166006)(81156014)(105586002)(99286002)(106116001)(106356001)(7846002)(2950100001)(68736007)(2900100001)(107886002)(305945005)(7736002)(11100500001)(19580395003)(189998001)(50986999)(54356999)(76176999)(2501003)(101416001)(586003)(92566002)(5001770100001)(102836003)(122556002)(3846002)(5002640100001)(93886004)(6116002)(77096005)(15975445007)(4001350100001)(8666005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0171; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:12:32.0377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0171 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:12:42 -0000 SGkgS2VubnksIA0KDQpPbiA3LzEyLzE2LCAxOjA1IFBNLCAiUGF0ZXJzb24sIEtlbm55IiA8S2Vu bnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQoNCj5IaQ0KPg0KPk9uIDEyLzA3LzIwMTYg MTY6MTIsICJEYW5nLCBRdXluaCAoRmVkKSIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3RlOg0K Pg0KPj5IaSBLZW5ueSwNCj4+DQo+PlRoZSBpbmRpc3Rpbmd1aXNoYWJpbGl0eS1iYXNlZCBzZWN1 cml0eSBub3Rpb24gaW4gdGhlIHBhcGVyIGlzIGEgc3Ryb25nZXINCj4+c2VjdXJpdHkgbm90aW9u IHRoYW4gdGhlIChvbGQpIHRyYWRpdGlvbmFsIGNvbmZpZGVudGlhbGl0eSBub3Rpb24uDQo+DQo+ V2VsbCwgaW5kZWVkLCBJJ20gc29tZXdoYXQgYXdhcmUgb2YgdGhlIG5vdGlvbiBhbmQgaXRzIGVt ZXJnZW5jZSBvdmVyIHRoZQ0KPnllYXJzLiBJbmRlZWQsIEkgaGF2ZSBoYWQgdGhlIHZlcnkgcmVh bCBwbGVhc3VyZSBvZiB3cml0aW5nIGEgZmV3IHJlc2VhcmNoDQo+cGFwZXJzIHVzaW5nIGluZGlz dGluZ3Vpc2hhYmlsaXR5LWJhc2VkIHNlY3VyaXR5IG5vdGlvbnMhIFJlc2lzdGluZyB0aGUNCj50 ZW1wdGF0aW9uIHRvIGdpdmUgeW91IGNoYXB0ZXIgYW5kIHZlcnNlIG9uIHlvdXIgYW5hbHlzaXMg b2YgdGhlIG5vdGlvbnMNCj5hbmQgaG93IHRvIGludGVycHJldCB0aGVtLi4uDQo+DQo+Pg0KPj4o KikgSW5kaXN0aW5ndWlzaGFiaWxpdHkgbm90aW9uIChmcmFtZXdvcmspIGd1YXJhbnRlZXMgbm8g b3RoZXIgYXR0YWNrcw0KPj5jYW4gYmUgYmV0dGVyIHRoYW4gdGhlIGluZGlzdGluZ3Vpc2hhYmls aXR5IGJvdW5kLiBJbnR1aXRpdmVseSwgeW91IGNhbqn2dA0KPj5hdHRhY2sgaWYgeW91IGNhbqn2 dCBldmVuIHRlbGwgdHdvIHRoaW5ncyBhcmUgZGlmZmVyZW50IG9yIG5vdC4gU28sIGJlaW5nDQo+ PmFibGUgdG8gc2F5IHR3byB0aGluZ3MgYXJlIGRpZmZlcmVudCBvciBub3QgaXMgdGhlIG1pbmlt YWwgY29uZGl0aW9uIHRvDQo+PmxlYWQgdG8gYW55IGF0dGFjay4NCj4+VGhlIHRyYWRpdGlvbmFs IGNvbmZpZGVudGlhbGl0eSBkZWZpbml0aW9uIGlzIHRoYXQga25vd2luZyBvbmx5IHRoZQ0KPj5j aXBoZXJ0ZXh0cywgdGhlIGF0dGFja2VyIGNhbqn2dCBrbm93IGFueSBjb250ZW50IG9mIHRoZSBj b3JyZXNwb25kaW5nDQo+PnBsYWludGV4dHMgd2l0aCBhIGdyZWF0ZXIgcHJvYmFiaWxpdHkgdGhh biBzb21lIHZhbHVlIGFuZCB0aGlzIHZhbHVlDQo+PmRlcGVuZHMgb24gdGhlIHBhcnRpY3VsYXIg Y2lwaGVyLg0KPj5PZiBjb3Vyc2UsIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBkYXRhDQo+Pm11c3Qg bm90IGJlIG1vcmUgdGhhbiBzb21lIGxpbWl0IHVuZGVyIGEgZ2l2ZW4ga2V5IHdoaWNoIGFsc28g ZGVwZW5kcyBvbg0KPj50aGUgY2lwaGVyLiANCj4+DQo+PkZvciBleGFtcGxlLCB3aXRoIGNvdW50 ZXIgbW9kZSBBRVNfMTI4LCBMZXSp9nMgc2F5IGVuY3J5cHRpbmcgMl43MCBpbnB1dA0KPj5ibG9j a3Mgd2l0aCBhIHNpbmdsZSBrZXkuIFdpdGggdGhlIDJeNzAgY2lwaGVydGV4dCBibG9ja3MgYWxv bmUgKGVhY2gNCj4+YmxvY2sgaXMgMTI4IGJpdHMpLCBJIGRvbqn2dCB0aGluayBvbmUgY2FuIGZp bmQgb3V0IGFueSBjb250ZW50IG9mIGFueSBvZg0KPj50aGUgcGxhaW50ZXh0cy4gVGhlIGNoYW5j ZSBmb3Iga25vd2luZyBhbnkgYmxvY2sgb2YgdGhlIHBsYWludGV4dHMgaXMNCj4+MS8oMl4xMjgp IGluIHRoaXMgY2FzZS4NCj4NCj4+SSBzdXBwb3J0IHRoZSBzdHJvbmdlc3QgaW5kaXN0aW5ndWlz aGFiaWxpdHkgbm90aW9uIG1lbnRpb25lZCBpbiAoKikNCj4+YWJvdmUsIGJ1dCBpbiBteSBvcGlu aW9uIHdlIHNob3VsZCBwcm92aWRlIGdvb2QgZGVzY3JpcHRpb24gdG8gdGhlIHVzZXJzLg0KPg0K Pk9LLCBJIHRoaW5rIG5vdyB3ZSBhcmUgYXQgdGhlIGhlYXJ0IG9mIHlvdXIgYXJndW1lbnQuIFlv dSBzdXBwb3J0IG91cg0KPmNob2ljZSBvZiBzZWN1cml0eSBkZWZpbml0aW9uIGFuZCBtZXRob2Qg b2YgYW5hbHlzaXMgYWZ0ZXIgYWxsLg0KPg0KPkFuZCB3ZSBjYW4gYWdyZWUgdGhhdCBnb29kIGRl c2NyaXB0aW9ucyBjYW4gb25seSBoZWxwLg0KPg0KPj5UaGF0IGlzIHdoeSBJIHN1cHBvcnQgdGhl IGxpbWl0IGFyb3VuZCAyXjM4IHJlY29yZHMuDQo+DQo+SSBkb24ndCBzZWUgaG93IGNoYW5naW5n IDJeMjQuNSAod2hpY2ggaXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQpIHRvIDJeMzgNCj5wcm92aWRl cyBhIGJldHRlciBkZXNjcmlwdGlvbiB0byB1c2Vycy4NCj4NCj5BcmUgeW91IHdvcnJpZWQgdGhl eSB3b24ndCBrbm93IHdoYXQgYSBkZWNpbWFsIGluIHRoZSBleHBvbmVudCBtZWFucz8NCj4NCj5P ciwgbW9yZSBzZXJpb3VzbHksIGFyZSB5b3Ugc2F5aW5nIHRoYXQgMl57LTMyfSBmb3Igc2luZ2xl IGtleSBhdHRhY2tzIGlzDQo+YSBiaWcgZW5vdWdoIHNlY3VyaXR5IG1hcmdpbj8gSWYgc28sIGNh biB5b3Ugc2F5IHdoYXQgdGhhdCdzIGJhc2VkIG9uPw0KDQpJdCB3b3VsZCBub3QgbWFrZSBzZW5z ZSB0byBhc2sgcGVvcGxlIHRvIHJla2V5IHVubmVjZXNzYXJpbHkuIDEgaW4gMl4zMiBpcw0KMSBp biA0LDI5NCw5NjcsMjk2IGZvciB0aGUgaW5kaXN0aW5ndWlzaGFiaWxpdHkgYXR0YWNrLg0KDQo+ Q2hlZXJzLA0KPg0KPktlbm55DQoNClJlZ2FyZHMsDQpRdXluaC4gDQoNCj4gDQo+DQo+DQo+Pg0K Pj5SZWdhcmRzLA0KPj5RdXluaC4gDQo+Pg0KPj5PbiA3LzEyLzE2LCAxMDowMyBBTSwgIlBhdGVy c29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+DQo+Pndyb3RlOg0KPj4NCj4+ PkhpIFF1eW5oLA0KPj4+DQo+Pj5UaGlzIGluZGlzdGluZ3Vpc2hhYmlsaXR5LWJhc2VkIHNlY3Vy aXR5IG5vdGlvbiBpcyB0aGUgY29uZmlkZW50aWFsaXR5DQo+Pj5ub3Rpb24gdGhhdCBpcyBieSBu b3cgZ2VuZXJhbGx5IGFjY2VwdGVkIGluIHRoZSBjcnlwdG8gY29tbXVuaXR5Lg0KPj4+TWVldGlu Zw0KPj4+aXQgaXMgc3VmZmljaWVudCB0byBndWFyYW50ZWUgc2VjdXJpdHkgYWdhaW5zdCBtYW55 IG90aGVyIGZvcm1zIG9mDQo+Pj5hdHRhY2sNCj4+Pm9uIGNvbmZpZGVudGlhbGl0eSwgd2hpY2gg aXMgb25lIG9mIHRoZSBtYWluIHJlYXNvbnMgd2UgdXNlIGl0Lg0KPj4+DQo+Pj5Zb3Ugc2F5IHRo YXQgYW4gYXR0YWNrIGluIHRoZSBzZW5zZSBpbXBsaWVkIGJ5IGJyZWFraW5nIHRoaXMgbm90aW9u IGRvZXMNCj4+Pm5vdCBicmVhayBjb25maWRlbnRpYWxpdHkuIENhbiB5b3UgZXhwbGFpbiB3aGF0 IHlvdSBtZWFuIGJ5DQo+Pj4iY29uZmlkZW50aWFsaXR5IiwgaW4gYSBwcmVjaXNlIHdheT8gSSBj YW4gdGhlbiB0cnkgdG8gdGVsbCB5b3Ugd2hldGhlcg0KPj4+dGhpcyBub3Rpb24gd2lsbCBpbXBs eSB5b3Vycy4NCj4+Pg0KPj4+UmVnYXJkcw0KPj4+DQo+Pj5LZW5ueSANCj4+Pg0KPj4+T24gMTIv MDcvMjAxNiAxNDowNCwgIlRMUyBvbiBiZWhhbGYgb2YgRGFuZywgUXV5bmggKEZlZCkiDQo+Pj48 dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdy b3RlOg0KPj4+DQo+Pj4+SGkgRXJpYyBhbmQgYWxsLA0KPj4+Pg0KPj4+Pg0KPj4+PkluIG15IG9w aW5pb24sIHdlIHNob3VsZCBnaXZlIGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCBkYXRhIGxpbWl0 IGZvcg0KPj4+PkFFU19HQ00gaW4gVExTIDEuMyBpbnN0ZWFkIG9mIHdoYXQgaXMgY3VycmVudCBp biB0aGUgZHJhZnQgMTQuDQo+Pj4+DQo+Pj4+DQo+Pj4+SW4gdGhpcyBwYXBlcjogaHR0cDovL3d3 dy5pc2cucmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZiwgIHdoYXQgaXMNCj4+Pj5jYWxs ZWQgY29uZmlkZW50aWFsaXR5IGF0dGFjayBpcyB0aGUga25vd24gcGxhaW50ZXh0IGRpZmZlcmVu dGlhbGl0eQ0KPj4+PmF0dGFjayB3aGVyZQ0KPj4+PiB0aGUgYXR0YWNrZXIgaGFzL2Nob29zZXMg dHdvIHBsYWludGV4dHMsIHNlbmQgdGhlbSB0byB0aGUNCj4+Pj5BRVMtZW5jcnlwdGlvbg0KPj4+ Pm9yYWNsZS4gIFRoZSBvcmFjbGUgZW5jcnlwdHMgb25lIG9mIHRoZW0sIHRoZW4gc2VuZHMgdGhl IGNpcGhlcnRleHQgdG8NCj4+Pj50aGUgYXR0YWNrZXIuICBBZnRlciBzZWVpbmcgdGhlIGNpcGhl cnRleHQsIHRoZSBhdHRhY2tlciBoYXMgc29tZQ0KPj4+PnN1Y2Nlc3MNCj4+Pj5wcm9iYWJpbGl0 eSBvZiB0ZWxsaW5nIHdoaWNoIHBsYWludGV4dA0KPj4+PiB3YXMgZW5jcnlwdGVkIGFuZCB0aGlz IHN1Y2Nlc3MgcHJvYmFiaWxpdHkgaXMgaW4gdGhlIGNvbHVtbiBjYWxsZWQNCj4+Pj6p+EF0dGFj ayBTdWNjZXNzIFByb2JhYmlsaXR5qfcgaW4gVGFibGUgMS4gIFRoaXMgYXR0YWNrIGRvZXMgbm90 IGJyZWFrDQo+Pj4+Y29uZmlkZW50aWFsaXR5Lg0KPj4+Pg0KPj4+Pg0KPj4+PklmIHRoZSBhdHRh Y2sgYWJvdmUgYnJlYWtzIG9uZSBvZiBzZWN1cml0eSBnb2FsKHMpIG9mIHlvdXIgaW5kaXZpZHVh bA0KPj4+PnN5c3RlbSwgdGhlbiBtYWtpbmcgc3VjY2VzcyBwcm9iYWJpbGl0eSBvZiB0aGF0IGF0 dGFjayBhdCAyXigtMzIpIG1heA0KPj4+PmlzDQo+Pj4+ZW5vdWdoLiBJbiB0aGF0IGNhc2UsIHRo ZSBNYXggbnVtYmVyIG9mIHJlY29yZHMgaXMgYXJvdW5kIDJeMzguDQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+UmVnYXJkcywNCj4+Pj5RdXluaC4gDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+RGF0ZTogTW9uZGF5LCBKdWx5IDExLCAyMDE2IGF0IDM6MDggUE0N Cj4+Pj5UbzogInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NCj4+Pj5TdWJqZWN0OiBbVExT XSBOZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdGxzLXRsczEzLTE0LnR4dA0KPj4+Pg0KPj4+Pg0KPj4+ Pg0KPj4+PkZvbGtzLA0KPj4+Pg0KPj4+Pg0KPj4+PkkndmUganVzdCBzdWJtaXR0ZWQgZHJhZnQt aWV0Zi10bHMtdGxzMTMtMTQudHh0IGFuZCBpdCBzaG91bGQNCj4+Pj5zaG93IHVwIG9uIHRoZSBk cmFmdCByZXBvc2l0b3J5IHNob3J0bHkuIEluIHRoZSBtZWFudGltZSB5b3UNCj4+Pj5jYW4gZmlu ZCB0aGUgZWRpdG9yJ3MgY29weSBpbiB0aGUgdXN1YWwgbG9jYXRpb24gYXQ6DQo+Pj4+DQo+Pj4+ DQo+Pj4+ICBodHRwOi8vdGxzd2cuZ2l0aHViLmlvL3RsczEzLXNwZWMvDQo+Pj4+DQo+Pj4+DQo+ Pj4+VGhlIG1ham9yIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCBhcmU6DQo+Pj4+DQo+Pj4+DQo+ Pj4+KiBBIGJpZyByZXN0cnVjdHVyZSB0byBtYWtlIGl0IHJlYWQgYmV0dGVyLiBJIG1vdmVkIHRo ZSBPdmVydmlldw0KPj4+PiAgdG8gdGhlIGJlZ2lubmluZyBhbmQgdGhlbiBwdXQgdGhlIGRvY3Vt ZW50IGluIGEgbW9yZSBsb2dpY2FsDQo+Pj4+ICBvcmRlciBzdGFydGluZyB3aXRoIHRoZSBoYW5k c2hha2UgYW5kIHRoZW4gdGhlIHJlY29yZCBhbmQNCj4+Pj4gIGFsZXJ0cy4NCj4+Pj4NCj4+Pj4N Cj4+Pj4qIFRvdGFsbHkgcmV3cm90ZSB0aGUgc2VjdGlvbiB3aGljaCB1c2VkIHRvIGJlIGNhbGxl ZCAiU2VjdXJpdHkNCj4+Pj4gIEFuYWx5c2lzIiBhbmQgaXMgbm93IGNhbGxlZCAiT3ZlcnZpZXcg b2YgU2VjdXJpdHkgUHJvcGVydGllcyIuDQo+Pj4+ICBUaGlzIHNlY3Rpb24gaXMgc3RpbGwga2lu ZCBvZiBhIGhhcmQgaGF0IGFyZWEsIHNvIFBScyB3ZWxjb21lLg0KPj4+PiAgSW4gcGFydGljdWxh ciwgSSBrbm93IEkgbmVlZCB0byBiZWVmIHVwIHRoZSBjaXRhdGlvbnMgZm9yIHRoZQ0KPj4+PiAg cmVjb3JkIGxheWVyIHNlY3Rpb24uDQo+Pj4+DQo+Pj4+DQo+Pj4+KiBSZW1vdmVkIHRoZSAwLVJU VCBFbmNyeXB0ZWRFeHRlbnNpb25zIGFuZCBtb3ZlZCB0aWNrZXRfYWdlDQo+Pj4+ICBpbnRvIHRo ZSBDbGllbnRIZWxsby4gVGhpcyBxdWFzaS1yZXZlcnRzIGEgY2hhbmdlIGluIC0xMyB0aGF0DQo+ Pj4+ICBtYWRlIGltcGxlbWVudGF0aW9uIG9mIDAtUlRUIGtpbmQgb2YgYSBwYWluLg0KPj4+Pg0K Pj4+Pg0KPj4+PkFzIHVzdWFsLCBjb21tZW50cyB3ZWxjb21lLg0KPj4+Pi1Fa3INCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4qIEFsbG93IGNvb2tpZXMgdG8gYmUgbG9u Z2VyICgqKQ0KPj4+Pg0KPj4+Pg0KPj4+PiogUmVtb3ZlIHRoZSAiY29udGV4dCIgZnJvbSBFYXJs eURhdGFJbmRpY2F0aW9uIGFzIGl0IHdhcyB1bmRlZmluZWQNCj4+Pj4gIGFuZCBub2JvZHkgdXNl ZCBpdCAoKikNCj4+Pj4NCj4+Pj4NCj4+Pj4qIFJlbW92ZSAwLVJUVCBFbmNyeXB0ZWRFeHRlbnNp b25zIGFuZCByZXBsYWNlIHRoZSB0aWNrZXRfYWdlIGV4dGVuc2lvbg0KPj4+PiAgd2l0aCBhbiBv YmZ1c2NhdGVkIHZlcnNpb24uIEFsc28gbmVjZXNzaXRhdGVzIGEgY2hhbmdlIHRvDQo+Pj4+ICBO ZXdTZXNzaW9uVGlja2V0ICgqKS4NCj4+Pj4NCj4+Pj4NCj4+Pj4qIE1vdmUgdGhlIGRvd25ncmFk ZSBzZW50aW5lbCB0byB0aGUgZW5kIG9mIFNlcnZlckhlbGxvLlJhbmRvbQ0KPj4+PiAgdG8gYWNj b21vZGF0ZSB0bHNkYXRlICgqKS4NCj4+Pj4NCj4+Pj4NCj4+Pj4qIERlZmluZSBlY2RzYV9zaGEx ICgqKS4NCj4+Pj4NCj4+Pj4NCj4+Pj4qIEFsbG93IHJlc3VtcHRpb24gZXZlbiBhZnRlciBmYXRh bCBhbGVydHMuIFRoaXMgbWF0Y2hlcyBjdXJyZW50DQo+Pj4+ICBwcmFjdGljZS4NCj4+Pj4NCj4+ Pj4NCj4+Pj4qIFJlbW92ZSBub24tY2xvc3VyZSB3YXJuaW5nIGFsZXJ0cy4gUmVxdWlyZSB0cmVh dGluZyB1bmtub3duIGFsZXJ0cyBhcw0KPj4+PiAgZmF0YWwuDQo+Pj4+DQo+Pj4+DQo+Pj4+KiBN YWtlIHRoZSBydWxlcyBmb3IgYWNjZXB0aW5nIDAtUlRUIGxlc3MgcmVzdHJpY3RpdmUuDQo+Pj4+ DQo+Pj4+DQo+Pj4+KiBDbGFyaWZ5IDAtUlRUIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgcnVsZXMu DQo+Pj4+DQo+Pj4+DQo+Pj4+KiBDbGFyaWZ5IGhvdyAwLVJUVCBhbmQgUFNLIGlkZW50aXRpZXMg aW50ZXJhY3QuDQo+Pj4+DQo+Pj4+DQo+Pj4+KiBBZGQgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhl IGRhdGEgbGltaXRzIGZvciBlYWNoIGNpcGhlci4NCj4+Pj4NCj4+Pj4NCj4+Pj4qIE1ham9yIGVk aXRvcmlhbCByZXN0cnVjdHVyaW5nLg0KPj4+Pg0KPj4+Pg0KPj4+PiogUmVwbGFjZSB0aGUgU2Vj dXJpdHkgQW5hbHlzaXMgc2VjdGlvbiB3aXRoIGEgV0lQIGRyYWZ0Lg0KPj4+Pg0KPj4+Pg0KPj4+ PigqKSBpbmRpY2F0ZXMgY2hhbmdlcyB0byB0aGUgd2lyZSBwcm90b2NvbCB3aGljaCBtYXkgcmVx dWlyZQ0KPj4+PmltcGxlbWVudGF0aW9ucw0KPj4+PiAgICB0byB1cGRhdGUuDQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+DQo+DQoNCg== From nobody Tue Jul 12 10:17:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853B912D5D3 for ; Tue, 12 Jul 2016 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBPDeYCDFEUD for ; Tue, 12 Jul 2016 10:17:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00065.outbound.protection.outlook.com [40.107.0.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D577712D785 for ; Tue, 12 Jul 2016 10:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NfPGAgaGP8BV6bNapefCsBVCm5Qhmejpr0OePaLwCOM=; b=w5Stlc5Sr8HNISYKX1pGkG8pxr+FCizCZRCNucvwkyXR5sQRw+Fvx8bjx3/V3Cs0U5YB1HWsxBckFEyMIDOafQrEWJw/CM/5l0b+5caRdRZBTVyhk2xtFAavEY7pBr3E6XM7NGPTnig9D81Lotw5L0OOiwuhoWLfM4rDBnsNv9I= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1821.eurprd03.prod.outlook.com (10.166.42.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 17:17:11 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 17:17:11 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , "Scott Fluhrer (sfluhrer)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAACUMAgAAetID///d5AIAAFNgA Date: Tue, 12 Jul 2016 17:17:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 0ac0d550-c418-4311-931d-08d3aa785cc2 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1821; 6:c0iJs8IYSEf2/lNLAZx/2MM45lwtPLLvy8bfXwuE62jGeXzUMYZ19hG/9sl7AwW0EGjrYERZLNyldAsVzY1ZKX3VQXvaFGDxRNnV5quMKkQXJm2djurzbpTrULrRtgZxvoJup7u2acnU3XhwAttq6AWq1wZ/Byo1VFefKqaWTi3EtJkud/znenR76g6aj0tFXhS4UAbICGuuWojPdm5MTzi5pl8GtQ1uCcloWuNjNP/NbvQRLpr4LOZ+TfwdXmU7h47NH0L6zpz3bvn6dMebEEJ4HyH2RPRoPFIId0YkXDc=; 5:ff0zZhDpvMOI7WDd2r4K8SCh4nROIqA9I0nDkitbbICrCFloZB10Y6iIrZp9WV3k1CRIfJAP9/PRpAS52o/5VT29V/nsdbA0paW9yKzyVy1OkzC07jHKj9b4mH8Ut4jISz5nSpFQ+tF3fKoaVZUImw==; 24:lAEMfo8AnNPJ7K9YyBI+Z6CmSEhzsjVOYDHIlEQyjrriKA1i5IsA1q8t0qR/HKE4zKj4UBE1nSZeUxyYlW6XiBNKDnltB61xv9Eg/aYXtO0=; 7:IuneG1jmeD7rAWBkMyDVpzRUSit/DdtZOXO+MpYyYXcyF912rK9/G79WNuQCK63p9EhnQRE6FWf4KX+ADyba5Pg7tRy1GsLkuRzc145n2tyyQOEMydR/RSe1qumAr3+OFpBwIn2a7d3Kk/rzqbK+F43oQ5wK4L7YC0vrXkIVwiFSISxFztqxNvVbHRnaViqjOu7ra57dO/VsGBzfNhDI5/c+EWhTIII2wFTUVkI2u6wI2qcup98HqJTFlUMyi5Ls x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1821; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1821; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1821; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51444003)(24454002)(377454003)(199003)(189002)(2501003)(83506001)(50986999)(101416001)(54356999)(76176999)(36756003)(66066001)(586003)(8676002)(102836003)(68736007)(3846002)(10400500002)(6116002)(77096005)(2950100001)(2900100001)(5002640100001)(81156014)(81166006)(2906002)(8936002)(122556002)(11100500001)(3660700001)(305945005)(8666005)(7846002)(7736002)(93886004)(3280700002)(87936001)(230783001)(92566002)(4001350100001)(5001770100001)(97736004)(189998001)(107886002)(74482002)(106356001)(106116001)(105586002)(86362001)(19580395003)(19580405001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1821; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:17:11.8114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1821 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:17:21 -0000 SGkNCg0KT24gMTIvMDcvMjAxNiAxODowNCwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFu Z0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5IaSBLZW5ueSwgDQo+DQo+T24gNy8xMi8xNiwgMTI6MzMg UE0sICJQYXRlcnNvbiwgS2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPiB3cm90ZToN Cj4NCj4+RmluYWxseSwgeW91IHdyaXRlICJ0byBjb21lIHRvIHRoZSAyXjM4IHJlY29yZCBsaW1p dCwgdGhleSBhc3N1bWUgdGhhdA0KPj5lYWNoIHJlY29yZCBpcyB0aGUgbWF4aW11bSAyXjE0IGJ5 dGVzIi4gRm9yIGNsYXJpdHksIHdlIGRpZCBub3QgcmVjb21tZW5kDQo+PmEgbGltaXQgb2YgMl4z OCByZWNvcmRzLiBUaGF0J3MgUXV5bmgncyBwcmVmZXJyZWQgbnVtYmVyLCBhbmQgaXMNCj4+dW5z dXBwb3J0ZWQgYnkgb3VyIGFuYWx5c2lzLg0KPg0KPldoYXQgaXMgcHJvYmxlbSB3aXRoIG15IHN1 Z2dlc3Rpb24gZXZlbiB3aXRoIHRoZSByZWNvcmQgc2l6ZSBiZWluZyB0aGUNCj5tYXhpbXVtIHZh bHVlPw0KDQpUaGVyZSBtYXkgYmUgbm8gcHJvYmxlbSB3aXRoIHlvdXIgc3VnZ2VzdGlvbi4gSSB3 YXMgc2ltcGx5IHRyeWluZyB0byBtYWtlDQppdCBjbGVhciB0aGF0IDJeMzggcmVjb3JkcyB3YXMg eW91ciBzdWdnZXN0aW9uIGZvciB0aGUgcmVjb3JkIGxpbWl0IGFuZA0Kbm90IG91cnMuIEluZGVl ZCwgaWYgb25lIHJlYWRzIG91ciBub3RlIGNhcmVmdWxseSwgb25lIHdpbGwgZmluZCB0aGF0IHdl DQpkbyBub3QgbWFrZSBhbnkgc3BlY2lmaWMgcmVjb21tZW5kYXRpb25zLiBXZSBjb25zaWRlciB0 aGUgZGVjaXNpb24gdG8gYmUNCm9uZSBmb3IgdGhlIFdHOyBvdXIgcHJlZmVycmVkIHJvbGUgaXMg dG8gc3VwcGx5IHRoZSBhbmFseXNpcyBhbmQgaGVscA0KaW50ZXJwcmV0IGl0IGlmIHBlb3BsZSB3 YW50IHRoYXQuIFBhcnQgb2YgdGhhdCBpbnZvbHZlcyBjb3JyZWN0aW5nDQpwb3NzaWJsZSBtaXNj b25jZXB0aW9ucyBhbmQgbWlzaW50ZXJwcmV0YXRpb25zIGJlZm9yZSB0aGV5IGdldCBvdXQgb2Yg aGFuZC4NCg0KTm93IDJeMzggZG9lcyBjb21lIG91dCBvZiBvdXIgYW5hbHlzaXMgaWYgeW91IGFy ZSB3aWxsaW5nIHRvIGFjY2VwdCBzaW5nbGUNCmtleSBhdHRhY2sgc2VjdXJpdHkgKGluIHRoZSBp bmRpc3Rpbmd1aXNoYWJpbGl0eSBzZW5zZSkgb2YgMl57LTMyfS4gU28gaW4NCnRoYXQgbGltaXRl ZCBzZW5zZSwgMl4zOCBpcyBzdXBwb3J0ZWQgYnkgb3VyIGFuYWx5c2lzLiBCdXQgaXQgaXMgbm90 IG91cg0KcmVjb21tZW5kYXRpb24uDQoNCkJ1dCwgc3BlYWtpbmcgbm93IGluIGEgcGVyc29uYWwg Y2FwYWNpdHksIEkgY29uc2lkZXIgdGhhdCBzZWN1cml0eSBtYXJnaW4NCnRvIGJlIHRvbyBzbWFs bCAoaS5lLiBJIHRoaW5rIHRoYXQgMl57LTMyfSBpcyB0b28gYmlnIGEgc3VjY2Vzcw0KcHJvYmFi aWxpdHkpLg0KDQpSZWdhcmRzLA0KDQpLZW5ueSANCg0K From nobody Tue Jul 12 10:39:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC212D59B for ; Tue, 12 Jul 2016 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCLR_84AbrtH for ; Tue, 12 Jul 2016 10:39:20 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0087.outbound.protection.outlook.com [104.47.2.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 F327412D586 for ; Tue, 12 Jul 2016 10:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N8FAaIR8kNMPWTtyeacemA9SzPvw8eASw3+PqH3Z5V4=; b=Nff268W/ALOXREyiJ5u0mYrufjcaLsfFkmY/d511VkeD9s5crDpdzobedxWB8k8pQxn0MHVuVmp8HG1fUTfRrFRzZ/GQjSVeHVGpnpaWYatDXv9ufmHWbhaRvt+RqHe2tycS3Yg9Grtw9vEReb3rwviQGjz8MltVniXszpw5tXk= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 17:39:17 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 17:39:17 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA///wrQCAABjmgA== Date: Tue, 12 Jul 2016 17:39:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 6ab184cb-f561-4316-3c3e-08d3aa7b72aa x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:UKT3e+7hIkrocngBg+0C9fIVxoMJQilWOkgs2sAt2NcfVyaS3JVQ4G1QnwVlfiQcai35vSgg6sCeuNT9+TCijH2sg9HAyUd5aVJOZDMxm6GNX6L+m4eLk307qstPbjjnwDwI0tpoxzXhiM8QiXEoda5bZQOmPJvID/gC19r8LxftkGvJxEGxSckjWMm3bma7pvA13zB0AwwxG4rEshtTvcP9qDNMgjMVv4HDo0Gg5Z9NaiYO+bgMxZTcA/BX/6izljvFKX0wmUteDVJHX7CaxnH0aly2jAL6nffu7+w0VV4=; 5:a0QJ53EtJHF3SaDEOHHD1FkVuy9elb6pqIo0cvUBo6eiBaVHPTsQhWM0cUMGhJZxdCnvnNIcD2Vn37uvdMPhdnnI9a8yZyZiC+disXSQVt3FnZ8uK+gXM8qFjv8Km/5hV73GkKnBWqLcyuokXcbKTg==; 24:IgJ7RtZlIWC5SY2qtir0MpA9EyjReXVSc4mgbVJJOhTGzudlq4NwQohEiF21HvHB3pgMVlQ8l7RhpYIw4Wjkc0OHVXHpkbXgRLhMLIAskqg=; 7:zgOEfAdZiQDXlCNedW24d3QCOvpvPwLGpPFVUwL/H4cZXL1I+sdYk/7agklWaDsZTHVYpnjDHUjY7y/lbXaECtHmKCuLWIltXSPRaokfbB0iZyWsbc9i+mq94ooiTl0YxTWW6BZ6v7K01MBJtZA70jW3JYYO2S862fQjmSeGTpvNqv091WGkxp52AQzuOWG+rt9l/YwKiXeueBM9VwitNRyT3OG49LeQt4xXnJl7F1sS4NfJga7QXxyQYY2E1XJs x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(377454003)(101416001)(305945005)(66066001)(36756003)(81166006)(2950100001)(2900100001)(54356999)(76176999)(50986999)(8666005)(7736002)(74482002)(8936002)(2501003)(83506001)(7846002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(3846002)(230783001)(106116001)(2906002)(6116002)(68736007)(106356001)(102836003)(87936001)(105586002)(86362001)(3280700002)(107886002)(10400500002)(3660700001)(5001770100001)(97736004)(11100500001)(189998001)(4001350100001)(93886004)(8676002)(5002640100001)(586003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7970C4B4FFE63B4E944C39ECBC4569E3@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:39:16.9249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:39:22 -0000 SGkNCg0KT24gMTIvMDcvMjAxNiAxODoxMiwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFu Z0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5IaSBLZW5ueSwgDQo+DQo+T24gNy8xMi8xNiwgMTowNSBQ TSwgIlBhdGVyc29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+IHdyb3RlOg0K Pg0KPj5IaQ0KPj4NCj4+T24gMTIvMDcvMjAxNiAxNjoxMiwgIkRhbmcsIFF1eW5oIChGZWQpIiA8 cXV5bmguZGFuZ0BuaXN0Lmdvdj4gd3JvdGU6DQo+Pg0KPj4+SGkgS2VubnksDQo+Pj4NCj4+Pkkg c3VwcG9ydCB0aGUgc3Ryb25nZXN0IGluZGlzdGluZ3Vpc2hhYmlsaXR5IG5vdGlvbiBtZW50aW9u ZWQgaW4gKCopDQo+Pj5hYm92ZSwgYnV0IGluIG15IG9waW5pb24gd2Ugc2hvdWxkIHByb3ZpZGUg Z29vZCBkZXNjcmlwdGlvbiB0byB0aGUNCj4+PnVzZXJzLg0KPj4NCj4+T0ssIEkgdGhpbmsgbm93 IHdlIGFyZSBhdCB0aGUgaGVhcnQgb2YgeW91ciBhcmd1bWVudC4gWW91IHN1cHBvcnQgb3VyDQo+ PmNob2ljZSBvZiBzZWN1cml0eSBkZWZpbml0aW9uIGFuZCBtZXRob2Qgb2YgYW5hbHlzaXMgYWZ0 ZXIgYWxsLg0KPj4NCj4+QW5kIHdlIGNhbiBhZ3JlZSB0aGF0IGdvb2QgZGVzY3JpcHRpb25zIGNh biBvbmx5IGhlbHAuDQo+Pg0KPj4+VGhhdCBpcyB3aHkgSSBzdXBwb3J0IHRoZSBsaW1pdCBhcm91 bmQgMl4zOCByZWNvcmRzLg0KPj4NCj4+SSBkb24ndCBzZWUgaG93IGNoYW5naW5nIDJeMjQuNSAo d2hpY2ggaXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQpIHRvIDJeMzgNCj4+cHJvdmlkZXMgYSBiZXR0 ZXIgZGVzY3JpcHRpb24gdG8gdXNlcnMuDQo+Pg0KPj5BcmUgeW91IHdvcnJpZWQgdGhleSB3b24n dCBrbm93IHdoYXQgYSBkZWNpbWFsIGluIHRoZSBleHBvbmVudCBtZWFucz8NCj4+DQo+Pk9yLCBt b3JlIHNlcmlvdXNseSwgYXJlIHlvdSBzYXlpbmcgdGhhdCAyXnstMzJ9IGZvciBzaW5nbGUga2V5 IGF0dGFja3MgaXMNCj4+YSBiaWcgZW5vdWdoIHNlY3VyaXR5IG1hcmdpbj8gSWYgc28sIGNhbiB5 b3Ugc2F5IHdoYXQgdGhhdCdzIGJhc2VkIG9uPw0KPg0KPkl0IHdvdWxkIG5vdCBtYWtlIHNlbnNl IHRvIGFzayBwZW9wbGUgdG8gcmVrZXkgdW5uZWNlc3NhcmlseS4gMSBpbiAyXjMyIGlzDQo+MSBp biA0LDI5NCw5NjcsMjk2IGZvciB0aGUgaW5kaXN0aW5ndWlzaGFiaWxpdHkgYXR0YWNrLg0KDQpJ IHdvdWxkIGFncmVlIHRoYXQgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBhc2sgVExTIHBlZXJz IHRvIHJla2V5DQp1bm5lY2Vzc2FyaWx5LiBJIGFsc28gYWdyZWUgdGhhdCAxIGluIDJeMzIgaXMN CjEgaW4gNCwyOTQsOTY3LDI5Ni4gU3VyZSBsb29rcyBsaWtlIGEgYmlnLCBzY2FyeSBudW1iZXIs IGRvbid0IGl0Pw0KDQpBcmUgeW91IHRoZW4gYXJndWluZyB0aGF0IDJeey0zMn0gZm9yIHNpbmds ZSBrZXkgYXR0YWNrcyBpcyBhIGJpZyBlbm91Z2gNCnNlY3VyaXR5IG1hcmdpbiBiZWNhdXNlIHdl IHdhbnQgdG8gYXZvaWQgcmVrZXlpbmc/IFRoZW4gZG8geW91IGhhdmUgYQ0Kc3BlY2lmaWMgY29u Y2VybiBhYm91dCB0aGUgc2VjdXJpdHkgb2YgcmVrZXlpbmc/IEkgY291bGQgc2VlIHZhcmlvdXMg d2F5cw0KaW4gd2hpY2ggaXQgbWlnaHQgZ28gd3JvbmcgaWYgbm90IGRlc2lnbmVkIGNhcmVmdWxs eS4NCg0KT3IgYXJlIHlvdSBkaXJlY3RseSBsaW5raW5nIGEgZnVuZGFtZW50YWwgc2VjdXJpdHkg cXVlc3Rpb24gdG8gYW4NCm9wZXJhdGlvbmFsIG9uZSwgYnkgd2hpY2ggSSBtZWFuOiBhcmUgeW91 IHNheWluZyB3ZSBzaG91bGQgdHJhZGUgc2VjdXJpdHkNCmZvciBhdm9pZGluZyB0aGUgImNvc3Qi IG9mIHJla2V5aW5nIGZvciBzb21lIG5vdGlvbiBvZiAiY29zdCI/IElmIHNvLCBjYW4NCnlvdSBx dWFudGlmeSB0aGUgY29zdCBmb3IgdGhlIHVzZSBjYXNlcyB0aGF0IG1hdHRlciB0byB5b3U/DQoN CkNoZWVycywNCg0KS2VubnkgDQoNCg== From nobody Tue Jul 12 10:47:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C350B12D586 for ; Tue, 12 Jul 2016 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAyCVWU5Wp6s for ; Tue, 12 Jul 2016 10:47:38 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 EB11312D59F for ; Tue, 12 Jul 2016 10:47:37 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6so86544561ith.1 for ; Tue, 12 Jul 2016 10:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nc2P3z3RgDhSVmSNL8eUBgI1dbndGEyNf/3CzqsnRwY=; b=PeJ7vWKQI6WGJBBew5DjhJXosDIgQINtUAERpbiAgR2SYkBNT20vYIdpny4wJjWsGU JdShJWboH8W54MctoPfwtyWLLva2bSkfnx9RReZqEKfZIRewkQJXQ8Rv/n6qq7AIvnrW 2H2lwwUW9Lkvl+Y0gvWXypihS0jozqqMeXYlI= 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; bh=nc2P3z3RgDhSVmSNL8eUBgI1dbndGEyNf/3CzqsnRwY=; b=ZMxLpMYb4ChWDfJ2HziSLKgrNJm+d/OWmv+Ou8a1I2xZ8OWqEXi+sasWLDThXj4qsQ brl8K5RpEdPm8Nlrmr4mQMcBauW3V1TZozZDPsJWQ6PBeFTg5gcR+E6D2YSp4nipoKK3 drmm8NO7DVXVvIOTKDenKvvoz8UeE1i4yx/S9CeGYeHKSnvHgQF0OOBrgKSbbWaEa21A QNmiEHQ9pFfj+Mg0yijZP7uTHWgOCz5gUn+TakBzpqyiMPhG6VSarIcQHsd5wnKWJ2rK VpXt1PQ8pKTX3kdbr9OG3Ld0RX04eEY3TND91KGk32GdE95udT+eNcQ1G1HBQLhT5saO 4QuQ== X-Gm-Message-State: ALyK8tJnJPnA2vdJtNFfJp1QJP6b03vG1V3NodcMpWDUFykEsbU/hzkpZRGfrlULKDgwRpogir6q2mtcS4L9WjFN X-Received: by 10.36.23.210 with SMTP id 201mr13813958ith.18.1468345657027; Tue, 12 Jul 2016 10:47:37 -0700 (PDT) MIME-Version: 1.0 References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Tue, 12 Jul 2016 17:47:26 +0000 Message-ID: To: Ilari Liusvaara , Eric Rescorla Content-Type: multipart/alternative; boundary=001a114370be4c1f4a053773ddb3 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:47:39 -0000 --001a114370be4c1f4a053773ddb3 Content-Type: text/plain; charset=UTF-8 [Changing subject since the other thread is about something else.] On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara wrote: > > ### Signature Algorithms > > > > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are > > encoded in two octets, so SignatureScheme values have been allocated to > > align with TLS 1.2's encoding. Some legacy pairs are left unallocated. > These > > algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or > > negotiated by any implementation. In particular, MD5 {{SLOTH}} and > SHA-224 > > MUST NOT be used. > > > > * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA > hash/signature pairs. > > However, the old semantics did not constrain the signing curve. > > Also, for interoperability, any legal TLS 1.3 meaning of these algorithms > must > be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything > else > would be pointless trap. > > This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those > work. > > Also, even if meaning of the ECDSA codepoints changed, those would not > break > that rule, since new definition is strict subset of old. Certainly, whether RSA-PSS and EdDSA are defined in 1.2 or not needs to be decided. Otherwise, a server may see a 1.3 ClientHello with an RSA-PSS offer, implement RSA-PSS (because the underlying library can do 1.3), but select 1.2 (because, for whatever reason, the server is still set to 1.2). If the client believes RSA-PSS does not exist in 1.2 but the server does, we will have interop failure. There's a few other analogous situations with things reversed. I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist in 1.2 because we're not touching the 1.2 registries. But this should be clarified in the spec. I would actually prefer they stay 1.3-only. I personally could live with either, but that's because we've backported the 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some minor weirdness). I did intentionally mean for the scheme to be backportable, but I do not think it should be mandated that implementations do so. 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a hash function and a signature algorithm which takes a pre-hashed value. A 1.3 signature scheme is a function that takes a message. This means that, to backport to TLS 1.2, implementations must remove all pre-hash steps and: 1. For ServerKeyExchange, assemble the client_random || server_random || ServerKeyExchange payload and then pass it into the signature scheme. Current logic probably hashes and then feeds the hash in. 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full handshake transcript, so there's interactions with the PRF. I've seen implementations which require signing hash match the PRF hash, sometimes with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a mess. I've also seen implementations which decouple them, at the cost of maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting forces the second choice. Notably, if backporting EdDSA, there is no rolling hash one can maintain for CertificateVerify anyway. EdDSA is inherently message-based, which motivated the 1.3 change. (That and simpler interfaces.) There is a middle ground: we backport RSA-PSS (then we should assign it in the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA. I intentionally did not do this. I did not want, many years down the line when EdDSA certificates actually exist, for implementations to discover the message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style so any questions about the new scheme would be resolved early. (We've implemented the message-based scheme and it seems to be just fine. If you're willing to pay the cost of the backport to all versions, it actually ends up quite tidy.) David [*] SSL 3.0 ServerKeyExchange is compatible with 1.3's API, but SSL 3.0 CertificateVerify signs some complex construction rather than simply a hash. --001a114370be4c1f4a053773ddb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Changing subject since the other thread is about somethin= g else.]

On Tue, Jul 12,= 2016 at 12:16 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> ###=C2=A0 Signature Algorithms
>
> * In TLS 1.2, the extension contained hash/signature pairs. The pairs = are
>=C2=A0 =C2=A0encoded in two octets, so SignatureScheme values have been= allocated to
>=C2=A0 =C2=A0align with TLS 1.2's encoding. Some legacy pairs are l= eft unallocated. These
>=C2=A0 =C2=A0algorithms are deprecated as of TLS 1.3. They MUST NOT be = offered or
>=C2=A0 =C2=A0negotiated by any implementation. In particular, MD5 {{SLO= TH}} and SHA-224
>=C2=A0 =C2=A0MUST NOT be used.
>
> * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/si= gnature pairs.
>=C2=A0 =C2=A0However, the old semantics did not constrain the signing c= urve.

Also, for interoperability, any legal TLS 1.3 meaning of these algorithms m= ust
be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything els= e
would be pointless trap.

This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those work= .

Also, even if meaning of the ECDSA codepoints changed, those would not brea= k
that rule, since new definition is strict subset of old.
<= br>
Certainly, whether RSA-PSS and EdDSA are defined in 1.2 = or not needs to be decided. Otherwise, a server may see a 1.3 ClientHello w= ith an RSA-PSS offer, implement RSA-PSS (because the underlying library can= do 1.3), but select 1.2 (because, for whatever reason, the server is still= set to 1.2). If the client believes RSA-PSS does not exist in 1.2 but the = server does, we will have interop failure. There's a few other analogou= s situations with things reversed.

= I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist i= n 1.2 because we're not touching the 1.2 registries. But this should be= clarified in the spec. I would actually prefer they stay 1.3-only. I perso= nally could live with either, but that's because we've backported t= he 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some m= inor weirdness). I did intentionally mean for the scheme to be backportable= , but I do not think it should be mandated that implementations do so.

1.2 and 1.3 signatures have different interfaces= . 1.2 is decomposed into a hash function and a signature algorithm which ta= kes a pre-hashed value. A 1.3 signature scheme is a function that takes a m= essage. This means that, to backport to TLS 1.2, implementations must remov= e all pre-hash steps and:

1. For ServerKeyExchange= , assemble the client_random || server_random || ServerKeyExchange payload = and then pass it into the signature scheme. Current logic probably hashes a= nd then feeds the hash in.

2. Client CertificateVe= rify in TLS 1.2 messed up. We sign the full handshake transcript, so there&= #39;s interactions with the PRF. I've seen implementations which requir= e signing hash match the PRF hash, sometimes with a backup SHA-1 hash (NSS)= , at the cost of hash negotiation being a mess. I've also seen implemen= tations which decouple them, at the cost of maintaining the raw handshake b= uffer (OpenSSL, BoringSSL). Backporting forces the second choice.

Notably, if backporting EdDSA, there is no rolling hash one= can maintain for CertificateVerify anyway. EdDSA is inherently message-bas= ed, which motivated the 1.3 change. (That and simpler interfaces.)

There is a middle ground: we backport RSA-PSS (then we sho= uld assign it in the 1.2 style and allocate corresponding 1.3-style numbers= ) and not EdDSA. I intentionally did not do this. I did not want, many year= s down the line when EdDSA certificates actually exist, for implementations= to discover the message-based scheme is trouble. I wanted RSA-PSS to be do= ne in 1.3 style so any questions about the new scheme would be resolved ear= ly.

(We've implemented the message-based schem= e and it seems to be just fine. If you're willing to pay the cost of th= e backport to all versions, it actually ends up quite tidy.)

=
David=C2=A0

[*] SSL 3.0 ServerKeyExchan= ge is compatible with 1.3's API, but SSL 3.0 CertificateVerify signs so= me complex construction rather than simply a hash.
--001a114370be4c1f4a053773ddb3-- From nobody Tue Jul 12 10:53:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7912D5B0 for ; Tue, 12 Jul 2016 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGNNoGtAW2Ae for ; Tue, 12 Jul 2016 10:53:44 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB0012D59F for ; Tue, 12 Jul 2016 10:53:44 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b62so23632368iod.3 for ; Tue, 12 Jul 2016 10:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TEknbLBTmXLwfsSsW7yZIeg+Okp8KYXlt+NgvwPG4Q0=; b=cB9haDjxJIbC5Or6m30824E3htgWFzbKxT/gfSxGlrZFVm2sFPX8LH8fbG3NON0RRt Ufv3wGTvyXiLKBKNkly6rd92RrAekHioQWiWk9PWB5VvJLi4QtLdGFSDUWYKcxszEHdt pdQNKrpSiiOfWIvZW3iSQnO2mWrDlbh4yFpFQ= 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; bh=TEknbLBTmXLwfsSsW7yZIeg+Okp8KYXlt+NgvwPG4Q0=; b=cjqutxE5Kln3u7Gn79XyOYXhrdKRVhI7o5/qRDKJJfL7bGcbxM3tsPXx2IOUzUDeXP ApuyL24O4p/+4M2SicthC6iEehDNUmoIW+tl38MT7XZASPxgaI9gayA6QSXF0atxySBg sUqAVleUcwkALiltO00frFEqFvP4hrtWGG1aJpNWihJSlmfqlIiGyTHwrvpZhYTQXDGC JGiolSGdj2fAsWsHCV5DMbhYK90WKAgw++q6MojEkAy2TRby4jmvy18z1UdrRjbp0iiE kUYYKJ0kefPnvDsy1EGPpQwBy+j2aYADlIpDRpD23tRsG9nzEOcYRvtJJMSgndGVQHac sC7w== X-Gm-Message-State: ALyK8tKJ5uEtmakYN5baEur13xS+XK4vBsu/WGdfaTAvEOdV9MrFwKWnKlyEG2jc9tJBEiaJM/ZRW9QLiXgWLlFX X-Received: by 10.107.52.133 with SMTP id b127mr4499232ioa.6.1468346023973; Tue, 12 Jul 2016 10:53:43 -0700 (PDT) MIME-Version: 1.0 References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Tue, 12 Jul 2016 17:53:34 +0000 Message-ID: To: Ilari Liusvaara , Eric Rescorla Content-Type: multipart/alternative; boundary=001a11440f1c2afffa053773f315 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:53:47 -0000 --001a11440f1c2afffa053773f315 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 1:47 PM David Benjamin wrote: > [Changing subject since the other thread is about something else.] > > On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara > wrote: > >> > ### Signature Algorithms >> > >> > * In TLS 1.2, the extension contained hash/signature pairs. The pairs >> are >> > encoded in two octets, so SignatureScheme values have been allocated >> to >> > align with TLS 1.2's encoding. Some legacy pairs are left >> unallocated. These >> > algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or >> > negotiated by any implementation. In particular, MD5 {{SLOTH}} and >> SHA-224 >> > MUST NOT be used. >> > >> > * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA >> hash/signature pairs. >> > However, the old semantics did not constrain the signing curve. >> >> Also, for interoperability, any legal TLS 1.3 meaning of these algorithms >> must >> be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything >> else >> would be pointless trap. >> >> This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those >> work. >> >> Also, even if meaning of the ECDSA codepoints changed, those would not >> break >> that rule, since new definition is strict subset of old. > > > Certainly, whether RSA-PSS and EdDSA are defined in 1.2 or not needs to be > decided. Otherwise, a server may see a 1.3 ClientHello with an RSA-PSS > offer, implement RSA-PSS (because the underlying library can do 1.3), but > select 1.2 (because, for whatever reason, the server is still set to 1.2). > If the client believes RSA-PSS does not exist in 1.2 but the server does, > we will have interop failure. There's a few other analogous situations with > things reversed. > > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist > in 1.2 because we're not touching the 1.2 registries. But this should be > clarified in the spec. I would actually prefer they stay 1.3-only. I > personally could live with either, but that's because we've backported the > 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some > minor weirdness). I did intentionally mean for the scheme to be > backportable, but I do not think it should be mandated that implementations > do so. > > 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a > hash function and a signature algorithm which takes a pre-hashed value. A > 1.3 signature scheme is a function that takes a message. This means that, > to backport to TLS 1.2, implementations must remove all pre-hash steps and: > > 1. For ServerKeyExchange, assemble the client_random || server_random || > ServerKeyExchange payload and then pass it into the signature scheme. > Current logic probably hashes and then feeds the hash in. > > 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full > handshake transcript, so there's interactions with the PRF. I've seen > implementations which require signing hash match the PRF hash, sometimes > with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a > mess. I've also seen implementations which decouple them, at the cost of > maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting > forces the second choice. > > Notably, if backporting EdDSA, there is no rolling hash one can maintain > for CertificateVerify anyway. EdDSA is inherently message-based, which > motivated the 1.3 change. (That and simpler interfaces.) > I should add: 1.3 CertificateVerify does not have this problem. One signs, e.g.: RSA-PSS-SHA384(padding || context || Hash(HS Context) || Hash(resumption_context)) The HS Context can be maintained as a rolling hash of the PRF hash. The signature scheme internally may use a different pre-hash or no pre-hash at all and the handshake logic doesn't care. There is a middle ground: we backport RSA-PSS (then we should assign it in > the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA. > I intentionally did not do this. I did not want, many years down the line > when EdDSA certificates actually exist, for implementations to discover the > message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style > so any questions about the new scheme would be resolved early. > > (We've implemented the message-based scheme and it seems to be just fine. > If you're willing to pay the cost of the backport to all versions, it > actually ends up quite tidy.) > > David > > [*] SSL 3.0 ServerKeyExchange is compatible with 1.3's API, but SSL 3.0 > CertificateVerify signs some complex construction rather than simply a hash. > --001a11440f1c2afffa053773f315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12= , 2016 at 1:47 PM David Benjamin <davidben@chromium.org> wrote:
[Changing subject since the other thread is about som= ething else.]

On Tue, Ju= l 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
=
> ###=C2=A0 Signature Algorithms
>
> * In TLS 1.2, the extension contained hash/signature pairs. The pairs = are
>=C2=A0 =C2=A0encoded in two octets, so SignatureScheme values have been= allocated to
>=C2=A0 =C2=A0align with TLS 1.2's encoding. Some legacy pairs are l= eft unallocated. These
>=C2=A0 =C2=A0algorithms are deprecated as of TLS 1.3. They MUST NOT be = offered or
>=C2=A0 =C2=A0negotiated by any implementation. In particular, MD5 {{SLO= TH}} and SHA-224
>=C2=A0 =C2=A0MUST NOT be used.
>
> * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/si= gnature pairs.
>=C2=A0 =C2=A0However, the old semantics did not constrain the signing c= urve.

Also, for interoperability, any legal TLS 1.3 meaning of these algorithms m= ust
be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything els= e
would be pointless trap.

This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those work= .

Also, even if meaning of the ECDSA codepoints changed, those would not brea= k
that rule, since new definition is strict subset of old.
<= br>
Certainly, whether RSA-PSS and EdDSA are defined in 1.2 = or not needs to be decided. Otherwise, a server may see a 1.3 ClientHello w= ith an RSA-PSS offer, implement RSA-PSS (because the underlying library can= do 1.3), but select 1.2 (because, for whatever reason, the server is still= set to 1.2). If the client believes RSA-PSS does not exist in 1.2 but the = server does, we will have interop failure. There's a few other analogou= s situations with things reversed.

= I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist i= n 1.2 because we're not touching the 1.2 registries. But this should be= clarified in the spec. I would actually prefer they stay 1.3-only. I perso= nally could live with either, but that's because we've backported t= he 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some m= inor weirdness). I did intentionally mean for the scheme to be backportable= , but I do not think it should be mandated that implementations do so.

1.2 and 1.3 signatures have different interfaces= . 1.2 is decomposed into a hash function and a signature algorithm which ta= kes a pre-hashed value. A 1.3 signature scheme is a function that takes a m= essage. This means that, to backport to TLS 1.2, implementations must remov= e all pre-hash steps and:

1. For ServerKeyExchange= , assemble the client_random || server_random || ServerKeyExchange payload = and then pass it into the signature scheme. Current logic probably hashes a= nd then feeds the hash in.

2. Client CertificateVe= rify in TLS 1.2 messed up. We sign the full handshake transcript, so there&= #39;s interactions with the PRF. I've seen implementations which requir= e signing hash match the PRF hash, sometimes with a backup SHA-1 hash (NSS)= , at the cost of hash negotiation being a mess. I've also seen implemen= tations which decouple them, at the cost of maintaining the raw handshake b= uffer (OpenSSL, BoringSSL). Backporting forces the second choice.

Notably, if backporting EdDSA, there is no rolling hash one= can maintain for CertificateVerify anyway. EdDSA is inherently message-bas= ed, which motivated the 1.3 change. (That and simpler interfaces.)

I should add: 1.3 CertificateVeri= fy does not have this problem. One signs, e.g.:

RS= A-PSS-SHA384(padding || context || Hash(HS Context) || Hash(resumption_cont= ext))

The HS Context can be maintained as a rollin= g hash of the PRF hash. The signature scheme internally may use a different= pre-hash or no pre-hash at all and the handshake logic doesn't care.

There is a middle ground: we backport RSA-PSS (then= we should assign it in the 1.2 style and allocate corresponding 1.3-style = numbers) and not EdDSA. I intentionally did not do this. I did not want, ma= ny years down the line when EdDSA certificates actually exist, for implemen= tations to discover the message-based scheme is trouble. I wanted RSA-PSS t= o be done in 1.3 style so any questions about the new scheme would be resol= ved early.

(We've implemented the message-base= d scheme and it seems to be just fine. If you're willing to pay the cos= t of the backport to all versions, it actually ends up quite tidy.)

David=C2=A0

[*] SSL 3.0 ServerKe= yExchange is compatible with 1.3's API, but SSL 3.0 CertificateVerify s= igns some complex construction rather than simply a hash.
=
--001a11440f1c2afffa053773f315-- From nobody Tue Jul 12 10:56:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3983312D59F for ; Tue, 12 Jul 2016 10:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQxbhWSyXH1d for ; Tue, 12 Jul 2016 10:56:19 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3517312D5B0 for ; Tue, 12 Jul 2016 10:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nkcb7dIZ7E9OvcV4HrgORgYvIFH4ammodee0+wHPPfM=; b=NYcm4sjv3egc9uZWoP8DdOC+aTfVO9yDHib518wMVLrgBcL3Jtp0jdDPhcvYlLQBNMTn1b/2+1NnDnuuHgTKDXERvSSMbx5K6oavPQa6VYqwA2aK/8j5aGhNQiDEXrUiYZnlYqWbR4JtMw0DrCjlO0kbEY5XWRxPHQ4jijwgrrA= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0170.namprd09.prod.outlook.com (10.255.192.148) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:56:17 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:56:17 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYCAAEqKAP//wbAA Date: Tue, 12 Jul 2016 17:56:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: e946f395-7610-4a51-1db7-08d3aa7dd2e6 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0170; 6:3eft2b9rGbBCb2Yn7L5vJOG+Cp2AvUqKhZGUbsqui4TV5RI7AWAlaxohKTEu33q6hxP5mu27sVVaPw0Ip+yVOj72x+LG81ztzVPyx6ga9nPnbT8/2BdspBx8rIOQiZlvN7HGCdvamT+F2U33OCL+Xg9zW9bWWp3CG9iixZ0+OWib8AlwMbXt8jPqRIzgsIDfrWllYm7Kbg6uPkRn/vp6cm6RwAJmJPQX/bR0nJvs3FYHIpMmByUBAOtkJitDdmj2YnzE9o/eNA+MGiAwbxeu6U85Po9fSyVx9GAy0+MKSzG3WBVS7K3VGw3JKyuvfcdxCd3h1VDpbHSUreT+wQxCFw==; 5:CxRK/2eBxXA8G3YJcgI9g0nX/NAAqmGwNDgUubI7TkP89zcWnxMsSuFK9RQH6bqav6TGdZpr2yjjvJKIqDu15NN3tEavkPDDalR9GuDKi47cxlDyrYfmB1PlWGnlQL3PHQ1omj4OtGQ7iuIEFyqKdA==; 24:1ntsgrteFhLUj7rBsqrwSuvrCVKWxDpswu3PqO2xi9369/pZDj607tyeFMtOuAqkcuRbi0tv/5SmDKWGybdH+jjYHB0t7otXKtSpMR1uR0c=; 7:hhX8BHSnFHAgAoMHziYaZwqHTJ7yWx3WY+MJNbJcGW3ysYZ89tLdSk6D7Nd3kwt5K0EflTHk2absgBni1cHY+PFzyGLsq9ro5oExTFds3l+ZU8y1sbGsGshRShMPh5JO0S2DNlc7WcNNadwNEBSlxWm2OVn6YzUPfpMlVdxR0koqtljYYyyWlWJs6i4hUAVD3rJtEiiZwexj6aW/R7d/Z+jkOeW7chhHHh2Una4fZJL+L1UV9TiJPXnbn3ihgO7h x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0170; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0170; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0170; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(3660700001)(19580395003)(54356999)(19580405001)(7846002)(7736002)(93886004)(2501003)(2906002)(305945005)(50986999)(106356001)(106116001)(76176999)(586003)(81156014)(81166006)(3280700002)(2900100001)(83506001)(2950100001)(101416001)(8666005)(36756003)(11100500001)(5001770100001)(92566002)(8676002)(122556002)(4001350100001)(3846002)(6116002)(102836003)(97736004)(68736007)(5002640100001)(107886002)(66066001)(189998001)(230783001)(10400500002)(87936001)(77096005)(99286002)(8936002)(86362001)(105586002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0170; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:56:17.1541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0170 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:56:21 -0000 Hi Kenny,=20 On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote: >Hi > >On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote: > >>Hi Kenny,=20 >> >>On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote: >> >>>Hi >>> >>>On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote: >>> >>>>Hi Kenny, >>>> >>>>I support the strongest indistinguishability notion mentioned in (*) >>>>above, but in my opinion we should provide good description to the >>>>users. >>> >>>OK, I think now we are at the heart of your argument. You support our >>>choice of security definition and method of analysis after all. >>> >>>And we can agree that good descriptions can only help. >>> >>>>That is why I support the limit around 2^38 records. >>> >>>I don't see how changing 2^24.5 (which is in the current draft) to 2^38 >>>provides a better description to users. >>> >>>Are you worried they won't know what a decimal in the exponent means? >>> >>>Or, more seriously, are you saying that 2^{-32} for single key attacks >>>is >>>a big enough security margin? If so, can you say what that's based on? >> >>It would not make sense to ask people to rekey unnecessarily. 1 in 2^32 >>is >>1 in 4,294,967,296 for the indistinguishability attack. > >I would agree that it does not make sense to ask TLS peers to rekey >unnecessarily. I also agree that 1 in 2^32 is >1 in 4,294,967,296. Sure looks like a big, scary number, don't it? > >Are you then arguing that 2^{-32} for single key attacks is a big enough >security margin because we want to avoid rekeying? Because it is safe therefore there are no needs to rekey. I don=B9t recommend to run another function/protocol when there are no needs for it. I don=B9t see any particular reasons for mentioning single key in the indistinguishability attack here. >Then do you have a >specific concern about the security of rekeying? I could see various ways >in which it might go wrong if not designed carefully. > >Or are you directly linking a fundamental security question to an >operational one, by which I mean: are you saying we should trade security >for avoiding the "cost" of rekeying for some notion of "cost"? If so, can >you quantify the cost for the use cases that matter to you? > >Cheers, > >Kenny=20 Regards, Quynh.=20 > From nobody Tue Jul 12 10:57:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7DB12D59F for ; Tue, 12 Jul 2016 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRCuvY27FsvY for ; Tue, 12 Jul 2016 10:57:07 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0127.outbound.protection.outlook.com [23.103.200.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D51312D5C6 for ; Tue, 12 Jul 2016 10:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LNIp4QL8AGXveTTQKoF4t1nOerzTjdTdEATTH1ezizY=; b=BwOvC7SQqnXxo732GUQrJ7YpjYJx/l36KeaB0Ia5+QoifmQt1vVhgFCjNx8lg/Ha4hVCL9A+JKYmIhrYBIMmc3Ri/+XtYXqTehTVJxrkxrywIH7NMp8565Wq9HlT1iN8JMQmNfji9Z+5+ZecKBifp/P61Q2eBcbs1z2cTw0yzyE= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0170.namprd09.prod.outlook.com (10.255.192.148) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:57:04 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:57:03 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Scott Fluhrer (sfluhrer)" , "Dang, Quynh (Fed)" , "Eric Rescorla" , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAATFUAgAANRgD//9RqAA== Date: Tue, 12 Jul 2016 17:57:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 29646bf8-ab25-4695-5c4c-08d3aa7dee73 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0170; 6:UVkWlkrO5tQaWv3GlS9vxXoP5o0XotvLzjk71tgw/QhDLSz5xGw1b+bls6ilammlrghHAVVAY7HtYPNu5gwikOYuQqenrHGKD4wIE0O6/AGf4FgHN5jMwtDMEO+6hnTd3l9izZr04uBhN4/rdawdERbyRRom+/WtjPAHxtXMkyCPxP99gjrhCgrmC6ukiJCefgBlhp3XIXsj7K5/JFYSFE40WTlXRsKKbUDz5yHxGihiC8YSqEGs6OodwMiv5fOPhJwn0hVqzybTKt3n8g6ThNMqYrk6yisQKrUz38X63sVdPQ0FXANNXdSqFGs2NXLWevoCEjRvIbyVn/SvaGC1Dw==; 5:dnqpoUnlytSDpqbQsZhSSZOQGwXJb74jbKp2KkcvRE4iEZQXMfHQeipzNouv/wb5cfFUADw2Pgt6j/03Tj1QepzK56cCWJut1DaF/2/FnxT5dpE4MVXPfiXYFFRnfxvHRvDhgmydpkhlcclPzQwWNA==; 24:5qPtJZ4QwvWkAWs59cVLA3Aqbu00VaffFkWed7AiVk/2T33odvtk+v5cz/nNNgFeLO5wIJpHnEBm2SrTuXOSJsD7yQKVOXoJx4cjAq0d1gg=; 7:4tTkE80JOvcekuMmbExnBEZ1j+IeJ0RSARpd4KQo5eN5FGtR4qbcU9KL/S6NXwi2NQgKk2dUbYolWL+gxgOxlu/7ENkk6zFPR62K1gkQFT9SXuxEZ4SYQUy/VGicAxhKmhAmuRvs9eQ4UEQuq4CfuIm5GXe9zcwiDGjrOh0zfKdRF5x4P5YYbZfGW1dk6v9ZYd+OTu9R/SycgbrttlncHxa3GwcpEuvjNuX6vWYC4omu5MdbNpFEeznvsb17+goa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0170; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0170; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0170; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(377454003)(199003)(55674003)(189002)(3660700001)(19580395003)(54356999)(19580405001)(7846002)(7736002)(93886004)(2501003)(2906002)(305945005)(50986999)(106356001)(106116001)(76176999)(586003)(81156014)(81166006)(3280700002)(2900100001)(83506001)(2950100001)(101416001)(8666005)(36756003)(5001770100001)(92566002)(8676002)(122556002)(4001350100001)(3846002)(6116002)(102836003)(97736004)(68736007)(5002640100001)(107886002)(66066001)(189998001)(230783001)(15975445007)(10400500002)(87936001)(77096005)(99286002)(8936002)(86362001)(105586002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0170; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: <37BEB1C71D26DB4BB337C8B04910F765@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:57:03.5722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0170 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:57:10 -0000 SGkgS2VubnksIA0KDQpPbiA3LzEyLzE2LCAxMjozMyBQTSwgIlBhdGVyc29uLCBLZW5ueSIgPEtl bm55LlBhdGVyc29uQHJodWwuYWMudWs+IHdyb3RlOg0KDQo+VW5mb3J0dW5hdGVseSwgdGhhdCdz IG5vdCBxdWl0ZSB0aGUgcmlnaHQgaW50ZXJwcmV0YXRpb24uIFRoZSBib3VuZHMgb25lDQo+b2J0 YWlucyBkZXBlbmQgb24gYm90aCB0aGUgdG90YWwgYW1vdW50IG9mIGRhdGEgZW5jcnlwdGVkIEFO RCB0aGUgbnVtYmVyDQo+b2YgZW5jcnlwdGlvbiBxdWVyaWVzIHRoZSBhZHZlcnNhcnkgaXMgYWxs b3dlZCB0byBtYWtlIHRvIEFFUy1HQ00gdW5kZXINCj50aGUgKHNpbmdsZSkgdGFyZ2V0IGtleS4N Cg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSB0b3RhbCBpcyB0aGUgZGF0YSBjb21wbGV4 aXR5IGxpbWl0IChjb3VudGluZw0KYmxvY2sgZW5jcnlwdGlvbnMgYW5kIHF1ZXJpZXMgd2hpY2gg YXJlIGFsc28gYmxvY2sgZW5jcnlwdGlvbnMpLiBUbyBiZQ0KbW9yZSBwcmVjaXNlLCB0aGVuIHdl IHNob3VsZCBjb3VudCBkYXRhIGNvbXBsZXhpdHkgYnkgbnVtYmVyIG9mIGJsb2NrDQplbmNyeXB0 aW9ucyAoZW5jcnlwdGluZyAxIGJpdCBpcyAxIGJsb2NrIGVuY3J5cHRpb24pLiBCdXQgZm9yIGxh cmdlIGRhdGENCmluIFRMUywgZW5jcnlwdGlvbiBpcyBwcmV0dHkgbXVjaCB3aXRoIGZ1bGwgYmxv Y2tzIG9mIHBsYWludGV4dHMuDQoNCklmIHRoZSBhdHRhY2tlciBoYXMgMl4xMCBlbmNyeXB0ZWQg YmxvY2tzIGFuZCAgaXMgYWxsb3dlZCB0byBxdWVyeSBhbm90aGVyDQoyXjEwIGVuY3J5cHRpb25z LCB0aGVuIHRoZSB0b3RhbCBkYXRhIGlzIDJeMjAgYmVjYXVzZSB0aGUgdG90YWwgb2YgMl4yMA0K YmxvY2sgZW5jcnlwdGlvbnMgaGFwcGVucy4gSW4gVExTLCBpdCBtZWFucyB0aGF0IDJeMjAgQUVT IGJsb2NrDQplbmNyeXB0aW9ucyBoYXBwZW4uDQoNCj5XZSBhc3N1bWVkIGVhY2ggcmVjb3JkIHdh cyAyXjE0IGJ5dGVzIGluIHNpemUgdG8gc2ltcGxpZnkgdGhlIGVuc3VpbmcNCj5hbmFseXNpcywg YW5kIHRvIGVuYWJsZSB1cyB0byBmb2N1cyBvbiBob3cgdGhlIHNlY3VyaXR5IGJvdW5kcyB0aGVu IGRlcGVuZA0KPm9uIHRoZSBudW1iZXIgb2YgcmVjb3JkcyBlbmNyeXB0ZWQuIFNlZSBlcXVhdGlv biAoNSkgYW5kIFRhYmxlIDIgaW4gdGhlDQo+bm90ZSBhdCANCj4NCj4JaHR0cDovL3d3dy5pc2cu cmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZi4NCj4NCj5JbiBzaG9ydCwgdGhlIHNlY3Vy aXR5IGJvdW5kIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhvbGQgZm9yIEFOWSAyXjUyDQo+ZW5jcnlw dGVkIGRhdGEgYnl0ZXMuIEZvciBleGFtcGxlLCBpZiB0aGUgYXR0YWNrZXIgZW5jcnlwdGVkIDJe NTIgcmVjb3Jkcw0KPm9mIHNpemUgMSAoISkgdGhlbiBlcXVhdGlvbiAoNSkgd291bGQgdGVsbCB1 cyBhbG1vc3Qgbm90aGluZyB1c2VmdWwgYXQgYWxsDQo+YWJvdXQgc2VjdXJpdHkuDQo+DQo+Rmlu YWxseSwgeW91IHdyaXRlICJ0byBjb21lIHRvIHRoZSAyXjM4IHJlY29yZCBsaW1pdCwgdGhleSBh c3N1bWUgdGhhdA0KPmVhY2ggcmVjb3JkIGlzIHRoZSBtYXhpbXVtIDJeMTQgYnl0ZXMiLiBGb3Ig Y2xhcml0eSwgd2UgZGlkIG5vdCByZWNvbW1lbmQNCj5hIGxpbWl0IG9mIDJeMzggcmVjb3Jkcy4g VGhhdCdzIFF1eW5oJ3MgcHJlZmVycmVkIG51bWJlciwgYW5kIGlzDQo+dW5zdXBwb3J0ZWQgYnkg b3VyIGFuYWx5c2lzLg0KPg0KPkNoZWVycywNCj4NCj5LZW5ueQ0KDQpSZWdhcmRzLA0KUXV5bmgu IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCj4gDQo+DQo+DQo+T24gMTIvMDcvMjAxNiAx Njo0NSwgIlNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSIgPHNmbHVocmVyQGNpc2NvLmNvbT4NCj53 cm90ZToNCj4NCj4+QWN0dWFsbHksIGEgbW9yZSBjb3JyZWN0IHdheSBvZiB2aWV3aW5nIHRoZSBs aW1pdCB3b3VsZCBiZSAyXjUyIGVuY3J5cHRlZA0KPj5kYXRhIGJ5dGVzLiBUbyBjb21lIHRvIHRo ZSAyXjM4IHJlY29yZCBsaW1pdCwgdGhleSBhc3N1bWUgdGhhdCBlYWNoDQo+PnJlY29yZCBpcyB0 aGUgbWF4aW11bSAyXjE0IGJ5dGVzLiAgT2YgY291cnNlLCBhdCBhIDFHYnBzIHJhdGUsIGl0J2Qg dGFrZQ0KPj5vdmVyIGEgeWVhciB0byBlbmNyeXB0IHRoYXQgbXVjaCBkYXRhLi4uDQo+Pg0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogVExTIFttYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5nLCBRdXluaCAoRmVkKQ0KPj4+IFNlbnQ6 IFR1ZXNkYXksIEp1bHkgMTIsIDIwMTYgMTE6MTIgQU0NCj4+PiBUbzogUGF0ZXJzb24sIEtlbm55 OyBEYW5nLCBRdXluaCAoRmVkKTsgRXJpYyBSZXNjb3JsYTsgdGxzQGlldGYub3JnDQo+Pj4gU3Vi amVjdDogUmU6IFtUTFNdIE5ldyBkcmFmdDogZHJhZnQtaWV0Zi10bHMtdGxzMTMtMTQudHh0DQo+ Pj4gDQo+Pj4gSGkgS2VubnksDQo+Pj4gDQo+Pj4gVGhlIGluZGlzdGluZ3Vpc2hhYmlsaXR5LWJh c2VkIHNlY3VyaXR5IG5vdGlvbiBpbiB0aGUgcGFwZXIgaXMgYQ0KPj4+c3Ryb25nZXINCj4+PiBz ZWN1cml0eSBub3Rpb24gdGhhbiB0aGUgKG9sZCkgdHJhZGl0aW9uYWwgY29uZmlkZW50aWFsaXR5 IG5vdGlvbi4NCj4+PiANCj4+PiANCj4+PiAoKikgSW5kaXN0aW5ndWlzaGFiaWxpdHkgbm90aW9u IChmcmFtZXdvcmspIGd1YXJhbnRlZXMgbm8gb3RoZXIgYXR0YWNrcw0KPj4+Y2FuDQo+Pj4gYmUg YmV0dGVyIHRoYW4gdGhlIGluZGlzdGluZ3Vpc2hhYmlsaXR5IGJvdW5kLiBJbnR1aXRpdmVseSwg eW91IGNhbqn2dA0KPj4+YXR0YWNrIGlmDQo+Pj4geW91IGNhbqn2dCBldmVuIHRlbGwgdHdvIHRo aW5ncyBhcmUgZGlmZmVyZW50IG9yIG5vdC4gU28sIGJlaW5nIGFibGUgdG8NCj4+PnNheSB0d28N Cj4+PiB0aGluZ3MgYXJlIGRpZmZlcmVudCBvciBub3QgaXMgdGhlIG1pbmltYWwgY29uZGl0aW9u IHRvIGxlYWQgdG8gYW55DQo+Pj5hdHRhY2suDQo+Pj4gDQo+Pj4gVGhlIHRyYWRpdGlvbmFsIGNv bmZpZGVudGlhbGl0eSBkZWZpbml0aW9uIGlzIHRoYXQga25vd2luZyBvbmx5IHRoZQ0KPj4+Y2lw aGVydGV4dHMsDQo+Pj4gdGhlIGF0dGFja2VyIGNhbqn2dCBrbm93IGFueSBjb250ZW50IG9mIHRo ZSBjb3JyZXNwb25kaW5nIHBsYWludGV4dHMNCj4+PndpdGggYQ0KPj4+IGdyZWF0ZXIgcHJvYmFi aWxpdHkgdGhhbiBzb21lIHZhbHVlIGFuZCB0aGlzIHZhbHVlIGRlcGVuZHMgb24gdGhlDQo+Pj5w YXJ0aWN1bGFyDQo+Pj4gY2lwaGVyLiBPZiBjb3Vyc2UsIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBk YXRhIG11c3Qgbm90IGJlIG1vcmUgdGhhbg0KPj4+IHNvbWUgbGltaXQgdW5kZXIgYSBnaXZlbiBr ZXkgd2hpY2ggYWxzbyBkZXBlbmRzIG9uIHRoZSBjaXBoZXIuDQo+Pj4gDQo+Pj4gRm9yIGV4YW1w bGUsIHdpdGggY291bnRlciBtb2RlIEFFU18xMjgsIExldKn2cyBzYXkgZW5jcnlwdGluZyAyXjcw IGlucHV0DQo+Pj4gYmxvY2tzIHdpdGggYSBzaW5nbGUga2V5LiBXaXRoIHRoZSAyXjcwIGNpcGhl cnRleHQgYmxvY2tzIGFsb25lIChlYWNoDQo+Pj5ibG9jayBpcw0KPj4+IDEyOCBiaXRzKSwgSSBk b26p9nQgdGhpbmsgb25lIGNhbiBmaW5kIG91dCBhbnkgY29udGVudCBvZiBhbnkgb2YgdGhlDQo+ Pj5wbGFpbnRleHRzLg0KPj4+IFRoZSBjaGFuY2UgZm9yIGtub3dpbmcgYW55IGJsb2NrIG9mIHRo ZSBwbGFpbnRleHRzIGlzDQo+Pj4gMS8oMl4xMjgpIGluIHRoaXMgY2FzZS4NCj4+PiANCj4+PiBJ IHN1cHBvcnQgdGhlIHN0cm9uZ2VzdCBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBub3Rpb24gbWVudGlv bmVkIGluICgqKQ0KPj4+YWJvdmUsDQo+Pj4gYnV0IGluIG15IG9waW5pb24gd2Ugc2hvdWxkIHBy b3ZpZGUgZ29vZCBkZXNjcmlwdGlvbiB0byB0aGUgdXNlcnMuDQo+Pj4gVGhhdCBpcyB3aHkgSSBz dXBwb3J0IHRoZSBsaW1pdCBhcm91bmQgMl4zOCByZWNvcmRzLg0KPj4+IA0KPj4+IFJlZ2FyZHMs DQo+Pj4gUXV5bmguDQo+Pj4gDQo+Pj4gT24gNy8xMi8xNiwgMTA6MDMgQU0sICJQYXRlcnNvbiwg S2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPg0KPj4+IHdyb3RlOg0KPj4+IA0KPj4+ ID5IaSBRdXluaCwNCj4+PiA+DQo+Pj4gPlRoaXMgaW5kaXN0aW5ndWlzaGFiaWxpdHktYmFzZWQg c2VjdXJpdHkgbm90aW9uIGlzIHRoZSBjb25maWRlbnRpYWxpdHkNCj4+PiA+bm90aW9uIHRoYXQg aXMgYnkgbm93IGdlbmVyYWxseSBhY2NlcHRlZCBpbiB0aGUgY3J5cHRvIGNvbW11bml0eS4NCj4+ PiA+TWVldGluZyBpdCBpcyBzdWZmaWNpZW50IHRvIGd1YXJhbnRlZSBzZWN1cml0eSBhZ2FpbnN0 IG1hbnkgb3RoZXINCj4+PmZvcm1zDQo+Pj4gPm9mIGF0dGFjayBvbiBjb25maWRlbnRpYWxpdHks IHdoaWNoIGlzIG9uZSBvZiB0aGUgbWFpbiByZWFzb25zIHdlIHVzZQ0KPj4+aXQuDQo+Pj4gPg0K Pj4+ID5Zb3Ugc2F5IHRoYXQgYW4gYXR0YWNrIGluIHRoZSBzZW5zZSBpbXBsaWVkIGJ5IGJyZWFr aW5nIHRoaXMgbm90aW9uDQo+Pj4gPmRvZXMgbm90IGJyZWFrIGNvbmZpZGVudGlhbGl0eS4gQ2Fu IHlvdSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkNCj4+PiA+ImNvbmZpZGVudGlhbGl0eSIsIGlu IGEgcHJlY2lzZSB3YXk/IEkgY2FuIHRoZW4gdHJ5IHRvIHRlbGwgeW91DQo+Pj53aGV0aGVyDQo+ Pj4gPnRoaXMgbm90aW9uIHdpbGwgaW1wbHkgeW91cnMuDQo+Pj4gPg0KPj4+ID5SZWdhcmRzDQo+ Pj4gPg0KPj4+ID5LZW5ueQ0KPj4+ID4NCj4+PiA+T24gMTIvMDcvMjAxNiAxNDowNCwgIlRMUyBv biBiZWhhbGYgb2YgRGFuZywgUXV5bmggKEZlZCkiDQo+Pj4gPjx0bHMtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgcXV5bmguZGFuZ0BuaXN0Lmdvdj4gd3JvdGU6DQo+Pj4gPg0KPj4+ID4+ SGkgRXJpYyBhbmQgYWxsLA0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PkluIG15IG9waW5pb24sIHdl IHNob3VsZCBnaXZlIGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCBkYXRhIGxpbWl0IGZvcg0KPj4+ ID4+QUVTX0dDTSBpbiBUTFMgMS4zIGluc3RlYWQgb2Ygd2hhdCBpcyBjdXJyZW50IGluIHRoZSBk cmFmdCAxNC4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj5JbiB0aGlzIHBhcGVyOiBodHRwOi8vd3d3 LmlzZy5yaHVsLmFjLnVrL35rcC9UTFMtQUVib3VuZHMucGRmLCAgd2hhdA0KPj4+ID4+aXMgY2Fs bGVkIGNvbmZpZGVudGlhbGl0eSBhdHRhY2sgaXMgdGhlIGtub3duIHBsYWludGV4dA0KPj4+ID4+ ZGlmZmVyZW50aWFsaXR5IGF0dGFjayB3aGVyZSAgdGhlIGF0dGFja2VyIGhhcy9jaG9vc2VzIHR3 bw0KPj4+cGxhaW50ZXh0cywNCj4+PiA+PnNlbmQgdGhlbSB0byB0aGUgQUVTLWVuY3J5cHRpb24g b3JhY2xlLiAgVGhlIG9yYWNsZSBlbmNyeXB0cyBvbmUgb2YNCj4+PiA+PnRoZW0sIHRoZW4gc2Vu ZHMgdGhlIGNpcGhlcnRleHQgdG8gdGhlIGF0dGFja2VyLiAgQWZ0ZXIgc2VlaW5nIHRoZQ0KPj4+ ID4+Y2lwaGVydGV4dCwgdGhlIGF0dGFja2VyIGhhcyBzb21lIHN1Y2Nlc3MgcHJvYmFiaWxpdHkg b2YgdGVsbGluZw0KPj4+d2hpY2gNCj4+PiA+PnBsYWludGV4dCAgd2FzIGVuY3J5cHRlZCBhbmQg dGhpcyBzdWNjZXNzIHByb2JhYmlsaXR5IGlzIGluIHRoZQ0KPj4+Y29sdW1uDQo+Pj4gPj5jYWxs ZWQgqfhBdHRhY2sgU3VjY2VzcyBQcm9iYWJpbGl0ean3IGluIFRhYmxlIDEuICBUaGlzIGF0dGFj ayBkb2VzIG5vdA0KPj4+ID4+YnJlYWsgY29uZmlkZW50aWFsaXR5Lg0KPj4+ID4+DQo+Pj4gPj4N Cj4+PiA+PklmIHRoZSBhdHRhY2sgYWJvdmUgYnJlYWtzIG9uZSBvZiBzZWN1cml0eSBnb2FsKHMp IG9mIHlvdXIgaW5kaXZpZHVhbA0KPj4+ID4+c3lzdGVtLCB0aGVuIG1ha2luZyBzdWNjZXNzIHBy b2JhYmlsaXR5IG9mIHRoYXQgYXR0YWNrIGF0IDJeKC0zMikgbWF4DQo+Pj4gPj5pcyBlbm91Z2gu IEluIHRoYXQgY2FzZSwgdGhlIE1heCBudW1iZXIgb2YgcmVjb3JkcyBpcyBhcm91bmQgMl4zOC4N Cj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+UmVnYXJkcywNCj4+PiA+PlF1 eW5oLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ ID4+RGF0ZTogTW9uZGF5LCBKdWx5IDExLCAyMDE2IGF0IDM6MDggUE0NCj4+PiA+PlRvOiAidGxz QGlldGYub3JnIiA8dGxzQGlldGYub3JnPg0KPj4+ID4+U3ViamVjdDogW1RMU10gTmV3IGRyYWZ0 OiBkcmFmdC1pZXRmLXRscy10bHMxMy0xNC50eHQNCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+ PiA+PkZvbGtzLA0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PkkndmUganVzdCBzdWJtaXR0ZWQgZHJh ZnQtaWV0Zi10bHMtdGxzMTMtMTQudHh0IGFuZCBpdCBzaG91bGQgc2hvdyB1cA0KPj4+ID4+b24g dGhlIGRyYWZ0IHJlcG9zaXRvcnkgc2hvcnRseS4gSW4gdGhlIG1lYW50aW1lIHlvdSBjYW4gZmlu ZCB0aGUNCj4+PiA+PmVkaXRvcidzIGNvcHkgaW4gdGhlIHVzdWFsIGxvY2F0aW9uIGF0Og0KPj4+ ID4+DQo+Pj4gPj4NCj4+PiA+PiAgaHR0cDovL3Rsc3dnLmdpdGh1Yi5pby90bHMxMy1zcGVjLw0K Pj4+ID4+DQo+Pj4gPj4NCj4+PiA+PlRoZSBtYWpvciBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQg YXJlOg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQSBiaWcgcmVzdHJ1Y3R1cmUgdG8gbWFrZSBp dCByZWFkIGJldHRlci4gSSBtb3ZlZCB0aGUgT3ZlcnZpZXcNCj4+PiA+PiAgdG8gdGhlIGJlZ2lu bmluZyBhbmQgdGhlbiBwdXQgdGhlIGRvY3VtZW50IGluIGEgbW9yZSBsb2dpY2FsDQo+Pj4gPj4g IG9yZGVyIHN0YXJ0aW5nIHdpdGggdGhlIGhhbmRzaGFrZSBhbmQgdGhlbiB0aGUgcmVjb3JkIGFu ZA0KPj4+ID4+ICBhbGVydHMuDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBUb3RhbGx5IHJld3Jv dGUgdGhlIHNlY3Rpb24gd2hpY2ggdXNlZCB0byBiZSBjYWxsZWQgIlNlY3VyaXR5DQo+Pj4gPj4g IEFuYWx5c2lzIiBhbmQgaXMgbm93IGNhbGxlZCAiT3ZlcnZpZXcgb2YgU2VjdXJpdHkgUHJvcGVy dGllcyIuDQo+Pj4gPj4gIFRoaXMgc2VjdGlvbiBpcyBzdGlsbCBraW5kIG9mIGEgaGFyZCBoYXQg YXJlYSwgc28gUFJzIHdlbGNvbWUuDQo+Pj4gPj4gIEluIHBhcnRpY3VsYXIsIEkga25vdyBJIG5l ZWQgdG8gYmVlZiB1cCB0aGUgY2l0YXRpb25zIGZvciB0aGUNCj4+PiA+PiAgcmVjb3JkIGxheWVy IHNlY3Rpb24uDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBSZW1vdmVkIHRoZSAwLVJUVCBFbmNy eXB0ZWRFeHRlbnNpb25zIGFuZCBtb3ZlZCB0aWNrZXRfYWdlDQo+Pj4gPj4gIGludG8gdGhlIENs aWVudEhlbGxvLiBUaGlzIHF1YXNpLXJldmVydHMgYSBjaGFuZ2UgaW4gLTEzIHRoYXQNCj4+PiA+ PiAgbWFkZSBpbXBsZW1lbnRhdGlvbiBvZiAwLVJUVCBraW5kIG9mIGEgcGFpbi4NCj4+PiA+Pg0K Pj4+ID4+DQo+Pj4gPj5BcyB1c3VhbCwgY29tbWVudHMgd2VsY29tZS4NCj4+PiA+Pi1Fa3INCj4+ PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQWxs b3cgY29va2llcyB0byBiZSBsb25nZXIgKCopDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBSZW1v dmUgdGhlICJjb250ZXh0IiBmcm9tIEVhcmx5RGF0YUluZGljYXRpb24gYXMgaXQgd2FzIHVuZGVm aW5lZA0KPj4+ID4+ICBhbmQgbm9ib2R5IHVzZWQgaXQgKCopDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ ID4+KiBSZW1vdmUgMC1SVFQgRW5jcnlwdGVkRXh0ZW5zaW9ucyBhbmQgcmVwbGFjZSB0aGUgdGlj a2V0X2FnZQ0KPj4+ID4+ZXh0ZW5zaW9uDQo+Pj4gPj4gIHdpdGggYW4gb2JmdXNjYXRlZCB2ZXJz aW9uLiBBbHNvIG5lY2Vzc2l0YXRlcyBhIGNoYW5nZSB0bw0KPj4+ID4+ICBOZXdTZXNzaW9uVGlj a2V0ICgqKS4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4qIE1vdmUgdGhlIGRvd25ncmFkZSBzZW50 aW5lbCB0byB0aGUgZW5kIG9mIFNlcnZlckhlbGxvLlJhbmRvbQ0KPj4+ID4+ICB0byBhY2NvbW9k YXRlIHRsc2RhdGUgKCopLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogRGVmaW5lIGVjZHNhX3No YTEgKCopLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQWxsb3cgcmVzdW1wdGlvbiBldmVuIGFm dGVyIGZhdGFsIGFsZXJ0cy4gVGhpcyBtYXRjaGVzIGN1cnJlbnQNCj4+PiA+PiAgcHJhY3RpY2Uu DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBSZW1vdmUgbm9uLWNsb3N1cmUgd2FybmluZyBhbGVy dHMuIFJlcXVpcmUgdHJlYXRpbmcgdW5rbm93biBhbGVydHMNCj4+PiA+PmFzDQo+Pj4gPj4gIGZh dGFsLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogTWFrZSB0aGUgcnVsZXMgZm9yIGFjY2VwdGlu ZyAwLVJUVCBsZXNzIHJlc3RyaWN0aXZlLg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiogQ2xhcmlm eSAwLVJUVCBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IHJ1bGVzLg0KPj4+ID4+DQo+Pj4gPj4NCj4+ PiA+PiogQ2xhcmlmeSBob3cgMC1SVFQgYW5kIFBTSyBpZGVudGl0aWVzIGludGVyYWN0Lg0KPj4+ ID4+DQo+Pj4gPj4NCj4+PiA+PiogQWRkIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBkYXRhIGxp bWl0cyBmb3IgZWFjaCBjaXBoZXIuDQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+KiBNYWpvciBlZGl0 b3JpYWwgcmVzdHJ1Y3R1cmluZy4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4qIFJlcGxhY2UgdGhl IFNlY3VyaXR5IEFuYWx5c2lzIHNlY3Rpb24gd2l0aCBhIFdJUCBkcmFmdC4NCj4+PiA+Pg0KPj4+ ID4+DQo+Pj4gPj4oKikgaW5kaWNhdGVzIGNoYW5nZXMgdG8gdGhlIHdpcmUgcHJvdG9jb2wgd2hp Y2ggbWF5IHJlcXVpcmUNCj4+PiA+PmltcGxlbWVudGF0aW9ucw0KPj4+ID4+ICAgIHRvIHVwZGF0 ZS4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPg0KPj4+IA0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g VExTIG1haWxpbmcgbGlzdA0KPj4+IFRMU0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+DQoNCg== From nobody Tue Jul 12 11:06:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA6712D59F for ; Tue, 12 Jul 2016 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2WGaBNpdXiG for ; Tue, 12 Jul 2016 11:06:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4647512D0D8 for ; Tue, 12 Jul 2016 11:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3204; q=dns/txt; s=iport; t=1468346788; x=1469556388; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Zon9okD8SJ0gtViXjYbIYc0ikUAa099joVDDMratsg4=; b=fv5hDJf7bA/YjU4NsragXkm+zPQapQyEG4/vBpsiWeRnGMfXn3SrUqN9 OWczT9NilnhWB7s6nKQLzBGttC/mTCPTYOVF2/3Wjkjoc47JfuVItdyKJ gqIGRmgyfs8aFVkQFtCoOrrqJJ8iUjOPP9P7wprSvUj/oBZlqU1PBCfuw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgBbMYVX/4kNJK1cDoMwgVIGuQOBe?= =?us-ascii?q?YYYAhyBGTgUAQEBAQEBAWUnhFwBAQQBIxFRBAIBCBEEAQEBAgIjAwICAjAUAQg?= =?us-ascii?q?IAgQBEgiIIAixD48NAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmETYQdASoQI?= =?us-ascii?q?4JHgloFmRsBjkyPNYQ7i1gBHjaCBgMcgRE7bodhASUffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="295081913" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 18:06:27 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6CI6RrS025055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 18:06:27 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 14:06:26 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 14:06:26 -0400 From: "Scott Fluhrer (sfluhrer)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26epuiTmg3+eU0yJfAjoGH7+FKAVB4KAgAAQs4CAABMcgP//w17wgABTKwCAAAjnAIAAA3GA///H5gA= Date: Tue, 12 Jul 2016 18:06:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:06:29 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdGVyc29uLCBLZW5ueSBb bWFpbHRvOktlbm55LlBhdGVyc29uQHJodWwuYWMudWtdDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkg MTIsIDIwMTYgMToxNyBQTQ0KPiBUbzogRGFuZywgUXV5bmggKEZlZCk7IFNjb3R0IEZsdWhyZXIg KHNmbHVocmVyKTsgRXJpYyBSZXNjb3JsYTsgdGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb VExTXSBOZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdGxzLXRsczEzLTE0LnR4dA0KPiANCj4gSGkNCj4g DQo+IE9uIDEyLzA3LzIwMTYgMTg6MDQsICJEYW5nLCBRdXluaCAoRmVkKSIgPHF1eW5oLmRhbmdA bmlzdC5nb3Y+IHdyb3RlOg0KPiANCj4gPkhpIEtlbm55LA0KPiA+DQo+ID5PbiA3LzEyLzE2LCAx MjozMyBQTSwgIlBhdGVyc29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+DQo+ IHdyb3RlOg0KPiA+DQo+ID4+RmluYWxseSwgeW91IHdyaXRlICJ0byBjb21lIHRvIHRoZSAyXjM4 IHJlY29yZCBsaW1pdCwgdGhleSBhc3N1bWUgdGhhdA0KPiA+PmVhY2ggcmVjb3JkIGlzIHRoZSBt YXhpbXVtIDJeMTQgYnl0ZXMiLiBGb3IgY2xhcml0eSwgd2UgZGlkIG5vdA0KPiA+PnJlY29tbWVu ZCBhIGxpbWl0IG9mIDJeMzggcmVjb3Jkcy4gVGhhdCdzIFF1eW5oJ3MgcHJlZmVycmVkIG51bWJl ciwNCj4gPj5hbmQgaXMgdW5zdXBwb3J0ZWQgYnkgb3VyIGFuYWx5c2lzLg0KPiA+DQo+ID5XaGF0 IGlzIHByb2JsZW0gd2l0aCBteSBzdWdnZXN0aW9uIGV2ZW4gd2l0aCB0aGUgcmVjb3JkIHNpemUg YmVpbmcgdGhlDQo+ID5tYXhpbXVtIHZhbHVlPw0KPiANCj4gVGhlcmUgbWF5IGJlIG5vIHByb2Js ZW0gd2l0aCB5b3VyIHN1Z2dlc3Rpb24uIEkgd2FzIHNpbXBseSB0cnlpbmcgdG8gbWFrZSBpdA0K PiBjbGVhciB0aGF0IDJeMzggcmVjb3JkcyB3YXMgeW91ciBzdWdnZXN0aW9uIGZvciB0aGUgcmVj b3JkIGxpbWl0IGFuZCBub3Qgb3Vycy4NCj4gSW5kZWVkLCBpZiBvbmUgcmVhZHMgb3VyIG5vdGUg Y2FyZWZ1bGx5LCBvbmUgd2lsbCBmaW5kIHRoYXQgd2UgZG8gbm90IG1ha2UgYW55DQo+IHNwZWNp ZmljIHJlY29tbWVuZGF0aW9ucy4gV2UgY29uc2lkZXIgdGhlIGRlY2lzaW9uIHRvIGJlIG9uZSBm b3IgdGhlIFdHOw0KPiBvdXIgcHJlZmVycmVkIHJvbGUgaXMgdG8gc3VwcGx5IHRoZSBhbmFseXNp cyBhbmQgaGVscCBpbnRlcnByZXQgaXQgaWYgcGVvcGxlDQo+IHdhbnQgdGhhdC4gUGFydCBvZiB0 aGF0IGludm9sdmVzIGNvcnJlY3RpbmcgcG9zc2libGUgbWlzY29uY2VwdGlvbnMgYW5kDQo+IG1p c2ludGVycHJldGF0aW9ucyBiZWZvcmUgdGhleSBnZXQgb3V0IG9mIGhhbmQuDQo+IA0KPiBOb3cg Ml4zOCBkb2VzIGNvbWUgb3V0IG9mIG91ciBhbmFseXNpcyBpZiB5b3UgYXJlIHdpbGxpbmcgdG8g YWNjZXB0IHNpbmdsZSBrZXkNCj4gYXR0YWNrIHNlY3VyaXR5IChpbiB0aGUgaW5kaXN0aW5ndWlz aGFiaWxpdHkgc2Vuc2UpIG9mIDJeey0zMn0uIFNvIGluIHRoYXQgbGltaXRlZA0KPiBzZW5zZSwg Ml4zOCBpcyBzdXBwb3J0ZWQgYnkgb3VyIGFuYWx5c2lzLiBCdXQgaXQgaXMgbm90IG91ciByZWNv bW1lbmRhdGlvbi4NCj4gDQo+IEJ1dCwgc3BlYWtpbmcgbm93IGluIGEgcGVyc29uYWwgY2FwYWNp dHksIEkgY29uc2lkZXIgdGhhdCBzZWN1cml0eSBtYXJnaW4gdG8gYmUNCj4gdG9vIHNtYWxsIChp LmUuIEkgdGhpbmsgdGhhdCAyXnstMzJ9IGlzIHRvbyBiaWcgYSBzdWNjZXNzIHByb2JhYmlsaXR5 KS4NCg0KVG8gYmUgY2xlYXIsIHRoaXMgcHJvYmFiaWxpdHkgaXMgdGhhdCBhbiBhdHRhY2tlciB3 b3VsZCBiZSBhYmxlIHRvIHRha2UgYSBodWdlICg0KyBQZXRhYnl0ZSkgY2lwaGVydGV4dCwgYW5k IGEgY29tcGF0aWJseSBzaXplZCBwb3RlbnRpYWwgKGJ1dCBpbmNvcnJlY3QpIHBsYWludGV4dCwg YW5kIHdpdGggcHJvYmFiaWxpdHkgMl57LTMyfSwgYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhhdCB0 aGlzIHBsYWludGV4dCB3YXMgbm90IHRoZSBvbmUgdXNlZCBmb3IgdGhlIGNpcGhlcnRleHQgKGFu ZCB3aXRoIHByb2JhYmlsaXR5IDAuOTk5OTk5OTk5NzY3Li4uLCBrbm93IG5vdGhpbmcgYWJvdXQg d2hldGhlciBoaXMgZ3Vlc3NlZCBwbGFpbnRleHQgd2FzIGNvcnJlY3Qgb3Igbm90KS4NCg0KSSdt IGp1c3QgdHJ5aW5nIHRvIGdldCBwZW9wbGUgdG8gdW5kZXJzdGFuZCB3aGF0IHdlJ3JlIHRhbGtp bmcgYWJvdXQuICBUaGlzIGlzIG5vdCAid2l0aCBwcm9iYWJpbGl0eSAyXnstMzJ9LCBoZSBjYW4g cmVjb3ZlciB0aGUgcGxhaW50ZXh0Ig0KDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBLZW5ueQ0K DQo= From nobody Tue Jul 12 11:55:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95AA12D5C3 for ; Tue, 12 Jul 2016 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRLWFNGeuhTO for ; Tue, 12 Jul 2016 11:54:59 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40045.outbound.protection.outlook.com [40.107.4.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C8F12B04E for ; Tue, 12 Jul 2016 11:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=srIcwIXx8tq5l2H1U1yOCe4c46wJ1pFAJHzJOYSmEzI=; b=3ESNvAz/86Uaw+BUVoK+NRDQ7qsI3EWkp9jnTaMnz/SwK0x4DyTwgPXESLeSuXH23IoZgnl2aaIUpX91izTXKChbMTS5Ydmt+Zwq4I89K1rDmWdTjJOGbPm0mSM9n3OPz4qYrfSbwRWNYauByAAU7GD8Uv3wPGMrpSLWTajHtGI= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 18:54:54 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 18:54:54 +0000 From: "Paterson, Kenny" To: "Scott Fluhrer (sfluhrer)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAACUMAgAAetID///d5AIAAFNgA///8WwCAAA2LTA== Date: Tue, 12 Jul 2016 18:54:54 +0000 Message-ID: <9D7727FF-08B6-4836-9231-A4D44051D2AA@rhul.ac.uk> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.146.50.187] x-ms-office365-filtering-correlation-id: 607306b7-c202-4e24-7803-08d3aa860319 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:DljvgyGbus40B7pec+mUuRFgn1U5XmojmLDgZ2jr0QpYLWa+N7O5g3ZE0Q4yWiaW8Lhe+4HiW/OOjz8IXEwdwEtFKh+2O4Nckzw3XFAwVC0+KaAvIEZNYQs/Ya7Kn7uwqGqsI0juqhOiNOfSWTHv5LxROR5Wi7yAdp4ypgdLFwFF4K9AjMDjvjbOMdztyMDYikC0+VIUhKeM+obfbjnxIvp0/Vz8AtcupQd+UT8/peus2GnS5zE2eF7Wa3Eh7fQo2SqlS1SpNdBKw/VxvqGhQ6tfQjan2VhTnZMafqDhJjA=; 5:Uu2q4fURfrBXOpQbuSH/bp1idTdDqAFTNSfoSbdCb8cVEbesvRiSFlWrNrLScC9YlUOirRAMyWOR/8up66DW8h3fxA0JuKkyJKiB+oQvXqHH3mhFwBU6cE7LOv+DeoSakeOP4i31xLTJSAb0qWn2sw==; 24:/HiEi0JeRSbZdxhfvYxUdixLKLFvR342vH4pzLmVpRXKxVafPlGKTlHHSyC1qMBTndx34FvrT8nR+pPw7H0e4RvlecuhiJuOIwsNLWouCeE=; 7:HHGIUneJCrXJjCwx/P+rr/HzRjW7cJuRw6Pj6YQSpvWKxr+pc6z97gnQIzx0JWU26nSvXObG8Ndmh1yVanalbUWNdEHydBJklF8wl+pENSZWabiMC2tw26T0rXp5V/1CimlDfO7L/fbb9yw8JHfMsp5rhQvVRETRCVLs58TY1JTH2h15Hhm9I1J2lglizarO2i4hU2G3K+qcGA9Di4ouuGGEEcoD8Bcn7EU6G30R1Ew/Z5YmcAmoY3a5tsqafXoc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377454003)(51444003)(13464003)(24454002)(189002)(105586002)(87936001)(68196006)(4326007)(86362001)(3846002)(106116001)(230783001)(68736007)(6116002)(106356001)(102836003)(2906002)(83716003)(8676002)(5002640100001)(586003)(33656002)(189998001)(11100500001)(97736004)(3660700001)(3280700002)(110136002)(10400500002)(93886004)(8666005)(76176999)(50986999)(54356999)(7736002)(101416001)(305945005)(66066001)(2900100001)(36756003)(2950100001)(81166006)(81156014)(77096005)(92566002)(19580405001)(19580395003)(7846002)(82746002)(74482002)(8936002)(122556002)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 18:54:54.2861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:55:01 -0000 Yup, that's crypto, folks.=20 These are the kinds of numbers we should be worrying about for a protocol t= hat will be deployed for decades to billions of people and devices.=20 > On 12 Jul 2016, at 19:06, Scott Fluhrer (sfluhrer) w= rote: >=20 >=20 >> -----Original Message----- >> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >> Sent: Tuesday, July 12, 2016 1:17 PM >> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; tls@ietf= .org >> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>=20 >> Hi >>=20 >>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote: >>>=20 >>> Hi Kenny, >>>=20 >>>> On 7/12/16, 12:33 PM, "Paterson, Kenny" >>> wrote: >>>=20 >>>> Finally, you write "to come to the 2^38 record limit, they assume that >>>> each record is the maximum 2^14 bytes". For clarity, we did not >>>> recommend a limit of 2^38 records. That's Quynh's preferred number, >>>> and is unsupported by our analysis. >>>=20 >>> What is problem with my suggestion even with the record size being the >>> maximum value? >>=20 >> There may be no problem with your suggestion. I was simply trying to mak= e it >> clear that 2^38 records was your suggestion for the record limit and not= ours. >> Indeed, if one reads our note carefully, one will find that we do not ma= ke any >> specific recommendations. We consider the decision to be one for the WG; >> our preferred role is to supply the analysis and help interpret it if pe= ople >> want that. Part of that involves correcting possible misconceptions and >> misinterpretations before they get out of hand. >>=20 >> Now 2^38 does come out of our analysis if you are willing to accept sing= le key >> attack security (in the indistinguishability sense) of 2^{-32}. So in th= at limited >> sense, 2^38 is supported by our analysis. But it is not our recommendati= on. >>=20 >> But, speaking now in a personal capacity, I consider that security margi= n to be >> too small (i.e. I think that 2^{-32} is too big a success probability). >=20 > To be clear, this probability is that an attacker would be able to take a= huge (4+ Petabyte) ciphertext, and a compatibly sized potential (but incor= rect) plaintext, and with probability 2^{-32}, be able to determine that th= is plaintext was not the one used for the ciphertext (and with probability = 0.999999999767..., know nothing about whether his guessed plaintext was cor= rect or not). >=20 > I'm just trying to get people to understand what we're talking about. Th= is is not "with probability 2^{-32}, he can recover the plaintext" >=20 >=20 >>=20 >> Regards, >>=20 >> Kenny >=20 From nobody Tue Jul 12 12:03:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F912D5D8 for ; Tue, 12 Jul 2016 12:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N05B8jAiYcFC for ; Tue, 12 Jul 2016 12:03:14 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0043.outbound.protection.outlook.com [104.47.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F7C12D5C3 for ; Tue, 12 Jul 2016 12:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=133Vvxr/aZAkeub5fAj/7x8VqwnH7khIK08bNhp+2Yc=; b=qmvX/QN33OE7wnsdMxeJJ4oSHiCEib41ZMkPdtjZYDyAEAkPkbPA95+O91BnVAFaFMeRvSPhd5TC31O/OBZnvz2eOWd6G/lKJxuzyuju34pQwYWRW5T05A9kBLOhh0QDe2u4WXgHQQdoXp2Hz6UadUY/RI0ZDj1WBqISodJFRCs= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 19:03:07 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 19:03:07 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA///wrQCAABjmgP//81OAgAASrf4= Date: Tue, 12 Jul 2016 19:03:07 +0000 Message-ID: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.146.50.187] x-ms-office365-filtering-correlation-id: 1c38db1f-a3f1-4d63-d2f6-08d3aa872939 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:d9eCTs/5P0w3bBjolLe07zRZ0MFrFpSaye5KQthKk6zAlulblSlzFEgRqCmU7oXAOREd8M6kHXtE8ekvM0YHOnOSqBte6b/WYTXkvXo/OsqN5IEEO4YQpCKRwk4cZhITIZeO+9LX6b2NDp4K7Q+9oMXzTtxDHJUtnYYWz+UAg2anwRjlIcMjvWg6+fOo0jKML7CISYsTX3byLgbJT9bC/BqK4GMBGo6axGTojRh9gzKfdKtDJrRxnsX73fAcAu+KZ2/TTBkAfRLVwZ4dn6O8/bbn/Z8dvI9sFgXLo4RYJ54=; 5:pyUt9H1a3T5lUeAzu4VL+V7AbzGzdZnXaib/idhQdhLDhROEMq8F8yBckd9npNSNEodhboT+xQ++hUULi52fE4cJO/O7DVTcJ0k+CEsw5CjV1rlx33iuLTc9aIoMRnExWiyuoH8N0SX+6Yzu/hTj4w==; 24:NFxlnHMf3OLO/uiQCIBk0zxHwkbOpQu9taStClsu5m8N5s9mdxmmRrMmscCcfG1OOnZDHDh2+zDinHd7E60x5LyeOaRiHsqEifFVdrmJs2c=; 7:Hwqar11YM9jEwDBTZch8wUta3s5J8E3l/7x75VOf0ra+O0T0laPsTljpvrbej+VSbVAneF2AYnQaWL58LOq6tphN265o7Y5BLt6T7S8J7VHBuPyGxRj7HN2R7Id+nC4TgqqDz7N49FXxIpCN6IZ2c3o+Oz+xrxclvJNQJEmeC2PRsPIm/JoIc2DTR+jKPPI3rdUikVPM0FKwRi+9efTroIEhhlTXUJ49Xn9CNJ2LoQiW3+nREhDhWMS4gF46PVdv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(377454003)(305945005)(66066001)(36756003)(81166006)(2950100001)(2900100001)(54356999)(76176999)(50986999)(8666005)(101416001)(7736002)(74482002)(8936002)(7846002)(82746002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(230783001)(106116001)(2906002)(83716003)(6116002)(106356001)(68736007)(102836003)(3846002)(87936001)(68196006)(105586002)(4326007)(86362001)(3280700002)(110136002)(10400500002)(3660700001)(33656002)(189998001)(11100500001)(97736004)(93886004)(8676002)(5002640100001)(586003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 19:03:07.6842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:03:15 -0000 Hi, > On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote: >=20 > Hi Kenny,=20 >=20 >> On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote= : >>=20 >> Hi >>=20 >>> On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote: >>>=20 >>> Hi Kenny,=20 >>>=20 >>>> On 7/12/16, 1:05 PM, "Paterson, Kenny" wro= te: >>>>=20 >>>> Hi >>>>=20 >>>>> On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote: >>>>>=20 >>>>> Hi Kenny, >>>>>=20 >>>>> I support the strongest indistinguishability notion mentioned in (*) >>>>> above, but in my opinion we should provide good description to the >>>>> users. >>>>=20 >>>> OK, I think now we are at the heart of your argument. You support our >>>> choice of security definition and method of analysis after all. >>>>=20 >>>> And we can agree that good descriptions can only help. >>>>=20 >>>>> That is why I support the limit around 2^38 records. >>>>=20 >>>> I don't see how changing 2^24.5 (which is in the current draft) to 2^3= 8 >>>> provides a better description to users. >>>>=20 >>>> Are you worried they won't know what a decimal in the exponent means? >>>>=20 >>>> Or, more seriously, are you saying that 2^{-32} for single key attacks >>>> is >>>> a big enough security margin? If so, can you say what that's based on? >>>=20 >>> It would not make sense to ask people to rekey unnecessarily. 1 in 2^32 >>> is >>> 1 in 4,294,967,296 for the indistinguishability attack. >>=20 >> I would agree that it does not make sense to ask TLS peers to rekey >> unnecessarily. I also agree that 1 in 2^32 is >> 1 in 4,294,967,296. Sure looks like a big, scary number, don't it? >>=20 >> Are you then arguing that 2^{-32} for single key attacks is a big enough >> security margin because we want to avoid rekeying? >=20 > Because it is safe therefore there are no needs to rekey. Could you define "safe", please? Safe for what? For whom? Again, why are you choosing 2^-32 for your security bound? Why not 2^-40 or= even 2^-24? What's your rationale? Is it just finger in the air, or do you= have a threat analysis, or ...? > I don=B9t > recommend to run another function/protocol when there are no needs for it= . > I don=B9t see any particular reasons for mentioning single key in the > indistinguishability attack here. >=20 Then please read a little further into the note that presents the analysis:= a conservative but generic approach dictates that, when the attacker has m= ultiple keys to attack, we should multiply the security bounds by the numbe= r of target keys.=20 A better analysis for AES-GCM may eventually be forthcoming but we don't ha= ve it yet.=20 >> Then do you have a >> specific concern about the security of rekeying? I could see various way= s >> in which it might go wrong if not designed carefully. >>=20 >> Or are you directly linking a fundamental security question to an >> operational one, by which I mean: are you saying we should trade securit= y >> for avoiding the "cost" of rekeying for some notion of "cost"? If so, ca= n >> you quantify the cost for the use cases that matter to you? I'd love to have your answer to these questions. I didn't see one yet. What= is the cost metric you're using and how does it quantity for your use case= s? Cheers, Kenny >>=20 >> Cheers, >>=20 >> Kenny >=20 > Regards, > Quynh.=20 >=20 >=20 >=20 From nobody Tue Jul 12 12:09:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E031112D5AE for ; Tue, 12 Jul 2016 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S_ZA6wyn_q6 for ; Tue, 12 Jul 2016 12:09:45 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDC712D5C2 for ; Tue, 12 Jul 2016 12:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1qhbnUCwHkKPbF31hzL5Pzr/K79GMjUempFKH1ZjKOs=; b=Y8GT6JjMUTJoaQOYgFE/jQ+zkWb+jQquAmpj69wAjPMbNpvOaOjStD0nm5vAj1pXjeUCJb3sNkyYKoHCBfe3bWazKEDXZFirke+1vhwfH/EwIm2iYfk0zWrKhnP4Hxo1lEKml5R9JBCHaXgjlfSYijqsQh72SgTBNYH//0F64io= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 19:09:41 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 19:09:41 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAACUMAgAAetICAAAYNgIAAFExS Date: Tue, 12 Jul 2016 19:09:41 +0000 Message-ID: <86A9696F-2B89-45D7-AEB1-7587326E3D4F@rhul.ac.uk> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.146.50.187] x-ms-office365-filtering-correlation-id: 262bfacd-8b40-4035-ddfc-08d3aa8813ea x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:fkzzqzEwec06L75smwA1iDYjtZLQvFAFP4fcvmJyH/Z7y3Hq0BExPREEaoVav0YZWOD37BTxb3Tdhuxw1vyY/KC94E0DQG9Dx0Qt4yH6zfPAkzQLOU0nGIWw0URLyQ6QJJspSFPIy0rt+71XsBFiJmssuG7xX56tC48UiUQd8jSWtrICIyshtM5zHC96bNXStfDawEobPM/BfuNQy+P3QaJoDI7T9CRl9C01ApYnimZ1BXXURcPjmaRYap5VDSQ5qphNS+vjmcln0Nl6EsXfoAZ3qbJNNbx3iHOiQW3dvn8=; 5:v/CFZ1USRA4Q/iRKNZRR7XMtuSJUDRQ4iACq281KE0/Y35y3Si/eIJ2NkG4DywLWzQhcYWEk7DcVIt3L7OEANjBepSXkWfjpqRUg/ELoYmGatp0fKfKC9PT66HacmSFudqyjseNwFuqxz9xO851laQ==; 24:ZDDOb0OHQTh2cNue4mwLW9c1+hldixxFgIIVXaUOm871gy0+fzH2+ZHiDsd2i+0SpP3iIISOe2BKYqeuqeAh4kkRF1CA/UweZq/sp5KhViY=; 7:wk9GIyFmH2UEEBpdVztqxkpF07KJbg42m1s/yNGPdttHgJH0yZbBi+v+mS4OHxabo333aOlu8rrAW9r2zghq8RDICApkBp+xNNIdaesc2YM4TBL6W11kpm3YO4KUeIAYpw/PuVzGjV3HzJHxRZSA1rMUmEOruSLhlmlz3CE9otQROc7wx0j6x63fPS4mk2HosbcO97T3f6ZQTtxCcbYo/VHtvnhXIaRAa1H2lwmGoXkg/FrAPGdgjbLFVKIjSGxR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(55674003)(189002)(199003)(377454003)(13464003)(305945005)(66066001)(36756003)(81166006)(2950100001)(15975445007)(2900100001)(54356999)(76176999)(50986999)(8666005)(101416001)(7736002)(74482002)(8936002)(7846002)(82746002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(230783001)(106116001)(2906002)(83716003)(6116002)(106356001)(68736007)(102836003)(3846002)(87936001)(68196006)(105586002)(4326007)(86362001)(3280700002)(110136002)(10400500002)(3660700001)(33656002)(189998001)(11100500001)(97736004)(93886004)(8676002)(5002640100001)(586003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 19:09:41.4494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:09:48 -0000 Hi > On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) wrote: >=20 > Hi Kenny,=20 >=20 >> On 7/12/16, 12:33 PM, "Paterson, Kenny" wrot= e: >>=20 >> Unfortunately, that's not quite the right interpretation. The bounds one >> obtains depend on both the total amount of data encrypted AND the number >> of encryption queries the adversary is allowed to make to AES-GCM under >> the (single) target key. >=20 > My understanding is that the total is the data complexity limit (counting > block encryptions and queries which are also block encryptions). Yes. And you can approximately convert between them by dividing by the bloc= k size (128 bits for AES).=20 > To be > more precise, then we should count data complexity by number of block > encryptions (encrypting 1 bit is 1 block encryption). But for large data > in TLS, encryption is pretty much with full blocks of plaintexts. Yes. For our analysis, we assume 2^14 bytes per record. This equates to a w= hole number of AES blocks. You can add one more block per record if you wan= t to, to cater for any rounding up, but it makes only a tiny difference to = the final bounds.=20 > If the attacker has 2^10 encrypted blocks and is allowed to query anothe= r > 2^10 encryptions, then the total data is 2^20 because the total of 2^20 > block encryptions happens. In TLS, it means that 2^20 AES block > encryptions happen. >=20 I'm not sure I understand this. It's perhaps worth rereading what I wrote j= ust below about why we assume 2^14 bytes per record.=20 Cheers, Kenny >> We assumed each record was 2^14 bytes in size to simplify the ensuing >> analysis, and to enable us to focus on how the security bounds then depe= nd >> on the number of records encrypted. See equation (5) and Table 2 in the >> note at=20 >>=20 >> http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf. >>=20 >> In short, the security bound does not necessarily hold for ANY 2^52 >> encrypted data bytes. For example, if the attacker encrypted 2^52 record= s >> of size 1 (!) then equation (5) would tell us almost nothing useful at a= ll >> about security. >>=20 >> Finally, you write "to come to the 2^38 record limit, they assume that >> each record is the maximum 2^14 bytes". For clarity, we did not recommen= d >> a limit of 2^38 records. That's Quynh's preferred number, and is >> unsupported by our analysis. >>=20 >> Cheers, >>=20 >> Kenny >=20 > Regards, > Quynh.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >>=20 >>=20 >> On 12/07/2016 16:45, "Scott Fluhrer (sfluhrer)" >> wrote: >>=20 >>> Actually, a more correct way of viewing the limit would be 2^52 encrypt= ed >>> data bytes. To come to the 2^38 record limit, they assume that each >>> record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd tak= e >>> over a year to encrypt that much data... >>>=20 >>>> -----Original Message----- >>>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed) >>>> Sent: Tuesday, July 12, 2016 11:12 AM >>>> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org >>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>=20 >>>> Hi Kenny, >>>>=20 >>>> The indistinguishability-based security notion in the paper is a >>>> stronger >>>> security notion than the (old) traditional confidentiality notion. >>>>=20 >>>>=20 >>>> (*) Indistinguishability notion (framework) guarantees no other attack= s >>>> can >>>> be better than the indistinguishability bound. Intuitively, you can=B9= t >>>> attack if >>>> you can=B9t even tell two things are different or not. So, being able = to >>>> say two >>>> things are different or not is the minimal condition to lead to any >>>> attack. >>>>=20 >>>> The traditional confidentiality definition is that knowing only the >>>> ciphertexts, >>>> the attacker can=B9t know any content of the corresponding plaintexts >>>> with a >>>> greater probability than some value and this value depends on the >>>> particular >>>> cipher. Of course, the maximum amount of data must not be more than >>>> some limit under a given key which also depends on the cipher. >>>>=20 >>>> For example, with counter mode AES_128, Let=B9s say encrypting 2^70 in= put >>>> blocks with a single key. With the 2^70 ciphertext blocks alone (each >>>> block is >>>> 128 bits), I don=B9t think one can find out any content of any of the >>>> plaintexts. >>>> The chance for knowing any block of the plaintexts is >>>> 1/(2^128) in this case. >>>>=20 >>>> I support the strongest indistinguishability notion mentioned in (*) >>>> above, >>>> but in my opinion we should provide good description to the users. >>>> That is why I support the limit around 2^38 records. >>>>=20 >>>> Regards, >>>> Quynh. >>>>=20 >>>> On 7/12/16, 10:03 AM, "Paterson, Kenny" >>>> wrote: >>>>=20 >>>>> Hi Quynh, >>>>>=20 >>>>> This indistinguishability-based security notion is the confidentialit= y >>>>> notion that is by now generally accepted in the crypto community. >>>>> Meeting it is sufficient to guarantee security against many other >>>> forms >>>>> of attack on confidentiality, which is one of the main reasons we use >>>> it. >>>>>=20 >>>>> You say that an attack in the sense implied by breaking this notion >>>>> does not break confidentiality. Can you explain what you mean by >>>>> "confidentiality", in a precise way? I can then try to tell you >>>> whether >>>>> this notion will imply yours. >>>>>=20 >>>>> Regards >>>>>=20 >>>>> Kenny >>>>>=20 >>>>> On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)" >>>>> wrote: >>>>>=20 >>>>>> Hi Eric and all, >>>>>>=20 >>>>>>=20 >>>>>> In my opinion, we should give better information about data limit fo= r >>>>>> AES_GCM in TLS 1.3 instead of what is current in the draft 14. >>>>>>=20 >>>>>>=20 >>>>>> In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what >>>>>> is called confidentiality attack is the known plaintext >>>>>> differentiality attack where the attacker has/chooses two >>>> plaintexts, >>>>>> send them to the AES-encryption oracle. The oracle encrypts one of >>>>>> them, then sends the ciphertext to the attacker. After seeing the >>>>>> ciphertext, the attacker has some success probability of telling >>>> which >>>>>> plaintext was encrypted and this success probability is in the >>>> column >>>>>> called =B3Attack Success Probability=B2 in Table 1. This attack doe= s not >>>>>> break confidentiality. >>>>>>=20 >>>>>>=20 >>>>>> If the attack above breaks one of security goal(s) of your individua= l >>>>>> system, then making success probability of that attack at 2^(-32) ma= x >>>>>> is enough. In that case, the Max number of records is around 2^38. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Quynh. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Date: Monday, July 11, 2016 at 3:08 PM >>>>>> To: "tls@ietf.org" >>>>>> Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>>=20 >>>>>> I've just submitted draft-ietf-tls-tls13-14.txt and it should show u= p >>>>>> on the draft repository shortly. In the meantime you can find the >>>>>> editor's copy in the usual location at: >>>>>>=20 >>>>>>=20 >>>>>> http://tlswg.github.io/tls13-spec/ >>>>>>=20 >>>>>>=20 >>>>>> The major changes in this document are: >>>>>>=20 >>>>>>=20 >>>>>> * A big restructure to make it read better. I moved the Overview >>>>>> to the beginning and then put the document in a more logical >>>>>> order starting with the handshake and then the record and >>>>>> alerts. >>>>>>=20 >>>>>>=20 >>>>>> * Totally rewrote the section which used to be called "Security >>>>>> Analysis" and is now called "Overview of Security Properties". >>>>>> This section is still kind of a hard hat area, so PRs welcome. >>>>>> In particular, I know I need to beef up the citations for the >>>>>> record layer section. >>>>>>=20 >>>>>>=20 >>>>>> * Removed the 0-RTT EncryptedExtensions and moved ticket_age >>>>>> into the ClientHello. This quasi-reverts a change in -13 that >>>>>> made implementation of 0-RTT kind of a pain. >>>>>>=20 >>>>>>=20 >>>>>> As usual, comments welcome. >>>>>> -Ekr >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> * Allow cookies to be longer (*) >>>>>>=20 >>>>>>=20 >>>>>> * Remove the "context" from EarlyDataIndication as it was undefined >>>>>> and nobody used it (*) >>>>>>=20 >>>>>>=20 >>>>>> * Remove 0-RTT EncryptedExtensions and replace the ticket_age >>>>>> extension >>>>>> with an obfuscated version. Also necessitates a change to >>>>>> NewSessionTicket (*). >>>>>>=20 >>>>>>=20 >>>>>> * Move the downgrade sentinel to the end of ServerHello.Random >>>>>> to accomodate tlsdate (*). >>>>>>=20 >>>>>>=20 >>>>>> * Define ecdsa_sha1 (*). >>>>>>=20 >>>>>>=20 >>>>>> * Allow resumption even after fatal alerts. This matches current >>>>>> practice. >>>>>>=20 >>>>>>=20 >>>>>> * Remove non-closure warning alerts. Require treating unknown alerts >>>>>> as >>>>>> fatal. >>>>>>=20 >>>>>>=20 >>>>>> * Make the rules for accepting 0-RTT less restrictive. >>>>>>=20 >>>>>>=20 >>>>>> * Clarify 0-RTT backward-compatibility rules. >>>>>>=20 >>>>>>=20 >>>>>> * Clarify how 0-RTT and PSK identities interact. >>>>>>=20 >>>>>>=20 >>>>>> * Add a section describing the data limits for each cipher. >>>>>>=20 >>>>>>=20 >>>>>> * Major editorial restructuring. >>>>>>=20 >>>>>>=20 >>>>>> * Replace the Security Analysis section with a WIP draft. >>>>>>=20 >>>>>>=20 >>>>>> (*) indicates changes to the wire protocol which may require >>>>>> implementations >>>>>> to update. >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Tue Jul 12 12:29:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A587F12D50D for ; Tue, 12 Jul 2016 12:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnsi4kbjFWAA for ; Tue, 12 Jul 2016 12:29:35 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3595112B038 for ; Tue, 12 Jul 2016 12:29:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1A23C7E90; Tue, 12 Jul 2016 22:29:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id tXCiq5glgMMF; Tue, 12 Jul 2016 22:29:32 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B13DF2315; Tue, 12 Jul 2016 22:29:32 +0300 (EEST) Date: Tue, 12 Jul 2016 22:29:29 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160712041624.GA30472@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:29:37 -0000 On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote: > [Changing subject since the other thread is about something else.] > > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist > in 1.2 because we're not touching the 1.2 registries. But this should be > clarified in the spec. I would actually prefer they stay 1.3-only. I > personally could live with either, but that's because we've backported the > 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some > minor weirdness). I did intentionally mean for the scheme to be > backportable, but I do not think it should be mandated that implementations > do so. If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better be able to gracefully deal with server picking on the offer, even after downnegotiation. Anything else, and you risk interop failures. Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older (no problems there: The server won't be able to pick on the offer). > 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a > hash function and a signature algorithm which takes a pre-hashed value. A > 1.3 signature scheme is a function that takes a message. This means that, > to backport to TLS 1.2, implementations must remove all pre-hash steps and: The current signature algorithm numbers are messed up. I would have assigned 0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA. (That way the signature algorithms have proper hash designations, and yes 0x00 is hash designation for "unhashed"). > 1. For ServerKeyExchange, assemble the client_random || server_random || > ServerKeyExchange payload and then pass it into the signature scheme. > Current logic probably hashes and then feeds the hash in. If one has proper signature primitive, it takes a message and internally hashes it the way needed. > 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full > handshake transcript, so there's interactions with the PRF. I've seen > implementations which require signing hash match the PRF hash, sometimes > with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a > mess. I've also seen implementations which decouple them, at the cost of > maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting > forces the second choice. By the time CertificateRequest is sent, the server knows the final protocol, so it can omit algorithms it knows it can't handle. Also, the client picks the actual algorithm, so it too can avoid algorithms it can't handle. So client auth isn't the interop hazard server auth is. > Notably, if backporting EdDSA, there is no rolling hash one can maintain > for CertificateVerify anyway. EdDSA is inherently message-based, which > motivated the 1.3 change. (That and simpler interfaces.) Well, proper crypto libs only have message-based signature APIs anyway (because hash-based ones are trouble). > There is a middle ground: we backport RSA-PSS (then we should assign it in > the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA. > I intentionally did not do this. I did not want, many years down the line > when EdDSA certificates actually exist, for implementations to discover the > message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style > so any questions about the new scheme would be resolved early. Well, RFC4492bis is likely have EdDSA, in way that is compatible with TLS 1.3... > (We've implemented the message-based scheme and it seems to be just fine. > If you're willing to pay the cost of the backport to all versions, it > actually ends up quite tidy.) Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but there either side can decide just not to support it. No such luck with clients that implement the algorithm for server certificates in any version. -Ilari From nobody Tue Jul 12 12:50:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CE712D5F6 for ; Tue, 12 Jul 2016 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb0OsB3jA-NF for ; Tue, 12 Jul 2016 12:50:11 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (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 C87B712D5CC for ; Tue, 12 Jul 2016 12:50:10 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 6BEAC12802D.A204B X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 6BEAC12802D for ; Tue, 12 Jul 2016 21:50:03 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id 5C7B62003B; Tue, 12 Jul 2016 21:50:03 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 4D6C26002E; Tue, 12 Jul 2016 21:50:03 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 2810540; Tue, 12 Jul 2016 21:50:03 +0200 (CEST) Received: from 94-224-67-16.access.telenet.be ([94.224.67.16]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 12 Jul 2016 21:50:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 21:50:03 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: "Scott Fluhrer (sfluhrer)" In-Reply-To: References: Message-ID: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:50:13 -0000 > To be clear, this probability is that an attacker would be able to > take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential > (but incorrect) plaintext, and with probability 2^{-32}, be able to > determine that this plaintext was not the one used for the ciphertext > (and with probability 0.999999999767..., know nothing about whether > his guessed plaintext was correct or not). You need to be careful when making such claims. There are schemes for which when you reach the birthday bound you can perform partial key recovery. The probabilities we calculated guarantee that there won't be any attacks (with the usual assumptions...). Beyond the bounds, there are no guarantees. In particular, you cannot conclude that one, for example, loses 1 bit of security once beyond the birthday bound. Atul On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >> -----Original Message----- >> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >> Sent: Tuesday, July 12, 2016 1:17 PM >> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >> tls@ietf.org >> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >> >> Hi >> >> On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote: >> >> >Hi Kenny, >> > >> >On 7/12/16, 12:33 PM, "Paterson, Kenny" >> wrote: >> > >> >>Finally, you write "to come to the 2^38 record limit, they assume that >> >>each record is the maximum 2^14 bytes". For clarity, we did not >> >>recommend a limit of 2^38 records. That's Quynh's preferred number, >> >>and is unsupported by our analysis. >> > >> >What is problem with my suggestion even with the record size being the >> >maximum value? >> >> There may be no problem with your suggestion. I was simply trying to >> make it >> clear that 2^38 records was your suggestion for the record limit and >> not ours. >> Indeed, if one reads our note carefully, one will find that we do not >> make any >> specific recommendations. We consider the decision to be one for the >> WG; >> our preferred role is to supply the analysis and help interpret it if >> people >> want that. Part of that involves correcting possible misconceptions >> and >> misinterpretations before they get out of hand. >> >> Now 2^38 does come out of our analysis if you are willing to accept >> single key >> attack security (in the indistinguishability sense) of 2^{-32}. So in >> that limited >> sense, 2^38 is supported by our analysis. But it is not our >> recommendation. >> >> But, speaking now in a personal capacity, I consider that security >> margin to be >> too small (i.e. I think that 2^{-32} is too big a success >> probability). > > To be clear, this probability is that an attacker would be able to > take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential > (but incorrect) plaintext, and with probability 2^{-32}, be able to > determine that this plaintext was not the one used for the ciphertext > (and with probability 0.999999999767..., know nothing about whether > his guessed plaintext was correct or not). > > I'm just trying to get people to understand what we're talking about. > This is not "with probability 2^{-32}, he can recover the plaintext" > > >> >> Regards, >> >> Kenny > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 12 12:53:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A38012D61C for ; Tue, 12 Jul 2016 12:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hmpqtJDevur for ; Tue, 12 Jul 2016 12:53:53 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 D7EE612D61A for ; Tue, 12 Jul 2016 12:53:52 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id j8so4598747itb.1 for ; Tue, 12 Jul 2016 12:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cpIhShgxR2uH1DDqJ4GiKOEJrKF+KHOeLRUlMvEM36U=; b=mZdfGoEYBWFhoa94umxvwfTO0aZUIBcwO+vIXtBiQTUwmsiUPig2cjavRjoNamqcJp qzl6P0IMHvnkqL8CaWCWJlOHfdSIUci4Q7xGRNKVELA650mYhBfCDf0Nz1EMgz0MJkhC PX6lJzdorUt5PzeCVGRsGGRutGbDMaSel5VwA= 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; bh=cpIhShgxR2uH1DDqJ4GiKOEJrKF+KHOeLRUlMvEM36U=; b=lcPTWPHuvolrGJRW+JhyE62adYAiJtT7RkYYg6oigO10HK2kNdrVDv5QToyYrinoUD 4AWJN/AWynwaZjAMyOgXvUWeM+GgjMXMuJTMxwtyXp7OrNMROJyk/s/aiXPSvhbz8i8F y8gUrOiy8ZPK1BgDZzn5vFnm3J5ugqMm7wKInJGPeVImrCuiCwiyxHMWfzuuZvybAqjd sg0Vy/31fbhW88JoMykPrbab1pVolJABmuURJ2BaxVUhNByavMsN4mVoxGMxZClZjMqy z3RI4ppiUKjfD85+v963P0eZz3Fj67c9mprULFMD4/itbMbzi2kqCwMJiRJ/4cQk8LYc lO/w== X-Gm-Message-State: ALyK8tKlCXn4F+56Ex/T8Ehf7pLMyS9gqQJ0g3jAFC5PqAV9PW+FavqaUhu6Hw4pu5hJgjE+bN56RItuzUHw/YtY X-Received: by 10.36.230.5 with SMTP id e5mr5096496ith.92.1468353231991; Tue, 12 Jul 2016 12:53:51 -0700 (PDT) MIME-Version: 1.0 References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Tue, 12 Jul 2016 19:53:41 +0000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c11c82ecc8185053775a03b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:53:55 -0000 --94eb2c11c82ecc8185053775a03b Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote: > > [Changing subject since the other thread is about something else.] > > > > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist > > in 1.2 because we're not touching the 1.2 registries. But this should be > > clarified in the spec. I would actually prefer they stay 1.3-only. I > > personally could live with either, but that's because we've backported > the > > 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some > > minor weirdness). I did intentionally mean for the scheme to be > > backportable, but I do not think it should be mandated that > implementations > > do so. > > If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better > be able to gracefully deal with server picking on the offer, even after > downnegotiation. Anything else, and you risk interop failures. > Right, there is a risk of interop failures if two implementations disagree on whether the algorithms exist in 1.2. Since getting these algorithms into 1.2 is not that important, I want everyone to standardize on the easier option (that is, they do *not* exist in 1.2). Otherwise we risk some implementations backporting (because the spec says to) and some not (because it is easier not to). > Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older > (no problems there: The server won't be able to pick on the offer). > > > 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into > a > > hash function and a signature algorithm which takes a pre-hashed value. A > > 1.3 signature scheme is a function that takes a message. This means that, > > to backport to TLS 1.2, implementations must remove all pre-hash steps > and: > > The current signature algorithm numbers are messed up. I would have > assigned > 0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA. > > (That way the signature algorithms have proper hash designations, and yes > 0x00 is hash designation for "unhashed"). > TLS 1.3 SignatureScheme intentionally does away with the decomposition. It thinks of a "signature algorithm" at the level of messages, which means implementations shouldn't care about this. This also gives us more breathing room to allocate ed25519-style IDs (which I would like to be the norm, rather than parametrizing everything). We get most of our 2^16 space rather than just 2^8. > > 1. For ServerKeyExchange, assemble the client_random || server_random || > > ServerKeyExchange payload and then pass it into the signature scheme. > > Current logic probably hashes and then feeds the hash in. > > If one has proper signature primitive, it takes a message and internally > hashes it the way needed. > Yup, that's why TLS 1.3's version looks the way it does. But if one has such a primitive, one shouldn't care about how the numbers are decomped (above). :-) > > 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full > > handshake transcript, so there's interactions with the PRF. I've seen > > implementations which require signing hash match the PRF hash, sometimes > > with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a > > mess. I've also seen implementations which decouple them, at the cost of > > maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting > > forces the second choice. > > By the time CertificateRequest is sent, the server knows the final > protocol, so it can omit algorithms it knows it can't handle. Also, > the client picks the actual algorithm, so it too can avoid algorithms > it can't handle. So client auth isn't the interop hazard server auth > is. > When we first added TLS 1.2 to Chrome via NSS, we hit exactly that interop hazard. Clients don't know a priori which hash functions the server will accept and may be using some crappy smartcard. The original implementation only accepted the PRF hash (SHA-256) and we ran into both servers and client smartcards that could only sign SHA-1. As a result, NSS maintains a rolling SHA-1 "backup hash" here. (The failure mode was, of course, everyone's favorite TLS version fallback.) I am sure that, were we still using NSS when we added AES_256_GCM (SHA-384 PRF), we would have hit more problems with smartcards that can only sign SHA-256. But this is all sort of beside the point. The way to avoid this interop hazard is to maintain the full handshake buffer which is also how you backport. :-) I'm more worried about implementations which don't do the backport because it's more work or they don't want to pay the handshake buffer. > > Notably, if backporting EdDSA, there is no rolling hash one can maintain > > for CertificateVerify anyway. EdDSA is inherently message-based, which > > motivated the 1.3 change. (That and simpler interfaces.) > > Well, proper crypto libs only have message-based signature APIs anyway > (because hash-based ones are trouble). > > > There is a middle ground: we backport RSA-PSS (then we should assign it > in > > the 1.2 style and allocate corresponding 1.3-style numbers) and not > EdDSA. > > I intentionally did not do this. I did not want, many years down the line > > when EdDSA certificates actually exist, for implementations to discover > the > > message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style > > so any questions about the new scheme would be resolved early. > > Well, RFC4492bis is likely have EdDSA, in way that is compatible with > TLS 1.3... > (s/TLS 1.3/TLS 1.2/?) Yeah, I don't think defining it for 1.2 makes much sense. I expect 1.3 will get deployed much faster than EdDSA PKIs. > > (We've implemented the message-based scheme and it seems to be just fine. > > If you're willing to pay the cost of the backport to all versions, it > > actually ends up quite tidy.) > > Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but > there either side can decide just not to support it. No such luck > with clients that implement the algorithm for server certificates in > any version. > > > -Ilari > --94eb2c11c82ecc8185053775a03b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12= , 2016 at 3:29 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrot= e:
> [Changing subject since the other thread is about something else.]
>
> I believe, as the text stands right now, RSA-PSS and EdDSA do *not* ex= ist
> in 1.2 because we're not touching the 1.2 registries. But this sho= uld be
> clarified in the spec. I would actually prefer they stay 1.3-only. I > personally could live with either, but that's because we've ba= ckported the
> 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some=
> minor weirdness). I did intentionally mean for the scheme to be
> backportable, but I do not think it should be mandated that implementa= tions
> do so.

If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better be able to gracefully deal with server picking on the offer, even after
downnegotiation. Anything else, and you risk interop failures.

Right, there is a risk of interop failures if two i= mplementations disagree on whether the algorithms exist in 1.2. Since getti= ng these algorithms into 1.2 is not that important, I want everyone to stan= dardize on the easier option (that is, they do *not* exist in 1.2). Otherwi= se we risk some implementations backporting (because the spec says to) and = some not (because it is easier not to).
=C2=A0
Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older
(no problems there: The server won't be able to pick on the offer).

> 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed in= to a
> hash function and a signature algorithm which takes a pre-hashed value= . A
> 1.3 signature scheme is a function that takes a message. This means th= at,
> to backport to TLS 1.2, implementations must remove all pre-hash steps= and:

The current signature algorithm numbers are messed up. I would have assigne= d
0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA.
(That way the signature algorithms have proper hash designations, and yes 0x00 is hash designation for "unhashed").
TLS 1.3 SignatureScheme intentionally does away with the decom= position. It thinks of a "signature algorithm" at the level of me= ssages, which means implementations shouldn't care about this.

This also gives us more breathing room to allocate ed25519= -style IDs (which I would like to be the norm, rather than parametrizing ev= erything). We get most of our 2^16 space rather than just 2^8.
= =C2=A0
> 1. For ServerKeyExchange, assemble the client_random || server_random = ||
> ServerKeyExchange payload and then pass it into the signature scheme.<= br> > Current logic probably hashes and then feeds the hash in.

If one has proper signature primitive, it takes a message and internally hashes it the way needed.

Yup, that'= ;s why TLS 1.3's version looks the way it does. But if one has such a p= rimitive, one shouldn't care about how the numbers are decomped (above)= . :-)
=C2=A0
> 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full
> handshake transcript, so there's interactions with the PRF. I'= ve seen
> implementations which require signing hash match the PRF hash, sometim= es
> with a backup SHA-1 hash (NSS), at the cost of hash negotiation being = a
> mess. I've also seen implementations which decouple them, at the c= ost of
> maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting=
> forces the second choice.

By the time CertificateRequest is sent, the server knows the final
protocol, so it can omit algorithms it knows it can't handle. Also,
the client picks the actual algorithm, so it too can avoid algorithms
it can't handle. So client auth isn't the interop hazard server aut= h
is.

When we first added TLS 1.2 to Chro= me via NSS, we hit exactly that interop hazard. Clients don't know a pr= iori which hash functions the server will accept and may be using some crap= py smartcard.=C2=A0The original implementat= ion only accepted the PRF hash (SHA-256) and we ran into both servers and c= lient smartcards that could only sign SHA-1. As a result, NSS maintains a r= olling SHA-1 "backup hash" here.

(The= failure mode was, of course, everyone's favorite TLS version fallback.= )

I am sure that, were we still using NSS w= hen we added AES_256_GCM (SHA-384 PRF), we would have hit more problems wit= h smartcards that can only sign SHA-256.

But this = is all sort of beside the point. The way to avoid this interop hazard is to= maintain the full handshake buffer which is also how you backport. :-) I&#= 39;m more worried about implementations which don't do the backport bec= ause it's more work or they don't want to pay the handshake buffer.=
=C2=A0
> Notably, if backporting EdDSA, there is no rolling hash one can mainta= in
> for CertificateVerify anyway. EdDSA is inherently message-based, which=
> motivated the 1.3 change. (That and simpler interfaces.)

Well, proper crypto libs only have message-based signature APIs anyway
(because hash-based ones are trouble).

> There is a middle ground: we backport RSA-PSS (then we should assign i= t in
> the 1.2 style and allocate corresponding 1.3-style numbers) and not Ed= DSA.
> I intentionally did not do this. I did not want, many years down the l= ine
> when EdDSA certificates actually exist, for implementations to discove= r the
> message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 st= yle
> so any questions about the new scheme would be resolved early.

Well, RFC4492bis is likely have EdDSA, in way that is compatible with
TLS 1.3...

(s/TLS 1.3/TLS 1.2/?)
<= div>
Yeah, I don't think defining it for 1.2 makes much s= ense. I expect 1.3 will get deployed much faster than EdDSA PKIs.
=C2=A0
> (We've implemented the message-based scheme and it seems to be jus= t fine.
> If you're willing to pay the cost of the backport to all versions,= it
> actually ends up quite tidy.)

Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but
there either side can decide just not to support it. No such luck
with clients that implement the algorithm for server certificates in
any version.


-Ilari
--94eb2c11c82ecc8185053775a03b-- From nobody Tue Jul 12 12:55:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5812D5D3 for ; Tue, 12 Jul 2016 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLjpeiHYtSgk for ; Tue, 12 Jul 2016 12:55:10 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AA6BB12D57B for ; Tue, 12 Jul 2016 12:55:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A492E4268; Tue, 12 Jul 2016 22:55:09 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Ragno-lEXiur; Tue, 12 Jul 2016 22:55:09 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 56C1F283; Tue, 12 Jul 2016 22:55:09 +0300 (EEST) Date: Tue, 12 Jul 2016 22:55:06 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160712195506.GA32300@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:55:12 -0000 On Tue, Jul 12, 2016 at 10:29:29PM +0300, Ilari Liusvaara wrote: > By the time CertificateRequest is sent, the server knows the final > protocol, so it can omit algorithms it knows it can't handle. Also, > the client picks the actual algorithm, so it too can avoid algorithms > it can't handle. So client auth isn't the interop hazard server auth > is. There actually are TLS stacks in dev that have TLS 1.2 client authentication on will-not-implement-list (for reasons totally unrelated to "message-based signatures") but are willing to consider or implement TLS 1.3 client authentication (these are done by authors who actually care about security[1], and know just how dangerous "crap" is). (Oh, at least two of those have backend signature APIs that actually are message-based for all signatures). [1] To the point of willfully ignoring "MUST" or "MUST NOT" requirements that conflict on security. E.g. unsafe MTIs won't be implemented. -Ilari From nobody Tue Jul 12 13:17:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3E12D5C4 for ; Tue, 12 Jul 2016 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-eJYUXM6pP3 for ; Tue, 12 Jul 2016 13:17:13 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id C260812D61C for ; Tue, 12 Jul 2016 13:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2EC028A0E; Tue, 12 Jul 2016 23:17:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id PbNQEx88PbfX; Tue, 12 Jul 2016 23:17:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D7A7C28B; Tue, 12 Jul 2016 23:17:10 +0300 (EEST) Date: Tue, 12 Jul 2016 23:17:07 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160712201707.GA32363@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <20160712192929.GA32063@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:17:16 -0000 On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote: > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara > wrote: > > Right, there is a risk of interop failures if two implementations disagree > on whether the algorithms exist in 1.2. Since getting these algorithms into > 1.2 is not that important, I want everyone to standardize on the easier > option (that is, they do *not* exist in 1.2). Otherwise we risk some > implementations backporting (because the spec says to) and some not > (because it is easier not to). Unfortunately, the way things are, it is both easier and way safer to say that they *do* exist in TLS 1.2, at least for server signatures (one can leave the crazy mess that is client signatures[1]). And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least requires its own EE certs, RSA-PSS works with standard RSA EE certs that are widespread. Have a TLS 1.3-capable server that doesn't check versions (easy enough[2]) and have it capped to TLS 1.2 by something (either misconfig or API issues, no end of those kind of servers) and there you go... That is, if client advertises EdDSA or RSA-PSS, it MUST be able to verify those, even after downnegotiation to TLS 1.2. If it doesn't, it MUST NOT advertise them, even in TLS 1.3 ClientHello. [1] How many borked/buggy servers there are that say they support X, but fail if you try to use X? Outside known trouble like mixing and matching curves and hashes in ECDSA? [2] There is actually very simple way to implement things that seems to work, only it blows up when client that claims it supports something it doesn't comes along... -Ilari From nobody Tue Jul 12 13:31:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB212D0B8 for ; Tue, 12 Jul 2016 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu5f_wDBnFYY for ; Tue, 12 Jul 2016 13:31:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A54BC12D658 for ; Tue, 12 Jul 2016 13:31:27 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AE2344334B0; Tue, 12 Jul 2016 20:31:21 +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 95FA74334A8; Tue, 12 Jul 2016 20:31:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468355481; bh=J/bOUyYEYOU2gdDXRBph2mxw8asK6mU7fxC2BCanbUY=; l=9121; h=To:References:Cc:From:Date:In-Reply-To:From; b=oPFZig7FLO1s7tAQ/mvq8bg4F+aX7MmldGGFnJA6keDByu8CVpdb21jqw1zZfQe0I 2xUV4/C/UxIDBpgTQ24sCg1HmWEV8I/G9tFDOaYYHQzoo6kgxdB1Fka3tv7zs6CGuz l1vJWSHKi7CXA4dm3YVyCubnL4JFQHXUzBLF7wBQ= 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 56E971FC94; Tue, 12 Jul 2016 20:31:21 +0000 (GMT) To: Ilari Liusvaara , Eric Rescorla References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <57855399.70201@akamai.com> Date: Tue, 12 Jul 2016 15:31:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:31:35 -0000 On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: > On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: >> Folks, >> >> I've just submitted draft-ietf-tls-tls13-14.txt and it should >> show up on the draft repository shortly. In the meantime you >> can find the editor's copy in the usual location at: >> As usual, comments welcome. >> -Ekr > Did a readthrough, here's a bunch of comments (didn't check the > issues list): Should we bulk-open issues for these so they don't get lost? I will only cherry-pick a couple to reply to. > ----------------------------------------------------------------------- > >> ### Server Hello >> >> cipher_suite >> : The single cipher suite selected by the server from the list in >> ClientHello.cipher_suites. For resumed sessions, this field is >> the value from the state of the session being resumed. >> [[TODO: interaction with PSK.]] > Isn't this the true ciphersuite used on this connection, "resumption" > or not? Otherwise you can get into all sorts of crazy situations that > WILL be sources of implementation bugs. It probably ought to be, yes. > The idea that it isn't true ciphersuite brings me bad flashbacks about > TLS 1.2 ticket "maybe resume" craziness (except this would be even > worse). I feel like we had discussed what the resumption ciphersuite should be previously, but I don't seem to be able to find it in my mail archives. > >> ### Negotiated Groups >> >> As of TLS 1.3, servers are permitted to send the "supported_groups" >> extension to the client. If the server has a group it prefers to the >> ones in the "key_share" extension but is still willing to accept the >> ClientHello, it SHOULD send "supported_groups" to update the client's >> view of its preferences. Clients MUST NOT act upon any information >> found in "supported_groups" prior to successful completion of the >> handshake, but MAY use the information learned from a successfully >> completed handshake to change what groups they offer to a server in >> subsequent connections. > Are those supposed to be filtered to be subset of ones client advertised > or not? E.g. if client didn't indicate support for x448, can the server > still send x448? Requiring filtering would prevent the client from learning when the server supports new schemes, but having the server not filter would likely end up with the server "always" sending a big pile of stuff even if the client has no idea that those schemes even exist. So, on the balance, I would go with filtering. > > >> [[TODO: Recommendation about what the client offers. >> Presumably which integer DH groups and which curves.]] > Bit crazy algorithm: If you haven't heard of this server before, > pick smallest you support, if you have, pick the one it selected > the last time. It does make it clear that things are only as secure as the weakest algorithm they will accept ... but stateless clients will also always get that weakest link. (Okay, "smallest" does not necessarily equal "weakest", but still.) With guidance on not supporting silly things, this algorithm does not seem too crazy... > >> ### Early Data Indication >> >> obfuscated_ticket_age >> : The time since the client learned about the server configuration that it is >> using, in milliseconds. This value is added modulo 2^32 to with the >> "ticket_age_add" value that was included with the ticket, see >> {{NewSessionTicket}}. This addition prevents passive observers from >> correlating sessions unless tickets are reused. Note: because ticket >> lifetimes are restricted to a week, 32 bits is enough to represent any >> plausible age, even in milliseconds. > > And the addition also prevents correlating session with its parent, > even in case of reuse (this was the reason for switching to addition > from XOR). > >> A server MUST validate that the ticket_age is within a small >> tolerance of the time since the ticket was issued (see {{replay-time}}). > Good luck with that... It would be good to not repeat the mistake that is the 5-minute replay window in Kerberos. (So, shall we make "small tolerance" a concrete value or otherwise give guidance? 5 seconds? 4xRTT? other? But, IIRC, this check does not require absolute time agreement between peers, only that their clocks advance at a similar rate. If your clock steps because you slept your laptop and you have to fall back to a full handshake, oh well. > Also, requirement that the server MUST proceed with the handshake and > reject 0-RTT if that validation fails would be good here... Definitely. > Oh, still trial decryption... Got it. I had managed to previously forget how we ended up deciding on trial decryption, but it basically was dkg commenting in the room at Buenos Aires "are we writing a security protocol or a protocol that is convenient to implement?" [with respect to the privacy/leakage from having the alert or other signal be unencrypted]. > >> #### Replay Properties {#replay-time} >> >> There are several potential sources of error that make an exact >> measurement of time difficult. Variations in client and server clocks >> are likely to be minimal, outside of gross time corrections. Network >> propagation delays are most likely causes of a mismatch in legitimate >> values for elapsed time. Both the NewSessionTicket and ClientHello >> messages might be retransmitted and therefore delayed, which might be >> hidden by TCP. > I don't think variations in clocks are minimal... Just to check: you mean the rate at which clocks advance, and not the absolute number reported as the time? > I wonder what 95% timeskew interval per day is... > > (Oh, and have fun with leap seconds!) It only matters how big the skew is relative to the acceptance window and how long the ticket is valid for. Which brings us back to what the acceptance window is measured in... >> ### Encrypted Extensions >> >> The same extension types MUST NOT appear in both the ServerHello and >> EncryptedExtensions. If the same extension appears in both locations, >> the client MUST rely only on the value in the EncryptedExtensions >> block. All server-sent extensions other than those explicitly listed >> in {{server-hello}} or designated in the IANA registry MUST only >> appear in EncryptedExtensions. Extensions which are designated to >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients >> MUST check EncryptedExtensions for the presence of any forbidden >> extensions and if any are found MUST terminate the handshake with an >> "illegal_parameter" alert. > This seems inconsistent. In implementation, I would write explicit disjoint > whitelists of extensions for both (and non-whitelisted one is a fatal > error). Explicit whitelisting is safe even on client side, since the > extensions are bounded by client-supported ones. You would have an explicit whitelist of all (including encrypted) extensions for the server, so that it chokes when a client starts sending a new one? Or just that it would not be considered for further processing [and potential inclusion in ServerHello]? > >> ## Random Number Generation and Seeding >> >> To estimate the amount of seed material being produced, add the number of bits >> of unpredictable information in each seed byte. For example, keystroke timing >> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure bits >> each, even though the total size of the counter value is 16 bits or more. >> Seeding a 128-bit PRNG would thus require approximately 100 such timer values. > This seems really obsolete. The timers have not been 18.2Hz for years, and > applications running on operating systems damn better use OS services for > random numbers, given that anything else is fraught with peril. > Sadly, there is a vocal minority of software implementors that insist that the OS service is too slow and write their own. But I agree this section needs some work; I may be able to contribute some text. > >> # Overview of Security Properties {#security-analysis} >> >> [[TODO: This section is still a WIP and needs a bunch more work.]] >> >> A complete security analysis of TLS is outside the scope of this document. >> In this section, we provide an informal description the desired properties >> as well as references to more detailed work in the research literature >> which provides more formal definitions. >> >> We cover properties of the handshake separately from those of the record layer. > I think properties of the exporter should be covered as well: I agree (but am unlikely to be able to contribute text). -Ben > - Is it intended to generate secret data (yes) > - Is it intended to generate connection-unique data (yes) > - Are values for different labels/contexts intended to be computationally > independent (yes) > > > (The TLS 1.2 exporter without EMS failed the middle requirement, > creating security issues in applications that assumed the data was > connection-unique. > > From nobody Tue Jul 12 14:07:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EA12D89D for ; Tue, 12 Jul 2016 14:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNaF64VDyuSI for ; Tue, 12 Jul 2016 14:07:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0649512D892 for ; Tue, 12 Jul 2016 14:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 902636497; Wed, 13 Jul 2016 00:07:36 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id VDBwQS2uimeE; Wed, 13 Jul 2016 00:07:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1555F2310; Wed, 13 Jul 2016 00:07:36 +0300 (EEST) Date: Wed, 13 Jul 2016 00:07:33 +0300 From: Ilari Liusvaara To: Benjamin Kaduk Message-ID: <20160712210732.GB32363@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57855399.70201@akamai.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:07:40 -0000 On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote: > On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: > > Isn't this the true ciphersuite used on this connection, "resumption" > > or not? Otherwise you can get into all sorts of crazy situations that > > WILL be sources of implementation bugs. > > It probably ought to be, yes. If the field is allowed to contain some ciphersuite with wrong key exchange type, it takes sniffing extensions from ServerHello and EncryptedExtensions to figure out what the actual ciphersuite is. And knowing the key exchange type is rather important in not getting hit by SMACK. > > The idea that it isn't true ciphersuite brings me bad flashbacks about > > TLS 1.2 ticket "maybe resume" craziness (except this would be even > > worse). > > I feel like we had discussed what the resumption ciphersuite should be > previously, but I don't seem to be able to find it in my mail archives. AFAIK, the ciphersuite with the same protection and PRF, but some PSK or GDHE-PSK key exchange type. There is well-defined function from (kextype,protection,prfhash) into ciphersuite (or that no such ciphersuite exists). > Requiring filtering would prevent the client from learning when the > server supports new schemes, but having the server not filter would > likely end up with the server "always" sending a big pile of stuff even > if the client has no idea that those schemes even exist. So, on the > balance, I would go with filtering. What would the client do with unknown groups anyway? Dump a message to log? > >> [[TODO: Recommendation about what the client offers. > >> Presumably which integer DH groups and which curves.]] > > Bit crazy algorithm: If you haven't heard of this server before, > > pick smallest you support, if you have, pick the one it selected > > the last time. > > It does make it clear that things are only as secure as the weakest > algorithm they will accept ... but stateless clients will also always > get that weakest link. (Okay, "smallest" does not necessarily equal > "weakest", but still.) With guidance on not supporting silly things, > this algorithm does not seem too crazy... Well, what client accepts is separate question to its speculative guesses for performance improvement. And for the first, there is supported_groups. key_share is not meant to be xmas tree! > > Good luck with that... > > It would be good to not repeat the mistake that is the 5-minute replay > window in Kerberos. (So, shall we make "small tolerance" a concrete > value or otherwise give guidance? 5 seconds? 4xRTT? other? > But, IIRC, this check does not require absolute time agreement between > peers, only that their clocks advance at a similar rate. If your clock > steps because you slept your laptop and you have to fall back to a full > handshake, oh well. In one piece of code I wrote, I pulled +-15s maximum (config can have tighter limits) out of thin air... And, actually, since failing 0-RTT time check is just 1-RTT delay (since in proper implementations it is not a fatal error). > > Oh, still trial decryption... Got it. > > I had managed to previously forget how we ended up deciding on trial > decryption, but it basically was dkg commenting in the room at Buenos > Aires "are we writing a security protocol or a protocol that is > convenient to implement?" [with respect to the privacy/leakage from > having the alert or other signal be unencrypted]. I thought they had switched to something else, but apparently not... > > > >> #### Replay Properties {#replay-time} > >> > >> There are several potential sources of error that make an exact > >> measurement of time difficult. Variations in client and server clocks > >> are likely to be minimal, outside of gross time corrections. Network > >> propagation delays are most likely causes of a mismatch in legitimate > >> values for elapsed time. Both the NewSessionTicket and ClientHello > >> messages might be retransmitted and therefore delayed, which might be > >> hidden by TCP. > > I don't think variations in clocks are minimal... > > Just to check: you mean the rate at which clocks advance, and not the > absolute number reported as the time? Correct. I should check the computers I have for what the tickrate approximately is (one curious observation: rebooting computer changes the tickrate(!)). I think I estimated 140ms/day drift for one of those (the others can be way worse). However, the rate of change of the rate (2nd derivate of time reported relative to "true time" (one can for all practical purposes ignore SR and GR here)) should be small. > > I wonder what 95% timeskew interval per day is... > > > > (Oh, and have fun with leap seconds!) > > It only matters how big the skew is relative to the acceptance window > and how long the ticket is valid for. Which brings us back to what the > acceptance window is measured in... IIRC, maximum ticket validity is 7 days (but for some crappier clocks, that can be lots of drift). But likely TCP delays and such can cause bigger errors than slightly- bad clocks. > You would have an explicit whitelist of all (including encrypted) > extensions for the server, so that it chokes when a client starts > sending a new one? Or just that it would not be considered for further > processing [and potential inclusion in ServerHello]? The opposite way: I would have client choke if server sends it extension outside those lists (TLS 1.3 clients are already supposed to choke if server sends them extension they don't know about, this is only extending it to per-messages lists). > > This seems really obsolete. The timers have not been 18.2Hz for years, and > > applications running on operating systems damn better use OS services for > > random numbers, given that anything else is fraught with peril. > > > > Sadly, there is a vocal minority of software implementors that insist > that the OS service is too slow and write their own. But I agree this > section needs some work; I may be able to contribute some text. I think "SHOULD" would be suitable. > > I think properties of the exporter should be covered as well: > > I agree (but am unlikely to be able to contribute text). > > -Ben > > > - Is it intended to generate secret data (yes) > > - Is it intended to generate connection-unique data (yes) > > - Are values for different labels/contexts intended to be computationally > > independent (yes) Oh, and stick that it stays constant for the duration of the connection as well... -Ilari From nobody Tue Jul 12 14:13:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E883D12D8F5 for ; Tue, 12 Jul 2016 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3IKOs25q9RI for ; Tue, 12 Jul 2016 14:13:55 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E432C12D8F0 for ; Tue, 12 Jul 2016 14:13:54 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q83so28772761iod.1 for ; Tue, 12 Jul 2016 14:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q140c/R16TQFCB6I5BqrvtsfDIYXzbKZ68VbwK1E3VA=; b=d2IlkW4lgGlu0R+3DyxR3GuECaMo3zFogaR1fZO3ZSFDWmEflvj7zbgOMHTGPz6L62 JzCnipCrVAsTA04ztpF65J9UVVMWXaY2cFOLen1u+rnW6g3jj+YGJUDwH4t9QSsETKia nv+sQ1A8QIH5P+sE+rjFERAQIHKmZ8iuTGTvM= 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; bh=q140c/R16TQFCB6I5BqrvtsfDIYXzbKZ68VbwK1E3VA=; b=SkKaElN6BaYAxWZthm60jFOP1a8oA2e7Bfyi/vFAJbynDLlrpHQcwtGn9xAhh8h+P1 ulgc/Ipyl6d9SniI3iojXLQ/HDcu+Q8n4Ymmcog+OgxGZTeqIfMp/i4Z05Pnf0P2YL2y 8FJpmxNOEBFIk3ZW261WWkjqoZm/6ocUiViHKSrHtIw5uMUhi8ofJwHqTNx1m2ZvyCq3 juReFliEtFLxu4uhCNrPpuz+ATWFo3PNtVmwyo38DXnOu02QkBKgybxjFfJx/GeBBeRr VlEnxS28E+F1yCuGjuirgM+DCh80ohkc/UNeHbAdkeGKQ4D1IqzESWC0Y5btgN3A9Oo5 GqKA== X-Gm-Message-State: ALyK8tKeuNTMb6BKNfisiY23Zh/mdI7QKE6LUTICtZrRndlxYFdpbSSiinHv7XHYP/4UqVJrOxhUqsKRfCwMluuu X-Received: by 10.107.13.82 with SMTP id 79mr5722275ion.97.1468358034150; Tue, 12 Jul 2016 14:13:54 -0700 (PDT) MIME-Version: 1.0 References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <20160712192929.GA32063@LK-Perkele-V2.elisa-laajakaista.fi> <20160712201707.GA32363@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160712201707.GA32363@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Tue, 12 Jul 2016 21:13:43 +0000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113fdb5e07bcf5053776bf6d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:13:57 -0000 --001a113fdb5e07bcf5053776bf6d Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 4:17 PM Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote: > > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > Right, there is a risk of interop failures if two implementations > disagree > > on whether the algorithms exist in 1.2. Since getting these algorithms > into > > 1.2 is not that important, I want everyone to standardize on the easier > > option (that is, they do *not* exist in 1.2). Otherwise we risk some > > implementations backporting (because the spec says to) and some not > > (because it is easier not to). > > Unfortunately, the way things are, it is both easier and way safer to > say that they *do* exist in TLS 1.2, at least for server signatures > (one can leave the crazy mess that is client signatures[1]). > > And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least > requires its own EE certs, RSA-PSS works with standard RSA EE > certs that are widespread. Have a TLS 1.3-capable server that > doesn't check versions (easy enough[2]) and have it capped to TLS 1.2 > by something (either misconfig or API issues, no end of those > kind of servers) and there you go... > That's fair. If you do the backport version, then you do have to go out of your way to do the version check. I guess the question is what other implementors intend then? We've actually done the backport on our end. Perhaps my guess that not everyone will do this is wrong. That is, if client advertises EdDSA or RSA-PSS, it MUST be able to > verify those, even after downnegotiation to TLS 1.2. If it doesn't, > it MUST NOT advertise them, even in TLS 1.3 ClientHello. > Well, we could define that EdDSA/RSA-PSS in TLS 1.2 doesn't exist and then spec-wise we're fine. The question is just which we think will cause fewer interop issues. Either way, worst case, we'd just end up in an awkward state where, when signing, one does not pick RSA-PSS in 1.2 but when verifying, one should accept it. Not the end of the world. I might just go ahead and do that anyway so I don't have to care about this issue... > > [1] How many borked/buggy servers there are that say they support > X, but fail if you try to use X? Outside known trouble like mixing > and matching curves and hashes in ECDSA? > > [2] There is actually very simple way to implement things that seems > to work, only it blows up when client that claims it supports > something it doesn't comes along... > > > > -Ilari > --001a113fdb5e07bcf5053776bf6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 12= , 2016 at 4:17 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrot= e:
> On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>
> Right, there is a risk of interop failures if two implementations disa= gree
> on whether the algorithms exist in 1.2. Since getting these algorithms= into
> 1.2 is not that important, I want everyone to standardize on the easie= r
> option (that is, they do *not* exist in 1.2). Otherwise we risk some > implementations backporting (because the spec says to) and some not > (because it is easier not to).

Unfortunately, the way things are, it is both easier and way safer to
say that they *do* exist in TLS 1.2, at least for server signatures
(one can leave the crazy mess that is client signatures[1]).

And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least
requires its own EE certs, RSA-PSS works with standard RSA EE
certs that are widespread. Have a TLS 1.3-capable server that
doesn't check versions (easy enough[2]) and have it capped to TLS 1.2 by something (either misconfig or API issues, no end of those
kind of servers) and there you go...

Th= at's fair. If you do the backport version, then you do have to go out o= f your way to do the version check.

I guess the qu= estion is what other implementors intend then? We've actually done the = backport on our end. Perhaps my guess that not everyone will do this is wro= ng.

That is, if client advertises EdDSA or RSA-PSS, it MUST be able to
verify those, even after downnegotiation to TLS 1.2. If it doesn't,
it MUST NOT advertise them, even in TLS 1.3 ClientHello.

Well, we could define that EdDSA/RSA-PSS in TLS 1.2 doesn= 't exist and then spec-wise we're fine. The question is just which = we think will cause fewer interop issues.

Either w= ay, worst case, we'd just end up in an awkward state where, when signin= g, one does not pick RSA-PSS in 1.2 but when verifying, one should accept i= t. Not the end of the world. I might just go ahead and do that anyway so I = don't have to care about this issue...
=C2=A0

[1] How many borked/buggy servers there are that say they support
X, but fail if you try to use X? Outside known trouble like mixing
and matching curves and hashes in ECDSA?

[2] There is actually very simple way to implement things that seems
to work, only it blows up when client that claims it supports
something it doesn't comes along...



-Ilari
--001a113fdb5e07bcf5053776bf6d-- From nobody Tue Jul 12 14:21:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7212D947 for ; Tue, 12 Jul 2016 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf6GEwD7lhqL for ; Tue, 12 Jul 2016 14:21:15 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 858F512D969 for ; Tue, 12 Jul 2016 14:21:01 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j17so26168980ywg.0 for ; Tue, 12 Jul 2016 14:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2xM1DsNvl0VfJXRZ6nfg2QFr2PWA1UBxoIfNhu08c8o=; b=qtkRO1Feh0jwuQhJfzakKJwbhBfinwQ6zxrzewKsGiDp7ndGvwodFGrchpD7DuUIY4 s8G5Bt72IEjkj587+yZ9ru3uIoHGFCQVkCrM4l1oIA4cTka2KsvpCHZP/sK3eziIdj+t lQ6LIPiSmFPNXICJOhTqaf4WhSDw5h4LXROwINoahGdL1icYG0qwxCPMrufKaKExPGzo PZYAsKvOZvcemaGwKW/Hgxio6NVxXcbKcVFkmKroL3zfikftQND2fYrJ//H32xe4x9sh ILBSImxJ1mMBzcx23awiXifBymL9qeamXJlL3jUPw7XsqqBCbNh6Dz1kbvBLf5IlkIRb 8Dnw== 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; bh=2xM1DsNvl0VfJXRZ6nfg2QFr2PWA1UBxoIfNhu08c8o=; b=gvKvuj+D/h8duebWjV67pdpZy2KFziPU0y5Zj53giXnsNTJM9BdOabZnFNLeaQVItJ 5NRoKrzvFA01crhOYHko2SJeJHtm6MJ5jDLXDSytnk67bY8cmE1An7z6T1BW4UFQ1lgw YkJ405/gthaET581N+PD7TpQZUqpOM7T08r9h9ItC2W5PqHyM8qtMUWB9T2+5ysG+iwN 4f4/lyffYpfyBvHZIjqWsV1lOT6R/TJZKBx7Bw/gTZsCrgk8nTovp8uB1wqKBmaMWa+r iuSPlonv8Ia3BgfZh/LSWPILm76+PH2A2i6qUudyxaU4Zrog6aDVMBK+RLjY2u2wNSJX FeYw== X-Gm-Message-State: ALyK8tJeB10E3HR5BPUanVoa4P3Js8y+MsRLwsHE3GRbt6MU6Xamqo4NSyL8MINAkRGU4Rr6yzh7Q15FkHK+Lw== X-Received: by 10.37.80.141 with SMTP id e135mr3096982ybb.162.1468358460773; Tue, 12 Jul 2016 14:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 12 Jul 2016 14:20:21 -0700 (PDT) In-Reply-To: <57855399.70201@akamai.com> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com> From: Eric Rescorla Date: Tue, 12 Jul 2016 14:20:21 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1141308c754cc0053776d840 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:21:18 -0000 --001a1141308c754cc0053776d840 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 1:31 PM, Benjamin Kaduk wrote: > On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: > > On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: > >> Folks, > >> > >> I've just submitted draft-ietf-tls-tls13-14.txt and it should > >> show up on the draft repository shortly. In the meantime you > >> can find the editor's copy in the usual location at: > >> As usual, comments welcome. > >> -Ekr > > Did a readthrough, here's a bunch of comments (didn't check the > > issues list): > > Should we bulk-open issues for these so they don't get lost? I will > only cherry-pick a couple to reply to. > I opened one giant issue because I haven't gone through this yet If you want to open individual issues that you think are meritorious that woul dbe fine -Ekr > > > ----------------------------------------------------------------------- > > > >> ### Server Hello > >> > >> cipher_suite > >> : The single cipher suite selected by the server from the list in > >> ClientHello.cipher_suites. For resumed sessions, this field is > >> the value from the state of the session being resumed. > >> [[TODO: interaction with PSK.]] > > Isn't this the true ciphersuite used on this connection, "resumption" > > or not? Otherwise you can get into all sorts of crazy situations that > > WILL be sources of implementation bugs. > > It probably ought to be, yes. > > > The idea that it isn't true ciphersuite brings me bad flashbacks about > > TLS 1.2 ticket "maybe resume" craziness (except this would be even > > worse). > > I feel like we had discussed what the resumption ciphersuite should be > previously, but I don't seem to be able to find it in my mail archives. > > > > >> ### Negotiated Groups > >> > >> As of TLS 1.3, servers are permitted to send the "supported_groups" > >> extension to the client. If the server has a group it prefers to the > >> ones in the "key_share" extension but is still willing to accept the > >> ClientHello, it SHOULD send "supported_groups" to update the client's > >> view of its preferences. Clients MUST NOT act upon any information > >> found in "supported_groups" prior to successful completion of the > >> handshake, but MAY use the information learned from a successfully > >> completed handshake to change what groups they offer to a server in > >> subsequent connections. > > Are those supposed to be filtered to be subset of ones client advertised > > or not? E.g. if client didn't indicate support for x448, can the server > > still send x448? > > Requiring filtering would prevent the client from learning when the > server supports new schemes, but having the server not filter would > likely end up with the server "always" sending a big pile of stuff even > if the client has no idea that those schemes even exist. So, on the > balance, I would go with filtering. > > > > > > >> [[TODO: Recommendation about what the client offers. > >> Presumably which integer DH groups and which curves.]] > > Bit crazy algorithm: If you haven't heard of this server before, > > pick smallest you support, if you have, pick the one it selected > > the last time. > > It does make it clear that things are only as secure as the weakest > algorithm they will accept ... but stateless clients will also always > get that weakest link. (Okay, "smallest" does not necessarily equal > "weakest", but still.) With guidance on not supporting silly things, > this algorithm does not seem too crazy... > > > > >> ### Early Data Indication > >> > >> obfuscated_ticket_age > >> : The time since the client learned about the server configuration that > it is > >> using, in milliseconds. This value is added modulo 2^32 to with the > >> "ticket_age_add" value that was included with the ticket, see > >> {{NewSessionTicket}}. This addition prevents passive observers from > >> correlating sessions unless tickets are reused. Note: because ticket > >> lifetimes are restricted to a week, 32 bits is enough to represent any > >> plausible age, even in milliseconds. > > > > And the addition also prevents correlating session with its parent, > > even in case of reuse (this was the reason for switching to addition > > from XOR). > > > >> A server MUST validate that the ticket_age is within a small > >> tolerance of the time since the ticket was issued (see {{replay-time}}). > > Good luck with that... > > It would be good to not repeat the mistake that is the 5-minute replay > window in Kerberos. (So, shall we make "small tolerance" a concrete > value or otherwise give guidance? 5 seconds? 4xRTT? other? > But, IIRC, this check does not require absolute time agreement between > peers, only that their clocks advance at a similar rate. If your clock > steps because you slept your laptop and you have to fall back to a full > handshake, oh well. > > > Also, requirement that the server MUST proceed with the handshake and > > reject 0-RTT if that validation fails would be good here... > > Definitely. > > > Oh, still trial decryption... Got it. > > I had managed to previously forget how we ended up deciding on trial > decryption, but it basically was dkg commenting in the room at Buenos > Aires "are we writing a security protocol or a protocol that is > convenient to implement?" [with respect to the privacy/leakage from > having the alert or other signal be unencrypted]. > > > > >> #### Replay Properties {#replay-time} > >> > >> There are several potential sources of error that make an exact > >> measurement of time difficult. Variations in client and server clocks > >> are likely to be minimal, outside of gross time corrections. Network > >> propagation delays are most likely causes of a mismatch in legitimate > >> values for elapsed time. Both the NewSessionTicket and ClientHello > >> messages might be retransmitted and therefore delayed, which might be > >> hidden by TCP. > > I don't think variations in clocks are minimal... > > Just to check: you mean the rate at which clocks advance, and not the > absolute number reported as the time? > > > I wonder what 95% timeskew interval per day is... > > > > (Oh, and have fun with leap seconds!) > > It only matters how big the skew is relative to the acceptance window > and how long the ticket is valid for. Which brings us back to what the > acceptance window is measured in... > > >> ### Encrypted Extensions > >> > >> The same extension types MUST NOT appear in both the ServerHello and > >> EncryptedExtensions. If the same extension appears in both locations, > >> the client MUST rely only on the value in the EncryptedExtensions > >> block. All server-sent extensions other than those explicitly listed > >> in {{server-hello}} or designated in the IANA registry MUST only > >> appear in EncryptedExtensions. Extensions which are designated to > >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients > >> MUST check EncryptedExtensions for the presence of any forbidden > >> extensions and if any are found MUST terminate the handshake with an > >> "illegal_parameter" alert. > > This seems inconsistent. In implementation, I would write explicit > disjoint > > whitelists of extensions for both (and non-whitelisted one is a fatal > > error). Explicit whitelisting is safe even on client side, since the > > extensions are bounded by client-supported ones. > > You would have an explicit whitelist of all (including encrypted) > extensions for the server, so that it chokes when a client starts > sending a new one? Or just that it would not be considered for further > processing [and potential inclusion in ServerHello]? > > > > >> ## Random Number Generation and Seeding > >> > >> To estimate the amount of seed material being produced, add the number > of bits > >> of unpredictable information in each seed byte. For example, keystroke > timing > >> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure > bits > >> each, even though the total size of the counter value is 16 bits or > more. > >> Seeding a 128-bit PRNG would thus require approximately 100 such timer > values. > > This seems really obsolete. The timers have not been 18.2Hz for years, > and > > applications running on operating systems damn better use OS services for > > random numbers, given that anything else is fraught with peril. > > > > Sadly, there is a vocal minority of software implementors that insist > that the OS service is too slow and write their own. But I agree this > section needs some work; I may be able to contribute some text. > > > > >> # Overview of Security Properties {#security-analysis} > >> > >> [[TODO: This section is still a WIP and needs a bunch more work.]] > >> > >> A complete security analysis of TLS is outside the scope of this > document. > >> In this section, we provide an informal description the desired > properties > >> as well as references to more detailed work in the research literature > >> which provides more formal definitions. > >> > >> We cover properties of the handshake separately from those of the > record layer. > > I think properties of the exporter should be covered as well: > > I agree (but am unlikely to be able to contribute text). > > -Ben > > > - Is it intended to generate secret data (yes) > > - Is it intended to generate connection-unique data (yes) > > - Are values for different labels/contexts intended to be computationally > > independent (yes) > > > > > > (The TLS 1.2 exporter without EMS failed the middle requirement, > > creating security issues in applications that assumed the data was > > connection-unique. > > > > > > --001a1141308c754cc0053776d840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 1:31 PM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
On 07= /11/2016 11:16 PM, Ilari Liusvaara wrote:
> On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote:
>> Folks,
>>
>> I've just submitted draft-ietf-tls-tls13-14.txt and it should<= br> >> show up on the draft repository shortly. In the meantime you
>> can find the editor's copy in the usual location at:
>> As usual, comments welcome.
>> -Ekr
> Did a readthrough, here's a bunch of comments (didn't check th= e
> issues list):

Should we bulk-open issues for these so they don't get lost?=C2= =A0 I will
only cherry-pick a couple to reply to.

= I opened one giant issue because I haven't gone through this yet
<= div>
If you want to open individual issues that you think are= meritorious that woul dbe fine

-Ekr
=C2= =A0

> ----------------------------------------------------------------------= -
>
>> ###=C2=A0 Server Hello
>>
>> cipher_suite
>> : The single cipher suite selected by the server from the list in<= br> >>=C2=A0 =C2=A0ClientHello.cipher_suites.=C2=A0 For resumed sessions,= this field is
>>=C2=A0 =C2=A0the value from the state of the session being resumed.=
>>=C2=A0 =C2=A0[[TODO: interaction with PSK.]]
> Isn't this the true ciphersuite used on this connection, "res= umption"
> or not? Otherwise you can get into all sorts of crazy situations that<= br> > WILL be sources of implementation bugs.

It probably ought to be, yes.

> The idea that it isn't true ciphersuite brings me bad flashbacks a= bout
> TLS 1.2 ticket "maybe resume" craziness (except this would b= e even
> worse).

I feel like we had discussed what the resumption ciphersuite should = be
previously, but I don't seem to be able to find it in my mail archives.=

>
>> ### Negotiated Groups
>>
>> As of TLS 1.3, servers are permitted to send the "supported_g= roups"
>> extension to the client.=C2=A0 If the server has a group it prefer= s to the
>> ones in the "key_share" extension but is still willing t= o accept the
>> ClientHello, it SHOULD send "supported_groups" to update= the client's
>> view of its preferences.=C2=A0 Clients MUST NOT act upon any infor= mation
>> found in "supported_groups" prior to successful completi= on of the
>> handshake, but MAY use the information learned from a successfully=
>> completed handshake to change what groups they offer to a server i= n
>> subsequent connections.
> Are those supposed to be filtered to be subset of ones client advertis= ed
> or not? E.g. if client didn't indicate support for x448, can the s= erver
> still send x448?

Requiring filtering would prevent the client from learning when the<= br> server supports new schemes, but having the server not filter would
likely end up with the server "always" sending a big pile of stuf= f even
if the client has no idea that those schemes even exist.=C2=A0 So, on the balance, I would go with filtering.

>
>
>> [[TODO: Recommendation about what the client offers.
>> Presumably which integer DH groups and which curves.]]
> Bit crazy algorithm: If you haven't heard of this server before, > pick smallest you support, if you have, pick the one it selected
> the last time.

It does make it clear that things are only as secure as the weakest<= br> algorithm they will accept ... but stateless clients will also always
get that weakest link.=C2=A0 (Okay, "smallest" does not necessari= ly equal
"weakest", but still.)=C2=A0 With guidance on not supporting sill= y things,
this algorithm does not seem too crazy...

>
>> ### Early Data Indication
>>
>> obfuscated_ticket_age
>> : The time since the client learned about the server configuration= that it is
>>=C2=A0 =C2=A0using, in milliseconds.=C2=A0 This value is added modu= lo 2^32 to with the
>>=C2=A0 =C2=A0"ticket_age_add" value that was included wit= h the ticket, see
>>=C2=A0 =C2=A0{{NewSessionTicket}}.=C2=A0 This addition prevents pas= sive observers from
>>=C2=A0 =C2=A0correlating sessions unless tickets are reused.=C2=A0 = Note: because ticket
>>=C2=A0 =C2=A0lifetimes are restricted to a week, 32 bits is enough = to represent any
>>=C2=A0 =C2=A0plausible age, even in milliseconds.
>
> And the addition also prevents correlating session with its parent, > even in case of reuse (this was the reason for switching to addition > from XOR).
>
>> A server MUST validate that the ticket_age is within a small
>> tolerance of the time since the ticket was issued (see {{replay-ti= me}}).
> Good luck with that...

It would be good to not repeat the mistake that is the 5-minute repl= ay
window in Kerberos.=C2=A0 (So, shall we make "small tolerance" a = concrete
value or otherwise give guidance?=C2=A0 5 seconds?=C2=A0 4xRTT? other?
But, IIRC, this check does not require absolute time agreement between
peers, only that their clocks advance at a similar rate.=C2=A0 If your cloc= k
steps because you slept your laptop and you have to fall back to a full
handshake, oh well.

> Also, requirement that the server MUST proceed with the handshake and<= br> > reject 0-RTT if that validation fails would be good here...

Definitely.

> Oh, still trial decryption... Got it.

I had managed to previously forget how we ended up deciding on trial=
decryption, but it basically was dkg commenting in the room at Buenos
Aires "are we writing a security protocol or a protocol that is
convenient to implement?" [with respect to the privacy/leakage from having the alert or other signal be unencrypted].

>
>> #### Replay Properties {#replay-time}
>>
>> There are several potential sources of error that make an exact >> measurement of time difficult.=C2=A0 Variations in client and serv= er clocks
>> are likely to be minimal, outside of gross time corrections.=C2=A0= Network
>> propagation delays are most likely causes of a mismatch in legitim= ate
>> values for elapsed time.=C2=A0 Both the NewSessionTicket and Clien= tHello
>> messages might be retransmitted and therefore delayed, which might= be
>> hidden by TCP.
> I don't think variations in clocks are minimal...

Just to check: you mean the rate at which clocks advance, and not th= e
absolute number reported as the time?

> I wonder what 95% timeskew interval per day is...
>
> (Oh, and have fun with leap seconds!)

It only matters how big the skew is relative to the acceptance windo= w
and how long the ticket is valid for.=C2=A0 Which brings us back to what th= e
acceptance window is measured in...

>> ###=C2=A0 Encrypted Extensions
>>
>> The same extension types MUST NOT appear in both the ServerHello a= nd
>> EncryptedExtensions.=C2=A0 If the same extension appears in both l= ocations,
>> the client MUST rely only on the value in the EncryptedExtensions<= br> >> block.=C2=A0 All server-sent extensions other than those explicitl= y listed
>> in {{server-hello}} or designated in the IANA registry MUST only >> appear in EncryptedExtensions. Extensions which are designated to<= br> >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clie= nts
>> MUST check EncryptedExtensions for the presence of any forbidden >> extensions and if any are found MUST terminate the handshake with = an
>> "illegal_parameter" alert.
> This seems inconsistent. In implementation, I would write explicit dis= joint
> whitelists of extensions for both (and non-whitelisted one is a fatal<= br> > error). Explicit whitelisting is safe even on client side, since the > extensions are bounded by client-supported ones.

You would have an explicit whitelist of all (including encrypted) extensions for the server, so that it chokes when a client starts
sending a new one?=C2=A0 Or just that it would not be considered for furthe= r
processing [and potential inclusion in ServerHello]?

>
>> ## Random Number Generation and Seeding
>>
>> To estimate the amount of seed material being produced, add the nu= mber of bits
>> of unpredictable information in each seed byte. For example, keyst= roke timing
>> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 sec= ure bits
>> each, even though the total size of the counter value is 16 bits o= r more.
>> Seeding a 128-bit PRNG would thus require approximately 100 such t= imer values.
> This seems really obsolete. The timers have not been 18.2Hz for years,= and
> applications running on operating systems damn better use OS services = for
> random numbers, given that anything else is fraught with peril.
>

Sadly, there is a vocal minority of software implementors that insis= t
that the OS service is too slow and write their own.=C2=A0 But I agree this=
section needs some work; I may be able to contribute some text.

>
>> #=C2=A0 Overview of Security Properties {#security-analysis}
>>
>> [[TODO: This section is still a WIP and needs a bunch more work.]]=
>>
>> A complete security analysis of TLS is outside the scope of this d= ocument.
>> In this section, we provide an informal description the desired pr= operties
>> as well as references to more detailed work in the research litera= ture
>> which provides more formal definitions.
>>
>> We cover properties of the handshake separately from those of the = record layer.
> I think properties of the exporter should be covered as well:

I agree (but am unlikely to be able to contribute text).

-Ben

> - Is it intended to generate secret data (yes)
> - Is it intended to generate connection-unique data (yes)
> - Are values for different labels/contexts intended to be computationa= lly
>=C2=A0 =C2=A0independent (yes)
>
>
> (The TLS 1.2 exporter without EMS failed the middle requirement,
> creating security issues in applications that assumed the data was
> connection-unique.
>
>


--001a1141308c754cc0053776d840-- From nobody Tue Jul 12 14:28:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04E12D97C for ; Tue, 12 Jul 2016 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGnr-KOWBRKG for ; Tue, 12 Jul 2016 14:28:25 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3091712D9C5 for ; Tue, 12 Jul 2016 14:27:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 13012650F; Wed, 13 Jul 2016 00:27:44 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id V2n2Wfqbvwtn; Wed, 13 Jul 2016 00:27:43 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AD939289; Wed, 13 Jul 2016 00:27:43 +0300 (EEST) Date: Wed, 13 Jul 2016 00:27:40 +0300 From: Ilari Liusvaara To: Douglas Stebila Message-ID: <20160712212740.GC32363@LK-Perkele-V2.elisa-laajakaista.fi> References: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:28:27 -0000 On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote: > > On Jul 11, 2016, at 19:24, Andrei Popov wrote: > > > > Back to the question... > > One challenge with this is that exporters are often used to compare > > things. For instance, one side signs an exported value, the other > > validates the signature by independently exporting the same value. > > Getting different values for a particular exporter will cause some > > classes of things to fail in subtle ways. > > Agreed, this does create the possibility that the endpoints will export > different values at different times due to unsynchronized context > switches. It gets worse: KeyUpdate is explicitly designed to work even when arbitrarily unsynchronized and run behind app's back (the application never having to care for it). > However, we should compare this failure mode (which might cause two > "partnered" parties to not get the same exporter key) with the failure > mode if we use the same EKM for the whole session (which might cause > more parties than we expect to get the same exporter key). Fail-closed > versus fail-open. Also, I wouldn't expect rekeying occur very often at default. 24M records in bulk transfer is quite a bit of data (would require quite fast connection to do in a few hours even at full blast). And there is no recommendation on time-based rekeying (and Chacha can run as good as forever even on the fastest connections). So, even if rekey changed EKM, it likely would not save you if application misused exporters in way vulernable to this. Worth security consideration? Certainly. Also, why does post-handshake auth seemingly always use traffic_secret_0, instead say whatever happens to be the newest in forward (C->S) direction when the Finished is sent (that would be well-defined key)? -Ilari From nobody Tue Jul 12 14:43:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86EC12D9CC for ; Tue, 12 Jul 2016 14:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JELhc3GrB4dk for ; Tue, 12 Jul 2016 14:42:56 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 4D15512D1A2 for ; Tue, 12 Jul 2016 14:42:55 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so26282869ywb.2 for ; Tue, 12 Jul 2016 14:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5aaGJsLKNqURs9FeL6MhwyRauEdcAdIRjThh5PGd988=; b=bXvkFr7hNhNq16sFvMR3SEYdIFP+9/czPzjLa+0tJ6XOfYawioJUeiZiba8Ns8mDOR Krv7V3nY1ys5i9BaEabm1i2lcRmWDEBIqWIqvM7Uuq8+Za1vGl/maX6L2ew8vZLSZZEO 0GhLnIZfIktOvognZw4FiD6gbEvfZWGM4kqMzSkNaeq/0pfWMK5HOJW7NyfUwr/3k6uR W4BppvJkfNQY/puW5K2P7SgUuKY1DcBCyrXsWsrfoKM/OJ7Qj7V30oqBSVWCYpD0ZzKz ITWA12MDMCgMPIbeBXS8Y320YYECwVMa+usnwtPioLE4fvcbffThjxfP2WYPjXIDjJe+ 3Z4w== 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; bh=5aaGJsLKNqURs9FeL6MhwyRauEdcAdIRjThh5PGd988=; b=G44ez6iS5rSSWDxv4V6ffUdNzxCr4v2rAanMVOuwGbcyoLRaRCAYQ+WSczduZ9Zrw9 uWIfzUglCVNO3O3xcCKcQ5kz/DJMFyhUtK6duvKN2KzP7/7jCozztAcqda4TucQzHnrV kNBdYyAwDuSceSCNyJKlWBkKjNg8NiaEHjsWoo1IzAOTeC/KEx3p0rNvzPw97SQnerVU xo4xUfEYpXXsAYsXsZyNj3IRXUEstuCStYNmozDeNiAuti/wQD0+Lp5WYvgT8RJ0MxjW OLqwUe/fgMitzu9ClHXV8YyeMsb3F+PQS1bTJ64SDHKUstU2IHg5xs03sk8y5mDL9YIR u8Dw== X-Gm-Message-State: ALyK8tIegvOT1akllLv/hEE/yqAYTPQBx5ix4DWbnVGODkM1p/G37/cp43uaAqWyooWy2UexXpEIc62nslU8Tw== X-Received: by 10.13.201.134 with SMTP id l128mr3644647ywd.93.1468359774565; Tue, 12 Jul 2016 14:42:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 12 Jul 2016 14:42:15 -0700 (PDT) In-Reply-To: <20160712212740.GC32363@LK-Perkele-V2.elisa-laajakaista.fi> References: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> <20160712212740.GC32363@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 12 Jul 2016 14:42:15 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114e630ec44fba05377726af Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:42:59 -0000 --001a114e630ec44fba05377726af Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 2:27 PM, Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote: > > > On Jul 11, 2016, at 19:24, Andrei Popov > wrote: > > > > > > Back to the question... > > > One challenge with this is that exporters are often used to compare > > > things. For instance, one side signs an exported value, the other > > > validates the signature by independently exporting the same value. > > > Getting different values for a particular exporter will cause some > > > classes of things to fail in subtle ways. > > > > Agreed, this does create the possibility that the endpoints will export > > different values at different times due to unsynchronized context > > switches. > > It gets worse: KeyUpdate is explicitly designed to work even when > arbitrarily unsynchronized and run behind app's back (the application > never having to care for it). > > > > However, we should compare this failure mode (which might cause two > > "partnered" parties to not get the same exporter key) with the failure > > mode if we use the same EKM for the whole session (which might cause > > more parties than we expect to get the same exporter key). Fail-closed > > versus fail-open. > > Also, I wouldn't expect rekeying occur very often at default. 24M > records in bulk transfer is quite a bit of data (would require quite > fast connection to do in a few hours even at full blast). And there > is no recommendation on time-based rekeying (and Chacha can run > as good as forever even on the fastest connections). > > So, even if rekey changed EKM, it likely would not save you if > application misused exporters in way vulernable to this. > > > Worth security consideration? Certainly. > > > > Also, why does post-handshake auth seemingly always use traffic_secret_0, > instead say whatever happens to be the newest in forward (C->S) > direction when the Finished is sent (that would be well-defined key)? > Thinko. Filed an issue for this. https://github.com/tlswg/tls13-spec/issues/545 -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114e630ec44fba05377726af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 2:27 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On T= ue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote:
> > On Jul 11, 2016, at 19:24, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> >
> > Back to the question...
> > One challenge with this is that exporters are often used to compa= re
> > things.=C2=A0 For instance, one side signs an exported value, the= other
> > validates the signature by independently exporting the same value= .
> > Getting different values for a particular exporter will cause som= e
> > classes of things to fail in subtle ways.
>
> Agreed, this does create the possibility that the endpoints will expor= t
> different values at different times due to unsynchronized context
> switches.

It gets worse: KeyUpdate is explicitly designed to work even when arbitrarily unsynchronized and run behind app's back (the application never having to care for it).


> However, we should compare this failure mode (which might cause two > "partnered" parties to not get the same exporter key) with t= he failure
> mode if we use the same EKM for the whole session (which might cause > more parties than we expect to get the same exporter key).=C2=A0 Fail-= closed
> versus fail-open.

Also, I wouldn't expect rekeying occur very often at default. 24= M
records in bulk transfer is quite a bit of data (would require quite
fast connection to do in a few hours even at full blast). And there
is no recommendation on time-based rekeying (and Chacha can run
as good as forever even on the fastest connections).

So, even if rekey changed EKM, it likely would not save you if
application misused exporters in way vulernable to this.


Worth security consideration? Certainly.



Also, why does post-handshake auth seemingly always use traffic_secret_0, instead say whatever happens to be the newest in forward (C->S)
direction when the Finished is sent (that would be well-defined key)?

Thinko.

Filed an is= sue for this.
-Ekr
=C2=A0


-Ilari

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

--001a114e630ec44fba05377726af-- From nobody Tue Jul 12 17:41:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4012D0E1 for ; Tue, 12 Jul 2016 17:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3k9sgPTwHTo for ; Tue, 12 Jul 2016 17:41:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC712D541 for ; Tue, 12 Jul 2016 17:41:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B140F4336DF; Wed, 13 Jul 2016 00:41:02 +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 88C1C4336D8; Wed, 13 Jul 2016 00:41:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468370462; bh=EMLE3HfVeEbeY9CQiJm3SUKKeByTMyAp0XPE0vnnxj0=; l=4577; h=To:References:Cc:From:Date:In-Reply-To:From; b=I+zviFpfrFue8n5TqLgK/CcbVSHwk7FNb2JBl8lNPIwlSioR3IMx01SHS//Zz08Vk UIhVgpODy5/0El/a0bC17q5kJBQma2UORZYEbupRXHuHqJTHBJgv8rq7RVAMWnOT3U 8g4bAkFxfS/90pMVfe71qBRDe36aaK6xVJ/z0Ixw= 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 496841FC9B; Wed, 13 Jul 2016 00:41:02 +0000 (GMT) To: Ilari Liusvaara References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com> <20160712210732.GB32363@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <57858E1E.6040701@akamai.com> Date: Tue, 12 Jul 2016 19:41:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160712210732.GB32363@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:41:06 -0000 On 07/12/2016 04:07 PM, Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote: >> On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: >> >> Requiring filtering would prevent the client from learning when the >> server supports new schemes, but having the server not filter would >> likely end up with the server "always" sending a big pile of stuff even >> if the client has no idea that those schemes even exist. So, on the >> balance, I would go with filtering. > What would the client do with unknown groups anyway? Dump a message > to log? > Basically. One could contrive an example where the client software knew about something but didn't normally send it, but that seems too contrived to care about. > >>> Good luck with that... >> It would be good to not repeat the mistake that is the 5-minute replay >> window in Kerberos. (So, shall we make "small tolerance" a concrete >> value or otherwise give guidance? 5 seconds? 4xRTT? other? >> But, IIRC, this check does not require absolute time agreement between >> peers, only that their clocks advance at a similar rate. If your clock >> steps because you slept your laptop and you have to fall back to a full >> handshake, oh well. > In one piece of code I wrote, I pulled +-15s maximum (config can have > tighter limits) out of thin air... > > And, actually, since failing 0-RTT time check is just 1-RTT delay > (since in proper implementations it is not a fatal error). > Right, so we can be relatively stringent in our guidance. > >>>> #### Replay Properties {#replay-time} >>>> >>>> There are several potential sources of error that make an exact >>>> measurement of time difficult. Variations in client and server clocks >>>> are likely to be minimal, outside of gross time corrections. Network >>>> propagation delays are most likely causes of a mismatch in legitimate >>>> values for elapsed time. Both the NewSessionTicket and ClientHello >>>> messages might be retransmitted and therefore delayed, which might be >>>> hidden by TCP. >>> I don't think variations in clocks are minimal... >> Just to check: you mean the rate at which clocks advance, and not the >> absolute number reported as the time? > Correct. I should check the computers I have for what the tickrate > approximately is (one curious observation: rebooting computer changes > the tickrate(!)). I think I estimated 140ms/day drift for one of > those (the others can be way worse). > > However, the rate of change of the rate (2nd derivate of time reported > relative to "true time" (one can for all practical purposes ignore > SR and GR here)) should be small. > Hmm, I would expect this second derivative to be sensitive to things like the temperature of the oscillator (and thus not always small). >>> I wonder what 95% timeskew interval per day is... >>> >>> (Oh, and have fun with leap seconds!) >> It only matters how big the skew is relative to the acceptance window >> and how long the ticket is valid for. Which brings us back to what the >> acceptance window is measured in... > IIRC, maximum ticket validity is 7 days (but for some crappier clocks, > that can be lots of drift). > > But likely TCP delays and such can cause bigger errors than slightly- > bad clocks. Hence my question about whether some multiple of (estimated) RTT would be reasonable. >> You would have an explicit whitelist of all (including encrypted) >> extensions for the server, so that it chokes when a client starts >> sending a new one? Or just that it would not be considered for further >> processing [and potential inclusion in ServerHello]? > The opposite way: I would have client choke if server sends it extension > outside those lists (TLS 1.3 clients are already supposed to choke if > server sends them extension they don't know about, this is only extending > it to per-messages lists). That certainly makes sense. I thought you also wanted a whitelist for the server to use, and wasn't sure how that would work. >>> This seems really obsolete. The timers have not been 18.2Hz for years, and >>> applications running on operating systems damn better use OS services for >>> random numbers, given that anything else is fraught with peril. >>> >> Sadly, there is a vocal minority of software implementors that insist >> that the OS service is too slow and write their own. But I agree this >> section needs some work; I may be able to contribute some text. > I think "SHOULD" would be suitable. > Sure. -Ben From nobody Tue Jul 12 18:59:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595212DB94 for ; Tue, 12 Jul 2016 18:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RISK_FREE=2.804, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoVwdSvgJbzj for ; Tue, 12 Jul 2016 18:58:57 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2316912DB80 for ; Tue, 12 Jul 2016 18:58:56 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m101so33589211ioi.2 for ; Tue, 12 Jul 2016 18:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=nF5Z506qI6Gr29k3dNWtAaIMXvhvHhJ97AExj8MZm9s=; b=fkgU8zLacbMAMihLnB9GFHfUrHEQZi6eRTm3bYmeoNRJJesYIbqbn7M0I2yl9tjWZY iHPDmOePTx68ZxnfKRERqnLDn3eNs95LTSQtJnbYjf8PGwFsJ8kRdUBR8GSayqqPct42 zLXkTB4mX2j7i9j9H+b/T3ENwbjAVF9Jr4IRY= 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; bh=nF5Z506qI6Gr29k3dNWtAaIMXvhvHhJ97AExj8MZm9s=; b=SF/n5IhY/q73I9E5EvVX2HdFop5onK3R3jUZZJuC789ByJaWodUGZKBCfc33SHUQpM NSEbTDS/DjaMqyNxeoP+RIF9pfMi+7oH+ukDC0jFrx39nh8JbQgWtMm79Bfgy+bsMK/W ksx42EQAavgCwGxIetXdQ0kxPzNSJyXYhdhdpz05Q2Nu0x2iDGWhypvDMXCZQge7oodX S0xQ7gWWFv5giLkOgV6txyK9whSTOfZkU9D7SmJ0DOCl/6teZZUSrfNPoI4W/zZQgV3W OgLlwxighA/1qtmBAZZW5dmZSjl0vw55ALAoLsvnNhC49XUJ3AsxyjKPQtaUEGTtw6Kq 9xrQ== X-Gm-Message-State: ALyK8tJ7dLs44m2nvfy2S5yvnJ0h7c6Ndv4IHPvEhbmjB/ZkXhv79boBlH3bTFHgD0JK193pk2wdBQNI2AdIKwtV X-Received: by 10.107.13.82 with SMTP id 79mr6887224ion.97.1468375136138; Tue, 12 Jul 2016 18:58:56 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Wed, 13 Jul 2016 01:58:46 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fdb5e635cbc05377abaa8 Archived-At: Subject: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 01:58:58 -0000 --001a113fdb5e635cbc05377abaa8 Content-Type: text/plain; charset=UTF-8 Hey folks, I would like to remove the missing_extension MUSTs on the server side. Full justification in the PR. https://github.com/tlswg/tls13-spec/pull/544 On the client, it is perfectly feasible to mandate a particular alert value. The check is very straight-forward. On the server, however, this is a mistake. Servers do not necessarily have full information if not all advertised ciphers are known, and a natural implementation of the negotiation algorithm will not output this case. Even without this clause, the handshake is already required to fail, so there is no risk of invalid clients being deployed. Adding more complexity to an already hairy negotiation algorithm (the pseudocode I mentioned is incomplete) just to diagnose what is an invalid ClientHello anyway is not worth it. It buys too little for the complexity cost. David --001a113fdb5e635cbc05377abaa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey folks,

I would like to r= emove the missing_extension MUSTs on the server side. Full justification in= the PR.
http= s://github.com/tlswg/tls13-spec/pull/544

On the clie= nt, it is perfectly feasible to mandate a particular alert value. The check= is very straight-forward. On the server, however, this is a mistake. Serve= rs do not necessarily have full information if not all advertised ciphers a= re known, and a natural implementation of the negotiation algorithm will no= t output this case. Even without this clause, the handshake is already requ= ired to fail, so there is no risk of invalid clients being deployed.
<= div>
Adding more complexity to an already hairy negotiation a= lgorithm (the pseudocode I mentioned is incomplete) just to diagnose what i= s an invalid ClientHello anyway is not worth it. It buys too little for the= complexity cost.

David
--001a113fdb5e635cbc05377abaa8-- From nobody Tue Jul 12 19:52:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3982112B057 for ; Tue, 12 Jul 2016 19:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ytm_9QIkMpx2 for ; Tue, 12 Jul 2016 19:52:02 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C485B12D7BC for ; Tue, 12 Jul 2016 19:52:02 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i12so31236610ywa.1 for ; Tue, 12 Jul 2016 19:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Al0OSPBQav96AGQPnmDID+SIPUZh5A1CJifNETv4esI=; b=p0qmCgcoFS8OX5d8f+HBbtyRzpgty6ewkbHv9b6oX/ybJJcfeeGVJGSG1GsqgkpAAs zyNmH19Fz/4cJGjD8HmqS9P+C65dYFBw6bMUi1jaDX2j64Ji1EOfjNzW85hE0Ut9k3Gc KAw0Uu5mvUvp2MScuObbpvIscmBjMv4y2xDLCHX8tmzPHvTog2VVqyaf9unl2fayK+YN lh1XNC3qkcBEjHS/AkoFQQKiuVlMZJr8UbS2KPgKhNoJxq10tUjd2UW+95Zsn5wyx2Uy nLHA7dKK598AB3fa4IUC8fwvBA/ijBHAQ8n/MA4Ye28qS7HRVO6z2EsHUJfTGecNH0gU 47Ow== 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; bh=Al0OSPBQav96AGQPnmDID+SIPUZh5A1CJifNETv4esI=; b=R/4BEbBgfbpVFfQkFXVz70TREIPLITQNpAHj0FOXqNh993uaNggMsQdjksbG6szQOb HPBPcLUKFen+9Y/ISIvFlgVTS8XsFsOPTlTxZim6y9aRKygMSvUU14pEhg3ylWG6l0Bl x5JrvVRg4NCNRCzvN60f8JD70U814h++UTO41gOSpt5iKzIkvz5vTDmcuysaD7R59SGR ExZsSB2/+WzMIP0gIUaEkNpYwU5Nlelp80PmDmXm44u/ITxkIgiRejMK/0yeAFkirWOo VSVHifstUY8cMUKztcJlL65g/qtUfw+ptxqNsj9rawXwdDmRRqlIvt9Jq2vdX72r9Awc 0OeA== X-Gm-Message-State: ALyK8tKV0lOG9Ae1ngVTRy1/C0rIYT0c0N7+FphIHQKK0OAg2bl/icsbZWy+2nbROZZjCsTDBxBmw+WVJpvstg== X-Received: by 10.129.161.129 with SMTP id y123mr4597518ywg.214.1468378322037; Tue, 12 Jul 2016 19:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 12 Jul 2016 19:51:22 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 12 Jul 2016 19:51:22 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114f8db2482c2d05377b7835 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 02:52:04 -0000 --001a114f8db2482c2d05377b7835 Content-Type: text/plain; charset=UTF-8 I generally agree with David here. -Ekr P.S. Back in Seattle, we had rough consensus to change the alert requirements [0] so that you didn't have to send alerts, but if you sent an alert, you had to send alert X. That's been on the TODO list for a while but expect a PR soon. [0] https://github.com/tlswg/tls13-spec/issues/254 On Tue, Jul 12, 2016 at 6:58 PM, David Benjamin wrote: > Hey folks, > > I would like to remove the missing_extension MUSTs on the server side. > Full justification in the PR. > https://github.com/tlswg/tls13-spec/pull/544 > > On the client, it is perfectly feasible to mandate a particular alert > value. The check is very straight-forward. On the server, however, this is > a mistake. Servers do not necessarily have full information if not all > advertised ciphers are known, and a natural implementation of the > negotiation algorithm will not output this case. Even without this clause, > the handshake is already required to fail, so there is no risk of invalid > clients being deployed. > > Adding more complexity to an already hairy negotiation algorithm (the > pseudocode I mentioned is incomplete) just to diagnose what is an invalid > ClientHello anyway is not worth it. It buys too little for the complexity > cost. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114f8db2482c2d05377b7835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I generally agree with David here.


-Ekr

P.S. Back in Seattle, w= e had rough consensus to change the alert requirements [0] so that
you didn't have to send alerts, but if you sent an alert, you had to = send alert X. That's been
on the TODO list for a while but ex= pect a PR soon.


On Tue, Jul 12, 2016 at 6:58 PM, David Benjamin <davidben@chromium.= org> wrote:
Hey folks,

I would like to remove the missi= ng_extension MUSTs on the server side. Full justification in the PR.
<= a href=3D"https://github.com/tlswg/tls13-spec/pull/544" target=3D"_blank">h= ttps://github.com/tlswg/tls13-spec/pull/544

On the c= lient, it is perfectly feasible to mandate a particular alert value. The ch= eck is very straight-forward. On the server, however, this is a mistake. Se= rvers do not necessarily have full information if not all advertised cipher= s are known, and a natural implementation of the negotiation algorithm will= not output this case. Even without this clause, the handshake is already r= equired to fail, so there is no risk of invalid clients being deployed.

Adding more complexity to an already hairy negotiatio= n algorithm (the pseudocode I mentioned is incomplete) just to diagnose wha= t is an invalid ClientHello anyway is not worth it. It buys too little for = the complexity cost.

David

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


--001a114f8db2482c2d05377b7835-- From nobody Tue Jul 12 20:10:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156512D8B2 for ; Tue, 12 Jul 2016 20:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3684xe8JID1p for ; Tue, 12 Jul 2016 20:10:21 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 BF89212D7BC for ; Tue, 12 Jul 2016 20:10:20 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so31781828ywb.2 for ; Tue, 12 Jul 2016 20:10:20 -0700 (PDT) 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:cc :mime-version:content-transfer-encoding:message-id; bh=rS1eoe/54WQ9yhqqLMCLBdpUpF8GMedFAJU7L46RyHM=; b=D+3LC72Osnbv878F7049afZY0vo3bDFGU2UwSRP8vQ1clyzvKPyP4e7/rsm4AInmQh +SJwydcWNqW1hGDJf9xHYoAbHo2If8tT0zpXaeayyOILnFRXCYNuhx7rKZRYdpPmSMYa pDQy/5o55ffO9G20XpFiCXNFlP63xuRidLbFJ5mcLxl+eT6DGKfzwCKClT9JOYc98bhu SI0LGH+1paLjzCcbOFCedYkNq1nWadHqyzGLlHBYqopXMU0futyh4abUyygNmHN0gwDr XKZ8EEhjuMwIDyQnBWBIh2lWserlzNNyYOZQIVsihCb0ymHcWe2TwGj+KIys8uy9A6CH a/ng== 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:references :in-reply-to:cc:mime-version:content-transfer-encoding:message-id; bh=rS1eoe/54WQ9yhqqLMCLBdpUpF8GMedFAJU7L46RyHM=; b=C5w2fzSFLGlDK3GPqjY1LrBtzWPCJ03JIXb9XVv8s8hTHPNfH7ofhLgCuzRJ6JKrmQ ymngqMV5AmRaeNTIUbAHvcH+elcHyNNTU0zB+Z31Q+8nufbl8nd04dAcUKosVKtuH7Cf asN+WYorw6AtXHp+niFJCF3cUulYH+IDQaJRghBE7IIVcGevwU1TKNW64M+s/MH2x3+2 XbY8iUksuZEJBooGViqgDN0rPy91EWMHEG9GuShZkQ8YZ6BxsN0X1Cn83owjPFM20Kv/ Md//Lv81RkgHj0YVMK34DtA/cSZEgfCFEAe4peyDYIsliUoAtmcHDSnZ7LB0DS7NzBRT O3CQ== X-Gm-Message-State: ALyK8tLRsCcvYALln+ezDru+KqG68VvuiKODpovYO4buYfTX4MS/QYpm4VKClXqGmQZmqA== X-Received: by 10.129.130.195 with SMTP id s186mr4365572ywf.267.1468379420057; Tue, 12 Jul 2016 20:10:20 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w185sm793055ywe.45.2016.07.12.20.10.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jul 2016 20:10:19 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Tue, 12 Jul 2016 23:10:17 -0400 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: <201607122310.18021.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 03:10:22 -0000 On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote: > I would like to remove the missing_extension MUSTs on the server side. Full > justification in the PR. > https://github.com/tlswg/tls13-spec/pull/544 > > On the client, it is perfectly feasible to mandate a particular alert > value. The check is very straight-forward. On the server, however, this is > a mistake. Servers do not necessarily have full information if not all > advertised ciphers are known, and a natural implementation of the > negotiation algorithm will not output this case. Even without this clause, > the handshake is already required to fail, so there is no risk of invalid > clients being deployed. > > Adding more complexity to an already hairy negotiation algorithm (the > pseudocode I mentioned is incomplete) just to diagnose what is an invalid > ClientHello anyway is not worth it. It buys too little for the complexity > cost. Reporting errors sufficiently is not an inconsequential issue. TLS has many interop issues with servers which just stare blankly back when something goes wrong, or fail in ways which do not indicate why. This general topic has come up as a problem in discussions here before. We need to specify how to fail appropriately such that when it happens, it can actually be diagnosed and fixed easily. The alternative is people sticking with the status quo forever. The only way this adds complexity is if you assume you're only writing the client and server for themselves, not expecting to interop with unknown peers. First of all, as to not having "full information", I don't think anyone expects a server to be expected to pick the exact error alert if it can't even parse the cipher suites in question. When a server just skips over an unknown suite, if a missing_extension was technically correct for a server which could've understood it, then it doesn't really matter; the lack of that extension isn't what's causing the failure, as it never gets to that point. To respond to your pseudocode in the PR, I'd say that explaining the expectation is simpler with a try/catch model: just assume that the required extensions are present, do whatever you do, and throw a missing_extension exception to trigger said fatal alert if at any point that fails to be true. (if you're using a language that does not have exceptions, you can of course do the same thing, just differently; this model just makes stating things simple) The current wording in the draft has "and no alternative cipher suite is available" added in there, as selecting another suite that doesn't care about such a fault was agreed to be passable because requiring further validation after an acceptable suite+variables was already found was agreed to be excessive. However, we do not mean to imply that you should go _looking_ for an alternative if you're evaluating a suite and the required extension for it is missing. I would generally advise against adding workarounds for implementation flaws you've yet to actually encounter, as all you do is make it harder to detect and fix them when first created. Dave From nobody Tue Jul 12 20:22:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D768112D51A for ; Tue, 12 Jul 2016 20:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59SemSLnBx-V for ; Tue, 12 Jul 2016 20:22:11 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 47B3D12B008 for ; Tue, 12 Jul 2016 20:22:11 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j17so32334203ywg.0 for ; Tue, 12 Jul 2016 20:22:11 -0700 (PDT) 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-transfer-encoding:message-id; bh=XxUbxxMiX6i1NimfTCXeUT4ZANVJmrCyiZWpuwpQIEo=; b=tNv7c/9ZUcsSMKgSPXNV3c8gnMJ6J0X8nIxt32HMD0ML4OFQ2Ul6iuGMq9opuSXAqt RfNveuIetwNDCW0/4BVqJMNHyWTRIRr0FUMz3nnB23Lwhs49r+uJBE8iPo7UAqlIJTu3 aO0jFOtLYNVKgFyXD/j/e9OcmybWZ+asDW7u01iS0L9W26lUfQEt4Yzns5tVbFABGjXt 9kS3SVR2ke0Aj5Yvaxfs1sZEhFlxAeh0R+kmWrTGcypQ8Z+wRdxEmmcxPA+nkAadmGUN Nh/Ta0ASyd/ke//yVgRFbU1HufqpmlCs/Ovts/eqy+O+9RTZ2ZRv6mN13prHQmcB/Fcc SD7w== 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-transfer-encoding:message-id; bh=XxUbxxMiX6i1NimfTCXeUT4ZANVJmrCyiZWpuwpQIEo=; b=JWSruiasAkzpbEJDTRR81+UCiQgQVUJxvaE3NcTxVg+zLokE1strGW3uZFym4QhG2j iuRszx8b/qUT2zSWlpcKgB0Fb35+YvH/X12gamC8/BsL9LQeLME5I6E/mXAlbamZlMHE Y6iaCJg9sq1a4M4y2CTOO/Dhj7IvXDr4qXaTxJhW8791/zD0UDUfOF+F5NGa0FiGoyqf f7Q2FeFLXvDhAO3vU4EoEXyFDdEojBOpWqdFM+fW+FZAR8t2GWyYqdKo3l/4zIvczrSU mA3mLfLiWF1SfPVEFZleejgYUH70mFEeB72wnHVX6Wm29DzVkKFcYvswyZP0QEu/3VZ0 WPsg== X-Gm-Message-State: ALyK8tLWlopdK/IS4MwAe/kzKBfzQoWGMCl0iB85pQqj5evCz6h2kCDX+xVxkgVcPz/hQQ== X-Received: by 10.129.120.82 with SMTP id t79mr4196047ywc.51.1468380130549; Tue, 12 Jul 2016 20:22:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id i62sm3592252ywd.11.2016.07.12.20.22.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jul 2016 20:22:10 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 12 Jul 2016 23:22:08 -0400 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: <201607122322.08815.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 03:22:13 -0000 On Tuesday, July 12, 2016 10:51:22 pm Eric Rescorla wrote: > I generally agree with David here. > > -Ekr > > P.S. Back in Seattle, we had rough consensus to change the alert requirements [0] so that > you didn't have to send alerts, but if you sent an alert, you had to send alert X. That's been > on the TODO list for a while but expect a PR soon. > > [0] https://github.com/tlswg/tls13-spec/issues/254 I am aware that discussion ended up on accepting sloppy error reporting as acceptable. Changing the disputed missing_extension alerts to SHOULDs would be an acceptable compromise if that decision is still actually going through. Dave From nobody Tue Jul 12 21:18:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5D512D187 for ; Tue, 12 Jul 2016 21:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sDj7l7X6Mxc for ; Tue, 12 Jul 2016 21:18:29 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 8851E12B02B for ; Tue, 12 Jul 2016 21:18:29 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p74so33415045qka.0 for ; Tue, 12 Jul 2016 21:18:29 -0700 (PDT) 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; bh=MUcnXgmyFS6HQHqWPUg1kZ7TbIvOhMiDZMpkTWfONTY=; b=tD2zGQ0rImFJu9p3NjXvEda/7m3jUh0Xlgncg6B+qs/DqfSQ8QnhzHHhK6nI2u2DoQ EwDKMMRZYlqNQ9JMYSlbV+gcvm9ub2Hhgvy6E4je+gYsJ61wvtjRKgka75ARCRiiOclL LpPYhGLXJu7+LmhXFdbmEAlxZiUZaQRZ+LYYKl7EfMladB0d8o/OjJWy6FsoFyRJ99oN LcKDboGpiZVXe+LxN/3sk7942ftATIOhCPFt6mBkidyl5MMlaTRrr9qXhA08v7Z7KNP8 /yijQ800iJbeTr3EvXOTOejpoj9Mxi6zy6A4JZVF+4uArBu0ZQkuhwt5SHbCRySVdMqt VWWg== 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; bh=MUcnXgmyFS6HQHqWPUg1kZ7TbIvOhMiDZMpkTWfONTY=; b=AY2AESoCEeUO48SDeRqaVg43xX0gI/Kxe3uvuhT7krwVSWQ9xXOlCXWRHAZCa4EWKt 0GxwDhgGuFuUcE9LIVdZiBy2IowybtlebvTeOryVfM3mg83t2y8DC6ZGtQ+LHKVeCCnh YMVvUvPe/r3XUWgzVoNTgxBhb8x4Vz7V+IygyuZxJ5BFjiVDECCqBUQiHJbcKuVmbUJ1 UoKAs8aeIdOl/ifYKG4Zqh92NYiM7dE6KJlXwK2cXqXDPE17rajm6e04E96f9DD5MpAd KHhx5LSXuMSX7K6UDwyTh8kR37Dh0r5bU0Eoo07V5Y7YaBwuJhUjeTmFZfs4VXI8sVCp hXsA== X-Gm-Message-State: ALyK8tLk4iLz75EPEjb5g+Hi5BHp1RnVmyscE8xht0kawJEJTDc3/adTVKDG2tICBc2HDGhvuWD41WZ1S62+jw== X-Received: by 10.55.214.77 with SMTP id t74mr7879904qki.80.1468383508713; Tue, 12 Jul 2016 21:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Tue, 12 Jul 2016 21:18:28 -0700 (PDT) In-Reply-To: <201607122322.08815.davemgarrett@gmail.com> References: <201607122322.08815.davemgarrett@gmail.com> From: Martin Thomson Date: Wed, 13 Jul 2016 14:18:28 +1000 Message-ID: To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 04:18:31 -0000 On 13 July 2016 at 13:22, Dave Garrett wrote: > I am aware that discussion ended up on accepting sloppy error reporting as acceptable. Changing the disputed missing_extension alerts to SHOULDs would be an acceptable compromise if that decision is still actually going through. "sloppy" is a bit of a mischaracterization. There are good reasons for this decision. It allows implementations to be structured differently. In particular, if there are two relevant error conditions, different implementations could discover them in different orders. MUST-strength requirements on alerting for one of those conditions means that you have to order your checking in a particular way; MUST-strength requirements on multiple concurrent conditions are basically impossible to meet. It also allows an implementation to decide that abrupt cessation of communications is preferable to generating a report. That can be important for DoS mitigation. In the end, we concluded that you shouldn't lie about error conditions; if you determine that there is a missing extension and you decide to send an alert, then it has to be the missing_extension alert. David's PR goes to the core of the first of my reasons here. The ways in which servers decide on the things like version and cipher suite when presented with a ClientHello is in practice hugely different between implementations. That's healthy, but it does mean that we need flexibility. From nobody Tue Jul 12 22:24:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CDB12D094 for ; Tue, 12 Jul 2016 22:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi0hqh4j1F-g for ; Tue, 12 Jul 2016 22:24:05 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6B412B01B for ; Tue, 12 Jul 2016 22:24:05 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m101so36615768ioi.2 for ; Tue, 12 Jul 2016 22:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=byukqeAAnJI69lnSCY8iIKJXRuNQJmOTBOyJRYFOuK0=; b=TMnZOen++oekWsEogBZw3mEqvYUlNA7w3EJVlzZqvo2wCdoh/c5znQeLasHKckQ6Gv R9EmW5VXj8Pi8TPl3IJn33eJWdke/HGmuVhKimFk66uAVgIZ/2SMevqtOx40i1K9DYtz o/wMAzsNhFER/01PHUu1R6jLMV8eihCA411qwHVsRa0ctA1O1jeb3oYXXYBJi9fmIGX0 0572yIry96kxGB7meVkzs3FFiD63VlD8UYcvz17gwNtwr9lDA2t6Xmv37WqKQbQyXOCh dcwFQrVBHEAYEw0XszyvxFTn/XHoS+PJJMuI++5hWGAl5F5jc0RWM8pdfJ3vHK6Vn/1F 4zow== 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; bh=byukqeAAnJI69lnSCY8iIKJXRuNQJmOTBOyJRYFOuK0=; b=Z/DOHs0vs+5uo153QE091itu9x+QyE52PHUCH12YptE7JtpHLwwNP1Ic2+mrBvzlOC A8QfbQQ6wOx3ZEy6+h4QPRs3wowBeHbisRmWpgIW/D0foMsXt1/U6unrjToDt74ahb33 Qg4AMclL+Ak13yircgt6s0bKlYand3tlnhaSVoNFbKH2KynTsJVNlX6c0N317/ghMIXD H6Uwb01bGzRSFTEYe6qM6otXgDp7k5gbw0ATghCGCRl5JW+kjWHjh/lSI1dX6UPkXnle 5YEVym24L5XbcHAxlT6VoDt/L1x6b1ebZd/Kxg2+/zMWYfh9bSXQZ8TxsRs605V/ycC3 lesA== X-Gm-Message-State: ALyK8tI2e2YlxL0QScz0d9DTKjKZAlZodAGV0kiKz4nsiwJVlpbY63tbrDH9/yAgqCaH/dxKxhO2z7xYUS+PUFSu X-Received: by 10.107.128.25 with SMTP id b25mr7471117iod.110.1468387444262; Tue, 12 Jul 2016 22:24:04 -0700 (PDT) MIME-Version: 1.0 References: <201607122322.08815.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Wed, 13 Jul 2016 05:23:53 +0000 Message-ID: To: Martin Thomson , Dave Garrett Content-Type: multipart/alternative; boundary=001a113fb596025f0805377d9864 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 05:24:06 -0000 --001a113fb596025f0805377d9864 Content-Type: text/plain; charset=UTF-8 I'm also curious what cases were you envisioning missing_extension to be useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so I'm certainly not blind to TLS handshake errors being difficult to diagnose, especially on the client. But I don't believe such an alert would ever have helped me. Perhaps I am missing something? I don't believe an implementation which fails to send supported_groups, etc., in 1.3 would ever leave a developer's workstation. It would not interoperate with anything. Such a client is completely failing to implement the protocol, and in a way that nothing would work. Difficulties usually arise not here, but with more complex cases. Where we have interop against some peers, but not others. Where all protocol messages are legal but, due to different configurations on either end, no set of parameters could be found. Where the connection would have succeeded but for, say, a recent RC4 removal. If we wish to address the diagnosis problem, we should think about those, and also how to simplify negotiation so the kinds of errors are less complex and reporting them is simpler, rather than get distracted by trivialities. David On Wed, Jul 13, 2016 at 12:18 AM Martin Thomson wrote: > On 13 July 2016 at 13:22, Dave Garrett wrote: > > I am aware that discussion ended up on accepting sloppy error reporting > as acceptable. Changing the disputed missing_extension alerts to SHOULDs > would be an acceptable compromise if that decision is still actually going > through. > > "sloppy" is a bit of a mischaracterization. There are good reasons > for this decision. > > It allows implementations to be structured differently. In > particular, if there are two relevant error conditions, different > implementations could discover them in different orders. > MUST-strength requirements on alerting for one of those conditions > means that you have to order your checking in a particular way; > MUST-strength requirements on multiple concurrent conditions are > basically impossible to meet. > > It also allows an implementation to decide that abrupt cessation of > communications is preferable to generating a report. That can be > important for DoS mitigation. > > In the end, we concluded that you shouldn't lie about error > conditions; if you determine that there is a missing extension and you > decide to send an alert, then it has to be the missing_extension > alert. > > David's PR goes to the core of the first of my reasons here. The ways > in which servers decide on the things like version and cipher suite > when presented with a ClientHello is in practice hugely different > between implementations. That's healthy, but it does mean that we > need flexibility. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113fb596025f0805377d9864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also curious what cases were you envisioning missi= ng_extension to be useful. I spend a lot of my time triaging TLS-related bu= gs in Chrome, so I'm certainly not blind to TLS handshake errors being = difficult to diagnose, especially on the client. But I don't believe su= ch an alert would ever have helped me. Perh= aps I am missing something?

I don't believe a= n implementation which fails to send supported_groups, etc., in 1.3 would e= ver leave a developer's workstation. It would not interoperate with any= thing. Such a client is completely failing to implement the protocol, and i= n a way that nothing would work. Difficulties usually arise not here, but w= ith more complex cases. Where we have interop against some peers, but not o= thers.=C2=A0Where all protocol messages are legal but, due to different con= figurations on either end, no set of parameters could be found. Where the c= onnection would have succeeded but for, say, a recent RC4 removal.

If we wish to address the diagnosis problem, we should thi= nk about those, and also how to simplify negotiation so the kinds of errors= are less complex and reporting them is simpler, rather than get distracted= by trivialities.

David

On Wed, Jul 13, 2016 at 1= 2:18 AM Martin Thomson <martin.thomson@gmail.com> wrote:
On 13 July 2016 at 13:22, Dave Garrett <davemgarrett@gmail.com&g= t; wrote:
> I am aware that discussion ended up on accepting sloppy error reportin= g as acceptable. Changing the disputed missing_extension alerts to SHOULDs = would be an acceptable compromise if that decision is still actually going = through.

"sloppy" is a bit of a mischaracterization.=C2=A0 There are good = reasons
for this decision.

It allows implementations to be structured differently.=C2=A0 In
particular, if there are two relevant error conditions, different
implementations could discover them in different orders.
MUST-strength requirements on alerting for one of those conditions
means that you have to order your checking in a particular way;
MUST-strength requirements on multiple concurrent conditions are
basically impossible to meet.

It also allows an implementation to decide that abrupt cessation of
communications is preferable to generating a report.=C2=A0 That can be
important for DoS mitigation.

In the end, we concluded that you shouldn't lie about error
conditions; if you determine that there is a missing extension and you
decide to send an alert, then it has to be the missing_extension
alert.

David's PR goes to the core of the first of my reasons here.=C2=A0 The = ways
in which servers decide on the things like version and cipher suite
when presented with a ClientHello is in practice hugely different
between implementations.=C2=A0 That's healthy, but it does mean that we=
need flexibility.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113fb596025f0805377d9864-- From nobody Wed Jul 13 00:31:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060112B019 for ; Wed, 13 Jul 2016 00:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s1tFk5bp52T for ; Wed, 13 Jul 2016 00:31:55 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 A2A7012B007 for ; Wed, 13 Jul 2016 00:31:55 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id i12so35361227ywa.1 for ; Wed, 13 Jul 2016 00:31:55 -0700 (PDT) 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-transfer-encoding:message-id; bh=GcNXv9YoHG8rt7Iv3JQJakFxGMb0kxAdo+JhEZH4TjU=; b=TfHuTAqrCFp3EzsZ2xEgBis7Vxe6g5jhWqleolUi3I5/1u8W0gCLU0bFLDCpO0pR7A Lx4SQGLGrZ4k3VjPCDoUaxAMIQCzqFd/g4/dOEu5gZbVD7ARuvI1MZYpendidrN8ApoV 9ty7eN+7icHMBwMNlQRfR3u7WbdKmjWBBqNYQ86tMTdAUziZ/8pP75WtmRUJGVjgA8Lj IH8LglP27suPXxqJglKTAY4mYz4emF8otZrWUUrhjGpjxXIAYTfRWSF3btsuhdrXrxqY 6raoA28dJW+guiyoPRspFX2qTCHuXZelUUdvrhtrnPF5QWU5B1rD29PG7gWDwdoa00wL 0XTA== 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-transfer-encoding:message-id; bh=GcNXv9YoHG8rt7Iv3JQJakFxGMb0kxAdo+JhEZH4TjU=; b=P89DT387HD3ZeOClqYXXrfYjQtQkxk55yHrmuCuIGIS+i27Y9sK7+Q5BF3NNn1UxX4 wy7mbmSqY5NivccEcpJ7yp2stHMsZvXhj1nJ+5jrz2oNyeie3esHZ/jZkESc0nurlvex 61CknJCOHzNJWftmRHK8BQdSmFsZ15lkX/sHCTT5UCVAVcb37R64X/2820LHiCdv+Kdl UbV3qmfRKVWYXBAfOLcTlwygr8KIzfmzprxBAIpESt6TnYVlugJrQYBQK0brml1V4YA3 nbsdgy7inZNiBDZsX0OPvMRhG/AzaASIF9JUNIP/Id03ygvwthqHAKoPBtgvRxItjqHZ W8iQ== X-Gm-Message-State: ALyK8tJqAea3eHpaR5XrPVhAQjxSQvLDTWAq543fzcG03aCUnNbzdotHQuEhjuzQd2c1/A== X-Received: by 10.13.206.65 with SMTP id q62mr4824369ywd.25.1468395114866; Wed, 13 Jul 2016 00:31:54 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id z185sm1290688ywe.33.2016.07.13.00.31.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 00:31:54 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Wed, 13 Jul 2016 03:31:52 -0400 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: <201607130331.52980.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 07:31:57 -0000 On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote: > I'm also curious what cases were you envisioning missing_extension to be > useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so > I'm certainly not blind to TLS handshake errors being difficult to > diagnose, especially on the client. But I don't believe such an alert would > ever have helped me. Perhaps I am missing something? I've triaged TLS-related bugs in Firefox (to be fair, not as much as of late), which largely made me come to the conclusion that stricter and more precise error handling is sorely needed. I make no claim that this particular error in this particular case is the focal point on which anything practical I can come up with at the moment hinges, however I have seen too much nonsense to not advocate for rigorous preventive action. When we leave holes and generic responses in specs, the incomprehensible litany of implementations inevitably results in interactions that we are not capable of predicting. To be clear though, completely mandatory extensions, at least as we're doing them here, are a new thing. TLS 1.2 relied on separate messages for stuff, but we're front-loading everything into the ClientHello to get reliable 1RTT (with the exception of HRR). > I don't believe an implementation which fails to send supported_groups, > etc., in 1.3 would ever leave a developer's workstation. It would not > interoperate with anything. Such a client is completely failing to > implement the protocol, and in a way that nothing would work. We have to assume that some small minority of implementors are not acting in good faith to maintain ideal security, but rather are creating something just functional enough for their specific purpose (possibly a larger minority with IoT). If someone kludges an ad hoc client/server pair that skips the groups extension to go straight to key share, they could get it to work fine. (they're only separate because we are, ourselves, kludging in new features into an old extension, whilst maintaining backwards compatibility) If someone else then has to get this to work with a normal server, they're going to have to let this slide. It is a hell of a lot easier (from a psychological & political perspective) to just kludge in a special case instead of being forced to explicitly cancel out error checks/reporting that come directly from the spec. The more this stuff is left unspecified, the more risk we get of kludge-related breakage/exploits. As a rule, I never assume something is impossible; you can always be surprised by the interactions of several kludges and a few lazy, sloppy, stupid, or malicious people. This is a 20 year old mess; paranoia is required. > If we wish to address the diagnosis problem, we should think about those, > and also how to simplify negotiation so the kinds of errors are less > complex and reporting them is simpler, rather than get distracted by > trivialities. I agree we should simplify negotiation, wholeheartedly. That is most certainly a better way to do things. I preferred we just require groups and key share for all TLS 1.3+ hellos, always, without exception. Much simpler, but pure-PSK (which I'd prefer was not in the spec) is the special case that complicates things here, and merging the two systems into one simpler one was rejected. (one always mandatory dh/psk key specification extension that is always used requires far less thought to sanity check) Just because a better system isn't used, doesn't mean I won't advocate for stop-loss on what we do go with, however. To restate what I said in my other reply, downgrading the relevant MUSTs to SHOULDs would be something I'd be ok with. Servers MUST give an appropriate error when aborting, and SHOULD give the most relevant one they can provide at that time. I do not claim that this here specifically is of top-tier importance, but I will generally resist all attempts to water-down constraints we had previously maintained consensus for. Dave From nobody Wed Jul 13 03:55:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE8212D790 for ; Wed, 13 Jul 2016 03:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9fuvWNSXJaJ for ; Wed, 13 Jul 2016 03:55:27 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0091.outbound.protection.outlook.com [23.103.200.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E0B12D789 for ; Wed, 13 Jul 2016 03:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2rB3g0PD7aB1L0ykSmPJjiRdJ1ZpN0qmba3SH9ju/wY=; b=IeLZEBWxWH1Pcc74UiJJQbGqf/pHZ8Xm8zfCo/ugxNrwuDBlEN5RdXHehwenYwopbLnbw2cDdQyqZtQrYCsnWeiiMUtwCxr5BnAsrt/fWiWfDMW3n64lWSS+QPz4hEJ7ihIBMf8K9KTANY0Hn85GTgNSSx7dXCPjJY01Kgss+ig= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0172.namprd09.prod.outlook.com (10.255.192.150) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 10:55:26 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Wed, 13 Jul 2016 10:55:25 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYCAAEqKAP//wbAAAAq3xoAAGN/cgA== Date: Wed, 13 Jul 2016 10:55:24 +0000 Message-ID: References: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> In-Reply-To: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: afdf1d07-cd67-4fbb-d9a8-08d3ab0c31ac x-microsoft-exchange-diagnostics: 1; BN1PR09MB0172; 6:qm8of+KS7U6/D9i6SNvljE94Jx5qKG9CWAcvZNOoJ0GBUljWuiGw1bsPh79mczSdCA4zdCjyMX3bcQRL4ldBE/8O1AgE44WIj9SqyQGF2e3UDAAhC9Q4afMQYOt9498T9/OMCWCxPd1qt0c61Euq3K6vEtofmvrprnYAZMiIwhEqaCCnBx2FP6dv6oeDhrpS3iCVk8xqze7bA8hOH39Iu/5vX1/HLNyEXna/mIV+Y2ABPQLogTUx5saPQz7DvpHcemeM6/3yh/swaN7PNC9JsR3ocFpMz5cRS5s7In21VIjBP/irPayYpZQUX+n89Ilr+G4NGAhxGyjjdPM5kmgZ6g==; 5:PioaTPSr2yGaR6JeGV61DcU4CaFSrFvwQqr3tfhV+pPPP28fNrQIkrmBvHzLA37roQMXwdc7acWvMGkRkdYQUXI8zMZJxxRDA4icXwMqzbMBJDLP8248sUwgUnYCT/7uuylSQS6Dzse3axyPTcJIdQ==; 24:GVrgIoE4kDN/YEV2YjhbXZ0IP+S9aApOiMSANI2N9bT9mbPPYqu4h5eUqE+ysW0d5aMfkWfECvrS+F71C+iIyz8a5zV9SP5eQ91A8z8WxGo=; 7:fHi9ylOADLc4E/5I5rVdfBs++I1yeVdzeL1gVEJ7aBwTxZobETh41p813hKG4OCImvlUJ6uW+QaWJfuM/MKz59x1S4FuF78jAKCj/30z8lRtDs7hO9c0NMVftRtYNx2mv3Buo8/YibTP0lrtrm+7XuAoabpwaCDwSMIW1uNr/9Ta2AR37aY6ETN5J6Z3XkMG84Qlf3LFPXceP2EphJHFhgpQmrq3h3Qb09dlsUtSk3qtdZusJqcTiSoYM2oo0PKF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0172; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0172; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0172; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(6116002)(102836003)(3846002)(87936001)(586003)(81166006)(8676002)(99286002)(81156014)(2906002)(8936002)(230783001)(3660700001)(3280700002)(10400500002)(86362001)(2900100001)(4326007)(19580405001)(19580395003)(93886004)(4001450100002)(106116001)(2950100001)(36756003)(105586002)(5001770100001)(66066001)(5002640100001)(68736007)(50986999)(83506001)(7736002)(7846002)(305945005)(97736004)(92566002)(54356999)(189998001)(8666005)(76176999)(106356001)(101416001)(4001350100001)(77096005)(122556002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0172; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: <61504B300487DB4D92AB69B543F9F0C1@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 10:55:24.6049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0172 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:55:29 -0000 R29vZCBtb3JuaW5nIEtlbm55LA0KDQpPbiA3LzEyLzE2LCAzOjAzIFBNLCAiUGF0ZXJzb24sIEtl bm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQoNCj5IaSwNCj4NCj4+IE9u IDEyIEp1bCAyMDE2LCBhdCAxODo1NiwgRGFuZywgUXV5bmggKEZlZCkgPHF1eW5oLmRhbmdAbmlz dC5nb3Y+IHdyb3RlOg0KPj4gDQo+PiBIaSBLZW5ueSwgDQo+PiANCj4+PiBPbiA3LzEyLzE2LCAx OjM5IFBNLCAiUGF0ZXJzb24sIEtlbm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4NCj4+ Pndyb3RlOg0KPj4+IA0KPj4+IEhpDQo+Pj4gDQo+Pj4+IE9uIDEyLzA3LzIwMTYgMTg6MTIsICJE YW5nLCBRdXluaCAoRmVkKSIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3RlOg0KPj4+PiANCj4+ Pj4gSGkgS2VubnksIA0KPj4+PiANCj4+Pj4+IE9uIDcvMTIvMTYsIDE6MDUgUE0sICJQYXRlcnNv biwgS2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPg0KPj4+Pj53cm90ZToNCj4+Pj4+ IA0KPj4+Pj4gSGkNCj4+Pj4+IA0KPj4+Pj4+IE9uIDEyLzA3LzIwMTYgMTY6MTIsICJEYW5nLCBR dXluaCAoRmVkKSIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+PiAN Cj4+Pj4+PiBIaSBLZW5ueSwNCj4+Pj4+PiANCj4+Pj4+PiBJIHN1cHBvcnQgdGhlIHN0cm9uZ2Vz dCBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBub3Rpb24gbWVudGlvbmVkIGluICgqKQ0KPj4+Pj4+IGFi b3ZlLCBidXQgaW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQgcHJvdmlkZSBnb29kIGRlc2NyaXB0aW9u IHRvIHRoZQ0KPj4+Pj4+IHVzZXJzLg0KPj4+Pj4gDQo+Pj4+PiBPSywgSSB0aGluayBub3cgd2Ug YXJlIGF0IHRoZSBoZWFydCBvZiB5b3VyIGFyZ3VtZW50LiBZb3Ugc3VwcG9ydCBvdXINCj4+Pj4+ IGNob2ljZSBvZiBzZWN1cml0eSBkZWZpbml0aW9uIGFuZCBtZXRob2Qgb2YgYW5hbHlzaXMgYWZ0 ZXIgYWxsLg0KPj4+Pj4gDQo+Pj4+PiBBbmQgd2UgY2FuIGFncmVlIHRoYXQgZ29vZCBkZXNjcmlw dGlvbnMgY2FuIG9ubHkgaGVscC4NCj4+Pj4+IA0KPj4+Pj4+IFRoYXQgaXMgd2h5IEkgc3VwcG9y dCB0aGUgbGltaXQgYXJvdW5kIDJeMzggcmVjb3Jkcy4NCj4+Pj4+IA0KPj4+Pj4gSSBkb24ndCBz ZWUgaG93IGNoYW5naW5nIDJeMjQuNSAod2hpY2ggaXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQpIHRv DQo+Pj4+PjJeMzgNCj4+Pj4+IHByb3ZpZGVzIGEgYmV0dGVyIGRlc2NyaXB0aW9uIHRvIHVzZXJz Lg0KPj4+Pj4gDQo+Pj4+PiBBcmUgeW91IHdvcnJpZWQgdGhleSB3b24ndCBrbm93IHdoYXQgYSBk ZWNpbWFsIGluIHRoZSBleHBvbmVudCBtZWFucz8NCj4+Pj4+IA0KPj4+Pj4gT3IsIG1vcmUgc2Vy aW91c2x5LCBhcmUgeW91IHNheWluZyB0aGF0IDJeey0zMn0gZm9yIHNpbmdsZSBrZXkNCj4+Pj4+ YXR0YWNrcw0KPj4+Pj4gaXMNCj4+Pj4+IGEgYmlnIGVub3VnaCBzZWN1cml0eSBtYXJnaW4/IElm IHNvLCBjYW4geW91IHNheSB3aGF0IHRoYXQncyBiYXNlZA0KPj4+Pj5vbj8NCj4+Pj4gDQo+Pj4+ IEl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvIGFzayBwZW9wbGUgdG8gcmVrZXkgdW5uZWNlc3Nh cmlseS4gMSBpbg0KPj4+PjJeMzINCj4+Pj4gaXMNCj4+Pj4gMSBpbiA0LDI5NCw5NjcsMjk2IGZv ciB0aGUgaW5kaXN0aW5ndWlzaGFiaWxpdHkgYXR0YWNrLg0KPj4+IA0KPj4+IEkgd291bGQgYWdy ZWUgdGhhdCBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIGFzayBUTFMgcGVlcnMgdG8gcmVrZXkN Cj4+PiB1bm5lY2Vzc2FyaWx5LiBJIGFsc28gYWdyZWUgdGhhdCAxIGluIDJeMzIgaXMNCj4+PiAx IGluIDQsMjk0LDk2NywyOTYuIFN1cmUgbG9va3MgbGlrZSBhIGJpZywgc2NhcnkgbnVtYmVyLCBk b24ndCBpdD8NCj4+PiANCj4+PiBBcmUgeW91IHRoZW4gYXJndWluZyB0aGF0IDJeey0zMn0gZm9y IHNpbmdsZSBrZXkgYXR0YWNrcyBpcyBhIGJpZw0KPj4+ZW5vdWdoDQo+Pj4gc2VjdXJpdHkgbWFy Z2luIGJlY2F1c2Ugd2Ugd2FudCB0byBhdm9pZCByZWtleWluZz8NCj4+IA0KPj4gQmVjYXVzZSBp dCBpcyBzYWZlIHRoZXJlZm9yZSB0aGVyZSBhcmUgbm8gbmVlZHMgdG8gcmVrZXkuDQo+DQo+Q291 bGQgeW91IGRlZmluZSAic2FmZSIsIHBsZWFzZT8gU2FmZSBmb3Igd2hhdD8gRm9yIHdob20/DQo+ DQo+QWdhaW4sIHdoeSBhcmUgeW91IGNob29zaW5nIDJeLTMyIGZvciB5b3VyIHNlY3VyaXR5IGJv dW5kPyBXaHkgbm90IDJeLTQwDQo+b3IgZXZlbiAyXi0yND8gV2hhdCdzIHlvdXIgcmF0aW9uYWxl PyBJcyBpdCBqdXN0IGZpbmdlciBpbiB0aGUgYWlyLCBvciBkbw0KPnlvdSBoYXZlIGEgdGhyZWF0 IGFuYWx5c2lzLCBvciAuLi4/DQoNCkkgc2FpZCBpdCBpcyBzYWZlIGJlY2F1c2UgdGhlIGNoYW5j ZSBvZiAxIGluIDQsMjk0LDk2NywyOTYgcHJhY3RpY2FsbHkNCmRvZXMgbm90IGhhcHBlbi4gSSBh bSBub3QgaW50ZXJlc3RlZCBpbiB0YWxraW5nIGFib3V0IG90aGVyIG51bWJlcnMgYW5kDQpvdGhl ciBxdWVzdGlvbnMuIA0KDQo+PiBJIGRvbqn2dA0KPj4gcmVjb21tZW5kIHRvIHJ1biBhbm90aGVy IGZ1bmN0aW9uL3Byb3RvY29sIHdoZW4gdGhlcmUgYXJlIG5vIG5lZWRzIGZvcg0KPj5pdC4NCj4+ IEkgZG9uqfZ0IHNlZSBhbnkgcGFydGljdWxhciByZWFzb25zIGZvciBtZW50aW9uaW5nIHNpbmds ZSBrZXkgaW4gdGhlDQo+PiBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBhdHRhY2sgaGVyZS4NCj4+IA0K Pg0KPlRoZW4gcGxlYXNlIHJlYWQgYSBsaXR0bGUgZnVydGhlciBpbnRvIHRoZSBub3RlIHRoYXQg cHJlc2VudHMgdGhlDQo+YW5hbHlzaXM6IGEgY29uc2VydmF0aXZlIGJ1dCBnZW5lcmljIGFwcHJv YWNoIGRpY3RhdGVzIHRoYXQsIHdoZW4gdGhlDQo+YXR0YWNrZXIgaGFzIG11bHRpcGxlIGtleXMg dG8gYXR0YWNrLCB3ZSBzaG91bGQgbXVsdGlwbHkgdGhlIHNlY3VyaXR5DQo+Ym91bmRzIGJ5IHRo ZSBudW1iZXIgb2YgdGFyZ2V0IGtleXMuDQo+DQo+QSBiZXR0ZXIgYW5hbHlzaXMgZm9yIEFFUy1H Q00gbWF5IGV2ZW50dWFsbHkgYmUgZm9ydGhjb21pbmcgYnV0IHdlIGRvbid0DQo+aGF2ZSBpdCB5 ZXQuIA0KPg0KPj4+IFRoZW4gZG8geW91IGhhdmUgYQ0KPj4+IHNwZWNpZmljIGNvbmNlcm4gYWJv dXQgdGhlIHNlY3VyaXR5IG9mIHJla2V5aW5nPyBJIGNvdWxkIHNlZSB2YXJpb3VzDQo+Pj53YXlz DQo+Pj4gaW4gd2hpY2ggaXQgbWlnaHQgZ28gd3JvbmcgaWYgbm90IGRlc2lnbmVkIGNhcmVmdWxs eS4NCj4+PiANCj4+PiBPciBhcmUgeW91IGRpcmVjdGx5IGxpbmtpbmcgYSBmdW5kYW1lbnRhbCBz ZWN1cml0eSBxdWVzdGlvbiB0byBhbg0KPj4+IG9wZXJhdGlvbmFsIG9uZSwgYnkgd2hpY2ggSSBt ZWFuOiBhcmUgeW91IHNheWluZyB3ZSBzaG91bGQgdHJhZGUNCj4+PnNlY3VyaXR5DQo+Pj4gZm9y IGF2b2lkaW5nIHRoZSAiY29zdCIgb2YgcmVrZXlpbmcgZm9yIHNvbWUgbm90aW9uIG9mICJjb3N0 Ij8gSWYgc28sDQo+Pj5jYW4NCj4+PiB5b3UgcXVhbnRpZnkgdGhlIGNvc3QgZm9yIHRoZSB1c2Ug Y2FzZXMgdGhhdCBtYXR0ZXIgdG8geW91Pw0KPg0KPkknZCBsb3ZlIHRvIGhhdmUgeW91ciBhbnN3 ZXIgdG8gdGhlc2UgcXVlc3Rpb25zLiBJIGRpZG4ndCBzZWUgb25lIHlldC4NCj5XaGF0IGlzIHRo ZSBjb3N0IG1ldHJpYyB5b3UncmUgdXNpbmcgYW5kIGhvdyBkb2VzIGl0IHF1YW50aXR5IGZvciB5 b3VyDQo+dXNlIGNhc2VzPw0KDQpBZ2FpbiwgSSBhbSBub3QgaW50ZXJlc3RlZCBpbiBvdGhlciBx dWVzdGlvbnMuIEkgc3VnZ2VzdGVkIHRoZSBudW1iZXINCmFib3V0IDJeMzggcmVjb3JkcyBiZWNh dXNlIGl0IGlzIGEgc2FmZSBkYXRhIGJvdW5kIGJlY2F1c2UgRXJpYyBwdXQgaW4gaGlzDQp0bHMg MS4zIGRyYWZ0IHRoZSBudW1iZXIgMl4yNC41IHdoaWNoIGlzIHVubmVjZXNzYXJpbHkgc21hbGwu DQoNCllvdXIgcGFwZXIgaXMgYSBuaWNlIG9uZSB3aGljaCBnaXZlcyB1c2VycyBnb29kIGluZm9y bWF0aW9uIGFib3V0IGNob2ljZXMuDQoNCj4NCj5DaGVlcnMsDQo+DQo+S2VubnkNCj4NCj4+PiAN Cj4+PiBDaGVlcnMsDQo+Pj4gDQo+Pj4gS2VubnkNCj4+IA0KPj4gUmVnYXJkcywNCj4+IFF1eW5o Lg0KDQpSZWdhcmRzLA0KUXV5bmguIA0KPj4gDQo+PiANCj4+IA0KPj4gDQoNCg== From nobody Wed Jul 13 04:09:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87112DD97 for ; Wed, 13 Jul 2016 04:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5w3kLVGdlI9 for ; Wed, 13 Jul 2016 04:09:39 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28C612DD99 for ; Wed, 13 Jul 2016 04:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OTXAMH3u6ljJ9o70zExPKCGxutHW5PFHL+o8yhDRrv0=; b=dwgpEuFEbPefCBNmtMx0/0BxP9hRUdr0yykGoE6qLzPo9sabWvApClZiNKaV18tBXP97+dhTkcTrFyJrvwqXLF9RvWuEPeFjy9Mk0r1/xMoMJ3VVlQohlxqyZ3+CypTBnkk3ERqb7yZWyJFYJOPJeXBcgGFT4WYAzQZH/Ytn9mg= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0172.namprd09.prod.outlook.com (10.255.192.150) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 11:09:37 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Wed, 13 Jul 2016 11:09:37 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYCAAEqKAP//wbAAAAq3xoAAGV7SgA== Date: Wed, 13 Jul 2016 11:09:36 +0000 Message-ID: References: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> In-Reply-To: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 1f2fcc9d-bf5d-4e77-0abb-08d3ab0e2d91 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0172; 6:fmTCRVWo9dG7e8cGe7sMakdch8BonZCvXNG4iKmj62+oxhFHjo+Yw1rBrM6MkoYKJy33GCoQvYCRbDhfB58NHZDGC6R5AIanoYB3/FddrIK+Sy9bFWPYV+S39kVh05w7M+3n4yH22AQEgjPKsPLX1u9Bh4frtC8U5ivvkP2/DmwPh2epdMvJPjQxScTLrTapKiCfdOmAlNCD2Mqe/ZQmBFnL1TMFjBukpiTVT5WkdvXSRrvatBcUBeYM5bnDx9VEo3Dklrusn4xfCUTXZQtGENr8IWhYfymCxOmyeOuzi/Ykm+XOYc7LR+3dNJf05XagWEkgEW6VjfQlhrS6feh6/A==; 5:eWOv6WRrOAXOynElk2FtOkFx+zp3ycEGnmT5wHhltShu2vMTvKxL2D0vcJH8FARlnLrqDvIR9p5CFWiIbmm1i/bc7NrYtPcGOMsFFfJYpcxH5EeqPk4NXMjth3/S12U5Alegv1KDjlkaNW8FRR5FoA==; 24:WKhluecOcO/F7FF9TDaAJE7jIQHcPHkjfjy76kl8s4xSyEuPsDRxmhxn2Yt/UQiJSit1bTdh01MTS63OzXl4Gi0ye+68FhqRmrq6c3s+vBg=; 7:7+3oP54IPhq4qD4X107bknf/fmO4jGtdyIp+++4PBDjw2uDHYOtpHiuruU1RN1MqcwJAEc178KDLr4VfHDZ+tPCuaS4Wdy5hXfFuNOwyvHoe3ZtEvO/MurXSkQkww5eIM/GrS6OQZgQzaFtXBchf0dc6nqWtc8XC2e7XkffKEPChu/bxKHD2AErGy46b/2rNsiwfz6gsI1Ssi7w2Zwf016Vr/00P3FgMVEUb+HYA++2e1MEnO6btDC8FJn94Twwv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0172; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0172; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0172; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(199003)(377454003)(189002)(83506001)(7736002)(7846002)(305945005)(11100500001)(5001770100001)(66066001)(36756003)(2950100001)(105586002)(68736007)(5002640100001)(50986999)(97736004)(101416001)(106356001)(4001350100001)(77096005)(122556002)(92566002)(8666005)(76176999)(189998001)(54356999)(8676002)(99286002)(3846002)(87936001)(586003)(6116002)(102836003)(81166006)(10400500002)(2900100001)(4326007)(86362001)(93886004)(4001450100002)(106116001)(19580395003)(19580405001)(81156014)(2906002)(3280700002)(230783001)(3660700001)(8936002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0172; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: <7311BCBCF532BE44BA46BA3572101010@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 11:09:36.3861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0172 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:09:41 -0000 SGkgS2VubnksIA0KDQpPbiA3LzEyLzE2LCAzOjAzIFBNLCAiUGF0ZXJzb24sIEtlbm55IiA8S2Vu bnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQoNCj5IaSwNCj4NCj4+IE9uIDEyIEp1bCAy MDE2LCBhdCAxODo1NiwgRGFuZywgUXV5bmggKEZlZCkgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdy b3RlOg0KPj4gDQo+PiBIaSBLZW5ueSwgDQo+PiANCj4+PiBPbiA3LzEyLzE2LCAxOjM5IFBNLCAi UGF0ZXJzb24sIEtlbm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4NCj4+Pndyb3RlOg0K Pj4+IA0KPj4+IEhpDQo+Pj4gDQo+Pj4+IE9uIDEyLzA3LzIwMTYgMTg6MTIsICJEYW5nLCBRdXlu aCAoRmVkKSIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3RlOg0KPj4+PiANCj4+Pj4gSGkgS2Vu bnksIA0KPj4+PiANCj4+Pj4+IE9uIDcvMTIvMTYsIDE6MDUgUE0sICJQYXRlcnNvbiwgS2Vubnki IDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPg0KPj4+Pj53cm90ZToNCj4+Pj4+IA0KPj4+Pj4g SGkNCj4+Pj4+IA0KPj4+Pj4+IE9uIDEyLzA3LzIwMTYgMTY6MTIsICJEYW5nLCBRdXluaCAoRmVk KSIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBI aSBLZW5ueSwNCj4+Pj4+PiANCj4+Pj4+PiBJIHN1cHBvcnQgdGhlIHN0cm9uZ2VzdCBpbmRpc3Rp bmd1aXNoYWJpbGl0eSBub3Rpb24gbWVudGlvbmVkIGluICgqKQ0KPj4+Pj4+IGFib3ZlLCBidXQg aW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQgcHJvdmlkZSBnb29kIGRlc2NyaXB0aW9uIHRvIHRoZQ0K Pj4+Pj4+IHVzZXJzLg0KPj4+Pj4gDQo+Pj4+PiBPSywgSSB0aGluayBub3cgd2UgYXJlIGF0IHRo ZSBoZWFydCBvZiB5b3VyIGFyZ3VtZW50LiBZb3Ugc3VwcG9ydCBvdXINCj4+Pj4+IGNob2ljZSBv ZiBzZWN1cml0eSBkZWZpbml0aW9uIGFuZCBtZXRob2Qgb2YgYW5hbHlzaXMgYWZ0ZXIgYWxsLg0K Pj4+Pj4gDQo+Pj4+PiBBbmQgd2UgY2FuIGFncmVlIHRoYXQgZ29vZCBkZXNjcmlwdGlvbnMgY2Fu IG9ubHkgaGVscC4NCj4+Pj4+IA0KPj4+Pj4+IFRoYXQgaXMgd2h5IEkgc3VwcG9ydCB0aGUgbGlt aXQgYXJvdW5kIDJeMzggcmVjb3Jkcy4NCj4+Pj4+IA0KPj4+Pj4gSSBkb24ndCBzZWUgaG93IGNo YW5naW5nIDJeMjQuNSAod2hpY2ggaXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQpIHRvDQo+Pj4+PjJe MzgNCj4+Pj4+IHByb3ZpZGVzIGEgYmV0dGVyIGRlc2NyaXB0aW9uIHRvIHVzZXJzLg0KPj4+Pj4g DQo+Pj4+PiBBcmUgeW91IHdvcnJpZWQgdGhleSB3b24ndCBrbm93IHdoYXQgYSBkZWNpbWFsIGlu IHRoZSBleHBvbmVudCBtZWFucz8NCj4+Pj4+IA0KPj4+Pj4gT3IsIG1vcmUgc2VyaW91c2x5LCBh cmUgeW91IHNheWluZyB0aGF0IDJeey0zMn0gZm9yIHNpbmdsZSBrZXkNCj4+Pj4+YXR0YWNrcw0K Pj4+Pj4gaXMNCj4+Pj4+IGEgYmlnIGVub3VnaCBzZWN1cml0eSBtYXJnaW4/IElmIHNvLCBjYW4g eW91IHNheSB3aGF0IHRoYXQncyBiYXNlZA0KPj4+Pj5vbj8NCj4+Pj4gDQo+Pj4+IEl0IHdvdWxk IG5vdCBtYWtlIHNlbnNlIHRvIGFzayBwZW9wbGUgdG8gcmVrZXkgdW5uZWNlc3NhcmlseS4gMSBp bg0KPj4+PjJeMzINCj4+Pj4gaXMNCj4+Pj4gMSBpbiA0LDI5NCw5NjcsMjk2IGZvciB0aGUgaW5k aXN0aW5ndWlzaGFiaWxpdHkgYXR0YWNrLg0KPj4+IA0KPj4+IEkgd291bGQgYWdyZWUgdGhhdCBp dCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIGFzayBUTFMgcGVlcnMgdG8gcmVrZXkNCj4+PiB1bm5l Y2Vzc2FyaWx5LiBJIGFsc28gYWdyZWUgdGhhdCAxIGluIDJeMzIgaXMNCj4+PiAxIGluIDQsMjk0 LDk2NywyOTYuIFN1cmUgbG9va3MgbGlrZSBhIGJpZywgc2NhcnkgbnVtYmVyLCBkb24ndCBpdD8N Cj4+PiANCj4+PiBBcmUgeW91IHRoZW4gYXJndWluZyB0aGF0IDJeey0zMn0gZm9yIHNpbmdsZSBr ZXkgYXR0YWNrcyBpcyBhIGJpZw0KPj4+ZW5vdWdoDQo+Pj4gc2VjdXJpdHkgbWFyZ2luIGJlY2F1 c2Ugd2Ugd2FudCB0byBhdm9pZCByZWtleWluZz8NCj4+IA0KPj4gQmVjYXVzZSBpdCBpcyBzYWZl IHRoZXJlZm9yZSB0aGVyZSBhcmUgbm8gbmVlZHMgdG8gcmVrZXkuDQo+DQo+Q291bGQgeW91IGRl ZmluZSAic2FmZSIsIHBsZWFzZT8gU2FmZSBmb3Igd2hhdD8gRm9yIHdob20/DQo+DQo+QWdhaW4s IHdoeSBhcmUgeW91IGNob29zaW5nIDJeLTMyIGZvciB5b3VyIHNlY3VyaXR5IGJvdW5kPyBXaHkg bm90IDJeLTQwDQo+b3IgZXZlbiAyXi0yND8gV2hhdCdzIHlvdXIgcmF0aW9uYWxlPyBJcyBpdCBq dXN0IGZpbmdlciBpbiB0aGUgYWlyLCBvciBkbw0KPnlvdSBoYXZlIGEgdGhyZWF0IGFuYWx5c2lz LCBvciAuLi4/DQo+DQo+PiBJIGRvbqn2dA0KPj4gcmVjb21tZW5kIHRvIHJ1biBhbm90aGVyIGZ1 bmN0aW9uL3Byb3RvY29sIHdoZW4gdGhlcmUgYXJlIG5vIG5lZWRzIGZvcg0KPj5pdC4NCj4+IEkg ZG9uqfZ0IHNlZSBhbnkgcGFydGljdWxhciByZWFzb25zIGZvciBtZW50aW9uaW5nIHNpbmdsZSBr ZXkgaW4gdGhlDQo+PiBpbmRpc3Rpbmd1aXNoYWJpbGl0eSBhdHRhY2sgaGVyZS4NCj4+IA0KPg0K PlRoZW4gcGxlYXNlIHJlYWQgYSBsaXR0bGUgZnVydGhlciBpbnRvIHRoZSBub3RlIHRoYXQgcHJl c2VudHMgdGhlDQo+YW5hbHlzaXM6IGEgY29uc2VydmF0aXZlIGJ1dCBnZW5lcmljIGFwcHJvYWNo IGRpY3RhdGVzIHRoYXQsIHdoZW4gdGhlDQo+YXR0YWNrZXIgaGFzIG11bHRpcGxlIGtleXMgdG8g YXR0YWNrLCB3ZSBzaG91bGQgbXVsdGlwbHkgdGhlIHNlY3VyaXR5DQo+Ym91bmRzIGJ5IHRoZSBu dW1iZXIgb2YgdGFyZ2V0IGtleXMuDQoNCkkgZG9uoa90IHRoaW5rIG11bHRpcGxlIHRhcmdldCBr ZXlzIGhlbHAgdGhlIGRhdGEgY29tcGxleGl0eSBpbiB0aGUgY29udGV4dA0Kb2YgVExTIGhlcmUg Zm9yIHRoZSBkaXN0aW5ndWlzaGluZyBhdHRhY2suIExldKGvcyBsb29rIGF0IHR3byBzaXR1YXRp b25zIGluDQptdWx0aXBsZSBrZXlzIGluIFRMUy4NCg0KMSkgRGlmZmVyZW50IGRhdGEgc2V0cyB3 aXRoIGRpZmZlcmVudCBrZXlzIGFuZCB0aGVpciByZXNwZWN0aXZlIGJvdW5kIHN1Y2gNCmFzIDJe MzggcmVjb3JkczogKGsxLCBkYXRhc2V0MSwgMl4zOCksoaYuLihrMTAsIGRhdGFzZXQxMCwgMl4z OCkuDQoNClRoZSBhdHRhY2tlciBoYXMgMTAgdGltZXMgbW9yZSBjaGFuY2VzIG9mIHN1Y2Nlc3Mg d2l0aCAxMCB0aW1lcyBtb3JlIGRhdGENCmNvbXBsZXhpdHkuDQoNCjIpIFRoZSBzYW1lIGRhdGEg c2V0IHdpdGggZGlmZmVyZW50IGtleXM6IChrMSwgZGF0YXNldCwgMl4zOCksoaYuLCAoazEwLA0K ZGF0YXNldCwgMl4zOCkuDQoNCkV2ZW4gdGhvdWdoLCB0aGUgc2FtZSBkYXRhIHNldCBpcyB1c2Vk IHdpdGggZGlmZmVyZW50IGtleXMsIHRoZSBkYXRhDQpjb21wbGV4aXR5IGlzIDEwIHRpbWVzIG1v cmUgaW4gb3JkZXIgZm9yIHRoZSBhdHRhY2tlciB0byBoYXZlIDEwIHRpbWVzDQptb3JlIGxpa2Vs eSB0byBzdWNjZWVkLg0KDQpSZWdhcmRzLA0KUXV5bmguIA0KDQoNCg0KPiANCg0K From nobody Wed Jul 13 04:14:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD112D79D for ; Wed, 13 Jul 2016 04:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cJe4TXwOvXg for ; Wed, 13 Jul 2016 04:14:42 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0095.outbound.protection.outlook.com [23.103.200.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF0B12DDE3 for ; Wed, 13 Jul 2016 04:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lu1GjsSb6KueibSCaT1el8cIfuy0JF7mp1UJFq8h30k=; b=ue3Y/6U4hX3I1B+fxQE6HVydZeL+qWKWbogRhY1rYJH+OiQTnwtWNQSLsiRIhiXbcKVVqAx1nTRFkDEEFJdWSFjTFijkKi6kTqjcOr+1/EUqRT9Hpr9gseXqfcOVWUyuafqq8zB8c2wzRK5K24Zw8kOcRWWbQPmdsHy24mBTlUo= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0169.namprd09.prod.outlook.com (10.255.192.147) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 11:14:14 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Wed, 13 Jul 2016 11:14:14 +0000 From: "Dang, Quynh (Fed)" To: Atul Luykx , "Scott Fluhrer (sfluhrer)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAATFUAgAANRgD//8XVgIAARoOAgAANwgCAABz0gIAAvyMA Date: Wed, 13 Jul 2016 11:14:13 +0000 Message-ID: References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> In-Reply-To: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: ff66d80f-14c6-4f1a-fdb7-08d3ab0ed2b0 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0169; 6:ZSC1YR8eE9zAsykvQFVWLIzBaz/jd+1VzeniRTRjymivnuD+t15pQDMIFteN8s8FCWoUMS6qx+fIp9Z0P5pHlU8lji30AOJ8NfGtSlE9L7rVVufFX44Ftvq0ifb2tBG5ldrQzEaY2kCe4pgfWVudp1Y0M8vMF3yHrI/HNXt7Yp+TiLeU8k5Iiybci3Kr8ugJ+uAiIkbMs9XpDG7a08pFwe0nBYTWNjJ8+C21/JVSplebd4cU6wk4Y0zWwBjNvqtfjpeso3IEj31QQTOBuQhghZP5tfPFdDrzvxJ3yYIG8uOwh70Fw/f3n5eJr8JTvYMjGhK9TfiF1tbWtr904AhaLQ==; 5:IZmv9q02JieJNJQd/Zchoagt0uGLhyXkV4IuA6jqZDXRkk+QlMEjBc+DhJEXLvwpTkLWJlMAd8ViPCu7rz6AlykeptGEPNlTGANRoFm7OVRZ69LHCPNxKjwvW+YY6T1Gn/BWWf8y134gaFnUkEA3sA==; 24:pZcfZ9Ssl2e2JQDeFZVvqO310ABQEE2O6mVUNIoQj9q/eUL/yOWcaprafH+JUbpZ9Yy4AMTcjcakmaOSFtGjgJ/STGHUtTpuB4Al0FNJJR4=; 7:5us34OX1ddmCsTYbfmd32jJE53u+53+9xgZbw4403ei8BtJ7O6drJ4evajSPXHy6lFxk+CWW9aZqFxURaWhUmuWuOemYssqgMFJM4pZ270DoHAWCH1TvbjJjUOqLqm1W4HTCXMfb7xDZIitXomZa6j51wyOhtCPpEDMQ8fwFWPJ+b948opt32swVsh02Ugt9PMqt6cxGtJtfv4lhd5dnVIc8G4EX9CQncx5+oruYUtgcaK/+ZumvnysZvhrp4XhH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0169; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB0169; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0169; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(24454002)(199003)(13464003)(377424004)(377454003)(189002)(105586002)(102836003)(77096005)(36756003)(2900100001)(5002640100001)(10400500002)(6116002)(106356001)(2950100001)(4326007)(50986999)(101416001)(2906002)(8936002)(189998001)(106116001)(76176999)(15975445007)(230783001)(3846002)(54356999)(99286002)(4001350100001)(11100500001)(97736004)(5001770100001)(68736007)(92566002)(87936001)(66066001)(19580405001)(305945005)(122556002)(8666005)(7846002)(19580395003)(83506001)(586003)(93886004)(8676002)(81166006)(3660700001)(86362001)(81156014)(3280700002)(7736002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0169; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <3D1D9F8278902E4EA57F9A81294AB739@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 11:14:13.9427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0169 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:14:45 -0000 Hi Atul,=20 On 7/12/16, 3:50 PM, "Atul Luykx" wrote: >> To be clear, this probability is that an attacker would be able to >> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential >> (but incorrect) plaintext, and with probability 2^{-32}, be able to >> determine that this plaintext was not the one used for the ciphertext >> (and with probability 0.999999999767..., know nothing about whether >> his guessed plaintext was correct or not). > >You need to be careful when making such claims. There are schemes for >which when you reach the birthday bound you can perform partial key >recovery. > >The probabilities we calculated guarantee that there won't be any >attacks (with the usual assumptions...). Beyond the bounds, there are no >guarantees. In particular, you cannot conclude that one, for example, >loses 1 bit of security once beyond the birthday bound. How can one use the distinguishing attack with the data complexity bound I suggested for recovering 1 bit of the encryption key in the context of TLS ?=20 Regards, Quynh.=20 > >Atul > >On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>> -----Original Message----- >>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>> Sent: Tuesday, July 12, 2016 1:17 PM >>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>> tls@ietf.org >>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>=20 >>> Hi >>>=20 >>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote: >>>=20 >>> >Hi Kenny, >>> > >>> >On 7/12/16, 12:33 PM, "Paterson, Kenny" >>> wrote: >>> > >>> >>Finally, you write "to come to the 2^38 record limit, they assume >>>that >>> >>each record is the maximum 2^14 bytes". For clarity, we did not >>> >>recommend a limit of 2^38 records. That's Quynh's preferred number, >>> >>and is unsupported by our analysis. >>> > >>> >What is problem with my suggestion even with the record size being the >>> >maximum value? >>>=20 >>> There may be no problem with your suggestion. I was simply trying to >>> make it >>> clear that 2^38 records was your suggestion for the record limit and >>> not ours. >>> Indeed, if one reads our note carefully, one will find that we do not >>> make any >>> specific recommendations. We consider the decision to be one for the >>> WG; >>> our preferred role is to supply the analysis and help interpret it if >>> people >>> want that. Part of that involves correcting possible misconceptions >>> and >>> misinterpretations before they get out of hand. >>>=20 >>> Now 2^38 does come out of our analysis if you are willing to accept >>> single key >>> attack security (in the indistinguishability sense) of 2^{-32}. So in >>> that limited >>> sense, 2^38 is supported by our analysis. But it is not our >>> recommendation. >>>=20 >>> But, speaking now in a personal capacity, I consider that security >>> margin to be >>> too small (i.e. I think that 2^{-32} is too big a success >>> probability). >>=20 >> To be clear, this probability is that an attacker would be able to >> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential >> (but incorrect) plaintext, and with probability 2^{-32}, be able to >> determine that this plaintext was not the one used for the ciphertext >> (and with probability 0.999999999767..., know nothing about whether >> his guessed plaintext was correct or not). >>=20 >> I'm just trying to get people to understand what we're talking about. >> This is not "with probability 2^{-32}, he can recover the plaintext" >>=20 >>=20 >>>=20 >>> Regards, >>>=20 >>> Kenny >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 13 04:51:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57012DECF for ; Wed, 13 Jul 2016 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9K08feI90wW for ; Wed, 13 Jul 2016 04:51:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F6312DE93 for ; Wed, 13 Jul 2016 04:51:31 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87F0412E05F; Wed, 13 Jul 2016 11:51:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DBpSoi020559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 07:51:29 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jul 2016 13:51:28 +0200 Message-ID: <4743747.aJSUQRlHeP@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.5.7-202.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: <57855399.70201@akamai.com> References: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1638506.2UfQhpHZdG"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Jul 2016 11:51:30 +0000 (UTC) Archived-At: Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:51:33 -0000 --nextPart1638506.2UfQhpHZdG Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 12 July 2016 15:31:21 Benjamin Kaduk wrote: > >> ### Encrypted Extensions > >> > >> The same extension types MUST NOT appear in both the ServerHello a= nd > >> EncryptedExtensions. If the same extension appears in both locati= ons, > >> the client MUST rely only on the value in the EncryptedExtensions > >> block. All server-sent extensions other than those explicitly lis= ted > >> in {{server-hello}} or designated in the IANA registry MUST only > >> appear in EncryptedExtensions. Extensions which are designated to > >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clie= nts > >> MUST check EncryptedExtensions for the presence of any forbidden > >> extensions and if any are found MUST terminate the handshake with = an > >> "illegal_parameter" alert. >=20 > > This seems inconsistent. In implementation, I would write explicit = disjoint > > whitelists of extensions for both (and non-whitelisted one is a fat= al > > error). Explicit whitelisting is safe even on client side, since th= e > > extensions are bounded by client-supported ones. >=20 > You would have an explicit whitelist of all (including encrypted) > extensions for the server, so that it chokes when a client starts > sending a new one? Or just that it would not be considered for furth= er > processing [and potential inclusion in ServerHello]? >=20 I'd rather not see a mechanism that will introduce TLS extension intole= rance in compliant implementations. IMNSHO this is the uncommon situation where a blacklist is the correct solution =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 --nextPart1638506.2UfQhpHZdG 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 iQIcBAABCgAGBQJXhitAAAoJEJKo0bgB0vX1+J4P/3/oMl36hj4mRln6nLBJFZjf 5sJRLhNN9rzIvBa8F/UqspmeELq8gRR+8sJ9WtLPJgUgnQZ56vkInh0SpI5DZZen CMVo5Gl7t+GGchQ8AUEMTEDToujWSQvjCG8CwAP5h3FWh6RPNv4FfnUcsL2m4+oV 5CHWK8oyaw/jXjgRCQhmUn6Yq1XpU0ULQE/+ZjhOO5vMl/5eK6ZCbScnGsXMBFYJ r+eBb2Y8FdiYorylq6888yL0M2frz+hHH9BLMdEpM/zAE1IVKchNmZ1QdwbNV+8v 5Ob7hw6QcTH4jGp+npUv2bq6SsCGVOUt8Za+hVl4R5OCdW6B1X0o3jW6jPeIE5+d CI/Xm2UtzwZP4iGGWrOzbmF5NifVg+QCSkf6Tq84h0idw/yxhNDaLq2zosIsIDh/ VgOHUqO2M5SUmINwFu7HJfMp2mkUbjmMtzVCLufoiG5EGXSC6Iv9x18lqM/+FmUF vkIdcuHugoK/kowTZhMzGm4wTgMddjhAHV9nMUars0OKrm6dOtFbI+r79JZI3ljc LSuxYqjpdsp9WIKzFbt/otF9BYxuB+eptTqH5f1Pky3q0dMp3h46hPjJqlOStZkU iVC6WgmnMULMw/MadMsWi1G4IX3rrjNE0S/0D/D0K5iipVvmaLa9Qj5BVJzUsyx3 TZMKNnH9Ql5XXEYHMeuc =Wq1m -----END PGP SIGNATURE----- --nextPart1638506.2UfQhpHZdG-- From nobody Wed Jul 13 05:12:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4321E12DF17 for ; Wed, 13 Jul 2016 05:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9yeKnsE9v0m for ; Wed, 13 Jul 2016 05:12:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C72A12DF1C for ; Wed, 13 Jul 2016 05:12:41 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF2FE3E2A4; Wed, 13 Jul 2016 12:12:40 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DCCddb005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 08:12:40 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jul 2016 14:12:39 +0200 Message-ID: <209780076.Yzkn8lymcZ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.5.7-202.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart146848134.jTCUAlIU8A"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Jul 2016 12:12:41 +0000 (UTC) Archived-At: Cc: David Benjamin Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:12:43 -0000 --nextPart146848134.jTCUAlIU8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > I don't believe an implementation which fails to send supported_group= s, > etc., in 1.3 would ever leave a developer's workstation. It would not= > interoperate with anything. it would interoperate with itself, and for some deployments that's enou= gh of a passing grade... (Even if you do interoperatbility testing you do not check all possible permutations of features and settings) I wholeheartedly agree with Dave here, error definitions should be stri= ct (both on the when and what to do). One, because it allows to better diagnose (in general, maybe not in this specific situation) problems. Two, because you can write a strict negative test case that actually checks for it. =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 --nextPart146848134.jTCUAlIU8A 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 iQIcBAABCgAGBQJXhjA3AAoJEJKo0bgB0vX1J10P/jL0NkebW2Nv2RrNLGS9JPyt dcgqJfMVhE1Oa+obJEbWDEnB/aIOfPiIakWaAZv4vOYqgPLUr0+DFHGK29NldsdN QsA4D+u45QXiGDQOJxUVkbkACMQjHzf/HWpqfmQCMMkzHgOQ/A371FniCwu+60cS 5PPjhCsCm6Bdfk8lM0W77hZYg0iN0UWzF0h9geiIxm7+KYKs1OaKPBjFMzKaypIo 2q7dI1HokGBf+5zZIy8vMC30a9+dSA35g/y3J3Ed3lU2HkXuSC7FuAKjyb+PHq+c r3ZRRw2KZdTP0MkPgfPOytjn5kz6vfBnC1Jj2KiT9/vMewHt8E0GKgWqs78X/KU9 fQuGiWTuMEa6lAJ6lkVAsFFN+ug/N8Ku4Cc4DKTAxigrBynhkxGFW1sicQnNvHD9 idi1arBPAbB4n7pWGn02qcKZ9o2SfGhiyYquqllenNXPL8UfH9PHkNrZZk73MC27 33uDT5MmWsdik2rcLB7WrL1wqRrwcehYG9QHFhnTH90HZ+9ROia8mFKL81aWjQPW 4mRKySuYlsGchboreFj9NwZKcg7gwceHVxLn3JA/W+hB273I17eFg1oYtdTud9kQ FJCGKkfjKEvDkVBkx62qtLT4XmGhanytWB11SmxgOW/RXFBXk1YJHooVwT4/NzHq SOqMs4ZTXeLDac5VCxBC =sQud -----END PGP SIGNATURE----- --nextPart146848134.jTCUAlIU8A-- From nobody Wed Jul 13 05:30:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD2412D7A4 for ; Wed, 13 Jul 2016 05:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK-MqgnKWH4N for ; Wed, 13 Jul 2016 05:30:35 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 7D40412DDC4 for ; Wed, 13 Jul 2016 05:30:34 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: CB1C5138034.A270A X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id CB1C5138034 for ; Wed, 13 Jul 2016 14:30:26 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 66521403B; Wed, 13 Jul 2016 14:30:25 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 63B426002E; Wed, 13 Jul 2016 14:30:25 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 6008D40; Wed, 13 Jul 2016 14:30:25 +0200 (CEST) Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 14:30:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 14:30:25 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: "Dang, Quynh (Fed)" In-Reply-To: References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> Message-ID: <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:30:38 -0000 Hey Quynh, > How can one use the distinguishing attack with the data complexity > bound I > suggested for recovering 1 bit of the encryption key in the context of > TLS > ? You cannot recover any bits of the encryption key unless you attack AES. No-one, as far as I know, has analyzed what kind of attacks one can perform against GCM around and beyond the birthday bound (except for the forgery attacks, which require repeated nonces or known forgeries). However, for CTR mode, the underlying encryption of GCM, David McGrew typed up a document describing an attack one could perform to recover information about the plaintext: http://eprint.iacr.org/2012/623 He describes it for 64 bit block ciphers, but the attacks work equally well for 128 bit block ciphers, at a higher data complexity of course. Basically, there are a lot of unknowns, and it could be that the bounds you recommend will be good enough in practice. However, it's important to be clear about the risks involved in venturing into unknown territory. Atul On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: > Hi Atul, > > On 7/12/16, 3:50 PM, "Atul Luykx" wrote: > >>> To be clear, this probability is that an attacker would be able to >>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>> potential >>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>> determine that this plaintext was not the one used for the ciphertext >>> (and with probability 0.999999999767..., know nothing about whether >>> his guessed plaintext was correct or not). >> >> You need to be careful when making such claims. There are schemes for >> which when you reach the birthday bound you can perform partial key >> recovery. >> >> The probabilities we calculated guarantee that there won't be any >> attacks (with the usual assumptions...). Beyond the bounds, there are >> no >> guarantees. In particular, you cannot conclude that one, for example, >> loses 1 bit of security once beyond the birthday bound. > > How can one use the distinguishing attack with the data complexity > bound I > suggested for recovering 1 bit of the encryption key in the context of > TLS > ? > > > Regards, > Quynh. > > > > >> >> Atul >> >> On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>>> -----Original Message----- >>>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>>> Sent: Tuesday, July 12, 2016 1:17 PM >>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>>> tls@ietf.org >>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>> >>>> Hi >>>> >>>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" >>>> wrote: >>>> >>>> >Hi Kenny, >>>> > >>>> >On 7/12/16, 12:33 PM, "Paterson, Kenny" >>>> wrote: >>>> > >>>> >>Finally, you write "to come to the 2^38 record limit, they assume >>>> that >>>> >>each record is the maximum 2^14 bytes". For clarity, we did not >>>> >>recommend a limit of 2^38 records. That's Quynh's preferred number, >>>> >>and is unsupported by our analysis. >>>> > >>>> >What is problem with my suggestion even with the record size being the >>>> >maximum value? >>>> >>>> There may be no problem with your suggestion. I was simply trying to >>>> make it >>>> clear that 2^38 records was your suggestion for the record limit and >>>> not ours. >>>> Indeed, if one reads our note carefully, one will find that we do >>>> not >>>> make any >>>> specific recommendations. We consider the decision to be one for the >>>> WG; >>>> our preferred role is to supply the analysis and help interpret it >>>> if >>>> people >>>> want that. Part of that involves correcting possible misconceptions >>>> and >>>> misinterpretations before they get out of hand. >>>> >>>> Now 2^38 does come out of our analysis if you are willing to accept >>>> single key >>>> attack security (in the indistinguishability sense) of 2^{-32}. So >>>> in >>>> that limited >>>> sense, 2^38 is supported by our analysis. But it is not our >>>> recommendation. >>>> >>>> But, speaking now in a personal capacity, I consider that security >>>> margin to be >>>> too small (i.e. I think that 2^{-32} is too big a success >>>> probability). >>> >>> To be clear, this probability is that an attacker would be able to >>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>> potential >>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>> determine that this plaintext was not the one used for the ciphertext >>> (and with probability 0.999999999767..., know nothing about whether >>> his guessed plaintext was correct or not). >>> >>> I'm just trying to get people to understand what we're talking about. >>> This is not "with probability 2^{-32}, he can recover the plaintext" >>> >>> >>>> >>>> Regards, >>>> >>>> Kenny >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 13 06:26:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6512D739 for ; Wed, 13 Jul 2016 06:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaeDtAg_0C7m for ; Wed, 13 Jul 2016 06:26:08 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 7F23A12B056 for ; Wed, 13 Jul 2016 06:26:08 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id o63so65021452vkg.1 for ; Wed, 13 Jul 2016 06:26:08 -0700 (PDT) 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; bh=JbiHHVWkCBeljYxXpPYwMKaSOIihCP+RENF4BJJvsYI=; b=Cwaa/YVw0WKdovWyejtTOXOgBXDzUPzUlwhqwTkiyTPNlf9aTuEI35nOTpJZGJRFPM Rm5p8yL6/jojj3PJlITgAGzlh/oMvY7pI0tmMXv78auJSfWKi+PwqJb4fwEXdvX1/6+/ kdRY1VHTNsDMaixDiZRxkaLy/Qk++K19Fe3o4+yLIulS3NZybtHgyow42+Y8JymIpy4r LjV6AMKuu3nKrxPiykwq7jirF0THg1u7ctlw7l/BD3MubJOLxD8SqUDxXhXAGOERDo1I TBoJn+wOkqnoGrrgvFlL3znnmteFu/WkK0gENnrFBDFzWkzl3AIUKVvzxlTtlAMJmSBE IZsg== 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; bh=JbiHHVWkCBeljYxXpPYwMKaSOIihCP+RENF4BJJvsYI=; b=gSdNVQFPCxUV1wE5Pg9XJxY78xqMtQr0J/B6kB72QGlnUbjhGSFt6y6PpOEXuq9Q8p osO4ZweLWeoFq0h56nd4OqwoZ8EtGNbEk1TwXvyrKa4gdG2LJ1l5HFqaAFQn3vAWoe3k S0+j4N7QgtxpMreiKsJPUOcq1Mt4Ehii1tV4l+xJh15aBzdC3m4xwDnc3rxbEgBRQbFG K55zQORQp4TgSUDbpAo9KxKikbG3mgEKDJ1BvK4JuzFlSZuyjK9Yr6ytte5gx5bMENNR 4ecewyk0eJsLcs5stNn5kwm8rj7oKR6prrAiFeopfTuPf2we176Da51NOkc0lR/BgNdA OWtQ== X-Gm-Message-State: ALyK8tL/i+9zWFN5zn+3U/4ZNYUplRu9gD2i1P8if/wH3TvUow2wDI564NLiNd27vJ1NYQtfaH9WuaFv0jLzhQ== X-Received: by 10.176.65.40 with SMTP id j37mr3184997uad.117.1468416367517; Wed, 13 Jul 2016 06:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Wed, 13 Jul 2016 06:26:06 -0700 (PDT) In-Reply-To: <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> From: Watson Ladd Date: Wed, 13 Jul 2016 06:26:06 -0700 Message-ID: To: Atul Luykx Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:26:12 -0000 On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx wrote: > Hey Quynh, > >> How can one use the distinguishing attack with the data complexity bound I >> suggested for recovering 1 bit of the encryption key in the context of TLS >> ? > > You cannot recover any bits of the encryption key unless you attack AES. > > No-one, as far as I know, has analyzed what kind of attacks one can perform > against GCM around and beyond the birthday bound (except for the forgery > attacks, which require repeated nonces or known forgeries). However, for CTR > mode, the underlying encryption of GCM, David McGrew typed up a document > describing an attack one could perform to recover information about the > plaintext: > http://eprint.iacr.org/2012/623 > He describes it for 64 bit block ciphers, but the attacks work equally well > for 128 bit block ciphers, at a higher data complexity of course. > > Basically, there are a lot of unknowns, and it could be that the bounds you > recommend will be good enough in practice. However, it's important to be > clear about the risks involved in venturing into unknown territory. > > Atul Furthermore the cost of avoiding this is trivial. The rekeying mechanism has been designed to have minimal code complexity. > > > On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: >> >> Hi Atul, >> >> On 7/12/16, 3:50 PM, "Atul Luykx" wrote: >> >>>> To be clear, this probability is that an attacker would be able to >>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential >>>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>>> determine that this plaintext was not the one used for the ciphertext >>>> (and with probability 0.999999999767..., know nothing about whether >>>> his guessed plaintext was correct or not). >>> >>> >>> You need to be careful when making such claims. There are schemes for >>> which when you reach the birthday bound you can perform partial key >>> recovery. >>> >>> The probabilities we calculated guarantee that there won't be any >>> attacks (with the usual assumptions...). Beyond the bounds, there are no >>> guarantees. In particular, you cannot conclude that one, for example, >>> loses 1 bit of security once beyond the birthday bound. >> >> >> How can one use the distinguishing attack with the data complexity bound I >> suggested for recovering 1 bit of the encryption key in the context of TLS >> ? >> >> >> Regards, >> Quynh. >> >> >> >> >>> >>> Atul >>> >>> On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>>>> >>>>> -----Original Message----- >>>>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>>>> Sent: Tuesday, July 12, 2016 1:17 PM >>>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>>>> tls@ietf.org >>>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>> >>>>> Hi >>>>> >>>>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote: >>>>> >>>>> >Hi Kenny, >>>>> > >>>>> >On 7/12/16, 12:33 PM, "Paterson, Kenny" >>>>> wrote: >>>>> > >>>>> >>Finally, you write "to come to the 2^38 record limit, they assume >>>>> that >>>>> >>each record is the maximum 2^14 bytes". For clarity, we did not >>>>> >>recommend a limit of 2^38 records. That's Quynh's preferred number, >>>>> >>and is unsupported by our analysis. >>>>> > >>>>> >What is problem with my suggestion even with the record size being the >>>>> >maximum value? >>>>> >>>>> There may be no problem with your suggestion. I was simply trying to >>>>> make it >>>>> clear that 2^38 records was your suggestion for the record limit and >>>>> not ours. >>>>> Indeed, if one reads our note carefully, one will find that we do not >>>>> make any >>>>> specific recommendations. We consider the decision to be one for the >>>>> WG; >>>>> our preferred role is to supply the analysis and help interpret it if >>>>> people >>>>> want that. Part of that involves correcting possible misconceptions >>>>> and >>>>> misinterpretations before they get out of hand. >>>>> >>>>> Now 2^38 does come out of our analysis if you are willing to accept >>>>> single key >>>>> attack security (in the indistinguishability sense) of 2^{-32}. So in >>>>> that limited >>>>> sense, 2^38 is supported by our analysis. But it is not our >>>>> recommendation. >>>>> >>>>> But, speaking now in a personal capacity, I consider that security >>>>> margin to be >>>>> too small (i.e. I think that 2^{-32} is too big a success >>>>> probability). >>>> >>>> >>>> To be clear, this probability is that an attacker would be able to >>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential >>>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>>> determine that this plaintext was not the one used for the ciphertext >>>> (and with probability 0.999999999767..., know nothing about whether >>>> his guessed plaintext was correct or not). >>>> >>>> I'm just trying to get people to understand what we're talking about. >>>> This is not "with probability 2^{-32}, he can recover the plaintext" >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Kenny >>>> >>>> >>>> _______________________________________________ >>>> 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 -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Jul 13 06:58:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E361C12D81D for ; Wed, 13 Jul 2016 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMPhRmkqKa7D for ; Wed, 13 Jul 2016 06:58:47 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0109.outbound.protection.outlook.com [23.103.201.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B998C12D80A for ; Wed, 13 Jul 2016 06:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XyL9SgNVdSnOawiedQhTwY74oS71/Feup6VEOhtYMe0=; b=W8eOZ+y0X2bh75Y0+3o3PjbWvVreZcXSKLSJC65HDLx/V517bD52y1Fb12NwdphtQnayooJVgsKyKxVZCrnfW+CLDH1Btz6DnYTAfZVNzxTlTouL1M8RjOk7tIcapWmD28H+GwhEVzQKOWihIYV5OA6fbDXMCqeFsInsG0jemLY= Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0170.namprd09.prod.outlook.com (10.255.192.148) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 13:58:44 +0000 Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Wed, 13 Jul 2016 13:58:44 +0000 From: "Dang, Quynh (Fed)" To: Watson Ladd , Atul Luykx Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAATFUAgAANRgD//8XVgIAARoOAgAANwgCAABz0gIAAvyMAgABYXICAAA+PAP//xg2A Date: Wed, 13 Jul 2016 13:58:44 +0000 Message-ID: References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 68b144fd-43e3-4a84-96bb-08d3ab25cdf9 x-microsoft-exchange-diagnostics: 1; BN1PR09MB0170; 6:ARW6foUVo4vwOJ1zPEJwTpHEyBIk/7aql+A6fTuiO6oyFdLBzZKWidhm6s6vYEWBnHLLSFWyrI5TWlDZ65YU3+ekjvSlXO5D5icKF6Sz0eseOCUOlH5do0BCRFp+RqsY4SdoMbwe3btWyf3JBtkC2ssIsnetnp/DRkJC1TqouG8DhA2eTkU8eeklcnbcPGlTYRfyVxfr4S6jc4IRFgerZmPYjnzQ+RdYx52tUnUK+3Jp73zNuQZYgMsoUAH+7n2pU5AMem0IsCpfDx10OQ/34OtFLZPDGVFsUDn8fp4mfxW1xfRIMDis2+QuFmTwotL+MyEapMHTgwXbCaJnby/qvg==; 5:05xJtsLcBhwXjfatE6z8tlxoDMz6d2GYNXPOzx65dMzLbK6j+CgG/lHgmSQY6Ny4hk5DWOsEterBTAT8+y/V3pj8wAmbyXdK/4abIxeJPGz/BJmSMXiyj99G1gPqXKgKbm6eU2vpRzl9o0yYBImz7g==; 24:Uit16EKYqteaj4EQUArTJY2AhclhiOLtoNs8Qb1goRLwehOZsVMhpKTIegrKXizxDEjz49M2i8tGO23Qm8z/G3ksBjLrwBOkjO8fWFQ++Xc=; 7:3l4+3sfkBZYnLF+ZZFaYzwVC6bk4AARuC+wzBv2izkF12Zk/bWtjIZzJ59ht5iiQW8p3fDJB3Nzw7+YKb1xGoCDQHKokQ0bLuLcddsh/ap2lTP0UtT6FrszHC63bgSLBSQN/Ueh2JiOYw72zjfU1Ltdba8y4xW8IJYe6XjnUvNDkFmra7BPtT0EmqPpwzt/hxs9ugwo0Oa9x5WRAj5NiJXjCBCyc4Dn1xv0ixgy/QIvBjHMgiuapRSCCnNSNn4Pt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0170; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0170; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0170; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377424004)(13464003)(377454003)(199003)(189002)(51444003)(3660700001)(54356999)(19580395003)(19580405001)(7846002)(7736002)(93886004)(2906002)(305945005)(50986999)(83506001)(106116001)(106356001)(81156014)(76176999)(81166006)(586003)(3280700002)(2900100001)(2950100001)(101416001)(36756003)(11100500001)(4326007)(5001770100001)(8936002)(92566002)(4001350100001)(8676002)(122556002)(3846002)(6116002)(99286002)(97736004)(68736007)(5002640100001)(66066001)(189998001)(230783001)(15975445007)(10400500002)(102836003)(87936001)(77096005)(1720100001)(105586002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0170; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4494E173C17C58498F8517D945B3E38D@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 13:58:44.3456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0170 Archived-At: Cc: David McGrew , "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:58:52 -0000 On 7/13/16, 9:26 AM, "Watson Ladd" wrote: >On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx >wrote: >> Hey Quynh, >> >>> How can one use the distinguishing attack with the data complexity >>>bound I >>> suggested for recovering 1 bit of the encryption key in the context of >>>TLS >>> ? >> >> You cannot recover any bits of the encryption key unless you attack AES. >> >> No-one, as far as I know, has analyzed what kind of attacks one can >>perform >> against GCM around and beyond the birthday bound (except for the forgery >> attacks, which require repeated nonces or known forgeries). However, >>for CTR >> mode, the underlying encryption of GCM, David McGrew typed up a document >> describing an attack one could perform to recover information about the >> plaintext: >> http://eprint.iacr.org/2012/623 >> He describes it for 64 bit block ciphers, but the attacks work equally >>well >> for 128 bit block ciphers, at a higher data complexity of course. >> >> Basically, there are a lot of unknowns, and it could be that the bounds >>you >> recommend will be good enough in practice. However, it's important to be >> clear about the risks involved in venturing into unknown territory. >> >> Atul > >Furthermore the cost of avoiding this is trivial. The rekeying >mechanism has been designed to have minimal code complexity. GCM with data complexity of about 3^38 records is not vulnerable to that plaintext recovery attack. Therefore, there are no needs to rekey before that data complexity is reached. For counter-mode, I think the attack works if there is a large set of known plaintexts. In protocols such as TLS and Ipsec, there are known plaintexts, but I don=B9t think the amount of known plaintexts (even though the amount of encrypted repeated-plaintexts can be big) is enough to create risk for AES_128 by the targeted plaintext recovery attack. A known plaintext can be encrypted multiple times with different keys, not with the same key.=20 Regards, Quynh.=20 >> >> >> On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: >>> >>> Hi Atul, >>> >>> On 7/12/16, 3:50 PM, "Atul Luykx" wrote: >>> >>>>> To be clear, this probability is that an attacker would be able to >>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>potential >>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>>>> determine that this plaintext was not the one used for the ciphertext >>>>> (and with probability 0.999999999767..., know nothing about whether >>>>> his guessed plaintext was correct or not). >>>> >>>> >>>> You need to be careful when making such claims. There are schemes for >>>> which when you reach the birthday bound you can perform partial key >>>> recovery. >>>> >>>> The probabilities we calculated guarantee that there won't be any >>>> attacks (with the usual assumptions...). Beyond the bounds, there are >>>>no >>>> guarantees. In particular, you cannot conclude that one, for example, >>>> loses 1 bit of security once beyond the birthday bound. >>> >>> >>> How can one use the distinguishing attack with the data complexity >>>bound I >>> suggested for recovering 1 bit of the encryption key in the context of >>>TLS >>> ? >>> >>> >>> Regards, >>> Quynh. >>> >>> >>> >>> >>>> >>>> Atul >>>> >>>> On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>>>>> Sent: Tuesday, July 12, 2016 1:17 PM >>>>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>>>>> tls@ietf.org >>>>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>>> >>>>>> Hi >>>>>> >>>>>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" >>>>>>wrote: >>>>>> >>>>>> >Hi Kenny, >>>>>> > >>>>>> >On 7/12/16, 12:33 PM, "Paterson, Kenny" >>>>>> wrote: >>>>>> > >>>>>> >>Finally, you write "to come to the 2^38 record limit, they assume >>>>>> that >>>>>> >>each record is the maximum 2^14 bytes". For clarity, we did not >>>>>> >>recommend a limit of 2^38 records. That's Quynh's preferred >>>>>>number, >>>>>> >>and is unsupported by our analysis. >>>>>> > >>>>>> >What is problem with my suggestion even with the record size being >>>>>>the >>>>>> >maximum value? >>>>>> >>>>>> There may be no problem with your suggestion. I was simply trying to >>>>>> make it >>>>>> clear that 2^38 records was your suggestion for the record limit and >>>>>> not ours. >>>>>> Indeed, if one reads our note carefully, one will find that we do >>>>>>not >>>>>> make any >>>>>> specific recommendations. We consider the decision to be one for the >>>>>> WG; >>>>>> our preferred role is to supply the analysis and help interpret it >>>>>>if >>>>>> people >>>>>> want that. Part of that involves correcting possible misconceptions >>>>>> and >>>>>> misinterpretations before they get out of hand. >>>>>> >>>>>> Now 2^38 does come out of our analysis if you are willing to accept >>>>>> single key >>>>>> attack security (in the indistinguishability sense) of 2^{-32}. So >>>>>>in >>>>>> that limited >>>>>> sense, 2^38 is supported by our analysis. But it is not our >>>>>> recommendation. >>>>>> >>>>>> But, speaking now in a personal capacity, I consider that security >>>>>> margin to be >>>>>> too small (i.e. I think that 2^{-32} is too big a success >>>>>> probability). >>>>> >>>>> >>>>> To be clear, this probability is that an attacker would be able to >>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>potential >>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able to >>>>> determine that this plaintext was not the one used for the ciphertext >>>>> (and with probability 0.999999999767..., know nothing about whether >>>>> his guessed plaintext was correct or not). >>>>> >>>>> I'm just trying to get people to understand what we're talking about. >>>>> This is not "with probability 2^{-32}, he can recover the plaintext" >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Kenny >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Jul 13 07:03:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3980512D748 for ; Wed, 13 Jul 2016 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p_EH7OnZRre for ; Wed, 13 Jul 2016 07:03:07 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C5E12D815 for ; Wed, 13 Jul 2016 07:03:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 38so47034270iol.0 for ; Wed, 13 Jul 2016 07:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pDUQPhyxdJmgVvXOzvmibPvdJ3phnb7UwEcc56HKt6k=; b=YcxmOjXLav1ggftGnQ/cGkuZ8CYuuJ+X3N65YwDNB7hYijWoN2DxYhxyjU5D8962+d CJS7wIKytbz0PBsLrQ6oXsZgUT1gQyrSjzzMmVSLw8LU4ZB2Xqx3Pt0TjkL19nqo0IA+ w65hLITfZrMPNjZnjjy13CYAju5Vo7dg6uMhQ= 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; bh=pDUQPhyxdJmgVvXOzvmibPvdJ3phnb7UwEcc56HKt6k=; b=KUYWI9dDs8YjglKTxEXcnQPhEL9Y1hNLd3eLi/ecR11MSggoXuLlmt5INuJRyX59Mn qkJBkZ5orIEhrE+eRDHirUl/XYZVV6Sqx2X+pBr/YMNfBRgljbXRplb+SHsgvT2Ku+GA 3/2JUgygbWMCJ+LqooyMm4plxub7HmIWem4odET0965KMfATVIsofUktgKXeI/7guXMe E+RFnZgWEZbLyWoIkai0zSPX8qNQHB9eBBOklodHR+T3M+b1ESWcphBW5c8F5Tzv971c kLEkSg6b57zydQxqDrgRGsu7ctUaLGxKqQ+tGr4XJwq+Hn6fW82TeiWKqLkt0yNc1h5a U0dQ== X-Gm-Message-State: ALyK8tLtT+ERlcg2ZkecTwJRTx1/6hp+tpkLHr2160L1GDJK6FfKUB/vN+nvkRJXPhVmqi+rsSMmzMsA+5FDK/b6 X-Received: by 10.107.13.82 with SMTP id 79mr9994467ion.97.1468418580366; Wed, 13 Jul 2016 07:03:00 -0700 (PDT) MIME-Version: 1.0 References: <209780076.Yzkn8lymcZ@pintsize.usersys.redhat.com> In-Reply-To: <209780076.Yzkn8lymcZ@pintsize.usersys.redhat.com> From: David Benjamin Date: Wed, 13 Jul 2016 14:02:50 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a113fdb5eddbcb4053784d72c Archived-At: Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:03:12 -0000 --001a113fdb5eddbcb4053784d72c Content-Type: text/plain; charset=UTF-8 On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett wrote: > To be clear though, completely mandatory extensions, at least as we're > doing them here, are a new thing. TLS 1.2 relied on separate messages for > stuff, but we're front-loading everything into the ClientHello to get > reliable 1RTT (with the exception of HRR). On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario wrote: > On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > > I don't believe an implementation which fails to send supported_groups, > > etc., in 1.3 would ever leave a developer's workstation. It would not > > interoperate with anything. > > it would interoperate with itself, and for some deployments that's enough > of a passing grade... (Even if you do interoperatbility testing you > do not check all possible permutations of features and settings) > > I wholeheartedly agree with Dave here, error definitions should be strict > (both on the when and what to do). One, because it allows to better > diagnose (in general, maybe not in this specific situation) problems. > Two, because you can write a strict negative test case that actually > checks for it. https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1af082580a1b87c9a690f/ssl/test/runner/runner.go#5646 Also something I have plenty of experience with. We're obsessive about adding this kind of test in BoringSSL[0]. :-) One doesn't need this alert to write a test for curve negotiation. Just test that the handshake hits the usual codepath for there not being a common cipher. This semi-mandatory extension isn't new in TLS 1.3, depending on your 1.2 behavior. BoringSSL will already refuse to select an ECDHE cipher if supported_curves is missing. 1.2 does not require this, but we opted to do it for simplicity[1]. David [0] If anyone wants to try, I'm sure there is an implementation-agnostic TLS protocol test suite one could extract out of that. It would take some wrangling as we cheat and condition on BoringSSL error codes, but the nice thing is I've already built up a large battery of tests here. [1] Previously we always picking our most preferred curve if the extension was missing, like OpenSSL. But now our most preferred curve is X25519, not P-256. It did not seem worth kludging that when we could just decline the cipher. No one's noticed, so I would say that worked. --001a113fdb5eddbcb4053784d72c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett <davemgarrett@gmail.com> wrote:
To be clear though, completely mandato= ry extensions, at least as we're doing them here, are a new thing. TLS = 1.2 relied on separate messages for stuff, but we're front-loading ever= ything into the ClientHello to get reliable 1RTT (with the exception of HRR= ).

On Wed, Ju= l 13, 2016 at 8:12 AM Hubert Kario <hkario@redhat.com> wrote:
O= n Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> I don't believe an implementation which fails to send supported_gr= oups,
> etc., in 1.3 would ever leave a developer's workstation. It would = not
> interoperate with anything.

it would interoperate with itself, and for some deployments that's enou= gh
of a passing grade... (Even if you do interoperatbility testing you
do not check all possible permutations of features and settings)

I wholeheartedly agree with Dave here, error definitions should be strict (both on the when and what to do). One, because it allows to better
diagnose (in general, maybe not in this specific situation) problems.
Two, because you can write a strict negative test case that actually
checks for it.=C2=A0

Also something I ha= ve plenty of experience with. We're obsessive about adding this kind of= test in BoringSSL[0]. :-)

One doesn't need th= is alert to write a test for curve negotiation. Just test that the handshak= e hits the usual codepath for there not being a common cipher.
This semi-mandatory extension isn't new in TLS 1.3, depend= ing on your 1.2 behavior. BoringSSL will already refuse to select an ECDHE = cipher if supported_curves is missing. 1.2 does not require this, but we op= ted to do it for simplicity[1].

David
[0] If anyone wants to try, I'm sure there is an implement= ation-agnostic TLS protocol test suite one could extract out of that. It wo= uld take some wrangling as we cheat and condition on BoringSSL error codes,= but the nice thing is I've already built up a large battery of tests h= ere.

[1] Previously we always picking our most pre= ferred curve if the extension was missing, like OpenSSL. But now our most p= referred curve is X25519, not P-256. It did not seem worth kludging that wh= en we could just decline the cipher. No one's noticed, so I would say t= hat worked.
--001a113fdb5eddbcb4053784d72c-- From nobody Wed Jul 13 07:44:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693512D94F for ; Wed, 13 Jul 2016 07:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FomcTLYDC0HU for ; Wed, 13 Jul 2016 07:44:10 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 EFE0012D923 for ; Wed, 13 Jul 2016 07:44:09 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id f6so45059698ith.0 for ; Wed, 13 Jul 2016 07:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4aVmdtRfvYGziovRm77cZhHa9/zFY1yEum2Dm3Ae+O0=; b=ENBOYUcvKUnOMpawNLHhCU18Lfo/ZhDWjzTeVP0FeRKqD1EhfDXdRRCb4qCD0NPIQ2 5sKo5DGzjpARJYplwJtfkKq5Il/3jTxTIRYN+5LVEvUNrKcSeTXv/NvvV0a/UVHaXFzI hZhKVqJWxq3UuXI9u4ZCuOsp+6L8AYY2Q99fE= 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; bh=4aVmdtRfvYGziovRm77cZhHa9/zFY1yEum2Dm3Ae+O0=; b=FZUuWkZnq6OcNKFOKtLQ0mbCEnyb138XN+5UQEm/U5ujOejLh3mlPptESZzSvo2lop 0MKCXSdKAZk3FPNwtwK2mD1/Hod6Q3cgs/1IM7GnbAiy6q9Mtgbw7C6vJKWxH5+akU5E 5ZA6V3knVCfA8w9asq43Z+ZGP6v451prcuMsrV8XDrwulNIOL0HbK4GTiAKZQ4Dtt8vl 2Ncv3S8LGIZUEojM1i502Ixu+X/5MYK0LPoZs+iBthzlhDOQiwb9iU5hUFq1QXdI+6Yu q9ldpt2KGS0iuB2EN7uFRmAMuZ1om4J9CzkCl2diyMXd8abHo6PDU23CXXSX7mwxxlPQ wNoA== X-Gm-Message-State: ALyK8tJSYjtzgUIOha4ttVz8HwL6R8iP0+qWG0d3ZcHx5TIfG1AZZYa9r5B7FPk+TMxb9GnS5RMVtB7IXImbdj21 X-Received: by 10.36.19.138 with SMTP id 132mr9853271itz.76.1468421048777; Wed, 13 Jul 2016 07:44:08 -0700 (PDT) MIME-Version: 1.0 References: <209780076.Yzkn8lymcZ@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Wed, 13 Jul 2016 14:43:58 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a11446074ff91e80537856a01 Archived-At: Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:44:12 -0000 --001a11446074ff91e80537856a01 Content-Type: text/plain; charset=UTF-8 To be clear, I am not at all opposed to useful errors or strict policing of what the peer sends. That's all great. Indeed the linked test below makes use of more specific error codes than TLS provides. But I would like such things to: 1. Be useful, either for debugging or because it rejects an invalid handshake that would otherwise go unnoticed. 2. Come out naturally out of what the implementation would do anyway, to keep complexity down. I'm also quite okay with budging on #2 where #1 is strong. Complexity is the currency we pay for adding things. But I do not think this particular error code passes #1 (the special-case is not useful and such a peer would not be able to handshake against correct implementations anyway), so I'm not willing to sacrifice #2 for it. On Wed, Jul 13, 2016 at 10:02 AM David Benjamin wrote: > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett > wrote: > >> To be clear though, completely mandatory extensions, at least as we're >> doing them here, are a new thing. TLS 1.2 relied on separate messages for >> stuff, but we're front-loading everything into the ClientHello to get >> reliable 1RTT (with the exception of HRR). > > > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario wrote: > >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: >> > I don't believe an implementation which fails to send supported_groups, >> > etc., in 1.3 would ever leave a developer's workstation. It would not >> > interoperate with anything. >> >> it would interoperate with itself, and for some deployments that's enough >> of a passing grade... (Even if you do interoperatbility testing you >> do not check all possible permutations of features and settings) >> >> I wholeheartedly agree with Dave here, error definitions should be strict >> (both on the when and what to do). One, because it allows to better >> diagnose (in general, maybe not in this specific situation) problems. >> Two, because you can write a strict negative test case that actually >> checks for it. > > > > https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1af082580a1b87c9a690f/ssl/test/runner/runner.go#5646 > Also something I have plenty of experience with. We're obsessive about > adding this kind of test in BoringSSL[0]. :-) > > One doesn't need this alert to write a test for curve negotiation. Just > test that the handshake hits the usual codepath for there not being a > common cipher. > > This semi-mandatory extension isn't new in TLS 1.3, depending on your 1.2 > behavior. BoringSSL will already refuse to select an ECDHE cipher if > supported_curves is missing. 1.2 does not require this, but we opted to do > it for simplicity[1]. > > David > > [0] If anyone wants to try, I'm sure there is an implementation-agnostic > TLS protocol test suite one could extract out of that. It would take some > wrangling as we cheat and condition on BoringSSL error codes, but the nice > thing is I've already built up a large battery of tests here. > > [1] Previously we always picking our most preferred curve if the extension > was missing, like OpenSSL. But now our most preferred curve is X25519, not > P-256. It did not seem worth kludging that when we could just decline the > cipher. No one's noticed, so I would say that worked. > --001a11446074ff91e80537856a01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be clear, I am not at a= ll opposed to useful errors or strict policing of what the peer sends. That= 's all great. Indeed the linked test below makes use of more specific e= rror codes than TLS provides. But I would like such things to:
1. Be useful, either for debugging or because it rejects an in= valid handshake that would otherwise go unnoticed.
2. Come out na= turally out of what the implementation would do anyway, to keep complexity = down.

I'm also quite okay with budging on #2 w= here #1 is strong. Complexity is the currency we pay for adding things. But= I do not think this particular error code passes #1 (the special-case is n= ot useful and such a peer would not be able to handshake against correct im= plementations anyway), so I'm not willing to sacrifice #2 for it.
=

On Wed, Jul 13, 2016 at 10:02 A= M David Benjamin <davidben@chro= mium.org> wrote:
On Wed, = Jul 13, 2016 at 3:31 AM Dave Garrett <davemgarrett@gmail.com> wrote:
To be clear though, completely = mandatory extensions, at least as we're doing them here, are a new thin= g. TLS 1.2 relied on separate messages for stuff, but we're front-loadi= ng everything into the ClientHello to get reliable 1RTT (with the exception= of HRR).

On Wed, Jul 13, 2016 a= t 8:12 AM Hubert Kario <hkario@redhat.com> wrote:
On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> I don't believe an implementation which fails to send supported_gr= oups,
> etc., in 1.3 would ever leave a developer's workstation. It would = not
> interoperate with anything.

it would interoperate with itself, and for some deployments that's enou= gh
of a passing grade... (Even if you do interoperatbility testing you
do not check all possible permutations of features and settings)

I wholeheartedly agree with Dave here, error definitions should be strict (both on the when and what to do). One, because it allows to better
diagnose (in general, maybe not in this specific situation) problems.
Two, because you can write a strict negative test case that actually
checks for it.=C2=A0

htt= ps://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1af082580a1b= 87c9a690f/ssl/test/runner/runner.go#5646
Also something I hav= e plenty of experience with. We're obsessive about adding this kind of = test in BoringSSL[0]. :-)

One doesn't need thi= s alert to write a test for curve negotiation. Just test that the handshake= hits the usual codepath for there not being a common cipher.
This semi-mandatory extension isn't new in TLS 1.3, dependi= ng on your 1.2 behavior. BoringSSL will already refuse to select an ECDHE c= ipher if supported_curves is missing. 1.2 does not require this, but we opt= ed to do it for simplicity[1].

David
[0] If anyone wants to try, I'm sure there is an implementa= tion-agnostic TLS protocol test suite one could extract out of that. It wou= ld take some wrangling as we cheat and condition on BoringSSL error codes, = but the nice thing is I've already built up a large battery of tests he= re.

[1] Previously we always picking our most pref= erred curve if the extension was missing, like OpenSSL. But now our most pr= eferred curve is X25519, not P-256. It did not seem worth kludging that whe= n we could just decline the cipher. No one's noticed, so I would say th= at worked.
--001a11446074ff91e80537856a01-- From nobody Wed Jul 13 08:06:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE04E12D9C6 for ; Wed, 13 Jul 2016 08:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxQF8_KPPBwe for ; Wed, 13 Jul 2016 08:06:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B5D12D1A7 for ; Wed, 13 Jul 2016 08:06:37 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 236D01A0EFB; Wed, 13 Jul 2016 15:06:37 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DF6ZJf009019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 11:06:36 -0400 From: Hubert Kario To: David Benjamin Date: Wed, 13 Jul 2016 17:06:26 +0200 Message-ID: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.5.7-202.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5070464.fAatkPdV5D"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Jul 2016 15:06:37 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:06:40 -0000 --nextPart5070464.fAatkPdV5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: > To be clear, I am not at all opposed to useful errors or strict polic= ing of > what the peer sends. That's all great. Indeed the linked test below m= akes > use of more specific error codes than TLS provides. But I would like = such > things to: >=20 > 1. Be useful, either for debugging or because it rejects an invalid > handshake that would otherwise go unnoticed. > 2. Come out naturally out of what the implementation would do anyway,= to > keep complexity down. >=20 > I'm also quite okay with budging on #2 where #1 is strong. Complexity= is > the currency we pay for adding things. But I do not think this partic= ular > error code passes #1 (the special-case is not useful and such a peer = would > not be able to handshake against correct implementations anyway), so = I'm > not willing to sacrifice #2 for it. Then I fail to see how missing_extension does not flow out of correct implementation (and from general RFC recommendations). You need to parse the Client Hello, and then sanity check it (length of= session ID, validity of ciphers, lack of duplicate extensions, etc.). Making sure that mandatory extensions are in place in the same code seems to me like a obvious place to do it. In other words, you shouldn't delay checking if a particular extension is present until the time you want to use it. If there is any chance (or possible configuration) in which you would end up using it, you should complain that the extension is missing or it is malformed. This way when you start to depend on it, things won't start breaking suddenly and you end up writing Yet Another Workaround for Broken Implementations=E2=84=A2 =20 > On Wed, Jul 13, 2016 at 10:02 AM David Benjamin > wrote: >=20 > > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett > > wrote: > > > >> To be clear though, completely mandatory extensions, at least as w= e're > >> doing them here, are a new thing. TLS 1.2 relied on separate messa= ges for > >> stuff, but we're front-loading everything into the ClientHello to = get > >> reliable 1RTT (with the exception of HRR). > > > > > > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario wr= ote: > > > >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > >> > I don't believe an implementation which fails to send supported_= groups, > >> > etc., in 1.3 would ever leave a developer's workstation. It woul= d not > >> > interoperate with anything. > >> > >> it would interoperate with itself, and for some deployments that's= enough > >> of a passing grade... (Even if you do interoperatbility testing yo= u > >> do not check all possible permutations of features and settings) > >> > >> I wholeheartedly agree with Dave here, error definitions should be= strict > >> (both on the when and what to do). One, because it allows to bette= r > >> diagnose (in general, maybe not in this specific situation) proble= ms. > >> Two, because you can write a strict negative test case that actual= ly > >> checks for it. > > > > > > > > https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1= af082580a1b87c9a690f/ssl/test/runner/runner.go#5646 > > Also something I have plenty of experience with. We're obsessive ab= out > > adding this kind of test in BoringSSL[0]. :-) > > > > One doesn't need this alert to write a test for curve negotiation. = Just > > test that the handshake hits the usual codepath for there not being= a > > common cipher. > > > > This semi-mandatory extension isn't new in TLS 1.3, depending on yo= ur 1.2 > > behavior. BoringSSL will already refuse to select an ECDHE cipher i= f > > supported_curves is missing. 1.2 does not require this, but we opte= d to do > > it for simplicity[1]. > > > > David > > > > [0] If anyone wants to try, I'm sure there is an implementation-agn= ostic > > TLS protocol test suite one could extract out of that. It would tak= e some > > wrangling as we cheat and condition on BoringSSL error codes, but t= he nice > > thing is I've already built up a large battery of tests here. > > > > [1] Previously we always picking our most preferred curve if the ex= tension > > was missing, like OpenSSL. But now our most preferred curve is X255= 19, not > > P-256. It did not seem worth kludging that when we could just decli= ne the > > cipher. No one's noticed, so I would say that worked. > > =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 --nextPart5070464.fAatkPdV5D 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 iQIcBAABCgAGBQJXhljyAAoJEJKo0bgB0vX1kb0P/3a1/6vYWqBmIbYQKMZS86TU 7pEkC0YhY3XQU1CcGTBAt7kiSRhXRNbNHFPZxwjzSgw2hyKCUXQh2eMUjT7tox0d GAz26okruyGz7AVREp7ZFuJPjBUrz3sTlUmSuSgTQaaCK64Fj8lcZx4fZghwY/+G PqXVSSL+3bCSAYekp3A0si7Q9GBmaGCHbiTz/+Apf0OBqAM0TzFuGyufRQJh+58U MtK7YLvsOQeHg9L/jbEv+xNQHS0KtgHVCHq83bVi3nJkFLbS8wfzYq+3X3ojFO5/ k/YXPrCK1uvPlaNPqzBy4kZQb8G8LhfEO6Gny9IuD5th32tMbkTBJYbRn2PonJdK r8u/MGnj5tkyXQxnMW03BD359/qCgT9LvL/nc9wZRRMSgwSHecJgileqPNMiWDH6 4PfcitSlMT7si9RED2i4v8LyAkPslyE8kfdeb/BHe6wD7w5wjmtKIXUIV54P+Bnj xTrGGxylR0qaATk3GkZZHwWLG4OfuMFd181dUunLGP3mHrm1yQhTSopjfKvW/rr0 AaWwefGBzWNo2nMlb6A16mU3atdFyqN4lf1h/AUjlCjwO4DixWIwd1BZ5VoFwiVf rZ+OOEfHSAPE/w9LhoKJO1fSlZ1L/nsfWKHcXr4S38xQMovD8Uj+NWnXtuzmp/3N Zs9cMbX9yPh5tHVQaqg/ =MTVK -----END PGP SIGNATURE----- --nextPart5070464.fAatkPdV5D-- From nobody Wed Jul 13 08:58:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE012D162 for ; Wed, 13 Jul 2016 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvVPsI6g2Um7 for ; Wed, 13 Jul 2016 08:58:36 -0700 (PDT) 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 B665F12D14D for ; Wed, 13 Jul 2016 08:58:34 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id b62so50276606iod.3 for ; Wed, 13 Jul 2016 08:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JASZrPjobG9wqR6xuwtj9UGHLPC9i4EYPeg0fXlq8As=; b=lFlxaQbiotBIpisSANij7+uxveuScaXZ75dGkDEGoDJKounJnT5k4hc169Djv40j42 3p07DTGYBPDJaWqFswKDJVJyX3gAbS/GH2liVgMo+O7TQ+990X9T9aHFq8gM+xaqsuyy A+4r/NcN9jd3RYb8/QKXN867ymvCtHeAZhW1g= 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; bh=JASZrPjobG9wqR6xuwtj9UGHLPC9i4EYPeg0fXlq8As=; b=Is2wmZfSuvZiKjNFhQ75YkBm039r+C5w1sAwX1FZ9sfY59anQwJi5IjXs8qlryt1HM n86/U/crmtqcCukEdKb5STuUnmcy6pnicyDiyhxM8bATDAl64DdEBOEyqL5WqDOSZ2sx N+eMkeC4hgwzt2JQS+Zk9VejAmGUPxcjGyC4YboY0h+D/heC0F/7HdmZgfEWnTDB/YDg ThPBVOzbpTm01hyE8gAvbPLjgeCqOUBwnszs7kK5EaeF721rZfa1OeRZRJYhuoYRM5Iz ilZfTeKdTeoavxyt2jhaQIFtBULxqY8dlI3xeSp6HC+MyWCgooI2u+5be7YsYQ9pNX0E AMUQ== X-Gm-Message-State: ALyK8tJST4tmc142nKLkXb2NYfuwje6MeAxYooaAlnaEObpXvtleWe/XGLELiQHjaEHjxTPlsU9kVhi9us1ey1Lg X-Received: by 10.107.52.133 with SMTP id b127mr10092678ioa.6.1468425513859; Wed, 13 Jul 2016 08:58:33 -0700 (PDT) MIME-Version: 1.0 References: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> In-Reply-To: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> From: David Benjamin Date: Wed, 13 Jul 2016 15:58:24 +0000 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11440f1c2279220537867596 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:58:38 -0000 --001a11440f1c2279220537867596 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wrote: > On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: > > To be clear, I am not at all opposed to useful errors or strict policin= g > of > > what the peer sends. That's all great. Indeed the linked test below mak= es > > use of more specific error codes than TLS provides. But I would like su= ch > > things to: > > > > 1. Be useful, either for debugging or because it rejects an invalid > > handshake that would otherwise go unnoticed. > > 2. Come out naturally out of what the implementation would do anyway, t= o > > keep complexity down. > > > > I'm also quite okay with budging on #2 where #1 is strong. Complexity i= s > > the currency we pay for adding things. But I do not think this particul= ar > > error code passes #1 (the special-case is not useful and such a peer > would > > not be able to handshake against correct implementations anyway), so I'= m > > not willing to sacrifice #2 for it. > > Then I fail to see how missing_extension does not flow out of correct > implementation (and from general RFC recommendations). > > You need to parse the Client Hello, and then sanity check it (length of > session ID, validity of ciphers, lack of duplicate extensions, etc.). > Making sure that mandatory extensions are in place in the same code > seems to me like a obvious place to do it. > The extension is not mandatory. Whether it is mandatory or not depends on the cipher suite selected. The cipher suite selected depends on the contents (or lack of) the extension. This makes checking things somewhat circular. If it were simply mandatory, by all means, mandate a missing_extension alert. I still do not think it'd be very useful (I'm more interested in non-syntax-error cases), but I have no objections. > In other words, you shouldn't delay checking if a particular extension > is present until the time you want to use it. If there is any chance > (or possible configuration) in which you would end up using it, you > should complain that the extension is missing or it is malformed. > > This way when you start to depend on it, things won't start breaking > suddenly and you end up writing Yet Another Workaround for Broken > Implementations=E2=84=A2 > I still do not see how returning handshake_failure (or whatever the "no common cipher" error is) for this case instead of missing_extension will cause broken implementations to come up. David > > On Wed, Jul 13, 2016 at 10:02 AM David Benjamin > > wrote: > > > > > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett > > > wrote: > > > > > >> To be clear though, completely mandatory extensions, at least as we'= re > > >> doing them here, are a new thing. TLS 1.2 relied on separate message= s > for > > >> stuff, but we're front-loading everything into the ClientHello to ge= t > > >> reliable 1RTT (with the exception of HRR). > > > > > > > > > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario > wrote: > > > > > >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > > >> > I don't believe an implementation which fails to send > supported_groups, > > >> > etc., in 1.3 would ever leave a developer's workstation. It would > not > > >> > interoperate with anything. > > >> > > >> it would interoperate with itself, and for some deployments that's > enough > > >> of a passing grade... (Even if you do interoperatbility testing you > > >> do not check all possible permutations of features and settings) > > >> > > >> I wholeheartedly agree with Dave here, error definitions should be > strict > > >> (both on the when and what to do). One, because it allows to better > > >> diagnose (in general, maybe not in this specific situation) problems= . > > >> Two, because you can write a strict negative test case that actually > > >> checks for it. > > > > > > > > > > > > > https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1af0825= 80a1b87c9a690f/ssl/test/runner/runner.go#5646 > > > Also something I have plenty of experience with. We're obsessive abou= t > > > adding this kind of test in BoringSSL[0]. :-) > > > > > > One doesn't need this alert to write a test for curve negotiation. Ju= st > > > test that the handshake hits the usual codepath for there not being a > > > common cipher. > > > > > > This semi-mandatory extension isn't new in TLS 1.3, depending on your > 1.2 > > > behavior. BoringSSL will already refuse to select an ECDHE cipher if > > > supported_curves is missing. 1.2 does not require this, but we opted > to do > > > it for simplicity[1]. > > > > > > David > > > > > > [0] If anyone wants to try, I'm sure there is an > implementation-agnostic > > > TLS protocol test suite one could extract out of that. It would take > some > > > wrangling as we cheat and condition on BoringSSL error codes, but the > nice > > > thing is I've already built up a large battery of tests here. > > > > > > [1] Previously we always picking our most preferred curve if the > extension > > > was missing, like OpenSSL. But now our most preferred curve is X25519= , > not > > > P-256. It did not seem worth kludging that when we could just decline > the > > > cipher. No one's noticed, so I would say that worked. > > > > > -- > 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 --001a11440f1c2279220537867596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13= , 2016 at 11:06 AM Hubert Kario <hk= ario@redhat.com> wrote:
On W= ednesday 13 July 2016 14:43:58 David Benjamin wrote:
> To be clear, I am not at all opposed to useful errors or strict polici= ng of
> what the peer sends. That's all great. Indeed the linked test belo= w makes
> use of more specific error codes than TLS provides. But I would like s= uch
> things to:
>
> 1. Be useful, either for debugging or because it rejects an invalid > handshake that would otherwise go unnoticed.
> 2. Come out naturally out of what the implementation would do anyway, = to
> keep complexity down.
>
> I'm also quite okay with budging on #2 where #1 is strong. Complex= ity is
> the currency we pay for adding things. But I do not think this particu= lar
> error code passes #1 (the special-case is not useful and such a peer w= ould
> not be able to handshake against correct implementations anyway), so I= 'm
> not willing to sacrifice #2 for it.

Then I fail to see how missing_extension does not flow out of correct
implementation (and from general RFC recommendations).

You need to parse the Client Hello, and then sanity check it (length of
session ID, validity of ciphers, lack of duplicate extensions, etc.).
Making sure that mandatory extensions are in place in the same code
seems to me like a obvious place to do it.

<= div>The extension is not mandatory. Whether it is mandatory or not depends = on the cipher suite selected. The cipher suite selected depends on the cont= ents (or lack of) the extension. This makes checking things somewhat circul= ar.

If it were simply mandatory, by all means, man= date a missing_extension alert. I still do not think it'd be very usefu= l (I'm more interested in non-syntax-error cases), but I have no object= ions.
=C2=A0
In other words, you shouldn't delay checking if a particular extension<= br> is present until the time you want to use it. If there is any chance
(or possible configuration) in which you would end up using it, you
should complain that the extension is missing or it is malformed.

This way when you start to depend on it, things won't start breaking suddenly and you end up writing Yet Another Workaround for Broken
Implementations=E2=84=A2

I still do not= see how returning handshake_failure (or whatever the "no common ciphe= r" error is) for this case instead of missing_extension will cause bro= ken implementations to come up.

David
= =C2=A0
> On Wed, Jul 13, 2016 at 10:02 AM David Benjamin <davidben@chromium.org>
> wrote:
>
> > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett <davemgarrett@gmail.com><= br> > > wrote:
> >
> >> To be clear though, completely mandatory extensions, at least= as we're
> >> doing them here, are a new thing. TLS 1.2 relied on separate = messages for
> >> stuff, but we're front-loading everything into the Client= Hello to get
> >> reliable 1RTT (with the exception of HRR).
> >
> >
> > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario <hkario@redhat.com> wrote:
> >
> >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> >> > I don't believe an implementation which fails to sen= d supported_groups,
> >> > etc., in 1.3 would ever leave a developer's workstat= ion. It would not
> >> > interoperate with anything.
> >>
> >> it would interoperate with itself, and for some deployments t= hat's enough
> >> of a passing grade... (Even if you do interoperatbility testi= ng you
> >> do not check all possible permutations of features and settin= gs)
> >>
> >> I wholeheartedly agree with Dave here, error definitions shou= ld be strict
> >> (both on the when and what to do). One, because it allows to = better
> >> diagnose (in general, maybe not in this specific situation) p= roblems.
> >> Two, because you can write a strict negative test case that a= ctually
> >> checks for it.
> >
> >
> >
> > https://boringssl.googlesource.com/boringssl/+/= 1c256544dda26e4042c1af082580a1b87c9a690f/ssl/test/runner/runner.go#5646=
> > Also something I have plenty of experience with. We're obsess= ive about
> > adding this kind of test in BoringSSL[0]. :-)
> >
> > One doesn't need this alert to write a test for curve negotia= tion. Just
> > test that the handshake hits the usual codepath for there not bei= ng a
> > common cipher.
> >
> > This semi-mandatory extension isn't new in TLS 1.3, depending= on your 1.2
> > behavior. BoringSSL will already refuse to select an ECDHE cipher= if
> > supported_curves is missing. 1.2 does not require this, but we op= ted to do
> > it for simplicity[1].
> >
> > David
> >
> > [0] If anyone wants to try, I'm sure there is an implementati= on-agnostic
> > TLS protocol test suite one could extract out of that. It would t= ake some
> > wrangling as we cheat and condition on BoringSSL error codes, but= the nice
> > thing is I've already built up a large battery of tests here.=
> >
> > [1] Previously we always picking our most preferred curve if the = extension
> > was missing, like OpenSSL. But now our most preferred curve is X2= 5519, not
> > P-256. It did not seem worth kludging that when we could just dec= line the
> > cipher. No one's noticed, so I would say that worked.
> >

--
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
--001a11440f1c2279220537867596-- From nobody Wed Jul 13 09:36:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB6E12D137 for ; Wed, 13 Jul 2016 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFwFnb_vCGLg for ; Wed, 13 Jul 2016 09:36:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568CB126FDC for ; Wed, 13 Jul 2016 09:36:38 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6A4613453EF; Wed, 13 Jul 2016 16:30:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-99.brq.redhat.com [10.40.204.99]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6DGUodG010889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2016 12:30:52 -0400 From: Hubert Kario To: David Benjamin Date: Wed, 13 Jul 2016 18:30:41 +0200 Message-ID: <1638525.WFeDikGCus@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.5.7-202.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3321673.oJgfTBGyNN"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Jul 2016 16:30:53 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:36:40 -0000 --nextPart3321673.oJgfTBGyNN Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 13 July 2016 15:58:24 David Benjamin wrote: > On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wro= te: >=20 > > On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: > > > To be clear, I am not at all opposed to useful errors or strict p= olicing > > of > > > what the peer sends. That's all great. Indeed the linked test bel= ow makes > > > use of more specific error codes than TLS provides. But I would l= ike such > > > things to: > > > > > > 1. Be useful, either for debugging or because it rejects an inval= id > > > handshake that would otherwise go unnoticed. > > > 2. Come out naturally out of what the implementation would do any= way, to > > > keep complexity down. > > > > > > I'm also quite okay with budging on #2 where #1 is strong. Comple= xity is > > > the currency we pay for adding things. But I do not think this pa= rticular > > > error code passes #1 (the special-case is not useful and such a p= eer > > would > > > not be able to handshake against correct implementations anyway),= so I'm > > > not willing to sacrifice #2 for it. > > > > Then I fail to see how missing_extension does not flow out of corre= ct > > implementation (and from general RFC recommendations). > > > > You need to parse the Client Hello, and then sanity check it (lengt= h of > > session ID, validity of ciphers, lack of duplicate extensions, etc.= ). > > Making sure that mandatory extensions are in place in the same code= > > seems to me like a obvious place to do it. > > >=20 > The extension is not mandatory. Whether it is mandatory or not depend= s on > the cipher suite selected. The cipher suite selected depends on the > contents (or lack of) the extension. This makes checking things somew= hat > circular. not really, if there is a cipher suite that uses ECDHE key exchange, the extension must be there so sure, the check is not as simple as=20 if client_hello.client_version >=3D (3, 4): assert len(x for x in client_hello.extesnions if x.ext_type =3D=3D s= upported_groups) =3D=3D 1 but rather something like: if client_hello.client_version >=3D (3, 4) and any(x in client_hello.ci= pher_suites for x in Ciphers.ecdheKex): assert len([x for x in client_hello.extensions if x.ext_type =3D=3D = ExtensionType.supported_groups]) =3D=3D 1 but my point is that it doesn't require any information not available just after the message was parsed =20 > If it were simply mandatory, by all means, mandate a missing_extensio= n > alert. I still do not think it'd be very useful (I'm more interested = in > non-syntax-error cases), but I have no objections. it is "simply mandatory" if client hello includes ciphers that use ECDH= E > > In other words, you shouldn't delay checking if a particular extens= ion > > is present until the time you want to use it. If there is any chanc= e > > (or possible configuration) in which you would end up using it, you= > > should complain that the extension is missing or it is malformed. > > > > This way when you start to depend on it, things won't start breakin= g > > suddenly and you end up writing Yet Another Workaround for Broken > > Implementations=E2=84=A2 > > >=20 > I still do not see how returning handshake_failure (or whatever the "= no > common cipher" error is) for this case instead of missing_extension w= ill > cause broken implementations to come up. there are implementations that send incorrect version number to negotia= te tls version they want to negotiate i.e. they send (3, 2) when they want to negotiate TLS 1.0 in case of TLS 1.3, returning missing_extension makes it clear that the client hello sent by such an implementation was incomplete for TLS = 1.3 and it wouldn't work with *any* correct TLS 1.3 implementation unlike a handshake_failure which generally means that the server config= uration is incompatible with the client proposed parameters > > > On Wed, Jul 13, 2016 at 10:02 AM David Benjamin > > > wrote: > > > > > > > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett > > > > wrote: > > > > > > > >> To be clear though, completely mandatory extensions, at least = as we're > > > >> doing them here, are a new thing. TLS 1.2 relied on separate m= essages > > for > > > >> stuff, but we're front-loading everything into the ClientHello= to get > > > >> reliable 1RTT (with the exception of HRR). > > > > > > > > > > > > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario > > wrote: > > > > > > > >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > > > >> > I don't believe an implementation which fails to send > > supported_groups, > > > >> > etc., in 1.3 would ever leave a developer's workstation. It = would > > not > > > >> > interoperate with anything. > > > >> > > > >> it would interoperate with itself, and for some deployments th= at's > > enough > > > >> of a passing grade... (Even if you do interoperatbility testin= g you > > > >> do not check all possible permutations of features and setting= s) > > > >> > > > >> I wholeheartedly agree with Dave here, error definitions shoul= d be > > strict > > > >> (both on the when and what to do). One, because it allows to b= etter > > > >> diagnose (in general, maybe not in this specific situation) pr= oblems. > > > >> Two, because you can write a strict negative test case that ac= tually > > > >> checks for it. > > > > > > > > > > > > > > > > > > https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1= af082580a1b87c9a690f/ssl/test/runner/runner.go#5646 > > > > Also something I have plenty of experience with. We're obsessiv= e about > > > > adding this kind of test in BoringSSL[0]. :-) > > > > > > > > One doesn't need this alert to write a test for curve negotiati= on. Just > > > > test that the handshake hits the usual codepath for there not b= eing a > > > > common cipher. > > > > > > > > This semi-mandatory extension isn't new in TLS 1.3, depending o= n your > > 1.2 > > > > behavior. BoringSSL will already refuse to select an ECDHE ciph= er if > > > > supported_curves is missing. 1.2 does not require this, but we = opted > > to do > > > > it for simplicity[1]. > > > > > > > > David > > > > > > > > [0] If anyone wants to try, I'm sure there is an > > implementation-agnostic > > > > TLS protocol test suite one could extract out of that. It would= take > > some > > > > wrangling as we cheat and condition on BoringSSL error codes, b= ut the > > nice > > > > thing is I've already built up a large battery of tests here. > > > > > > > > [1] Previously we always picking our most preferred curve if th= e > > extension > > > > was missing, like OpenSSL. But now our most preferred curve is = X25519, > > not > > > > P-256. It did not seem worth kludging that when we could just d= ecline > > the > > > > cipher. No one's noticed, so I would say that worked. > > > > > > > > -- > > 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 Rep= ublic =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 --nextPart3321673.oJgfTBGyNN 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 iQIcBAABCgAGBQJXhmyxAAoJEJKo0bgB0vX1VFcQAI91nHJEYGjfpEo8/5mfiXhd z3F9qRAHDmoIjRVcSZfQ/Cavz1ZfDg9DDeD2GYLXfV8eAN6tgCT+e7AfmTtBPNNq Nm5Hz0uJHyZla3uDoMPzrDsny9nC5fuJZv1G7pIx0J8+28AMl9Ucw1Egdm7QZkqx AVQPR4ehSUojOQNaKO5cLLFhUzeL1UOSohTNHgtW9aS7ry9BsPyHuuv5isref+Cz HNa4mEdUNQaFU715ekkb43fV3/uCQnhDV+zX0kvAbM0nFjfhMNPCGAM/05dl0dow Rnwq/JG/k/BPt3TdvJ8hssz7caFznZhFNfxj1iSoLmb1iBx2gwkBmjgDMOSXexr6 SdUj7NbZnlGufsSIUP3AQo1k2RLpTMgOb60XELYy/f8JsbeIdHjtnBTGNUON6G+r DlNlI57+Osla3lbbM7jwl6FoQCtsrwwb5NZQxFLJDZwWkV4Ox/usarE4zQuQ2u6e Zme6VOzSmjsJE2+f9AgEYWwh7Oi8M/CVKtbRDYTQzlOYLdhH9ejeOUesClR2eg0E +5APd4URaLpjGh8C5CZut47oJISO/wmYGjIjvWmHH9kF9SPrGnPgr2dGtY1ClUbl 0OUcE13u4kxOImWNmhHz+YViyOdVtyn+lxTpN6bIwr24ecv5vIYH2wsfA8I4i1HP cgvjQ1sx0obOYSKcngRU =8PAg -----END PGP SIGNATURE----- --nextPart3321673.oJgfTBGyNN-- From nobody Wed Jul 13 10:01:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F002612D0C9 for ; Wed, 13 Jul 2016 10:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w90WRzZ8lKuO for ; Wed, 13 Jul 2016 10:01:53 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 428FA12B012 for ; Wed, 13 Jul 2016 10:01:53 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id i12so48559144ywa.1 for ; Wed, 13 Jul 2016 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tgwgv5CynsB8UOjlYEz8C2Q3p/nsGshx735owqGwFaE=; b=ebypDX2HsDVFkGYA9RsPApOhkPM6C+Z72TvcTckdXLA66ZlCo9OOILWCdHSdoFqSjz HWcGKCkzgzQK/XbweCNdkBFYw8J/AijOwMPjuhczGzN5dhyaRR8ogWopfB174GsnY/mG S8xnjYIJBOKTIz7DLvvi0fUspit1hm9R8QH/xVe8lwDxf1GSh8Q+Rd9x0y9ev9EJRGmA I8JyZxwFyGagGGyyliosIbc5U1qmgnlclZAzl7Nktz4dCB9sZa+PqVy1n3cKD5NaowV5 nlMXI6NPmUcsDtyQeCfJshfioFE2DekHqfpHXGESiDCZsgraKCUx8w6fc73+XXNMbR0V TAXw== 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; bh=Tgwgv5CynsB8UOjlYEz8C2Q3p/nsGshx735owqGwFaE=; b=D6UNi9o0acsjGBIHSLJnFIIf8Fl3938fgnJZLe8fsqxIgNpQ3jUZG9aQ+l8jA0xsU8 d98kpBRjHXfNpcPa7YZhJ1mbcwbtCxt54U+AttrYhDBZKQJamFlBWdsuDZMi6rJxy/On JlmX27csoil4SgSaiCMDeSIolU0HSocSFXG9ivWqfpypbGR+Upyy6A1au6liIG/eruRd 3rDocmLW8kpQ3AOmbiG5Jlbri6uiBJibtzargF/OiTVzSkopzpAQJKPUsTbsDkQcUKRI 8tIEwGCxaHmMx0UD2TFSCAafFFXq0kZ6hHPq82BKLAhHRpid+0UrCz1VOyZoTB+Z39u2 wyVQ== X-Gm-Message-State: ALyK8tK+uLE1uQ1cIbaBgi2N0T+QVZENdQUjn2IsSJ2PXO/bztFPLEFlyScsDe5GcARVt064OgP6/CkZiBHMOQ== X-Received: by 10.129.161.129 with SMTP id y123mr7501631ywg.214.1468429312512; Wed, 13 Jul 2016 10:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 10:01:13 -0700 (PDT) In-Reply-To: References: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 13 Jul 2016 10:01:13 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114f8db28d08cb053787571a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:01:56 -0000 --001a114f8db28d08cb053787571a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reinforcing what David says here: It's natural to pick the cipher suite first and then look for the key_share extension, so if, for instance, you pick a PSK-only cipher suite, then you wouldn't look for the key_share. Obviously, you could add a check that said that if an EC cipher suite was advertised, then you had to look for key shares even if you picked one, but it's not a check you otherwise need. -Ekr On Wed, Jul 13, 2016 at 8:58 AM, David Benjamin wrote: > On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wrote: > >> On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: >> > To be clear, I am not at all opposed to useful errors or strict >> policing of >> > what the peer sends. That's all great. Indeed the linked test below >> makes >> > use of more specific error codes than TLS provides. But I would like >> such >> > things to: >> > >> > 1. Be useful, either for debugging or because it rejects an invalid >> > handshake that would otherwise go unnoticed. >> > 2. Come out naturally out of what the implementation would do anyway, = to >> > keep complexity down. >> > >> > I'm also quite okay with budging on #2 where #1 is strong. Complexity = is >> > the currency we pay for adding things. But I do not think this >> particular >> > error code passes #1 (the special-case is not useful and such a peer >> would >> > not be able to handshake against correct implementations anyway), so I= 'm >> > not willing to sacrifice #2 for it. >> >> Then I fail to see how missing_extension does not flow out of correct >> implementation (and from general RFC recommendations). >> >> You need to parse the Client Hello, and then sanity check it (length of >> session ID, validity of ciphers, lack of duplicate extensions, etc.). >> Making sure that mandatory extensions are in place in the same code >> seems to me like a obvious place to do it. >> > > The extension is not mandatory. Whether it is mandatory or not depends on > the cipher suite selected. The cipher suite selected depends on the > contents (or lack of) the extension. This makes checking things somewhat > circular. > > If it were simply mandatory, by all means, mandate a missing_extension > alert. I still do not think it'd be very useful (I'm more interested in > non-syntax-error cases), but I have no objections. > > >> In other words, you shouldn't delay checking if a particular extension >> is present until the time you want to use it. If there is any chance >> (or possible configuration) in which you would end up using it, you >> should complain that the extension is missing or it is malformed. >> >> This way when you start to depend on it, things won't start breaking >> suddenly and you end up writing Yet Another Workaround for Broken >> Implementations=E2=84=A2 >> > > I still do not see how returning handshake_failure (or whatever the "no > common cipher" error is) for this case instead of missing_extension will > cause broken implementations to come up. > > David > > >> > On Wed, Jul 13, 2016 at 10:02 AM David Benjamin >> > wrote: >> > >> > > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett >> > > wrote: >> > > >> > >> To be clear though, completely mandatory extensions, at least as >> we're >> > >> doing them here, are a new thing. TLS 1.2 relied on separate >> messages for >> > >> stuff, but we're front-loading everything into the ClientHello to g= et >> > >> reliable 1RTT (with the exception of HRR). >> > > >> > > >> > > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario >> wrote: >> > > >> > >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: >> > >> > I don't believe an implementation which fails to send >> supported_groups, >> > >> > etc., in 1.3 would ever leave a developer's workstation. It would >> not >> > >> > interoperate with anything. >> > >> >> > >> it would interoperate with itself, and for some deployments that's >> enough >> > >> of a passing grade... (Even if you do interoperatbility testing you >> > >> do not check all possible permutations of features and settings) >> > >> >> > >> I wholeheartedly agree with Dave here, error definitions should be >> strict >> > >> (both on the when and what to do). One, because it allows to better >> > >> diagnose (in general, maybe not in this specific situation) problem= s. >> > >> Two, because you can write a strict negative test case that actuall= y >> > >> checks for it. >> > > >> > > >> > > >> > > >> https://boringssl.googlesource.com/boringssl/+/1c256544dda26e4042c1af082= 580a1b87c9a690f/ssl/test/runner/runner.go#5646 >> > > Also something I have plenty of experience with. We're obsessive abo= ut >> > > adding this kind of test in BoringSSL[0]. :-) >> > > >> > > One doesn't need this alert to write a test for curve negotiation. >> Just >> > > test that the handshake hits the usual codepath for there not being = a >> > > common cipher. >> > > >> > > This semi-mandatory extension isn't new in TLS 1.3, depending on you= r >> 1.2 >> > > behavior. BoringSSL will already refuse to select an ECDHE cipher if >> > > supported_curves is missing. 1.2 does not require this, but we opted >> to do >> > > it for simplicity[1]. >> > > >> > > David >> > > >> > > [0] If anyone wants to try, I'm sure there is an >> implementation-agnostic >> > > TLS protocol test suite one could extract out of that. It would take >> some >> > > wrangling as we cheat and condition on BoringSSL error codes, but th= e >> nice >> > > thing is I've already built up a large battery of tests here. >> > > >> > > [1] Previously we always picking our most preferred curve if the >> extension >> > > was missing, like OpenSSL. But now our most preferred curve is >> X25519, not >> > > P-256. It did not seem worth kludging that when we could just declin= e >> the >> > > cipher. No one's noticed, so I would say that worked. >> > > >> >> -- >> 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 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114f8db28d08cb053787571a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reinforcing what David says here:
It's = natural to pick the cipher suite first and then look for the key_share exte= nsion, so if, for instance, you pick a PSK-only cipher suite, then you woul= dn't look for the key_share.

Obviously, you co= uld add a check that said that if an EC cipher suite was advertised, then y= ou had to look for key shares even if you picked one, but it's not a ch= eck you otherwise need.

-Ekr

<= div>


On Wed, Jul 13, 2016 at 8:58 AM, David Benjamin <dav= idben@chromium.org> wrote:
=
On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario <hkario@redhat.com> wrote:
=
On Wednesday 13 July 2016 14:43:58 David Ben= jamin wrote:
> To be clear, I am not at all opposed to useful errors or strict polici= ng of
> what the peer sends. That's all great. Indeed the linked test belo= w makes
> use of more specific error codes than TLS provides. But I would like s= uch
> things to:
>
> 1. Be useful, either for debugging or because it rejects an invalid > handshake that would otherwise go unnoticed.
> 2. Come out naturally out of what the implementation would do anyway, = to
> keep complexity down.
>
> I'm also quite okay with budging on #2 where #1 is strong. Complex= ity is
> the currency we pay for adding things. But I do not think this particu= lar
> error code passes #1 (the special-case is not useful and such a peer w= ould
> not be able to handshake against correct implementations anyway), so I= 'm
> not willing to sacrifice #2 for it.

Then I fail to see how missing_extension does not flow out of correct
implementation (and from general RFC recommendations).

You need to parse the Client Hello, and then sanity check it (length of
session ID, validity of ciphers, lack of duplicate extensions, etc.).
Making sure that mandatory extensions are in place in the same code
seems to me like a obvious place to do it.

<= /span>
The extension is not mandatory. Whether it is mandatory or not d= epends on the cipher suite selected. The cipher suite selected depends on t= he contents (or lack of) the extension. This makes checking things somewhat= circular.

If it were simply mandatory, by all mea= ns, mandate a missing_extension alert. I still do not think it'd be ver= y useful (I'm more interested in non-syntax-error cases), but I have no= objections.
=C2=A0
In other words, you shouldn't delay checking if a particular extension<= br> is present until the time you want to use it. If there is any chance
(or possible configuration) in which you would end up using it, you
should complain that the extension is missing or it is malformed.

This way when you start to depend on it, things won't start breaking suddenly and you end up writing Yet Another Workaround for Broken
Implementations=E2=84=A2

I still= do not see how returning handshake_failure (or whatever the "no commo= n cipher" error is) for this case instead of missing_extension will ca= use broken implementations to come up.

David
=C2=A0
> On Wed, Jul 13, 2016 at 10:02 AM David Benjamin <davidben@chromium.org>
> wrote:
>
> > On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett <davemgarrett@gmail.com><= br> > > wrote:
> >
> >> To be clear though, completely mandatory extensions, at least= as we're
> >> doing them here, are a new thing. TLS 1.2 relied on separate = messages for
> >> stuff, but we're front-loading everything into the Client= Hello to get
> >> reliable 1RTT (with the exception of HRR).
> >
> >
> > On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario <hkario@redhat.com> wrote:
> >
> >> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> >> > I don't believe an implementation which fails to sen= d supported_groups,
> >> > etc., in 1.3 would ever leave a developer's workstat= ion. It would not
> >> > interoperate with anything.
> >>
> >> it would interoperate with itself, and for some deployments t= hat's enough
> >> of a passing grade... (Even if you do interoperatbility testi= ng you
> >> do not check all possible permutations of features and settin= gs)
> >>
> >> I wholeheartedly agree with Dave here, error definitions shou= ld be strict
> >> (both on the when and what to do). One, because it allows to = better
> >> diagnose (in general, maybe not in this specific situation) p= roblems.
> >> Two, because you can write a strict negative test case that a= ctually
> >> checks for it.
> >
> >
> >
> > https://boringssl.googlesource.com/boringssl/+/= 1c256544dda26e4042c1af082580a1b87c9a690f/ssl/test/runner/runner.go#5646=
> > Also something I have plenty of experience with. We're obsess= ive about
> > adding this kind of test in BoringSSL[0]. :-)
> >
> > One doesn't need this alert to write a test for curve negotia= tion. Just
> > test that the handshake hits the usual codepath for there not bei= ng a
> > common cipher.
> >
> > This semi-mandatory extension isn't new in TLS 1.3, depending= on your 1.2
> > behavior. BoringSSL will already refuse to select an ECDHE cipher= if
> > supported_curves is missing. 1.2 does not require this, but we op= ted to do
> > it for simplicity[1].
> >
> > David
> >
> > [0] If anyone wants to try, I'm sure there is an implementati= on-agnostic
> > TLS protocol test suite one could extract out of that. It would t= ake some
> > wrangling as we cheat and condition on BoringSSL error codes, but= the nice
> > thing is I've already built up a large battery of tests here.=
> >
> > [1] Previously we always picking our most preferred curve if the = extension
> > was missing, like OpenSSL. But now our most preferred curve is X2= 5519, not
> > P-256. It did not seem worth kludging that when we could just dec= line the
> > cipher. No one's noticed, so I would say that worked.
> >

--
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

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


--001a114f8db28d08cb053787571a-- From nobody Wed Jul 13 10:13:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0815812D13D for ; Wed, 13 Jul 2016 10:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85j_BfrJsXq7 for ; Wed, 13 Jul 2016 10:13:35 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 BF6DF12D08E for ; Wed, 13 Jul 2016 10:13:34 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w127so49755763ywf.3 for ; Wed, 13 Jul 2016 10:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0TyEHUm87L5b4MezPw3A61CRFvVrh7jO1+kQB4r8oCM=; b=x5nLP68odybXvp7FmBORTbMUnHI1zMCytvvK4DcX+H+We1Z7Pm/iLzxT+wNi91VK9b HRFpCb6+fueHcstdbvPfjobaUckBLqk3IpW5L+w8HybhcOZ5se3X2TCjNKIrLZwLeu8/ DCHCWyPP1VC5Y8ochEyrFkTIPUIM4WHFgGjUYAw5Re/O9V7wcR5rREz17wxO47XFHZUg g1kwX/cQrtz5jjF/cc+9LfNCmbmugBAWnw7OIuBIQGcQlb/lCdChw+3Hapja13RueoaX RnO2oxfErkqxtTopljUTm+DWa9tkXsHU8jmkHvbmnIeHwggjdfB956I7WBba4Z9erb33 whmg== 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; bh=0TyEHUm87L5b4MezPw3A61CRFvVrh7jO1+kQB4r8oCM=; b=XAkQwAWbZ9W0UsHctEE/wqrvVH54TVBVtUY050PDBcptrSmX6mOc8D9gKtrRHPu83m r6PDKOF3+8IDp0oqwSuaQBFhiB3Z+567wMAqX+4E0JTYwiwLlP6k83iOI1oONSuBawb9 it0i1MNFtkxdftnUJy+wkhRrSnDQs53s+a73NmVSyEssXafFu7SCHEGUG6ywvLbrbkAD LSXvloo11Yub0wkeDR2oQmQfBq+nZ+Gu675NXh19E+fcXJ/vCcea0MlrrPxSQIN4kpXn 6B6St6HnFkR6Rgy9IaV7KYeGcJJnym8BTAqj0l0NGrUPiXJ7kbIXLppy7JcU9dt7m3Ba qndg== X-Gm-Message-State: ALyK8tLo/i7Ys4rXmFRIMXSuopsScxAoYJzh2o41dOxewN6JjfrbwNg48HZ3ELdsLoKEe/22zh3FMihLy8d5bw== X-Received: by 10.13.201.134 with SMTP id l128mr7039489ywd.93.1468430013696; Wed, 13 Jul 2016 10:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 10:12:54 -0700 (PDT) From: Eric Rescorla Date: Wed, 13 Jul 2016 10:12:54 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e630e5839b20537878167 Archived-At: Subject: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:13:37 -0000 --001a114e630e5839b20537878167 Content-Type: text/plain; charset=UTF-8 Hi folks, There have been a lot of discussions about whether we should try to refactor cipher-suite negotiation to be less monolithic in the cipher suite. I've generally been on the "no" side of that on cost/benefit grounds as well as not quite seeing how it would fit into the rest of the infrastructure. However, now that we're starting to get full implementations, and it's becoming clearer how the new elements (principally PSK-resumption and key_shares) interact with cipher suites, I've started to think that in fact we may be able to clean things up. One proposal for this is below [0]. I know this is pretty late in the process, but if we do want this change it's better to do it now. I'm sure we'll need to discuss this in Berlin, but in the meantime, fire away. The basic idea here is to factor out the TLS 1.3 negotiation into three mostly orthogonal axes. - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 - Key exchange -- indicated by the key_shares and pre_shared_key extensions - Authentication -- indicated the signature_algorithms and pre_shared_key extensions A proposal for how to do this is below. See the end for other options, caveats, etc. If we take PSK out of the picture, this gives us a very simple structure: - The client offers a set of key_shares and the server picks one that it likes [1]. - The client offers a list of signature_algorithms and the server picks a certificate/key that matches that list and signs with it. In other words, we just eliminate the redundancy with the cipher suite indications. This leaves is with the question of how to handle the existing TLS 1.2 cipher suites. We can either assign new cipher suites or say that any cipher suite with *_aead_alg_hash means that we support aead_alg_hash. Matter of taste. PSK is handled by extending the concept of PSK flags that we already have in NewSessionTicket to also include uses of PSKs where you indicate the way in which you are using the PSK (or want it to be used). There a bunch of ways to encode this. I'll give you the one I mostly prefer below and then a one that's a smaller change but I think a little less elegant at the end [note #4]. First, we replace the flags word of the different KE modes for the ticket with lists of code points, as below: enum { psk_ke(0), // PSK key exchange psk_dhe_ke(1), // PSK + DHE key exchange (255) } PskKeModes; And then add new code points for being able to use the PSK with and without signatures (from the server). We had pretty rough consensus in B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01] is part of the motivation for this idea. enum { psk_auth(0), // PSK only psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5] (255) } PskAuthModes; This gives us the following NewSessionTicket message where we have replaced the flags word with two (potentially ordered) lists: struct { uint32 ticket_lifetime; PskAuthModes auth_modes<1..255>; PskKeModes ke_modes<1..255>; TicketExtension extensions<2..2^16-2>; opaque ticket<0..2^16-1>; } NewSessionTicket; We now need a way to indicate that the server will do 0-RTT (previously in the flags word) so we add a new 0-RTT extension: struct { uint32 ticket_age_add; } TicketEarlyDataInfo; This has two nice properties: - You don't need to provide ticket_age_add when you don't do 0-RTT (and it is silly if you don't). - It exercises this extension mechanism, which is good for future-proofing. PreSharedKeyExtension becomes: struct { PskAuthMode auth_modes<1..255>; PskKeModee ke_modes<1..255>; opaque identity<0..2^16-1>; } PskIdentity; struct { select (Role) { case client: PskIdentity identities<2..2^16-1>; case server: PskAuthMode auth_mode; PskKeMode ke_mode; uint16 selected_identity; } } PreSharedKeyExtension; The way to interpret these is as follows: - With each identity, the client indicates to the server which modes it can be used with. - When the server responds with an identity, it tells you how it used it. You might ask why you need the server to indicate what it did. The reason is that we would like the client to know in advance (at the time of the ServerHello) whether the server has sent Certificate/CertificateVerify rather than having to figure it out from what messages the server sends. The ke_mode field is redundant (because you also infer it from the server key_shares) but I added it for parity. I haven't implemented this yet (am going to try to take a crack at that before Berlin) but I believe based on experience with the NSS negotiation that it will be simpler. I know it removes a bunch of odd edge cases which have accumulated over the years, but maybe it adds others. -Ekr BONUS MATERIAL 0. I've discussed this with and/or borrowed ideas from Richard Barnes, David Benjamin, Karthik Bhargavan, Dave Garrett, Nick Sullivan, Martin Thomson, and others. Thanks to those guys, but blame me if you think this is bad. 1. The other major encoding option here is to have dummy group/signature_algorithm indicators that tell you whether you can use a pure PSK. When I and others discussed this, the consensus was that that was less clean. 2. One question that comes up at the same time is whether we should allow multiple key shares to be used, which is a structure that this makes pretty easy. Basically, the server would just supply as many counter-shares as it wanted and then we'd need a defined order for how they were inserted into the key schedule. This feature would be nice for enabling post-quantum, but probably better to just define code points. 3. Note that because of this PSK-PRF interaction, PSK isn't totally orthogonal with AEAD/PRF. I.e., you cannot use the same PSK with HKDF-SHA256 and HKDF-SHA384 if you want to be on the cryptographic fairway, but I think it should be easy enough to filter out the cipher suites to make that work. 4. The other major alternative is just to use the flags bits. So we would extend and generalize the flags as shown below. enum { early_data(1), dhe_psk_ke(2), psk_ke(4), psk_auth(8), // New (no server cert) sig_psk_auth(16) // New (sign with server cert) } PskUsageFlags; These new flags have the expected meaning, namely: psk_auth The server will do connections with just PSK authentication (equivalent to PSK now) sig_psk_auth The server will do connections with PSK plus signature (not currently specified). Then we update the PreSharedKeyExtension as follows: struct { uint32 usage_flags; opaque identity<0..2^16-1>; } PskIdentity; struct { select (Role) { case client: PskIdentity identities<2..2^16-1>; case server: uint32 usage_flags; // New (one from each category) uint16 selected_identity; } } PreSharedKeyExtension; The idea here is: - The client indicates how each PSK can be used (by flags, which need to be a subset of the ticket flags). - The server can pick a PSK and indicate how it was actually used. For instance, if the client wants to do PSK w/ ECDHE it would indicate dhe_psk_ke. If it only wants PSK it would indicate psk_ke. If it was willing to do both, it would indicate the bitwise OR. Similarly, if the client wants PSK for auth, it would indicate psk_auth. If it wants the server to sign, it indicates sig_psk_auth, and so on (indicating neither is silly because it makes the key unusable). By contrast, the server just sets the bits that it actually used. I.e., if it sets psk_auth, that means it won't be signing and there is no Certificate/CertificateVerify. OTOH if it sets sign_psk_auth, that means it will be signing and there will be a Certificate/CertificateVerify. This leaves early data. As above, the client uses the early_data bit to indicate that the PSK was used to encrypt early data (obviously, this can just be one key) and the server uses it to indicate that it accepted early data. ticket_age needs to go in its own extension, but that's easy enough. 5. Note: this would allow for modes where the server signs over a PSK handshake with no DHE at all. The resumption_ctx mechanism is intended to ensure that that is OK, but we'd need to confirm with analysis. --001a114e630e5839b20537878167 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

There have been a = lot of discussions about whether we should try to
refactor cipher= -suite negotiation to be less monolithic in the cipher
suite. I&#= 39;ve generally been on the "no" side of that on cost/benefit
grounds as well as not quite seeing how it would fit into the rest
of the infrastructure. However, now that we're starting to get= full
implementations, and it's becoming clearer how the new = elements
(principally PSK-resumption and key_shares) interact wit= h cipher
suites, I've started to think that in fact we may be= able to clean
things up. One proposal for this is below [0]. I k= now this is
pretty late in the process, but if we do want this ch= ange it's
better to do it now.

I'= ;m sure we'll need to discuss this in Berlin, but in the meantime,
fire away.


The basic idea her= e is to factor out the TLS 1.3 negotiation into three
mostly orth= ogonal axes.=C2=A0

- Symmetric cipher/PRF =C2=A0--= indicated by the cipher suite list as in TLS 1.2
- Key exchange = -- indicated by the key_shares and pre_shared_key extensions
- Au= thentication -- indicated the signature_algorithms and pre_shared_key
=
=C2=A0 extensions

A proposal for how to do th= is is below. See the end for other options,
caveats, etc.


If we take PSK out of the picture, this gi= ves us a very simple structure:

- The client offer= s a set of key_shares and the server picks one that it
=C2=A0 lik= es [1].
- The client offers a list of signature_algorithms and th= e server picks
=C2=A0 a certificate/key that matches that list an= d signs with it.

In other words, we just eliminate= the redundancy with the cipher suite
indications. This leaves is= with the question of how to handle the
existing TLS 1.2 cipher s= uites. We can either assign new cipher suites
or say that any cip= her suite with *_aead_alg_hash means that we
support aead_alg_has= h. Matter of taste.


PSK is handled = by extending the concept of PSK flags that we already
have in New= SessionTicket to also include uses of PSKs where you
indicate the= way in which you are using the PSK (or want it to be
used). Ther= e a bunch of ways to encode this. I'll give you the one I
mos= tly prefer below and then a one that's a smaller change but I think
a little less elegant at the end [note #4].

First, we replace the flags word of the different KE modes for the
ticket with lists of code points, as below:

=C2= =A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0psk_ke(0), =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0// PSK key exchange
=C2=A0 =C2=A0 =C2=A0psk_dhe_= ke(1), =C2=A0 =C2=A0 =C2=A0// PSK + DHE key exchange
=C2=A0 =C2= =A0 =C2=A0(255)
=C2=A0 =C2=A0} PskKeModes;

And then add new code points for being able to use the PSK with and
without signatures (from the server). We had pretty rough consensus i= n
B-A that we needed this mode and [draft-thomson-tls-0rtt-and-ce= rts-01]
is part of the motivation for this idea.

=C2=A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0psk_auth(0), =C2= =A0 =C2=A0 =C2=A0 =C2=A0// PSK only
=C2=A0 =C2=A0 =C2=A0psk_sign_= auth(1), =C2=A0 // PSK + a signature (as in draft-thomson) [5]
= =C2=A0 =C2=A0 =C2=A0(255)
=C2=A0 =C2=A0} PskAuthModes;
=
This gives us the following NewSessionTicket message where w= e have
replaced the flags word with two (potentially ordered) lis= ts:

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0uint32 ticket_lifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0P= skAuthModes auth_modes<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= PskKeModes ke_modes<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0Tic= ketExtension extensions<2..2^16-2>;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0opaque ticket<0..2^16-1>;
=C2=A0 =C2=A0} NewSessionTi= cket;

We now need a way to indicate that the serve= r will do 0-RTT (previously
in the flags word) so we add a new 0-= RTT extension:

=C2=A0 =C2=A0struct {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_age_add;
=C2=A0 =C2=A0} Tic= ketEarlyDataInfo;
=C2=A0 =C2=A0
This has two nice prope= rties:

- You don't need to provide ticket_age_= add when you don't do 0-RTT
=C2=A0 (and it is silly if you do= n't).
- It exercises this extension mechanism, which is good = for future-proofing.


PreSharedKeyEx= tension becomes:

=C2=A0 =C2=A0 struct {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0PskAuthMode auth_modes<1..255>;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0PskKeModee ke_modes<1..255>;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0opaque identity<0..2^16-1>;=C2=A0
= =C2=A0 =C2=A0 } PskIdentity;

=C2=A0 =C2=A0 struct = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PskIdentity identiti= es<2..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 case server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0PskAuthMode auth_mode;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PskKeMode ke_mode;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 selected_iden= tity;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0= =C2=A0} PreSharedKeyExtension;

The way to interpr= et these is as follows:

- With each identity, the = client indicates to the server which modes
=C2=A0 it can be used = with.
- When the server responds with an identity, it tells you h= ow it
=C2=A0 used it.

You might ask why = you need the server to indicate what it did.=C2=A0 The
reason is = that we would like the client to know in advance (at the
time of = the ServerHello) whether the server has sent
Certificate/Certific= ateVerify rather than having to figure it out from
what messages = the server sends. The ke_mode field is redundant
(because you als= o infer it from the server key_shares) but I added it
for parity.=

I haven't implemented this yet (am going to t= ry to take a crack at that
before Berlin) but I believe based on = experience with the NSS
negotiation that it will be simpler. I kn= ow it removes a bunch of odd
edge cases which have accumulated ov= er the years, but maybe it adds
others.

= -Ekr


BONUS MATERIAL
0. I&= #39;ve discussed this with and/or borrowed ideas from Richard Barnes,
=
David Benjamin, Karthik Bhargavan, Dave Garrett, Nick Sullivan, Martin=
Thomson, and others. Thanks to those guys, but blame me if you t= hink
this is bad.

1. The other major enc= oding option here is to have dummy
group/signature_algorithm indi= cators that tell you whether you can use
a pure PSK. When I and o= thers discussed this, the consensus was that
that was less clean.=

2. One question that comes up at the same time is= whether we should
allow multiple key shares to be used, which is= a structure that this
makes pretty easy. Basically, the server w= ould just supply as many
counter-shares as it wanted and then we&= #39;d need a defined order for how
they were inserted into the ke= y schedule. This feature would be nice
for enabling post-quantum,= but probably better to just define
<PQ-Algorithm + Curve> = code points.

3. Note that because of this PSK-PRF = interaction, PSK isn't totally
orthogonal with AEAD/PRF. I.e.= , you cannot use the same PSK with
HKDF-SHA256 and HKDF-SHA384 if= you want to be on the cryptographic
fairway, but I think it shou= ld be easy enough to filter out the cipher
suites to make that wo= rk.

4. The other major alternative is just to use = the flags bits. So we
would extend and generalize the flags as sh= own below.

=C2=A0 =C2=A0enum {
=C2=A0 = =C2=A0 =C2=A0early_data(1),
=C2=A0 =C2=A0 =C2=A0dhe_psk_ke(2),
=C2=A0 =C2=A0 =C2=A0psk_ke(4),
=C2=A0 =C2=A0 =C2=A0psk_au= th(8), =C2=A0 =C2=A0 =C2=A0 =C2=A0 // New (no server cert)
=C2=A0= =C2=A0 =C2=A0sig_psk_auth(16) =C2=A0 =C2=A0 // New (sign with server cert)=
=C2=A0 =C2=A0} PskUsageFlags;

These new= flags have the expected meaning, namely:

psk_auth= =C2=A0 =C2=A0 =C2=A0 =C2=A0 The server will do connections with just
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PSK auth= entication (equivalent to PSK now)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
sig_psk_auth =C2=A0 =C2=A0 The= server will do connections with PSK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0plus signature (not currently specified).=


Then we update the PreSharedKeyExt= ension as follows:

=C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 usage_flags;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque identity<0..2^16-1>;=C2=A0
=C2=A0 =C2=A0 } PskIdentity;
=C2=A0 =C2=A0=C2=A0
=C2= =A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Rol= e) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ps= kIdentity identities<2..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 case server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 usage_flags; =C2=A0// New (one fr= om each category)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0uint16 selected_identity;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0} PreSharedKeyExtension;
=

The idea here is:

- The client= indicates how each PSK can be used (by flags, which
=C2=A0 need = to be a subset of the ticket flags).
- The server can pick a PSK = and indicate how it was actually
=C2=A0 used.

For instance, if the client wants to do PSK w/ ECDHE it would indicat= e
dhe_psk_ke. If it only wants PSK it would indicate psk_ke. If i= t was
willing to do both, it would indicate the bitwise OR.
=

Similarly, if the client wants PSK for auth, it would i= ndicate
psk_auth. If it wants the server to sign, it indicates si= g_psk_auth,
and so on (indicating neither is silly because it mak= es the key
unusable).

By contrast, the s= erver just sets the bits that it actually used.
I.e., if it sets = psk_auth, that means it won't be signing and
there is no Cert= ificate/CertificateVerify. OTOH if it sets
sign_psk_auth, that me= ans it will be signing and there will
be a Certificate/Certificat= eVerify.

This leaves early data. As above, the cli= ent uses the early_data
bit to indicate that the PSK was used to = encrypt early data
(obviously, this can just be one key) and the = server uses it to
indicate that it accepted early data. ticket_ag= e needs to go in
its own extension, but that's easy enough.


5. Note: this would allow for modes = where the server signs over a PSK
handshake with no DHE at all. T= he resumption_ctx mechanism is intended
to ensure that that is OK= , but we'd need to confirm with analysis.

--001a114e630e5839b20537878167-- From nobody Wed Jul 13 10:22:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395C12D16C for ; Wed, 13 Jul 2016 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WQUt44JlIUT for ; Wed, 13 Jul 2016 10:22:19 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA50C12B03C for ; Wed, 13 Jul 2016 10:22:18 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id i12so49111830ywa.1 for ; Wed, 13 Jul 2016 10:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qTuYnYmTIeByBQXqQAwhMpWgNWiWeKYH8MAypHLRVuE=; b=lEGFFvINtfUp7F1DNzClnjq4RjjJNw+COE4G8rNXtrutMzKPO64JBrTjiDESEX1vrN FVXwMRLuZiUNRGuf7oZeTyFtcL+VJyMTkJ5k78AlAfOfEjkq7DvE4mehsiMvNC4eYPzc 5eKXH4Q2eu2vSyOs3dd12/rSquflNpzyZWv3dtEWqkelBUSI/3w5LXS2F1s6p4mP/x3r 7PdgyIDGhQ4CMW9Yh2+HUuwWKnvvTG9ZPTTmjJyZHQLZDvBDb3VXjPYFBjUfyn/Lwm7F eINoJVLoSolUmRa8loszPOeftOQV3VeHNXDNNE2rwm+drnBF6HsQS7jSZYaMllaLJ2yl PLiA== 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; bh=qTuYnYmTIeByBQXqQAwhMpWgNWiWeKYH8MAypHLRVuE=; b=QLKgyWr34LQ59xKHP8G8rs2Dt+tM5ux/rdpFV2rx3iAp+f4xnpZjaFWbzCTvX3m4dt W5OMIpprfqSps18o9pe4MqgVlKFNVwZyjZlH6YJVkd+YJf9cnXTpnir+8DL8CO3RHxGd +J8TWw4VareH+7DTQj91C45Am0BvzHUtwZ0UPTfidUScTcqyAGkSwelH4U2Uzlg13Z8v acB+F5z2vK7vXQZ0ElX2FrjRcUrr/jz/L3zrcDE+Nj7tNSzSDj/07mXbIrs9nClemNIS xvR0pj54X9eOTZFPmJib5NbINZCR0eZniIeCjvg45xmnzqIgtNGesQQurCorQfH01MX7 VMyw== X-Gm-Message-State: ALyK8tL7IYrHk/7TstP/ancoQBSrHq63VYI6PddmTDzeRxLKPQ+LmxvgJUQELxsZQDUNBD8GM3X7n1W4tYFs9g== X-Received: by 10.129.39.200 with SMTP id n191mr7413330ywn.16.1468430537955; Wed, 13 Jul 2016 10:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 10:21:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 13 Jul 2016 10:21:38 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1141826a97c8fc053787a0d9 Archived-At: Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:22:21 -0000 --001a1141826a97c8fc053787a0d9 Content-Type: text/plain; charset=UTF-8 Replying to myself: We obviously don't *need* to do this. We have working implementations that use the current syntax, so we know it can be done, and "finished is a feature", so we have to balance against that whether this is a better syntax. OTOH, if you think this is a worse syntax, then it's easy. :) -Ekr On Wed, Jul 13, 2016 at 10:12 AM, Eric Rescorla wrote: > Hi folks, > > There have been a lot of discussions about whether we should try to > refactor cipher-suite negotiation to be less monolithic in the cipher > suite. I've generally been on the "no" side of that on cost/benefit > grounds as well as not quite seeing how it would fit into the rest > of the infrastructure. However, now that we're starting to get full > implementations, and it's becoming clearer how the new elements > (principally PSK-resumption and key_shares) interact with cipher > suites, I've started to think that in fact we may be able to clean > things up. One proposal for this is below [0]. I know this is > pretty late in the process, but if we do want this change it's > better to do it now. > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > fire away. > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > > A proposal for how to do this is below. See the end for other options, > caveats, etc. > > > If we take PSK out of the picture, this gives us a very simple structure: > > - The client offers a set of key_shares and the server picks one that it > likes [1]. > - The client offers a list of signature_algorithms and the server picks > a certificate/key that matches that list and signs with it. > > In other words, we just eliminate the redundancy with the cipher suite > indications. This leaves is with the question of how to handle the > existing TLS 1.2 cipher suites. We can either assign new cipher suites > or say that any cipher suite with *_aead_alg_hash means that we > support aead_alg_hash. Matter of taste. > > > PSK is handled by extending the concept of PSK flags that we already > have in NewSessionTicket to also include uses of PSKs where you > indicate the way in which you are using the PSK (or want it to be > used). There a bunch of ways to encode this. I'll give you the one I > mostly prefer below and then a one that's a smaller change but I think > a little less elegant at the end [note #4]. > > First, we replace the flags word of the different KE modes for the > ticket with lists of code points, as below: > > enum { > psk_ke(0), // PSK key exchange > psk_dhe_ke(1), // PSK + DHE key exchange > (255) > } PskKeModes; > > And then add new code points for being able to use the PSK with and > without signatures (from the server). We had pretty rough consensus in > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01] > is part of the motivation for this idea. > > enum { > psk_auth(0), // PSK only > psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5] > (255) > } PskAuthModes; > > This gives us the following NewSessionTicket message where we have > replaced the flags word with two (potentially ordered) lists: > > struct { > uint32 ticket_lifetime; > PskAuthModes auth_modes<1..255>; > PskKeModes ke_modes<1..255>; > TicketExtension extensions<2..2^16-2>; > opaque ticket<0..2^16-1>; > } NewSessionTicket; > > We now need a way to indicate that the server will do 0-RTT (previously > in the flags word) so we add a new 0-RTT extension: > > struct { > uint32 ticket_age_add; > } TicketEarlyDataInfo; > > This has two nice properties: > > - You don't need to provide ticket_age_add when you don't do 0-RTT > (and it is silly if you don't). > - It exercises this extension mechanism, which is good for future-proofing. > > > PreSharedKeyExtension becomes: > > struct { > PskAuthMode auth_modes<1..255>; > PskKeModee ke_modes<1..255>; > opaque identity<0..2^16-1>; > } PskIdentity; > > struct { > select (Role) { > case client: > PskIdentity identities<2..2^16-1>; > case server: > PskAuthMode auth_mode; > PskKeMode ke_mode; > uint16 selected_identity; > } > } PreSharedKeyExtension; > > The way to interpret these is as follows: > > - With each identity, the client indicates to the server which modes > it can be used with. > - When the server responds with an identity, it tells you how it > used it. > > You might ask why you need the server to indicate what it did. The > reason is that we would like the client to know in advance (at the > time of the ServerHello) whether the server has sent > Certificate/CertificateVerify rather than having to figure it out from > what messages the server sends. The ke_mode field is redundant > (because you also infer it from the server key_shares) but I added it > for parity. > > I haven't implemented this yet (am going to try to take a crack at that > before Berlin) but I believe based on experience with the NSS > negotiation that it will be simpler. I know it removes a bunch of odd > edge cases which have accumulated over the years, but maybe it adds > others. > > -Ekr > > > BONUS MATERIAL > 0. I've discussed this with and/or borrowed ideas from Richard Barnes, > David Benjamin, Karthik Bhargavan, Dave Garrett, Nick Sullivan, Martin > Thomson, and others. Thanks to those guys, but blame me if you think > this is bad. > > 1. The other major encoding option here is to have dummy > group/signature_algorithm indicators that tell you whether you can use > a pure PSK. When I and others discussed this, the consensus was that > that was less clean. > > 2. One question that comes up at the same time is whether we should > allow multiple key shares to be used, which is a structure that this > makes pretty easy. Basically, the server would just supply as many > counter-shares as it wanted and then we'd need a defined order for how > they were inserted into the key schedule. This feature would be nice > for enabling post-quantum, but probably better to just define > code points. > > 3. Note that because of this PSK-PRF interaction, PSK isn't totally > orthogonal with AEAD/PRF. I.e., you cannot use the same PSK with > HKDF-SHA256 and HKDF-SHA384 if you want to be on the cryptographic > fairway, but I think it should be easy enough to filter out the cipher > suites to make that work. > > 4. The other major alternative is just to use the flags bits. So we > would extend and generalize the flags as shown below. > > enum { > early_data(1), > dhe_psk_ke(2), > psk_ke(4), > psk_auth(8), // New (no server cert) > sig_psk_auth(16) // New (sign with server cert) > } PskUsageFlags; > > These new flags have the expected meaning, namely: > > psk_auth The server will do connections with just > PSK authentication (equivalent to PSK now) > > sig_psk_auth The server will do connections with PSK > plus signature (not currently specified). > > > Then we update the PreSharedKeyExtension as follows: > > struct { > uint32 usage_flags; > opaque identity<0..2^16-1>; > } PskIdentity; > > struct { > select (Role) { > case client: > PskIdentity identities<2..2^16-1>; > case server: > uint32 usage_flags; // New (one from each category) > uint16 selected_identity; > } > } PreSharedKeyExtension; > > The idea here is: > > - The client indicates how each PSK can be used (by flags, which > need to be a subset of the ticket flags). > - The server can pick a PSK and indicate how it was actually > used. > > For instance, if the client wants to do PSK w/ ECDHE it would indicate > dhe_psk_ke. If it only wants PSK it would indicate psk_ke. If it was > willing to do both, it would indicate the bitwise OR. > > Similarly, if the client wants PSK for auth, it would indicate > psk_auth. If it wants the server to sign, it indicates sig_psk_auth, > and so on (indicating neither is silly because it makes the key > unusable). > > By contrast, the server just sets the bits that it actually used. > I.e., if it sets psk_auth, that means it won't be signing and > there is no Certificate/CertificateVerify. OTOH if it sets > sign_psk_auth, that means it will be signing and there will > be a Certificate/CertificateVerify. > > This leaves early data. As above, the client uses the early_data > bit to indicate that the PSK was used to encrypt early data > (obviously, this can just be one key) and the server uses it to > indicate that it accepted early data. ticket_age needs to go in > its own extension, but that's easy enough. > > > 5. Note: this would allow for modes where the server signs over a PSK > handshake with no DHE at all. The resumption_ctx mechanism is intended > to ensure that that is OK, but we'd need to confirm with analysis. > > --001a1141826a97c8fc053787a0d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Replying to myself:
We obviously don't *need* to d= o this. We have working implementations that use the current syntax, so we = know it can be done, and "finished is a feature", so we have to b= alance against that whether this is a better syntax. OTOH, if you think thi= s is a worse syntax, then it's easy. :)

-Ekr


On Wed, Jul 13, 2016 at 10:12 AM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:
Hi= folks,

There have been a lot of discussions about= whether we should try to
refactor cipher-suite negotiation to be= less monolithic in the cipher
suite. I've generally been on = the "no" side of that on cost/benefit
grounds as well a= s not quite seeing how it would fit into the rest
of the infrastr= ucture. However, now that we're starting to get full
implemen= tations, and it's becoming clearer how the new elements
(prin= cipally PSK-resumption and key_shares) interact with cipher
suite= s, I've started to think that in fact we may be able to clean
things up. One proposal for this is below [0]. I know this is
pr= etty late in the process, but if we do want this change it's
= better to do it now.

I'm sure we'll need t= o discuss this in Berlin, but in the meantime,
fire away.


The basic idea here is to factor out the T= LS 1.3 negotiation into three
mostly orthogonal axes.=C2=A0
=

- Symmetric cipher/PRF =C2=A0-- indicated by the cipher= suite list as in TLS 1.2
- Key exchange -- indicated by the key_= shares and pre_shared_key extensions
- Authentication -- indicate= d the signature_algorithms and pre_shared_key
=C2=A0 extensions

A proposal for how to do this is below. See the end= for other options,
caveats, etc.


If we take PSK out of the picture, this gives us a very simple str= ucture:

- The client offers a set of key_shares an= d the server picks one that it
=C2=A0 likes [1].
- The = client offers a list of signature_algorithms and the server picks
=C2=A0 a certificate/key that matches that list and signs with it.

In other words, we just eliminate the redundancy with the= cipher suite
indications. This leaves is with the question of ho= w to handle the
existing TLS 1.2 cipher suites. We can either ass= ign new cipher suites
or say that any cipher suite with *_aead_al= g_hash means that we
support aead_alg_hash. Matter of taste.


PSK is handled by extending the concept= of PSK flags that we already
have in NewSessionTicket to also in= clude uses of PSKs where you
indicate the way in which you are us= ing the PSK (or want it to be
used). There a bunch of ways to enc= ode this. I'll give you the one I
mostly prefer below and the= n a one that's a smaller change but I think
a little less ele= gant at the end [note #4].

First, we replace the f= lags word of the different KE modes for the
ticket with lists of = code points, as below:

=C2=A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0psk_ke(0), =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// PSK = key exchange
=C2=A0 =C2=A0 =C2=A0psk_dhe_ke(1), =C2=A0 =C2=A0 =C2= =A0// PSK + DHE key exchange
=C2=A0 =C2=A0 =C2=A0(255)
= =C2=A0 =C2=A0} PskKeModes;

And then add new code p= oints for being able to use the PSK with and
without signatures (= from the server). We had pretty rough consensus in
B-A that we ne= eded this mode and [draft-thomson-tls-0rtt-and-certs-01]
is part = of the motivation for this idea.

=C2=A0 =C2=A0enum= {
=C2=A0 =C2=A0 =C2=A0psk_auth(0), =C2=A0 =C2=A0 =C2=A0 =C2=A0//= PSK only
=C2=A0 =C2=A0 =C2=A0psk_sign_auth(1), =C2=A0 // PSK + a= signature (as in draft-thomson) [5]
=C2=A0 =C2=A0 =C2=A0(255)
=C2=A0 =C2=A0} PskAuthModes;

This gives us= the following NewSessionTicket message where we have
replaced th= e flags word with two (potentially ordered) lists:

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_l= ifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0PskAuthModes auth_modes<1.= .255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0PskKeModes ke_modes<1..25= 5>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0TicketExtension extensions<2= ..2^16-2>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket<0..2^16= -1>;
=C2=A0 =C2=A0} NewSessionTicket;

We now need a way to indicate that the server will do 0-RTT (previously
in the flags word) so we add a new 0-RTT extension:

<= /div>
=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32= ticket_age_add;
=C2=A0 =C2=A0} TicketEarlyDataInfo;
= =C2=A0 =C2=A0
This has two nice properties:

<= div>- You don't need to provide ticket_age_add when you don't do 0-= RTT
=C2=A0 (and it is silly if you don't).
- It exe= rcises this extension mechanism, which is good for future-proofing.


PreSharedKeyExtension becomes:
<= br>
=C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0P= skAuthMode auth_modes<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0P= skKeModee ke_modes<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaq= ue identity<0..2^16-1>;=C2=A0
=C2=A0 =C2=A0 } PskIdentity;<= /div>

=C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0select (Role) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0case client:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0PskIdentity identities<2..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PskAuthMode a= uth_mode;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0PskKeMode ke_mode;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0uint16 selected_identity;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0} PreSharedKeyExtension= ;

The way to interpret these is as follows:
<= div>
- With each identity, the client indicates to the server= which modes
=C2=A0 it can be used with.
- When the ser= ver responds with an identity, it tells you how it
=C2=A0 used it= .

You might ask why you need the server to indicat= e what it did.=C2=A0 The
reason is that we would like the client = to know in advance (at the
time of the ServerHello) whether the s= erver has sent
Certificate/CertificateVerify rather than having t= o figure it out from
what messages the server sends. The ke_mode = field is redundant
(because you also infer it from the server key= _shares) but I added it
for parity.

I ha= ven't implemented this yet (am going to try to take a crack at that
before Berlin) but I believe based on experience with the NSS
<= div>negotiation that it will be simpler. I know it removes a bunch of odd
edge cases which have accumulated over the years, but maybe it add= s
others.

-Ekr

=
BONUS MATERIAL
0. I've discussed this with and= /or borrowed ideas from Richard Barnes,
David Benjamin, Karthik B= hargavan, Dave Garrett, Nick Sullivan, Martin
Thomson, and others= . Thanks to those guys, but blame me if you think
this is bad.

1. The other major encoding option here is to have d= ummy
group/signature_algorithm indicators that tell you whether y= ou can use
a pure PSK. When I and others discussed this, the cons= ensus was that
that was less clean.

2. O= ne question that comes up at the same time is whether we should
a= llow multiple key shares to be used, which is a structure that this
makes pretty easy. Basically, the server would just supply as many
=
counter-shares as it wanted and then we'd need a defined order for= how
they were inserted into the key schedule. This feature would= be nice
for enabling post-quantum, but probably better to just d= efine
<PQ-Algorithm + Curve> code points.

3. Note that because of this PSK-PRF interaction, PSK isn't tot= ally
orthogonal with AEAD/PRF. I.e., you cannot use the same PSK = with
HKDF-SHA256 and HKDF-SHA384 if you want to be on the cryptog= raphic
fairway, but I think it should be easy enough to filter ou= t the cipher
suites to make that work.

4= . The other major alternative is just to use the flags bits. So we
would extend and generalize the flags as shown below.

=C2=A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0early_data(1),
=C2=A0 =C2=A0 =C2=A0dhe_psk_ke(2),
=C2=A0 =C2=A0 =C2=A0psk_= ke(4),
=C2=A0 =C2=A0 =C2=A0psk_auth(8), =C2=A0 =C2=A0 =C2=A0 =C2= =A0 // New (no server cert)
=C2=A0 =C2=A0 =C2=A0sig_psk_auth(16) = =C2=A0 =C2=A0 // New (sign with server cert)
=C2=A0 =C2=A0} PskUs= ageFlags;

These new flags have the expected meanin= g, namely:

psk_auth =C2=A0 =C2=A0 =C2=A0 =C2=A0 Th= e server will do connections with just
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PSK authentication (equivalent to PSK= now)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
sig_psk_auth =C2=A0 =C2=A0 The server will do connections wit= h PSK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0plus signature (not currently specified).


<= /div>
Then we update the PreSharedKeyExtension as follows:
=C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 uint32 usage_flags;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opa= que identity<0..2^16-1>;=C2=A0
=C2=A0 =C2=A0 } PskIdentity;=
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 struct {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PskIdentity identities<2..2= ^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case = server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0uint32 usage_flags; =C2=A0// New (one from each category)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 select= ed_identity;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0= =C2=A0 =C2=A0} PreSharedKeyExtension;

The idea he= re is:

- The client indicates how each PSK can be = used (by flags, which
=C2=A0 need to be a subset of the ticket fl= ags).
- The server can pick a PSK and indicate how it was actuall= y
=C2=A0 used.

For instance, if the clie= nt wants to do PSK w/ ECDHE it would indicate
dhe_psk_ke. If it o= nly wants PSK it would indicate psk_ke. If it was
willing to do b= oth, it would indicate the bitwise OR.

Similarly, = if the client wants PSK for auth, it would indicate
psk_auth. If = it wants the server to sign, it indicates sig_psk_auth,
and so on= (indicating neither is silly because it makes the key
unusable).=

By contrast, the server just sets the bits that i= t actually used.
I.e., if it sets psk_auth, that means it won'= ;t be signing and
there is no Certificate/CertificateVerify. OTOH= if it sets
sign_psk_auth, that means it will be signing and ther= e will
be a Certificate/CertificateVerify.

This leaves early data. As above, the client uses the early_data
bit to indicate that the PSK was used to encrypt early data
(o= bviously, this can just be one key) and the server uses it to
ind= icate that it accepted early data. ticket_age needs to go in
its = own extension, but that's easy enough.


5. Note: this would allow for modes where the server signs over a P= SK
handshake with no DHE at all. The resumption_ctx mechanism is = intended
to ensure that that is OK, but we'd need to confirm = with analysis.


--001a1141826a97c8fc053787a0d9-- From nobody Wed Jul 13 10:28:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7111612B03C for ; Wed, 13 Jul 2016 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m7lzdHqfipb for ; Wed, 13 Jul 2016 10:28:22 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 DAAD512B02C for ; Wed, 13 Jul 2016 10:28:21 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j17so50295331ywg.0 for ; Wed, 13 Jul 2016 10:28:21 -0700 (PDT) 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-transfer-encoding:message-id; bh=oNjCAB6bmyzRz9m/qbGQCGza3BddMoNhy/C3rSfNQFk=; b=WWUS8y+eZzfAUCj7oD9XtSkEjaKJQ5g3lNfW0nkjAK3+b7ad5EO1HWhNla7ipT3J3j 9xoiy2nNKTu+QBaEr6lcjqEjyJjoA/z+Krdb0i3rWauQ/JxmDU2EjB0sRVREysIu+6wX O73A7nVy2pVFmw69Fr0Kc1SwwJp6P7s7zFvc5EHpQWe2sNoqsnG7iySjo5IbCUxU7R1D g8VgZAxZJ2Oz8qfna982RnrvqoPmMNh+SVSpBxYnmuJUP5UgW9AZgjCyCBD6ezqfDjIt ck/VIn3Bvrgpja4bdiNltuK8b8WIp8FNg0CcXZi6sap7wsgzLQIZ0hFDXKLsiEWeGeFY qKkQ== 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-transfer-encoding:message-id; bh=oNjCAB6bmyzRz9m/qbGQCGza3BddMoNhy/C3rSfNQFk=; b=UNbSVZf92srIt1mow34Ot4UeMOZy1PSixEoFDgEG/ubfqkCeJ6qccRFs2ht1jNUoN6 pPTvzXuQQFiTK4gA8Kz1uHxn9lSojqZ3bis+Jc2O6G6bvRKh+jduKiE7qlB8jOGTav1y g066HGD23ZpPyXa4pLtbOnmjOEyPBSRrx604aMQzMJlk4tQtSM3sHa72MuEdBp4BAJ18 Lmf+KWjpcmgbxLf5VRcfhFg5C2pX0CMazqrpvnxefwUYaX8+wfPrWAKQMh/D7+yAB5CZ oYXgWOoyCT/ujiOV2GYM4/YdxNEpPQE2tFCZjYVr9OWn9/g9VC2G15laOou/GbYKyGCp eAZg== X-Gm-Message-State: ALyK8tJ9YOQqkfTFwbm2iQ1GMyamJdXnxZtBmynUIlGH03974nk1Nbwdb83Bgqi4kTf5ZQ== X-Received: by 10.37.77.137 with SMTP id a131mr6756466ybb.1.1468430901189; Wed, 13 Jul 2016 10:28:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id u187sm2180347ywu.27.2016.07.13.10.28.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 10:28:20 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 13 Jul 2016 13:28:18 -0400 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: <201607131328.19024.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:28:23 -0000 On Wednesday, July 13, 2016 01:01:13 pm Eric Rescorla wrote: > It's natural to pick the cipher suite first and then look for the key_share > extension, so if, for instance, you pick a PSK-only cipher suite, then you > wouldn't look for the key_share. Agreed. That's why I'm ok with the current "no alternative cipher suite is available" qualification. If the extension never comes up, then not giving a specific error for it is allowed. On Wednesday, July 13, 2016 10:43:58 am David Benjamin wrote: > To be clear, I am not at all opposed to useful errors or strict policing of > what the peer sends. [...] > Complexity is the currency we pay for adding things. I very much agree. Our debate hinges on risk assessment, which gets admittedly hard when talking about unknown future implementations. ;) Essentially, the design philosophy I and Hubert are advocating involves mandatory validation of inputs by all implementations such that we focus on avoiding divergence from what we all agree to in the spec, rather than always try and use our imagination to enumerate each individual screw up that could be made. Dave From nobody Wed Jul 13 11:01:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84F112D0C1 for ; Wed, 13 Jul 2016 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkYcu4zBGKnk for ; Wed, 13 Jul 2016 11:01:16 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B163D12D193 for ; Wed, 13 Jul 2016 11:01:15 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j17so51161088ywg.0 for ; Wed, 13 Jul 2016 11:01:15 -0700 (PDT) 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-transfer-encoding:message-id; bh=tF0Ta5b14/SZH/qFd3XFMkFPST3suXXPhy+WhdUOAXM=; b=rTOk7kQ7bZu8BdqnX/LIbBegsElKpncJx3VehaTHAoFViNR+3+YnepGvDBcmwhZ/4c ZUOMcynOCN1bn+8MPiKBP7Y5oFI8BEWv0YtcwH6LvzSvwbeHgXnH1HaNgGkBVEbe5WGp 851/vdyke8285fjIwvCMk/oo1IDGqDvNfGiYVFz09i8/8T0jTM00TQUWt03F3fcfe/Js jgwCiU+imNhZv6cZljjZ8fl/ZhqfxLkLU3DqnLO+DH+4TeXaB3i2E73/pkVqioYxZr7a IVy3zAU0HfsZpSwq5lKCpjybHHV3kW6uutfQTDAYp8rBSPuakGn4IsinKBBz4PCaGDhj 5d3A== 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:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=tF0Ta5b14/SZH/qFd3XFMkFPST3suXXPhy+WhdUOAXM=; b=Ecya5VJvTQS+TSynahklXppUcSsq/UsP72Vgz+IBUNrV+jUcoMxEdUAGI83XgugO3b owCFqoTqdzEWoyY+He0tr7QCcPuZLjjBIk5LXaGsKI31c3+ci6sD7vsxDwxqqOLpYETB k29SpuJWpus/PA1k/oC84k4lZZDJh9B24htq4JMWVS/ECVrihxmZ2R/QieqL7TD5PW9p gcfxbjZnKNkmx0CZMbTVeyoOdUFzISkPb/f6sRjpj8OxvxqCrwKDOJ3dH8h3lYBUzGyC EhtH9yXi6xpl1YCH4301f67caMR8Flxhwk9qERT/tk4AeG9QmL6siwqC62J08fXUq/Or tIMQ== X-Gm-Message-State: ALyK8tKL9i2Uz8Fk9XwQ/aRqHUINc6WRZZywBwaLJQR4BgpVJs54tKRR74rhuwSgoeCLAQ== X-Received: by 10.13.251.4 with SMTP id l4mr6903733ywf.132.1468432874696; Wed, 13 Jul 2016 11:01:14 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id a22sm6294ywh.42.2016.07.13.11.01.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 11:01:14 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Wed, 13 Jul 2016 14:01:12 -0400 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: <201607131401.12856.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:01:18 -0000 On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote: > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > > A proposal for how to do this is below. See the end for other options, > caveats, etc. > > > If we take PSK out of the picture, this gives us a very simple structure: > > - The client offers a set of key_shares and the server picks one that it > likes [1]. > - The client offers a list of signature_algorithms and the server picks > a certificate/key that matches that list and signs with it. Your proposal ignores the supported_groups extension. The requirement of this is one of the wrenches that causes the complexity of this whole system to increase. HelloRetryRequest is the other wrench here. We very much could do everything supported_groups does in key_share; just stick unsent supported groups in the share with null keys. The desire to maintain backwards compatibility with a different mechanism using the old version of supported_groups is what makes this a problem. (back compat is not free) As to the PSK side of things, one idea which I brought up at some point is to merge the PSK extension into the key share extension to create one unified key exchange extension. We just assign some group ID to PSK, then the identity is just its equivalent of a key to be in the bag of keys. One less new extension to worry about, and instead one new extension that is 100% required for all TLS 1.3 requests, without exceptions that might need to be handled. (blending into the other current list thread, here) The special handling of PSK is another one of these metaphorical wrenches that increases the design complexity in various places. As to the actual core proposal, it could work. I too am not ideally in favor of redoing everything at this late stage, but I'm not against reconsidering it, if we can all actually agree on an alternative. Dave From nobody Wed Jul 13 11:04:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1E412D103 for ; Wed, 13 Jul 2016 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPmPdP6NJRsF for ; Wed, 13 Jul 2016 11:04:44 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0062.outbound.protection.outlook.com [104.47.2.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E736712B03C for ; Wed, 13 Jul 2016 10:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3z1AwFp4qTie23FK0TJ3SILK64l56/PIH1YInIr+RZo=; b=zWSoMK0Tppv/amKhqHUsKB3lXhGKpkR8SAagCbL+5OJX531HX1zDJ7beWblYK1N4UWgXxJ7JEHAmPja8/6D0ZvSsJHALnvhVkD0MjhO5qG5ypi2rOwM/IxzJkPGlZMq8BiAup1vO892D0mAhAxQo9z8+31bAWRNLhEeZcbQS8V0= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1823.eurprd03.prod.outlook.com (10.166.42.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 17:57:10 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 17:57:09 +0000 From: "Paterson, Kenny" To: "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA///wrQCAABjmgP//81OAgAASrf6AAQoQAIAAh0QA Date: Wed, 13 Jul 2016 17:57:09 +0000 Message-ID: References: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.148.47] x-ms-office365-filtering-correlation-id: 5aca3701-607c-449d-ce3d-08d3ab471c68 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1823; 6:b3Tu4rE1wdqB7AB4Kujq1uFfDz5JIDwOmNs8T47O5DmvjbzTHIiu3ZlkY/Bk+SJP9EntvGz3Fjtowy+ZsN8M+UZY6jDoJEkE5ln2Aw2YRLYA4cTSsITxfbcxoljUqaLJXad1FcPCV1/mL4K2gSpr0oDYPcWbgbBY1iU2s0Y95V3SwVeoYsQsJzZfCKlkRaPjGVxQdejwp1+6BC3gREiOhK2oDvbOKhLShB2JNBic5kO1MSyKu+85F0jrxFm1JvPd1PeWkTfNKrtCN6VMnUtzEpNVe/zHbrL3XhT8a80zIsg=; 5:OYmpZ0pJyLl37etmNLS3jlreOrGrlApqMt8/yzXKgyskHRstdMN/evG/yrw4VAhay8r3ydPd+lYh9Mz16iMqe67RxprYC2T04gtnYXmcnyP1YPbZAHkCcq93LjJJmEX+wk0HbYG4g5C95lC+FGGYqQ==; 24:M5blgaiNGL7VfkHGsCl/Hu8QJXpJ1WYzaDnEE+cNWIM5Yxt7q0Hbre6olGFVz85tSquOuVzdcNUmJQj13lb5pCrNJfWCxsFWMUFHKO8WdlI=; 7:6DMdzjgS1f3rmzE3cSY+uqv0u4cXmBFv/sE1EO/Do+NeY4zwBr+52dgA6HrfBssYBVJ6uV1KtvbhMP2OWjpep/Nn+5WA/eiYDICB0g7eZod1mz9FSRs14bK962F+I8GH0wbUOyD0LTv2Rl0piBkpl2ndOU0dbgQbS3xAcGH7jGJNcgMEyzpZMcsb+WKLk1KMbY2mCDFz5e1TJu0QlrivD7bOY+1Nh47WsvwEp9ermGmPgTAjv1aNMlbwazaS27sb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1823; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1823; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1823; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(24454002)(199003)(189002)(81166006)(74482002)(77096005)(230783001)(36756003)(19580395003)(19580405001)(110136002)(87936001)(2900100001)(97736004)(2950100001)(3280700002)(3660700001)(5002640100001)(4001350100001)(83506001)(122556002)(92566002)(86362001)(81156014)(6116002)(3846002)(586003)(106356001)(106116001)(102836003)(8666005)(7736002)(68736007)(54356999)(76176999)(50986999)(101416001)(8936002)(66066001)(105586002)(4326007)(2906002)(10400500002)(305945005)(189998001)(7846002)(8676002)(93886004)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1823; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5728ACE9F965B04CBD323330FE9D7065@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 17:57:09.6049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1823 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:04:45 -0000 SGkNCg0KT24gMTMvMDcvMjAxNiAxMTo1NSwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFu Z0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5Hb29kIG1vcm5pbmcgS2VubnksDQo+DQo+T24gNy8xMi8x NiwgMzowMyBQTSwgIlBhdGVyc29uLCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+ IHdyb3RlOg0KPg0KPj5IaSwNCg0KPHNuaXA+DQoNCj4+Q291bGQgeW91IGRlZmluZSAic2FmZSIs IHBsZWFzZT8gU2FmZSBmb3Igd2hhdD8gRm9yIHdob20/DQo+Pg0KPj5BZ2Fpbiwgd2h5IGFyZSB5 b3UgY2hvb3NpbmcgMl4tMzIgZm9yIHlvdXIgc2VjdXJpdHkgYm91bmQ/IFdoeSBub3QgMl4tNDAN Cj4+b3IgZXZlbiAyXi0yND8gV2hhdCdzIHlvdXIgcmF0aW9uYWxlPyBJcyBpdCBqdXN0IGZpbmdl ciBpbiB0aGUgYWlyLCBvciBkbw0KPj55b3UgaGF2ZSBhIHRocmVhdCBhbmFseXNpcywgb3IgLi4u Pw0KPg0KPkkgc2FpZCBpdCBpcyBzYWZlIGJlY2F1c2UgdGhlIGNoYW5jZSBvZiAxIGluIDQsMjk0 LDk2NywyOTYgcHJhY3RpY2FsbHkNCj5kb2VzIG5vdCBoYXBwZW4uIEkgYW0gbm90IGludGVyZXN0 ZWQgaW4gdGFsa2luZyBhYm91dCBvdGhlciBudW1iZXJzIGFuZA0KPm90aGVyIHF1ZXN0aW9ucy4N Cg0KT0ssIHRoZW4gSSB0aGluayB3ZSdyZSBkb25lIGhlcmUuDQoNCj4+PiBJIGRvbsK5dA0KPj4+ IHJlY29tbWVuZCB0byBydW4gYW5vdGhlciBmdW5jdGlvbi9wcm90b2NvbCB3aGVuIHRoZXJlIGFy ZSBubyBuZWVkcyBmb3INCj4+Pml0Lg0KPj4+IEkgZG9uwrl0IHNlZSBhbnkgcGFydGljdWxhciBy ZWFzb25zIGZvciBtZW50aW9uaW5nIHNpbmdsZSBrZXkgaW4gdGhlDQo+Pj4gaW5kaXN0aW5ndWlz aGFiaWxpdHkgYXR0YWNrIGhlcmUuDQo+Pj4gDQo+Pg0KPj5UaGVuIHBsZWFzZSByZWFkIGEgbGl0 dGxlIGZ1cnRoZXIgaW50byB0aGUgbm90ZSB0aGF0IHByZXNlbnRzIHRoZQ0KPj5hbmFseXNpczog YSBjb25zZXJ2YXRpdmUgYnV0IGdlbmVyaWMgYXBwcm9hY2ggZGljdGF0ZXMgdGhhdCwgd2hlbiB0 aGUNCj4+YXR0YWNrZXIgaGFzIG11bHRpcGxlIGtleXMgdG8gYXR0YWNrLCB3ZSBzaG91bGQgbXVs dGlwbHkgdGhlIHNlY3VyaXR5DQo+PmJvdW5kcyBieSB0aGUgbnVtYmVyIG9mIHRhcmdldCBrZXlz Lg0KPj4NCj4+QSBiZXR0ZXIgYW5hbHlzaXMgZm9yIEFFUy1HQ00gbWF5IGV2ZW50dWFsbHkgYmUg Zm9ydGhjb21pbmcgYnV0IHdlIGRvbid0DQo+PmhhdmUgaXQgeWV0LiANCj4+DQo+Pj4+IFRoZW4g ZG8geW91IGhhdmUgYQ0KPj4+PiBzcGVjaWZpYyBjb25jZXJuIGFib3V0IHRoZSBzZWN1cml0eSBv ZiByZWtleWluZz8gSSBjb3VsZCBzZWUgdmFyaW91cw0KPj4+PndheXMNCj4+Pj4gaW4gd2hpY2gg aXQgbWlnaHQgZ28gd3JvbmcgaWYgbm90IGRlc2lnbmVkIGNhcmVmdWxseS4NCj4+Pj4gDQo+Pj4+ IE9yIGFyZSB5b3UgZGlyZWN0bHkgbGlua2luZyBhIGZ1bmRhbWVudGFsIHNlY3VyaXR5IHF1ZXN0 aW9uIHRvIGFuDQo+Pj4+IG9wZXJhdGlvbmFsIG9uZSwgYnkgd2hpY2ggSSBtZWFuOiBhcmUgeW91 IHNheWluZyB3ZSBzaG91bGQgdHJhZGUNCj4+Pj5zZWN1cml0eQ0KPj4+PiBmb3IgYXZvaWRpbmcg dGhlICJjb3N0IiBvZiByZWtleWluZyBmb3Igc29tZSBub3Rpb24gb2YgImNvc3QiPyBJZiBzbywN Cj4+Pj5jYW4NCj4+Pj4geW91IHF1YW50aWZ5IHRoZSBjb3N0IGZvciB0aGUgdXNlIGNhc2VzIHRo YXQgbWF0dGVyIHRvIHlvdT8NCj4+DQo+PkknZCBsb3ZlIHRvIGhhdmUgeW91ciBhbnN3ZXIgdG8g dGhlc2UgcXVlc3Rpb25zLiBJIGRpZG4ndCBzZWUgb25lIHlldC4NCj4+V2hhdCBpcyB0aGUgY29z dCBtZXRyaWMgeW91J3JlIHVzaW5nIGFuZCBob3cgZG9lcyBpdCBxdWFudGl0eSBmb3IgeW91cg0K Pj51c2UgY2FzZXM/DQo+DQo+QWdhaW4sIEkgYW0gbm90IGludGVyZXN0ZWQgaW4gb3RoZXIgcXVl c3Rpb25zLiBJIHN1Z2dlc3RlZCB0aGUgbnVtYmVyDQo+YWJvdXQgMl4zOCByZWNvcmRzIGJlY2F1 c2UgaXQgaXMgYSBzYWZlIGRhdGEgYm91bmQgYmVjYXVzZSBFcmljIHB1dCBpbiBoaXMNCj50bHMg MS4zIGRyYWZ0IHRoZSBudW1iZXIgMl4yNC41IHdoaWNoIGlzIHVubmVjZXNzYXJpbHkgc21hbGwu DQoNCkFnYWluLCBsb29rIGxpa2Ugd2UncmUgZG9uZSBoZXJlLg0KDQoNCj5Zb3VyIHBhcGVyIGlz IGEgbmljZSBvbmUgd2hpY2ggZ2l2ZXMgdXNlcnMgZ29vZCBpbmZvcm1hdGlvbiBhYm91dCBjaG9p Y2VzLg0KDQpUaGFua3MsIEknbSBnbGFkIHlvdSBmb3VuZCBpdCB1c2VmdWwuDQoNCkNoZWVycw0K DQpLZW5ueSANCg0KPg0KPj4NCj4+Q2hlZXJzLA0KPj4NCj4+S2VubnkNCj4+DQo+Pj4+IA0KPj4+ PiBDaGVlcnMsDQo+Pj4+IA0KPj4+PiBLZW5ueQ0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gUXV5 bmguDQo+DQo+UmVnYXJkcywNCj5RdXluaC4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+DQoN Cg== From nobody Wed Jul 13 13:23:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA612B037 for ; Wed, 13 Jul 2016 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_iu5d1kDvDY for ; Wed, 13 Jul 2016 13:23:41 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 51AE912D7B9 for ; Wed, 13 Jul 2016 13:23:41 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id i12so53708053ywa.1 for ; Wed, 13 Jul 2016 13:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uOsZCB2TLoT9yYKu1d664ZITDTglQ1xhXKRyIeXeeog=; b=Eu9eweVrgarUYuHPjYCJ+KuQ9DmXJGvF4Vn2nCscmMwM0CLUcbn9sFJt6vMatjibhP FFEVij9GNUk9caUN45MGdoYCpDzNywd7hJ4DddetPQ962LAKvi5+zmKHrghTA+8Egsdo 6EneyDTlnjKc1zXK9f8K/rMP4JBxO1lLnBU5OjPMI0e867ABtPEh8spZn2AGi7mumH8v N5flo003ifoVc5L3/4K4m/O1/4ytZP3RRO6Sdke2sEBrzg5kXFv8EVa3Z+EOPy83PTu2 EcpzsqRNQc5kebpKEUieF8GWuGmrHS1qDTWZ4EDx2+j7bxqtJ2cADgceD3osFtvJx2Eq z02g== 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; bh=uOsZCB2TLoT9yYKu1d664ZITDTglQ1xhXKRyIeXeeog=; b=ME80c8RI2Bhmz/EV6vWLSivu5atu6gduywFEG+blgmdHQk0Rrx+JMGvkEsYV+2gPIt WjX9Mr+7Ol64UMDA1VQUc415PT9njtmqFwSA+JN4eGHaM1j82Tt2b0GR5A8+uT7zkvHH 3qZNhDEyxurVUBQaPF4jywrTC5U/CaRbnCVwc/lnbJZvGZ1avlqjCg8gHTHB5HIQ4kVG mnFaSQ63cEepPxZwNfRViLWANscCumAoTIXVEzjOV60165S2MfdsqGnoSoz85MLwWaIN y2a3Ts6FDR/bhDf4uws/XNhl5awMHw7VSpBechQgbeiVv18rOQ9K4wxLlBrudYYKidRJ S1tw== X-Gm-Message-State: ALyK8tJ7JxuzitNFpuiQVrgmk+jrauN1X5FUFdggbRegCBR8UI6hHEjMA7YsumdH+vSOtyBjYC0svtJCd5+W9A== X-Received: by 10.13.201.134 with SMTP id l128mr7688650ywd.93.1468441420567; Wed, 13 Jul 2016 13:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 13:23:01 -0700 (PDT) In-Reply-To: <201607131401.12856.davemgarrett@gmail.com> References: <201607131401.12856.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 13 Jul 2016 13:23:01 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114e630e3f4a0e05378a294a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:23:42 -0000 --001a114e630e3f4a0e05378a294a Content-Type: text/plain; charset=UTF-8 On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett wrote: > On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote: > > The basic idea here is to factor out the TLS 1.3 negotiation into three > > mostly orthogonal axes. > > > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS > 1.2 > > - Key exchange -- indicated by the key_shares and pre_shared_key > extensions > > - Authentication -- indicated the signature_algorithms and pre_shared_key > > extensions > > > > A proposal for how to do this is below. See the end for other options, > > caveats, etc. > > > > > > If we take PSK out of the picture, this gives us a very simple structure: > > > > - The client offers a set of key_shares and the server picks one that it > > likes [1]. > > - The client offers a list of signature_algorithms and the server picks > > a certificate/key that matches that list and signs with it. > > Your proposal ignores the supported_groups extension. I don't think it affects it either way. The requirement of this is one of the wrenches that causes the complexity > of this whole system to increase. HelloRetryRequest is the other wrench > here. We very much could do everything supported_groups does in key_share; > just stick unsent supported groups in the share with null keys. David suggested this offline, but I don't think this makes things significantly simpler, because now. As to the PSK side of things, one idea which I brought up at some point is > to merge the PSK extension into the key share extension to create one > unified key exchange extension. We just assign some group ID to PSK, then > the identity is just its equivalent of a key to be in the bag of keys. One > less new extension to worry about, and instead one new extension that is > 100% required for all TLS 1.3 requests, without exceptions that might need > to be handled. (blending into the other current list thread, here) The > special handling of PSK is another one of these metaphorical wrenches that > increases the design complexity in various places. > I think this actually makes matters *worse* because then you have one situation where (ECDHE) where the server sends one key share and one (ECDHE-PSK) where the server has to send/acknowledge two -Ekr As to the actual core proposal, it could work. I too am not ideally in > favor of redoing everything at this late stage, but I'm not against > reconsidering it, if we can all actually agree on an alternative. > > > Dave > --001a114e630e3f4a0e05378a294a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote:
> The basic idea here is to factor out the TLS 1.3 negotiation into thre= e
> mostly orthogonal axes.
>
> - Symmetric cipher/PRF=C2=A0 -- indicated by the cipher suite list as = in TLS 1.2
> - Key exchange -- indicated by the key_shares and pre_shared_key exten= sions
> - Authentication -- indicated the signature_algorithms and pre_shared_= key
>=C2=A0 =C2=A0extensions
>
> A proposal for how to do this is below. See the end for other options,=
> caveats, etc.
>
>
> If we take PSK out of the picture, this gives us a very simple structu= re:
>
> - The client offers a set of key_shares and the server picks one that = it
>=C2=A0 =C2=A0likes [1].
> - The client offers a list of signature_algorithms and the server pick= s
>=C2=A0 =C2=A0a certificate/key that matches that list and signs with it= .

Your proposal ignores the supported_groups extension.
<= div>
I don't think it affects it either way.

The requirement of th= is is one of the wrenches that causes the complexity of this whole system t= o increase. HelloRetryRequest is the other wrench here. We very much could = do everything supported_groups does in key_share; just stick unsent support= ed groups in the share with null keys.

Davi= d suggested this offline, but I don't think this makes things significa= ntly simpler, because now.


As to the PSK side of things, one idea which I brought up at some point is = to merge the PSK extension into the key share extension to create one unifi= ed key exchange extension. We just assign some group ID to PSK, then the id= entity is just its equivalent of a key to be in the bag of keys. One less n= ew extension to worry about, and instead one new extension that is 100% req= uired for all TLS 1.3 requests, without exceptions that might need to be ha= ndled. (blending into the other current list thread, here) The special hand= ling of PSK is another one of these metaphorical wrenches that increases th= e design complexity in various places.

= I think this actually makes matters *worse* because then you have one situa= tion where (ECDHE) where the server sends one key share and one (ECDHE-PSK)= where the server has to send/acknowledge two

-Ekr=


As to the actual core proposal, it could work. I too am not ideally in favo= r of redoing everything at this late stage, but I'm not against reconsi= dering it, if we can all actually agree on an alternative.


Dave

--001a114e630e3f4a0e05378a294a-- From nobody Wed Jul 13 13:36:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF10112D848 for ; Wed, 13 Jul 2016 13:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUwDpvM_GLT1 for ; Wed, 13 Jul 2016 13:36:20 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id EA57612D534 for ; Wed, 13 Jul 2016 13:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 69F2680E6; Wed, 13 Jul 2016 23:36:18 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id qYQWy2ToDS_Y; Wed, 13 Jul 2016 23:36:17 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DE231285; Wed, 13 Jul 2016 23:36:17 +0300 (EEST) Date: Wed, 13 Jul 2016 23:36:14 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160713203614.GA4757@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:36:24 -0000 On Wed, Jul 13, 2016 at 10:12:54AM -0700, Eric Rescorla wrote: > Hi folks, > > There have been a lot of discussions about whether we should try to > refactor cipher-suite negotiation to be less monolithic in the cipher > suite. I've generally been on the "no" side of that on cost/benefit > grounds as well as not quite seeing how it would fit into the rest > of the infrastructure. However, now that we're starting to get full > implementations, and it's becoming clearer how the new elements > (principally PSK-resumption and key_shares) interact with cipher > suites, I've started to think that in fact we may be able to clean > things up. One proposal for this is below [0]. I know this is > pretty late in the process, but if we do want this change it's > better to do it now. > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > fire away. > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > > A proposal for how to do this is below. See the end for other options, > caveats, etc. Those axes aren't properly orthogonal. IMO, the most orthogonal axes are: - Key exchange main type: PSK vs. GDHE-PSK vs. GDHE-CERT. - Key exchange function (for GDHE-*) - Signature algorithm (for GDHE-CERT) - Record protection - PRF-hash. And the most logical way to choose from above list is to first choose the major type, and then mostly independently (might want to tweak protection/PRF priorities based on key exchange function strength) the rest (also, might want to check ther is OK choice for kex function before chosing main type). Now, the issue is that orthogonality is completely broken in TLS 1.2. The factors that most break it are group types and legacy signature types and how those can interact with record protection or PRF. Send a ClientHello that does not have cartesian product of group types, legacy signature types and protections/prfs and you can get some very surprising results (or at worst, bugs where server selects ciphersuite that isn't on your list!). OTOH, the problem with changing it is that TLS 1.2 and 1.3-14 parameter negotiation works mostly the same way (other than lack of the broken RSA key exchange and the DHE downnegotiation issue, which is mostly client problem rather than server problem) So any dual 1.2/1.3 server would have to implement both mechanisms if those are changed. So only 1.3-only servers would benefit. > If we take PSK out of the picture, this gives us a very simple structure: > > - The client offers a set of key_shares and the server picks one that it > likes [1]. > - The client offers a list of signature_algorithms and the server picks > a certificate/key that matches that list and signs with it. > > In other words, we just eliminate the redundancy with the cipher suite > indications. This leaves is with the question of how to handle the > existing TLS 1.2 cipher suites. We can either assign new cipher suites > or say that any cipher suite with *_aead_alg_hash means that we > support aead_alg_hash. Matter of taste. Yes, that's the key exchange function and signature algorithm parts from the above. > PSK is handled by extending the concept of PSK flags that we already > have in NewSessionTicket to also include uses of PSKs where you > indicate the way in which you are using the PSK (or want it to be > used). There a bunch of ways to encode this. I'll give you the one I > mostly prefer below and then a one that's a smaller change but I think > a little less elegant at the end [note #4]. > > First, we replace the flags word of the different KE modes for the > ticket with lists of code points, as below: > > enum { > psk_ke(0), // PSK key exchange > psk_dhe_ke(1), // PSK + DHE key exchange > (255) > } PskKeModes; In the orthogonalization above, the second entry would be PSK+GDHE (any supported key exchange function), but that's probably what you meant already. > And then add new code points for being able to use the PSK with and > without signatures (from the server). We had pretty rough consensus in > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01] > is part of the motivation for this idea. > > enum { > psk_auth(0), // PSK only > psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5] > (255) > } PskAuthModes; I think that PSK+signature modes are so different that those warrant promotion to a new major key exchange type. Depending on the actual implementation, those might have some new message sequence (e.g. omitting Certificate if the key can't change). > This gives us the following NewSessionTicket message where we have > replaced the flags word with two (potentially ordered) lists: > > struct { > uint32 ticket_lifetime; > PskAuthModes auth_modes<1..255>; > PskKeModes ke_modes<1..255>; > TicketExtension extensions<2..2^16-2>; > opaque ticket<0..2^16-1>; > } NewSessionTicket; > > PreSharedKeyExtension becomes: > > struct { > PskAuthMode auth_modes<1..255>; > PskKeModee ke_modes<1..255>; > opaque identity<0..2^16-1>; > } PskIdentity; > > struct { > select (Role) { > case client: > PskIdentity identities<2..2^16-1>; > case server: > PskAuthMode auth_mode; > PskKeMode ke_mode; > uint16 selected_identity; > } > } PreSharedKeyExtension; This seems somehow bit questionable to me (taking this as clean- slate design), but I can't quite put my finger on it... OTOH, if one wants to combine PSK and auth, one probably want's to keep it separate like it is done above... > You might ask why you need the server to indicate what it did. The > reason is that we would like the client to know in advance (at the > time of the ServerHello) whether the server has sent > Certificate/CertificateVerify rather than having to figure it out from > what messages the server sends. The ke_mode field is redundant > (because you also infer it from the server key_shares) but I added it > for parity. Well, figuring out from ServerHello (and even EncryptedExtensions) would not be so bad if the rules were clear. > I haven't implemented this yet (am going to try to take a crack at that > before Berlin) but I believe based on experience with the NSS > negotiation that it will be simpler. I know it removes a bunch of odd > edge cases which have accumulated over the years, but maybe it adds > others. Maybe I could take a crack too (maybe)... > > BONUS MATERIAL > > 2. One question that comes up at the same time is whether we should > allow multiple key shares to be used, which is a structure that this > makes pretty easy. Basically, the server would just supply as many > counter-shares as it wanted and then we'd need a defined order for how > they were inserted into the key schedule. This feature would be nice > for enabling post-quantum, but probably better to just define > code points. In order of group number? Or in order of server reply? (Both orders would be well-defined). Would also avoid the bit of special case of zero key in pure-PSK mode... > 3. Note that because of this PSK-PRF interaction, PSK isn't totally > orthogonal with AEAD/PRF. I.e., you cannot use the same PSK with > HKDF-SHA256 and HKDF-SHA384 if you want to be on the cryptographic > fairway, but I think it should be easy enough to filter out the cipher > suites to make that work. The 0-RTT locking the protection/prf is surprisingly easy (other than the checks if such locking can give anything sane due to couplings in ciphersuites). > 4. The other major alternative is just to use the flags bits. So we > would extend and generalize the flags as shown below. > > enum { > early_data(1), > dhe_psk_ke(2), > psk_ke(4), > psk_auth(8), // New (no server cert) > sig_psk_auth(16) // New (sign with server cert) > } PskUsageFlags; > > These new flags have the expected meaning, namely: > > psk_auth The server will do connections with just > PSK authentication (equivalent to PSK now) > > sig_psk_auth The server will do connections with PSK > plus signature (not currently specified). > > > Then we update the PreSharedKeyExtension as follows: > > struct { > uint32 usage_flags; > opaque identity<0..2^16-1>; > } PskIdentity; > > struct { > select (Role) { > case client: > PskIdentity identities<2..2^16-1>; > case server: > uint32 usage_flags; // New (one from each category) > uint16 selected_identity; > } > } PreSharedKeyExtension; > > The idea here is: > > - The client indicates how each PSK can be used (by flags, which > need to be a subset of the ticket flags). > - The server can pick a PSK and indicate how it was actually > used. Based on quick look, I like this less than the decoupled version... > 5. Note: this would allow for modes where the server signs over a PSK > handshake with no DHE at all. The resumption_ctx mechanism is intended > to ensure that that is OK, but we'd need to confirm with analysis. I should also figure out all the attacks I figured out against server auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported any such modes). Yeah, if resumption_ctx stuff is actually used, it should do the trick, as it binds the PSK key used (and the normal handshake hash binds the negotiation). The resumption_ctx would also bind the key if one kept it as constant and omitted Certificate message. -Ilari From nobody Wed Jul 13 15:08:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E412D8EA for ; Wed, 13 Jul 2016 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17FiagagVHSw for ; Wed, 13 Jul 2016 15:08:26 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE58012D901 for ; Wed, 13 Jul 2016 15:08:26 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i12so56065797ywa.1 for ; Wed, 13 Jul 2016 15:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jG0indO/E2PTOJD8RFCJQLjm4wUpzAgXZgR1pf6P1DI=; b=SlhUAIyu4+ypZ5pWbJ0DDhcYVJNX2drREXgCp6PYct9GrCx6swCvccnvf1zQxRM+FL eAT5pSUO1YlDhKBtKJfOugTcpHm0+yOxWQO+z9pBHv0S8jdH/3DsUZSDpteide5KSz3K +yXXX8rRa3x09kvp/95vqzRJXOhDCv+UxL2GjrTalSSNvuhKW0wyu0vtbX3xWB96SAd1 s4smJGCwsdIgbDQVJ8PGpWSvT61WmXIv12bbi0Z4SJSb2b/2LnbniGRvpbZ/gT6ZkYrn TsXWuDVhVrsxE35fGhV67CgtyM4wYNmjCXMh7oOLUECg7OWT54h99Usf95Rd3SvlyYXm yhUw== 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; bh=jG0indO/E2PTOJD8RFCJQLjm4wUpzAgXZgR1pf6P1DI=; b=ZCzmD4eKjE7OCy/a9tEs7QhMJsmI8N4cG+fn0cypDC3dnnNOfxvraD6OH0Ey9s/tEl mVSzHLD4JeiEBZX/wOVeICGMm8rns5vqsdUTZHaBPyDkSYf+JfC392JQX63qBgAKH7wx xDHFxHMR8ZDcfiSH3wG/rEH6EvrqLKnWppf6BxXv5kDSaKZdjfsqBIMrqoSpFpNb6Vil SWO/cLV8mJkHTxRe8RS1B1S0rlknR5vYNGqCBvtVYZiZ1tkHIo6AXknjk9TWSVpt8AeX HRKpnqsC9+x+0SgQd6qRiE28RwLMt+BC8b+KtnAhc0q2mmZMtAY6EJATnpDe2cVflY2m tFfw== X-Gm-Message-State: ALyK8tKftIA2wKWHxUt9rh4sh0XZ36a3rd0C3GyI9r8NMERo1mrWOMsDw7XRK3jmCe2B7hiPXA1wKzTCYQW2BA== X-Received: by 10.129.161.129 with SMTP id y123mr8543307ywg.214.1468447706006; Wed, 13 Jul 2016 15:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 15:07:46 -0700 (PDT) In-Reply-To: <20160713203614.GA4757@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160713203614.GA4757@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Wed, 13 Jul 2016 15:07:46 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114f8db2e3836d05378b9ff5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:08:28 -0000 --001a114f8db2e3836d05378b9ff5 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara wrote: > > > > PSK is handled by extending the concept of PSK flags that we already > > have in NewSessionTicket to also include uses of PSKs where you > > indicate the way in which you are using the PSK (or want it to be > > used). There a bunch of ways to encode this. I'll give you the one I > > mostly prefer below and then a one that's a smaller change but I think > > a little less elegant at the end [note #4]. > > > > First, we replace the flags word of the different KE modes for the > > ticket with lists of code points, as below: > > > > enum { > > psk_ke(0), // PSK key exchange > > psk_dhe_ke(1), // PSK + DHE key exchange > > (255) > > } PskKeModes; > > In the orthogonalization above, the second entry would be PSK+GDHE > (any supported key exchange function), but that's probably what you > meant already. > Yes, we're using "dhe == GDHE" > > > And then add new code points for being able to use the PSK with and > > without signatures (from the server). We had pretty rough consensus in > > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01] > > is part of the motivation for this idea. > > > > enum { > > psk_auth(0), // PSK only > > psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5] > > (255) > > } PskAuthModes; > > I think that PSK+signature modes are so different that those warrant > promotion to a new major key exchange type. > Hmm... Why? > > You might ask why you need the server to indicate what it did. The > > reason is that we would like the client to know in advance (at the > > time of the ServerHello) whether the server has sent > > Certificate/CertificateVerify rather than having to figure it out from > > what messages the server sends. The ke_mode field is redundant > > (because you also infer it from the server key_shares) but I added it > > for parity. > > Well, figuring out from ServerHello (and even EncryptedExtensions) > would not be so bad if the rules were clear. Yes, that's what I'm hoping for. > > > > > 2. One question that comes up at the same time is whether we should > > allow multiple key shares to be used, which is a structure that this > > makes pretty easy. Basically, the server would just supply as many > > counter-shares as it wanted and then we'd need a defined order for how > > they were inserted into the key schedule. This feature would be nice > > for enabling post-quantum, but probably better to just define > > code points. > > In order of group number? Or in order of server reply? > > (Both orders would be well-defined). Would also avoid the bit of > special case of zero key in pure-PSK mode... > I was thinking in order of group number, but if you do combined code points you don't need to do this. > 5. Note: this would allow for modes where the server signs over a PSK > > handshake with no DHE at all. The resumption_ctx mechanism is intended > > to ensure that that is OK, but we'd need to confirm with analysis. > > I should also figure out all the attacks I figured out against server > auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported > any such modes). > > Yeah, if resumption_ctx stuff is actually used, it should do the trick, > as it binds the PSK key used (and the normal handshake hash binds the > negotiation). > > The resumption_ctx would also bind the key if one kept it as constant > and omitted Certificate message. > Definitely like to hear about this. -Ekr > > > -Ilari > --001a114f8db2e3836d05378b9ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:


> PSK is handled by extending the concept of PSK flags that we already > have in NewSessionTicket to also include uses of PSKs where you
> indicate the way in which you are using the PSK (or want it to be
> used). There a bunch of ways to encode this. I'll give you the one= I
> mostly prefer below and then a one that's a smaller change but I t= hink
> a little less elegant at the end [note #4].
>
> First, we replace the flags word of the different KE modes for the
> ticket with lists of code points, as below:
>
>=C2=A0 =C2=A0 enum {
>=C2=A0 =C2=A0 =C2=A0 psk_ke(0),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // PS= K key exchange
>=C2=A0 =C2=A0 =C2=A0 psk_dhe_ke(1),=C2=A0 =C2=A0 =C2=A0 // PSK + DHE ke= y exchange
>=C2=A0 =C2=A0 =C2=A0 (255)
>=C2=A0 =C2=A0 } PskKeModes;

In the orthogonalization above, the second entry would be PSK+GDHE (any supported key exchange function), but that's probably what you
meant already.

Yes, we're using &qu= ot;dhe =3D=3D GDHE"

=C2=A0

> And then add new code points for being able to use the PSK with and > without signatures (from the server). We had pretty rough consensus in=
> B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01]=
> is part of the motivation for this idea.
>
>=C2=A0 =C2=A0 enum {
>=C2=A0 =C2=A0 =C2=A0 psk_auth(0),=C2=A0 =C2=A0 =C2=A0 =C2=A0 // PSK onl= y
>=C2=A0 =C2=A0 =C2=A0 psk_sign_auth(1),=C2=A0 =C2=A0// PSK + a signature= (as in draft-thomson) [5]
>=C2=A0 =C2=A0 =C2=A0 (255)
>=C2=A0 =C2=A0 } PskAuthModes;

I think that PSK+signature modes are so different that those warrant=
promotion to a new major key exchange type.

=
Hmm...=C2=A0 Why?



> You might ask why you need the server to indicate what it did.=C2=A0 T= he
> reason is that we would like the client to know in advance (at the
> time of the ServerHello) whether the server has sent
> Certificate/CertificateVerify rather than having to figure it out from=
> what messages the server sends. The ke_mode field is redundant
> (because you also infer it from the server key_shares) but I added it<= br> > for parity.

Well, figuring out from ServerHello (and even EncryptedExtensions) would not be so bad if the rules were clear.

Yes, that's what I'm hoping for.
=C2=A0

>=C2=A0
> 2. One question that comes up at the same time is whether we should > allow multiple key shares to be used, which is a structure that this > makes pretty easy. Basically, the server would just supply as many
> counter-shares as it wanted and then we'd need a defined order for= how
> they were inserted into the key schedule. This feature would be nice > for enabling post-quantum, but probably better to just define
> <PQ-Algorithm + Curve> code points.

In order of group number? Or in order of server reply?

(Both orders would be well-defined). Would also avoid the bit of
special case of zero key in pure-PSK mode...

I was thinking in order of group number, but if you do combined code = points you don't
need to do this.

> 5. Note: this would allow for modes where the server signs over a PSK<= br> > handshake with no DHE at all. The resumption_ctx mechanism is intended=
> to ensure that that is OK, but we'd need to confirm with analysis.=

I should also figure out all the attacks I figured out against serve= r
auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported=
any such modes).

Yeah, if resumption_ctx stuff is actually used, it should do the trick,
as it binds the PSK key used (and the normal handshake hash binds the
negotiation).

The resumption_ctx would also bind the key if one kept it as constant
and omitted Certificate message.

Defini= tely like to hear about this.

-Ekr
=C2= =A0


-Ilari

--001a114f8db2e3836d05378b9ff5-- From nobody Wed Jul 13 16:17:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F5812D0C7 for ; Wed, 13 Jul 2016 16:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSMcCSuJ_TNX for ; Wed, 13 Jul 2016 16:17:08 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F348812D86E for ; Wed, 13 Jul 2016 16:17:07 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 52so34394053qtq.3 for ; Wed, 13 Jul 2016 16:17:07 -0700 (PDT) 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; bh=mRDOGFJyE+Sa0H0pJbcnO4nP4lpALcWWQXl4dUIqCnM=; b=t8m4Tg9+kiPvH+AZREyrKuMxyYOWNIR3i8NL4cYtoYYbhJS61B+obhBxN7Zok930i7 xFjR9U7SIJdxDHc5bYngOG4wNUmJFf7BWKd5D8Ka3SFuG7isiCEqFeFM/NOIMWhYPHfK lW5Zr5oG7bsz5/YUSJZkN1rKXa5A6ANaAigwqMOIVc4rX/WmBGdUrvMcMBoEglbLTzGO FgU8VCsVQQtP8V9Hc1GWSw6XvKONG3keDUo5SidV/5KjDonOCy+oM2KFuYf4h1sz9tkl SUVibg0Kd6xslNsqEoAPCmOdLznIdI00NqNbgGQfDZmI5ECF8312osAtwJBLfPPR172J 6MXw== 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; bh=mRDOGFJyE+Sa0H0pJbcnO4nP4lpALcWWQXl4dUIqCnM=; b=ShePxgM8Cc/umGghPd54Zj3oSNdHXB0zMBNE/0536q0LIMo0dCPi/tLMPj/9wR/YdI CQQ0AC4V3S1qF1VyPsgoXJaJtIHL1nFtySb3O9vrVJSq/1djz7qiCw3WhuBHZdIvcEzu Abnbs7Id8nQ2UPD4/SnG/IWMNBvzRCQrxflPMgs7YiAIDIk5jQmAAbqzkqhj9yzmeWE1 M/qhU7MvCQ+AxNgy81w7gT7zX219u3hyVTYxCmJXKWI6CZLBC2+kzKnjGq+9KVY/Ol7I QNVjYDA8D8jJD9CYGwbgB86maHdG9y45ZRVTpts1zpY/sXhsiBBtjmoPLH7WbYjPpO5u dqMg== X-Gm-Message-State: ALyK8tLabmhe54pBjXRtPq+Oawdr62yB7zk8X6OXOVT3mEtKvoUrO1ZF0/Bqw7XYn+qkQwfCASuVTQg1oSFzmA== X-Received: by 10.200.44.136 with SMTP id 8mr16453555qtw.18.1468451827092; Wed, 13 Jul 2016 16:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Wed, 13 Jul 2016 16:17:06 -0700 (PDT) In-Reply-To: References: <3111426.zLZNlvgK9Q@pintsize.usersys.redhat.com> From: Martin Thomson Date: Thu, 14 Jul 2016 09:17:06 +1000 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 23:17:09 -0000 On 14 July 2016 at 03:01, Eric Rescorla wrote: > > Obviously, you could add a check that said that if an EC cipher suite was > advertised, then you had to look for key shares even if you picked one, but > it's not a check you otherwise need. Though you would miss an EC cipher suite that you didn't know about. And as far as the client is concerned, any cipher suite that the server didn't pick is potentially one that it didn't know about. From nobody Thu Jul 14 01:32:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829312D0B1 for ; Thu, 14 Jul 2016 01:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6cmpyr010bG for ; Thu, 14 Jul 2016 01:32:07 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E751012D9AC for ; Thu, 14 Jul 2016 01:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A98E27F49; Thu, 14 Jul 2016 11:32:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id nHkMhEu68JPC; Thu, 14 Jul 2016 11:32:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 496D4285; Thu, 14 Jul 2016 11:32:04 +0300 (EEST) Date: Thu, 14 Jul 2016 11:32:00 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160714083200.GA4895@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160713203614.GA4757@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 08:32:09 -0000 On Wed, Jul 13, 2016 at 03:07:46PM -0700, Eric Rescorla wrote: > On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara > wrote: > > > > > > > > And then add new code points for being able to use the PSK with and > > > without signatures (from the server). We had pretty rough consensus in > > > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01] > > > is part of the motivation for this idea. > > > > > > enum { > > > psk_auth(0), // PSK only > > > psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5] > > > (255) > > > } PskAuthModes; > > > > I think that PSK+signature modes are so different that those warrant > > promotion to a new major key exchange type. > > > > Hmm... Why? Or might be better to have those as add-ons like in your proposal. The above look to be independent. If you think chinese menus are problematic, coupled choices are way more so... > > > 2. One question that comes up at the same time is whether we should > > > allow multiple key shares to be used, which is a structure that this > > > makes pretty easy. Basically, the server would just supply as many > > > counter-shares as it wanted and then we'd need a defined order for how > > > they were inserted into the key schedule. This feature would be nice > > > for enabling post-quantum, but probably better to just define > > > code points. > > > > In order of group number? Or in order of server reply? > > > > (Both orders would be well-defined). Would also avoid the bit of > > special case of zero key in pure-PSK mode... > > > > I was thinking in order of group number, but if you do combined code points > you don't > need to do this. I was thinking of just scanning the server key_share in order the groups appear... With no mixing if no key_share is absent. This would unify DHE-PSK and PSK for purposes of later handshake. Would need a way to ensure that some mixing happened tho! > > > 5. Note: this would allow for modes where the server signs over a PSK > > > handshake with no DHE at all. The resumption_ctx mechanism is intended > > > to ensure that that is OK, but we'd need to confirm with analysis. > > > > I should also figure out all the attacks I figured out against server > > auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported > > any such modes). > > > > Yeah, if resumption_ctx stuff is actually used, it should do the trick, > > as it binds the PSK key used (and the normal handshake hash binds the > > negotiation). > > > > The resumption_ctx would also bind the key if one kept it as constant > > and omitted Certificate message. > > Definitely like to hear about this. One thing that comes to mind is (this is not mode that is presently supported or discussed to be added): Say you had a mode where server could send a public key in NewSessionTicket and then have client do key transport with that key to agree "SS key" for 0-RTT and as second key (useful for PQC purposes, since this lets you use PQEncryption instead of PQKeyAgreement, and the first seems to be in better shape than the latter). Now you are in cryptographic weeds and resumption_ctx won't help. Also, need to check the extension rules in case of PSKwCERT. More annoyingly, those depend on the exact semantics of the certificate authentication in that case. Certificate is constant (in addition to base ALPN and SNI): - If status_request was originally present, now status_request or status_request_v2 has to be present. Contents can be different. - server_authz must not be present - cert_type/server_certificate_type negotiation has to have the same result (including the implicit "X509" case).. - signature_algorithms from client has to contain the signature algorithm used on parent connection. - If status_request_v2 was originally present, it has also be present now. Contents can be different. Key is constant (in addition to ALPN and SNI): - signature_algorithms from client has to contain the signature algorithm used on parent connection. - If using implcit-key: trusted_ca_keys, status_request,server_authz, cert_type,status_request_v2,signed_certificate_timestamp and server_certificate_type must not be negotiated. No constraints (in addition to ALPN and SNI): - (No additional constraints on extensions) Each mode from above has its strengths and weaknesses: Certificate is constant: - Limits 0-RTT to lifetime of parent certificate (or less!) + Revocation works as well as usual (which isn't very!) - Problems with farms +- Implicit-key would save chunk of bandwidth, but need to check if it is safe (should be, since resumption_ctx covers it).. Key is constant: + 0-RTT lifetime can extend beyond certificate lifetime. - No workable key revocation. - Problems with farms +- Implicit-key would save chunk of bandwidth, but need to check if it is safe (should be, since resumption_ctx covers it).. No constraints: - Weakest assurances. - No implicit-key bandwidth savings. -Ilari From nobody Thu Jul 14 04:37:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB74A12D753 for ; Thu, 14 Jul 2016 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu6J2ALaFBZu for ; Thu, 14 Jul 2016 04:37:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADDF12D549 for ; Thu, 14 Jul 2016 04:37:11 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DB83F4883F; Thu, 14 Jul 2016 11:37:10 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6EBb9GL027849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2016 07:37:10 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 14 Jul 2016 13:37:08 +0200 Message-ID: <4869007.FHLngpRvOx@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.6.3-300.fc24.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6578271.a0n0SpiqmN"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 14 Jul 2016 11:37:10 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server-side missing_extension MUSTs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:37:13 -0000 --nextPart6578271.a0n0SpiqmN Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 14 July 2016 09:17:06 Martin Thomson wrote: > On 14 July 2016 at 03:01, Eric Rescorla wrote: > > > > Obviously, you could add a check that said that if an EC cipher sui= te was > > advertised, then you had to look for key shares even if you picked = one, but > > it's not a check you otherwise need. >=20 > Though you would miss an EC cipher suite that you didn't know about. > And as far as the client is concerned, any cipher suite that the > server didn't pick is potentially one that it didn't know about. yes, but it's also a ciphersuite no other client will negotiate with th= at server and that's why we don't say that server should complain that an extensi= on it does know about was sent despite there are no EC ciphers from its po= int of view you, as server, act on what you know and understand, and you check it fastidiously, everything else you MUST completely ignore ie. if you know about supported_groups extension you MUST check that th= e length of extension matches exactly the length of array (minus the 2 bytes for= length), and that length is an even number but you MUST ignore any identifiers y= ou don't know about if they appear in the array so server should check if, and only if, there are EC ciphers it knows a= bout* in the client hello, then it should check for the presence of the extensio= n and abort if it is missing * either ones it can negotiate now, or in general, but that's unimport= ant (I'd say the latter solution would be "cleaner") =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 --nextPart6578271.a0n0SpiqmN 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 iQIcBAABCgAGBQJXh3lkAAoJEJKo0bgB0vX12+QP/1ComtzNfxfgG8nZ2Av8R60t c9u/+YMooFI+tuDKb+et3rygfAPkF/GxST/XYEsAKjW9+EDFJmk+WKKZyG9jEpd3 Z1Ls2vXDbSeY0E1wLBn49mE+nbo5oyYwJ4QRv/yNTbfwQ92ciODAfFoR1KxxP0+g MlHpshg3SXdR+WzOxkDr7GClLzqOR0JU6ewPjQSrPlO2KIjJqDf4AuK+4o3GNeFG 2WSUPhvZIWlOZgwklllhO+vK9jm7rXwrCtyEXVjn8FW/Nzk87GHBWQ3qkq12G7vn pH1+5ZEWcpIXLuoN2qPt9ytXztYieArl86bAOdL7fALbFrhM68JkQLpW0HRaAPOZ 3c8Fi+fPTKWOd+DDBE6kIznthvUa2RCOdlIQ9eEWKnPFgxANaHwmT6EAyV9y0vzm 9sRksAAiDmsFeQkCMmYN7+NZZ5PdOpMkvsvh5krJ7TiU6HAN+wV0zxBJ8j1A07Ui sUhk/8ksyBynMvuQAHcZ5/A3t1AWaDT6XCcylymw2fjtowJwLKGbqGjaVISuUj6J fQQcxH6lcf5uVm57LQQ6IAdNYqlgtk6yM3RanhpA2UKm2JUNayJQVY1YLFbIqT0M TYNJbxUCrniI7qiTT65Q8A8ETlJKpda/0WgbrrIjylSPPYV9QA9jy7TleLtUJt7i ZTbjqhwDg/RtaGmszcDT =ze1r -----END PGP SIGNATURE----- --nextPart6578271.a0n0SpiqmN-- From nobody Thu Jul 14 04:44:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3461512D0E3 for ; Thu, 14 Jul 2016 04:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgzt3tIk1j6j for ; Thu, 14 Jul 2016 04:44:49 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 48FEC12B03A for ; Thu, 14 Jul 2016 04:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 165C84792; Thu, 14 Jul 2016 14:44:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 8b5gStat6F2R; Thu, 14 Jul 2016 14:44:47 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id BC8DA283; Thu, 14 Jul 2016 14:44:47 +0300 (EEST) Date: Thu, 14 Jul 2016 14:44:43 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160714114443.GA5328@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160713203614.GA4757@LK-Perkele-V2.elisa-laajakaista.fi> <20160714083200.GA4895@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160714083200.GA4895@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:44:51 -0000 On Thu, Jul 14, 2016 at 11:32:00AM +0300, Ilari Liusvaara wrote: > > I was thinking of just scanning the server key_share in order the groups > appear... With no mixing if no key_share is absent. > > This would unify DHE-PSK and PSK for purposes of later handshake. > > Would need a way to ensure that some mixing happened tho! Thinking some more about this: - The initial value for the chain secret should be empty string, not L zeroes. If hash function is well-behaved (and most are), then empty and L zeroes are the same if passed as salt to HKDF-Extract, but empty string would cause an internal fault in derive_secret. - One should ensure that the default type is "certificate authentication" and that this can't be changed without mixing in a secret. - One needs to require that at least one secret mixing occurs in processing of CH/SH. -Ilari From nobody Thu Jul 14 10:58:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC412D13D for ; Thu, 14 Jul 2016 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kGaDP9dApX3 for ; Thu, 14 Jul 2016 10:58:13 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB90412D08D for ; Thu, 14 Jul 2016 10:58:12 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id w38so46696466qtb.0 for ; Thu, 14 Jul 2016 10:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=O2MPg7f0Pg/Y9kCdMP2AyLCE4tmzN5ilHjiQ6f/oXPk=; b=bk4GgglsTIF8LTm+JVGNT3ZbzcYZam319twM3U4FJzvurng9ojTVfQAvhSsd8u0HLI XRZI+s3HdRK5jZeyEeRVf/AWRF7sQ0HEIBipOivhCVyBpmmKLWfl8pSiOjWLhJ5ToW3F xYisat05KlbyVzVeWiWIfUAwvfGQGC6Bn/mt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=O2MPg7f0Pg/Y9kCdMP2AyLCE4tmzN5ilHjiQ6f/oXPk=; b=R9A1KuSXt0W/jIY5b8ayVGvFszqS+A3hp5JJn0NlfzRU84MH/8NDSrWm5tmxZrQS5t Z25yOlw+nnRZKCpHQTdcD5YW9WVEMoMGviAhOcWmmYvfhAEnp0wntaBcCHWjdsRINCWR lBNs2tkeP0wR9FtDwsrFcn2WqAUX8F40Iux0gNBFgTFqCqgoZazl0J9Z4ODH+I7fGxRc WohKh+qkTO0y6l8qYjO/xyY5UU8vp9k/4Up9k5/fG9urNu0lS03cILbkwL3pePVGxDsQ hbxOuUOyXQpqJrqMIT32aCezVmYJNMfWJRkgDnmqRVzDDqz7EEGOu8FEqPfjEcSKUxHP UDqg== X-Gm-Message-State: ALyK8tJW/7MYQJVYmM3gfYgY6KlzTVRxxj3WZyBV0KIf6GkkUV9LF0Qts7ZXxIT2SdOeTA== X-Received: by 10.200.52.182 with SMTP id w51mr13024895qtb.90.1468519092010; Thu, 14 Jul 2016 10:58:12 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id 128sm1539150qke.10.2016.07.14.10.58.11 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 10:58:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <7E71298A-1B25-452A-BDC0-DCC5616CDF98@sn3rd.com> Date: Thu, 14 Jul 2016 13:58:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E71298A-1B25-452A-BDC0-DCC5616CDF98@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] confirming AUTH48 changes to draft-ietf-tls-cached-info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:58:14 -0000 The consensus of the WG is to not make the changes to the referred to by = this msg. Hannes, Please respond to the RFC Editor to complete AUTH48 processing of this = draft. J&S > On Jul 06, 2016, at 13:45, Sean Turner wrote: >=20 > Anirudh noted [0] that existing implementation practices in TLS stacks = may lead to additional complexity when implementing TLS cached info on = the server side. The main issue is that the server needs to prepare the = ServerHello (and list the CachedInfo extension) saying which payloads = will subsequently modify. However, most implementations create each = message somewhat independently and so it is not clear whether a = certificate message, for example, will indeed contain the full payload = or the fingerprint at the time of creating the ServerHello. >=20 > We need the WG to verify an AUTH48-proposed change to s4 of = cached-info [1]. Please let us know whether you agree with the = following changes by 14 July. >=20 > The proposed changes can be seen in the diff: > http://www.tschofenig.priv.at/Diff_rfc7924-before_after.pdf >=20 > Cheers, >=20 > J&S >=20 > [0] https://www.ietf.org/mail-archive/web/tls/current/msg19493.html >=20 > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ >=20 From nobody Thu Jul 14 17:28:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F4612D140 for ; Thu, 14 Jul 2016 17:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwh_-h6gws-T for ; Thu, 14 Jul 2016 17:28:20 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0117.outbound.protection.outlook.com [104.47.40.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C6A12D0C5 for ; Thu, 14 Jul 2016 17:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oSIZlPr307vIFatIY/pJ+WS2jdXE86XHy6qUq5u9lrw=; b=b0dji+TmVIOEj4xuP6SYwMQOGbdYHy9RJ/Rc8Oa3U23keZYb7LwcZES0yIufoB1SOhj1wrbS7dkPWpcVd/CZY9MFy+9ZXfkPa4gmKYNluMAnj2NNqt1gHjN70+6s7ZeYOS9cPb02YaF/0UJZRHro0hXOU1aWjmsF4v7CcXXaYLI= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Fri, 15 Jul 2016 00:28:19 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.023; Fri, 15 Jul 2016 00:28:19 +0000 From: Andrei Popov To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] draft-rescorla-tls-subcerts Thread-Index: AQHR2IXi5/u6A9XC6UWhBIud7iIL56AYq7cg Date: Fri, 15 Jul 2016 00:28:18 +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:e::1d2] x-ms-office365-filtering-correlation-id: 81c5b733-fc02-49a6-f025-08d3ac46eb9d x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:KRDBhsMBjBantk6Llx/9QzqCMFVAQ4SRSFiEEipV416rOqqPF9KC9BfgpLYOoT7aBqnqPjCOcqPlszh7XEjimQ059fPw5LT+bwKDtmGMs16wx0a+R+q+fIIlXmFlsyYm9Cn8gwKAAnsUnDSIFqmjip6C6G+CQ+YrGKEyF+KClSb0ySG1Q8nNUYImycieH8T9vMIUD7RdkAw+m66J6y9+bFxjP8Uj3ylf4IiLMjBtc3X69K48RJps0v3Y4iNHMrtrB3PUJRgymPNkv6xHtMR7fD/3Umb00CRjzfZn4vo2XQXl7svQ7r7Jem0d2b/DKLaLgMVfUsjFzAl6i7r4LfuMLQ==; 5:tjpTawuqYgQmiS89sNSlRfYDEAXWSW8R0FtjNAypRBM72cONtjuR379C/y2o2LGAS74Yq3Q8uM54myqgncMLCyZsYGIAThhTPC4yeWj1qbMZLu4/AO2RJMNYh79vMsTLPqm6fwSlGUvpNEUrQRn+Vw==; 24:aPnkYbIfEOFdeaFEZ0TAIfEePSxVpH9bXniKrGwYfikZceWhkJMr3bhW+Fx7FAK1de0/WhLB4mfGrXNBlNtTMx0VIMTFQdkqc+S+8QrfTFU=; 7:QhSys6CJIOX6mve/PrUffsVSHQjs9CBaRYW80R46eOXgQgsFvTmcafckjabu3rDgU//TOFmDjRQfWcsgJyuxbOLqWaX8EY/71nmV+b/TeYkR3BpJQruV8FiczytZFhcpaKFFu+PzxcTeSVejTHhny+BjfbCNVO5eeOT+Uy0xSJEx56FGvSy+8IFDVoAIPLNwtEAABZg9/MQ9u+j8WacPLNYqJun6+MfUi14bHunZqPCJmFREiTfDYlnECaY810If x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(8936002)(7846002)(99286002)(9686002)(3660700001)(19617315012)(74316002)(10290500002)(7696003)(7736002)(5003600100003)(97736004)(68736007)(5002640100001)(189998001)(7906003)(3280700002)(92566002)(11100500001)(8990500004)(107886002)(10090500001)(19580395003)(2501003)(5005710100001)(230783001)(10400500002)(8676002)(19580405001)(106356001)(76576001)(54356999)(106116001)(105586002)(586003)(5001770100001)(2900100001)(2906002)(87936001)(81156014)(77096005)(86362001)(2950100001)(81166006)(50986999)(33656002)(19609705001)(101416001)(15975445007)(19300405004)(86612001)(102836003)(122556002)(790700001)(6116002)(19625215002)(16236675004)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21551F88A99C2CEF07548A2D8C330CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2016 00:28:18.8475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 00:28:23 -0000 --_000_CY1PR03MB21551F88A99C2CEF07548A2D8C330CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmHDr3ZlIHF1ZXN0aW9uOiB3aHkgbm90IHNpbXBseSBnZXQgYSBjb25zdHJhaW5lZCBDQSBjZXJ0 aWZpY2F0ZSBhbmQgaXNzdWUgc2hvcnQtdmFsaWRpdHkgZW5kIGVudGl0eSBjZXJ0cz8gVW5sZXNz IEnigJltIG1pc3Npbmcgc29tZXRoaW5nLCB0aGlzIHdvdWxkIHdvcmsgd2l0aCBleGlzdGluZyBU TFMgaW1wbGVtZW50YXRpb25zLCBubyBleHRlbnNpb25zIHJlcXVpcmVkLg0KDQpTaG9ydC1saXZl ZCBjcmVkZW50aWFsIGFwcHJvYWNoIHNlZW1zIG1vcmUgdmlhYmxlIHRoYW4gZHJhZnQtbWdsdC1s dXJrLXRscy1yZXF1aXJlbWVudHMtMDAgKHdoaWNoIHJlcXVpcmVzIGFuIGFkZGl0aW9uYWwgcm91 bmQtdHJpcCBiZXR3ZWVuIHRoZSBFZGdlIFNlcnZlciBhbmQgQ29udGVudCBQcm92aWRlcikuDQoN CkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVGh1cnNkYXksIEp1bHkgNywg MjAxNiAxMjoyOSBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gZHJhZnQtcmVz Y29ybGEtdGxzLXN1YmNlcnRzDQoNCldlJ3ZlIHRhbGtlZCBzZXZlcmFsIHRpbWVzIGFib3V0IGRl c2lnbmluZyBzb21lIHNvcnQgb2YgVExTIGRlbGVnYXRpb24NCm1lY2hhbmlzbS4gQSBmZXcgb2Yg dXMgZ290IHRvZ2V0aGVyIGFuZCBwdXQgdG9nZXRoZXIgc29tZSBpbml0aWFsIHRob3VnaHRzDQph Ym91dCB0aGUgb3B0aW9ucyBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXJlc2Nv cmxhLXRscy1zdWJjZXJ0cy0wMC50eHQNCg0KVGhlIGdlbmVyYWwgaWRlYSBoZXJlIGlzIHRvIGhh dmUgc29tZSBtZWNoYW5pc20gZm9yIGFsbG93aW5nIHdoYXQNCmFyZSBlZmZlY3RpdmVseSBlbmQt ZW50aXRpZXMgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgY3JlZGVudGlhbHMgdGhhdCBhbGxvdyBvdGhl cg0KZW50aXRpZXMgdG8gYWN0IG9uIHRoZWlyIGJlaGFsZiAoZS5nLiwgZm9yIENETiB1c2UgY2Fz ZXMpLg0KQ29tbWVudHMgd2VsY29tZS4NCg0KSW4gdGVybXMgb2YgdGhlIHNlY3VyaXR5IGFuYWx5 c2lzLCBpdCdzIG9idmlvdXNseSB2ZXJ5IGltcG9ydGFudCB0aGF0IHRoaXMgbWVjaGFuaXNtDQpu b3QgcHJlc2VudCBhIHJpc2sgdG8gZXhpc3RpbmcgVExTIHNlcnZlcnMuIFRoZSBtZWNoYW5pc20g ZGVzaWduZWQgaGVyZSBpcw0KaW50ZW5kZWQgdG8gYmUgZnV0dXJlIHNhZmUgaW4gdGhhdCBzZW5z ZSwgdGhvdWdoIHBlcmhhcHMgd2UndmUgbWlzc2VkIHNvbWV0aGluZy4NCg0KSSBhbHNvIHdhbnRl ZCB0byBjbGFyaWZ5IGEgY291cGxlIHBvaW50cyBhYm91dCBhdHRhY2tzIHdoZXJlIHRoZSBjZXJ0 aWZpY2F0ZSB0aGF0IHNpZ25zIHRoZSBkZWxlZ2F0ZWQgY3JlZGVudGlhbCBpcyBhbHNvIHVzZWQg Zm9yIG9yZGluYXJ5IFRMUyBvcGVyYXRpb24gKHdoaWNoIGdlbmVyYWxseSBpcyBhIHByYWN0aWNl IHRoYXQncyBwcmV0dHkgc2NhcnkpLiBBcyBub3RlZCBhYm92ZSBpdCdzIGltcG9ydGFudCB0aGF0 IGV4aXN0aW5nIGNlcnRzIG5vdCBiZSB1c2FibGUgdGhpcyB3YXksIGJ1dCBtYXliZSBmdXR1cmUg Y2VydHMgd291bGQgYmUuDQoNCjEuIEl0J3MgaW1wb3J0YW50IHRvIGNvbnN0cnVjdCB0aGUgZGVs ZWdhdGVkIGNyZWRlbnRpYWwgaW4gc3VjaCBhIHdheSB0aGF0IHlvdSBjYW4ndCB1c2UgYSBUTFMg c2VydmVyIGFzIGEgc2lnbmluZyBvcmFjbGUuIElmIHlvdSBjaG9vc2UgIm9wdGlvbiAyIiB3aGVy ZSB5b3UgZGVmaW5lIGEgbmV3IHN0cnVjdHVyZSwgdGhlbiBpdCdzIHByb2JhYmx5IHN1ZmZpY2ll bnQgdG8gdXNlIHRoZSBUTFMgMS4zICJjb250ZXh0LWluY2x1ZGluZyIgZGlnaXRhbGx5LXNpZ25l ZCBwcm9kdWN0aW9uIHByb3Bvc2VkIGJ5IEFHTC4gSWYgeW91IHlvdSBjaG9vc2UgIm9wdGlvbiAx IiB3aGVyZSB0aGUgZGVsZWdhdGVkIGNyZWRlbnRpYWwgaXMgYW4gWC41MDkgY2VydCwgdGhlbiB5 b3UnZCBuZWVkIHRvIG1ha2Ugc29tZSBydWxlcyBhYm91dCBmaXhpbmcgcG9ydGlvbnMgb2YgdGhl IGNlcnQgdGhhdCB0aGUgVExTIGNsaWVudCBjYW4ndCBjb250cm9sLg0KDQoyLiBJZiB5b3UncmUg Y29uY2VybmVkIGFib3V0IGF0dGFja3MgbGlrZSB0aG9zZSBvZiBKYWdlciBldCBhbC4gd2hpY2gg ZXhwbG9pdCBSU0EgZGVjcnlwdGlvbiwgd2hhdCdzIGltcG9ydGFudCBpcyB0aGF0IHRoZSBhdHRh Y2tlciBub3QgYmUgYWJsZSB0byBnZXQgdGhlIHNlcnZlciB0byBkbyBUTFMgMS4yLXN0eWxlIHN0 YXRpYyBSU0Egd2l0aCB0aGUga2V5LiBQbGF5aW5nIHdpdGggdGhlIHVzYWdlIGJpdHMgZGVmaW5p dGVseSBtYWtlcyBpdCBoYXJkZXIgdG8gY29uZmlndXJlIHRoZSBzZXJ2ZXIgdGhpcyB3YXkgKGJl Y2F1c2UgaXQncyBsaWtlbHkgdG8gY2F1c2UgYnVzdGFnZSkgYnV0IG1heSBub3QgYmUgZW5vdWdo LCBiZWNhdXNlIHN1ZmZpY2llbnRseSBidXN0ZWQgY2xpZW50cyBhbmQgc2VydmVyIG1pZ2h0IGJl IHdpbGxpbmcgdG8gdXNlIHRoZW0gdGhhdCB3YXkgYW55d2F5Lg0KDQpJbiB0aGUgbmV4dCByZXYs IHdlJ2xsIHVwZGF0ZSB0aGUgZHJhZnQgdG8gbWFrZSB0aGVzZSBwb2ludHMgbW9yZSBjbGVhcmx5 Lg0KDQotRWtyDQoNCg0KDQo= --_000_CY1PR03MB21551F88A99C2CEF07548A2D8C330CY1PR03MB2155namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5OYcOvdmUgcXVlc3Rpb246IHdoeSBub3Qgc2ltcGx5IGdldCBhIGNvbnN0 cmFpbmVkIENBIGNlcnRpZmljYXRlIGFuZCBpc3N1ZSBzaG9ydC12YWxpZGl0eSBlbmQgZW50aXR5 IGNlcnRzPyBVbmxlc3MgSeKAmW0gbWlzc2luZyBzb21ldGhpbmcsIHRoaXMgd291bGQgd29yayB3 aXRoIGV4aXN0aW5nIFRMUyBpbXBsZW1lbnRhdGlvbnMsDQogbm8gZXh0ZW5zaW9ucyByZXF1aXJl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+U2hvcnQtbGl2ZWQgY3JlZGVudGlhbCBhcHByb2FjaCBzZWVtcyBt b3JlIHZpYWJsZSB0aGFuIGRyYWZ0LW1nbHQtbHVyay10bHMtcmVxdWlyZW1lbnRzLTAwICh3aGlj aCByZXF1aXJlcyBhbiBhZGRpdGlvbmFsIHJvdW5kLXRyaXAgYmV0d2VlbiB0aGUgRWRnZSBTZXJ2 ZXIgYW5kIENvbnRlbnQgUHJvdmlkZXIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgNywg MjAxNiAxMjoyOSBQTTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFtUTFNdIGRyYWZ0LXJlc2NvcmxhLXRscy1zdWJjZXJ0czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlJ3ZlIHRhbGtlZCBzZXZlcmFsIHRpbWVzIGFib3V0IGRl c2lnbmluZyBzb21lIHNvcnQgb2YgVExTIGRlbGVnYXRpb248bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tZWNoYW5pc20uIEEgZmV3IG9mIHVzIGdvdCB0b2dldGhl ciBhbmQgcHV0IHRvZ2V0aGVyIHNvbWUgaW5pdGlhbCB0aG91Z2h0czxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWJvdXQgdGhlIG9wdGlvbnMgYXQ6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1yZXNjb3JsYS10bHMtc3ViY2VydHMt MDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcmVz Y29ybGEtdGxzLXN1YmNlcnRzLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdlbmVyYWwgaWRlYSBoZXJlIGlzIHRvIGhh dmUgc29tZSBtZWNoYW5pc20gZm9yIGFsbG93aW5nIHdoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZSBlZmZlY3RpdmVseSBlbmQtZW50aXRp ZXMgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgY3JlZGVudGlhbHMgdGhhdCBhbGxvdyBvdGhlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZW50aXRpZXMg dG8gYWN0IG9uIHRoZWlyIGJlaGFsZiAoZS5nLiwgZm9yIENETiB1c2UgY2FzZXMpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHMgd2Vs Y29tZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gdGVybXMgb2YgdGhlIHNlY3VyaXR5IGFuYWx5c2lzLCBpdCdzIG9idmlvdXNseSB2ZXJ5 IGltcG9ydGFudCB0aGF0IHRoaXMgbWVjaGFuaXNtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3QgcHJlc2VudCBhIHJpc2sgdG8gZXhpc3Rpbmcg VExTIHNlcnZlcnMuIFRoZSBtZWNoYW5pc20gZGVzaWduZWQgaGVyZSBpczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50ZW5kZWQgdG8gYmUgZnV0 dXJlIHNhZmUgaW4gdGhhdCBzZW5zZSwgdGhvdWdoIHBlcmhhcHMgd2UndmUgbWlzc2VkIHNvbWV0 aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBhbHNvIHdhbnRlZCB0byBjbGFyaWZ5IGEgY291cGxlIHBvaW50cyBhYm91dCBhdHRhY2tz IHdoZXJlIHRoZSBjZXJ0aWZpY2F0ZSB0aGF0IHNpZ25zIHRoZSBkZWxlZ2F0ZWQgY3JlZGVudGlh bCBpcyBhbHNvIHVzZWQgZm9yIG9yZGluYXJ5IFRMUyBvcGVyYXRpb24gKHdoaWNoIGdlbmVyYWxs eSBpcyBhIHByYWN0aWNlIHRoYXQncyBwcmV0dHkgc2NhcnkpLiBBcyBub3RlZCBhYm92ZSBpdCdz IGltcG9ydGFudA0KIHRoYXQgZXhpc3RpbmcgY2VydHMgbm90IGJlIHVzYWJsZSB0aGlzIHdheSwg YnV0IG1heWJlIGZ1dHVyZSBjZXJ0cyB3b3VsZCBiZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gSXQncyBpbXBvcnRhbnQgdG8gY29uc3Ry dWN0IHRoZSBkZWxlZ2F0ZWQgY3JlZGVudGlhbCBpbiBzdWNoIGEgd2F5IHRoYXQgeW91IGNhbid0 IHVzZSBhIFRMUyBzZXJ2ZXIgYXMgYSBzaWduaW5nIG9yYWNsZS4gSWYgeW91IGNob29zZSAmcXVv dDtvcHRpb24gMiZxdW90OyB3aGVyZSB5b3UgZGVmaW5lIGEgbmV3IHN0cnVjdHVyZSwgdGhlbiBp dCdzIHByb2JhYmx5IHN1ZmZpY2llbnQgdG8gdXNlIHRoZSBUTFMgMS4zICZxdW90O2NvbnRleHQt aW5jbHVkaW5nJnF1b3Q7DQogZGlnaXRhbGx5LXNpZ25lZCBwcm9kdWN0aW9uIHByb3Bvc2VkIGJ5 IEFHTC4gSWYgeW91IHlvdSBjaG9vc2UgJnF1b3Q7b3B0aW9uIDEmcXVvdDsgd2hlcmUgdGhlIGRl bGVnYXRlZCBjcmVkZW50aWFsIGlzIGFuIFguNTA5IGNlcnQsIHRoZW4geW91J2QgbmVlZCB0byBt YWtlIHNvbWUgcnVsZXMgYWJvdXQgZml4aW5nIHBvcnRpb25zIG9mIHRoZSBjZXJ0IHRoYXQgdGhl IFRMUyBjbGllbnQgY2FuJ3QgY29udHJvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gSWYgeW91J3JlIGNvbmNlcm5lZCBhYm91dCBhdHRh Y2tzIGxpa2UgdGhvc2Ugb2YgSmFnZXIgZXQgYWwuIHdoaWNoIGV4cGxvaXQgUlNBIGRlY3J5cHRp b24sIHdoYXQncyBpbXBvcnRhbnQgaXMgdGhhdCB0aGUgYXR0YWNrZXIgbm90IGJlIGFibGUgdG8g Z2V0IHRoZSBzZXJ2ZXIgdG8gZG8gVExTIDEuMi1zdHlsZSBzdGF0aWMgUlNBIHdpdGggdGhlIGtl eS4gUGxheWluZyB3aXRoIHRoZSB1c2FnZSBiaXRzIGRlZmluaXRlbHkNCiBtYWtlcyBpdCBoYXJk ZXIgdG8gY29uZmlndXJlIHRoZSBzZXJ2ZXIgdGhpcyB3YXkgKGJlY2F1c2UgaXQncyBsaWtlbHkg dG8gY2F1c2UgYnVzdGFnZSkgYnV0IG1heSBub3QgYmUgZW5vdWdoLCBiZWNhdXNlIHN1ZmZpY2ll bnRseSBidXN0ZWQgY2xpZW50cyBhbmQgc2VydmVyIG1pZ2h0IGJlIHdpbGxpbmcgdG8gdXNlIHRo ZW0gdGhhdCB3YXkgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgbmV4dCByZXYsIHdlJ2xsIHVwZGF0ZSB0aGUgZHJhZnQg dG8gbWFrZSB0aGVzZSBwb2ludHMgbW9yZSBjbGVhcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB21551F88A99C2CEF07548A2D8C330CY1PR03MB2155namp_-- From nobody Thu Jul 14 19:53:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD11512B02A for ; Thu, 14 Jul 2016 19:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCQupKzop-7o for ; Thu, 14 Jul 2016 19:53:07 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E352512B011 for ; Thu, 14 Jul 2016 19:53:06 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ECB4242374D; Fri, 15 Jul 2016 02:53:05 +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 B25E942372F; Fri, 15 Jul 2016 02:53:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468551185; bh=KvnhI2WphfG833QIZgr6OZas5+Hbul6qwwd2HUIxZw0=; l=670; h=From:To:Date:References:In-Reply-To:From; b=tFxcLPPWax6w3oSJVJ2y1wdnejTFkt1yLofWsfsOY6KtrGPSOcqXhngZg+S1cP5qv C+lkgr1n+cMKvRURMGsFqDEX6AVh6rISxEGcb07ytogI1ftW5Dgsx8hYtIi0Ye77yD /j6eAkAoJhOViZtRetrXCoOoDBWMvu8WZJ1MlDHc= 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 A9C021FC98; Fri, 15 Jul 2016 02:53:05 +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.1178.4; Thu, 14 Jul 2016 22:53:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 14 Jul 2016 22:53:05 -0400 From: "Salz, Rich" To: Andrei Popov , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] draft-rescorla-tls-subcerts Thread-Index: AQHR2IXcVquhYzeOPUa1QtaSPyWJv6AY8ZMA///k6OA= Date: Fri, 15 Jul 2016 02:53:04 +0000 Message-ID: <77982989336748a5847ef4cb9999cdc8@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.40.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 02:53:09 -0000 PiBOYcOvdmUgcXVlc3Rpb246IHdoeSBub3Qgc2ltcGx5IGdldCBhIGNvbnN0cmFpbmVkIENBIGNl cnRpZmljYXRlIGFuZCBpc3N1ZSBzaG9ydC12YWxpZGl0eSBlbmQgZW50aXR5IGNlcnRzPw0KDQpX b3VsZG4ndCB5b3UgbmVlZCBvbmUgZm9yIGV2ZXJ5IHBvdGVudGlhbCB1c2VyPyBBbmQgdGhlIG5h bWVDb25zdHJhaW50cyB0aGVuIGJlY29tZXMgYSB1bmlvbiBvZiBhbGwgU0FOIGZpZWxkcz8NCg0K PiBTaG9ydC1saXZlZCBjcmVkZW50aWFsIGFwcHJvYWNoIHNlZW1zIG1vcmUgdmlhYmxlIHRoYW4g ZHJhZnQtbWdsdC1sdXJrLXRscy1yZXF1aXJlbWVudHMtMDAgKHdoaWNoIHJlcXVpcmVzIGFuIGFk ZGl0aW9uYWwgcm91bmQtdHJpcCBiZXR3ZWVuIHRoZSBFZGdlIFNlcnZlciBhbmQgQ29udGVudCBQ cm92aWRlcikuDQoNCkV4Y2VwdCB0aGF0IHRoZSBSU0FMRyBhbmQvb3IgImtleWxlc3MgU1NMIiBh cHByb2FjaCBhcmUgYWxyZWFkeSBkZXBsb3llZC4NCg0K From nobody Fri Jul 15 02:16:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF8C12DC52 for ; Fri, 15 Jul 2016 02:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNO_Ulyqq1qq for ; Fri, 15 Jul 2016 02:16:17 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92F12DC54 for ; Fri, 15 Jul 2016 02:14:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4852F8721; Fri, 15 Jul 2016 12:14:28 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id gOAXao5qM3bn; Fri, 15 Jul 2016 12:14:27 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8B5DF287; Fri, 15 Jul 2016 12:14:27 +0300 (EEST) Date: Fri, 15 Jul 2016 12:14:23 +0300 From: Ilari Liusvaara To: Andrei Popov Message-ID: <20160715091423.GA6556@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:16:19 -0000 On Fri, Jul 15, 2016 at 12:28:18AM +0000, Andrei Popov wrote: > Naïve question: why not simply get a constrained CA certificate and > issue short-validity end entity certs? Unless I’m missing something, > this would work with existing TLS implementations, no extensions > required. The I-D actually covers this. Additionally, I think getting NC certificate is quite expensive/difficult. > Short-lived credential approach seems more viable than > draft-mglt-lurk-tls-requirements-00 (which requires an additional > round-trip between the Edge Server and Content Provider). Those two serve different purposes. Sometimes you really need the ES/KS split, sometimes short-lived certs would be more useful. -Ilari From nobody Fri Jul 15 03:39:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1174312B050 for ; Fri, 15 Jul 2016 03:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nwzbSPeNYa4 for ; Fri, 15 Jul 2016 03:39:55 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7D912DA60 for ; Fri, 15 Jul 2016 03:39:54 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id b62so100474236iod.3 for ; Fri, 15 Jul 2016 03:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=6Q2IN0/DeIXssu6RWwsHkqcEFq6m4qWImGreGYANNlk=; b=MiRAZizHTz83R6h7CGBXtYh/DxCcI0jC4nWus4UFVGxo978vqVQQ0CXMm21HtHWkNd rxu9oQfEjCUV0PugHYvXUCAbNDA9Ys0+YI02aif9HARbMzbaZ6pDEtjPsrT/g1T3+a/y eVD1zWFj1rkFlUy1jwKYryWGZbl8Hy7LaeuxY= 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; bh=6Q2IN0/DeIXssu6RWwsHkqcEFq6m4qWImGreGYANNlk=; b=jf+5wR7kKx9CjjY2NY3nOA4Q3siz3uvDJuFVvEk46GvpBCb0UNjJlNneJgDE0Fxm21 B4q8TKQCb0XEiBbU+M6xO0Kwe48fu/iuON1LU7JcGZa/UM2FfJ1mCi4ldipiypp0SXoO SNU5K2qjfcZw/zSdh3APTlI1F8/focFU4VqtPQJzHpC1zfCMsE6a0FKH3zXWIYsbIuUC gWVsULv/36AiNz/qJCnvlovExnNd4ROGf1qQJPbGOqXWqyrBYK5RtCk13KVy6Ydmf8Zy yBBpAS/tSUOlauyxA24L+uyXEB7eF+VK99vwYBTbtqaZu+Hw/qhuzH312b+Dm9noc/bp Yr9g== X-Gm-Message-State: ALyK8tLSWoLOH+b7w4pB5HeIIACU+qgZ50WWN/bHmBAVVhh0BGWKXh02c4C9PMjDcSOr47mYMW0v+XnUSeQ1ukh8 X-Received: by 10.107.52.133 with SMTP id b127mr21177909ioa.6.1468579193876; Fri, 15 Jul 2016 03:39:53 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Fri, 15 Jul 2016 10:39:43 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11440f1c2d55a10537aa3d8d Archived-At: Subject: [TLS] Why is resumption_context hashed? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:39:57 -0000 --001a11440f1c2d55a10537aa3d8d Content-Type: text/plain; charset=UTF-8 Every time resumption_context is used, it's fed into the PRF hash. Handshake Context gets hashed since that actually expands to the full concatenation and we want to be able to maintain a rolling hash. But resumption_context is always a short value and is already the size of the PRF hash. (If not resuming, it is the zero key, which is sized appropriately. If resuming, it is the size of the PRF hash of the original connection. But we require that resumptions use the same PRF, so that too will be the right size.) Was there some other reason we needed to hash it, or is a guarantee of constant size sufficient to use it directly? If it still needs to be hashed, it seems we ought to redefine resumption_context to be Hash(HKDF-Expand-Label(...)) instead, mostly as a hint to implementors that one may as well store the final value in the ticket. David --001a11440f1c2d55a10537aa3d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Every time resumption_context is used, it's fed into t= he PRF hash. Handshake Context gets hashed since that actually expands to t= he full concatenation and we want to be able to maintain a rolling hash. Bu= t=C2=A0resumption_context is always a short value and is already the size o= f the PRF hash. (If not resuming, it is the zero key, which is sized approp= riately. If resuming, it is the size of the PRF hash of the original connec= tion.=C2=A0But we require that resumptions = use the same PRF, so that too will be the right size.)

Was there some other reason we needed to hash it, or is a guarantee o= f constant size sufficient to use it directly? If it still needs to be hash= ed, it seems we ought to redefine resumption_context to be Hash(HKDF-Expand= -Label(...)) instead, mostly as a hint to implementors that one may as well= store the final value in the ticket.

Davi= d
--001a11440f1c2d55a10537aa3d8d-- From nobody Fri Jul 15 04:59:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA012D511 for ; Fri, 15 Jul 2016 04:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m784iqQOk_-v for ; Fri, 15 Jul 2016 04:59:53 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAEC12B058 for ; Fri, 15 Jul 2016 04:59:53 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l125so99430402ywb.2 for ; Fri, 15 Jul 2016 04:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tZ2CMwlNHFKRtHQbnZnvy/aVBSgV5LV29pDNROci26I=; b=YC48GF5F8pESEg2LjGdszve4ma4D6tZ8DjSjdCEnXmdCoDk0dVZjqvdkIGwMzi6evW gKDw2AaAu07mh/oj8wEsTuMS2xXyP7deHWQoVU+xwYHPjJSlQ5+OBQSbu5HGAKMBpaEr +hXsv3ODh5I3ZIazoSSF+n5HCHewcbQX1QwEmoGCPQDc+xyzP5TK19a4HjNnLARXeNyC hVEDJxKnzHUY20HdW9eBMvxTxzs9mkzT4SAgwXkXSIrEdAXuIOwseA83EP2ZciOAYn/i EDbJWKppO2cTE0Y6awh6JUo/KObITHcuMG2BNZd9i6A6Fp/BwSWmDp6TCgMuAowJF7OT H7iw== 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; bh=tZ2CMwlNHFKRtHQbnZnvy/aVBSgV5LV29pDNROci26I=; b=fGMTzWn2qBJlFhDygJUWTj2q9XbvCv8ApJpec2B8KyyLZ/EmZcqAJf36Y5RfZCJKRn vB+Kd3TAdZbnjZfXbItLg5CkijRv6f9lmozdX9jTn/SlhQLdkNAIaAdHjQRbbH8DQNkC 90D2thEh1N81+2KhXJsh9B5ZZxXUIVJagUvVoHMOIYkl1yG5v5Tvj8IQMs0k2HP+Ug8D 2IGtLIqfri6vn2iMlvYaXcOJW1cQbt2bE7fhbD/3Qj4bMTo25C94XLaA5YeNXSwoyXRO jPeMRHRffTIdLF3T3x2CjKGXAmge+2FEKiOjPBAJ1M+Vxd1T4uNmWAn+xe0VtD8RVK/O Eb7g== X-Gm-Message-State: ALyK8tKmFUv/Tfv3Lt/SPZgSxpp82tEwImnX6CQiyR/Kfr5Heju+XGpNkSqc5ia8Cfvy+CaSG19e6hBdbSNeXA== X-Received: by 10.37.211.132 with SMTP id e126mr12878825ybf.74.1468583992717; Fri, 15 Jul 2016 04:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Fri, 15 Jul 2016 04:59:13 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 15 Jul 2016 12:59:13 +0100 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c14710a35a7330537ab5b67 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why is resumption_context hashed? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:59:55 -0000 --94eb2c14710a35a7330537ab5b67 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 15, 2016 at 11:39 AM, David Benjamin wrote: > Every time resumption_context is used, it's fed into the PRF hash. > Handshake Context gets hashed since that actually expands to the full > concatenation and we want to be able to maintain a rolling hash. > But resumption_context is always a short value and is already the size of > the PRF hash. (If not resuming, it is the zero key, which is sized > appropriately. If resuming, it is the size of the PRF hash of the original > connection. But we require that resumptions use the same PRF, so that too > will be the right size.) > > Was there some other reason we needed to hash it, or is a guarantee of > constant size sufficient to use it directly? If it still needs to be > hashed, it seems we ought to redefine resumption_context to be > Hash(HKDF-Expand-Label(...)) instead, mostly as a hint to implementors that > one may as well store the final value in the ticket. > I didn't have a good reason. It was just giving me the heebie jeebies (technical term) to append something that wasn't hashed to something that was. -Ekr > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c14710a35a7330537ab5b67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 15, 2016 at 11:39 AM, David Benjamin <davidben@chromium.org> wrote:
Eve= ry time resumption_context is used, it's fed into the PRF hash. Handsha= ke Context gets hashed since that actually expands to the full concatenatio= n and we want to be able to maintain a rolling hash. But=C2=A0resumption_co= ntext is always a short value and is already the size of the PRF hash. (If = not resuming, it is the zero key, which is sized appropriately. If resuming= , it is the size of the PRF hash of the original connection.=C2=A0But we require that resumptions use the same PRF, so= that too will be the right size.)

Was there some= other reason we needed to hash it, or is a guarantee of constant size suff= icient to use it directly? If it still needs to be hashed, it seems we ough= t to redefine resumption_context to be Hash(HKDF-Expand-Label(...)) instead= , mostly as a hint to implementors that one may as well store the final val= ue in the ticket.

I didn't = have a good reason. It was just giving me the heebie jeebies (technical ter= m) to append something that wasn't hashed to something that was.
<= div>

=


David

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


--94eb2c14710a35a7330537ab5b67-- From nobody Fri Jul 15 10:34:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20E12D76D for ; Fri, 15 Jul 2016 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGzVEPtYRaz7 for ; Fri, 15 Jul 2016 10:34:41 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8276012D761 for ; Fri, 15 Jul 2016 10:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ry6HKNUc0vzAr7ibvN/fICieZ0hrykKrg6TOLDnbBFw=; b=kj+SvOKCyAHy98nRGQ6VpR8NTzFI5FKDziIf2E2zm7wcwTg1JXLQhQdSbjtHlto2TOyUvVR3QMaRmDDS3Fsh02+s7ofveJczrwrO/FZkHku1MrT82B78jqoAbW16QRdB8mckRENuo+dGqJJ5dnecv/6dDGebj1ZmqVykr4i4kIo= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Fri, 15 Jul 2016 17:34:40 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.023; Fri, 15 Jul 2016 17:34:40 +0000 From: Andrei Popov To: "ilariliusvaara@welho.com" Thread-Topic: [TLS] draft-rescorla-tls-subcerts Thread-Index: AQHR2IXi5/u6A9XC6UWhBIud7iIL56AYq7cggACVyoCAAIjwgA== Date: Fri, 15 Jul 2016 17:34:40 +0000 Message-ID: References: <20160715091423.GA6556@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160715091423.GA6556@LK-Perkele-V2.elisa-laajakaista.fi> 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:e::1d2] x-ms-office365-filtering-correlation-id: 8bf7db98-6e46-4a5f-381a-08d3acd64cfe x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:SbzKHuqKusyiwbqWzmbW2CsTYaxdV2D3uX1aE+cF04ZN5FpNT33S/nuQu5+d+k6znymkXrzV/UDnrJxc1DF1b1RKEnG6LF13/eebjoPd+h7Us4P4z9OoM98fx6PZcwPn7uzXOyLba6pdwC8hr3KuY+0nhFv1DCFPiKVlVbZt884WuH1ICnoaQArAKVz0RWXmG9kLguH6nhp3P/kjpi9IdTq4atPJy/hNXu1lS4Q36/hea3AT8JoW71K6gPQBBrIsGb3vp9tZYOqnbd4/DBu5Cq9dlMAlsLdjhj6eZciiMz19hlx7Bfr3eP59sU+m5fhou8h28bAxHC5QLDd/ylX9jQ==; 5:yeyPF/ZHdk8PLVEQoO6pTrmOdx+3TsajjU5plt8gR7wetMvoQWqY/tqEocqUqRiR3tnTZZc2OevtTjkIvCKVHz9oOPIsCSxR0EQzhLdAtAzTWqusSy3mHWsL/0gN6Rto2CE4PdOsfQBGin6sP+Y56g==; 24:tptT5wCLhdn/5oDwdi3lEZ+6fxKpResTMq0+ai+80TzJlPpcFzrxWDl7BY7eatbxCtDeB8xHWykhoaaqnO4Z3YngahOFaHgboptGeSpf3Qo=; 7:P5PrNeDUiR6OSaIdECftEjTcdD7ZY/9TBEtwQ8inZVveNGEjNt36J3CMi9vgNuyE1hUSSmQHXCiG79N/Mm8X7xQO6fDlAoG5o0t8iQzyPx0QQrcfU7qkUDUbWXxTpf/uOdcSDIGKw3DMMeyk8XqIrf7aNgE+S5rbMjRPeyJZWHOnihRYc9DgKOh1YUVEkkUyu6GdtaSzm50qSZGVu2Co+JCoCfXXbe607Tp3QqLNqb3I1B0Q34wq775wq3e6m8X1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(24454002)(5640700001)(586003)(74316002)(2351001)(305945005)(5002640100001)(106116001)(19580395003)(8936002)(19580405001)(122556002)(106356001)(2900100001)(230783001)(92566002)(1730700003)(9686002)(99286002)(7736002)(105586002)(7846002)(2501003)(77096005)(7696003)(5003600100003)(10090500001)(2906002)(33656002)(8990500004)(102836003)(2950100001)(4326007)(3280700002)(6116002)(3660700001)(68736007)(76176999)(76576001)(87936001)(54356999)(10290500002)(101416001)(50986999)(10400500002)(86362001)(11100500001)(86612001)(81156014)(8676002)(110136002)(5005710100001)(189998001)(81166006)(97736004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2016 17:34:40.2938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:34:43 -0000 PiBUaGUgSS1EIGFjdHVhbGx5IGNvdmVycyB0aGlzLg0KVW5kZXJzdG9vZDsgdGhlIEktRCBsaXN0 cyBhIGZldyBjb25zLCBidXQgYXJndWFibHkgbm9uZSBvZiB0aGVtIGFyZSBibG9ja2luZyBpc3N1 ZXMuIEl0IHNlZW1zIHVubmVjZXNzYXJ5IHRvIGNyZWF0ZSBhIG5ldyBUTFMtc3BlY2lmaWMgbWVj aGFuaXNtIHRoYXQgZHVwbGljYXRlcyBleGlzdGluZyBQS0kgc2VtYW50aWNzLg0KDQo+IFRob3Nl IHR3byBzZXJ2ZSBkaWZmZXJlbnQgcHVycG9zZXMuIFNvbWV0aW1lcyB5b3UgcmVhbGx5IG5lZWQg dGhlIEVTL0tTIHNwbGl0LCBzb21ldGltZXMgc2hvcnQtbGl2ZWQgY2VydHMgd291bGQgYmUgbW9y ZSB1c2VmdWwuDQpQb3NzaWJseSBzby4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSBbbWFpbHRv OmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMTUsIDIwMTYg MjoxNCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpD YzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1RMU10gZHJhZnQtcmVzY29ybGEtdGxzLXN1YmNlcnRzDQoNCk9uIEZyaSwgSnVsIDE1LCAy MDE2IGF0IDEyOjI4OjE4QU0gKzAwMDAsIEFuZHJlaSBQb3BvdiB3cm90ZToNCj4gTmHDr3ZlIHF1 ZXN0aW9uOiB3aHkgbm90IHNpbXBseSBnZXQgYSBjb25zdHJhaW5lZCBDQSBjZXJ0aWZpY2F0ZSBh bmQgDQo+IGlzc3VlIHNob3J0LXZhbGlkaXR5IGVuZCBlbnRpdHkgY2VydHM/IFVubGVzcyBJ4oCZ bSBtaXNzaW5nIHNvbWV0aGluZywgDQo+IHRoaXMgd291bGQgd29yayB3aXRoIGV4aXN0aW5nIFRM UyBpbXBsZW1lbnRhdGlvbnMsIG5vIGV4dGVuc2lvbnMgDQo+IHJlcXVpcmVkLg0KDQpUaGUgSS1E IGFjdHVhbGx5IGNvdmVycyB0aGlzLiBBZGRpdGlvbmFsbHksIEkgdGhpbmsgZ2V0dGluZyBOQyBj ZXJ0aWZpY2F0ZSBpcyBxdWl0ZSBleHBlbnNpdmUvZGlmZmljdWx0Lg0KDQo+IFNob3J0LWxpdmVk IGNyZWRlbnRpYWwgYXBwcm9hY2ggc2VlbXMgbW9yZSB2aWFibGUgdGhhbg0KPiBkcmFmdC1tZ2x0 LWx1cmstdGxzLXJlcXVpcmVtZW50cy0wMCAod2hpY2ggcmVxdWlyZXMgYW4gYWRkaXRpb25hbCAN Cj4gcm91bmQtdHJpcCBiZXR3ZWVuIHRoZSBFZGdlIFNlcnZlciBhbmQgQ29udGVudCBQcm92aWRl cikuDQoNClRob3NlIHR3byBzZXJ2ZSBkaWZmZXJlbnQgcHVycG9zZXMuIFNvbWV0aW1lcyB5b3Ug cmVhbGx5IG5lZWQgdGhlIEVTL0tTIHNwbGl0LCBzb21ldGltZXMgc2hvcnQtbGl2ZWQgY2VydHMg d291bGQgYmUgbW9yZSB1c2VmdWwuDQoNCg0KLUlsYXJpDQo= From nobody Fri Jul 15 11:47:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8CF12D190 for ; Fri, 15 Jul 2016 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABsnuK5KH0lY for ; Fri, 15 Jul 2016 11:47:02 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E648212D15E for ; Fri, 15 Jul 2016 11:47:01 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4FAC542377C; Fri, 15 Jul 2016 18:47:01 +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 2DB6942373D; Fri, 15 Jul 2016 18:47:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468608421; bh=UhX4713aI3QmF3V/MGSq527zGGsAkqDEnj5Kid9g6/M=; l=477; h=To:References:Cc:From:Date:In-Reply-To:From; b=AT5ss79VMyQURsX32/0R+urZ4zFZFOlzksz+BClrIq35Ev/g1Ma0MKaCHDg+4jgxL 7moteAs298hOxtfiodvld6Ll7KqyUrnaeJaC7uew/KP6zvTfjab5aaRHy8Yw3iNAgB ZmKzq0dxsA6FA+MMUQlaN5hWC4/eV8EE8livwQ/8= 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 E3B241FC95; Fri, 15 Jul 2016 18:47:00 +0000 (GMT) To: Andrei Popov References: <20160715091423.GA6556@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: <57892FA4.4080607@akamai.com> Date: Fri, 15 Jul 2016 13:47:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:47:03 -0000 On 07/15/2016 12:34 PM, Andrei Popov wrote: >> The I-D actually covers this. > Understood; the I-D lists a few cons, but arguably none of them are blocking issues. It seems unnecessary to create a new TLS-specific mechanism that duplicates existing PKI semantics. > I think the main justification is supposed to be that there's a big impedance mismatch between the engineering reality of interacting with PKI CAs and the engineering demands seen in the field. -Ben From nobody Sat Jul 16 02:09:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28B12D7D2 for ; Sat, 16 Jul 2016 02:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzopLpoiMXzu for ; Sat, 16 Jul 2016 02:09:34 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC526126579 for ; Sat, 16 Jul 2016 02:09:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 53DEF7B9A; Sat, 16 Jul 2016 12:09:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id wI6Musx7VzBa; Sat, 16 Jul 2016 12:09:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0F66D21C; Sat, 16 Jul 2016 12:09:33 +0300 (EEST) Date: Sat, 16 Jul 2016 12:09:29 +0300 From: Ilari Liusvaara To: Andrei Popov Message-ID: <20160716090929.GA11085@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160715091423.GA6556@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:09:36 -0000 On Fri, Jul 15, 2016 at 05:34:40PM +0000, Andrei Popov wrote: > > The I-D actually covers this. > Understood; the I-D lists a few cons, but arguably none of them are > blocking issues. It seems unnecessary to create a new TLS-specific > mechanism that duplicates existing PKI semantics. IMO, the draft severly understates the cons. Basically, NC certs aren't feasible except for the bigger shops that can afford the $$$ and the difficulty needed. Also, it doesn't look like the semantics are complicated. E.g one can completely skip revocation by making things short-lived (because revocation on short timescales simply does not work anyway). -Ilari From nobody Sat Jul 16 22:45:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6074812B040 for ; Sat, 16 Jul 2016 22:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oY_QX96WAam for ; Sat, 16 Jul 2016 22:44:56 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 36AAB12B00C for ; Sat, 16 Jul 2016 22:44:56 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id y188so2925498ywf.0 for ; Sat, 16 Jul 2016 22:44:56 -0700 (PDT) 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; bh=P7VyUIyVjfG38SPrBq3P+p0ps19raOJyGquUrJEwq7o=; b=ikB2yStDRUWbGtQVoDuniyEoCYpQ//XpPSqlSmQDx0ovr7HqSkfHbzLVP81CJSF829 sLt0mU4HWgBV5Th6vtiQxPVRxuDE9FQ9bLef3b004rai+YtOk9QotOmdA67ODoDupEDl Tgq+6nPmmpXy+hMhR7oV60dzKM18dADXmh7V+7YoY6wMqqFTN4EfWqeF3t+1HBrrLBkK cZFn/R0BlzqGcTffXyN/acQNtQwzkVRrykwCrfQN5BfRaCdKTOnqxJukimXo0zznzZLq i23pWC4PApQT/eRvdR0IXSPBOU1vbRCcUPgewnK3ilvRT4KycX6ZbhP3+0dVmEdHx9YS N0bg== 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; bh=P7VyUIyVjfG38SPrBq3P+p0ps19raOJyGquUrJEwq7o=; b=l/rc2km1WFFb1xAuGUYHQjZVG3M+K5WGpypchK64J9KRBI4LKeTWH6XtIoIHlz4C9+ r06jNUZS97hmNNNNtKvkvuqmm3IHGZKfwBTVsxoYEXQkh6ov3REeFeUpLzKCWwLwAiUO lEULMoJomgebU4i0KKsHiHDWJxTjcVRNqmYqf4iBLmUKxrR2GlxM24vDw0AY9BoCp/+5 UkKv4ONswq+2McvXn6o13Is3hBVBlI3/BW3nYp8beEqnVkUjs5wJ3v0alkmWTNWHNpZw vKd6NotPr9ifJ6xJTMyqyy7ZGOSA1mltuxeX4cYS/j7DIHrF5IopXZC2eAUO47TOtgRI xiEg== X-Gm-Message-State: ALyK8tIye5c9jMrT2L13/TzwZn475TfjKoL+qx/aLW4XL7OSKSk3wY0yWAlDstYjDdvoBSBjDzwl3JLOw8TtKg== X-Received: by 10.37.35.136 with SMTP id j130mr18582243ybj.84.1468734294657; Sat, 16 Jul 2016 22:44:54 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.64.3 with HTTP; Sat, 16 Jul 2016 22:44:25 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Sun, 17 Jul 2016 01:44:25 -0400 X-Google-Sender-Auth: 9ZSxMo4rbzZK1eO2wv5dciCInMk Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d3e1ce7128e0537ce5949 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why is resumption_context hashed? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 05:44:59 -0000 --001a113d3e1ce7128e0537ce5949 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B Here are some (second) thoughts on the derivation of resumption_context. The purpose of this value is to bind the resumed session to the data in the original connection, namely, to "ClientHello...Client Finished" (and, in particular, to the server's identity). The right way to do this binding is by defining resumption_context =3D CR(ClientHello...Client Finished) where CR is a collision resistant function. This CR can be the TLS hash function Hash or it can be implemented by a series of HKDF computations as currently done. Specifically, we now have two steps: resumption_secret =3D Derive-Secret(Master Secret, "resumption master secre= t", ClientHello...Client Finished) resumption_context =3D HKDF-Expand-Label(resumption_secret, "resumption context", "", Hash.Length) Due to the use of HMAC in HKDF, if the underlying Hash is collision resistant then one can argue that the above two-step derivation is also collision resistant (as long as there is not truncation anywhere in the derivation process!). Still, it would be nicer if the collision resistance property would be more direct/explicit. The most explicit way would be just to define: resumption_context =3D Hash(ClientHello...Client Finished). However, this deterministic derivation from the original handshake transcript has disadvantages, including possible leakage on the handshake transcript values and the danger of reusing the same value for other purposes. The next alternative would be to define resumption_context as a "sibling" of resumption_secret, namely, resumption_context =3D Derive-Secret(Master Secret, "resumption context", ClientHello...Client Finished) This does not make explicit the use of a collision resistant hash function in the derivation but at least shows the direct relationship of resumption_context to the handshake transcript. Collision resistance can still be argued on th= e basis of HKDF properties. Finally, we can stick to the current definition which, as said, can be argued via collision resistance properties of HKDF, but with one more level of indirection (and less explicit relation to the handshake transcript). In all cases, we need some text in the security considerations about the collision resistance assumption on HKDF (which is not an integral part of its key derivation definition); this applies also to the exporter key as mentioned in a previous email and any key/value that can be used as a "binding value". Hugo PS: To the question of whether we should apply Hash to resumption_context when concatenating it to other hashes, the answer is that this does not make a difference. It does not add or subtract from the collision resistance property of resumption_context. =E2=80=8B On Fri, Jul 15, 2016 at 7:59 AM, Eric Rescorla wrote: > On Fri, Jul 15, 2016 at 11:39 AM, David Benjamin > wrote: > >> Every time resumption_context is used, it's fed into the PRF hash. >> Handshake Context gets hashed since that actually expands to the full >> concatenation and we want to be able to maintain a rolling hash. >> But resumption_context is always a short value and is already the size o= f >> the PRF hash. (If not resuming, it is the zero key, which is sized >> appropriately. If resuming, it is the size of the PRF hash of the origin= al >> connection. But we require that resumptions use the same PRF, so that >> too will be the right size.) >> >> Was there some other reason we needed to hash it, or is a guarantee of >> constant size sufficient to use it directly? If it still needs to be >> hashed, it seems we ought to redefine resumption_context to be >> Hash(HKDF-Expand-Label(...)) instead, mostly as a hint to implementors t= hat >> one may as well store the final value in the ticket. >> > > I didn't have a good reason. It was just giving me the heebie jeebies > (technical term) to append something that wasn't hashed to something that > was. > > -Ekr > > >> >> David >> >> _______________________________________________ >> 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 > > --001a113d3e1ce7128e0537ce5949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B

Here are s= ome (second) thoughts on the derivation of resumption_context.
=

=
The p= urpose of this value is to bind the resumed session to the data in the
ori= ginal connection, namely, to "ClientHello...Client Finished" (and= , in
particular, to the server's identity).
The right way to do this = binding is by defining
resumption_context =3D CR(ClientHello...Client Fin= ished)=C2=A0
where CR is a collision resistant function. =C2=A0

Thi= s CR can be the TLS hash function Hash or it can be implemented by a series=
Specifically, we now have = two steps:

resumption_secret =3D Derive-Secret(Master Secret, "= resumption master secret",
=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 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello...Client Finished)=
resum= ption_context =3D HKDF-Expand-Label(resumption_secret,
=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"resumption context", "", Hash.Leng= th)

Due to the use of HMAC in HKDF, if the underlying Hash is collis= ion resistant
then one can argue that the above two-step derivation is als= o collision
resistant (as long as there is not truncation anywhere in the = derivation
process!).

Still, it would be nicer if the collision re= sistance property would be more
direct/explicit. The most explicit way wou= ld be just to define:
resumption_context =3D Hash(ClientHello...Client F= inished).
However, this deterministic derivation from the original handsha= ke transcript
has disadvantages, including possible leakage on the handsha= ke transcript values
and the danger of reusing the same value for other pu= rposes.

The next alternative would be to define resumption_context a= s a "sibling" of=C2=A0
<= font face=3D"verdana, sans-serif">resumption_secret, namely,
resumption_co= ntext =3D Derive-Secret(Master Secret, "resumption context",
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0ClientHello...Client Finished)
= This does not make explicit the use of a= collision resistant hash function in
the derivation but at least shows th= e direct relationship of resumption_context
to the handshake transcript. C= ollision resistance can still be argued on the
basis of HKDF properties.
=
Finally, we can stick to the current definition which, as said, can b= e argued
via collision resistance properties of HKDF, but with one more le= vel of
indirection (and less explicit relation to the handshake transcript= ).

In all cases, we need some text in the security considerations ab= out the=C2=A0collisio= n=C2=A0
resistance assumption on HKDF (which is not an integra= l part of=C2=A0its ke= y derivation=C2=A0
definition);=C2=A0this applies also to the exporter key as menti= oned in a previous email
and any key/value that can be used as= a "binding value".

Hugo

PS: To the que= stion of whether we should apply Hash to resumption_context when
concatena= ting it to other hashes, the answer is that this does not make a
differenc= e. It does not add or subtract from the collision resistance property
of r= esumption_context.

=E2=80=8B

On Fri, Jul 15, 2016 at 7:59 AM, Eric Rescorla <ekr@rtfm.com= > wrote:
On Fri, Jul 15, 201= 6 at 11:39 AM, David Benjamin <davidben@chromium.org> wr= ote:
Every time resumption_context is = used, it's fed into the PRF hash. Handshake Context gets hashed since t= hat actually expands to the full concatenation and we want to be able to ma= intain a rolling hash. But=C2=A0resumption_context is always a short value = and is already the size of the PRF hash. (If not resuming, it is the zero k= ey, which is sized appropriately. If resuming, it is the size of the PRF ha= sh of the original connection.=C2=A0But we = require that resumptions use the same PRF, so that too will be the right si= ze.)

Was there some other reason we needed to has= h it, or is a guarantee of constant size sufficient to use it directly? If = it still needs to be hashed, it seems we ought to redefine resumption_conte= xt to be Hash(HKDF-Expand-Label(...)) instead, mostly as a hint to implemen= tors that one may as well store the final value in the ticket.
<= /blockquote>

I didn't have a good reason. It = was just giving me the heebie jeebies (technical term) to append something = that wasn't hashed to something that was.

-Ekr=



David

_______________________________________________
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


--001a113d3e1ce7128e0537ce5949-- From nobody Sun Jul 17 14:42:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9DF12D0FE for ; Sun, 17 Jul 2016 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqMtqWmBy4LW for ; Sun, 17 Jul 2016 14:42:46 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 A86E412D096 for ; Sun, 17 Jul 2016 14:42:46 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 52so83705399qtq.3 for ; Sun, 17 Jul 2016 14:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zo3sd7yFz8o24862n7uEmp3xLpSSlDx7WHut1WItuMc=; b=AZ604t4lgyEEy42PcJhxNbL6jeYL7NzMJmlmSLy/RMyoLhkaqVTvZRe4KTidPPddjE qCMIankk/BWyW6jIdlzZjfdxkE4rPsSsuWc8qeFKDxQ+TlosO0nBmQ0PJpEnb7PMA767 09cKgDOgX2LhZR8CASdCtzjDyjHB5vwAGKeS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zo3sd7yFz8o24862n7uEmp3xLpSSlDx7WHut1WItuMc=; b=RX+V8wljdgBq2CwJie+OhD40hjH9pVn29ITZ6igknESUUSksgBSeYmgAueJ24UYM/M bWYNJqPzGxjYDRNRuIBodgCpLT6GAW2C8fzqBKCisWY/+1zQn2E6v5xUqQC+ScwK+9bb P6tKxCKliY3ISOYCk2odKRiMzhKLA9bItRwXfT57+pn+MmCJHb4FqmwCJWl+9KaG+Sd5 XYeb0w/IBC8m3LMLn4aUHgVJ66SgQ2GbiyO3/7K67i5Yx2NLzSzfWC5kOkvA0sT/qi3m E/E+qj2mfcsRumNwdiI3cyWqJpE2EZMNuZ2ZVX2V6IYIz0PlOMjxpmli953+BmUZj78d pCMg== X-Gm-Message-State: ALyK8tLrNZwAam/V9xoZDAzZBFwjtS62adlWdqibZUp9XL3qtMCofV0jzLyjDB0+KqqlVA== X-Received: by 10.237.53.157 with SMTP id c29mr44161746qte.75.1468791765659; Sun, 17 Jul 2016 14:42:45 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id b132sm1256515qkg.8.2016.07.17.14.42.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jul 2016 14:42:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> Date: Sun, 17 Jul 2016 17:42:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2FA8CD53-697B-4B83-856C-7DBB77B528F8@sn3rd.com> References: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] WG Status of draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:42:48 -0000 The comment period has now passed. There appears to be no support to = continue work on draft-ietf-tls-pwd in the TLS WG. The chairs will = leave the draft in the =E2=80=9Cparked=E2=80=9D status. Note that the = authors are free to attempt to progress the draft through other = channels, but are requested to progress the draft as an individual = submission (i.e., resubmit the draft as draft-nomdeplume-catchytitlehere = before approaching an AD or the ISE). The chairs will ensure the = =E2=80=9Creplaces=E2=80=9D metadata information is attached to the = resubmitted draft to ensure the draft=E2=80=99s history is not lost. J&S > On Jun 27, 2016, at 10:35, Sean Turner wrote: >=20 > All, >=20 > draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late = 2013. It was parked=C2=9D by the WG chairs because there was no = consensus to move the document forward during WGLC [2][3]. However, = circumstances have changed namely the publication of Dragonfly Key = Exchange RFC [4] and the proposed changes to the IANA registration rules = for algorithm code points. In light of these two developments, the = chairs want to revisit this decision and would like to know before 12 = July if the WG wants to progress draft-ietf-pwd as a WG item to obtain = algorithm code points under the new rules [5]. >=20 > Note that if the WG decides not to progress the draft the author will = be free to pursue other publication paths, e.g., through the AD or the = ISE. >=20 > Thanks, >=20 > J&S >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > [1] https://datatracker.ietf.org/doc/rfc6174/ > [2] = https://mailarchive.ietf.org/arch/msg/tls/aYIXwO8l4K8XdvUoW9ysHT8WzA0 > [3] = https://mailarchive.ietf.org/arch/msg/tls/Fep2-E7xQX7OQKzfxOoFInVFtm4 > [4] https://datatracker.ietf.org/doc/rfc7664/ > [5] Obviously, the draft needs to be revised in light of [3]. From nobody Mon Jul 18 03:06:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9710212D740 for ; Mon, 18 Jul 2016 03:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r2-rCwQHAXP for ; Mon, 18 Jul 2016 03:06:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A40712D76D for ; Mon, 18 Jul 2016 03:06:26 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 870F51FE034E; Mon, 18 Jul 2016 03:06:25 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 18 Jul 2016 03:06:26 -0700 (PDT) Message-ID: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 18 Jul 2016 03:06:26 -0700 (PDT) From: "Dan Harkins" To: robert.cragie@gridmerge.com 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] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:06:43 -0000 Hi Robert, This draft moves the NamedCurve/EllipticCurveList into the ClientHello, and since the client sends X1 and ZKP(X1) in the ClientHello it means that is going to be a list of 1. It basically moves the client's key exchange portion from ClientKeyExchange into ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE then that's the only thing it can offer and the parameters of that exchange are all selected by the client, not the server. This is a fundamental change to TLS. If it's going to be offered, it's the only thing that can be offered and therefore the only thing that can be used. Seems like for a deployment either it's never used or it's the only thing used and that makes it sort of a proprietary protocol, not TLS. Dan. On Thu, June 16, 2016 2:51 am, Robert Cragie wrote: > I would like to ask the working group for comments on the TLS-ECJ-PAKE > draft: > > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 > > Some brief notes: > > * This intended status is informational. > * The draft is based on TLS/DTLS 1.2 as the Thread group required basis on > existing RFCs wherever possible. For that reason and due to the WGs focus > on TLS 1.3, I have understood from the chairs that it would not have > received a great deal of attention from the WG, hence the intended status > of informational. > * The draft reflects the current use of the TLS_ECJPAKE_WITH_AES_128_CCM_8 > cipher suite in Thread (http://threadgroup.org/). > * There is an experimental implementation in mbed TLS ( > https://github.com/ARMmbed/mbedtls) > * The Thread group would like to get IANA assignments for 4 cipher suite > values and one ExtensionType value as soon as possible. > * There are at least four independent implementations, which have been > used > in interop. testing over the last 18 months. > * The security considerations recommend restriction of the use of this > cipher suite to Thread and similar applications and recommends it should > not be used with web browsers and servers (mainly due to the long > discussions regarding the use of PAKEs on this and other mailing lists). > > Robert > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Jul 18 04:08:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0258E12D8C9 for ; Mon, 18 Jul 2016 04:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBgGxVns3dCD for ; Mon, 18 Jul 2016 04:08:48 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D184412D8CB for ; Mon, 18 Jul 2016 04:08:47 -0700 (PDT) Received: from pc1 ([2001:67c:370:176:e394:67f1:be9a:d08e]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Mon, 18 Jul 2016 13:08:46 +0200 id 0000000000000051.00000000578CB8BE.000053DA Date: Mon, 18 Jul 2016 13:08:43 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: "" Message-ID: <20160718130843.0320d43f@pc1> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:08:52 -0000 Hi, Recently both Adam Langley [1] and David Benjamin [2] indicated that they expect with TLS 1.3 Browsers will have to bring back the infamous version falbacks that caused so much trouble in the past (POODLE etc.) to work around broken implementations of the TLS handshake. I don't blame browser vendors for this, I can understand their reasoning why they think they have to do this, although I don't share their opinion. But I think this sheds a light on the sorry state of TLS implementations and I want to ask if there's a better way out of this. Let me quickly summarize how I see the situation: * The issue has been known for a long time. I found a document from Mozilla [3] from 2003 that describes the core issue. * While there is a lot of scattered discussion about the issue, the pure documentation status of this problem is far from ideal. I am not aware of any good documentation that even describes how exactly version intolerance happens. The "classic" variant seems to be implementations that just close the connection if they are contacted with a version number higher than what they support. But there are also weirder variants where a connection attempt with TLS 1.2 will be downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead to an answer with TLS 1.0. Questions I couldn't easily answer is how connections are terminated (TCP disconnect? TLS alert? Timeouts?) Also I'm not fully aware what the different version numbers (ClientHelo + record version number) mean in context of a handshake and how this influences version intolerance issues. * There don't seem to be any straightforward tools that test for version intolerance. The SSL Labs test does detect version intolerance, but it's limited to public facing https servers and it doesn't seem to detect some of the weirder variations (as described above). There's also a test in Hubert Kario's tlsfuzzer, but I've been unable to get it to work. I tried to create a test myself, but the results were highly erratic and I'm not sure why. * We don't have good data on the issue. The latest numbers I could find came from Ivan Ristic in 2013 [4], and from David Benjamin we know he considers the problem to be large enough that version fallbacks are inevitable. That's far from good data. We also don't seem to have any public list of affected vendors, devices and webpages. I want to try to work on some of those issues in the near future. Roughly I'd like to see that we work on a plan to reduce TLS brokenness in general and in particular - right now as this is an issue affecting the deployment of TLS 1.3 - Version intolerance. Things that I think we could and should do: * Talk to developers of test tools (sslyze, testssl, openvas, but also commercial tools etc.) that they include appropriate tests in their tools and warn about these issues. Also it'd be great if e.g. things like the google webmaster tools or any other public test tools for webservers/websites could test for this. * Raise this issue with pentesters and tell them they should include this when they're testing devices / products. (Of course this requires to have test tools in the first place.) * Get some data from internet wide scans and make it public. Maybe have a public shame list of the top X pages breaking TLS. * In general, more and better detailed documentation of this and similar issues, also raise this as a potential research topic. My hope would be that we can avoid the reintroduction of version fallbacks or at the very least reduce the amount of time they have to be used. And hopefully at least avoid them altogether for TLS 1.4 or whatever comes after 1.3. I'm in Berlin at IETF96 in case people want to discuss this. As this is terribly late for this I don't know if this can be included in the TLS WG discussion as it's probably already packed with other issues (but I'd happily introduce the issue if people want to discuss it). [1] https://www.imperialviolet.org/2016/05/16/agility.html [2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_= -_SSL_3.0_Intolerant_Servers [4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 From nobody Mon Jul 18 06:12:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1617B12DAEC for ; Mon, 18 Jul 2016 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.189 X-Spam-Level: X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD0piWYaJ7uz for ; Mon, 18 Jul 2016 06:11:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BDB12DA39 for ; Mon, 18 Jul 2016 06:08:10 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA943C0005D0; Mon, 18 Jul 2016 13:08:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6ID88wt026261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2016 09:08:09 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 18 Jul 2016 15:08:03 +0200 Message-ID: <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.6.3-300.fc24.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: <20160718130843.0320d43f@pc1> References: <20160718130843.0320d43f@pc1> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2311106.RTmiUEvLIW"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 18 Jul 2016 13:08:10 +0000 (UTC) Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:12:01 -0000 --nextPart2311106.RTmiUEvLIW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 18 July 2016 13:08:43 Hanno B=C3=B6ck wrote: > * There don't seem to be any straightforward tools that test for > version intolerance. The SSL Labs test does detect version > intolerance, but it's limited to public facing https servers and it= > doesn't seem to detect some of the weirder variations (as described= > above). There's also a test in Hubert Kario's tlsfuzzer, but I've > been unable to get it to work. I tried to create a test myself, but= > the results were highly erratic and I'm not sure why. I hope that the updated README helps about this (just pushed the change= s), tell me if anything else is missing feel free to send the problems with the test you wrote yourself (but please remember, the note in README applies - it's an alpha, so no API stability guarantees) > * We don't have good data on the issue. The latest numbers I could fi= nd > came from Ivan Ristic in 2013 [4], and from David Benjamin we know = he > considers the problem to be large enough that version fallbacks are= > inevitable. That's far from good data. We also don't seem to have a= ny > public list of affected vendors, devices and webpages. I'm running a test against the Alexa Top 1 million /right now/ using th= is code: https://github.com/jvehent/cipherscan/pull/109 In general it's a rough check, i.e. it's only a check for client hello version intolerance, irrespective of record layer version, ciphers or extensions (it sends multiple probes, based on different clients and then modified) I've also added an Xmas-client hello message[1] that aims to trigger as= many intolerancies as possible, but it's mostly just to single out some weirder servers. e.g. some servers will just close connection if you send them an SNI name they don't expect 1 - similar to https://en.wikipedia.org/wiki/Christmas_tree_packet > I want to try to work on some of those issues in the near future. > Roughly I'd like to see that we work on a plan to reduce TLS brokenne= ss > in general and in particular - right now as this is an issue affectin= g > the deployment of TLS 1.3 - Version intolerance. >=20 > Things that I think we could and should do: > * Talk to developers of test tools (sslyze, testssl, openvas, but als= o > commercial tools etc.) that they include appropriate tests in their= > tools and warn about these issues. Also it'd be great if e.g. thing= s > like the google webmaster tools or any other public test tools for > webservers/websites could test for this. +1, especially TLS 1.3 client hello version intolerance should be an outright failure of any TLS test > * Get some data from internet wide scans and make it public. Maybe ha= ve > a public shame list of the top X pages breaking TLS. I'm working on it. I'll make the scan data public, but I'll leave the shaming part to somebody else > * In general, more and better detailed documentation of this and > similar issues, also raise this as a potential research topic. +1 again, I think we should do a more "negative" reading of the TLS sta= ndard (as in what the peer should do if the other side does not behave as expected) both to specify what alerts should be sent, when, and when such "misbehavior" MUST NOT trigger any failure in the other side =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 --nextPart2311106.RTmiUEvLIW 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 iQIcBAABCgAGBQJXjNSzAAoJEJKo0bgB0vX18TcP/RnwWwiPIW6kk5JJ3UjnBYq7 wlNws21moRdyhvWUcOzFF5liJsucs5QJ8je8HcZ4x0sf9KpNV1ofZOP59ABJ0gnC 5TBn37oXHJHnzB5mWQOWv5CS17KPfIwYqlzjsYcEEvYhBc0x3/z8hJApZyeQGXeF q9X8F7ecK1jvlfHVcxrYwUukAbI3xJKxbd2L3X+jJEbI+K42GdoeoBQMOb4NNnpZ kEldwCerDRQBD4V4naD/u3zhd8HEYZQl1ZVhqbIE1ckuRB3+4VXFY0eBuL49oint 6xftLllDOGIUT/vfOHdEc/MhAsbHYxA5+mKLezsGeSRfH251vsRSJbPwoqOPa3s+ jL06R5a6e7ouyvOw0Seq2vLVuM4bNVw/AE/06owCLXbM6ODUqbt1HFFJXeUNIJPC 1gMivy1mPa+1yTbw3RHGWO1C0jl0jRID7tb+V0Y/WBYDh2FGLosr0ytz5sa9aUBJ oJXzzs7PWeyNVQIxsz5eKyvgEYcjc7STHiIgFWUncwH47Tm97RL+l100jSwoPnJl 8x8I19U6tvuHGxCFnBXINc2GK9+9HVbswCCMVXLqe1KLSzESTU4u1T0egs9fy224 gahFzuZ8xQMQsk69OU0inVvGzaYJRKELVx9IrsrsI1pXeTc0Nfe1yFDNBrDtCQQF WnbY6SGFzr0Pv4gsu9Xr =1xnJ -----END PGP SIGNATURE----- --nextPart2311106.RTmiUEvLIW-- From nobody Mon Jul 18 06:27:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9512DD2F for ; Mon, 18 Jul 2016 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJLtKDvPCnb9 for ; Mon, 18 Jul 2016 06:27:33 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81D0312DADE for ; Mon, 18 Jul 2016 06:17:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 192787F3E for ; Mon, 18 Jul 2016 16:17:39 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZcEWy4OpVGD6 for ; Mon, 18 Jul 2016 16:17:38 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5A4122315 for ; Mon, 18 Jul 2016 16:11:11 +0300 (EEST) Date: Mon, 18 Jul 2016 16:11:07 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160718131107.GA12937@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718130843.0320d43f@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160718130843.0320d43f@pc1> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:27:39 -0000 On Mon, Jul 18, 2016 at 01:08:43PM +0200, Hanno Böck wrote: > Hi, > > Recently both Adam Langley [1] and David Benjamin [2] indicated that > they expect with TLS 1.3 Browsers will have to bring back the infamous > version falbacks that caused so much trouble in the past (POODLE etc.) > to work around broken implementations of the TLS handshake. > > I don't blame browser vendors for this, I can understand their > reasoning why they think they have to do this, although I don't share > their opinion. But I think this sheds a light on the sorry state of TLS > implementations and I want to ask if there's a better way out of this. Ocassionally browsers also send odd stuff: Recently I ran into a browser that sends empty session_ticket (or whatever) instead of session_ticket with empty ticket. This becomes an issue when the server is pretty hard about TLS hanshake syntax. > * While there is a lot of scattered discussion about the issue, the > pure documentation status of this problem is far from ideal. I am not > aware of any good documentation that even describes how exactly > version intolerance happens. The "classic" variant seems to be > implementations that just close the connection if they are contacted > with a version number higher than what they support. But there are > also weirder variants where a connection attempt with TLS 1.2 will be > downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead > to an answer with TLS 1.0. Questions I couldn't easily answer is how > connections are terminated (TCP disconnect? TLS alert? Timeouts?) > Also I'm not fully aware what the different version numbers > (ClientHelo + record version number) mean in context of a handshake > and how this influences version intolerance issues. Things are made even more complicated by the intearction of extension intolerance: Newer TLS versions might involve new extensions, which may choke a server, causing extension intolerance to be misdiagnosed as version intolerance. > * There don't seem to be any straightforward tools that test for > version intolerance. The SSL Labs test does detect version > intolerance, but it's limited to public facing https servers and it > doesn't seem to detect some of the weirder variations (as described > above). There's also a test in Hubert Kario's tlsfuzzer, but I've > been unable to get it to work. I tried to create a test myself, but > the results were highly erratic and I'm not sure why. Also, I have seen at least one server that SSL labs claimed is intolerant to TLS 1.2, but browser could connect using TLS 1.2 ClientHello without fallback (verified using wireshark). No real idea what caused that. > I want to try to work on some of those issues in the near future. > Roughly I'd like to see that we work on a plan to reduce TLS brokenness > in general and in particular - right now as this is an issue affecting > the deployment of TLS 1.3 - Version intolerance. > > Things that I think we could and should do: > * Talk to developers of test tools (sslyze, testssl, openvas, but also > commercial tools etc.) that they include appropriate tests in their > tools and warn about these issues. Also it'd be great if e.g. things > like the google webmaster tools or any other public test tools for > webservers/websites could test for this. I think SSL labs has had TLS 1.3 intoleance test for a long time. Of course, it probably doesn't test with what real-world TLS 1.3 ClientHello looks like... -Ilari From nobody Mon Jul 18 06:51:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1784412DE91 for ; Mon, 18 Jul 2016 06:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwfjywCqHHcX for ; Mon, 18 Jul 2016 06:51:28 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A1512DD25 for ; Mon, 18 Jul 2016 06:27:30 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 52so91494927qtq.3 for ; Mon, 18 Jul 2016 06:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9SeUQg6qVZ47RiE67bwTMpc3YnC8rtC5UZORJaTWGvo=; b=LjkgUW1/HDGEYInizqdz3uWJ5lpTt5aF1fZGHKPS4wO51ccnzSt97XzKehh/z7/Nj8 LMjZdDBwbW5vVQ/k30jd1Fjfbi/xWo/eOzDxtU3wlAu03Gqh9ZM+SFbtgUsDo9lKqOjG J2k5lFyBHps32ehzg10lIdIzJdgWP6h0h8jXs= 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; bh=9SeUQg6qVZ47RiE67bwTMpc3YnC8rtC5UZORJaTWGvo=; b=Ksz91/hF+bu42ff1hQoZnd3o21mpaaiA+XJOYvTh/6ZRWQrXxq5HSq3tPCN/ppkrbl 4znAxvoo7vu0thFEKzRT0FKa1ogj5rZn3PYdE+pLORCcMWDMQYQ8E7RkpGjPioqB6Ufp gK/3enwJtzTAeVxEl47iYpGeP23yoKxjjEOjDK8R+XmH8HQEP1SXM6ROIY+GVCde9qn1 PGlUU54gRl+/X/CauLLSRK76YIxa7WvimJzzkwmEJswFHzwRyWqs4QM76l9UVU4pCLtx edIQulrrAzUGozSGxfcvh2sUJf1UOQn/O3ZcRuwA08Qcig2b+H+0Z38wMUZAFGfc6k// HiCQ== X-Gm-Message-State: ALyK8tI83AXY+k1RwfqSI39x7hFd6auDX9rUHZJdEd9rUVkWDfHT2+n7k1ZELzHsmwvk9Nl7MVyieztf7iyCSw== X-Received: by 10.237.36.38 with SMTP id r35mr52728481qtc.3.1468848449063; Mon, 18 Jul 2016 06:27:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.118.135 with HTTP; Mon, 18 Jul 2016 06:27:28 -0700 (PDT) X-Originating-IP: [31.133.178.3] In-Reply-To: References: From: Kyle Rose Date: Mon, 18 Jul 2016 15:27:28 +0200 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d3aac092b690537e8ee27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:51:34 -0000 --001a113d3aac092b690537e8ee27 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote: > There have been a lot of discussions about whether we should try to > refactor cipher-suite negotiation to be less monolithic in the cipher > suite. I've generally been on the "no" side of that on cost/benefit > grounds as well as not quite seeing how it would fit into the rest > of the infrastructure. However, now that we're starting to get full > implementations, and it's becoming clearer how the new elements > (principally PSK-resumption and key_shares) interact with cipher > suites, I've started to think that in fact we may be able to clean > things up. One proposal for this is below [0]. I know this is > pretty late in the process, but if we do want this change it's > better to do it now. > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > fire away. > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > Tl;dr: I think this is a good approach because it eliminates much of the existing negotiation redundancy/complexity and combinatorial explosion in the 1.3+ ciphersuite menu. The longer version: the argument I made in Prague (though IIRC not very clearly) was that while it would be nice to limit the ciphersuite options to agreed-upon "good" combinations based on some sane notion of forward-looking security margin (notwithstanding the practical inability to see the future), the reality on the ground is that authentication is based on something pre-existing---the server has one or two long-term keys of a fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on demand---so it really only makes sense for the client to indicate what it supports and to deal with whatever the server chooses to send it on that basis. So I'd argue that this one is orthogonal based on that constraint, and so it should be negotiated separately. AEAD and PRF OTOH don't come with built-in keys, so they can always be chosen as a pair as a function of the desired security margin. Key agreement is not clearly in either category: when it's PSK, it's based on what you have, so it's similar to authentication; but when it's (EC)DHE, it's not, and so ideally you'd like the chosen group to be tied to the AEAD/PRF security margin. But, since the client has to offer specific groups rather than specifying general support for ECDHE or EdDHE, both because ideally we want the client key share sent in the first flight and because unlike RSA or FFDHE a client can't generalize to key sizes it hasn't seen before, it actually still shares a lot in common with the auth case of being sort-of something you have rather than something you can choose on the fly. So I'm also in agreement that this is mostly orthogonal and should be negotiated separately. So now you have several grab bags and need to choose one from each. Is it necessary to tie the various bits together by security margin? Not clear. It's probably fine to assume a client isn't going to announce support for anything it doesn't think is secure enough, so the only practical downside to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary additional CPU consumption of AES-256/SHA-384. The client was willing to accept P-256 server authentication, so presumably it's happy with that security margin; and anyway, the server could prefer ciphersuites and ECDHE groups that better match the available auth credentials. Additionally, aside from the situation in which a paucity of ciphersuites is offered by a client, the one situation with no good resolution is security margin of PSK vs. authentication in PSK+signature: both are based on pre-existing credentials, one offered by the client and one offered by the server, so if they disagree there's nothing to be done about it. So maybe the server then just prefers ciphersuites (and group in PSK+DHE) that match the minimum of the security margin of the PSK and available auth credentials. Or maybe prospective security margin is too complex and/or too ill-defined to bother with, and a server should just choose the least CPU-intensive combination of everything. In other words, we just eliminate the redundancy with the cipher suite > indications. This leaves is with the question of how to handle the > existing TLS 1.2 cipher suites. We can either assign new cipher suites > or say that any cipher suite with *_aead_alg_hash means that we > support aead_alg_hash. Matter of taste. > Meaning that if a 1.3 client offers TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and the server has only TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 in its list, that they would internally map to the same ciphersuite and so the server would agree on and offer up the client's code point? It might be cleaner just to have new suites for 1.3, if for no other reason but to reduce confusion when someone looks at this ten years from now. Kyle --001a113d3aac092b690537e8ee27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
The= re have been a lot of discussions about whether we should try to
refact= or cipher-suite negotiation to be less monolithic in the cipher
s= uite. I've generally been on the "no" side of that on cost/be= nefit
grounds as well as not quite seeing how it would fit into t= he rest
of the infrastructure. However, now that we're starti= ng to get full
implementations, and it's becoming clearer how= the new elements
(principally PSK-resumption and key_shares) int= eract with cipher
suites, I've started to think that in fact = we may be able to clean
things up. One proposal for this is below= [0]. I know this is
pretty late in the process, but if we do wan= t this change it's
better to do it now.

<= div>I'm sure we'll need to discuss this in Berlin, but in the meant= ime,
fire away.


The basic= idea here is to factor out the TLS 1.3 negotiation into three
mo= stly orthogonal axes.=C2=A0

- Symmetric cipher/PRF= =C2=A0-- indicated by the cipher suite list as in TLS 1.2
- Key = exchange -- indicated by the key_shares and pre_shared_key extensions
=
- Authentication -- indicated the signature_algorithms and pre_shared_= key
=C2=A0 extensions

Tl;dr: I think this is a good approach because it eliminates much of the e= xisting negotiation redundancy/complexity and combinatorial explosion in th= e 1.3+ ciphersuite menu.

The longer version: t= he argument I made in Prague (though IIRC not very clearly) was that while = it would be nice to limit the ciphersuite options to agreed-upon "good= " combinations based on some sane notion of forward-looking security m= argin (notwithstanding the practical inability to see the future), the real= ity on the ground is that authentication is based on something pre-existing= ---the server has one or two long-term keys of a fixed length (e.g., one RS= A-2048 and one P-256) that it can't augment on demand---so it really on= ly makes sense for the client to indicate what it supports and to deal with= whatever the server chooses to send it on that basis. So I'd argue tha= t this one is orthogonal based on that constraint, and so it should be nego= tiated separately.

AEAD and PRF OTOH don't come with = built-in keys, so they can always be chosen as a pair as a function of the = desired security margin.

Key agreement is not clear= ly in either category: when it's PSK, it's based on what you have, = so it's similar to authentication; but when it's (EC)DHE, it's = not, and so ideally you'd like the chosen group to be tied to the AEAD/= PRF security margin. But, since the client has to offer specific groups rat= her than specifying general support for ECDHE or EdDHE, both because ideall= y we want the client key share sent in the first flight and because unlike = RSA or FFDHE a client can't generalize to key sizes it hasn't seen = before, it actually still shares a lot in common with the auth case of bein= g sort-of something you have rather than something you can choose on the fl= y. So I'm also in agreement that this is mostly orthogonal and should b= e negotiated separately.

So now you= have several grab bags and need to choose one from each. Is it necessary t= o tie the various bits together by security margin? Not clear. It's pro= bably fine to assume a client isn't going to announce support for anyth= ing it doesn't think is secure enough, so the only practical downside t= o using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary addition= al CPU consumption of AES-256/SHA-384. The client was willing to accept P-2= 56 server authentication, so presumably it's happy with that security m= argin; and anyway, the server could prefer ciphersuites and ECDHE groups th= at better match the available auth credentials.

Additionally, aside from the situation in which a paucity of c= iphersuites is offered by a client, the one situation with no good resoluti= on is security margin of PSK vs. authentication in PSK+signature: both are = based on pre-existing credentials, one offered by the client and one offere= d by the server, so if they disagree there's nothing to be done about i= t. So maybe the server then just prefers ciphersuites (and group in PSK+DHE= ) that match the minimum of the security margin of the PSK and available au= th credentials.

Or maybe prospective security margin is too complex = and/or too ill-defined to bother with, and a server should just choose the = least CPU-intensive combination of everything.

In other words, we just eliminate the redundancy with the cipher suite<= div>indications. This leaves is with the question of how to handle the
existing TLS 1.2 cipher suites. We can either assign new cipher suite= s
or say that any cipher suite with *_aead_alg_hash means that we=
support aead_alg_hash. Matter of taste.
=

Meaning that if a 1.3 client offers TLS_ECDHE_RSA_WITH_= AES_256_GCM_SHA384 and the server has only TLS_ECDHE_ECDSA_WITH_AES_256_GCM= _SHA384 in its list, that they would internally map to the same ciphersuite= and so the server would agree on and offer up the client's code point?= It might be cleaner just to have new suites for 1.3, if for no other reaso= n but to reduce confusion when someone looks at this ten years from now.
Kyle

--001a113d3aac092b690537e8ee27-- From nobody Mon Jul 18 06:55:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0503212DFE0 for ; Mon, 18 Jul 2016 06:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ba0TZyNi1Dt for ; Mon, 18 Jul 2016 06:55:26 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727B812DAE9 for ; Mon, 18 Jul 2016 06:30:14 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 38so159347473iol.0 for ; Mon, 18 Jul 2016 06:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uvIXO5NwIpmVRzjK/2a4+BMY7ZmGc7xsfHnAAQxqEnE=; b=JqtPL5l0lNuyd4KX7UHQ/B6rGLiH/UPoP8p5ue7OkEbNh30W+IAIe+ZC0W74gyeOIF zkrteiKj73Z9ey0ewaC7ErWv/GmH80V00UKtjWQczwIHQvDCScefiw3jauitMuscgdOv jIDW0rGVHwtYqN5g5tbtNSP1g+ReHxAzoiGZE= 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; bh=uvIXO5NwIpmVRzjK/2a4+BMY7ZmGc7xsfHnAAQxqEnE=; b=TvFJJkRWBgY+vJr5KUuu4nljd64CCyQaN5YtnE6bl215Iuv4nPgA3oN8W9CVFhgU5P eHeFruVvAwhuQ6TU6EGhMwIjS3ibWoSbr+IdUNnjEmdKqyV48n08Js/yEozQPLxWjfnr 7V5WLcs+nS+Ky43WD3FwHTrAinG2yq4aCKyjCe3FpZj6m+ErJCHkDB8ve6s4m4u2Hkxy 0JPT0A3HReO8Rh63qhAsVrhyCEPS1KDkfk+VtcfiigTee0mPFRXoOjl89uTp+ZfT9KmB LgLpi75UcolDoUasytYaKgUtIfdIEgc5vmbFHkxE1n0gOWgMo3MxRI/z+HJDVMoCJlbd iOBQ== X-Gm-Message-State: ALyK8tLLPMduyaRuYci3lpHBOq6fnkuPdAkOjTNrPHtO6c7FvMWDJqv6YDpVpQ7xFim9ONYo57IZxvsiiZfdlW0T X-Received: by 10.107.128.25 with SMTP id b25mr36849220iod.110.1468848613571; Mon, 18 Jul 2016 06:30:13 -0700 (PDT) MIME-Version: 1.0 References: <20160718130843.0320d43f@pc1> In-Reply-To: <20160718130843.0320d43f@pc1> From: David Benjamin Date: Mon, 18 Jul 2016 13:30:04 +0000 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "" Content-Type: multipart/alternative; boundary=001a113fb596d79df70537e8f75b Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:55:31 -0000 --001a113fb596d79df70537e8f75b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If we keep trying to salvage the ClientHello version number, we will be chasing down intolerance forever. (And I'm honestly bored of doing that.) I'd prefer we move it to an extension. Either an empty indicator extension for each version or a single version extension with a list of versions. Or maybe fake cipher suites if people want it nearer the front. The important thing is lists can be actively defended. We simply burn a bunch of u16s and have clients advertise a few random fake ones in every ClientHello. (I'll be writing something up soon to request that range for extensions, cipher suites, and curves.) I expect this will make it much less likely anyone will accidentally ship a server that rejects unknown versions (or whatever else). On Mon, Jul 18, 2016 at 1:08 PM Hanno B=C3=B6ck wrote: > Hi, > > Recently both Adam Langley [1] and David Benjamin [2] indicated that > they expect with TLS 1.3 Browsers will have to bring back the infamous > version falbacks that caused so much trouble in the past (POODLE etc.) > to work around broken implementations of the TLS handshake. > > I don't blame browser vendors for this, I can understand their > reasoning why they think they have to do this, although I don't share > their opinion. But I think this sheds a light on the sorry state of TLS > implementations and I want to ask if there's a better way out of this. > > Let me quickly summarize how I see the situation: > * The issue has been known for a long time. I found a document from > Mozilla [3] from 2003 that describes the core issue. > * While there is a lot of scattered discussion about the issue, the > pure documentation status of this problem is far from ideal. I am not > aware of any good documentation that even describes how exactly > version intolerance happens. The "classic" variant seems to be > implementations that just close the connection if they are contacted > with a version number higher than what they support. But there are > also weirder variants where a connection attempt with TLS 1.2 will be > downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead > to an answer with TLS 1.0. (I have only seen this once. I'm guessing someone tried to write a filter which dispatched between two different backends and got it wrong.) > Questions I couldn't easily answer is how > connections are terminated (TCP disconnect? TLS alert? Timeouts?) > Connections can get shut off in all kinds of ways. It's buggy servers getting confused, so the space is pretty open-ended. Various flavors of TCP disconnects happen, as do alerts. (Not timeouts. Those we can't even address with a fallback.) > Also I'm not fully aware what the different version numbers > (ClientHelo + record version number) mean in context of a handshake > and how this influences version intolerance issues. > The record version number is meaningless in the protocol. It's frozen at TLS 1.0 for the ClientHello (and, in 1.3, for all records) and not relevant for version negotiation or fallbacks. (Note: at least a while ago SSL Labs' intolerance check incorrectly used the record-layer number. I don't know if this has been fixed. But apart from that bug, there is no relation between the two.) > * There don't seem to be any straightforward tools that test for > version intolerance. The SSL Labs test does detect version > intolerance, but it's limited to public facing https servers and it > doesn't seem to detect some of the weirder variations (as described > above). There's also a test in Hubert Kario's tlsfuzzer, but I've > been unable to get it to work. I tried to create a test myself, but > the results were highly erratic and I'm not sure why. > * We don't have good data on the issue. The latest numbers I could find > came from Ivan Ristic in 2013 [4], and from David Benjamin we know he > considers the problem to be large enough that version fallbacks are > inevitable. That's far from good data. We also don't seem to have any > public list of affected vendors, devices and webpages. > I have quite conclusive data. TLS 1.3 version intolerance is real. The version negotiation mechanism in draft-ietf-tls-tls13-14 will not be deployable on the web without a fallback. 2% is a very large number. I don't want to play the "davidben publicly shames such-and-such site or vendor" game, which is why I haven't been naming names and reaching out to people privately. If you prefer a more noisy approach, I didn't do anything complicated. Just send a 1.2 ClientHello and then swap the number for 1.3 to see if it stopped working. > I want to try to work on some of those issues in the near future. > Roughly I'd like to see that we work on a plan to reduce TLS brokenness > in general and in particular - right now as this is an issue affecting > the deployment of TLS 1.3 - Version intolerance. > > Things that I think we could and should do: > * Talk to developers of test tools (sslyze, testssl, openvas, but also > commercial tools etc.) that they include appropriate tests in their > tools and warn about these issues. Also it'd be great if e.g. things > like the google webmaster tools or any other public test tools for > webservers/websites could test for this. > Test suites are great, but I don't think we can rely on people to know to run them in every corner of the ecosystem. * Raise this issue with pentesters and tell them they should include > this when they're testing devices / products. (Of course this > requires to have test tools in the first place.) > * Get some data from internet wide scans and make it public. Maybe have > a public shame list of the top X pages breaking TLS. > * In general, more and better detailed documentation of this and > similar issues, also raise this as a potential research topic. > > My hope would be that we can avoid the reintroduction of version > fallbacks or at the very least reduce the amount of time they have to > be used. And hopefully at least avoid them altogether for TLS 1.4 or > whatever comes after 1.3. > The only way we're going to do that is by ditching the ClientHello.version field. > I'm in Berlin at IETF96 in case people want to discuss this. As this is > terribly late for this I don't know if this can be included in the TLS > WG discussion as it's probably already packed with other issues (but I'd > happily introduce the issue if people want to discuss it). > > > [1] https://www.imperialviolet.org/2016/05/16/agility.html > [2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html > [3] > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TL= S_-_SSL_3.0_Intolerant_Servers > [4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113fb596d79df70537e8f75b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we keep trying to salvage the ClientHello version numbe= r, we will be chasing down intolerance forever. (And I'm honestly bored= of doing that.) I'd prefer we move it = to an extension. Either an empty indicator extension for each version or a = single version extension with a list of versions. Or maybe fake cipher suit= es if people want it nearer the front.

The i= mportant thing is lists can be actively defended. We=C2=A0simply burn a bunch of u16s and have clients advertise a few= random fake ones in every ClientHello. (I'll be writing something up soon to request that range for extens= ions, cipher suites, and curves.) I expect this will make it much less like= ly anyone will accidentally ship a server that rejects unknown versions (or= whatever else).

On Mon, Jul 18, 2016 at 1:08 PM Hanno B=C3=B6ck <hanno@hboeck.de> wrote= :
Hi,

Recently both Adam Langley [1] and David Benjamin [2] indicated that
they expect with TLS 1.3 Browsers will have to bring back the infamous
version falbacks that caused so much trouble in the past (POODLE etc.)
to work around broken implementations of the TLS handshake.

I don't blame browser vendors for this, I can understand their
reasoning why they think they have to do this, although I don't share their opinion. But I think this sheds a light on the sorry state of TLS
implementations and I want to ask if there's a better way out of this.<= br>
Let me quickly summarize how I see the situation:
* The issue has been known for a long time. I found a document from
=C2=A0 Mozilla [3] from 2003 that describes the core issue.
* While there is a lot of scattered discussion about the issue, the
=C2=A0 pure documentation status of this problem is far from ideal. I am no= t
=C2=A0 aware of any good documentation that even describes how exactly
=C2=A0 version intolerance happens. The "classic" variant seems t= o be
=C2=A0 implementations that just close the connection if they are contacted=
=C2=A0 with a version number higher than what they support. But there are =C2=A0 also weirder variants where a connection attempt with TLS 1.2 will b= e
=C2=A0 downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead=
=C2=A0 to an answer with TLS 1.0.

(I hav= e only seen this once. I'm guessing someone tried to write a filter whi= ch dispatched between two different backends and got it wrong.)
=
=C2=A0
Questions I couldn't easil= y answer is how
=C2=A0 connections are terminated (TCP disconnect? TLS alert? Timeouts?)

=
Connections can get shut off in a= ll kinds of ways. It's buggy servers getting confused, so the space is = pretty open-ended. Various flavors of TCP disconnects happen, as do alerts.= (Not timeouts. Those we can't even address with a fallback.)
=C2=A0
=C2=A0 Also I'm not fully aware what the different version numbers
=C2=A0 (ClientHelo + record version number) mean in context of a handshake<= br> =C2=A0 and how this influences version intolerance issues.
=

The record version number is meaningless in the protocol. It's= frozen at TLS 1.0 for the ClientHello (and, in 1.3, for all records) and n= ot relevant for version negotiation or fallbacks.

(Note: at least a while ago S= SL Labs' intolerance check incorrectly used the record-layer number. I = don't know if this has been fixed. But apart from that bug, there is no= relation between the two.)
=C2=A0
* There don't seem to be any straightforward tools that test for
=C2=A0 version intolerance. The SSL Labs test does detect version
=C2=A0 intolerance, but it's limited to public facing https servers and= it
=C2=A0 doesn't seem to detect some of the weirder variations (as descri= bed
=C2=A0 above). There's also a test in Hubert Kario's tlsfuzzer, but= I've
=C2=A0 been unable to get it to work. I tried to create a test myself, but<= br> =C2=A0 the results were highly erratic and I'm not sure why.
* We don't have good data on the issue. The latest numbers I could find=
=C2=A0 came from Ivan Ristic in 2013 [4], and from David Benjamin we know h= e
=C2=A0 considers the problem to be large enough that version fallbacks are<= br> =C2=A0 inevitable. That's far from good data. We also don't seem to= have any
=C2=A0 public list of affected vendors, devices and webpages.

I have quite conclusive data. TLS 1.3 version int= olerance is real. The version negotiation mechanism in draft-ietf-tls-tls13= -14 will not be deployable on the web without a fallback. 2% is a very larg= e number.

I don't want to play the "david= ben publicly shames such-and-such site or vendor" game, which is why I= haven't been naming names and reaching out to people privately. If you= prefer a more noisy approach, I didn't do anything complicated. Just s= end a 1.2 ClientHello and then swap the number for 1.3 to see if it stopped= working.
=C2=A0
I want to try to work on some of those issues in the near future.
Roughly I'd like to see that we work on a plan to reduce TLS brokenness=
in general and in particular - right now as this is an issue affecting
the deployment of TLS 1.3 - Version intolerance.

Things that I think we could and should do:
* Talk to developers of test tools (sslyze, testssl, openvas, but also
=C2=A0 commercial tools etc.) that they include appropriate tests in their<= br> =C2=A0 tools and warn about these issues. Also it'd be great if e.g. th= ings
=C2=A0 like the google webmaster tools or any other public test tools for =C2=A0 webservers/websites could test for this.

Test suites are great, but I don't think we can rely on peo= ple to know to run them in every corner of the ecosystem.=C2=A0
=

* Raise this issue with pentesters and tell them they should include
=C2=A0 this when they're testing devices / products. (Of course this =C2=A0 requires to have test tools in the first place.)
* Get some data from internet wide scans and make it public. Maybe have
=C2=A0 a public shame list of the top X pages breaking TLS.
* In general, more and better detailed documentation of this and
=C2=A0 similar issues, also raise this as a potential research topic.

My hope would be that we can avoid the reintroduction of version
fallbacks or at the very least reduce the amount of time they have to
be used. And hopefully at least avoid them altogether for TLS 1.4 or
whatever comes after 1.3.

=
The only w= ay we're going to do that is by ditching the ClientHello.version field.=
=C2=A0
I'm in Berlin at IETF96 in case people want to discuss this. As this is=
terribly late for this I don't know if this can be included in the TLS<= br> WG discussion as it's probably already packed with other issues (but I&= #39;d
happily introduce the issue if people want to discuss it).


[1] https://www.imperialviolet.org/2016/05/16= /agility.html
[2] https://www.ietf.org/mail-archive= /web/tls/current/msg20207.html
[3]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_T= LS_-_SSL_3.0_Intolerant_Servers
[4] https://www.ietf.org/mail-archive= /web/tls/current/msg10657.html

--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hbo= eck.de
GPG: BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113fb596d79df70537e8f75b-- From nobody Mon Jul 18 07:39:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385A712DE02 for ; Mon, 18 Jul 2016 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7iJZRFNyd97 for ; Mon, 18 Jul 2016 07:39:15 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 2110C12DC58 for ; Mon, 18 Jul 2016 07:09:18 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id x130so240147291vkc.0 for ; Mon, 18 Jul 2016 07:09:18 -0700 (PDT) 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; bh=JbK7AovuTSC8QWO1n1ABoUQm19EcvbSnbMi3wY0idBY=; b=lZYomnj+5jrBboaBFKwquW/QdrCbZPNuwHolhdm+SyPOoj9isiu1pD1DJyWVobGHGn W7H2ff1WqofMTCXaSEnHs0UNAfoewG5CipdBrHgNtMZOT0HIH7AYPXGNTAqzquqOB7UG ooV5yb+c5GKutv0PPk1Oj26WJ9CyiG/4LkwGZ51ig5GX2SWtnOYpHFbYHZ0TCsS/bTxN b0Z8FRurE1iXUTxRmTWjXzmYIlbGgjq8kc88r5GqL1ypzFAfNCY1M1dqnJykqO78j9e9 //CPlqJ6wqJV2NU3S+Qtp9pbZxaHOTTcFN0sDQqui26ud8Cvy8OBxUWOufvmJ8enXQ9s 3nSA== 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; bh=JbK7AovuTSC8QWO1n1ABoUQm19EcvbSnbMi3wY0idBY=; b=GoVcTGLriMLupg9oV4rs8WmZWWYvnVjU5epEv/ePnWnWw4Dm57UBKz0PyF+Op2XAeo rNk6TgvixGY9nBrUW2TqDsEZ3nibWvNiUeB3kSHgtzzCGh6kjFoZf40II9vabfZNKZk5 GS32GrtL22ES87zHIul8OMxmJczouG6OQ8JrXmRHJ2kuRD4JIKD9K6OmLRHlmaXSA+up kQtXMklL6bMl9iZX49gXH2J6Q4eI1+/ZEkXBz5aKH+j5tVmZwdjGh0GJqpc4U6T2ghII dkoyvULYJp9to8+gRrQn8Qakvnk/RKCk03Wezi41IO2kNxlMfgtBgC5MOQlXCIbmviiK Scuw== X-Gm-Message-State: ALyK8tIL2DTDMCR2tSbO7thTeGr4lsljfMxc7SX3hyCqVX7aoSzmLtnmh3TCAvA36fk+56V2rape3PyUAXyucg== X-Received: by 10.31.93.129 with SMTP id r123mr16999810vkb.149.1468850957200; Mon, 18 Jul 2016 07:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Mon, 18 Jul 2016 07:09:16 -0700 (PDT) In-Reply-To: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> References: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> From: Watson Ladd Date: Mon, 18 Jul 2016 07:09:16 -0700 Message-ID: To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:39:17 -0000 On Mon, Jul 18, 2016 at 3:06 AM, Dan Harkins wrote: > > Hi Robert, > > This draft moves the NamedCurve/EllipticCurveList into the > ClientHello, and since the client sends X1 and ZKP(X1) in the > ClientHello it means that is going to be a list of 1. It basically > moves the client's key exchange portion from ClientKeyExchange into > ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE > then that's the only thing it can offer and the parameters of > that exchange are all selected by the client, not the server. > > This is a fundamental change to TLS. If it's going to be offered, > it's the only thing that can be offered and therefore the only thing > that can be used. Seems like for a deployment either it's never used > or it's the only thing used and that makes it sort of a proprietary > protocol, not TLS. This stems from the multiple rounds used in JPAKE. SPAKE2 uses only 2 rounds, and would be easier to put into TLS. I'm still working on the draft, but haven't gotten to it in a while. Sincerely, Watson > > Dan. > > On Thu, June 16, 2016 2:51 am, Robert Cragie wrote: >> I would like to ask the working group for comments on the TLS-ECJ-PAKE >> draft: >> >> https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 >> >> Some brief notes: >> >> * This intended status is informational. >> * The draft is based on TLS/DTLS 1.2 as the Thread group required basis on >> existing RFCs wherever possible. For that reason and due to the WGs focus >> on TLS 1.3, I have understood from the chairs that it would not have >> received a great deal of attention from the WG, hence the intended status >> of informational. >> * The draft reflects the current use of the TLS_ECJPAKE_WITH_AES_128_CCM_8 >> cipher suite in Thread (http://threadgroup.org/). >> * There is an experimental implementation in mbed TLS ( >> https://github.com/ARMmbed/mbedtls) >> * The Thread group would like to get IANA assignments for 4 cipher suite >> values and one ExtensionType value as soon as possible. >> * There are at least four independent implementations, which have been >> used >> in interop. testing over the last 18 months. >> * The security considerations recommend restriction of the use of this >> cipher suite to Thread and similar applications and recommends it should >> not be used with web browsers and servers (mainly due to the long >> discussions regarding the use of PAKEs on this and other mailing lists). >> >> Robert >> _______________________________________________ >> 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 -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Jul 18 08:25:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31212DC59 for ; Mon, 18 Jul 2016 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUXAi-ShXG-c for ; Mon, 18 Jul 2016 08:25:51 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AA0D012DA7C for ; Mon, 18 Jul 2016 08:07:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id EFA054CE3; Mon, 18 Jul 2016 18:07:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id RLeij_TO7eLh; Mon, 18 Jul 2016 18:07:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 72740C4; Mon, 18 Jul 2016 18:07:54 +0300 (EEST) Date: Mon, 18 Jul 2016 18:07:50 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160718150750.GA13139@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:25:54 -0000 On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote: > On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote: > > > There have been a lot of discussions about whether we should try to > > refactor cipher-suite negotiation to be less monolithic in the cipher > > suite. I've generally been on the "no" side of that on cost/benefit > > grounds as well as not quite seeing how it would fit into the rest > > of the infrastructure. However, now that we're starting to get full > > implementations, and it's becoming clearer how the new elements > > (principally PSK-resumption and key_shares) interact with cipher > > suites, I've started to think that in fact we may be able to clean > > things up. One proposal for this is below [0]. I know this is > > pretty late in the process, but if we do want this change it's > > better to do it now. > > > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > > fire away. > > > > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > > mostly orthogonal axes. > > > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > > - Authentication -- indicated the signature_algorithms and pre_shared_key > > extensions > > > > Tl;dr: I think this is a good approach because it eliminates much of the > existing negotiation redundancy/complexity and combinatorial explosion in > the 1.3+ ciphersuite menu. I recently tried to write code to handle this ciphersuite negotiation, so that it always negotiates a valid choice if any valid choice exists. I think the end result was insane. The problem that makes it so difficult is that legacy signature types, group types and protection/PRFs interact, so not all supported offers that server has enabled are actually possible to chose. > The longer version: the argument I made in Prague (though IIRC not very > clearly) was that while it would be nice to limit the ciphersuite options > to agreed-upon "good" combinations based on some sane notion of > forward-looking security margin (notwithstanding the practical inability to > see the future), the reality on the ground is that authentication is based > on something pre-existing---the server has one or two long-term keys of a > fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on > demand---so it really only makes sense for the client to indicate what it > supports and to deal with whatever the server chooses to send it on that > basis. So I'd argue that this one is orthogonal based on that constraint, > and so it should be negotiated separately. If you are talking about "strength-matching", there is no sane notion of security equivalence with protection, key exchange and signatures (due to different sub-threshold, multi-key and period properties). And coupling those in a way that doesn't lead to great difficulty (even greater than currently) REALLY causes the ciphersuite space to combinatorially explode. > AEAD and PRF OTOH don't come with built-in keys, so they can always be > chosen as a pair as a function of the desired security margin. Except in some situations (e.g. 64-bit systems with hardware AES and CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384. The "match security" is IMO about not having the weakest algorithm not being too weak, or "paying too much" for algorithm that is much above anything else. But what it doesn't consider is what if the stronger algorithm is actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384. Or if on 32-bit hardware where you don't have hw AES? Then X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256 if you don't have Ed25519), nevermind that it has "256-bit" symmetric cipher, but everything else at "128-bit" level... > Key agreement is not clearly in either category: when it's PSK, it's based > on what you have, so it's similar to authentication; but when it's (EC)DHE, > it's not, and so ideally you'd like the chosen group to be tied to the > AEAD/PRF security margin. But, since the client has to offer specific > groups rather than specifying general support for ECDHE or EdDHE, both > because ideally we want the client key share sent in the first flight and > because unlike RSA or FFDHE a client can't generalize to key sizes it > hasn't seen before, it actually still shares a lot in common with the auth > case of being sort-of something you have rather than something you can > choose on the fly. So I'm also in agreement that this is mostly orthogonal > and should be negotiated separately. "Security matching" between groups and symmetric ciphers is already highly problematic, and depends on all sorts of assumptions (and is generally biased towards symmetric ciphers being less secure than they seem). Sure, the server might bias choices, but actually enforcing anything here is IMO unwise. > So now you have several grab bags and need to choose one from each. Is it > necessary to tie the various bits together by security margin? Not clear. > It's probably fine to assume a client isn't going to announce support for > anything it doesn't think is secure enough, so the only practical downside > to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary > additional CPU consumption of AES-256/SHA-384. The client was willing to > accept P-256 server authentication, so presumably it's happy with that > security margin; and anyway, the server could prefer ciphersuites and ECDHE > groups that better match the available auth credentials. IMO, no it is not necressary to tie the security margins. In case of authentication and encryption, there is also the issue that authentication is good if it is unbroken at that moment, whereas key exchange and encryption must remain unbroken for long time since. So that someone thinks ECDSA P-256 is OK for authentication does not mean that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think that 128-bit symmetric encryption is OK. > Or maybe prospective security margin is too complex and/or too ill-defined > to bother with, and a server should just choose the least CPU-intensive > combination of everything. Well, yeah, it is ill-defined. Of course, there can be bad algorithms that one wants to disable. However, interactions between bad algorithms are much less likely than actual bad algorithms causing problems by themselves. -Ilari From nobody Mon Jul 18 08:51:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100512D0E8 for ; Mon, 18 Jul 2016 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df5wiiD35rOU for ; Mon, 18 Jul 2016 08:51:19 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D1112D08E for ; Mon, 18 Jul 2016 08:51:17 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id p74so160848061qka.0 for ; Mon, 18 Jul 2016 08:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wXTHet+wJXVdeOkbpk0tOB/8w4TPlPWyEFbtSc4JrTs=; b=rRg2HQIIM7ia/cU8iWRJK9fG6yJ9znhg5TjUb+MyfRFUGpxzQNM6et9MqewjrXL7fl hFws9vcS9QsSOjHLvPbQbqLzSK+5DnRr1yx5zeju76I6zWushqMyZFnUhYbc5D7H7Oyz FA8XprHQzG6TI4QZ0y/bOzghh2Fns+u7zz0CE= 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; bh=wXTHet+wJXVdeOkbpk0tOB/8w4TPlPWyEFbtSc4JrTs=; b=hkdpZqC2ICJi2LtqCdZUOT4ggwJpKnJn89sMGq5mSqT+yCJrhx0nIpRzNh3h3ubSEJ SPIuXsncLkomPO+6KcV3Nk7EWhBmu2xzsZmnXN4emf/UtcuAH8NauEDBjQACqWgtHfSC EZgJW3dJXGjRZgFm+j3YT9eGYb5954Xtsy6Yk8KjV8TxqeOp+QxyvQfdxAAUVyxlmKYM PtaorcNpMNqYMMhOzCHC6h+AOlr/efOSZdeX2YtWSownI4ImYUajfnCT0etRHkVkEoqR BUR1fMyB//h7Dbb6eJJcIM89JkeaQ/33k3xDeDJbBSV6uffHYhDaTGTjFjIoBFI9OrW0 hzcQ== X-Gm-Message-State: ALyK8tIYCCypAu/2/JhtQicopOvDMfO6KwbgVBa5s6LiRiOBIS1aOqSZwOp7YjaW5l6mGVLqjJN2uT6V5XX2bQ== X-Received: by 10.55.137.70 with SMTP id l67mr45489163qkd.17.1468857076708; Mon, 18 Jul 2016 08:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.118.135 with HTTP; Mon, 18 Jul 2016 08:51:15 -0700 (PDT) X-Originating-IP: [31.133.178.3] In-Reply-To: <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Mon, 18 Jul 2016 17:51:15 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0731e6490afb0537eaf0a3 Archived-At: Cc: "" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:51:21 -0000 --94eb2c0731e6490afb0537eaf0a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara wrote: > > Tl;dr: I think this is a good approach because it eliminates much of th= e > > existing negotiation redundancy/complexity and combinatorial explosion = in > > the 1.3+ ciphersuite menu. > > I recently tried to write code to handle this ciphersuite negotiation, so > that it always negotiates a valid choice if any valid choice exists. > > I think the end result was insane. The problem that makes it so difficult > is that legacy signature types, group types and protection/PRFs interact, > so not all supported offers that server has enabled are actually possible > to chose. > It may also be that combinatorial explosion in ciphersuites just isn't a problem in reality: that there should be so few choices offered in the standard, with those believed to be secure, and new ones introduced only when they are actually needed, not simply when there is something shiny and new. > If you are talking about "strength-matching", there is no sane notion of > security equivalence with protection, key exchange and signatures (due to > different sub-threshold, multi-key and period properties). > .... > IMO, no it is not necressary to tie the security margins. In case of > authentication and encryption, there is also the issue that authenticatio= n > is good if it is unbroken at that moment, whereas key exchange and > encryption > must remain unbroken for long time since. > > So that someone thinks ECDSA P-256 is OK for authentication does not mean > that the same entity thinks ECDHE P-256 is OK for key exchange. Or to thi= nk > that 128-bit symmetric encryption is OK. > Yeah, this is a really good point. This argues for a complete separation of authentication (over which the client has no control) from the rest of the security parameters. In some sense, the KX and symmetric cipher are still tied together as a break in either in the future will reveal confidential data, but I'll concede the point that there is no sane way to tie security margins between KX and cipher suite. > And coupling those in a way that doesn't lead to great difficulty (even > greater than currently) REALLY causes the ciphersuite space to > combinatorially explode. > The combinatorial explosion I was referring to was that of consuming code points for multiple combinations of things that have a separate negotiation mechanism (e.g., SignatureAlgorithms). But maybe it's not a problem in practice. > Or maybe prospective security margin is too complex and/or too ill-define= d > > to bother with, and a server should just choose the least CPU-intensive > > combination of everything. > > Well, yeah, it is ill-defined. Of course, there can be bad algorithms > that one wants to disable. > > However, interactions between bad algorithms are much less likely than > actual bad algorithms causing problems by themselves. > I'm more concerned about the a la carte approach admitting bad ciphers or PRFs that then get implemented na=C3=AFvely by completists, but I suppose t= hat problem still exists when they are tied together. And maybe this won't be a problem in practice in the presence of a "recommended" column in the registry. Kyle --94eb2c0731e6490afb0537eaf0a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <= ilariliusvaara@welho.com> wrote:
> Tl;dr: I think this is a good approach because it= eliminates much of the
> existing negotiation redundancy/complexity and combinatorial explosion= in
> the 1.3+ ciphersuite menu.

I recently tried to write code to handle this ciphersuite negotiatio= n, so
that it always negotiates a valid choice if any valid choice exists.

I think the end result was insane. The problem that makes it so difficult is that legacy signature types, group types and protection/PRFs interact, so not all supported offers that server has enabled are actually possible to chose.

It may also be that combinato= rial explosion in ciphersuites just isn't a problem in reality: that th= ere should be so few choices offered in the standard, with those believed t= o be secure, and new ones introduced only when they are actually needed, no= t simply when there is something shiny and new.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> If you are talking about "strength-matching", there is no sane no= tion of
security equivalence with protection, key exchange and signatures (due to different sub-threshold, multi-key and period properties).
....
IMO, = no it is not necressary to tie the security margins. In case of
authentication and encryption, there is also the issue that authentication<= br> is good if it is unbroken at that moment, whereas key exchange and encrypti= on
must remain unbroken for long time since.

So that someone thinks ECDSA P-256 is OK for authentication does not mean that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think=
that 128-bit symmetric encryption is OK.

Yeah, this is a really good point. This argues for a complete separation = of authentication (over which the client has no control) from the rest of t= he security parameters. In some sense, the KX and symmetric cipher are stil= l tied together as a break in either in the future will reveal confidential= data, but I'll concede the point that there is no sane way to tie secu= rity margins between KX and cipher suite.
=C2=A0
And coupling those in a way that doesn't lead to great difficulty (even=
greater than currently) REALLY causes the ciphersuite space to
combinatorially explode.

The combinator= ial explosion I was referring to was that of consuming code points for mult= iple combinations of things that have a separate negotiation mechanism (e.g= ., SignatureAlgorithms). But maybe it's not a problem in practice.
<= /div>
> Or maybe prospective security margin is too co= mplex and/or too ill-defined
> to bother with, and a server should just choose the least CPU-intensiv= e
> combination of everything.

Well, yeah, it is ill-defined. Of course, there can be bad algorithm= s
that one wants to disable.

However, interactions between bad algorithms are much less likely than
actual bad algorithms causing problems by themselves.
= =C2=A0
I'm more concerned about the a la carte approach a= dmitting bad ciphers or PRFs that then get implemented na=C3=AFvely by comp= letists, but I suppose that problem still exists when they are tied togethe= r. And maybe this won't be a problem in practice in the presence of a &= quot;recommended" column in the registry.

Kyle
--94eb2c0731e6490afb0537eaf0a3-- From nobody Mon Jul 18 08:56:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7996112DA15 for ; Mon, 18 Jul 2016 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-AT52BZQEyR for ; Mon, 18 Jul 2016 08:56:35 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 71ECD12DA19 for ; Mon, 18 Jul 2016 08:56:31 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i12so162549965ywa.1 for ; Mon, 18 Jul 2016 08:56:31 -0700 (PDT) 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:cc; bh=+2ZdVcGGdeiJWhmcqDXWj4uxEcZufNwNqsGxOBUi1EE=; b=JxgrgQna8CPfnqU67mGwMMMViiq9M+lrpy6xhCKSoRfVtYy0ZDwWdA5TQfcPBw9AkD bu2+Gq1rdVJUTnBxcOGYaMNVB4zX8/kiS+1WO5xKrZQZ3IGgd1yPD0k416AFVvkJ47WJ 03s1LavKu9L0GCN4VpIHWXYhNpw62ROYGrcVT6HP/Yy2hvxeCGIObJCMnMFwbFK1/bUI RQNh2n6Q3/crSFmBQgP/VXNJuDUSHVdaN9/obRE5rcFLKaM+qdIC2XEskPXM2FzXMmQX ec8j5shbkpPAY9qbAKBlrmh1PHAZ0UEBDCzqt+3211rBd53xME66+Mme+uwyu9aZRJig eVZg== 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:cc; bh=+2ZdVcGGdeiJWhmcqDXWj4uxEcZufNwNqsGxOBUi1EE=; b=ZGNSbsT3p5NUE64CyPhBcKbtRIgFhS/z/cdKIAWwNxMHhv9LtOjntjSPec+y9jKoRC iKTGtbdYri4POjy4MqVY1f0ws9K+WJ6S5jg8e+oFep2BlSnf9CezoPrap9meJiVfDeAC LBG0FS2XfFoIOlM6gqXLb1UbhRKc2qO+/7VrnHO5ScPXdKbTHT6p27nC5oyiMteUYXfQ d1jwHqqEGr+cfmp2fIxVUDXNvw8DbkEOxhiy7Zy4nw6sijcTvG1/zctUL5Ub9BBiG37k bWFHmZn6Y3ZeWSpi1gjc+sDBmbVHKmelFIdU5fp7X60wJVMsWHiXYY+9ffQZFPqZC4lz 4l2Q== X-Gm-Message-State: ALyK8tLorm9ObEkf7AXF9KqLi+Xe0RAiSBakR7lsV1Dka3KDq1J+rTs3hciq4NML9mrBXmg8LlMfApmGDcgmNQ== X-Received: by 10.129.135.5 with SMTP id x5mr24867108ywf.114.1468857390498; Mon, 18 Jul 2016 08:56:30 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.64.82 with HTTP; Mon, 18 Jul 2016 08:56:00 -0700 (PDT) In-Reply-To: References: <201607062024.46745.davemgarrett@gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> From: Hugo Krawczyk Date: Mon, 18 Jul 2016 11:56:00 -0400 X-Google-Sender-Auth: tLA_mcWTqlIU7ca1bH24ijTs4jI Message-ID: Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114f11c6fcb9980537eb0257 Archived-At: Subject: Re: [TLS] judging consensus on keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:56:37 -0000 --001a114f11c6fcb9980537eb0257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk wrote: > I do not have an objection to option 1 if re-phrased as > Option 1 - use the same key for protecting both *post*-handshake and > applications messages.. > > I believe this is what was intended by that option anyway. Let me clarify= . > > I understand the question as relating *only* to post-handshake messages > and not > to the main handshake (three initial flights). For the latter we have key > separation in the sense that none of these main-handshake messages is > encrypted > under the application key but rather under dedicated handshake keys. This > should > not be changed as it provides key indistinguishability to the application > key, a > desirable design and analysis (=3Dproof) modularity property. > > On the other hand, for post-handshake messages, and particularly for > encrypting > post-handshake client authentication messages, preserving key > indistinguishability is not relevant since at the time of post-handshake > client authentication, the application key has already lost its > indistinguishability > by the mere fact that the key was used to encrypt application data. Key > indistinguishability is the main reason to insist in key separation and > this > principle does not apply here anymore hence removing the objection to 1. > > I'd note that the best one could hope for in the post-handshake setting i= s > that > as a result of post-handshake client authentication the application key > becomes > a secure mutually-authenticated key for providing "secure channels" > security. > As pointed out by others in previous posts I have an analysis showing tha= t > this > delayed mutual authentication guarantee is achieved even if one uses the > application key to encrypt the post-handshake messages. I have circulated= a > preliminary version of the paper among cryptographers working on TLS 1.3 > and I will post a public copy next week so this can be scrutinized > further. > =E2=80=8BHere is the promised posted paper http://eprint.iacr.org/2016/711 " A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3) =E2=80=8B"=E2=80=8B Its analysis of client authentication is relevant to the different modes of TLS 1.3 and, in particular, to post-handshake authentication. As said above, the results support the use of the application key to encrypt the post-handshake messages, hence avoiding the need to use a dedicated key for this and the consequent need for trial decryption (or related techniques). Comments on and off list are welcome. Hugo =E2=80=8B > > Hugo > > > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > >> If we are left with 1 or 3, the miTLS team would prefer 1. >> >> On the cryptographic side, Hugo has a recent (draft) paper that seems to >> provide >> some more justification for (1), at least for client authentication. >> >> I know this is a bit off-topic, but the miTLS team would also like to ge= t >> rid of 0-RTT ClientFinished >> if that is the only message left in the 0-RTT encrypted handshake flight= . >> That should remove >> another Handshake/Data key separation from the protocol, leaving only 3 >> keys: 0-RTT data, >> 1-RTT handshake, and 1-RTT data. >> >> Best, >> -Karthik >> >> >> On 07 Jul 2016, at 02:49, David Benjamin wrote: >> >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote: >> >>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett >>> wrote: >>> >>>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >>>> > I'm also curious which post-handshake messages are the problem. If w= e >>>> were >>>> > to rename "post-handshake handshake messages" to "post-handshake bon= us >>>> > messages" with a distinct bonus_message record type, where would the= re >>>> > still be an issue? (Alerts and application data share keys and this >>>> seems >>>> > to have been fine.) >>>> >>>> Recasting all the post-handshake handshake messages as not something >>>> named "handshake" does make a degree of sense, on its own. (bikesheddi= ng: >>>> I'd name it something more descriptive like "secondary negotiation" >>>> messages or something, though.) Even if this doesn't directly help wit= h the >>>> issue at hand here, does forking these into a new ContentType sound li= ke a >>>> useful move, in general? >>> >>> >>> I'm not sure what this would accomplish. >>> >> >> Me neither. To clarify, I mention this not as a suggestion, but to >> motivate asking about the type of message. If the only reason the proofs >> want them in the handshake bucket rather than the application data bucke= t >> is that they say "handshake" in them then, sure, let's do an >> inconsequential re-spelling and move on from this problem. >> >> But presumably something about the messages motivate this key separation >> issue and I'd like to know what they are. >> >> David >> _______________________________________________ >> 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 >> >> > --001a114f11c6fcb9980537eb0257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk <h= ugo@ee.technion.ac.il> wrote:
I do not have an objecti= on to option 1 if re-phrased as=C2=A0
Option 1 - use the same key for protecting both *post*-handsha= ke and applications messages..=C2= =A0

I believe this is what was intended b= y that option anyway.=C2=A0Let me clarify.

I = understand the question as relating *only* to post-handshake messages and n= ot
to the main handshak= e (three initial flights). For the latter we have key
separation in the sense that none of these m= ain-handshake messages is encrypted
under the application key but rather under dedicated handshake= keys. This should
not be changed as it provides key indistinguishability to the applicatio= n key, a
desirable desi= gn and analysis (=3Dproof) modularity property.

On the other hand, for post-handshake messages, and particularly for= encrypting
post-handsh= ake client authentication messages, preserving key
indistinguishability is not relevant since at t= he time of post-handshake
client authentication, the application key has already lost its indistin= guishability
by the mer= e fact that the key was used to encrypt application data. Key
<= span class=3D"">
indistinguishabilit= y is the main reason to insist in key separation and this
principle does not apply here any= more hence removing the objection to 1.

I= 'd note that the best one could hope for in the post-handshake setting = is that
a secure mutuall= y-authenticated key for providing "secure channels" security.
As pointed out by others i= n previous posts I have an analysis showing that this
delayed mutual authentication guarantee is a= chieved even if one uses the
application key to encrypt the post-handshake messages. I have circul= ated a
prelimina= ry version of the =C2=A0paper among cryptographers working on TLS 1.3=C2=A0=
and = =C2=A0I will post a p= ublic copy next week so this can be scrutinized further.

=E2= =80=8BHere is the promised posted paper=C2=A0
"
A Unilateral-to-Mutual Authentication Compiler for Key Exchange= (with Applications to Client Authentication in TLS 1.3)
=E2=80=8B"=E2=80=8B

Its analysis of client= authentication is relevant to the different modes of TLS 1.3 and, in parti= cular, to post-handshake authentication. As said above, the results support= the use of the application key to encrypt the post-handshake messages, hen= ce avoiding the need to use a dedicated key for this and the consequent nee= d for trial decryption (or related techniques).

Comments on = and off list are welcome.

Hugo
=E2=80=8B
=C2=A0
Hugo

<= /div>

On Thu, Jul 7, 2016 at 1:10 AM, Ka= rthikeyan Bhargavan <karthik.bhargavan@gmail.com> = wrote:
If we are le= ft with 1 or 3, the miTLS team would prefer 1.

On the cr= yptographic side, Hugo has a recent (draft) paper that seems to provide
some more justification for (1), at least for client authentication.= =C2=A0

I know this is a bit off-topic, but the miTLS tea= m would also like to get rid of 0-RTT ClientFinished=C2=A0
if tha= t is the only message left in the 0-RTT encrypted handshake flight. That sh= ould remove
another Handshake/Data key separation from the protoc= ol, leaving only 3 keys: 0-RTT data,
1-RTT handshake, and 1-RTT d= ata.=C2=A0

Best,
-Karthik


On 0= 7 Jul 2016, at 02:49, David Benjamin <davidben@chromium.org> wrote:

On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <= davemgarrett@gm= ail.com> wrote:
On Wednesday, July = 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If= we were
> to rename "post-handshake handshake messages" to "post-= handshake bonus
> messages" with a distinct bonus_message record type, where would = there
> still be an issue? (Alerts and application data share keys and this se= ems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something= named "handshake" does make a degree of sense, on its own. (bike= shedding: I'd name it something more descriptive like "secondary n= egotiation" messages or something, though.) Even if this doesn't d= irectly help with the issue at hand here, does forking these into a new Con= tentType sound like a useful move, in general?

<= /div>
I'm not sure what this would accomplish.
<= /div>

Me neither. To clarify, I mention this = not as a suggestion, but to motivate asking about the type of message. If t= he only reason the proofs want them in the handshake bucket rather than the= application data bucket is that they say "handshake" in them the= n, sure, let's do an inconsequential re-spelling and move on from this = problem.

But presumably something about the messag= es motivate this key separation issue and I'd like to know what they ar= e.

David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

=

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



--001a114f11c6fcb9980537eb0257-- From nobody Mon Jul 18 09:03:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969AB12DA4F for ; Mon, 18 Jul 2016 09:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSC81nU-z4rg for ; Mon, 18 Jul 2016 09:03:49 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40D312B00B for ; Mon, 18 Jul 2016 09:03:48 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id i12so162762747ywa.1 for ; Mon, 18 Jul 2016 09:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EeJFXHljhpMZkhCcd5qY0RagN54119xdELIML8aL8Lk=; b=PICaCVbSxQdVBlJwGsaxaH3GAuShkAPYsLnn9D5FAIGJxR7qOCqZrD4gZwlfQxD+xk v+OvEBDJVMj++8Wz6LVOH3JWMt2azY00BZm7zWB2/igpdCweMbg6oydsrcH26cDO+bIr /O1R6I2vCDcaYcd41C46eJO1g28CvkCwhIGfIkOroV9HEi2TwY3rV29cegu51o4t54Fy qPoFoUySzO/LeSLt+kD4FC4UGszEdUtbL9hcIl37amCda9r1wtENQYRHtKVbwezwanei 9r1K9VR6oHwgS7guv8rR71f0ks+3rhKyHJRcmkBwBlCfDzI12xS8uc9b0B+lI7HY9y65 vAgQ== 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; bh=EeJFXHljhpMZkhCcd5qY0RagN54119xdELIML8aL8Lk=; b=bY9RyfQc8sVoAVVf2ytgkNfeOWXKKcJwFzOsYgjbRRnR45XVYP5Ixyfpa2810fYB9z 7Fa4ZdXzx20LvL0LeVzvS0dg5fqc+5YYrZaTG5z5giavBKHfsSjKhZr7ChVZ2N3aGytP yuiKWAy0caNiBr9z5QHBFDYSuoiYi9dsTI1CMJvkBp8/k9z2PyTUn5+Fmu+H2IWO56Yd ZzD5C4JYeuIMnLuBotl8YR6vX6TBg26TKy1Ox88Gui6yd9RcJsMAxr59BnfZ+OzXCWxy jw2BrffSZeKcSKF9KQFoKp52Sh2+wpGdtMqGPTJHlO0RuPl/T2j0epupMzkPHK2NL3Pn cP3g== X-Gm-Message-State: ALyK8tIlDoiG3/dyPfihRdMJStCFb/fWdzYQ7Zj73/NZ60opST7LsA717Xa1a3ODDYJWo8cEzxN4+4T8bwkHbg== X-Received: by 10.129.161.129 with SMTP id y123mr26476061ywg.214.1468857828164; Mon, 18 Jul 2016 09:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 18 Jul 2016 09:03:08 -0700 (PDT) In-Reply-To: <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 18 Jul 2016 18:03:08 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114f8db21314ff0537eb1d32 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:03:52 -0000 --001a114f8db21314ff0537eb1d32 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara wrote: > On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote: > > On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote: > > > > > There have been a lot of discussions about whether we should try to > > > refactor cipher-suite negotiation to be less monolithic in the cipher > > > suite. I've generally been on the "no" side of that on cost/benefit > > > grounds as well as not quite seeing how it would fit into the rest > > > of the infrastructure. However, now that we're starting to get full > > > implementations, and it's becoming clearer how the new elements > > > (principally PSK-resumption and key_shares) interact with cipher > > > suites, I've started to think that in fact we may be able to clean > > > things up. One proposal for this is below [0]. I know this is > > > pretty late in the process, but if we do want this change it's > > > better to do it now. > > > > > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > > > fire away. > > > > > > > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > > > mostly orthogonal axes. > > > > > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in > TLS 1.2 > > > - Key exchange -- indicated by the key_shares and pre_shared_key > extensions > > > - Authentication -- indicated the signature_algorithms and > pre_shared_key > > > extensions > > > > > > > Tl;dr: I think this is a good approach because it eliminates much of the > > existing negotiation redundancy/complexity and combinatorial explosion in > > the 1.3+ ciphersuite menu. > > I recently tried to write code to handle this ciphersuite negotiation, so > that it always negotiates a valid choice if any valid choice exists. > > I think the end result was insane. The problem that makes it so difficult > is that legacy signature types, group types and protection/PRFs interact, > so not all supported offers that server has enabled are actually possible > to chose. > Can you say more about this? I spent some time mocking up an implementation locally and it was pretty clean. Perhaps what made it easier is that I did: 1. Define new cipher suites that were totally agnostic about the key exchange and signature. 2. Assume everything was orthogonal except for the PSK/signature/key exchange interaction... -Ekr -Ekr > > > The longer version: the argument I made in Prague (though IIRC not very > > clearly) was that while it would be nice to limit the ciphersuite options > > to agreed-upon "good" combinations based on some sane notion of > > forward-looking security margin (notwithstanding the practical inability > to > > see the future), the reality on the ground is that authentication is > based > > on something pre-existing---the server has one or two long-term keys of a > > fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on > > demand---so it really only makes sense for the client to indicate what it > > supports and to deal with whatever the server chooses to send it on that > > basis. So I'd argue that this one is orthogonal based on that constraint, > > and so it should be negotiated separately. > > If you are talking about "strength-matching", there is no sane notion of > security equivalence with protection, key exchange and signatures (due to > different sub-threshold, multi-key and period properties). > > And coupling those in a way that doesn't lead to great difficulty (even > greater than currently) REALLY causes the ciphersuite space to > combinatorially explode. > > > AEAD and PRF OTOH don't come with built-in keys, so they can always be > > chosen as a pair as a function of the desired security margin. > > Except in some situations (e.g. 64-bit systems with hardware AES and > CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384. > > The "match security" is IMO about not having the weakest algorithm not > being too weak, or "paying too much" for algorithm that is much above > anything else. > > But what it doesn't consider is what if the stronger algorithm is > actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384. > > Or if on 32-bit hardware where you don't have hw AES? Then > X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256 > if you don't have Ed25519), nevermind that it has "256-bit" symmetric > cipher, > but everything else at "128-bit" level... > > > Key agreement is not clearly in either category: when it's PSK, it's > based > > on what you have, so it's similar to authentication; but when it's > (EC)DHE, > > it's not, and so ideally you'd like the chosen group to be tied to the > > AEAD/PRF security margin. But, since the client has to offer specific > > groups rather than specifying general support for ECDHE or EdDHE, both > > because ideally we want the client key share sent in the first flight and > > because unlike RSA or FFDHE a client can't generalize to key sizes it > > hasn't seen before, it actually still shares a lot in common with the > auth > > case of being sort-of something you have rather than something you can > > choose on the fly. So I'm also in agreement that this is mostly > orthogonal > > and should be negotiated separately. > > "Security matching" between groups and symmetric ciphers is already highly > problematic, and depends on all sorts of assumptions (and is generally > biased towards symmetric ciphers being less secure than they seem). > > Sure, the server might bias choices, but actually enforcing anything here > is IMO unwise. > > > So now you have several grab bags and need to choose one from each. Is it > > necessary to tie the various bits together by security margin? Not clear. > > It's probably fine to assume a client isn't going to announce support for > > anything it doesn't think is secure enough, so the only practical > downside > > to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary > > additional CPU consumption of AES-256/SHA-384. The client was willing to > > accept P-256 server authentication, so presumably it's happy with that > > security margin; and anyway, the server could prefer ciphersuites and > ECDHE > > groups that better match the available auth credentials. > > IMO, no it is not necressary to tie the security margins. In case of > authentication and encryption, there is also the issue that authentication > is good if it is unbroken at that moment, whereas key exchange and > encryption > must remain unbroken for long time since. > > So that someone thinks ECDSA P-256 is OK for authentication does not mean > that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think > that 128-bit symmetric encryption is OK. > > > Or maybe prospective security margin is too complex and/or too > ill-defined > > to bother with, and a server should just choose the least CPU-intensive > > combination of everything. > > Well, yeah, it is ill-defined. Of course, there can be bad algorithms > that one wants to disable. > > However, interactions between bad algorithms are much less likely than > actual bad algorithms causing problems by themselves. > > > -Ilari > --001a114f8db21314ff0537eb1d32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote:
> On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > There have been a lot of discussions about whether we should try = to
> > refactor cipher-suite negotiation to be less monolithic in the ci= pher
> > suite. I've generally been on the "no" side of that= on cost/benefit
> > grounds as well as not quite seeing how it would fit into the res= t
> > of the infrastructure. However, now that we're starting to ge= t full
> > implementations, and it's becoming clearer how the new elemen= ts
> > (principally PSK-resumption and key_shares) interact with cipher<= br> > > suites, I've started to think that in fact we may be able to = clean
> > things up. One proposal for this is below [0]. I know this is
> > pretty late in the process, but if we do want this change it'= s
> > better to do it now.
> >
> > I'm sure we'll need to discuss this in Berlin, but in the= meantime,
> > fire away.
> >
> >
> > The basic idea here is to factor out the TLS 1.3 negotiation into= three
> > mostly orthogonal axes.
> >
> > - Symmetric cipher/PRF=C2=A0 -- indicated by the cipher suite lis= t as in TLS 1.2
> > - Key exchange -- indicated by the key_shares and pre_shared_key = extensions
> > - Authentication -- indicated the signature_algorithms and pre_sh= ared_key
> >=C2=A0 =C2=A0extensions
> >
>
> Tl;dr: I think this is a good approach because it eliminates much of t= he
> existing negotiation redundancy/complexity and combinatorial explosion= in
> the 1.3+ ciphersuite menu.

I recently tried to write code to handle this ciphersuite negotiatio= n, so
that it always negotiates a valid choice if any valid choice exists.

I think the end result was insane. The problem that makes it so difficult is that legacy signature types, group types and protection/PRFs interact, so not all supported offers that server has enabled are actually possible to chose.

Can you say more about this?<= /div>

I spent some time mocking up an implementation loc= ally and it was pretty clean.

Perhaps what made it= easier is that I did:

1. Define new cipher suites= that were totally agnostic about the key exchange
and signature.=

2. Assume everything was orthogonal except for th= e PSK/signature/key exchange
interaction...

-Ekr



-Ekr
=C2=A0

> The longer version: the argument I made in Prague (though IIRC not ver= y
> clearly) was that while it would be nice to limit the ciphersuite opti= ons
> to agreed-upon "good" combinations based on some sane notion= of
> forward-looking security margin (notwithstanding the practical inabili= ty to
> see the future), the reality on the ground is that authentication is b= ased
> on something pre-existing---the server has one or two long-term keys o= f a
> fixed length (e.g., one RSA-2048 and one P-256) that it can't augm= ent on
> demand---so it really only makes sense for the client to indicate what= it
> supports and to deal with whatever the server chooses to send it on th= at
> basis. So I'd argue that this one is orthogonal based on that cons= traint,
> and so it should be negotiated separately.

If you are talking about "strength-matching", there is no = sane notion of
security equivalence with protection, key exchange and signatures (due to different sub-threshold, multi-key and period properties).

And coupling those in a way that doesn't lead to great difficulty (even=
greater than currently) REALLY causes the ciphersuite space to
combinatorially explode.

> AEAD and PRF OTOH don't come with built-in keys, so they can alway= s be
> chosen as a pair as a function of the desired security margin.

Except in some situations (e.g. 64-bit systems with hardware AES and=
CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384.
The "match security" is IMO about not having the weakest algorith= m not
being too weak, or "paying too much" for algorithm that is much a= bove
anything else.

But what it doesn't consider is what if the stronger algorithm is
actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384.
Or if on 32-bit hardware where you don't have hw AES? Then
X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256
if you don't have Ed25519), nevermind that it has "256-bit" s= ymmetric cipher,
but everything else at "128-bit" level...

> Key agreement is not clearly in either category: when it's PSK, it= 's based
> on what you have, so it's similar to authentication; but when it&#= 39;s (EC)DHE,
> it's not, and so ideally you'd like the chosen group to be tie= d to the
> AEAD/PRF security margin. But, since the client has to offer specific<= br> > groups rather than specifying general support for ECDHE or EdDHE, both=
> because ideally we want the client key share sent in the first flight = and
> because unlike RSA or FFDHE a client can't generalize to key sizes= it
> hasn't seen before, it actually still shares a lot in common with = the auth
> case of being sort-of something you have rather than something you can=
> choose on the fly. So I'm also in agreement that this is mostly or= thogonal
> and should be negotiated separately.

"Security matching" between groups and symmetric ciphers i= s already highly
problematic, and depends on all sorts of assumptions (and is generally
biased towards symmetric ciphers being less secure than they seem).

Sure, the server might bias choices, but actually enforcing anything here is IMO unwise.

> So now you have several grab bags and need to choose one from each. Is= it
> necessary to tie the various bits together by security margin? Not cle= ar.
> It's probably fine to assume a client isn't going to announce = support for
> anything it doesn't think is secure enough, so the only practical = downside
> to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary > additional CPU consumption of AES-256/SHA-384. The client was willing = to
> accept P-256 server authentication, so presumably it's happy with = that
> security margin; and anyway, the server could prefer ciphersuites and = ECDHE
> groups that better match the available auth credentials.

IMO, no it is not necressary to tie the security margins. In case of=
authentication and encryption, there is also the issue that authentication<= br> is good if it is unbroken at that moment, whereas key exchange and encrypti= on
must remain unbroken for long time since.

So that someone thinks ECDSA P-256 is OK for authentication does not mean that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think=
that 128-bit symmetric encryption is OK.

> Or maybe prospective security margin is too complex and/or too ill-def= ined
> to bother with, and a server should just choose the least CPU-intensiv= e
> combination of everything.

Well, yeah, it is ill-defined. Of course, there can be bad algorithm= s
that one wants to disable.

However, interactions between bad algorithms are much less likely than
actual bad algorithms causing problems by themselves.


-Ilari

--001a114f8db21314ff0537eb1d32-- From nobody Mon Jul 18 09:19:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767C312DA2F for ; Mon, 18 Jul 2016 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4efKnfEMyUgh for ; Mon, 18 Jul 2016 09:19:43 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0CA12DAC1 for ; Mon, 18 Jul 2016 09:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 93F47115C; Mon, 18 Jul 2016 19:19:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id RaXvimBi5xiY; Mon, 18 Jul 2016 19:19:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 404B721C; Mon, 18 Jul 2016 19:19:40 +0300 (EEST) Date: Mon, 18 Jul 2016 19:19:36 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160718161936.GA13192@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718150750.GA13139@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Refactoring the negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:19:45 -0000 On Mon, Jul 18, 2016 at 06:03:08PM +0200, Eric Rescorla wrote: > On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara > wrote: > > > I think the end result was insane. The problem that makes it so difficult > > is that legacy signature types, group types and protection/PRFs interact, > > so not all supported offers that server has enabled are actually possible > > to chose. > > > > Can you say more about this? I was referring to the scheme in TLS 1.2 and 1.3-14. The problem is, that even if X is "locally" possible (enabled on both sides, the algorithm and its "class" is advertised) does not guarantee that X is "globally" possible (there is actual configuration using X that meets all TLS constraints and algorithm enables). > I spent some time mocking up an implementation locally and it was pretty > clean. > > Perhaps what made it easier is that I did: > > 1. Define new cipher suites that were totally agnostic about the key > exchange and signature. > > 2. Assume everything was orthogonal except for the PSK/signature/key > exchange interaction... Both should eliminate the really nasty parts, as it would mean that unless server wanted to, any X is "locally" valid is also "globally" valid. Modulo key exchange types, but those aren't that bad usually. -Ilari From nobody Mon Jul 18 14:11:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3812D108 for ; Mon, 18 Jul 2016 14:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhmWesIQ1jJO for ; Mon, 18 Jul 2016 14:11:17 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B3112B049 for ; Mon, 18 Jul 2016 14:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7893; q=dns/txt; s=iport; t=1468876277; x=1470085877; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RdVdb+1mmYJAL0vzKDNU4cerZaxzd29VTKUtlhO6SRY=; b=N5Lrk1278iUDtLnyk9U5sQZATDaa8w2XjyKGCGgX6IP0foZikrpXMBa0 Lfa87Nlcrm9pqpEISeiMVqUaTpXgxTdaiUagFSVSWDA/luT7B7sw73Kuq qtbuhF/LhOxZ0HwS8bo0y/O6ICKvK74wz4O0YhWnRd5Hzo5ZmXGMlaTMZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAgDsRI1X/4MNJK1bgz9WfKxKjBuBe?= =?us-ascii?q?iKFeAKBNTgUAQEBAQEBAWUnhFwBAQQBAQEhSwsFBwQLEQQBAQECAiMDAgIhBh8?= =?us-ascii?q?JCAYTiBYDDwgOsCmJWw2EHgEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYchCIJNg?= =?us-ascii?q?kOBWQEjgwErgi8FmHA0hhOCN4N6ghuCOYx+hD+DZod5HjaCCAMcgWggMgGGHQE?= =?us-ascii?q?lgR4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,385,1464652800"; d="scan'208";a="298483787" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 21:11:16 +0000 Received: from rtp-mcgrew-89110.cisco.com (rtp-mcgrew-89110.cisco.com [10.117.10.235]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6ILBFZY006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2016 21:11:15 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: Date: Mon, 18 Jul 2016 17:11:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> To: "Dang, Quynh (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:11:20 -0000 Hi Quynh, > On Jul 13, 2016, at 9:58 AM, Dang, Quynh (Fed) = wrote: >=20 >=20 >=20 > On 7/13/16, 9:26 AM, "Watson Ladd" wrote: >=20 >> On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx = >> wrote: >>> Hey Quynh, >>>=20 >>>> How can one use the distinguishing attack with the data complexity >>>> bound I >>>> suggested for recovering 1 bit of the encryption key in the context = of >>>> TLS >>>> ? >>>=20 >>> You cannot recover any bits of the encryption key unless you attack = AES. >>>=20 >>> No-one, as far as I know, has analyzed what kind of attacks one can >>> perform >>> against GCM around and beyond the birthday bound (except for the = forgery >>> attacks, which require repeated nonces or known forgeries). However, >>> for CTR >>> mode, the underlying encryption of GCM, David McGrew typed up a = document >>> describing an attack one could perform to recover information about = the >>> plaintext: >>> http://eprint.iacr.org/2012/623 >>> He describes it for 64 bit block ciphers, but the attacks work = equally >>> well >>> for 128 bit block ciphers, at a higher data complexity of course. >>>=20 >>> Basically, there are a lot of unknowns, and it could be that the = bounds >>> you >>> recommend will be good enough in practice. However, it's important = to be >>> clear about the risks involved in venturing into unknown territory. >>>=20 >>> Atul >>=20 >> Furthermore the cost of avoiding this is trivial. The rekeying >> mechanism has been designed to have minimal code complexity. >=20 > GCM with data complexity of about 3^38 records is not vulnerable to = that > plaintext recovery attack. Therefore, there are no needs to rekey = before > that data complexity is reached. That=E2=80=99s right, as long as the number of 16-byte blocks per record = is guaranteed to be significantly below 2^26. =20 >=20 > For counter-mode, I think the attack works if there is a large set of > known plaintexts. In protocols such as TLS and Ipsec, there are known > plaintexts, but I don=C2=B9t think the amount of known plaintexts = (even though > the amount of encrypted repeated-plaintexts can be big) is enough to > create risk for AES_128 by the targeted plaintext recovery attack. What is especially cool about counter mode encryption is how its real = world security degrades more gracefully than CBC mode encryption. I am = not sure that the FSE paper did a good job of saying it in English as = opposed to math (except for the last sentence of Section 4), but even = though CTR may be just as distinguishable as CBC after some amount of = known plaintext is encrypted, counter mode in practice gives away much = less information. =20 best David > A known > plaintext can be encrypted multiple times with different keys, not = with > the same key. >=20 > Regards, > Quynh. >=20 >=20 >>>=20 >>>=20 >>> On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: >>>>=20 >>>> Hi Atul, >>>>=20 >>>> On 7/12/16, 3:50 PM, "Atul Luykx" = wrote: >>>>=20 >>>>>> To be clear, this probability is that an attacker would be able = to >>>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>> potential >>>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able = to >>>>>> determine that this plaintext was not the one used for the = ciphertext >>>>>> (and with probability 0.999999999767..., know nothing about = whether >>>>>> his guessed plaintext was correct or not). >>>>>=20 >>>>>=20 >>>>> You need to be careful when making such claims. There are schemes = for >>>>> which when you reach the birthday bound you can perform partial = key >>>>> recovery. >>>>>=20 >>>>> The probabilities we calculated guarantee that there won't be any >>>>> attacks (with the usual assumptions...). Beyond the bounds, there = are >>>>> no >>>>> guarantees. In particular, you cannot conclude that one, for = example, >>>>> loses 1 bit of security once beyond the birthday bound. >>>>=20 >>>>=20 >>>> How can one use the distinguishing attack with the data complexity >>>> bound I >>>> suggested for recovering 1 bit of the encryption key in the context = of >>>> TLS >>>> ? >>>>=20 >>>>=20 >>>> Regards, >>>> Quynh. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Atul >>>>>=20 >>>>> On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>>>>>> Sent: Tuesday, July 12, 2016 1:17 PM >>>>>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>>>>>> tls@ietf.org >>>>>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>>>>=20 >>>>>>> Hi >>>>>>>=20 >>>>>>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Kenny, >>>>>>>>=20 >>>>>>>> On 7/12/16, 12:33 PM, "Paterson, Kenny" = >>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Finally, you write "to come to the 2^38 record limit, they = assume >>>>>>> that >>>>>>>>> each record is the maximum 2^14 bytes". For clarity, we did = not >>>>>>>>> recommend a limit of 2^38 records. That's Quynh's preferred >>>>>>> number, >>>>>>>>> and is unsupported by our analysis. >>>>>>>>=20 >>>>>>>> What is problem with my suggestion even with the record size = being >>>>>>> the >>>>>>>> maximum value? >>>>>>>=20 >>>>>>> There may be no problem with your suggestion. I was simply = trying to >>>>>>> make it >>>>>>> clear that 2^38 records was your suggestion for the record limit = and >>>>>>> not ours. >>>>>>> Indeed, if one reads our note carefully, one will find that we = do >>>>>>> not >>>>>>> make any >>>>>>> specific recommendations. We consider the decision to be one for = the >>>>>>> WG; >>>>>>> our preferred role is to supply the analysis and help interpret = it >>>>>>> if >>>>>>> people >>>>>>> want that. Part of that involves correcting possible = misconceptions >>>>>>> and >>>>>>> misinterpretations before they get out of hand. >>>>>>>=20 >>>>>>> Now 2^38 does come out of our analysis if you are willing to = accept >>>>>>> single key >>>>>>> attack security (in the indistinguishability sense) of 2^{-32}. = So >>>>>>> in >>>>>>> that limited >>>>>>> sense, 2^38 is supported by our analysis. But it is not our >>>>>>> recommendation. >>>>>>>=20 >>>>>>> But, speaking now in a personal capacity, I consider that = security >>>>>>> margin to be >>>>>>> too small (i.e. I think that 2^{-32} is too big a success >>>>>>> probability). >>>>>>=20 >>>>>>=20 >>>>>> To be clear, this probability is that an attacker would be able = to >>>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>> potential >>>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able = to >>>>>> determine that this plaintext was not the one used for the = ciphertext >>>>>> (and with probability 0.999999999767..., know nothing about = whether >>>>>> his guessed plaintext was correct or not). >>>>>>=20 >>>>>> I'm just trying to get people to understand what we're talking = about. >>>>>> This is not "with probability 2^{-32}, he can recover the = plaintext" >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Kenny >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >>=20 >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >=20 From nobody Mon Jul 18 23:26:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30D912DCAF for ; Mon, 18 Jul 2016 23:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVCJHy06D6o1 for ; Mon, 18 Jul 2016 23:26:53 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 5126412DCB1 for ; Mon, 18 Jul 2016 23:26:51 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: C367B13802C.AC1A7 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id C367B13802C for ; Tue, 19 Jul 2016 08:26:47 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id BB2112003B; Tue, 19 Jul 2016 08:26:47 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id B77BF60030; Tue, 19 Jul 2016 08:26:47 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id B247940; Tue, 19 Jul 2016 08:26:47 +0200 (CEST) Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 19 Jul 2016 08:26:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 19 Jul 2016 08:26:47 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: David McGrew In-Reply-To: <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> Message-ID: <57dc53aed46f6a29b30d7db2e4ca38f0@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 06:26:57 -0000 > What is especially cool about counter mode encryption is how its real > world security degrades more gracefully than CBC mode encryption. I > am not sure that the FSE paper did a good job of saying it in English > as opposed to math (except for the last sentence of Section 4), but > even though CTR may be just as distinguishable as CBC after some > amount of known plaintext is encrypted, counter mode in practice gives > away much less information. Just to be precise, no attack has been found which illustrates that CTR mode's security degrades like CBC's. Nevertheless, it might be possible to formalize your intuition. Atul On 2016-07-18 23:11, David McGrew wrote: > Hi Quynh, > >> On Jul 13, 2016, at 9:58 AM, Dang, Quynh (Fed) >> wrote: >> >> >> >> On 7/13/16, 9:26 AM, "Watson Ladd" wrote: >> >>> On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx >>> >>> wrote: >>>> Hey Quynh, >>>> >>>>> How can one use the distinguishing attack with the data complexity >>>>> bound I >>>>> suggested for recovering 1 bit of the encryption key in the context >>>>> of >>>>> TLS >>>>> ? >>>> >>>> You cannot recover any bits of the encryption key unless you attack >>>> AES. >>>> >>>> No-one, as far as I know, has analyzed what kind of attacks one can >>>> perform >>>> against GCM around and beyond the birthday bound (except for the >>>> forgery >>>> attacks, which require repeated nonces or known forgeries). However, >>>> for CTR >>>> mode, the underlying encryption of GCM, David McGrew typed up a >>>> document >>>> describing an attack one could perform to recover information about >>>> the >>>> plaintext: >>>> http://eprint.iacr.org/2012/623 >>>> He describes it for 64 bit block ciphers, but the attacks work >>>> equally >>>> well >>>> for 128 bit block ciphers, at a higher data complexity of course. >>>> >>>> Basically, there are a lot of unknowns, and it could be that the >>>> bounds >>>> you >>>> recommend will be good enough in practice. However, it's important >>>> to be >>>> clear about the risks involved in venturing into unknown territory. >>>> >>>> Atul >>> >>> Furthermore the cost of avoiding this is trivial. The rekeying >>> mechanism has been designed to have minimal code complexity. >> >> GCM with data complexity of about 3^38 records is not vulnerable to >> that >> plaintext recovery attack. Therefore, there are no needs to rekey >> before >> that data complexity is reached. > > That’s right, as long as the number of 16-byte blocks per record is > guaranteed to be significantly below 2^26. > >> >> For counter-mode, I think the attack works if there is a large set of >> known plaintexts. In protocols such as TLS and Ipsec, there are known >> plaintexts, but I don¹t think the amount of known plaintexts (even >> though >> the amount of encrypted repeated-plaintexts can be big) is enough to >> create risk for AES_128 by the targeted plaintext recovery attack. > > What is especially cool about counter mode encryption is how its real > world security degrades more gracefully than CBC mode encryption. I > am not sure that the FSE paper did a good job of saying it in English > as opposed to math (except for the last sentence of Section 4), but > even though CTR may be just as distinguishable as CBC after some > amount of known plaintext is encrypted, counter mode in practice gives > away much less information. > > best > > David > >> A known >> plaintext can be encrypted multiple times with different keys, not >> with >> the same key. >> >> Regards, >> Quynh. >> >> >>>> >>>> >>>> On 2016-07-13 13:14, Dang, Quynh (Fed) wrote: >>>>> >>>>> Hi Atul, >>>>> >>>>> On 7/12/16, 3:50 PM, "Atul Luykx" >>>>> wrote: >>>>> >>>>>>> To be clear, this probability is that an attacker would be able >>>>>>> to >>>>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>>> potential >>>>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able >>>>>>> to >>>>>>> determine that this plaintext was not the one used for the >>>>>>> ciphertext >>>>>>> (and with probability 0.999999999767..., know nothing about >>>>>>> whether >>>>>>> his guessed plaintext was correct or not). >>>>>> >>>>>> >>>>>> You need to be careful when making such claims. There are schemes >>>>>> for >>>>>> which when you reach the birthday bound you can perform partial >>>>>> key >>>>>> recovery. >>>>>> >>>>>> The probabilities we calculated guarantee that there won't be any >>>>>> attacks (with the usual assumptions...). Beyond the bounds, there >>>>>> are >>>>>> no >>>>>> guarantees. In particular, you cannot conclude that one, for >>>>>> example, >>>>>> loses 1 bit of security once beyond the birthday bound. >>>>> >>>>> >>>>> How can one use the distinguishing attack with the data complexity >>>>> bound I >>>>> suggested for recovering 1 bit of the encryption key in the context >>>>> of >>>>> TLS >>>>> ? >>>>> >>>>> >>>>> Regards, >>>>> Quynh. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Atul >>>>>> >>>>>> On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote: >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] >>>>>>>> Sent: Tuesday, July 12, 2016 1:17 PM >>>>>>>> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; >>>>>>>> tls@ietf.org >>>>>>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On 12/07/2016 18:04, "Dang, Quynh (Fed)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Kenny, >>>>>>>>> >>>>>>>>> On 7/12/16, 12:33 PM, "Paterson, Kenny" >>>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Finally, you write "to come to the 2^38 record limit, they >>>>>>>>>> assume >>>>>>>> that >>>>>>>>>> each record is the maximum 2^14 bytes". For clarity, we did >>>>>>>>>> not >>>>>>>>>> recommend a limit of 2^38 records. That's Quynh's preferred >>>>>>>> number, >>>>>>>>>> and is unsupported by our analysis. >>>>>>>>> >>>>>>>>> What is problem with my suggestion even with the record size >>>>>>>>> being >>>>>>>> the >>>>>>>>> maximum value? >>>>>>>> >>>>>>>> There may be no problem with your suggestion. I was simply >>>>>>>> trying to >>>>>>>> make it >>>>>>>> clear that 2^38 records was your suggestion for the record limit >>>>>>>> and >>>>>>>> not ours. >>>>>>>> Indeed, if one reads our note carefully, one will find that we >>>>>>>> do >>>>>>>> not >>>>>>>> make any >>>>>>>> specific recommendations. We consider the decision to be one for >>>>>>>> the >>>>>>>> WG; >>>>>>>> our preferred role is to supply the analysis and help interpret >>>>>>>> it >>>>>>>> if >>>>>>>> people >>>>>>>> want that. Part of that involves correcting possible >>>>>>>> misconceptions >>>>>>>> and >>>>>>>> misinterpretations before they get out of hand. >>>>>>>> >>>>>>>> Now 2^38 does come out of our analysis if you are willing to >>>>>>>> accept >>>>>>>> single key >>>>>>>> attack security (in the indistinguishability sense) of 2^{-32}. >>>>>>>> So >>>>>>>> in >>>>>>>> that limited >>>>>>>> sense, 2^38 is supported by our analysis. But it is not our >>>>>>>> recommendation. >>>>>>>> >>>>>>>> But, speaking now in a personal capacity, I consider that >>>>>>>> security >>>>>>>> margin to be >>>>>>>> too small (i.e. I think that 2^{-32} is too big a success >>>>>>>> probability). >>>>>>> >>>>>>> >>>>>>> To be clear, this probability is that an attacker would be able >>>>>>> to >>>>>>> take a huge (4+ Petabyte) ciphertext, and a compatibly sized >>>>>>> potential >>>>>>> (but incorrect) plaintext, and with probability 2^{-32}, be able >>>>>>> to >>>>>>> determine that this plaintext was not the one used for the >>>>>>> ciphertext >>>>>>> (and with probability 0.999999999767..., know nothing about >>>>>>> whether >>>>>>> his guessed plaintext was correct or not). >>>>>>> >>>>>>> I'm just trying to get people to understand what we're talking >>>>>>> about. >>>>>>> This is not "with probability 2^{-32}, he can recover the >>>>>>> plaintext" >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Kenny >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> >>> -- >>> "Man is born free, but everywhere he is in chains". >>> --Rousseau. >> From nobody Mon Jul 18 23:59:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB6D12B004 for ; Mon, 18 Jul 2016 23:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 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=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCVhvhSTv4BL for ; Mon, 18 Jul 2016 23:58:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0B712B038 for ; Mon, 18 Jul 2016 23:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1468911535; x=1500447535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tyTnbfkOC2xYvdPV5Hd04y1ZiEmzZFLIS/Ual+s6r9o=; b=KXDlxYfdqnr1ngfIXv14xRy6wfGxEtGvLr8YM0c99r4pcQe10Z7pG10P YeprMUP8BC4wW+27y2tRKvn7QR6lOt4SOuccBGOaiqkYONLzJW5Visn9B UwWGqFnfOcedYviNkpxfl2K+r9y6bRi9pJRhCKAiGbuNbm1B4hRqchja+ 9SJjRAjQGORndTEPgayTiQR70IxJTxlUDUEumVb1Gq4m4wynrkhv9bg49 W/nw5e9zJ9nBOAG6Ttv0XbB2QMqYqHaEtHDI9PdvISRQQ64mfIcBNc36A ZxpUr8Swl1XhIQDxkvS4JGfVzlc40dNQOBRrdDbOjI/vGKycVYvr9UUEN w==; X-IronPort-AV: E=Sophos;i="5.28,388,1464609600"; d="scan'208";a="97543499" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Jul 2016 18:58:53 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 19 Jul 2016 18:58:53 +1200 From: Peter Gutmann To: David McGrew , "Dang, Quynh (Fed)" Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt Thread-Index: AQHR4Tj/PHuK4OImE0W52Oo237UniqAfU2NL Date: Tue, 19 Jul 2016 06:58:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CCD669@uxcn10-5.UoA.auckland.ac.nz> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> , <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> In-Reply-To: <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] 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] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 06:59:01 -0000 David McGrew writes:=0A= =0A= >What is especially cool about counter mode encryption is how its real worl= d=0A= >security degrades more gracefully than CBC mode encryption.=0A= =0A= Uhh... how does CTR "degrade gracefully" compared to CBC? With CTR, any ki= nd=0A= of problem with the IV/CTR leads to a catastrophic loss of security. With = CBC,=0A= even the worst-case IV abuse you can apply, setting it to all zeroes, just= =0A= degrades the mode to ECB.=0A= =0A= (There have been a number of instances of CTR, or at least GCM, failures=0A= already, and I doubt we've seen the last of it. It's RC4 all over again).= =0A= =0A= Peter.= From nobody Tue Jul 19 02:53:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6F12DDAA for ; Tue, 19 Jul 2016 02:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BqMq3UdYdkn for ; Tue, 19 Jul 2016 02:53:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F8C12D186 for ; Tue, 19 Jul 2016 02:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=995; q=dns/txt; s=iport; t=1468921670; x=1470131270; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TJDFsiTaA0h9IP6DimN8vg1xJomVyc4aCE/cnkpwVLY=; b=gSN9vGVhnWGnvkLFzf1POAkvllqs5IDjmPuijvjuBdCF6KvBEfCZHipl V6CjIlc7nhXOIqck07gC9XMIEAlGo4ndqpOiNUU1jNPn28iQty+uv2FRe Jh2T+3cJR6R9mAzvHrNf7haGB038C9DrnH0RMqvlGdXdmMBh5p1tYC3hN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7BQAb9o1X/4ENJK1cDoMxgVK4ZYF6h?= =?us-ascii?q?hoCgTI6EgEBAQEBAQFlJ4RcAQEEASNWBQsLDgoCAiYCAlcGE4goCK59jg4BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEcgQGHIYJVhECDASuCLwEEmSSOYo83kB4lCySCC?= =?us-ascii?q?xyBEVcgMogQAQEB?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="125640563" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 09:47:49 +0000 Received: from rtp-mcgrew-89110.cisco.com (rtp-mcgrew-89110.cisco.com [10.117.10.235]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6J9lmuu014394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 09:47:49 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CCD669@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 19 Jul 2016 05:47:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CAE805B-A8E4-409A-A6E4-314DE4BD07B5@cisco.com> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4CCD669@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:53:47 -0000 Hi Peter, > On Jul 19, 2016, at 2:58 AM, Peter Gutmann = wrote: >=20 > David McGrew writes: >=20 >> What is especially cool about counter mode encryption is how its real = world >> security degrades more gracefully than CBC mode encryption. >=20 > Uhh... how does CTR "degrade gracefully" compared to CBC? =20 I should have said: =E2=80=9Cdegrades more gracefully as the number of = known plaintext blocks increases to, and beyond, the birthday bound=E2=80=9D= . =20 > With CTR, any kind > of problem with the IV/CTR leads to a catastrophic loss of security. = With CBC, > even the worst-case IV abuse you can apply, setting it to all zeroes, = just > degrades the mode to ECB. >=20 Right, but that=E2=80=99s a different topic. David > (There have been a number of instances of CTR, or at least GCM, = failures > already, and I doubt we've seen the last of it. It's RC4 all over = again). >=20 > Peter. From nobody Tue Jul 19 03:03:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7975112DB7F for ; Tue, 19 Jul 2016 03:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLf_C7NKMqf5 for ; Tue, 19 Jul 2016 03:03:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C2F12DC4F for ; Tue, 19 Jul 2016 02:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1522; q=dns/txt; s=iport; t=1468922335; x=1470131935; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t0mTDiQ/d8Pg2XGqT6GslBBpvUADr/wWc4RyVQMubRk=; b=kknalgjZFJ9V4t04W40d3I8M76ynqN5hzdegPNYDthosXfNgGrhT+Jtx VIbjPJOUOuoxM79wTecf5fFupFiSBkJTVDQrZkfHHLoxUTvSoEr7pDcRo 8lBnLtmfRHGYUjpHvgV3IpSJ6opFcGgyUnJumZ72bfHu2j7WHu1aYFAWg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7BQCT+I1X/4ENJK1cgz+BUrhlgXqGG?= =?us-ascii?q?gKBMjoSAQEBAQEBAWUnhFwBAQQBI1YFCwsYAgImAgJXBhOIKAiucY4OAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHIEBhyGCVYRAgwErgi8FmSSOYo83kB4lAS6CCxyBa?= =?us-ascii?q?CAyAYgPAQEB?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="127436220" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 09:58:55 +0000 Received: from rtp-mcgrew-89110.cisco.com (rtp-mcgrew-89110.cisco.com [10.117.10.235]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6J9ws2R024187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 09:58:54 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: <57dc53aed46f6a29b30d7db2e4ca38f0@esat.kuleuven.be> Date: Tue, 19 Jul 2016 05:58:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <795DBE17-4A95-4AF8-929E-6C247C3324E4@cisco.com> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> <57dc53aed46f6a29b30d7db2e4ca38f0@esat.kuleuven.be> To: Atul Luykx X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:03:36 -0000 HI Atul, > On Jul 19, 2016, at 2:26 AM, Atul Luykx = wrote: >=20 >> What is especially cool about counter mode encryption is how its real >> world security degrades more gracefully than CBC mode encryption. I >> am not sure that the FSE paper did a good job of saying it in English >> as opposed to math (except for the last sentence of Section 4), but >> even though CTR may be just as distinguishable as CBC after some >> amount of known plaintext is encrypted, counter mode in practice = gives >> away much less information. >=20 > Just to be precise, no attack has been found which illustrates that = CTR mode's security degrades like CBC=E2=80=99s. I either don=E2=80=99t understand the sentence, or I disagree with it. = Both CTR and CBC are only secure up to the birthday bound, and are = distinguishable at or beyond that bound. =20 > Nevertheless, it might be possible to formalize your intuition. >=20 Agreed, and what is needed is a measure of the expected amount of = information an attacker has about the (unknown) target plaintext, which = would be larger in the CBC case than the CTR case. This is = interesting, but of course, we should stick with the standard definition = of indistinguishability as our security criterion. Hope this doesn=E2=80=99t sound like nit picking; I just want to make = sure that no one thinks I am suggesting that it is OK to use encryption = systems that are distinguishable. best, David > Atul From nobody Tue Jul 19 03:12:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3392912D522 for ; Tue, 19 Jul 2016 03:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKfiXh8MOyY8 for ; Tue, 19 Jul 2016 03:12:53 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 3FAE912D1BC for ; Tue, 19 Jul 2016 03:12:47 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 944D513802F.A8D27 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 944D513802F for ; Tue, 19 Jul 2016 12:12:45 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 8F8ED403B; Tue, 19 Jul 2016 12:12:45 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 8BE6B6002E; Tue, 19 Jul 2016 12:12:45 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 82DCE40; Tue, 19 Jul 2016 12:12:45 +0200 (CEST) Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 19 Jul 2016 12:12:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 19 Jul 2016 12:12:45 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: David McGrew In-Reply-To: <795DBE17-4A95-4AF8-929E-6C247C3324E4@cisco.com> References: <0ad33f70cbe2aabba1f16f4cac876b0f@esat.kuleuven.be> <553ea052cc05b4f7315e19c943b0c2b0@esat.kuleuven.be> <88AC1F39-6222-4D7A-AB1D-5FA4156C42C3@cisco.com> <57dc53aed46f6a29b30d7db2e4ca38f0@esat.kuleuven.be> <795DBE17-4A95-4AF8-929E-6C247C3324E4@cisco.com> Message-ID: <1759eae16992f43f05b894b0df5c0c98@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:12:56 -0000 Hey David, On 2016-07-19 11:58, David McGrew wrote: > HI Atul, > >> On Jul 19, 2016, at 2:26 AM, Atul Luykx >> wrote: >> >>> What is especially cool about counter mode encryption is how its real >>> world security degrades more gracefully than CBC mode encryption. I >>> am not sure that the FSE paper did a good job of saying it in English >>> as opposed to math (except for the last sentence of Section 4), but >>> even though CTR may be just as distinguishable as CBC after some >>> amount of known plaintext is encrypted, counter mode in practice >>> gives >>> away much less information. >> >> Just to be precise, no attack has been found which illustrates that >> CTR mode's security degrades like CBC’s. > > I either don’t understand the sentence, or I disagree with it. Both > CTR and CBC are only secure up to the birthday bound, and are > distinguishable at or beyond that bound. > Sounds good; I was just clarifying the possibility that CTR could be as vulnerable as CBC beyond the birthday bound in practice, addressing the following sentence: >> counter mode in practice gives away much less information. But you're right, I wasn't very clear. >> Nevertheless, it might be possible to formalize your intuition. >> > > Agreed, and what is needed is a measure of the expected amount of > information an attacker has about the (unknown) target plaintext, > which would be larger in the CBC case than the CTR case. This is > interesting, but of course, we should stick with the standard > definition of indistinguishability as our security criterion. > > Hope this doesn’t sound like nit picking; I just want to make sure > that no one thinks I am suggesting that it is OK to use encryption > systems that are distinguishable. > > best, > > David > >> Atul From nobody Tue Jul 19 07:25:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF412E14F for ; Tue, 19 Jul 2016 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2uzEEqVRYf2 for ; Tue, 19 Jul 2016 07:25:55 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7010812E2BC for ; Tue, 19 Jul 2016 06:46:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AD4E24603 for ; Tue, 19 Jul 2016 16:46:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id mLxMBzBcjZSw for ; Tue, 19 Jul 2016 16:46:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 67C54C4 for ; Tue, 19 Jul 2016 16:46:30 +0300 (EEST) Date: Tue, 19 Jul 2016 16:46:26 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:25:57 -0000 Thinking about this... One option would be like 2 on the slides (the overstriked one!), except: - The message is synthethized, not actually sent on wire (but still logged). - It only happens after the last ClientHello. - It uses the actual PSK, even if not #0. Maybe I should have listened to the talk more carefully, but the reason I got for overstriking the second option was that it is unimplementable in practice. Of course, dunno if the changes would actually fix the problems with PSK contexts... -Ilari From nobody Tue Jul 19 07:33:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F396612DD30; Tue, 19 Jul 2016 07:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nSHDPSN4ag2; Tue, 19 Jul 2016 07:33:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F0912D6AC; Tue, 19 Jul 2016 07:01:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B2F20B80E05; Tue, 19 Jul 2016 07:01:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160719140100.B2F20B80E05@rfc-editor.org> Date: Tue, 19 Jul 2016 07:01:00 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7924 on Transport Layer Security (TLS) Cached Information Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 14:33:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7924 Title: Transport Layer Security (TLS) Cached Information Extension Author: S. Santesson, H. Tschofenig Status: Standards Track Stream: IETF Date: July 2016 Mailbox: sts@aaa-sec.com, Hannes.Tschofenig@gmx.net Pages: 19 Characters: 35144 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-cached-info-23.txt URL: https://www.rfc-editor.org/info/rfc7924 DOI: http://dx.doi.org/10.17487/RFC7924 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, thereby enabling the server to omit already available information. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jul 19 08:05:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE712D7A3 for ; Tue, 19 Jul 2016 08:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZdT79nleUo1 for ; Tue, 19 Jul 2016 08:05:17 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 34E2412E042 for ; Tue, 19 Jul 2016 07:41:19 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r9so18033579ywg.0 for ; Tue, 19 Jul 2016 07:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cS5b1+en2rO5q4+I6RRecZ3odkII2QHWrYyGBn6J8jQ=; b=cZGz1j9RaU0bNGQGEaXlqxPF+oAk3vKxldBrcj9lYDodDQFmzz+vh/sQhFWx34xDES GpG/HzAdh1h0dBxDcV816+tc4Zfg14aKyDbf/L8Rr9+0ZPzybbu1vHBxX6BQPOeuIrte RC+Sql9rJct27dmB/daJfD0Z/tW9ZV5rpOigBdmel9xatHv4kol+By3LYHhf15UCbavn sgLJOnhRBE141HYvN8nAXgBNOurQ1Q7TfPTea5PP9+M/ilyLx9fvMeA2kEqWC5JLA9jl masZMKOO8m2XvTamnAnOjWbSvm0IJfJ1MHB0sSYfY6x6MSkdy8l9V9UNhwPAPv9+bPqA wXnQ== 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; bh=cS5b1+en2rO5q4+I6RRecZ3odkII2QHWrYyGBn6J8jQ=; b=F8KZz/0ZztyNynsFzvHL0A+9xKJuTstKB4JAiAIw+YoF1dlvZlvCRUl8QPdXS1OB2P yLSCHCqVJDsS7wHS++fm7fP5w6HTC/mIBCBqKKvgLui7iKScJo+qHCBvl5LXq35LlxEp hrgAHU02jZw2l9Kw+XHNOXmGgc0Rg8xb5D5Q2vNuTUhrqo9qM3V1hyPHsIkHey02znWf juQqHqGOSKPXJLs3Vr2L7Je1opolE1Uw8/xy9EtiA3T4N7YEcFA3/UW+br9tBhIEIlr/ o4DBNrYoiIu6nwcO4n0Ik5qwEGdQyz2KvVjj3CpMUhjzdfZ0GrG6YliZ+urln0VLbRsq hYow== X-Gm-Message-State: ALyK8tJb0jN25MO/3i+NJWJix2daGZmcS+F1bmfw5xkzABuQ+CNfJUaY/DRGl2m7yz1Iouk3nA1VHHsdoDeWwA== X-Received: by 10.37.211.132 with SMTP id e126mr25862130ybf.74.1468939278438; Tue, 19 Jul 2016 07:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 19 Jul 2016 07:40:38 -0700 (PDT) In-Reply-To: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 19 Jul 2016 16:40:38 +0200 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c14710ae380660537fe1320 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:05:19 -0000 --94eb2c14710ae380660537fe1320 Content-Type: text/plain; charset=UTF-8 The problem with the second option is that it's not safe to send the 0-RTT Finished on the wire if you don't know that the other side is 1.3; that's an assumption we made about 0-RTT but not one we want to make for PSK-resumption. -Ekr On Tue, Jul 19, 2016 at 3:46 PM, Ilari Liusvaara wrote: > Thinking about this... > > One option would be like 2 on the slides (the overstriked one!), except: > > - The message is synthethized, not actually sent on wire (but still > logged). > - It only happens after the last ClientHello. > - It uses the actual PSK, even if not #0. > > > Maybe I should have listened to the talk more carefully, but the > reason I got for overstriking the second option was that it is > unimplementable in practice. > > > Of course, dunno if the changes would actually fix the problems > with PSK contexts... > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c14710ae380660537fe1320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem with the second option is that it's not sa= fe to send the 0-RTT Finished on the wire if you don't know that the ot= her side is 1.3; that's an assumption we made about 0-RTT but not one w= e want to make for PSK-resumption.

-Ekr


On Tue,= Jul 19, 2016 at 3:46 PM, Ilari Liusvaara <ilariliusvaara@welho.com= > wrote:
Thinking about thi= s...

One option would be like 2 on the slides (the overstriked one!), except:
- The message is synthethized, not actually sent on wire (but still
=C2=A0 logged).
- It only happens after the last ClientHello.
- It uses the actual PSK, even if not #0.


Maybe I should have listened to the talk more carefully, but the
reason I got for overstriking the second option was that it is
unimplementable in practice.


Of course, dunno if the changes would actually fix the problems
with PSK contexts...



-Ilari

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

--94eb2c14710ae380660537fe1320-- From nobody Tue Jul 19 08:09:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022112DF80 for ; Tue, 19 Jul 2016 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tJVQo4d6Sdy for ; Tue, 19 Jul 2016 08:09:19 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360E512DDA3 for ; Tue, 19 Jul 2016 07:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Ti/WBKNfnBa0B8os0RmHDi9LCh9RGu07XmKh3HWxoX4=; b=JQ/fWYUm6h99XqzQOJUZq5H8U1HmhSxMacMt87elCVwlZ+4TZTiLXTT+tzvg12JytAMehunbWs3xDqN0Oj+OLHK33xvRFFwJeqeeN7eGg0CZHNI9Om+Lhnd78ijDmirvqas48ZqiP3jC67uzlJKmHdV7v54A+zx5KX1qwK/EO8EjkdMezPwo5ecrVYWyGL2B3ayrXfpmGs0kYH/3o3cIQqf6RQXfAP6HXI4IFo1v8E5Xe7w/asys6dOTFVS8XyGjYwj2NtxT50VISY4rB6HwgMwGEu/85AzToAMPoO2J5begGvmOa7gxICmIU0Dj7VdUYRMHQeJEneeL0Pxd/C9yrA==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (envelope-from ) id 1bPWGh-00078M-7s ; Tue, 19 Jul 2016 16:45:08 +0200 From: "Antoine Delignat-Lavaud" To: "'Ilari Liusvaara'" , References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 19 Jul 2016 16:45:01 +0200 Message-ID: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9/e1dQJA4pkpRlO4rMyjbOzdXDaBHmdxg Content-Language: fr X-Invalid-HELO: HELO is no FQDN (contains no dot) (See RFC2821 4.1.1.1) Archived-At: Cc: 'Karthikeyan Bhargavan' , Markulf Kohlweiss Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:09:23 -0000 Dear all, Here is an extended summary of the early Finished / resumption context discussion at the WG. 1. Signature forwarding with external PSK Currently, resumption context is only defined for resumption-based PSK, which means that external PSKs are not protected against transcript synchronization attacks. At a high level, this means that there is no crypographic binding between the handshake log (what is signed for authentication) and the PSK used in the key exchange. In the resumption case, the resumption context fills this role (which is the reason why it was introduced); however, all external PSKs currently have their resumption context set to 0 (and thus, all logs are equivalent w.r.t. all non-resumption PSK). Since the handshake log is what get signed during certificate-based authentication, the lack of binding means that a signature from a session s1 can be used in a session s2 as long as the PSK identifier are the same, which is a very weak constraint. Before Cas Cremer's paper, this was particularly bad because the Finished (which is bound cryptographically to the PSK) was not part of the handshake log; therefore, all signatures could potentially be replayed. However, even though Finished are now part of the log, the server signature in PSK 1-RTT remains vulnerable (because the log is then ClientHello, ServerHello, Certificate and thus has no Finished message to save us from transcript synchronization). For those of you who were at TRON, you may remember that Karthik made this point quite clearly in his talk (he even proposed to swap CV and Finished for this very reason!). An attack against external PSKs easily follows: we assume that an attacker A wants to impersonate a server S to some IoT-like client C that can only do pure PSK for key exchange. 1. C registers to A under the PSK identifier Xc. The PSK between C and A is Kca 2. A, acting as a client, registers to S under the same identifier Xc. The PSK between A and S is Kas 3. C connects to A using (Xc, Kca). A forwards the ClientHello to S 4. S sends back ServerHello, [EE, Cert(S), CertVerify, Finished]_hs where hs depends on Kas and the log [ClientHello, ServerHello] 5. A forwards ServerHello from S to A and re-encrypts [EE, Cert(S), CertVerify] under hs' which depends on Kca and [ClientHello, ServerHello] 6. Since all logs are synchronized and nothing in the CertVerify depends on Kca or Kas, C authenticates A as S. 2. Proposals to bind log and PSK As pointed out by Karthik months ago (and by myself years ago, in the context of Triple Handshake), implicit authentication (such as PSK or resumption) is difficult to mix correctly with transcript-based signatures. We have considered several ways to ensure uniform security for all PSK modes. The simplest solution (let's call it option A) is to rely on the draft 13 resumption context infrastructure also in the case of external PSK. Put it simply, externally-provided PSKs are treated as if they were resumption master secrets: if K is the external key, we first compute Ek = extract(K, 0), then PSK=expand(Ek, "external psk") and RC=expand(Ek, "external psk context"). Resumption context is renamed PSK context and PSK and RC are used as in the current draft13 key schedule. While option A does the job, we think it is over-complicated, as we observe that the early finished can actually play exactly the same role as the current resumption context (saving the concatenation with rc in every expansion with an handshake log). As an option B, we propose to always include an early finished in the log, regardless of the handshake mode. This comes with some complications that were discussed during the WG meeting. Very notably, if this early finished is assumed to always come after the ClientHello, then it must either a. mangled with the ClientHello in an ugly way or b.send on the wire at all. During the WG meeting, it was pointed out that regardless of whether a or b is used, if the client proposes more than one PSK, there needs to be more than one early finished. I have thought more about this, and I now agree that this makes option B unpractical. We are left with some more options: one would be to swap CertificateVerify and Finished, as Karthik originally suggested. Another would be to have a Finished immediately after ServerHello. Neither of these alternatives is particularly appealing, and it may be the case that option A is in fact the better choice. Best, Antoine -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: mardi 19 juillet 2016 15:46 To: tls@ietf.org Subject: [TLS] Resumption Contexts and 0-RTT Finished Thinking about this... One option would be like 2 on the slides (the overstriked one!), except: - The message is synthethized, not actually sent on wire (but still logged). - It only happens after the last ClientHello. - It uses the actual PSK, even if not #0. Maybe I should have listened to the talk more carefully, but the reason I got for overstriking the second option was that it is unimplementable in practice. Of course, dunno if the changes would actually fix the problems with PSK contexts... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 19 08:40:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806F12D971 for ; Tue, 19 Jul 2016 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h75kCJjMgGXN for ; Tue, 19 Jul 2016 08:40:16 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72DA12DC39 for ; Tue, 19 Jul 2016 08:25:03 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u134so18506610ywg.3 for ; Tue, 19 Jul 2016 08:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZB8uaH47tlHMfa+ir70KGeuEZgNNNt12CRoSphH8LbE=; b=jemn5xdsKdqNoAuqVuutuqNe2n3X8/0J82Pij23UPtbwLYEbk8GQBFc3MD9SrqJPat 0C/TMKnERDETJld4txLrTksnMw4iD9ZPa59IsH3Vn2EnJ7qs/2bvWjuSfLGgyjdhb3m3 bizxBAn21fGQ4qspz69sx042gSp/y++U2AUUUqDKxu6enz+hrRNzxxWlhWXT96X4+CHH 3dgwh0BYAJbrfBZ3Ot6t4dpr73XraE7RBYzZSrfFInMDCc0mfX4zCpnQTgr6pUZfHWjg fu1fxLz6uP9taOWfmVPL9W+s7wr6YL/0L4npb7EvoylpzEO7md/LIWx0/5RhhOJjsjxb 7pHg== 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; bh=ZB8uaH47tlHMfa+ir70KGeuEZgNNNt12CRoSphH8LbE=; b=GbTO5dNsxOMxCjQq4UmEjjv5hhYpyLIlJLy1pO+HweiLCD3epawkBvEFfGRMudc2ZW ilBSzaLpXFiMgWCeh6p0V72iHNf8OgKpYCGq+XMDOkl/B/VyvuYN8lWm4XepZ54GFoQi 3fyQs2jfNDOFtplJTMD7RamQCrHcnzKZ04Iv+B9U3aWNiRIMIQZKn0aCX/TnMhjdvD00 yW7HgBOXRfVcvPWe9vYSmVLcd3EcyWcWcv54y9wYc0D/IX+lBXwiwP8NQLg3B8oro4GQ lS2WFxHcHPZcyMx2mXiOLDL1Ux48Tn1KaH6GJm454oP/IWNnuRhq8LGXRI7UiQu8x4vb Z6Lg== X-Gm-Message-State: ALyK8tKCflHGQEEwNeTwP9VSGTFkeV9aBl9ePfMa2dEKymQ/3DTwAHS9o5qhvKwp68zygpca2RoDwy9RDtCoew== X-Received: by 10.129.161.129 with SMTP id y123mr29949222ywg.214.1468941902970; Tue, 19 Jul 2016 08:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Tue, 19 Jul 2016 08:24:23 -0700 (PDT) In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> From: Eric Rescorla Date: Tue, 19 Jul 2016 17:24:23 +0200 Message-ID: To: Antoine Delignat-Lavaud Content-Type: multipart/alternative; boundary=001a114f8db252b0ca0537feb068 Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:40:18 -0000 --001a114f8db252b0ca0537feb068 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 4:45 PM, Antoine Delignat-Lavaud < antoine@delignat-lavaud.fr> wrote: > Dear all, > > Here is an extended summary of the early Finished / resumption context > discussion at the WG. > > Thanks for writing this up! > 1. Signature forwarding with external PSK > > Currently, resumption context is only defined for resumption-based PSK, > which means that external PSKs are not protected against transcript > synchronization attacks. > > At a high level, this means that there is no crypographic binding between > the handshake log (what is signed for authentication) and the PSK used in > the key exchange. > In the resumption case, the resumption context fills this role (which is > the > reason why it was introduced); however, all external PSKs currently have > their resumption context set to 0 (and thus, all logs are equivalent w.r.t. > all non-resumption PSK). > Since the handshake log is what get signed during certificate-based > authentication, the lack of binding > means that a signature from a session s1 can be used in a session s2 as > long > as the PSK identifier are the same, which is a very weak constraint. > Note that this form of PSK + server signature isn't a mode we currently specify in TLS 1.3 However, given that the negotiation changes we discussed today would in fact enable it, it seems like that would be something that's good to fix now. We have considered several ways to ensure uniform security for all PSK > modes. > The simplest solution (let's call it option A) is to rely on the draft 13 > resumption context infrastructure also in the case of external PSK. > Put it simply, externally-provided PSKs are treated as if they were > resumption master secrets: if K is the external key, we first compute > Ek = extract(K, 0), then PSK=expand(Ek, "external psk") and RC=expand(Ek, > "external psk context"). > Resumption context is renamed PSK context and PSK and RC are used as in the > current draft13 key schedule. > I think this is the best option at this point. -Ekr > I have thought more about this, and I now agree that this makes option B > unpractical. > We are left with some more options: one would be to swap CertificateVerify > and Finished, as Karthik originally suggested. > Another would be to have a Finished immediately after ServerHello. Neither > of these alternatives is particularly appealing, > and it may be the case that option A is in fact the better choice. > > Best, > > Antoine > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: mardi 19 juillet 2016 15:46 > To: tls@ietf.org > Subject: [TLS] Resumption Contexts and 0-RTT Finished > > Thinking about this... > > One option would be like 2 on the slides (the overstriked one!), except: > > - The message is synthethized, not actually sent on wire (but still > logged). > - It only happens after the last ClientHello. > - It uses the actual PSK, even if not #0. > > > Maybe I should have listened to the talk more carefully, but the reason I > got for overstriking the second option was that it is unimplementable in > practice. > > > Of course, dunno if the changes would actually fix the problems with PSK > contexts... > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114f8db252b0ca0537feb068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 19, 2016 at 4:45 PM, Antoine Delignat-Lavaud <ant= oine@delignat-lavaud.fr> wrote:
Dear all,=

Here is an extended summary of the early Finished / resumption context
discussion at the WG.


Thanks for writing this up!
=
=C2=A0
1. Signature forwarding with external PSK

Currently, resumption context is only defined for resumption-based PSK,
which means that external PSKs are not protected against transcript
synchronization attacks.

At a high level, this means that there is no crypographic binding between the handshake log (what is signed for authentication) and the PSK used in the key exchange.
In the resumption case, the resumption context fills this role (which is th= e
reason why it was introduced); however, all external PSKs currently have their resumption context set to 0 (and thus, all logs are equivalent w.r.t.=
all non-resumption PSK).
Since the handshake log is what get signed during certificate-based
authentication, the lack of binding
means that a signature from a session s1 can be used in a session s2 as lon= g
as the PSK identifier are the same, which is a very weak constraint.

Note that this form of PSK + server signature= isn't a mode we currently specify
in TLS 1.3 =C2=A0However, = given that the negotiation changes we discussed today
would in fa= ct enable it, it seems like that would be something that's good to fix<= /div>
now.


We have considered several ways to ensure uniform security for all PSK
modes.
The simplest solution (let's call it option A) is to rely on the draft = 13
resumption context infrastructure also in the case of external PSK.
Put it simply, externally-provided PSKs are treated as if they were
resumption master secrets: if K is the external key, we first compute
Ek =3D extract(K, 0), then PSK=3Dexpand(Ek, "external psk") and R= C=3Dexpand(Ek,
"external psk context").
Resumption context is renamed PSK context and PSK and RC are used as in the=
current draft13 key schedule.

I think t= his is the best option at this point.

-Ekr
=C2=A0
I have thought more about this, and I now agree that this makes option B unpractical.
We are left with some more options: one would be to swap CertificateVerify<= br> and Finished, as Karthik originally suggested.
Another would be to have a Finished immediately after ServerHello. Neither<= br> of these alternatives is particularly appealing,
and it may be the case that option A is in fact the better choice.

Best,

Antoine

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Ilari Liusvaara
Sent: mardi 19 juillet 2016 15:46
To: tls@ietf.org
Subject: [TLS] Resumption Contexts and 0-RTT Finished

Thinking about this...

One option would be like 2 on the slides (the overstriked one!), except:
- The message is synthethized, not actually sent on wire (but still
=C2=A0 logged).
- It only happens after the last ClientHello.
- It uses the actual PSK, even if not #0.


Maybe I should have listened to the talk more carefully, but the reason I got for overstriking the second option was that it is unimplementable in practice.


Of course, dunno if the changes would actually fix the problems with PSK contexts...



-Ilari

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


--001a114f8db252b0ca0537feb068-- From nobody Tue Jul 19 09:37:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AA812D0E5 for ; Tue, 19 Jul 2016 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVAxKWVqizet for ; Tue, 19 Jul 2016 09:37:39 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D15BE12B04F for ; Tue, 19 Jul 2016 09:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 4F5CA4820; Tue, 19 Jul 2016 19:37:37 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id c55pwJ2lcFoD; Tue, 19 Jul 2016 19:37:37 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EE72C2310; Tue, 19 Jul 2016 19:37:36 +0300 (EEST) Date: Tue, 19 Jul 2016 19:37:32 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160719163732.GA14532@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:37:41 -0000 On Tue, Jul 19, 2016 at 04:45:01PM +0200, Antoine Delignat-Lavaud wrote: > > 1. Signature forwarding with external PSK > > Currently, resumption context is only defined for resumption-based PSK, > which means that external PSKs are not protected against transcript > synchronization attacks. > > Before Cas Cremer's paper, this was particularly bad because the Finished > (which is bound cryptographically to the PSK) was not part of the handshake > log; therefore, all signatures could potentially be replayed. > However, even though Finished are now part of the log, the server signature > in PSK 1-RTT remains vulnerable (because the log is then ClientHello, > ServerHello, Certificate and thus has no Finished message to save us from > transcript synchronization). Oh yeah, that. > 2. Proposals to bind log and PSK > > As an option B, we propose to always include an early finished in the log, > regardless of the handshake mode. > This comes with some complications that were discussed during the WG > meeting. Very notably, if this early finished is assumed to always come > after the ClientHello, then it must either a. mangled with the ClientHello > in an ugly way or b.send on the wire at all. > During the WG meeting, it was pointed out that regardless of whether a or b > is used, if the client proposes more than > one PSK, there needs to be more than one early finished. What about never sending it on the wire but still having it in hash just before ServerHello, using the actually used PSK key and PRF and logically sent by the client. Placing it before SH instead of after CH is because of interactions with restart/0-RTT. The logical sender matters for DTLS (uses message number on which side?). Pros: - Binds PSK into the log (dealing with the attack above) - Friendly to TLS 1.2 servers. - Can be made up on the spot, no need to compute multiple, no need to speculate (even if speculating on PSK). Cons: - Special case of message being hashed that doesn't appear on the wire, no percedent for this (only hs messages on wire not appearing in logs). - Can't be easily included in 0-RTT keymat. But then, seems kinda pointless to include it, as 0-RTT keymat already depends on all the same inputs (PSK#0 and CH). Of course, no idea just how nasty implementing this in various TLS stacks would be... Could be very nasty... -Ilari From nobody Tue Jul 19 22:43:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F012DA7A for ; Tue, 19 Jul 2016 22:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBwqCt-ntmIN for ; Tue, 19 Jul 2016 22:43:29 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966C112DA82 for ; Tue, 19 Jul 2016 22:43:28 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j12so29203070ywb.2 for ; Tue, 19 Jul 2016 22:43:28 -0700 (PDT) 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; bh=CxdmZ6fK/dVlw/sVjzGMkfMD2RozZvJJ7EtMyPjwHmc=; b=wtYHF5YsEHz33Nim6SOFa1WvnIlsA4KzovIR2NpH76FxAaSYv00pWrirXXGANox4L6 1dfChvTHiUFak4mi1nv4x3TsQv3BGYdSGgaIprNON5qhfJ6Nq3e3gFRNhaLJq9+z9otV JRXTzfPMK2OPVnYZfPPz3r+iOmLk2UNcppSzdTW5iJBxNMuBDHm/CJP+i1HSMWFVu+Lt cRDWWMnWGXW7HfbWH+7WtyzD5YIgCCPFV80e04FxNO3MMHWdnK67OCNRQ9coJqOhVXp8 kYuIQN+AcO48149CHgC2xxFBSgFBaD7q8v+/VtfKnove13c4aoWDzmJdwp0yzJ3YG6fv +nhQ== 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; bh=CxdmZ6fK/dVlw/sVjzGMkfMD2RozZvJJ7EtMyPjwHmc=; b=Znp3GAQaQ1gPwzVR1iL9ewtykKZwJJFy31prOovIsftluExwhyIgQ/KoqgR7Vu+Wnz kYpoQcHm2vTO7rRXidVxhjjzLmiX5y6g0FN09pARNsNUzg9Un+a1s05JcKCYgFwVQ69f yepJzRMyHoapogaXIqXxW84cYmn/ZfeKbBP5c7a6r3GDXeYmrerr3aomw31uXM1x/ttd ChLgyBnyrmz0kJqv0dA4d0joj26HBrRmIykimFIfcP48DTaQ6RYLAHdceF8XdAUE8jsb EucvWp8+X5M36OjSNcleUvrfkBrPyBaP7T85pVsvD7Oy3R7i+zViCFoDes/clK0EojJB L3vw== X-Gm-Message-State: ALyK8tKa6qNTXooVdAOj8oGWSBrAY2hVLlgf9Q8xveyirq2oHKhHBmKswuLtFC6/jCXUOo39h6HdKYdOkzgVow== X-Received: by 10.13.237.68 with SMTP id w65mr18890613ywe.128.1468993407788; Tue, 19 Jul 2016 22:43:27 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.64.82 with HTTP; Tue, 19 Jul 2016 22:42:58 -0700 (PDT) In-Reply-To: <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> From: Hugo Krawczyk Date: Wed, 20 Jul 2016 01:42:58 -0400 X-Google-Sender-Auth: gSQFjxQdMGyuTlSMbndHChLTG3I Message-ID: To: Antoine Delignat-Lavaud Content-Type: multipart/alternative; boundary=94eb2c0887443fae4505380aaee7 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" , Markulf Kohlweiss Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 05:43:35 -0000 --94eb2c0887443fae4505380aaee7 Content-Type: text/plain; charset=UTF-8 Without taking a position on the implementation issues, I am in favor of Option A with a dedicated context value (and an explicit name "PSK Context") as this makes clear the function of this value. Relying in Finished makes it more fragile and open to be dropped in the future when its binding role is "forgotten" or when deriving some other protocol or variant. Also, I insist on the need to remark about the need for collision resistance of any value with a binding functionality. If this value is produced with HKDF (or HMAC as in he case of Finished) the need for collision resistance is not explicit and can lead to truncation (which is perfectly fine when just deriving keys or when used with a regular PRF functionality). Actually, I would suggest that for any such value, we add "collision resistance" to the label for that derivation - this would apply to resumption/PSK context and to Exporter key (and possibly others) Hugo On Tue, Jul 19, 2016 at 10:45 AM, Antoine Delignat-Lavaud < antoine@delignat-lavaud.fr> wrote: > Dear all, > > Here is an extended summary of the early Finished / resumption context > discussion at the WG. > > 1. Signature forwarding with external PSK > > Currently, resumption context is only defined for resumption-based PSK, > which means that external PSKs are not protected against transcript > synchronization attacks. > > At a high level, this means that there is no crypographic binding between > the handshake log (what is signed for authentication) and the PSK used in > the key exchange. > In the resumption case, the resumption context fills this role (which is > the > reason why it was introduced); however, all external PSKs currently have > their resumption context set to 0 (and thus, all logs are equivalent w.r.t. > all non-resumption PSK). > Since the handshake log is what get signed during certificate-based > authentication, the lack of binding > means that a signature from a session s1 can be used in a session s2 as > long > as the PSK identifier are the same, which is a very weak constraint. > > Before Cas Cremer's paper, this was particularly bad because the Finished > (which is bound cryptographically to the PSK) was not part of the handshake > log; therefore, all signatures could potentially be replayed. > However, even though Finished are now part of the log, the server signature > in PSK 1-RTT remains vulnerable (because the log is then ClientHello, > ServerHello, Certificate and thus has no Finished message to save us from > transcript synchronization). For those of you who were at TRON, you may > remember that Karthik made this point quite clearly in his talk (he even > proposed to swap CV and Finished for this very reason!). > > An attack against external PSKs easily follows: we assume that an attacker > A > wants to impersonate a server S to some > IoT-like client C that can only do pure PSK for key exchange. > > 1. C registers to A under the PSK identifier Xc. The PSK between C and A is > Kca > 2. A, acting as a client, registers to S under the same identifier Xc. The > PSK between A and S is Kas > 3. C connects to A using (Xc, Kca). A forwards the ClientHello to S > 4. S sends back ServerHello, [EE, Cert(S), CertVerify, Finished]_hs where > hs > depends on Kas and the log [ClientHello, ServerHello] > 5. A forwards ServerHello from S to A and re-encrypts [EE, Cert(S), > CertVerify] under hs' which depends on Kca and [ClientHello, ServerHello] > 6. Since all logs are synchronized and nothing in the CertVerify depends on > Kca or Kas, C authenticates A as S. > > 2. Proposals to bind log and PSK > > As pointed out by Karthik months ago (and by myself years ago, in the > context of Triple Handshake), implicit authentication (such as PSK or > resumption) is difficult to mix correctly with transcript-based signatures. > > We have considered several ways to ensure uniform security for all PSK > modes. > The simplest solution (let's call it option A) is to rely on the draft 13 > resumption context infrastructure also in the case of external PSK. > Put it simply, externally-provided PSKs are treated as if they were > resumption master secrets: if K is the external key, we first compute > Ek = extract(K, 0), then PSK=expand(Ek, "external psk") and RC=expand(Ek, > "external psk context"). > Resumption context is renamed PSK context and PSK and RC are used as in the > current draft13 key schedule. > > While option A does the job, we think it is over-complicated, as we observe > that the early finished can actually play exactly the same role as the > current resumption context (saving the concatenation with rc in every > expansion with an handshake log). > > As an option B, we propose to always include an early finished in the log, > regardless of the handshake mode. > This comes with some complications that were discussed during the WG > meeting. Very notably, if this early finished is assumed to always come > after the ClientHello, then it must either a. mangled with the ClientHello > in an ugly way or b.send on the wire at all. > During the WG meeting, it was pointed out that regardless of whether a or b > is used, if the client proposes more than > one PSK, there needs to be more than one early finished. > > I have thought more about this, and I now agree that this makes option B > unpractical. > We are left with some more options: one would be to swap CertificateVerify > and Finished, as Karthik originally suggested. > Another would be to have a Finished immediately after ServerHello. Neither > of these alternatives is particularly appealing, > and it may be the case that option A is in fact the better choice. > > Best, > > Antoine > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: mardi 19 juillet 2016 15:46 > To: tls@ietf.org > Subject: [TLS] Resumption Contexts and 0-RTT Finished > > Thinking about this... > > One option would be like 2 on the slides (the overstriked one!), except: > > - The message is synthethized, not actually sent on wire (but still > logged). > - It only happens after the last ClientHello. > - It uses the actual PSK, even if not #0. > > > Maybe I should have listened to the talk more carefully, but the reason I > got for overstriking the second option was that it is unimplementable in > practice. > > > Of course, dunno if the changes would actually fix the problems with PSK > contexts... > > > > -Ilari > > _______________________________________________ > 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 > --94eb2c0887443fae4505380aaee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Without taking a position on the implementation= issues, I am in favor of Option A with a dedicated context value (and an e= xplicit name "PSK Context") as this makes clear the function of t= his value. Relying in Finished makes it more fragile and open to be dropped= in the future when its binding role is "forgotten" or when deriv= ing some other protocol or variant.

Al= so, I insist on the need to remark about the need for collision resistance = of any value with a binding functionality. If this value is produced with H= KDF (or HMAC as in he case of Finished) the need for collision resistance i= s not explicit and can lead to truncation (which is perfectly fine when jus= t deriving keys or when used with a regular PRF functionality).

Actually, I would suggest that for any such value= , we add "collision resistance" to the label for that derivation = - this would apply to resumption/PSK context and to Exporter key (and possi= bly others)

Hugo=C2=A0

On Tue, Jul 19, 2016 = at 10:45 AM, Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr<= /a>> wrote:
Dear all,

Here is an extended summary of the early Finished / resumption context
discussion at the WG.

1. Signature forwarding with external PSK

Currently, resumption context is only defined for resumption-based PSK,
which means that external PSKs are not protected against transcript
synchronization attacks.

At a high level, this means that there is no crypographic binding between the handshake log (what is signed for authentication) and the PSK used in the key exchange.
In the resumption case, the resumption context fills this role (which is th= e
reason why it was introduced); however, all external PSKs currently have their resumption context set to 0 (and thus, all logs are equivalent w.r.t.=
all non-resumption PSK).
Since the handshake log is what get signed during certificate-based
authentication, the lack of binding
means that a signature from a session s1 can be used in a session s2 as lon= g
as the PSK identifier are the same, which is a very weak constraint.

Before Cas Cremer's paper, this was particularly bad because the Finish= ed
(which is bound cryptographically to the PSK) was not part of the handshake=
log; therefore, all signatures could potentially be replayed.
However, even though Finished are now part of the log, the server signature=
in PSK 1-RTT remains vulnerable (because the log is then ClientHello,
ServerHello, Certificate and thus has no Finished message to save us from transcript synchronization). For those of you who were at TRON, you may
remember that Karthik made this point quite clearly in his talk (he even proposed to swap CV and Finished for this very reason!).

An attack against external PSKs easily follows: we assume that an attacker = A
wants to impersonate a server S to some
IoT-like client C that can only do pure PSK for key exchange.

1. C registers to A under the PSK identifier Xc. The PSK between C and A is=
Kca
2. A, acting as a client, registers to S under the same identifier Xc. The<= br> PSK between A and S is Kas
3. C connects to A using (Xc, Kca). A forwards the ClientHello to S
4. S sends back ServerHello, [EE, Cert(S), CertVerify, Finished]_hs where h= s
depends on Kas and the log [ClientHello, ServerHello]
5. A forwards ServerHello from S to A and re-encrypts [EE, Cert(S),
CertVerify] under hs' which depends on Kca and [ClientHello, ServerHell= o]
6. Since all logs are synchronized and nothing in the CertVerify depends on=
Kca or Kas, C authenticates A as S.

2. Proposals to bind log and PSK

As pointed out by Karthik months ago (and by myself years ago, in the
context of Triple Handshake), implicit authentication (such as PSK or
resumption) is difficult to mix correctly with transcript-based signatures.=

We have considered several ways to ensure uniform security for all PSK
modes.
The simplest solution (let's call it option A) is to rely on the draft = 13
resumption context infrastructure also in the case of external PSK.
Put it simply, externally-provided PSKs are treated as if they were
resumption master secrets: if K is the external key, we first compute
Ek =3D extract(K, 0), then PSK=3Dexpand(Ek, "external psk") and R= C=3Dexpand(Ek,
"external psk context").
Resumption context is renamed PSK context and PSK and RC are used as in the=
current draft13 key schedule.

While option A does the job, we think it is over-complicated, as we observe=
that the early finished can actually play exactly the same role as the
current resumption context (saving the concatenation with rc in every
expansion with an handshake log).

As an option B, we propose to always include an early finished in the log,<= br> regardless of the handshake mode.
This comes with some complications that were discussed during the WG
meeting. Very notably, if this early finished is assumed to always come
after the ClientHello, then it must either a. mangled with the ClientHello<= br> in an ugly way or b.send on the wire at all.
During the WG meeting, it was pointed out that regardless of whether a or b=
is used, if the client proposes more than
one PSK, there needs to be more than one early finished.

I have thought more about this, and I now agree that this makes option B unpractical.
We are left with some more options: one would be to swap CertificateVerify<= br> and Finished, as Karthik originally suggested.
Another would be to have a Finished immediately after ServerHello. Neither<= br> of these alternatives is particularly appealing,
and it may be the case that option A is in fact the better choice.

Best,

Antoine

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Ilari Liusvaara
Sent: mardi 19 juillet 2016 15:46
To: tls@ietf.org
Subject: [TLS] Resumption Contexts and 0-RTT Finished

Thinking about this...

One option would be like 2 on the slides (the overstriked one!), except:
- The message is synthethized, not actually sent on wire (but still
=C2=A0 logged).
- It only happens after the last ClientHello.
- It uses the actual PSK, even if not #0.


Maybe I should have listened to the talk more carefully, but the reason I got for overstriking the second option was that it is unimplementable in practice.


Of course, dunno if the changes would actually fix the problems with PSK contexts...



-Ilari

_______________________________________________
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

--94eb2c0887443fae4505380aaee7-- From nobody Wed Jul 20 00:52:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F212D1B3 for ; Tue, 19 Jul 2016 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPnKcpnFRW-l for ; Tue, 19 Jul 2016 12:55:12 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 2243212D7A4 for ; Tue, 19 Jul 2016 12:55:11 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so39593459wme.1 for ; Tue, 19 Jul 2016 12:55:11 -0700 (PDT) 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; bh=E/TJXeHDfZ279AmWGLZI90vOGQ7qD4n1ZR7hNPUL6nU=; b=N/Nu2YNI9zbUSDDqe23mHHifGgGLefjKlVWP6G9GFLmHY47F+8lqTQ8FmiyXaFnJ0a Sc09HVPAMijTvjPxdfd7jv8ciOLyiuiMaXhyTthzY/eD/YfK2vJxbEEPTYoaI3LyWzA5 CsfmlE/d8iHHNfKhAGqfE27MaIfysZC2Z0EY1TGlNYb2Kvjg1Kyh0raCnjYZA/Hd518P rWsSRFaeBm/UGfmaf0yQ1NxRwMHVRnCjG03JT6pkICoeYid3oAV52w1V9kAxLMm7GFlz xXPxg0GBjEoUkl7A5Vs8BOCzOrNcGnQlmYrepc1lhMSVJGI+O2is60e30bt2dYoGRjc1 RgBA== 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; bh=E/TJXeHDfZ279AmWGLZI90vOGQ7qD4n1ZR7hNPUL6nU=; b=gpJj5M/sPNFCbBLP1FjaPUEedBvNKPK/CLSNvfZ7uvdeE4jX7T/uy4rjbWgWO2UYWt m8LtzMn4pAYbOOEEg6VDMVK6rVeT74HX+8EW8ZT2DuBHJlpaei+mXNtVwaAlV2BRjMej mkjYIrCLM4NdkrJS5RdN7PPrUmeeN/QPkmPlpDIMQMLcRi/AAhaasFc6rNP/o9Maf1B0 OCO/D9ZxYunojNx77jAeZjdzHqbZLljPZpiy2ipTQF33JoQKSPsW+bKOeDd5SnlI14vP uu182UQ1vQJoXbpu7yWBH7ybO4rMtOgYF9yVNWx18ZaL/BqHO11dBkY1T6bFcYSK4cuQ 5X2Q== X-Gm-Message-State: ALyK8tIxTdz1/QKyDaY6s6838aqWvHuzqiEAI8aGwDfxuHMogL0Vi7R9CDOOLo4gYCA8hTufp3NblStEfDe1ig== X-Received: by 10.28.232.145 with SMTP id f17mr6310981wmi.15.1468958109583; Tue, 19 Jul 2016 12:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.99 with HTTP; Tue, 19 Jul 2016 12:55:09 -0700 (PDT) In-Reply-To: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> References: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> From: Robert Cragie Date: Tue, 19 Jul 2016 20:55:09 +0100 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=001a11466d9a5001a10538027610 Archived-At: X-Mailman-Approved-At: Wed, 20 Jul 2016 00:52:00 -0700 Cc: tls@ietf.org Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:55:14 -0000 --001a11466d9a5001a10538027610 Content-Type: text/plain; charset=UTF-8 Hi Dan, What you say regarding the NamedCurve/EllipticCurveList is of course right. Whether this constitutes a fundamental change to TLS is debatable. The aim was never to propose this as a cipher suite for general inclusion in a range of supported cipher suites in a browser/server scenario as is pointed out in various places in the draft. The aim was to reuse TLS (a well-known and widely implemented protocol) as a vehicle to support the ECJ-PAKE method and to deliberately constrain the implementation parameters a priori. To me, that does not make this a proprietary protocol and the ease by which existing TLS implementations have been adapted to support TLS-ECJ-PAKE. I guess it does raise the wider question of "what is TLS" though and whether this approach flouts conventional thinking about TLS (which, IMHO, it doesn't). Robert On 18 July 2016 at 11:06, Dan Harkins wrote: > > Hi Robert, > > This draft moves the NamedCurve/EllipticCurveList into the > ClientHello, and since the client sends X1 and ZKP(X1) in the > ClientHello it means that is going to be a list of 1. It basically > moves the client's key exchange portion from ClientKeyExchange into > ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE > then that's the only thing it can offer and the parameters of > that exchange are all selected by the client, not the server. > > This is a fundamental change to TLS. If it's going to be offered, > it's the only thing that can be offered and therefore the only thing > that can be used. Seems like for a deployment either it's never used > or it's the only thing used and that makes it sort of a proprietary > protocol, not TLS. > > Dan. > > On Thu, June 16, 2016 2:51 am, Robert Cragie wrote: > > I would like to ask the working group for comments on the TLS-ECJ-PAKE > > draft: > > > > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 > > > > Some brief notes: > > > > * This intended status is informational. > > * The draft is based on TLS/DTLS 1.2 as the Thread group required basis > on > > existing RFCs wherever possible. For that reason and due to the WGs focus > > on TLS 1.3, I have understood from the chairs that it would not have > > received a great deal of attention from the WG, hence the intended status > > of informational. > > * The draft reflects the current use of the > TLS_ECJPAKE_WITH_AES_128_CCM_8 > > cipher suite in Thread (http://threadgroup.org/). > > * There is an experimental implementation in mbed TLS ( > > https://github.com/ARMmbed/mbedtls) > > * The Thread group would like to get IANA assignments for 4 cipher suite > > values and one ExtensionType value as soon as possible. > > * There are at least four independent implementations, which have been > > used > > in interop. testing over the last 18 months. > > * The security considerations recommend restriction of the use of this > > cipher suite to Thread and similar applications and recommends it should > > not be used with web browsers and servers (mainly due to the long > > discussions regarding the use of PAKEs on this and other mailing lists). > > > > Robert > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > --001a11466d9a5001a10538027610 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan,

What you sa= y regarding the NamedCurve/EllipticCurveList is of course right. Whether th= is constitutes a fundamental change to TLS is debatable. The aim was never = to propose this as a cipher suite for general inclusion in a range of suppo= rted cipher suites in a browser/server scenario as is pointed out in variou= s places in the draft. The aim was to reuse TLS (a well-known and widely im= plemented protocol) as a vehicle to support the ECJ-PAKE method and to deli= berately constrain the implementation parameters a priori. To me, that does= not make this a proprietary protocol and the ease by which existing TLS im= plementations have been adapted to support TLS-ECJ-PAKE. I guess it does ra= ise the wider question of "what is TLS" though and whether this a= pproach flouts conventional thinking about TLS (which, IMHO, it doesn't= ).

Robert

On 18 July 2016 at 11:06, Dan Harkins <dharkins@lounge.org&g= t; wrote:

=C2=A0 Hi Robert,

=C2=A0 This draft moves the NamedCurve/EllipticCurveList into the
ClientHello, and since the client sends X1 and ZKP(X1) in the
ClientHello it means that is going to be a list of 1. It basically
moves the client's key exchange portion from ClientKeyExchange into
ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE
then that's the only thing it can offer and the parameters of
that exchange are all selected by the client, not the server.

=C2=A0 This is a fundamental change to TLS. If it's going to be offered= ,
it's the only thing that can be offered and therefore the only thing that can be used. Seems like for a deployment either it's never used or it's the only thing used and that makes it sort of a proprietary
protocol, not TLS.

=C2=A0 Dan.

On Thu, June 16, 2016 2:51 am, Robert Cragie wrote:
> I would like to ask the working group for comments on the TLS-ECJ-PAKE=
> draft:
>
> https://tools.ietf.org/html/draft-cragie= -tls-ecjpake-00
>
> Some brief notes:
>
> * This intended status is informational.
> * The draft is based on TLS/DTLS 1.2 as the Thread group required basi= s on
> existing RFCs wherever possible. For that reason and due to the WGs fo= cus
> on TLS 1.3, I have understood from the chairs that it would not have > received a great deal of attention from the WG, hence the intended sta= tus
> of informational.
> * The draft reflects the current use of the TLS_ECJPAKE_WITH_AES_128_C= CM_8
> cipher suite in Thread (http://threadgroup.org/).
> * There is an experimental implementation in mbed TLS (
> https://github.com/ARMmbed/mbedtls)
> * The Thread group would like to get IANA assignments for 4 cipher sui= te
> values and one ExtensionType value as soon as possible.
> * There are at least four independent implementations, which have been=
> used
> in interop. testing over the last 18 months.
> * The security considerations recommend restriction of the use of this=
> cipher suite to Thread and similar applications and recommends it shou= ld
> not be used with web browsers and servers (mainly due to the long
> discussions regarding the use of PAKEs on this and other mailing lists= ).
>
> Robert
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--001a11466d9a5001a10538027610-- From nobody Wed Jul 20 02:20:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5410A12D0D3 for ; Wed, 20 Jul 2016 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2QB4HHEVqdG for ; Wed, 20 Jul 2016 02:20:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B2F12B004 for ; Wed, 20 Jul 2016 02:20:52 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 051D17F7BB for ; Wed, 20 Jul 2016 09:20:52 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6K9Ko8A018211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 05:20:51 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 20 Jul 2016 11:20:46 +0200 Message-ID: <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3020828.KfZDmd1KME"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 20 Jul 2016 09:20:52 +0000 (UTC) Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:20:56 -0000 --nextPart3020828.KfZDmd1KME Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 18 July 2016 15:08:03 CEST Hubert Kario wrote: > On Monday 18 July 2016 13:08:43 Hanno B=C3=B6ck wrote: > > * We don't have good data on the issue. The latest numbers I could find > >=20 > > came from Ivan Ristic in 2013 [4], and from David Benjamin we know he > > considers the problem to be large enough that version fallbacks are > > inevitable. That's far from good data. We also don't seem to have any > > public list of affected vendors, devices and webpages. >=20 > I'm running a test against the Alexa Top 1 million /right now/ using this > code: > https://github.com/jvehent/cipherscan/pull/109 >=20 > In general it's a rough check, i.e. it's only a check for client hello > version intolerance, irrespective of record layer version, ciphers or > extensions (it sends multiple probes, based on different clients and > then modified) >=20 > I've also added an Xmas-client hello message[1] that aims to trigger as > many intolerancies as possible, but it's mostly just to single out > some weirder servers. So I have partial results after scanning around 14 000 domains. The scanner was able to connect to 12 606 hosts that presented unexpired certificates signed by CA's in Mozilla root program. Of those: 93% support TLSv1.2 protocol (11807) a single one is intolerant to TLSv1.2 Client Hello 3.7% (469) are intolerant to TLSv1.3 Client Hello 4.4% (556) are intolerant to TLSv1.4 Client Hello (by intolerant, I mean, I was not able to connect to them with any hello message that looked like an IE, Chrome or Firefox Client Hello with just version changed or additionally some or all extensions removed) at the same time, 15.5% (1965) are intolerant to an "Xmas tree" Client Hello (one that includes many ciphers, few TLSv1.3 key shares, etc. bringing its size to something like 2800 bytes) 49% (6240) are intolerant to a Client Hello with no extensions but big number of ciphers that bring its size to 16388 bytes) 91.5% (11539) are intolerant to a Client Hello with no extensions but a number of ciphers that bring it well above single record layer limit (16.5KiB) so it looks to me like while we may gain a bit of compatibility by using extension based mechanism to indicate TLSv1.3, it looks to me like the 1RTT mechanism will uncover more bugs like the one in F5 accelerators (the 256-512 byte black hole) =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 Republic --nextPart3020828.KfZDmd1KME 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 iQIcBAABCgAGBQJXj0JuAAoJEJKo0bgB0vX1iLcP/2ZfuzNvq6i5T8tKD6lrbStE +2O+WW0m14azgH9J1d1IaOvnDwg3G4j7t4bMhx+zO8FVCE3gbX5ZPHWv38zoKcc6 NoGMqCvVTRjN0U1Z4qI+Y0E2FsGgeSSgOUQKA/ZPMKFhOqDbKgYGBCaVDYnexcRh iSjdQ/FuymhYvMmHRt9Ucfs6OyNXdMg7L6YopdsiwHWY45h8SJWy0BkSq09i2prq LqLJcmmi225r64ajhjP+bIRxWUAAoecEADJSb5jiprEAC9qGHEaSQptjzONnXK4u vhMwnsh+2AKRH2+sWJpmtZeNufjh8AcdP1ZoSSjK5yNiPkVwLoryFzTv7ZX9HOo0 v5BBcObueIPexO92g00Cpq2ppBVvKfBfGhDPupdZ9EJjz7uSnE01ztiG4snvcocO +sa+/RCaGIHpMw/Q6CHR2frHldkLsfNqQ1CZDOhCxkKdlw+2UWHCVV08lUQ/MzQK 2WO7K59z4UJxq8EAkB3XEHQ2eFkDpVguQ1FfGMiQocqleSHxDtXPVYfw5C+qgcmt /E1obpL7FXpdiIlNKXtClSea+HkqUKw0S/5jMIA+omHp9iG3OglZ/tjftJQJQOOu Wer9BlRrM9CVqRuBEbFx19NpHNoDvCP1Phr7e+hvDpqGoTN4FCjdAeCkQdZh+MXL SYS5rYxewvq1dO2X4GvN =olGh -----END PGP SIGNATURE----- --nextPart3020828.KfZDmd1KME-- From nobody Wed Jul 20 02:32:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E0128E18 for ; Wed, 20 Jul 2016 02:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9VMec9P3vrB for ; Wed, 20 Jul 2016 02:32:18 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A366812D811 for ; Wed, 20 Jul 2016 02:32:18 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id s63so39794356qkb.2 for ; Wed, 20 Jul 2016 02:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=toI/3JCaxJRCDPmxZ6zu+NhqyUB+Ot6OxeBOGrwtEzw=; b=VDtD/S0gskXRHFKr7r1rhJQ4+3Xo0enRoG1u1D/YD4riuHFdrAmzgViV7emMAeSbbc 3yYpxL+cjVlfcVuFZksLMH321/UDePIwXcWO6XnGHuRFaJrKtB3DkrXwKq1G/lnlo7dR 3UlYomxMHWKilxFmGePI4t67ekRYbSGwyq3wxN6ULyzi8NrJI1WVFXdwCIqszvRdsOsY k7Tl8UqDwSb01DjuGTMv0F8LmffAKZyu0H3p4dKNzM56OkntR78jiRBqYl14ZO924bMZ bZkYbSk8qCaJ6kXU6gKMMcSlllOaQkDeo6SCGyjODmikBlfRP7+Psb5gxGEl7wOsB5qU 0EBg== 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:cc; bh=toI/3JCaxJRCDPmxZ6zu+NhqyUB+Ot6OxeBOGrwtEzw=; b=MS1O11QldoVttKXxRKT+D2zPbnuhh2+It55GuiWItOrNnH2IAN/7EU0QsK/PZzBRTL RUbfTtgILQib1dZ1XAunRFj2dIrBUZYdZum7BwxY/rmTXYtyyRx19Ku7rBSRKv78Czdt 00Y1fT4hx2i6WpY9leGaY/alB2HFe7IsctoD0wOq+KPZOSHu+gXAsCYxEvigo3SWx+Bh sdxgmezCeMYZ4PE6G2Z17k0qHupEcHFsOcK4aE92awbpKVahdqo/tuSDojgtnw1/xMjA WjjPueutYWC64wnEo1prt4Tau/z7t0Sqa4CEOuHKavITl9k+HWAPc3P7pa6Y9Nl2xLpi Mt4A== X-Gm-Message-State: ALyK8tKWvv+pMJEdv2qc4EwK+uwnGwEA3wuWr+bN80is6sCggqdnsZDxWC7EMb6GwJkuT7qgQvQ5LKE5WZQO+g== X-Received: by 10.55.23.25 with SMTP id i25mr61034742qkh.142.1469007137836; Wed, 20 Jul 2016 02:32:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.75.84 with HTTP; Wed, 20 Jul 2016 02:31:58 -0700 (PDT) From: Joseph Salowey Date: Wed, 20 Jul 2016 11:31:58 +0200 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a114596a89fa70c05380de0b6 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] TLS WG Summary for IETF 96 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:32:21 -0000 --001a114596a89fa70c05380de0b6 Content-Type: text/plain; charset=UTF-8 The TLS working group met on Tuesday morning. We are continuing progress on TLS 1.3. Main discussion points included a change in the cipher suite model from a monolithic ID approach to a menu based approach. During the hackathon on Saturday we had 7 different TLS 1.3 implementations achieve interoperability to various degrees. We expect to have a draft (probably -16) that "freezes" the wire format at the end of next month available for broad review by the cryptographic and security modeling communities. We plan on holding working group last call before the next IETF. --001a114596a89fa70c05380de0b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The TLS working group met= on Tuesday morning. We are continuing progress on TLS 1.3. Main discussion= points included a change in the cipher suite model from a monolithic ID ap= proach to a menu based approach. During the hackathon on Saturday we had 7 = different TLS 1.3 implementations achieve interoperability to various degre= es. We expect to have a draft (probably -16) that "freezes" the w= ire format at the end of next month available for broad review by the crypt= ographic and security modeling communities. We plan on holding working grou= p last call before the next IETF. =C2=A0

--001a114596a89fa70c05380de0b6-- From nobody Wed Jul 20 03:01:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093012DAD1 for ; Wed, 20 Jul 2016 03:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8WW-Q3tyEQU for ; Wed, 20 Jul 2016 03:01:36 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C1212DA51 for ; Wed, 20 Jul 2016 03:01:36 -0700 (PDT) Received: from pc1 ([::ffff:89.15.236.146]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Wed, 20 Jul 2016 12:01:34 +0200 id 0000000000000029.00000000578F4BFE.000079B8 Date: Wed, 20 Jul 2016 12:01:25 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160720120125.43f61155@pc1> In-Reply-To: <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-31160-1469008894-0001-2" Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:01:44 -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-31160-1469008894-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 20 Jul 2016 11:20:46 +0200 Hubert Kario wrote: > so it looks to me like while we may gain a bit of compatibility by > using extension based mechanism to indicate TLSv1.3, Just quick: This was discussed yesterday, David Benjamin had an interesting proposal, but it was largely met with resistance. So from the WG discussion yesterday I had the impression that we will most likely stay with the existing clienthello version mechanism. While that will cause us more trouble, it's probably the cleaner option anyway. So we definitely should continue investigating version intolerance and tell people to fix their stuff. I'm now also collecting some data and have some preliminary suspicion on affected devices. My numbers roughly match yours that we are in the more or less 3% area of 1.3 intolerance. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-31160-1469008894-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXj0v1AAoJEKWIAHK7tR5CsggQAIK/nRF8MXxRzUEWejReCPHS lKl2kMUTCDSvChbhoddN856+O4Ba70IfAbAL/ESxl6MJyKDW3TK3cRPPxIDGho5O GfXH4wV/RWrsha2Y+KtR+bdpfwWQMyOyjCF7Yrk9/ipHjAk68MirIQ53p5bYanHp RhXnGNvXq377uLkNAzFfnisYhEahGzXPusfbcG8pSHLFVxV9L0LlpAiR/+plMfVx SglG8nHlw/7vDVD3SPnoMq1h1zGAXc4boY5diWj04WgoumirX5pOpx86QlJutL17 ekP/SXO5Zp/v8OV1/Fwn3gwi0iB+TUUcrSm3NBYzL3CI9NB7r9i1TYGZpCrH78G6 qhOVG/qJE8/r000ZctYAJmktHb9kBtj/LW4ehYtnMbv87WOr2KyiVDU2vA9peqH7 EluJ52YmuQtPM3X2pIUC8i7/st01G6dbu1+/gvb5MtlpaitEYu/t9lv5U/Gbgo16 YCX/B7lW2BfzMnPj9O2bUzXMAGDQ8Ow4nz+h7uRASacl+loSxu1R9LeS38vJ4Uwn toGeiF3Sk9zJQXso6eZJus2Ulc6iF2Oa8rHX2PQo6kjc4J+32tYXxJmFmNgkdHqz P8EzpPALF7R2cMKH+xFj9Jwkc5TezMmfRAOp7A7nsxgEwUXHBJlqaHVNbo3+3DwT Vy2Vo1jk1s1RifNyvH6C =xvlS -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-31160-1469008894-0001-2-- From nobody Wed Jul 20 03:14:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA96412D0FC for ; Wed, 20 Jul 2016 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MRdyA47z4bz for ; Wed, 20 Jul 2016 03:14:04 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC3812D0A5 for ; Wed, 20 Jul 2016 03:14:04 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 3rvXnQ4sDNz25Nc; Wed, 20 Jul 2016 12:14:02 +0200 (CEST) X-purgate-ID: 152705::1469009642-0000299C-BBF951AC/0/0 X-purgate-size: 1612 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rvXnQ0Y9lzkwBl; Wed, 20 Jul 2016 12:14:02 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 09EC41A504; Wed, 20 Jul 2016 12:14:02 +0200 (CEST) In-Reply-To: <20160720120125.43f61155@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Wed, 20 Jul 2016 12:14:01 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 10:14:06 -0000 Hanno B=F6ck wrote: Checking application/pgp-signature: FAILURE > Hubert Kario wrote: >=20 >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, Forget TLS extensions, forget ClientHello.client_version. Both in fundamentally broken, and led to Web Browsers coming up with the "downgrade dance" that is target&victim of the POODLE attack. We know fairly reliably what kind of negotiation works just fine: TLS cipher suite codepoints. Please define *ALL* TLSv1.3-specific cipher suites to a) indicate that the client offering it supports (at least) TLSv1.3 b) that indication (a) will override any lower ClientHello.client_version that may have been used for backwards compatibility. >=20 > I'm now also collecting some data and have some preliminary > suspicion on affected devices. My numbers roughly match yours that we > are in the more or less 3% area of 1.3 intolerance. The TLSv1.2 version intolerance is already a huge problem, and I'm not seeing it go away. Acutally Microsoft created an awfully large installed base of TLSv1.2-intolerant servers (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2). I would really like to see the TLS WG improving the situation rather than keep sitting on its hands. The problem has been well-known since 2005. And the "downgrade dance" was a predictably lame approach to deal with the situation, because it completely subverts/evades the cryptographic protection of the TLS handshake. -Martin From nobody Wed Jul 20 03:18:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1151E12DB09 for ; Wed, 20 Jul 2016 03:18:00 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVuDGbVRFboJ for ; Wed, 20 Jul 2016 03:17:57 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8612DB38 for ; Wed, 20 Jul 2016 03:17:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4E9BE1FE0240; Wed, 20 Jul 2016 03:17:46 -0700 (PDT) Received: from 31.133.162.219 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 20 Jul 2016 03:17:46 -0700 (PDT) Message-ID: <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net> In-Reply-To: References: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> Date: Wed, 20 Jul 2016 03:17:46 -0700 (PDT) From: "Dan Harkins" To: "Robert Cragie" 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] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:18:00 -0000 Hi Robert, Sorry for the confusing comments. There are 2 but one follows because of the other. The first comment concerns the fact that J-PAKE is a 4 message handshake. This is different than other PAKES like EKE, SPAKE2, dragonfly, or SRP which all establish their shared key in a single 2 message exchange. A 2 message exchange falls into the TLS handshake elegantly, e.g.: - figure 1 in https://tools.ietf.org/html/rfc5054#page-5 and - figure 1 in https://tools.ietf.org/html/draft-ietf-tls-pwd-07#page-10 as opposed to: - figure 1 in https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00#page-7 where as you are making the TLS "Hello phase" into a "Hello plus one-half of the key exchange phase". This is my comment about this being a fundamental change to TLS. Now the 2nd comment that follows out of the 1st is that by overloading the Hello Phase to include half the key exchange phase you remove all ability to do negotiation. When TLS-ECJ-PAKE is used it is the only thing that can be used. The client can only offer it and it can only talk to servers that support it. Which is why my 2nd comment is that this is fundamentally a proprietary protocol. You don't need a cipher suite assignment for this because you have no ability to negotiate it. You could make it 0xFF,0xFC-FF (reserved for private use) and have no issues. You will never have interop issues with some other TLS-like private protocol that also uses 0xFF,0xFC-FF because you'll never talk to them. Your TLS-ECJ-PAKE client always and only talks to your TLS-ECJ-PAKE server so your private assignment of the private use cipher suites cannot conflict with any other private assignment. Proprietary protocols don't need cipher suite assignments and this is a proprietary extension of TLS. regards, Dan. On Tue, July 19, 2016 12:55 pm, Robert Cragie wrote: > Hi Dan, > > What you say regarding the NamedCurve/EllipticCurveList is of course > right. > Whether this constitutes a fundamental change to TLS is debatable. The aim > was never to propose this as a cipher suite for general inclusion in a > range of supported cipher suites in a browser/server scenario as is > pointed > out in various places in the draft. The aim was to reuse TLS (a well-known > and widely implemented protocol) as a vehicle to support the ECJ-PAKE > method and to deliberately constrain the implementation parameters a > priori. To me, that does not make this a proprietary protocol and the ease > by which existing TLS implementations have been adapted to support > TLS-ECJ-PAKE. I guess it does raise the wider question of "what is TLS" > though and whether this approach flouts conventional thinking about TLS > (which, IMHO, it doesn't). > > Robert > > On 18 July 2016 at 11:06, Dan Harkins wrote: > >> >> Hi Robert, >> >> This draft moves the NamedCurve/EllipticCurveList into the >> ClientHello, and since the client sends X1 and ZKP(X1) in the >> ClientHello it means that is going to be a list of 1. It basically >> moves the client's key exchange portion from ClientKeyExchange into >> ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE >> then that's the only thing it can offer and the parameters of >> that exchange are all selected by the client, not the server. >> >> This is a fundamental change to TLS. If it's going to be offered, >> it's the only thing that can be offered and therefore the only thing >> that can be used. Seems like for a deployment either it's never used >> or it's the only thing used and that makes it sort of a proprietary >> protocol, not TLS. >> >> Dan. >> >> On Thu, June 16, 2016 2:51 am, Robert Cragie wrote: >> > I would like to ask the working group for comments on the TLS-ECJ-PAKE >> > draft: >> > >> > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 >> > >> > Some brief notes: >> > >> > * This intended status is informational. >> > * The draft is based on TLS/DTLS 1.2 as the Thread group required >> basis >> on >> > existing RFCs wherever possible. For that reason and due to the WGs >> focus >> > on TLS 1.3, I have understood from the chairs that it would not have >> > received a great deal of attention from the WG, hence the intended >> status >> > of informational. >> > * The draft reflects the current use of the >> TLS_ECJPAKE_WITH_AES_128_CCM_8 >> > cipher suite in Thread (http://threadgroup.org/). >> > * There is an experimental implementation in mbed TLS ( >> > https://github.com/ARMmbed/mbedtls) >> > * The Thread group would like to get IANA assignments for 4 cipher >> suite >> > values and one ExtensionType value as soon as possible. >> > * There are at least four independent implementations, which have been >> > used >> > in interop. testing over the last 18 months. >> > * The security considerations recommend restriction of the use of this >> > cipher suite to Thread and similar applications and recommends it >> should >> > not be used with web browsers and servers (mainly due to the long >> > discussions regarding the use of PAKEs on this and other mailing >> lists). >> > >> > Robert >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> > From nobody Wed Jul 20 03:57:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BECE12D594 for ; Wed, 20 Jul 2016 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2N257riOeUI for ; Wed, 20 Jul 2016 03:57:43 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89312D0F7 for ; Wed, 20 Jul 2016 03:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 6EBC51260 for ; Wed, 20 Jul 2016 13:57:41 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 9DTzHWutcgdJ for ; Wed, 20 Jul 2016 13:57:41 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1FD9C2310 for ; Wed, 20 Jul 2016 13:57:41 +0300 (EEST) Date: Wed, 20 Jul 2016 13:57:36 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160720105736.GA22387@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:57:46 -0000 On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote: > > So I have partial results after scanning around 14 000 domains. > The scanner was able to connect to 12 606 hosts that presented unexpired > certificates signed by CA's in Mozilla root program. > > Of those: > 93% support TLSv1.2 protocol (11807) > a single one is intolerant to TLSv1.2 Client Hello > 3.7% (469) are intolerant to TLSv1.3 Client Hello > 4.4% (556) are intolerant to TLSv1.4 Client Hello > > (by intolerant, I mean, I was not able to connect to them with any hello > message that looked like an IE, Chrome or Firefox Client Hello with just > version changed or additionally some or all extensions removed) > > at the same time, 15.5% (1965) are intolerant to an "Xmas tree" Client > Hello (one that includes many ciphers, few TLSv1.3 key shares, etc. bringing > its size to something like 2800 bytes) Wonder how big part of the difference is due to steps (eg. 1024 and 2048 bytes) in between and how much is due to the extra extensions or cihpers. > 49% (6240) are intolerant to a Client Hello with no extensions but > big number of ciphers that bring its size to 16388 bytes) > 91.5% (11539) are intolerant to a Client Hello with no extensions > but a number of ciphers that bring it well above single record layer limit > (16.5KiB) Wonder how much of that is again size thresholds (in Ciphersuites and in total ClientHello size) and how much is fragmenting the Client Hello to multiple fragments... -Ilari From nobody Wed Jul 20 04:14:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AE012DB9D for ; Wed, 20 Jul 2016 04:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS0zHZ7sIvp4 for ; Wed, 20 Jul 2016 04:14:49 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5112D0CC for ; Wed, 20 Jul 2016 04:14:49 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BBF643F4005; Wed, 20 Jul 2016 11:14:48 +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 A5C1F3F4003; Wed, 20 Jul 2016 11:14:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469013288; bh=S4u+1BP0mrF7TeQJ/QcnRGuh+/QDDlP74sTTyBU2G1k=; l=341; h=From:To:CC:Date:References:In-Reply-To:From; b=R7ZDpnXs8dZtQVLll7GqdRRXa+JljQYeOx4LYVrjbK1S2q1fW8NfL4LCTeM1QFxll 7MJ+GJUye+qTpwCd+lrjH/FbRWEOjwVHhs9UBltT6N4aUxCmEArg7/BhXjg+CAYnDn HIbZnH3GKwLOAcIolcgbpv/FfYFGsM4M7YmPhMRs= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A202F1FC94; Wed, 20 Jul 2016 11:14:48 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 20 Jul 2016 07:14:47 -0400 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.1178.4; Wed, 20 Jul 2016 07:14:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 20 Jul 2016 07:14:47 -0400 From: "Salz, Rich" To: Dan Harkins , Robert Cragie Thread-Topic: [TLS] Comments on TLS-ECJ-PAKE draft Thread-Index: AQHR4NwZGP9qkl6OtUulnNHFW9cxUqAgcD2AgADxBAD//8xRMA== Date: Wed, 20 Jul 2016 11:14:47 +0000 Message-ID: <6d5f109ecebc4ca4ab1d1da259dc1540@usma1ex-dag1mb1.msg.corp.akamai.com> References: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net> In-Reply-To: <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net> 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.152.111] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:14:51 -0000 So Dan, If your reasoning is correct, it seems like an individual submission "using= TLS for ECJ-PAKE" seems more appropriate than a TLS WG document or any cod= epoint assignment (since as you say they can use the private-use one). /r$=20 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Jul 20 05:36:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E9C12D187 for ; Wed, 20 Jul 2016 05:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmtd1gP4bNTa for ; Wed, 20 Jul 2016 05:36:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429AE12D552 for ; Wed, 20 Jul 2016 05:36:09 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA75963321; Wed, 20 Jul 2016 12:36:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KCa7Jk031321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:36:08 -0400 From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Wed, 20 Jul 2016 14:36:06 +0200 Message-ID: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2058958.CnHea5GNph"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 20 Jul 2016 12:36:08 +0000 (UTC) Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:36:12 -0000 --nextPart2058958.CnHea5GNph Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 20 July 2016 12:14:01 CEST Martin Rex wrote: > Hanno B=C3=B6ck wrote: >=20 > Checking application/pgp-signature: FAILURE >=20 > > Hubert Kario wrote: > >> so it looks to me like while we may gain a bit of compatibility by > >> using extension based mechanism to indicate TLSv1.3, >=20 > Forget TLS extensions, forget ClientHello.client_version. > Both in fundamentally broken, and led to Web Browsers coming up > with the "downgrade dance" that is target&victim of the POODLE attack. >=20 > We know fairly reliably what kind of negotiation works just fine: > TLS cipher suite codepoints. please re-read my mail, they don't: 49% (6240) are intolerant to a Client Hello with no extensions but big number of ciphers that bring its size to 16388 bytes) 91.5% (11539) are intolerant to a Client Hello with no extensions but a number of ciphers that bring it well above single record layer limit (16.5KiB) > > I'm now also collecting some data and have some preliminary > > suspicion on affected devices. My numbers roughly match yours that we > > are in the more or less 3% area of 1.3 intolerance. >=20 > The TLSv1.2 version intolerance is already a huge problem, > and I'm not seeing it go away. Acutally Microsoft created an > awfully large installed base of TLSv1.2-intolerant servers > (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R= 2). >=20 >=20 > I would really like to see the TLS WG improving the situation > rather than keep sitting on its hands. The problem has been well-known > since 2005. And the "downgrade dance" was a predictably lame approach > to deal with the situation, because it completely subverts/evades the > cryptographic protection of the TLS handshake. it's not IETF's fault that the implementers add unspecified by IETF restrictions and limitations to parsers of Client Hello messages or that they can't handle handshake messages split over multiple record layer messages, despite the standard being very explicit in that they MUST support this =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 Republic --nextPart2058958.CnHea5GNph 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 iQIcBAABCgAGBQJXj3A2AAoJEJKo0bgB0vX1uzwQAJ147mJ2PKSzB9hsE/QVAeR/ YQst+1qj/XvPfVd0jyn/w3yHW8ZCdkAeFevoMF9rADvHU+WpVBDTYyJ0I/SJ5fRB 1ppsVCW5oSB2uS5P1At3fsSZgP+hK96Jt7b7tQCtQleZDvS7mc6kc9jD+KdGENHl bQ+/KLrYZKLCY61rMefkTskW+HMGAlol6dW0pQeXpeW76XrWLweOo/U+21zF1gTe fI+sIbfa+U/vvxoLa3AS/FicPmYulFjQdu7Hd3UVZa+DL+rwmMV/A8FcAPGMm1Rh bT0ex16XXoy4JcHg2FuJUabARzdL1Oe+iIBaaUfIlsiGhw4bw3cMrrIRSB3wg6gY 0olVkbin9qAZHTuYBAfgPhkfGq1kd84G7lwPfqVF2BSdfSEpYC9oCiTgdqmtDlUd LMhgiQP1kh7XHWRUIHRQ/jvbThvZlMZqKfVdzX97StJ4sMaGZEUxoYv475nrOREu WymvWm8oVcpE04+00vWHnGEDlPOftl6Wh1HB/7hTCaO7fu8eO50lz/PdQkT24ncw LFvaUcTEr5aSQEhb7BvNL9CZI5onSbrZr+g/kXq+jeUDBaL/DDStQAMgZyCUXETM Jx5vxrC1vhkgKuabFQFV9joIrCy/ZgeyHeGnZcAInUFtSTc5a0+jkWJEzTzTfySA Ss2wqbBL9FDDCbYSbqF2 =UZLM -----END PGP SIGNATURE----- --nextPart2058958.CnHea5GNph-- From nobody Wed Jul 20 05:47:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D5C12D6AA for ; Wed, 20 Jul 2016 05:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO4M3lIplPwE for ; Wed, 20 Jul 2016 05:47:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F3612D58A for ; Wed, 20 Jul 2016 05:47:05 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA777796F4; Wed, 20 Jul 2016 12:47:04 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KCl25s005131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:47:03 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 20 Jul 2016 14:46:51 +0200 Message-ID: <12453699.ubOGoNYMcu@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <20160720105736.GA22387@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718130843.0320d43f@pc1> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720105736.GA22387@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2130319.uUDHmnaQPA"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 20 Jul 2016 12:47:04 +0000 (UTC) Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:47:08 -0000 --nextPart2130319.uUDHmnaQPA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 20 July 2016 13:57:36 CEST Ilari Liusvaara wrote: > On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote: > > So I have partial results after scanning around 14 000 domains. > > The scanner was able to connect to 12 606 hosts that presented unexpired > > certificates signed by CA's in Mozilla root program. > >=20 > > Of those: > > 93% support TLSv1.2 protocol (11807) > > a single one is intolerant to TLSv1.2 Client Hello > > 3.7% (469) are intolerant to TLSv1.3 Client Hello > > 4.4% (556) are intolerant to TLSv1.4 Client Hello > >=20 > > (by intolerant, I mean, I was not able to connect to them with any hello > > message that looked like an IE, Chrome or Firefox Client Hello with just > > version changed or additionally some or all extensions removed) > >=20 > > at the same time, 15.5% (1965) are intolerant to an "Xmas tree" Client > > Hello (one that includes many ciphers, few TLSv1.3 key shares, etc. > > bringing its size to something like 2800 bytes) >=20 > Wonder how big part of the difference is due to steps (eg. 1024 and > 2048 bytes) in between and how much is due to the extra extensions or > cihpers. >=20 > > 49% (6240) are intolerant to a Client Hello with no extensions but > > big number of ciphers that bring its size to 16388 bytes) > > 91.5% (11539) are intolerant to a Client Hello with no extensions > > but a number of ciphers that bring it well above single record layer li= mit > > (16.5KiB) >=20 > Wonder how much of that is again size thresholds (in Ciphersuites and > in total ClientHello size) and how much is fragmenting the Client > Hello to multiple fragments... yes, that's something I'd like to figure out too, but I was thinking of using a bisect approach to do it, so it will be more complex to do =3D> I won't do this for this month's scan patches welcome, though :) =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 Republic --nextPart2130319.uUDHmnaQPA 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 iQIcBAABCgAGBQJXj3K7AAoJEJKo0bgB0vX1tagP/1b4ial3d55Gdr2vKt4I0Zd7 qK4qDXxL9wgG8vnlIGS5GDep/Q8X8eWVObNV0duSs95BCshG/jkdv3AkFdAV5pQ8 Py92qOeESHJK01+HI8tUEn9tsBT3jGZIorAscgrWCQoKLivdftKowd7ub9ajohS8 sTDdy7LJZ/XhV//9I4AI7+B4sGZrErOD7TkOF1Y2Ot2sJNlZAu94uGHcV5M7tyUD pNcbH10EeizQAuJtcxgOkbJic/5GURgLL3ivQMReVLtljdx+HU53FulivDlbUHfI /jGg6vLnqfYzpHSnBFKqVW8sp28VTpJjKQ0tlzZxzXXYRO1a3RAdpQ/B+yOXr/S7 1CPS0XO/Cw7ikwGZOrktSVHq6iGnzo+oylMsBVYuwKaQs/DyYqHlQ7WKKQw6URmt JIOPk4PhnkOVMjB4tc1Cd8pPlMDHMRiWklRq7IdubACnEgr9vaj9sGXkcU6SLa7h JFkvU5Dzns3YWVEP3BoHPDNKy/NbgPjbc0dGbC8I/qet7fDV9ek1bZxVkj1KQzyv jEfVephCFP1s8OPYCw1vfnuOXAO7eLSDjSSy7v1LABd5iWPN0aw+gpJWOd8ygWXc ijq5OpT4UAqQSt4vpPp+Sj2lXdzYxlQSP0j+EiQl4Si6dNz9UfVmJ2Uar76aoWjD XNrAg1pl/QeXkMsJd5RA =0Yq/ -----END PGP SIGNATURE----- --nextPart2130319.uUDHmnaQPA-- From nobody Wed Jul 20 05:49:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA912D5F8 for ; Wed, 20 Jul 2016 05:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8JGyYfofTtY for ; Wed, 20 Jul 2016 05:49:07 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C2A12D5F9 for ; Wed, 20 Jul 2016 05:49:04 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id s63so43717396qkb.2 for ; Wed, 20 Jul 2016 05:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgpzQbszEvPkCbUrAZiGSa+8g+0OBZQS/TA5eDVV3Sw=; b=e8WmJuFTAcJtmICWpLenad7PPx/p2QhWcByL0Ec96qrKRBaX2sNWGpBfo2iGsQqQlF XwV3sKCaKC5aDN8D3X5DxJKPyUd1U+R+gbumHeYGC55+Ev0is553GrN3qKILEtwAkfVm OIJF9igP+i4qlOb85LDV6NydwDgAJVrUHEytk= 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; bh=zgpzQbszEvPkCbUrAZiGSa+8g+0OBZQS/TA5eDVV3Sw=; b=hM4ZNtPG8v2BT+MvF+SdsS0WmfeEIwJCA9JyjmItrEofME6jX+GaJIn5A0ICphmAOW e1FopnmEeW7WQGKMAJQfc5Oh7mtjeKbycY/0BLYPAFdB08gCkFm/zJgRnjrhBQ5201Qy J3x1DJGqd55ZeKDXiEGPcapAD6rv2+FOordvfcqp6BlB4il4hRWVDbxpvmAiNlqEGn/h LNUMIBl8/owilaDT5fmDrv8mQJkzNsWauV3o5fzrkOXYuXDIuG6yNNf31ai3nflWu85H eeYVT9kINfKAP5QvTzwE1KdXKxeC91H0GfVz+n0YVUhtiIwu03+bRouNbH0vIC6qPk+i M/oQ== X-Gm-Message-State: ALyK8tKby4aBIPCmpTKCzskg0l4tteMmXemPDgxZm9oT0ObhB2BOkFnXpN1SsQXXByEkKBdMyuIhCyzxg3Uabg== X-Received: by 10.55.24.215 with SMTP id 84mr61922928qky.51.1469018943768; Wed, 20 Jul 2016 05:49:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.118.135 with HTTP; Wed, 20 Jul 2016 05:49:03 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:88a4:cf8f:e95f:e111] In-Reply-To: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> From: Kyle Rose Date: Wed, 20 Jul 2016 14:49:03 +0200 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a113b9dc45003ff053810a0df Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:49:13 -0000 --001a113b9dc45003ff053810a0df Content-Type: text/plain; charset=UTF-8 > it's not IETF's fault that the implementers add unspecified by IETF > restrictions and limitations to parsers of Client Hello messages or that > they can't handle handshake messages split over multiple record layer > messages, despite the standard being very explicit in that they MUST > support this > When the failures are limited to obscure implementations, and/or popular ones with a hope of being updated, I'm in the "fix your shit" camp. When a substantial fraction of the internet breaks, this approach is less clearly the right one because it can result in the never-ending downgrade dance, or in limited deployment of new versions/ossification. I hope (with no real evidence) that given the strong level of involvement of the major browsers in 1.3 development that advantage goes to the client. Kyle --001a113b9dc45003ff053810a0df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

it's not IETF's fault that the implementers add unspecified = by IETF
restrictions and limitations to parsers of Client Hello messages or that they can't handle handshake messages split over multiple record layer messages, despite the standard being very explicit in that they MUST
support this

When the failures are limited to obscure i= mplementations, and/or popular ones with a hope of being updated, I'm i= n the "fix your shit" camp.

When a substantial fraction of= the internet breaks, this approach is less clearly the right one because i= t can result in the never-ending downgrade dance, or in limited deployment = of new versions/ossification. I hope (with no real evidence) that given the= strong level of involvement of the major browsers in 1.3 development that = advantage goes to the client.

Kyle

--001a113b9dc45003ff053810a0df-- From nobody Wed Jul 20 06:14:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D180C12B019 for ; Wed, 20 Jul 2016 06:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKb40GjHLSTs for ; Wed, 20 Jul 2016 06:14:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3D312D62E for ; Wed, 20 Jul 2016 06:14:00 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 94DEA6540B; Wed, 20 Jul 2016 13:13:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KDDw8V018488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 09:13:59 -0400 From: Hubert Kario To: Kyle Rose Date: Wed, 20 Jul 2016 15:13:57 +0200 Message-ID: <1577215.bshq0AhCfG@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10422972.cX2HCJ7cja"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 20 Jul 2016 13:13:59 +0000 (UTC) Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:14:04 -0000 --nextPart10422972.cX2HCJ7cja Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote: > > it's not IETF's fault that the implementers add unspecified by IETF > > restrictions and limitations to parsers of Client Hello messages or that > > they can't handle handshake messages split over multiple record layer > > messages, despite the standard being very explicit in that they MUST > > support this >=20 > When the failures are limited to obscure implementations, and/or popular > ones with a hope of being updated, I'm in the "fix your shit" camp. >=20 > When a substantial fraction of the internet breaks, this approach is less > clearly the right one because it can result in the never-ending downgrade > dance, or in limited deployment of new versions/ossification. I hope (with > no real evidence) that given the strong level of involvement of the major > browsers in 1.3 development that advantage goes to the client. I think that implementing complex binary cryptographic protocols is simply= =20 hard. At the same time many corner cases are not encountered in day to day use, m= any=20 failures are completely silent (TLS POODLE). Which means that many implementers stop working on their TLS stack as soon = as=20 they can connect to default OpenSSL instance or to google.com, or can proce= ss=20 hello message from Internet Explorer/Chrome. While I think that the standard should be more strict, and the section D.4.= we=20 know from RFC 5246 should be much longer in the TLSv1.3 document, it won't= =20 matter if the implementers won't read the thing. And from what I can see, people that implemented the servers that 90% of Al= exa=20 top 1 million sites use, simply haven't recognized that section D is=20 important. Let alone tested that their implementation actually follows it! =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 Republic --nextPart10422972.cX2HCJ7cja 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 iQIcBAABCgAGBQJXj3kVAAoJEJKo0bgB0vX1RLsP/0DH9+hWLoGfCAAy3hvOaABA ZHBFIp5iD0R/YVSIxFk7OykKmEmUDn3O3QdWiJECbsVHGW6xagXjcMiSGqNP/OLZ bmvsXMvb/A/pe5IjvnMqJ3uPu38mF2cEWMwFrFz/Icb2QE3nGDTdSkofvVUifzWX CrXpK0wgB0Q7jNfX4G4DKvijsJ/Wo7rwe16BVzMTG/nt1rdeuK1TDEnz82onlD14 uNRkCdjS3pFGWqwgWXOsjYylx5WaAb269oc6RNk4Yl0N6NNZPlBLAuy8qR2Lgq6n 7K/YN0llTRM2HaZTKBdfrnWZ9bnOsjJ3/ZwK6kgnUQV1OvY0EVIjUafTjCTrH8SA pbsDubCpNw/g9yCt2jcDTOoLjp1QGBJQzQpf11rsHjzv4VWOcVketQ83UE4sxUw0 stotjrexaEWxcL2tTagZFMaJs6zCCYnkrpHKPIYomgrE4ec1Zn7TocKcnXsT795Y ZX27DBIAJ+FelQkQszQNLkcI65YjgDJoiIEEBhVldTHwJlT4IFDddKLeNQIBZGs/ b36v+hl+eDGmsdDgjVRkFyjBVdyeOOndTPHeR1V2zrXq8zOq5EmA2K0Wuxgs0aYS styYSuSTpHakLao1fRkkIdYJRD73aUXsm8sCqAA34Zx3QQKy/R0Xl6GgfTDYC5EW 9KZA9F+kg9qDqYYh4iXe =ZZWj -----END PGP SIGNATURE----- --nextPart10422972.cX2HCJ7cja-- From nobody Wed Jul 20 06:24:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4412D5D3 for ; Wed, 20 Jul 2016 06:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv1kyPTM3TcU for ; Wed, 20 Jul 2016 06:24:53 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 6AA7F12D130 for ; Wed, 20 Jul 2016 06:24:52 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id n129so23289602vke.3 for ; Wed, 20 Jul 2016 06:24:52 -0700 (PDT) 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; bh=tFDioV++81bp0jJHct0dhV0wJMBJ5ldhfLAyijYvJtk=; b=hqTEvJrWVM+nqq6GPKR2SCuDo7UBh6kgp0hOwkT9VReaw17V55axLgFkfKEiwNewXl zGQLzxG0WC5iOvfJnSDME6dhcSWbzOKBSwwG+CZ3TtlBnps9HNIHftGdvmTBgAvyXHFP Lm/f71eWUF5YKCmAKLN6dYRn56h+Hr2FGGUaz8GbLFDWAFvTzzf6zAHGGu7aWSP8zYry sY2UVnXFlkbGDj9FaC0ZEIK48kngLM8ztOBQOft3xRlTrlz6ywmOQrcbZeY/H1RVCzyE IQRIzt/bRX2HMdEdtjqqG4coDILZtbzolJcBLCG0W9wL7bikgHpQNwFZhXRnXRRfk36t VCTg== 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; bh=tFDioV++81bp0jJHct0dhV0wJMBJ5ldhfLAyijYvJtk=; b=XDzGB1LzMEEaUpGRJYAsnCeemnOMK4LCH+16YM7j10BiS7O0u3NBDwoG3+z38gN7iu r4ntO5K0kv4y/8865wETWhSM47+PNabN5J4P4k+2mHN00kc4O6qc1ypznKKT3R06anMG Qa+hvGNhZXYpc23gae6sZpk/mUNRD8RUmcg2XtpWDvdQg4u5NDIeDWr9TTb8OhyvG40f oUrvdFykUwYvi0nrxGjN9RXMWDeYDXOQZynGJB1+Z2xY6DFEnN+pXbhHC8DxlV/RxvdI laRySavB17uWjalhjd43qxQBArszbGiWZDYjRKkwRMEcR8/9w8KKMRuEtLbGQivCvD9b E5Ew== X-Gm-Message-State: ALyK8tL4My9j5FnwAIbKw06PLbzFZ69ul2vaHDiwb6MOyHLeiFiXVNoSBviDcD+0snoY5SrWVca+2hfaujO9Aw== X-Received: by 10.31.93.129 with SMTP id r123mr22985478vkb.149.1469021091484; Wed, 20 Jul 2016 06:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Wed, 20 Jul 2016 06:24:50 -0700 (PDT) In-Reply-To: <1577215.bshq0AhCfG@pintsize.usersys.redhat.com> References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <1577215.bshq0AhCfG@pintsize.usersys.redhat.com> From: Watson Ladd Date: Wed, 20 Jul 2016 06:24:50 -0700 Message-ID: To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:24:54 -0000 On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote: > On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote: > I think that implementing complex binary cryptographic protocols is simply > hard. > And what conclusion should one draw about TLS 2.0 (*ahem* 1.3) as a result of this realization? One hopes the IETF manages to avoid overcomplicating (extending and supporting necessary usecases actually) QUIC. I've given up on any substantial improvements in TLS. Sincerely, Watson From nobody Wed Jul 20 06:37:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2812D66B for ; Wed, 20 Jul 2016 06:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRurWTK_4IwC for ; Wed, 20 Jul 2016 06:37:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A070412D691 for ; Wed, 20 Jul 2016 06:37:08 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 97F6D4DAF1; Wed, 20 Jul 2016 13:37:07 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KDb6LB020705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 09:37:07 -0400 From: Hubert Kario To: Watson Ladd Date: Wed, 20 Jul 2016 15:37:05 +0200 Message-ID: <2675336.ahjJXf64CF@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> <1577215.bshq0AhCfG@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1708589.SSRuIdWrpc"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 20 Jul 2016 13:37:07 +0000 (UTC) Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 13:37:11 -0000 --nextPart1708589.SSRuIdWrpc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 20 July 2016 06:24:50 CEST Watson Ladd wrote: > On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote: > > On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote: > >=20 > > I think that implementing complex binary cryptographic protocols is sim= ply > > hard. >=20 > And what conclusion should one draw about TLS 2.0 (*ahem* 1.3) as a > result of this realization? we need what I'm already working on - a test suite (and a standard that makes it easy to know what is the expected behaviour for an implementation,= in=20 all cases) =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 Republic --nextPart1708589.SSRuIdWrpc 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 iQIcBAABCgAGBQJXj36BAAoJEJKo0bgB0vX1a98P/0kwme9KQzckA5aFZDkwY4bm tcsIm7PNVoSuI1u8NGweefxNf7cnyeeXCZuNJ81Ia36rKtElZ5QlqvPG3rmhJKK0 mx48SJW0Lbhp//qmMHPtku+ZSyh1RKEesrKwJoxZTaNo5UDO3GLOAiUAfPrAVJET gPqTPU2aIHGSGhC2Q58OqbHg/ZezLBjqaDYEV8kdm+BzEifN/tU/2KhCSV3WzL8R YaFTX1q533pQISAiNbTWz5Gbfff3mTUMFMuVVFG0dHU+p6C+xxUk+mwUGDaAA9b6 mVZJaaMZ8ee3aBrkdVa9sdUSWK+DC9qlHKBtTwGEmO/a51cf76SDDrU7Y6IVLgXw FE9bZ8LZ9cA8dVkPpoI32Oyy4gCiE4PBCmvHHWjpqbVnqvMlOZVjcO05GOEtSzJo 9V3i0hDRGg00lARYYVx6xLTxSlHdtdhRRKT7Zgm5veeFvC2u1p8/0u3MXMavjLGL 0T561CPBkuXyjZqqODFKVOhruH0hBwqdtsBZhg61gpgbUYW5vIFowUKULuLXBmr0 pc3QOQAYLL6LfsZmvlNYmiHA57ytR2Kj5W1JJgEJoFbDSvRmprAPa6XsCiY0ZIFe QgFwAKAEtpqUO3iin8AhrbzJi3uhb9S1aV7ng/gSFcfNB13VuDge/rPdg5QVs61U PWk34bYDEEiIwo+MNAYf =o8m5 -----END PGP SIGNATURE----- --nextPart1708589.SSRuIdWrpc-- From nobody Wed Jul 20 08:14:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957212D7DA for ; Wed, 20 Jul 2016 08:14:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=newcastle.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnov2WVgYTQj for ; Wed, 20 Jul 2016 08:14:08 -0700 (PDT) Received: from cheviot12.ncl.ac.uk (cheviot12.ncl.ac.uk [128.240.234.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5681B12D7DB for ; Wed, 20 Jul 2016 08:14:08 -0700 (PDT) Received: from exhubvm02.ncl.ac.uk ([128.240.234.9] helo=EXHUBVM02.campus.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1bPtCI-0008Mc-BK; Wed, 20 Jul 2016 16:14:06 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (213.199.154.239) by exhub.ncl.ac.uk (128.240.234.9) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 20 Jul 2016 16:13:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newcastle.onmicrosoft.com; s=selector1-newcastle-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zhSWLesJhtn+t+D69Zt1sMyeAlZIotA5zGcsgEDejxI=; b=lnookAUrdm3l3QCXuPbTcqWewliRykGJcG06MXa5vKpha8nCo0mh/kMuRiOxLdAgOGIEOhXVEBOslWBZbS4G0vnD3+DXQshcGpZKiEcrnd5wXiC8qeSAakpDxa1ZBdhCZ5gTEkgcbGzJjwREihBijX89Ts4UFKtkg0wA96wPowA= Received: from DB5PR0701MB1928.eurprd07.prod.outlook.com (10.167.228.24) by DB5PR0701MB1925.eurprd07.prod.outlook.com (10.167.228.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 15:13:56 +0000 Received: from DB5PR0701MB1928.eurprd07.prod.outlook.com ([10.167.228.24]) by DB5PR0701MB1928.eurprd07.prod.outlook.com ([10.167.228.24]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 15:13:56 +0000 From: Feng Hao To: Dan Harkins Thread-Topic: [TLS] Comments on TLS-ECJ-PAKE draft Thread-Index: AQHR4NwvKPpbhbjrqEGFHD5Bf6yEOKAgLS+AgADxAwCAAC48EA== Date: Wed, 20 Jul 2016 15:13:56 +0000 Message-ID: References: <52173e33a5b14592b16ac6b6eae8fe81.squirrel@www.trepanning.net> <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net> In-Reply-To: <2ee1801e4404fd17c2a1694ac12f79d3.squirrel@www.trepanning.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=feng.hao@newcastle.ac.uk; x-originating-ip: [128.240.225.103] x-ms-office365-filtering-correlation-id: ecaec035-fada-42bc-192d-08d3b0b0780e x-microsoft-exchange-diagnostics: 1; DB5PR0701MB1925; 6:Z5C2GFZV9pOkzzDcJcZIGuXrt8zUnmnEF5b4OKn7eruLN1hIrZP+GVkWiTlAB2anF1WUxzNpMTgCNIK9oTpdbMcT2mhPa2fxEKPZShmfYv+jjiwHJvTsZiYSHPRlqDBRq8jlrykR8dCV53fSY7lYb5DEQNyrLu+OElXms/OxGYZRLk0tSrQzMbyXDKCR0/pHBne6MakOkbPuRO3lDrTqdQe8QXm4419dKT8mAvRJsTsUmuA1HhGKobg68OEcRTOp2pYBBHzbbQgksFq03x6KIkwzdN2rC0zoWJw4i0GYmZU=; 5:iPdENwk5Cl40DU8h50e7cLp0AEjt47KYukZr7VuOGxmm0D08vXlWAMbLTIx3gotftD3uS9z81ZHIv6exBs8tAo9widHztGoPWY6ugZIbsYpDXHelLCtoO/IJQvRIp03BI0rGMMmPxT/ITHJi2VK5jA==; 24:J9EZiAlSVp2En59yxR++5dIaTO62Snm7nIQscTaNVkItjgh1YVQqZwz90NIWzcapQ5xHrr70e6ICkMqLwFCmn6Ell4nwAJ5F8iI9GA3IPbA=; 7:NI1QSEciQi+w4cLbgBHPphy/1LDY9ko2ErUDgt+FRD+SjwOmCEO7Z/TGOihnvOks/tTqyvHn3mYsDje3h6rRJefbIXX+Ftm+pe0vufLL0NTlyGRIb/JCE2xhuRKfFe4cmcYY8bBpERniXDve1X9yaE65TxfC+58BdE8Xyl5SctNAxkneQ2mVazMJCGND/7cLzyU+2o+YGZiNp5aUD50/IR5kzVrpQFT011uNJVDQXPUJho7XjFhIo5xegYpuiugd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0701MB1925; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR0701MB1925; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0701MB1925; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(24454002)(13464003)(189002)(199003)(230783001)(102836003)(11100500001)(66066001)(4326007)(2906002)(74316002)(87936001)(106116001)(8936002)(106356001)(33656002)(3846002)(3280700002)(3660700001)(9686002)(6116002)(74482002)(122556002)(76576001)(10400500002)(2950100001)(2900100001)(15975445007)(77096005)(5002640100001)(105586002)(81166006)(81156014)(93886004)(86362001)(76176999)(50986999)(54356999)(97736004)(68736007)(15395725005)(586003)(189998001)(7846002)(7696003)(305945005)(8676002)(92566002)(19580405001)(101416001)(19580395003)(110136002)(7736002)(5003600100003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0701MB1925; H:DB5PR0701MB1928.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: newcastle.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 15:13:56.1362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c5012c9-b616-44c2-a917-66814fbe3e87 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0701MB1925 X-OriginatorOrg: newcastle.ac.uk Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:14:13 -0000 Hi Dan, On your first comment, Yes, J-PAKE requires one more flow, but for the foll= owing benefits * Unlike EKE and SRP, it has the flexibility to work in any prime-order su= bgroup over a finite field (e.g., DSA-like groups).=20 * Unlike SPAKE2, it doesn't require setting up two generators whose discre= te logarithm must be unknown. The design of J-PAKE is to let end users have= the complete control of the randomness (by generating two ephemeral public= keys which are random and unrelated) rather than trusting an external part= y to set the randomness in the group parameters. * Unlike Dragonfly, it doesn't require any hashing-to-curve function. It m= erely needs a curve, a base point and +/* operations. Hence, it can be easi= ly applied to any EC curve that is suitable for cryptography (as long as th= e DDH assumption holds). On your second comment, is there any fundamental reason why the first flow = (client hello) can't contain key exchange messages? Kindly note that: * The proposed PAKE usage is not meant for web browsers (for reasons expla= ined in the draft). But TLS should be useful for applications other than ju= st web browsers.=20 * In a non-browser setting for realizing secure communication between two = remote parties and considering the fact that J-PAKE is a balanced PAKE (sam= e as Dragonfly), it seems sensible to let client initiate the choice of cip= hersuit and see if the server supports it (here, I use client and server fo= r convenience, but they are more like peers with equal say). Cheers, Feng -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dan Harkins Sent: 20 July 2016 11:18 To: Robert Cragie Cc: tls@ietf.org Subject: Re: [TLS] Comments on TLS-ECJ-PAKE draft Hi Robert, Sorry for the confusing comments. There are 2 but one follows because of = the other. The first comment concerns the fact that J-PAKE is a 4 message handshake.= This is different than other PAKES like EKE, SPAKE2, dragonfly, or SRP whi= ch all establish their shared key in a single 2 message exchange. A 2 message exchange falls into the TLS handshake elega= ntly, e.g.: - figure 1 in https://tools.ietf.org/html/rfc5054#page-5 and - figure 1 in https://tools.ietf.org/html/draft-ietf-tls-pwd-07#page-10 as opposed to: - figure 1 in https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00#page-7 where as you are making the TLS "Hello phase" into a "Hello plus one-half o= f the key exchange phase". This is my comment about this being a fundamenta= l change to TLS. Now the 2nd comment that follows out of the 1st is that by overloading th= e Hello Phase to include half the key exchange phase you remove all ability= to do negotiation. When TLS-ECJ-PAKE is used it is the only thing that can= be used. The client can only offer it and it can only talk to servers that= support it. Which is why my 2nd comment is that this is fundamentally a pr= oprietary protocol. You don't need a cipher suite assignment for this becau= se you have no ability to negotiate it. You could make it 0xFF,0xFC-FF (res= erved for private use) and have no issues. You will never have interop issu= es with some other TLS-like private protocol that also uses 0xFF,0xFC-FF be= cause you'll never talk to them. Your TLS-ECJ-PAKE client always and only t= alks to your TLS-ECJ-PAKE server so your private assignment of the private = use cipher suites cannot conflict with any other private assignment. Propri= etary protocols don't need cipher suite assignments and this is a proprieta= ry extension of TLS. regards, Dan. On Tue, July 19, 2016 12:55 pm, Robert Cragie wrote: > Hi Dan, > > What you say regarding the NamedCurve/EllipticCurveList is of course=20 > right. > Whether this constitutes a fundamental change to TLS is debatable. The=20 > aim was never to propose this as a cipher suite for general inclusion=20 > in a range of supported cipher suites in a browser/server scenario as=20 > is pointed out in various places in the draft. The aim was to reuse=20 > TLS (a well-known and widely implemented protocol) as a vehicle to=20 > support the ECJ-PAKE method and to deliberately constrain the=20 > implementation parameters a priori. To me, that does not make this a=20 > proprietary protocol and the ease by which existing TLS=20 > implementations have been adapted to support TLS-ECJ-PAKE. I guess it=20 > does raise the wider question of "what is TLS" > though and whether this approach flouts conventional thinking about=20 > TLS (which, IMHO, it doesn't). > > Robert > > On 18 July 2016 at 11:06, Dan Harkins wrote: > >> >> Hi Robert, >> >> This draft moves the NamedCurve/EllipticCurveList into the=20 >> ClientHello, and since the client sends X1 and ZKP(X1) in the=20 >> ClientHello it means that is going to be a list of 1. It basically=20 >> moves the client's key exchange portion from ClientKeyExchange into=20 >> ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE then=20 >> that's the only thing it can offer and the parameters of that=20 >> exchange are all selected by the client, not the server. >> >> This is a fundamental change to TLS. If it's going to be offered,=20 >> it's the only thing that can be offered and therefore the only thing=20 >> that can be used. Seems like for a deployment either it's never used=20 >> or it's the only thing used and that makes it sort of a proprietary=20 >> protocol, not TLS. >> >> Dan. >> >> On Thu, June 16, 2016 2:51 am, Robert Cragie wrote: >> > I would like to ask the working group for comments on the=20 >> > TLS-ECJ-PAKE >> > draft: >> > >> > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 >> > >> > Some brief notes: >> > >> > * This intended status is informational. >> > * The draft is based on TLS/DTLS 1.2 as the Thread group required >> basis >> on >> > existing RFCs wherever possible. For that reason and due to the WGs >> focus >> > on TLS 1.3, I have understood from the chairs that it would not=20 >> > have received a great deal of attention from the WG, hence the=20 >> > intended >> status >> > of informational. >> > * The draft reflects the current use of the >> TLS_ECJPAKE_WITH_AES_128_CCM_8 >> > cipher suite in Thread (http://threadgroup.org/). >> > * There is an experimental implementation in mbed TLS ( >> > https://github.com/ARMmbed/mbedtls) >> > * The Thread group would like to get IANA assignments for 4 cipher >> suite >> > values and one ExtensionType value as soon as possible. >> > * There are at least four independent implementations, which have=20 >> > been used in interop. testing over the last 18 months. >> > * The security considerations recommend restriction of the use of=20 >> > this cipher suite to Thread and similar applications and recommends=20 >> > it >> should >> > not be used with web browsers and servers (mainly due to the long=20 >> > discussions regarding the use of PAKEs on this and other mailing >> lists). >> > >> > Robert >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 20 08:17:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA6212D924 for ; Wed, 20 Jul 2016 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTR6tU5Nh5nq for ; Wed, 20 Jul 2016 08:16:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB812D8A5 for ; Wed, 20 Jul 2016 08:16:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DAA71433457; Wed, 20 Jul 2016 15:16:53 +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 ADE1F433447; Wed, 20 Jul 2016 15:16:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469027813; bh=/Ac9Q/pgyo3V4seIxs3bAib4UelfZWX4WOUazXv4dd8=; l=1517; h=To:References:Cc:From:Date:In-Reply-To:From; b=Z9Jgsvd3mb2AuHhWc8vRXJoLxWKNoEdrO+uTLtX7KXnkT6z6WKZBkS2hC0YrvktIq 2nNM5po0gQja3zcQAeBAAZNaeNBpLY/jI9LH6aqqmLMExaSiCtGu45Yjw689H3WtlX 7DczalzCHdFIzqc1rw1rNqaDPU2mS5OK8bRqP1XQ= 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 85F911FC94; Wed, 20 Jul 2016 15:16:53 +0000 (GMT) To: Hugo Krawczyk References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> From: Benjamin Kaduk Message-ID: <13ece779-79ea-6fd8-fe40-73614146b230@akamai.com> Date: Wed, 20 Jul 2016 10:16:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7734455C1E575ECB8DB11416" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:17:00 -0000 This is a multi-part message in MIME format. --------------7734455C1E575ECB8DB11416 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 07/20/2016 12:42 AM, Hugo Krawczyk wrote: > > Actually, I would suggest that for any such value, we add "collision > resistance" to the label for that derivation - this would apply to > resumption/PSK context and to Exporter key (and possibly others) > Seems reasonable; space in the label is relatively cheap. -Ben --------------7734455C1E575ECB8DB11416 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 07/20/2016 12:42 AM, Hugo Krawczyk wrote:

Actually, I would suggest that for any such value, we add "collision resistance" to the label for that derivation - this would apply to resumption/PSK context and to Exporter key (and possibly others)


Seems reasonable; space in the label is relatively cheap.

-Ben
--------------7734455C1E575ECB8DB11416-- From nobody Wed Jul 20 08:43:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8209512B013 for ; Wed, 20 Jul 2016 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2N5b_XkakOh for ; Wed, 20 Jul 2016 08:43:39 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 63E29120727 for ; Wed, 20 Jul 2016 08:43:39 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7C0244F09C; Wed, 20 Jul 2016 15:43: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 63DBA4F072; Wed, 20 Jul 2016 15:43:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469029418; bh=wImDxMYirj5Ge4OxwUjspeXxhiYwW1uYu+CqT1zU+/Q=; l=2078; h=To:References:From:Date:In-Reply-To:From; b=VlEhZ+zw4RKYaU/EkIH4v3XX/YbDnN9Sl5sZwB2IvC48xnWBpqIFbuAs6r1YioURO v+9RgqMooBqOGKNUWX13/ma2hShbRJDneCaVqDUxT7HSwhukTpMyelbYwJ8V/jsIMw nVHZp1E/zUBJNrzlf3TcsqnzyQBcWlG0UNBYfugQ= 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 3B5431FC8C; Wed, 20 Jul 2016 15:43:38 +0000 (GMT) To: =?UTF-8?Q?Hanno_B=c3=b6ck?= , tls@ietf.org References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com> Date: Wed, 20 Jul 2016 10:43:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720120125.43f61155@pc1> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:43:41 -0000 On 07/20/2016 05:01 AM, Hanno Böck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from I had some follow-up discussion with David and a few others later in the day. One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is futureproof could be done in the hot path, so that it is impossible to implement a server that works in a major browser and is (e.g., 1.4) version-intolerant. Right now, if a browser wants to probe for (e.g., 1.3) version intolerance, it essentially has to treat it as a data-collection step, either doing the fallback dance on failure or just doing the probe in parallel with a 1.2 clienthello that is actually used for the connection, since we know that 1.3-intolerance exists. With David's proposal (and potentially variants of the other ones), browsers could implement a check that sends nonexistent versions in their clienthello, so that once a server implements 1.3, it would not be 1.4-intolerant. If we just keep with the current version negotiation scheme, we'll always be stuck in the "data-collecting" mode and won't be able to strictly enforce the future-proofing, since there are existing servers that are intolerant to the current scheme, and the browsers will be blamed for breaking sites on those servers if the browsers try to introduce strict enforcement of version negotiation future-proofing. -Ben > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. > From nobody Wed Jul 20 10:30:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CE812D8E7 for ; Wed, 20 Jul 2016 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz6-BShSEnK0 for ; Wed, 20 Jul 2016 10:30:30 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9896112D8DE for ; Wed, 20 Jul 2016 10:30:30 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3rvkT0278vz1HXs; Wed, 20 Jul 2016 19:30:28 +0200 (CEST) X-purgate-ID: 152705::1469035828-0000299C-09F29E2A/0/0 X-purgate-size: 3132 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rvkSz4lrQzkvlx; Wed, 20 Jul 2016 19:30:27 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9BC3D1A504; Wed, 20 Jul 2016 19:30:27 +0200 (CEST) In-Reply-To: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> To: Hubert Kario Date: Wed, 20 Jul 2016 19:30:27 +0200 (CEST) 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: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 17:30:36 -0000 Hubert Kario wrote: > Martin Rex wrote: >> >> Forget TLS extensions, forget ClientHello.client_version. >> Both in fundamentally broken, and led to Web Browsers coming up >> with the "downgrade dance" that is target&victim of the POODLE attack. >> >> We know fairly reliably what kind of negotiation works just fine: >> TLS cipher suite codepoints. > > please re-read my mail, they don't: > > 49% (6240) are intolerant to a Client Hello with no extensions but > big number of ciphers that bring its size to 16388 bytes) > 91.5% (11539) are intolerant to a Client Hello with no extensions > but a number of ciphers that bring it well above single record layer limit > (16.5KiB) You're seriously confusing things here. Any ClientHello with > 200 Cipher suite code points indicates fairly insane Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. Trying to support theoretical encoding size limits is a stupid idea, because it leads to endless security problems. Imposing sane sizes plus a safety margin is solid implementation advice. Large stuff that doesn't need to be exchanged in abbreviated handshakes should *NEVER* be included in ClientHello, because of the performance penalties this creates (Network bandwidth for TLS handshake, and TCP slow start). > >>> I'm now also collecting some data and have some preliminary >>> suspicion on affected devices. My numbers roughly match yours that we >>> are in the more or less 3% area of 1.3 intolerance. >> >> The TLSv1.2 version intolerance is already a huge problem, >> and I'm not seeing it go away. Acutally Microsoft created an >> awfully large installed base of TLSv1.2-intolerant servers >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2). Please recheck with a vanilla (aka extension-free) ClientHello that has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant implementations in your counts. >> >> I would really like to see the TLS WG improving the situation >> rather than keep sitting on its hands. The problem has been well-known >> since 2005. And the "downgrade dance" was a predictably lame approach >> to deal with the situation, because it completely subverts/evades the >> cryptographic protection of the TLS handshake. > > it's not IETF's fault that the implementers add unspecified by IETF > restrictions and limitations to parsers of Client Hello messages or that > they can't handle handshake messages split over multiple record layer > messages, despite the standard being very explicit in that they MUST > support this. Nope, not really. Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour. X.509v3 certificates can theoretically include CAT MPEGs and amount to megabytes. A TLS implementation that limits the certificate chain (i.e. the TLS Certificate Handshake message) to a reasonably sane size with safety margin, say 32 KBytes in total, is acting totally reasonable. Anyone who creates an insane PKI deserves to loose, and deserves to loose quite badly. -Martin From nobody Wed Jul 20 11:12:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F312D9CF for ; Wed, 20 Jul 2016 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUKu5aeJ2vji for ; Wed, 20 Jul 2016 11:11:58 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 69E4912D9E0 for ; Wed, 20 Jul 2016 11:11:58 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id x130so80478403vkc.0 for ; Wed, 20 Jul 2016 11:11:58 -0700 (PDT) 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; bh=eTE09lquMOodjQ3xqsOuYWBlehbc/UkiWDPwqInHZyk=; b=iZMyaQewEpxVlD6eO+Tp9fugyluuzTkS52NLjY+3TM/j2pe0Squz/nhKb7qgrWfgXy cJCBSphl9EuV77pg1lSeu7J1IAp0pDyAQU5qtNJ3BtzsZgTHd2ahVdZjVevuhtg6OGB+ LSTHQkEMCJVvCXspJbaLIdlkda+7gZLrfFqbzHlo7Iq4k8Y3Ai9WZGdP1/G6/YXBZJqw 2ZuOjAdtij7DdYBHbFqEcvg4Y4lIRzmuVUX2iJCEHhLc97iL91AKXF1tn7QYP2qk84dN CD/rhqdM54w7Wyh9KB6rpBxwMInCUj6PoB2Ve1aeY1C4+oKCSAwifC1jngO4JljETFT2 nLVw== 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; bh=eTE09lquMOodjQ3xqsOuYWBlehbc/UkiWDPwqInHZyk=; b=BMB5D3NOjn4mS+4VEfvfrXBL4W0wsfe2hZJA/juVbg2m2r4hgI0bmqJ0qamAqEOccm CF5QSXMufEhG6IBJwWoEMiYhqpCrKeQQxIbD0qewIictNvA2bnRoCiISALq2/Fmeqznv eZ5r4apjwrhd7HgOqg0uRN3qCZc962jHVs5uKoaG3PrNjQb0t2rCJz6Z+K7pbPhJTTp0 CFVd2BzQSwuY/gQgerYv174oEKI2PhIbSQGreqzbnrUCU1UbTsW5qq6pj+EX+J5LawYD r73j9GenqWThIw/hFinAELbPmxcSAa7LCMwjQxvujnXo5MOleU+PKterPO7pkXjeCZMt VQLg== X-Gm-Message-State: ALyK8tKZTqevP+lslIJ1UkiknDJI7tEh0bx7tIm652OGPF52WOT6g3213TjrwqgeCy0r+Qaj6oR6m/3mIxxUtQ== MIME-Version: 1.0 X-Received: by 10.176.1.67 with SMTP id 61mr24462138uak.87.1469038317445; Wed, 20 Jul 2016 11:11:57 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Wed, 20 Jul 2016 11:11:56 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Wed, 20 Jul 2016 11:11:56 -0700 (PDT) In-Reply-To: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> References: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> Date: Wed, 20 Jul 2016 11:11:56 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a113cf70a12a6d005381523c4 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:12:01 -0000 --001a113cf70a12a6d005381523c4 Content-Type: text/plain; charset=UTF-8 On Jul 20, 2016 10:31 AM, "Martin Rex" wrote: > > Hubert Kario wrote: > > Martin Rex wrote: > >> > >> Forget TLS extensions, forget ClientHello.client_version. > >> Both in fundamentally broken, and led to Web Browsers coming up > >> with the "downgrade dance" that is target&victim of the POODLE attack. > >> > >> We know fairly reliably what kind of negotiation works just fine: > >> TLS cipher suite codepoints. > > > > please re-read my mail, they don't: > > > > 49% (6240) are intolerant to a Client Hello with no extensions but > > big number of ciphers that bring its size to 16388 bytes) > > 91.5% (11539) are intolerant to a Client Hello with no extensions > > but a number of ciphers that bring it well above single record layer limit > > (16.5KiB) > > You're seriously confusing things here. > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. The IANA registry contains > > Trying to support theoretical encoding size limits is a stupid idea, > because it leads to endless security problems. Imposing sane sizes > plus a safety margin is solid implementation advice. No, using languages that permit memory safety violations leads to problems. Somehow I doubt you would call avoiding those languages sane implementation advice. Yes, a device with 8kbyte RAM could have a problem with large Client Hellos, but I doubt that is the issue here. > > Large stuff that doesn't need to be exchanged in abbreviated handshakes > should *NEVER* be included in ClientHello, because of the performance > penalties this creates (Network bandwidth for TLS handshake, > and TCP slow start). > > > > > >>> I'm now also collecting some data and have some preliminary > >>> suspicion on affected devices. My numbers roughly match yours that we > >>> are in the more or less 3% area of 1.3 intolerance. > >> > >> The TLSv1.2 version intolerance is already a huge problem, > >> and I'm not seeing it go away. Acutally Microsoft created an > >> awfully large installed base of TLSv1.2-intolerant servers > >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2). > > Please recheck with a vanilla (aka extension-free) ClientHello that > has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant > implementations in your counts. Since TLS 1.0 servers have been instructed to ignore extensions, which finally got used in TLS 1.2. Hardly matters exactly what causes the problem. > > > >> > >> I would really like to see the TLS WG improving the situation > >> rather than keep sitting on its hands. The problem has been well-known > >> since 2005. And the "downgrade dance" was a predictably lame approach > >> to deal with the situation, because it completely subverts/evades the > >> cryptographic protection of the TLS handshake. > > > > it's not IETF's fault that the implementers add unspecified by IETF > > restrictions and limitations to parsers of Client Hello messages or that > > they can't handle handshake messages split over multiple record layer > > messages, despite the standard being very explicit in that they MUST > > support this. > > Nope, not really. Limiting PDU sizes to reasonably sane sizes is > perfectly valid behaviour. X.509v3 certificates can theoretically include > CAT MPEGs and amount to megabytes. A TLS implementation that limits > the certificate chain (i.e. the TLS Certificate Handshake message) to > a reasonably sane size with safety margin, say 32 KBytes in total, > is acting totally reasonable. Anyone who creates an insane PKI deserves > to loose, and deserves to loose quite badly. Unless we specify minimum sizes that must be handled, this creates difficult interop problems, particularly when sizes need to be expanded. That size is less then one SPHINCS signature for instance. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a113cf70a12a6d005381523c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 20, 2016 10:31 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Hubert Kario wrote:
> > Martin Rex wrote:
> >>
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming = up
> >> with the "downgrade dance" that is target&victi= m of the POODLE attack.
> >>
> >> We know fairly reliably what kind of negotiation works just f= ine:
> >> TLS cipher suite codepoints.
> >
> > please re-read my mail, they don't:
> >
> > 49% (6240) are intolerant to a Client Hello with no extensions bu= t
> > big number of ciphers that bring its size to 16388 bytes)
> > 91.5% (11539) are intolerant to a Client Hello with no extensions=
> > but a number of ciphers that bring it well above single record la= yer limit
> > (16.5KiB)
>
> You're seriously confusing things here.
>
> Any ClientHello with > 200 Cipher suite code points indicates fairl= y insane
> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour= .

The IANA registry contains
>
> Trying to support theoretical encoding size limits is a stupid idea, > because it leads to endless security problems.=C2=A0 Imposing sane siz= es
> plus a safety margin is solid implementation advice.

No, using languages that permit memory safety violations lea= ds to problems. Somehow I doubt you would call avoiding those languages san= e implementation advice. Yes, a device with 8kbyte RAM could have a problem= with large Client Hellos, but I doubt that is the issue here.

>
> Large stuff that doesn't need to be exchanged in abbreviated hands= hakes
> should *NEVER* be included in ClientHello, because of the performance<= br> > penalties this creates (Network bandwidth for TLS handshake,
> and TCP slow start).
>
>
> >
> >>> I'm now also collecting some data and have some preli= minary
> >>> suspicion on affected devices. My numbers roughly match y= ours that we
> >>> are in the more or less 3% area of 1.3 intolerance.
> >>
> >> The TLSv1.2 version intolerance is already a huge problem, > >> and I'm not seeing it go away.=C2=A0 Acutally Microsoft c= reated an
> >> awfully large installed base of TLSv1.2-intolerant servers > >> (the entire installed base of Win7 through Win8.1 aka 2008R2,= 2012, 2012R2).
>
> Please recheck with a vanilla (aka extension-free) ClientHello that > has ClientHello.client_version =3D (3,3), to recognize all TLSv1.2-int= olerant
> implementations in your counts.

Since TLS 1.0 servers have been instructed to ignore extensi= ons, which finally got used in TLS 1.2. Hardly matters exactly what causes = the problem.

>
>
> >>
> >> I would really like to see the TLS WG improving the situation=
> >> rather than keep sitting on its hands.=C2=A0 The problem has = been well-known
> >> since 2005.=C2=A0 And the "downgrade dance" was a p= redictably lame approach
> >> to deal with the situation, because it completely subverts/ev= ades the
> >> cryptographic protection of the TLS handshake.
> >
> > it's not IETF's fault that the implementers add unspecifi= ed by IETF
> > restrictions and limitations to parsers of Client Hello messages = or that
> > they can't handle handshake messages split over multiple reco= rd layer
> > messages, despite the standard being very explicit in that they M= UST
> > support this.
>
> Nope, not really.=C2=A0 Limiting PDU sizes to reasonably sane sizes is=
> perfectly valid behaviour.=C2=A0 X.509v3 certificates can theoreticall= y include
> CAT MPEGs and amount to megabytes.=C2=A0 A TLS implementation that lim= its
> the certificate chain (i.e. the TLS Certificate Handshake message) to<= br> > a reasonably sane size with safety margin, say 32 KBytes in total,
> is acting totally reasonable.=C2=A0 Anyone who creates an insane PKI d= eserves
> to loose, and deserves to loose quite badly.

Unless we specify minimum sizes that must be handled, this c= reates difficult interop problems, particularly when sizes need to be expan= ded. That size is less then one SPHINCS signature for instance.

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

--001a113cf70a12a6d005381523c4-- From nobody Thu Jul 21 00:12:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE53B12DA83 for ; Thu, 21 Jul 2016 00:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO-8Hyeln6YU for ; Thu, 21 Jul 2016 00:12:23 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81F12DA80 for ; Thu, 21 Jul 2016 00:12:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A3B137E25 for ; Thu, 21 Jul 2016 10:12:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ApeJqmdGF03l for ; Thu, 21 Jul 2016 10:12:21 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4D4B7C4 for ; Thu, 21 Jul 2016 10:12:21 +0300 (EEST) Date: Thu, 21 Jul 2016 10:12:17 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160721071217.GB23604@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160719134626.GA14259@LK-Perkele-V2.elisa-laajakaista.fi> <013101d1e1cc$253eddb0$6fbc9910$@delignat-lavaud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Resumption Contexts and 0-RTT Finished X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 07:12:26 -0000 On Wed, Jul 20, 2016 at 01:42:58AM -0400, Hugo Krawczyk wrote: > Without taking a position on the implementation issues, I am in favor of > Option A with a dedicated context value (and an explicit name "PSK > Context") as this makes clear the function of this value. Relying in > Finished makes it more fragile and open to be dropped in the future when > its binding role is "forgotten" or when deriving some other protocol or > variant. Furthermore, I think that there are only two ways to do the kind of binding required that aren't fatally flawed (as far as I know) in some way. One is ADL's "Option A", and the other is implicit variant of "Option B" I came up with. Both are ugly. I think ADL's "Option A" is easier to implement (no need to mess with Finished generation). I also think that the 0-RTT Finished message should be removed (as suggested before by one of the "crypto guys", I forgot who). It is major implementation problem, and doesn't seem to even provode any security. > Also, I insist on the need to remark about the need for collision > resistance of any value with a binding functionality. If this value is > produced with HKDF (or HMAC as in he case of Finished) the need for > collision resistance is not explicit and can lead to truncation (which is > perfectly fine when just deriving keys or when used with a regular PRF > functionality). The properties that HKDF and HMAC actually provodes here: If the base hash is CR and has output length at most blocklength, then... - HMAC is CR w.r.t. its message input. - If the HMAC key is of constant length, the HMAC is CR w.r.t. its key. - HKDF-Extract is CR w.r.t. its key input. - If the salt is of constant length, HKDF-Extract is CR w.r.t. its salt. - If length is at least one hash output, HKDF-Expand-Label is CR w.r.t. its label. - If length is at least one hash output, HKDF-Expand-Label is CR w.r.t. its hashvalue. - If length is at least one hash output and secret is of constant length, HKDF-Expand-Label is CR w.r.t. its secret. These all can be shown by supposing an counterexample, and showing that it inevitably follows that the base hash is both CR and not CR at the same time, which is not possible. (Conviniently, all length constraints are currently always met). > Actually, I would suggest that for any such value, we add "collision > resistance" to the label for that derivation - this would apply to > resumption/PSK context and to Exporter key (and possibly others) I suggest appending ", collision resistant". (E.g. "TLS 1.3, exporter master secret, collision resistant", after fully expanding the label) -Ilari From nobody Thu Jul 21 02:22:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D208E12DC4E for ; Thu, 21 Jul 2016 02:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QUGbOb2XTsU for ; Thu, 21 Jul 2016 02:22:13 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D847E12D0AC for ; Thu, 21 Jul 2016 02:22:12 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id o67so68401796qke.1 for ; Thu, 21 Jul 2016 02:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=irLcqk0Z7KbHsenmbDwXe+R+peqG+sut6aCO+ZZlDEg=; b=B/ZDwPa7M5HfOBShzWYliK2iX8kznOySVGt5oFbAmhDrcGyn2HlEHbrURbxDByN+A7 Q2+bavkz/6lutnWC4bDBe0b5Ci6lGaL10iKZ20O/JQTtDRe2pHLuxssTFencdycfmMpr vRlDbpaRzSyrlUWtBJf6W20oQ3z1obn9nxEoQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=irLcqk0Z7KbHsenmbDwXe+R+peqG+sut6aCO+ZZlDEg=; b=BM9ywM8jz6Pi+J/rqWK8DCtKDl2othLDN+mYFzEFglOWebYUhWOXPOvqSfeCn5GRZt ylEGtd9gAsZPYTZYLFdWUXdAIE7e9gcvuWqFkFshmDmV/9r6qvA1UC8ZgLkWwGCOKHpg kgnP0qRRaj9pf+rBWVm0CXMAFB+xDJ+MSQX1tj2w0tDeeCzlkeSMGh8n2qFAuK9K3lEE a6AO4uYWnUEsejYZxG29gRnsadafBM1MhiY59Vh2yjyZXYy8nqQTmfv53iIVNQWYRuUH guQhwL1LjXx0xt2yCsMV/T0lhf9bRGbbTJkikuZ7h+5brjUcYC+j6LU+vfS8sBgqiE0N txAw== X-Gm-Message-State: ALyK8tIOidLbMuLwhx2RXhJpjfPBOOP5PrnF3WAsomfL13TieK8ovkOFIXkXQl4MI2umcQ== X-Received: by 10.55.136.133 with SMTP id k127mr26187202qkd.0.1469092931898; Thu, 21 Jul 2016 02:22:11 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id l22sm3774607qtl.34.2016.07.21.02.22.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 02:22:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160719140100.B2F20B80E05@rfc-editor.org> Date: Thu, 21 Jul 2016 05:22:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9703F211-2396-40C4-91CE-C98EEA024C0F@sn3rd.com> References: <20160719140100.B2F20B80E05@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] RFC 7924 on Transport Layer Security (TLS) Cached Information Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:22:15 -0000 Congrats to all involved! spt > On Jul 19, 2016, at 10:01, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7924 >=20 > Title: Transport Layer Security (TLS) Cached=20 > Information Extension=20 > Author: S. Santesson, H. Tschofenig > Status: Standards Track > Stream: IETF > Date: July 2016 > Mailbox: sts@aaa-sec.com,=20 > Hannes.Tschofenig@gmx.net > Pages: 19 > Characters: 35144 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-tls-cached-info-23.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7924 >=20 > DOI: http://dx.doi.org/10.17487/RFC7924 >=20 > 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). >=20 > This document defines an extension that allows a TLS client to inform > a server of cached information, thereby enabling the server to omit > already available information. >=20 > This document is a product of the Transport Layer Security Working = Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 21 02:39:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9691412DC25 for ; Thu, 21 Jul 2016 02:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2lyj0Tc_nos for ; Thu, 21 Jul 2016 02:39:02 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com [104.47.37.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2BE12DC16 for ; Thu, 21 Jul 2016 02:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=js+vQh67Q2iEHNzu8iYAo9p6O7pCSYp5IxlzAFBkZlM=; b=FDnqtMktxb+rQfPs4c9KdaVWuZ0ynwzhgntNLb23PuVeOLmN6ljk9cPfyt79SG0fplG92NzWQfPifY121m7SGJjN8AMGQvK46Bc0Fo9FuMJwh7nrcBxGD8OVlClSL8z1esAA/38bCZp4Fi8+tQXrK4v0Rkp0rg1GBlAUdYZvpx0= Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1332.namprd03.prod.outlook.com (10.163.80.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 09:39:01 +0000 Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 09:38:59 +0000 From: Mike Bishop To: "tls@ietf.org" Thread-Topic: HTTP, Certificates, and TLS Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7sw== Date: Thu, 21 Jul 2016 09:38:59 +0000 Message-ID: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:67c:370:176:fd36:414d:818e:cc12] x-ms-office365-filtering-correlation-id: 7fd64161-50c5-4125-f8e3-08d3b14ad7a4 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1332; 6:01hAaguqa2fo6ijpdnOD3+/tf43ihJMVgL8D0Im4SyDw5XQm6U5iFwenpVpTXfLxxQlJY210xOduksblU2KSI5tTUvNeDvIwRmRRvj8wYkZSSY7Hw5VcfH/nWMqQvOMqYI9X+uhAflbiy49Au4354D27ddM8V8GvEaX8tnzWGprPbxiveaZBe8+dhLVh4H8RvbO+fUHceQZRI2z+yQfeVBUtCnVCEQeVPcSPp7lAZHnm6u0bADtPJKLWx5fpJcgR4zrvhF9a3vmnJXsgrda0z7BM6pRTbzVOvQ/t0mOMFGGVJuuTEN/l93oP2uPE+mhoqy0g9/SrpoGTSL0c0T2VeQ==; 5:I8xB54yyWWiT3KzagWPFBvjUENZH//b2b7fqHtHatqC4XG/K5zOudIN099slwYt/Pi/z4IaWgjOtylWNXtPuwgEJP0hXueU0Pld38hKCdL6cf0+XM4gGvINM2URuPUkEU9b5IKGwgvfQ6Ey0YY6uwQ==; 24:bRHj3PgVq/Gr2NXXQaoCneT2BzWx51ivh8NFPfedODq5H9Yfs1RsEFwk2Z5C2lt4S+77DdO1YGDlqtS4NLYop24OZBqkhlmTT94o/y7s2Qk=; 7:qKbqpQDJ5JVKM/3MdxVGP3k4qDvCb7ePrhnU2paa9qBVIlJwj2nOGOFx3+vXpYor36nXKS0F/ASnyJeuGt+7Egt5d1nJBRxH4acAsB+xIGdaHUSDg/QD7yJ6wCIiSmY5qTlLMy3yVfutbVylq0oiwD9fA6w4mEc7qU7w7lXNhGfEdzEwXVpbBQFd5oon1xjgKr4T1ShOWqwgomKN+gRoh0zepHqgEZt0thtAmoB55NmvzQ63Z8sjtrzZs2CzBFV1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1332; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1332; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1332; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(110136002)(68736007)(99286002)(189998001)(102836003)(6116002)(790700001)(10090500001)(4326007)(76576001)(92566002)(8676002)(1730700003)(105586002)(2906002)(10400500002)(586003)(19580395003)(10290500002)(5005710100001)(2501003)(5640700001)(97736004)(8990500004)(122556002)(5630700001)(19300405004)(3280700002)(15975445007)(8936002)(229853001)(16236675004)(33656002)(2351001)(81156014)(81166006)(5003600100003)(86612001)(87936001)(7736002)(7696003)(561944003)(106356001)(5002640100001)(19625215002)(86362001)(77096005)(3660700001)(9686002)(54356999)(2900100001)(7846002)(101416001)(50986999)(74316002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1332; H:BLUPR03MB1330.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 09:38:59.0559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1332 Archived-At: Subject: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:39:07 -0000 --_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks - Martin and I had come previously to the TLS WG to discuss our work with han= dling client certificates at the HTTP layer. Based on that discussion, we = revised our model to cover signatures of an exporter value and carry the pr= oof in an HTTP/2 frame. During BA, the HTTP WG expressed interest in flipp= ing the model in the opposite direction - carrying additional server identi= ties as well. That means we now have a proposal for carrying both client a= nd server certificates above TLS, found at https://tools.ietf.org/html/draf= t-bishop-httpbis-http2-additional-certs. We have also discussed that it might be preferable to pull part of this cap= ability back into TLS, expanding post-handshake authentication to allow pro= viding multiple certificates in either direction. Since that would necessa= rily require additional work on that part of the TLS 1.3 spec, we discussed= the possibility of splitting post-handshake authentication into a separate= spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled and = take a little longer on the second draft. Having spoken to some other TLS WG members, some people would prefer to mov= e post-handshake authentication entirely to our layer. While that's probab= ly not feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardl= ess of what HTTP/2 does), we can retain our application-layer authenticatio= n. This has the advantage of leaving TLS 1.3 unchanged, but keeps a securi= ty draft in a non-security working group. We are concerned that, by doing = this at the HTTP layer, we'll be missing necessary security expert review a= s this moves forward. (EKR already suggested some necessary improvements t= o our signature model to prevent some pretty trivial attacks; these aren't = reflected in the current draft.) If that's the route we go, I would greatl= y appreciate some TLS folks visiting the HTTP WG and helping us review this= draft. I was on the "time permitting" list to present in the TLS meeting on Tuesda= y, and we didn't get a chance to. We'll be discussing the actual draft tom= orrow morning in HTTP; I'd be happy to have some TLS folks there to discuss= the draft, and I'd like to get a sense from the TLS WG whether there's a p= reference for us to do this at the application layer or pass additional req= uirements to post-handshake auth. Thanks! -Mike Bishop --_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks –

 

Martin and I had come previously to the TLS WG to di= scuss our work with handling client certificates at the HTTP layer.  B= ased on that discussion, we revised our model to cover signatures of an exp= orter value and carry the proof in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipping the mod= el in the opposite direction – carrying additional server identities = as well.  That means we now have a proposal for carrying both client a= nd server certificates above TLS, found at https://tools.ietf.org/html/draf= t-bishop-httpbis-http2-additional-certs.

 

We have also discussed that it might be preferable t= o pull part of this capability back into TLS, expanding post-handshake auth= entication to allow providing multiple certificates in either direction.&nb= sp; Since that would necessarily require additional work on that part of the TLS 1.3 spec, we discussed the possibi= lity of splitting post-handshake authentication into a separate spec so tha= t the core TLS 1.3 spec could proceed to WGLC as scheduled and take a littl= e longer on the second draft.

 

Having spoken to some other TLS WG members, some peo= ple would prefer to move post-handshake authentication entirely to our layer.  While that’s probably not feasibl= e (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what HT= TP/2 does), we can retain our application-layer authentication.  This = has the advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a non-security working group.  We are c= oncerned that, by doing this at the HTTP layer, we’ll be missing nece= ssary security expert review as this moves forward.  (EKR already sugg= ested some necessary improvements to our signature model to prevent some pretty trivial attacks; these aren’t reflected= in the current draft.)  If that’s the route we go, I would grea= tly appreciate some TLS folks visiting the HTTP WG and helping us review th= is draft.

 

I was on the “time permitting” list to p= resent in the TLS meeting on Tuesday, and we didn’t get a chance to.&= nbsp; We’ll be discussing the actual draft tomorrow morning in HTTP; = I’d be happy to have some TLS folks there to discuss the draft, and I’d like to get a sense from the TLS WG whether there’s a = preference for us to do this at the application layer or pass additional re= quirements to post-handshake auth.

 

Thanks!

-Mike Bishop

--_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_-- From nobody Thu Jul 21 03:20:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458312DC9D for ; Thu, 21 Jul 2016 03:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q72rYf1WQOQT for ; Thu, 21 Jul 2016 03:19:57 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010: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 3327012DCB0 for ; Thu, 21 Jul 2016 03:19:46 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f93so57591355lfi.2 for ; Thu, 21 Jul 2016 03:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8dSlcv5leiCsSEbVQhzbktZr7J/yNg2uW4j4wct2iQw=; b=c3GHQuwVUT+NKx3+g+vMOtmErhgFf0pi26BdiXjR8bHmSc+cDDwTyN0YUPsld3J/E7 BFJz2PoeX4ELO019zHypIpvtE5I4tNydIzVmAwREO/idi3TJhIcb0zmJnjl7vM4lXvwB ZstQH/RwL0FUKW3wCexOzVn2uXBBg6EY6lghg= 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; bh=8dSlcv5leiCsSEbVQhzbktZr7J/yNg2uW4j4wct2iQw=; b=Frs+W49PQETcl+CBCMRQIkSZoHvuhLuXItK1qJom092vxLDWbbztioqJjExSZuyoyo XTsij7TMwFgec2hca06+bPMTip7QXs+fba/lkD7m2dAjg4iyhoTO0ptBCZzdFcAy3Hd2 EJsq/FvMGD3F7FBt05HghKj1jmR4RFyhAEZ/3eQbiQWAh0bsd5bf/t/bYK1BnJsSFvtE pQn3b9PSthIKiW181ZH/VfaCEBJ0V3+29pwuMordymyOIH/93zbzyr6y+f+RXWhjOUoK Hidxif5UpMlRTisr5oCa5VY+maGwnHhTo8MlbzeWQH4/mJEfSzLfsFHn9zlPf7zlSQoN dxfg== X-Gm-Message-State: ALyK8tKfOByomBXrJdb+Gwyx1AFQewf4cPT7oErySTHE98WfEP51HHCM4MQ6lgJi8qseLEyZjqhPCO9pR3j8FmnV X-Received: by 10.46.0.167 with SMTP id e39mr8990624lji.55.1469096384210; Thu, 21 Jul 2016 03:19:44 -0700 (PDT) MIME-Version: 1.0 References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com> In-Reply-To: <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com> From: David Benjamin Date: Thu, 21 Jul 2016 10:19:34 +0000 Message-ID: To: Benjamin Kaduk , =?UTF-8?Q?Hanno_B=C3=B6ck?= , tls@ietf.org Content-Type: multipart/alternative; boundary=001a1142c1301f7f60053822a816 Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:20:00 -0000 --001a1142c1301f7f60053822a816 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote: > On 07/20/2016 05:01 AM, Hanno B=C3=B6ck wrote: > > On Wed, 20 Jul 2016 11:20:46 +0200 > > Hubert Kario wrote: > > > >> so it looks to me like while we may gain a bit of compatibility by > >> using extension based mechanism to indicate TLSv1.3, > > Just quick: This was discussed yesterday, David Benjamin had an > > interesting proposal, but it was largely met with resistance. So from > > I had some follow-up discussion with David and a few others later in the > day. One point that I think was not clear during the WG session was > whether the check for whether a server's version negotiation is > futureproof could be done in the hot path, so that it is impossible to > implement a server that works in a major browser and is (e.g., 1.4) > version-intolerant. > > Right now, if a browser wants to probe for (e.g., 1.3) version > intolerance, it essentially has to treat it as a data-collection step, > either doing the fallback dance on failure or just doing the probe in > parallel with a 1.2 clienthello that is actually used for the > connection, since we know that 1.3-intolerance exists. With David's > proposal (and potentially variants of the other ones), browsers could > implement a check that sends nonexistent versions in their clienthello, > so that once a server implements 1.3, it would not be 1.4-intolerant. > > If we just keep with the current version negotiation scheme, we'll > always be stuck in the "data-collecting" mode and won't be able to > strictly enforce the future-proofing, since there are existing servers > that are intolerant to the current scheme, and the browsers will be > blamed for breaking sites on those servers if the browsers try to > introduce strict enforcement of version negotiation future-proofing. > [Credit where credit is due, I was not the first to propose the version list. I don't know who was first, but Dave Garrett had proposed the same thing. The TLS 1.3 implementors effectively did so too with the draft version extension. Though I think the fake versions idea is new?] I should also add that, even if we ever got to our prerequisite quiet point, this scheme is still problematic. If we had a list, all clients could participate in this fuzzing and we have a shot at vaccinating the ecosystem. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some sort of field trial mechanism, for instance.) And it requires manual work to sustain: I would probably only do it for, say, 3 months at a time and manually extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off. And as Hubert notes, there may well be other intolerance triggers to clear through. 1.3 has a larger ClientHello. We have also never added a new signature algorithm before. But I think that just means we have more rusted protocol joints fix rather than just the one. Fortunately, most of our other joints admit this kind of fuzzing. It's just the versioning scheme (fixable with a list), and large ClientHellos. I don't have a good answer to the second one, but I would be very happy if it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conversations usually go like this: "Hi, your server software appears to have a bug where you reject TLS 1.2 ClientHellos rather than implementing the version negotiation right." "Okay, we will deploy TLS 1.2." "No, please don't fix this with 1.2. That's a different problem." "You don't want us to add 1.2?" "No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3." I am obviously exaggerating for humor, but it's a very common confusion and I think is part of why version intolerance keeps on existing. If you implement the latest version of TLS but are intolerant to N+1, even if no clients did fallbacks, your bug will not be noticed and you'll thrive in the ecosystem. Then when we go to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop failures so the bugs are caught before software ships. David > -Ben > > > the WG discussion yesterday I had the impression that we will most > > likely stay with the existing clienthello version mechanism. While that > > will cause us more trouble, it's probably the cleaner option anyway. So > > we definitely should continue investigating version intolerance and > > tell people to fix their stuff. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142c1301f7f60053822a816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 20= , 2016 at 5:43 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 07/20/2016 05:01 AM, Hanno B=C3=B6ck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario <hkario@redhat.com> wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by=
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> interesting proposal, but it was largely met with resistance. So from<= br>
I had some follow-up discussion with David and a few others later in the day.=C2=A0 One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.=C2=A0 With David'= ;s
proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be ab= le to
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the fi= rst to propose the version list. I don't know who was first, but Dave G= arrett had proposed the same thing. The TLS 1.3 implementors effectively di= d so too with the draft version extension. Though I think the fake versions= idea is new?]

I should also add that, even if we ever got to our prerequis= ite quiet point, this scheme is still problematic. If we had a list, all cl= ients could participate in this fuzzing and we have a shot at vaccinating t= he ecosystem. This one violates the specification, so only clients which ca= n rapidly deploy changes can safely do it. (Some sort of field trial mechan= ism, for instance.) And it requires manual work to sustain: I would probabl= y only do it for, say, 3 months at a time and manually extend so long as TL= S 1.4 does not exist. I would not want to cause problems by forgetting to t= urn it off.

And as Hubert notes, there may well be= other intolerance triggers to clear through. 1.3 has a larger ClientHello.= We have also never added a new signature algorithm before. But I think tha= t just means we have more rusted protocol joints fix rather than just the o= ne.

Fortunately, most of our other joints admit th= is kind of fuzzing. It's just the versioning scheme (fixable with a lis= t), and large ClientHellos. I don't have a good answer to the second on= e, but I would be very happy if it were our only problem. It's much eas= ier to understand. The version one is surprisingly difficult. The conversat= ions usually go like this:

"Hi, your server software appears to have a bug where you rej= ect TLS 1.2 ClientHellos rather than implementing the version negotiation r= ight."
"Okay, we will deploy TLS 1.2."<= /div>
"No, please don't fix this with 1.2. That's a differ= ent problem."
"You don't want us to add 1.2?"<= /div>
"No no no. Please do switch to 1.2. I mean...=C2=A0oh, nevermind. I'll just email you later for 1.3= ."

<= div>I am obviously exaggerating for humor, = but it's a very common confusion and I think is part of why version int= olerance keeps on existing.

If you implement th= e latest version of TLS but are intolerant to N+1, even if no clients did f= allbacks, your bug will not be noticed and you'll thrive in the ecosyst= em. Then when we go to deploy N+1, we have problems. We want, as much as po= ssible, turn tomorrow's interop failures into today's interop failu= res so the bugs are caught before software ships.
<= div dir=3D"ltr">

David
<= /div>
=C2=A0
-Ben

> the WG discussion yesterday I had the impression that we will most
> likely stay with the existing clienthello version mechanism. While tha= t
> will cause us more trouble, it's probably the cleaner option anywa= y. So
> we definitely should continue investigating version intolerance and > tell people to fix their stuff.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1142c1301f7f60053822a816-- From nobody Thu Jul 21 03:47:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A986412DCC3 for ; Thu, 21 Jul 2016 03:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZcGapAsuBcv for ; Thu, 21 Jul 2016 03:47:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F4112DAE3 for ; Thu, 21 Jul 2016 03:43:02 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 90D5B7F6A8; Thu, 21 Jul 2016 10:43:01 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6LAgxHY027135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 06:43:01 -0400 From: Hubert Kario To: mrex@sap.com Date: Thu, 21 Jul 2016 12:42:52 +0200 Message-ID: <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8183777.xUpXZBdEHM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 21 Jul 2016 10:43:01 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:47:31 -0000 --nextPart8183777.xUpXZBdEHM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > Hubert Kario wrote: > > Martin Rex wrote: > >> Forget TLS extensions, forget ClientHello.client_version. > >> Both in fundamentally broken, and led to Web Browsers coming up > >> with the "downgrade dance" that is target&victim of the POODLE attack. > >>=20 > >> We know fairly reliably what kind of negotiation works just fine: > >> TLS cipher suite codepoints. > >=20 > > please re-read my mail, they don't: > >=20 > > 49% (6240) are intolerant to a Client Hello with no extensions but > > big number of ciphers that bring its size to 16388 bytes) > > 91.5% (11539) are intolerant to a Client Hello with no extensions > > but a number of ciphers that bring it well above single record layer li= mit > > (16.5KiB) >=20 > You're seriously confusing things here. >=20 > Any ClientHello with > 200 Cipher suite code points indicates fairly insa= ne > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. and which part of the standard says that it is "_perfectly_sane_" server=20 behaviour? =20 > Trying to support theoretical encoding size limits is a stupid idea, > because it leads to endless security problems. Imposing sane sizes > plus a safety margin is solid implementation advice. unlike the endless incompatibility problems? > Large stuff that doesn't need to be exchanged in abbreviated handshakes > should *NEVER* be included in ClientHello, because of the performance > penalties this creates (Network bandwidth for TLS handshake, > and TCP slow start). I suggest you take a look at the key_share extension and what are the size= =20 requirements for PQcrypto key exchanges > >>> I'm now also collecting some data and have some preliminary > >>> suspicion on affected devices. My numbers roughly match yours that we > >>> are in the more or less 3% area of 1.3 intolerance. > >>=20 > >> The TLSv1.2 version intolerance is already a huge problem, > >> and I'm not seeing it go away. Acutally Microsoft created an > >> awfully large installed base of TLSv1.2-intolerant servers > >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, > >> 2012R2). > Please recheck with a vanilla (aka extension-free) ClientHello that > has ClientHello.client_version =3D (3,3), to recognize all TLSv1.2-intole= rant > implementations in your counts. and what about those servers that will abort connection if the RC4 ciphes a= re=20 below the 64'th position in the list? > >> I would really like to see the TLS WG improving the situation > >> rather than keep sitting on its hands. The problem has been well-known > >> since 2005. And the "downgrade dance" was a predictably lame approach > >> to deal with the situation, because it completely subverts/evades the > >> cryptographic protection of the TLS handshake. > >=20 > > it's not IETF's fault that the implementers add unspecified by IETF > > restrictions and limitations to parsers of Client Hello messages or that > > they can't handle handshake messages split over multiple record layer > > messages, despite the standard being very explicit in that they MUST > > support this. >=20 > Nope, not really. Limiting PDU sizes to reasonably sane sizes is > perfectly valid behaviour. X.509v3 certificates can theoretically include > CAT MPEGs and amount to megabytes. A TLS implementation that limits > the certificate chain (i.e. the TLS Certificate Handshake message) to > a reasonably sane size with safety margin, say 32 KBytes in total, > is acting totally reasonable. Anyone who creates an insane PKI deserves > to loose, and deserves to loose quite badly. if it's valid, please point me to the part of RFC that says that. and we're not talking about Certificate message here, we're talking about=20 Client Hello. The absolute upper size limit for it is 131396 bytes. Any=20 implementation that can't process messages that big is simply RFC non=20 compliant. Besides, so what that you can send megabyte sized certificates thought TLS? even if you do consider it a DoS, pausing the ECDHE key exchange with a large curve just before Client Key Exchange message is a far more effecti= ve=20 use of attacker's resources. =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 Republic --nextPart8183777.xUpXZBdEHM 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 iQIcBAABCgAGBQJXkKcsAAoJEJKo0bgB0vX1si4QAJa0EO9BGsW78lRXBu2FaBBv 1a9vJoOlawTzzEtBhet3Nkb4JCrJEG5SY28U7mX+Lc+r221Tsfz4WBrPto3HhyCT 28gws6PkY1DdSumKymANmiiKuv7u/9We+DOFdY++8HgnKgd9e1YSKXHTA4LRIMo4 DbhubbfVgp8Upzq0O1NojCGGFNwLo5oj/uo+604CLAqPD4ZefYUiT0N1vm1ExuZu 2vOtumjnGtRgBODHeyXAtfDGS8sYE27UyGeWuUygtHA7v1FurbR8ov3bnApnLs1g 7JZc4yTOQSPQbXsAeK4fS6T+WhhrEXjXPmKV49ltZhdkDmAQaT2wNJJd4wUlN+wl kBjjgbycX4TO/tcNdEVKSa2Rawf54rwUd8T4O4qfjyI6CRJafb14RoHE8uL+rzhj DrElwf7Bhlzz/1wu1F3F+hF3snGP6zKbZBb+QNfiMX+XvhLI2ghEMx9nIZ6ejwPq /NWkRzrzGHPNmAZvb86SEU/T2qYC1AFNsX/U4aOx7LX8wg0kJrOyY9W3thC8XPoh mjk9KR6JB2cNJ2IuVUyOHtGVZXIQG7QGc42+zdy9LOwb/I6BxiH052OqbmlHPmKn 55ie7zX0F/qAuZsGlhlJuX4QuEwmFceIVdvswlsqnAY1d/8IU8iLKdrHZTwXSxYH dKNX+dwJ2CKrrM3FWSMA =V9jb -----END PGP SIGNATURE----- --nextPart8183777.xUpXZBdEHM-- From nobody Thu Jul 21 03:54:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A092012DAF0 for ; Thu, 21 Jul 2016 03:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v11wbVeE4vce for ; Thu, 21 Jul 2016 03:54:13 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id D081112DD18 for ; Thu, 21 Jul 2016 03:52:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3A9F88529; Thu, 21 Jul 2016 13:52:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id m0tW8daMcZhq; Thu, 21 Jul 2016 13:52:50 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id DFF61C4; Thu, 21 Jul 2016 13:52:50 +0300 (EEST) Date: Thu, 21 Jul 2016 13:52:46 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160721105246.GC23702@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:54:15 -0000 On Thu, Jul 21, 2016 at 10:19:34AM +0000, David Benjamin wrote: > On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote: > > > On 07/20/2016 05:01 AM, Hanno Böck wrote: > > > On Wed, 20 Jul 2016 11:20:46 +0200 > > > Hubert Kario wrote: > > > > And as Hubert notes, there may well be other intolerance triggers to clear > through. 1.3 has a larger ClientHello. We have also never added a new > signature algorithm before. But I think that just means we have more rusted > protocol joints fix rather than just the one. Could be useful to scan for SignatureScheme. I think the most worthwhile 6 to scan would be: 0x0003 (ECDSA-NONE in TLS 1.2) 0x0004 (UNKNOWN4-NONE in TLS 1.2) 0x0404 (UNKNOWN4-SHA256 in TLS 1.2) 0x0700 (ANON-UNKNOWN7 in TLS 1.2) 0x0703 (ECDSA-UNKNOWN7 in TLS 1.2) 0x0704 (UNKNOWN4-UNKNOWN7 in TLS 1.2) And then see how many servers do anything retarded with these... -Ilari From nobody Thu Jul 21 05:25:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95712DB7D for ; Thu, 21 Jul 2016 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 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=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pLeG0zQIs92 for ; Thu, 21 Jul 2016 05:25:54 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7A212DB8B for ; Thu, 21 Jul 2016 05:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1469103954; x=1500639954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8Y25ge4mOnv0Sk0WWkW9Jjc0KnRrjPB56y7DhLKOYn0=; b=rU64FbcOGxKKBtSG2yAJB7VS7dgAVMIggVr7SSM6yfFEd8RVXsI6kRi7 oQQbPfpJI3C4vl0mpV7h/jPEgfWpOSlANhdO9nYx4LK3s55CRa0GFdUfb 1+ht0exEJ3iApI66LKNYwWAiaBAIymB1ZHWJTP8fgpqk1TblxTNp3R4NT m+kkXxp1aHZSG5ZTvSfOyEZ9+kbeWjQsYQSe2AssGyzFkm/WF77O4QdS+ +TyDR8W8XOgo84A/hZMIhekjNszPlkHM2PJFlZMKT+I2LgB5h55iQwSqu N4pS9ruBvmG6SMbPlJdBjaN/cV8os+PRxt1j9EfiUroQrmSffUrGcC+2p g==; X-IronPort-AV: E=Sophos;i="5.28,399,1464609600"; d="scan'208";a="98012712" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Jul 2016 00:25:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Fri, 22 Jul 2016 00:25:49 +1200 From: Peter Gutmann To: "mrex@sap.com" , Hubert Kario Thread-Topic: [TLS] Thoughts on Version Intolerance Thread-Index: AQHR4OTM2eSp/VUo4Ee5kqtv5bpkQaAdX+GAgALlKQCAAAtbgIAAA4WAgAAnswCAAFI+gIACBjhZ Date: Thu, 21 Jul 2016 12:25:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CCF7C1@uxcn10-5.UoA.auckland.ac.nz> References: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com>, <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> In-Reply-To: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] 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] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:25:58 -0000 Martin Rex writes:=0A= =0A= >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.= =0A= >X.509v3 certificates can theoretically include CAT MPEGs and amount to=0A= >megabytes.=0A= =0A= We really need a TLS scanner that does this just to see what happens. When= I=0A= created that cat-MPEG cert, I fed it to both MSIE and Netscape. Both happi= ly=0A= accepted it, and then essentially become nonfunctional because although the= y=0A= saw nothing wrong with accepting a cert of that size, they couldn't actuall= y=0A= deal with it. In Netscape's case I had to delete the .db file before it co= uld=0A= be used again. I wouldn't be surprised if you can quite effectively DoS=0A= assorted TLS implementations with stuff like this.=0A= =0A= (This is one of the design features of TLS-LTS, if both sides do -LTS then = the=0A= Hello only needs a single extension to specify everything. Combine that wi= th=0A= PSK, so no certs, and you get quite an efficient protocol, the only thing o= f=0A= any size is the keyex and server signature).=0A= =0A= Peter.= From nobody Thu Jul 21 05:35:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B681112DA66 for ; Thu, 21 Jul 2016 05:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Aeo7YT2HoGs for ; Thu, 21 Jul 2016 05:35:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD0C12D65F for ; Thu, 21 Jul 2016 05:35:39 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C10363B720; Thu, 21 Jul 2016 12:35:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6LCZbBs003133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 08:35:38 -0400 From: Hubert Kario To: Peter Gutmann Date: Thu, 21 Jul 2016 14:35:32 +0200 Message-ID: <3605304.gtMSxrymAa@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CCF7C1@uxcn10-5.UoA.auckland.ac.nz> References: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4CCF7C1@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3368602.uRosMLnluf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 21 Jul 2016 12:35:38 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 12:35:48 -0000 --nextPart3368602.uRosMLnluf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote: > Martin Rex writes: > >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour. > >X.509v3 certificates can theoretically include CAT MPEGs and amount to > >megabytes. >=20 > We really need a TLS scanner that does this just to see what happens. Wh= en > I created that cat-MPEG cert, I fed it to both MSIE and Netscape. Both > happily accepted it, and then essentially become nonfunctional because > although they saw nothing wrong with accepting a cert of that size, they > couldn't actually deal with it. In Netscape's case I had to delete the .= db > file before it could be used again. I wouldn't be surprised if you can > quite effectively DoS assorted TLS implementations with stuff like this. if you have such certificate, you can use this script from tlsfuzzer to tes= t=20 if server won't explode by processing it: https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-rsa-sigs-on-= certificate-verify.py (I haven't tested if it actually can send a 2MiB large certificate, but in= =20 general there are no limits in tlslite-ng or tlsfuzzer, so it should work j= ust=20 fine, bugreports welcome if that is not the case). =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 Republic --nextPart3368602.uRosMLnluf 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 iQIcBAABCgAGBQJXkMGUAAoJEJKo0bgB0vX1+/AP/2h0+MNBzEV6sRDn14wQGSIy 7RV3eE1VFQfRF5APjV1Fp912gIPXqgmlc4u3uFnDnfxJDa4M6DElAkATOwzUvEBa C6f0CfNH7L9yD5Ni4NC5lEg0vJhYY5dlcKl2KGcTB7VeeZQa81jSLT0cJiyeitqF Bvx7tp8PIizZMJGM8vKcUphyIDr88MzFjZxFfigHRav4SlhMLs8rK/0gvtYn/at9 rP0xk+GaBDh4xtfwEx2w0u0A8RYTlLtpVCBbSM9cF2RQYO6dWUL5yb4GTVxhfHTS 98FsPR3Q2hPt2dTgHuhx/2zadfQwQ0fLKtPG/cojoYSWP5meW9D/rvZnVacN/i+n 2Tr8BNiqOhiivxWgMy+IqFa6Ya//omt66x8yu3zCrkIqvWgYx7SsvWMoWSWoFc7J WdJBv2sgeuXwGCkoS9N+Cwi1kppXqtlh4KG5i/HjygFXzH2uYZ7CqglNwwyvzMFz Oxq229w9rBfoiU83Q7qPl7lFKq+jGdRUPGeBgcWxehDQQ226Sy+1DOPVfN1D275B tKT3yJMtRQ/JMYfX3qyMD336FYKDVzQ9LMVKtkeMfZNDMPyh0UMGAl5Z8Jl2n7It XHLsqDad6ELmHwDqbyatq2rM0G8NuEVLthmVw3sWLJ8ULE7CY5YyRv7g6bOUPsMN fbbBW2UTMr1GSMKEQanh =5aV4 -----END PGP SIGNATURE----- --nextPart3368602.uRosMLnluf-- From nobody Thu Jul 21 08:57:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37412D66A for ; Thu, 21 Jul 2016 08:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6C67U2uTlIs for ; Thu, 21 Jul 2016 08:57:16 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C1B120727 for ; Thu, 21 Jul 2016 08:57:15 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 3rwJLx6430z25QZ; Thu, 21 Jul 2016 17:57:13 +0200 (CEST) X-purgate-ID: 152705::1469116633-00000827-3B10B377/0/0 X-purgate-size: 699 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rwJLx3k6Szkw0G; Thu, 21 Jul 2016 17:57:13 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 795ED1A504; Thu, 21 Jul 2016 17:57:13 +0200 (CEST) In-Reply-To: To: Mike Bishop Date: Thu, 21 Jul 2016 17:57:13 +0200 (CEST) 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: <20160721155713.795ED1A504@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 15:57:18 -0000 Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs. > > We have also discussed that it might be preferable to pull part of this > capability back into TLS, You are facing a MUST NOT in rfc6066 for this particularly bad idea. I'm currently wondering what kind of (weird) TLS session caching strategy would actually allow you to create such client or server behaviour. You're definitely in severe conflict with the "principle of least surprise" in respect to deterministic behaviour of your TLS clients and TLS servers. -Martin From nobody Thu Jul 21 09:08:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32012D528 for ; Thu, 21 Jul 2016 09:08:57 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQcfA7orMlvh for ; Thu, 21 Jul 2016 09:08:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA17E12D50E for ; Thu, 21 Jul 2016 09:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5bxMHk/ngWLvtfTv6JLUupNyzXHlmocgCzgNnSLIYjo=; b=KT8EfGa6WmrbiX1HHasVN7locx7Cy7P3hiqxthLNnFXNGkuqFs+AnVyzEnqM8QwbCTtGXL8PjV6HeQB05ngD23vgrUhlp7WwMcxpT9zT0kELtQ8utQgaSMAaPAKOGNcJECmvIPMW0I66GPMmIcNxaT6vJvpa7OJnLPa7tMrS0qM= Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1329.namprd03.prod.outlook.com (10.163.80.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 16:08:52 +0000 Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 16:08:51 +0000 From: Mike Bishop To: "mrex@sap.com" Thread-Topic: [TLS] HTTP, Certificates, and TLS Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7swAPA9OAAAARPNA= Date: Thu, 21 Jul 2016 16:08:51 +0000 Message-ID: References: <20160721155713.795ED1A504@ld9781.wdf.sap.corp> In-Reply-To: <20160721155713.795ED1A504@ld9781.wdf.sap.corp> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:67c:370:176:31a0:98ff:53f5:8cf7] x-ms-office365-filtering-correlation-id: 93d1c3c7-6bfb-4647-0dca-08d3b1814eb8 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1329; 6:g+CF8chI68xH6BWkmJGSkyEVLVd/BgH2RHgOGEnfjOHUNXpZParY7crW38KtLDB4v6EdN378P4hogFiLnb+naSebaF1mwXL9zcIeHLXZAR67kJz9Nn17tf2olszU2qjpjIV70prFSyplT+NSxLPksbkbfmIlstdR/dtrRSlnib1F4VVHupSWZvZNDYpVA6dD3z0fJjhgk5zZgygt1AACmzY4NBtZ3nqhaTRCc/O85JXvPslhSyVy9LPPgdo7x+sokzSMigsYGmG/di215aBmbDXX02H/4DUlv2lh5yJhBzVswk9ASoMy89enebQy7N6aDJom69ZU3oMTSYj1Yw59Vw==; 5:myOTjeC7PkMkOZOx41gfPzVHwlEc1rE0M4E33GztTA5COT7i+evoDAvBUl31eo3nGCpkS/9b3vdAxmWJYtUByzii34NiYtlkjSF0dv4Wavd5mos8aMMfSyVh/i82Iw+/kJfzzEDQRHcgNSt99NZ0XQ==; 24:UTiTAjp1ym78+EHq6Tsdz/B7YDqeH1FiphPl4UCY/H8Pvh8jJ+RLQoTDbcTe8ey6GiiXIyqcEf351t/cm5ELMXSi0dqK+8/csXDTlbgUvSs=; 7:ze8d08wqbWKvUU+qQ+P3RH66AJcrZbvKqkYoNlQGaFIJPeLPwEvjdgHQcEh9vPCVtAmoRIeBP9cdoEm4EtOku+kVEDQKn6ppaTP+BC9M/1k0jaiUcAPanoFCp205J/TrdbGUd8DGB1ju+CxBg3KyUlx7BdjAfOVPdi7/DLsbdTcBoR4IjTTUr2iRqg9E/K4UMgazOJAZ2Z2+W0TelZ3uNLfB/N2/SyE3r1Ly+KTnHfexxa9wK/IJfk37GOJV8TLa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(55761251573089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(13464003)(86612001)(99286002)(97736004)(2950100001)(2900100001)(2501003)(8676002)(561944003)(189998001)(101416001)(16236675004)(81156014)(9686002)(68736007)(8936002)(87936001)(33656002)(1730700003)(92566002)(81166006)(50986999)(76176999)(54356999)(3280700002)(122556002)(110136002)(19625215002)(19300405004)(7906003)(7696003)(74316002)(7846002)(5003600100003)(5005710100001)(7736002)(8990500004)(10400500002)(8666005)(86362001)(19580405001)(790700001)(3660700001)(5002640100001)(10090500001)(10290500002)(2351001)(102836003)(6116002)(5640700001)(586003)(5630700001)(77096005)(105586002)(15975445007)(4326007)(2906002)(76576001)(19580395003)(19617315012)(106356001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329; H:BLUPR03MB1330.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 16:08:51.5962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:08:57 -0000 --_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assume you're referring to Section 3, SNI's ServerNameList MUST NOT conta= in more than one name of a given type? Technically, we're not violating th= at, since we're not changing SNI. The client requests a single identity in= the TLS handshake, which the server provides. Additional identities can b= e demonstrated later, regardless of where. Or are you referring to the (lower-case) must not resume if SNI and the cer= tificate used in the resumed session differ? For HTTP, we're leaving resum= ption out of the picture, requiring that any secondary certificates be prov= ed anew for each connection. You're certainly correct that if the logic we= re moved to TLS, the semantics of resumption would have to be defined. Tha= t may be a solid argument on why it should remain at the application layer. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Thursday, July 21, 2016 5:57 PM To: Mike Bishop Cc: tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs. > > We have also discussed that it might be preferable to pull part of > this capability back into TLS, You are facing a MUST NOT in rfc6066 for this particularly bad idea. I'm currently wondering what kind of (weird) TLS session caching strategy w= ould actually allow you to create such client or server behaviour. You're definitely in severe conflict with the "principle of least surprise" in respect to deterministic behaviour of your TLS clients and TLS servers. -Martin --_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I assume you’re referring to Section 3, SNI= ’s ServerNameList MUST NOT contain more than one name of a given type= ?  Technically, we’re not violating that, since we’re not = changing SNI.  The client requests a single identity in the TLS handshake, which the server provides.  Additional identities can be d= emonstrated later, regardless of where.

 

Or are you referring to the (lower-case) must not= resume if SNI and the certificate used in the resumed session differ? = ; For HTTP, we’re leaving resumption out of the picture, requiring th= at any secondary certificates be proved anew for each connection.  You’re certainly correct that if the logi= c were moved to TLS, the semantics of resumption would have to be defined.&= nbsp; That may be a solid argument on why it should remain at the applicati= on layer.

 =

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS

 

Mike Bishop wrote:

>

> That means we now have a proposal for carryi= ng both client and server

> certificates above TLS, found at =

> https://tools.ietf.or= g/html/draft-bishop-httpbis-http2-additional-certs.

>

> We have also discussed that it might be pref= erable to pull part of

> this capability back into TLS,

 

You are facing a MUST NOT in rfc6066 for this par= ticularly bad idea.

 

I'm currently wondering what kind of (weird) TLS = session caching strategy would actually allow you to create such client or = server behaviour.

You're definitely in severe conflict with the &qu= ot;principle of least surprise"

in respect to deterministic behaviour of your TLS= clients and TLS servers.

 

-Martin

--_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_-- From nobody Thu Jul 21 09:41:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B600912D7A6 for ; Thu, 21 Jul 2016 09:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w0h2k3ORIJr for ; Thu, 21 Jul 2016 09:41:43 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04F812D79C for ; Thu, 21 Jul 2016 09:41:42 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 3rwKLD69C2z25HF; Thu, 21 Jul 2016 18:41:40 +0200 (CEST) X-purgate-ID: 152705::1469119300-00000827-EE67469B/0/0 X-purgate-size: 722 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rwKLD3zg8zkwxl; Thu, 21 Jul 2016 18:41:40 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 822601A504; Thu, 21 Jul 2016 18:41:40 +0200 (CEST) In-Reply-To: To: Mike Bishop Date: Thu, 21 Jul 2016 18:41:40 +0200 (CEST) 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: <20160721164140.822601A504@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 16:41:46 -0000 Mike Bishop wrote: > > I assume you're referring to Section 3, SNI's ServerNameList MUST NOT > contain more than one name of a given type? > > Or are you referring to the (lower-case) must not resume if SNI and the > certificate used in the resumed session differ? My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT. Last paragraph on page 7, rfc6066 (TLS extension server_name_indication) https://tools.ietf.org/html/rfc6066#page-7 A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. -Martin From nobody Thu Jul 21 09:45:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B78D12D596 for ; Thu, 21 Jul 2016 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvGv8Aw2tUTt for ; Thu, 21 Jul 2016 09:45:00 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AC512D565 for ; Thu, 21 Jul 2016 09:45:00 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p74so78927989qka.0 for ; Thu, 21 Jul 2016 09:45:00 -0700 (PDT) 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; bh=JDFz2NTStsbl5KHqTbZvkH6z/5FCPdoUYDTqsFTwOq8=; b=sEiNE5CEyudPBO9fLSv9fwuuZ9PJxdCLXtGjwDbMbMFo28/fEph0TZoakjYD4bRR9k AUcv4oInSmFEnCK/rLO9uaSSXN0EXp7FRkE892tt6Cmm9TaK7CR7EuBikXPm0jIoke0t yPbQV5m866SVsM+dkGNu0DEzYIhUL4E/+6Qvim3LhGACFqQvmvUigACX/fI9QhGp4xXK ToACFebGVNqMwXkjz59xMPqwU+lwve2kufOUrOaHSPUEfNmX66oaTku9Ajn1wcA3SZ7f /asULzS9TZ33WxbMqSkqFvWjOLhW5F78ido/RmUi6k/LrFuVblBhWDFXwozUjfqdFky7 TD3Q== 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; bh=JDFz2NTStsbl5KHqTbZvkH6z/5FCPdoUYDTqsFTwOq8=; b=QarvfQ7QUILxBDHroB5Gk9sOPArWW4l+BOPKe1qeaCAuNCi1jEwwD1aXjE+H2qUz3q j2ySVLgKnO0dol2LxTL+o3tQtLRTZwf20ibzgZE31Kfqj6v3h0ddzqvrOjXRgtvPGtfb VAual/FMV4ETWJG1hXKRhFvPHUzITE3oSCV65sbVjF0D0SRqijQXPI2BuNQ1HlfjkvBv 0XbuRIaBaghDWhvEih+IC3mGQNoQ8cDN60uIiZTOJclaCNtvWblALqIjxvu24IeLRJhc 6/ZSpj5P0h1hsB1hKEGeimzF2AS0erqPX+Kp+oqT2vZOtd2SJiHh/xp5o1gyPTK4tWq4 e/sg== X-Gm-Message-State: ALyK8tJ6oHHs6FoerZPxu6SaJr4kK0p3iVDOB1ymVpwOkq27yyITCgwPMwpK9Ease7SMgkpfeDJr6T1I3awpHA== X-Received: by 10.55.147.70 with SMTP id v67mr56581895qkd.32.1469119499781; Thu, 21 Jul 2016 09:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 21 Jul 2016 09:44:59 -0700 (PDT) In-Reply-To: <20160721164140.822601A504@ld9781.wdf.sap.corp> References: <20160721164140.822601A504@ld9781.wdf.sap.corp> From: Martin Thomson Date: Thu, 21 Jul 2016 18:44:59 +0200 Message-ID: To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:45:02 -0000 On 21 July 2016 at 18:41, Martin Rex wrote: > A server that implements this extension MUST NOT accept the request > to resume the session if the server_name extension contains a > different name. Instead, it proceeds with a full handshake to > establish a new session. If that's the only barrier to doing this, I'd be surprised. The prospect of having to overcome this is not at all daunting. From nobody Thu Jul 21 09:51:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71D512D7C3 for ; Thu, 21 Jul 2016 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azXskeSIiUcg for ; Thu, 21 Jul 2016 09:51:28 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0101.outbound.protection.outlook.com [104.47.40.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0293B12D75E for ; Thu, 21 Jul 2016 09:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lPxuoWyNsuLcrdGJddR+kWu96DPRlFuE8sK8TCaUWvs=; b=K9+Wq1m9/ruYuwRrhrsP+Fh+CfI0rSu0Xi9c58GlCHfLsJO5O2sHmPRpA54xl42iO13rBY87Shpr4xD5Fvw8kySK/V83+r0F0nOAard86RxfjvwcS0s4n9j/EZ//AbA+0HY7cSlUMhQ1kVMMXjXQYooPZQ2hCUW6itN16BAWz6M= Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1329.namprd03.prod.outlook.com (10.163.80.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 16:51:25 +0000 Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 16:51:25 +0000 From: Mike Bishop To: "mrex@sap.com" Thread-Topic: [TLS]HTTP, Certificates, and TLS Thread-Index: AdHjb+pTj8yF87I8SMmcC0b14GDBNg== Date: Thu, 21 Jul 2016 16:51:24 +0000 Message-ID: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:67c:370:136:196b:abb1:c6e0:27a3] x-ms-office365-filtering-correlation-id: b87bfa5f-36ef-4672-782e-08d3b1874093 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1329; 6:9UM1pTOYSynFZ66K00YynGmw88N638QokPWEy8OK1LqcAulX3vBg1oU946dUbuOtYHumghYYRLrVX9omQ06zajJ5pf46Rt0XSSVWbsn43GprRMTWPbqvRpbiPUeWStMfEp/w2TgsVcV0T4+1LJohrAY2iP6j4ljbKhH1ksG6l+aVieLSx4PS3ZQWV5P6qHa1gmhNbptnAhOxLmvFdc7ib5WFlDZpPvTgdoJn1Htqzl9RCt5BPqdWTKNwjEltbwgt/ERGJBU/pQ5sMRa96uquF8W/o92vaghl0WnlPheWoiidV9jJ6YsulbiZldU1igAFY4TFGm/vB0pKcWy6kxN24g==; 5:JALEHE37hE5/tT4tpaIn1Nkl8zatDS/DWDv4e2MxL23QU4mxzTV9002spE+4bzeiXSc6WWdA+7FOGXuP+ZxmFiVc0KQUGVRtW7OA5nzCAZ1i/2a9sCPOfF6fvIfWwVH4nd1syosHwZEVNMzCWW+cXg==; 24:Pgtc8oFOv0bcb0diFvaOhlMx0s+nmbi84sAdp7x2rbyTzIsKsvoxeXmY05hlAcB8/VzQ9HNgaRNcTuBbwnqB08bQsgO2Sf4twVvltWgbnR4=; 7:cNiG0lWoByoPi7U6W2u57n/CKk7W1oC185VMRFJdvjf9RPd8VA0jgjaVkHu3p9IfR+h05JdK5Q7oe8HrlICZBYovlchKQnZZMeecLTwazhLxBnX6YFyZGiewW0RXMaBu73iNS6jAr/GG/x/7X1yLslmsWdOFJttdplw7r6KkZbx+qLwTua5FfBeNWXMPwiN2Fhj4i/jKFBNwzvdlIWwhcg1fgyps49v6CxcG2MeAw5txgQHe6DSrqDDAEkdiIDnT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(189002)(199003)(24454002)(7736002)(8990500004)(8666005)(86362001)(10400500002)(5003600100003)(19580405001)(5005710100001)(7846002)(2351001)(6116002)(102836003)(3660700001)(10290500002)(10090500001)(5002640100001)(122556002)(3280700002)(7696003)(74316002)(305945005)(110136002)(2906002)(76576001)(4326007)(11100500001)(106356001)(19580395003)(586003)(5640700001)(105586002)(77096005)(15975445007)(2900100001)(97736004)(2501003)(86612001)(99286002)(33656002)(8936002)(68736007)(87936001)(1730700003)(54356999)(81166006)(92566002)(50986999)(9686002)(81156014)(101416001)(8676002)(189998001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329; H:BLUPR03MB1330.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:99 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: 21 Jul 2016 16:51:24.9177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:51:29 -0000 Ah, I was seeing the lower-case version in Appendix A from a quick search. = Yes, that one is upper-case. Still, that seems simple enough to handle in whatever discussion of how res= umption affects this. If they remain in effect across a resumption, any na= me in that set could reasonably be valid; if not, then only the name on the= certificate is originally valid. >From an HTTP layer, we see this as analogous to a certificate with multiple= SANs present -- if the original connection asked for one name on the cert,= but a resumption asked for a different SAN, is resumption permitted? This= seems to suggest that it's not, and to strictly obey that requires that th= e server remember which of several hostnames tied to that certificate was a= ctually used to establish the connection. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, July 21, 2016 6:42 PM To: Mike Bishop Cc: mrex@sap.com; tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Mike Bishop wrote: > > I assume you're referring to Section 3, SNI's ServerNameList MUST NOT=20 > contain more than one name of a given type? > > Or are you referring to the (lower-case) must not resume if SNI and=20 > the certificate used in the resumed session differ? My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT. Last paragraph on page 7, rfc6066 (TLS extension server_name_indication) https://tools.ietf.org/html/rfc6066#page-7 A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. -Martin From nobody Thu Jul 21 10:08:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7312D7BC for ; Thu, 21 Jul 2016 10:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j1bjhRNX0BB for ; Thu, 21 Jul 2016 10:08:07 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CA712D7B2 for ; Thu, 21 Jul 2016 10:08:06 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 3rwKwj2PPVz25MZ; Thu, 21 Jul 2016 19:08:05 +0200 (CEST) X-purgate-ID: 152705::1469120885-0000082D-59ED423E/0/0 X-purgate-size: 2066 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rwKwj0Cd9zkjtp; Thu, 21 Jul 2016 19:08:05 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id F38B01A504; Thu, 21 Jul 2016 19:08:04 +0200 (CEST) In-Reply-To: To: Martin Thomson Date: Thu, 21 Jul 2016 19:08:04 +0200 (CEST) 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: <20160721170804.F38B01A504@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Mike Bishop , "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jul 2016 17:08:08 -0000 Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex wrote: >> A server that implements this extension MUST NOT accept the request >> to resume the session if the server_name extension contains a >> different name. Instead, it proceeds with a full handshake to >> establish a new session. > > If that's the only barrier to doing this, I'd be surprised. The > prospect of having to overcome this is not at all daunting. No, that is only the tip of an iceberg, and you're going Titanic here. Really, this is about TLS session cache management (which is something very close to TLS) vs. Endpoint identification, i.e. interpreting end-entity certificates -- which is something that is explicitly outside of the scope of TLS (e.g. rfc2818 and rfc6125). Could you please describe the approach to session cache management that you're conceiving here? In the original TLS architecture (up to TLSv1.2) TLS sessions are read-only after creation, and identities (certificates) are locked down. Forgetting to cryptographically bind the communication identities into the session properties allowed the triple-handshake-attack. If you want to change any session properties (including certificates), you MUST perform a new full handshake, which creates a new session with new properties and a new session ID / session cache entry. Session resumption (and session resumption proposal) should operate based on requested properties (is there an existing session with the requested properties?) and this is conceptually independent from the app-level endpoint identification (such as rfc2818/rfc6125). The wording in rfc6066 is not optimal. It should have better said: whenever a full handshake would result in selection of a different server certificate, then the server MUST perform a full handshake, in order to produce predictable/deterministic behaviour that is not side-effected by session cache management / session cache lifetime effects. The principle of least surprise. -Martin From nobody Thu Jul 21 10:14:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514C12D7D5 for ; Thu, 21 Jul 2016 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJFnwCMCVg-I for ; Thu, 21 Jul 2016 10:14:25 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0091.outbound.protection.outlook.com [104.47.33.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12CE12D7D4 for ; Thu, 21 Jul 2016 10:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qPUOy+zaMEfZ/F5tKSH/dS/5Kasg64dwYNp02/BUHCQ=; b=LjCoX4rYKWUrjqlV8Z/yZhAfLh+0FC3BRayK4dS2IzCLzdG79zi9eY+RVpPsRh4TvC/m1KLaBw7s2MB3wqHAusdvkv1b5HSFCJj8cBKmG5ptS5VhxJ5yAR/UManivVrvgZjPWotycSbravtygBh4D3gkDw0TbtlV04cqFMOf87M= Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1329.namprd03.prod.outlook.com (10.163.80.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 17:14:22 +0000 Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 17:14:22 +0000 From: Mike Bishop To: "mrex@sap.com" , Martin Thomson Thread-Topic: [TLS] HTTP, Certificates, and TLS Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7swAPA9OAAAARPNAAAXwuAAAAHaeAAADOYgAAACLRkA== Date: Thu, 21 Jul 2016 17:14:21 +0000 Message-ID: References: <20160721170804.F38B01A504@ld9781.wdf.sap.corp> In-Reply-To: <20160721170804.F38B01A504@ld9781.wdf.sap.corp> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:67c:370:136:196b:abb1:c6e0:27a3] x-ms-office365-filtering-correlation-id: 09b57e60-8e82-4810-23e7-08d3b18a7543 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1329; 6:q3Y/v1PFgD7qYiIs8RkZO+W23McPt3Y8FhOH7eXiP0sXn07wyX58Jlp8BQxTrum/5JsNjPpXtBy0pZo86tnr5GPZd1uHM+ZKCqny3VjhOxGOCMJjHAEvKze88O8QbEisuV4lvN8VvJ/RTDqzLQ9hkwaaXbMfPZNoH1wM2uqNJp8fUIazXYk7jSbp0goORaPB1FYfQzJUD2q+/AxOccBUAwqCfsIv9jZHdEevu//7hFM5Dyo9C5KlD9ClYvEVz9dOSG6Xq1eBBsktE4SczQKVfX25PQok6i8jqx36M8yVGzjPvILAGStCjKtKCrJJdeGB5vX7CVZ5Czf+q6qkK97gXg==; 5:5/KKaOn25IelqRdpmUrgKQPBYP+iwjjRhnXVO/+bT6xQmK4GaQ1mMuJ4hR6rCwwzcKx3RNDMk1yfgT3GMPK9dQlTg94cu38MpCbqIVgKy2AeHKczcQ76obZ5UNK7OQZRlwSSlgRYmFD21T5OSbdylw==; 24:+ecDcHytxXjzt03EF7gp0vvnb7AXlzHaklndSR+N2+s3kuSGI9ueSyq1qJs8S4lUjSGZ2YSzH7tac0qAX68VJ6zaicNyC7fQIPGv84xCoCs=; 7:3cw/UERtFOcc8sTT5y9afIjPWZMb/dgW7Fd3Iwy088lOsq8jsf/4+TwPxLWWDNwoKmOCLKMpN0ABm4xTVj4G31dlv6JyBzA846y2GHWh+HFYiHnEJ7OGA8w5nmF/2u8gX/ADrZVJEckpBIKWticcqiIN2LNWk/e0M3Z3tB2YVUCuM3+7nZLFcQx6bylAa+jQgQQU5h0KeZU+zFrI7GHT9PnV6dJW2/9viLnypSA8+GXqm7Q76b9LYMAcnlPJWelR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(189002)(199003)(24454002)(7736002)(8990500004)(86362001)(10400500002)(8666005)(5003600100003)(19580405001)(5005710100001)(7846002)(102836003)(6116002)(3660700001)(10290500002)(10090500001)(5002640100001)(122556002)(3280700002)(7696003)(74316002)(305945005)(2906002)(76576001)(11100500001)(4326007)(106356001)(19580395003)(586003)(105586002)(77096005)(2950100001)(2900100001)(97736004)(2501003)(86612001)(99286002)(33656002)(8936002)(68736007)(87936001)(54356999)(76176999)(81166006)(92566002)(50986999)(9686002)(5001770100001)(81156014)(101416001)(8676002)(561944003)(189998001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329; H:BLUPR03MB1330.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:99 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: 21 Jul 2016 17:14:21.9478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 17:14:27 -0000 That argument seems like it would apply to all post-handshake authenticatio= n, unless there's something different about that. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, July 21, 2016 7:08 PM To: Martin Thomson Cc: mrex@sap.com; Mike Bishop ; tls@ietf.org Subject: Re: [TLS] HTTP, Certificates, and TLS Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex wrote: >> A server that implements this extension MUST NOT accept the request >> to resume the session if the server_name extension contains a >> different name. Instead, it proceeds with a full handshake to >> establish a new session. >=20 > If that's the only barrier to doing this, I'd be surprised. The=20 > prospect of having to overcome this is not at all daunting. No, that is only the tip of an iceberg, and you're going Titanic here. Really, this is about TLS session cache management (which is something very= close to TLS) vs. Endpoint identification, i.e. interpreting end-entity ce= rtificates -- which is something that is explicitly outside of the scope of= TLS (e.g. rfc2818 and rfc6125). Could you please describe the approach to session cache management that you= 're conceiving here? In the original TLS architecture (up to TLSv1.2) TLS = sessions are read-only after creation, and identities (certificates) are lo= cked down. Forgetting to cryptographically bind the communication identiti= es into the session properties allowed the triple-handshake-attack. If you want to change any session properties (including certificates), you = MUST perform a new full handshake, which creates a new session with new pro= perties and a new session ID / session cache entry. Session resumption (and session resumption proposal) should operate based o= n requested properties (is there an existing session with the requested pro= perties?) and this is conceptually independent from the app-level endpoint = identification (such as rfc2818/rfc6125). The wording in rfc6066 is not optimal. It should have better said: whenever a full handshake would result in selection of a different server c= ertificate, then the server MUST perform a full handshake, in order to prod= uce predictable/deterministic behaviour that is not side-effected by sessio= n cache management / session cache lifetime effects. The principle of leas= t surprise. -Martin From nobody Thu Jul 21 11:00:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64C12D768 for ; Thu, 21 Jul 2016 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAu-7nlyqvEk for ; Thu, 21 Jul 2016 11:00:03 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE3E12D0B5 for ; Thu, 21 Jul 2016 11:00:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 14F7284BE; Thu, 21 Jul 2016 21:00:02 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id CqZgM4mIAvIa; Thu, 21 Jul 2016 21:00:01 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 484DF2315; Thu, 21 Jul 2016 21:00:01 +0300 (EEST) Date: Thu, 21 Jul 2016 20:59:56 +0300 From: Ilari Liusvaara To: Martin Rex Message-ID: <20160721175956.GA24593@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160721170804.F38B01A504@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160721170804.F38B01A504@ld9781.wdf.sap.corp> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: Mike Bishop , "tls@ietf.org" Subject: Re: [TLS] HTTP, Certificates, and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 18:00:06 -0000 On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote: > Martin Thomson wrote: > > On 21 July 2016 at 18:41, Martin Rex wrote: > >> A server that implements this extension MUST NOT accept the request > >> to resume the session if the server_name extension contains a > >> different name. Instead, it proceeds with a full handshake to > >> establish a new session. > > > > If that's the only barrier to doing this, I'd be surprised. The > > prospect of having to overcome this is not at all daunting. > > No, that is only the tip of an iceberg, and you're going Titanic here. > > Really, this is about TLS session cache management (which is something > very close to TLS) vs. Endpoint identification, i.e. interpreting > end-entity certificates -- which is something that is explicitly > outside of the scope of TLS (e.g. rfc2818 and rfc6125). > > > Could you please describe the approach to session cache management that > you're conceiving here? Well, I guess it would be reasonable to remember the server identites on client side, but clear client identities on server side. Especially the client identies are highly important: If the server thinks any identity is valid that client thinks is invalid, that will lead to attacks. > In the original TLS architecture (up to TLSv1.2) > TLS sessions are read-only after creation, and identities (certificates) > are locked down. Forgetting to cryptographically bind the communication > identities into the session properties allowed the triple-handshake-attack. No, THS was caused by failing to bind the exchange keys (I consider the abstract of EMS RFC to be quite misleading). > If you want to change any session properties (including certificates), > you MUST perform a new full handshake, which creates a new session with > new properties and a new session ID / session cache entry. And thanks to all sorts of crypto restrictions, exchange keys have nothing to do with certificates of any kind (all modes where they have anything to do are banned), and that the exchange keys are properly bound. > Session resumption (and session resumption proposal) should operate > based on requested properties (is there an existing session with the > requested properties?) and this is conceptually independent from the > app-level endpoint identification (such as rfc2818/rfc6125). > > The wording in rfc6066 is not optimal. It should have better said: > whenever a full handshake would result in selection of a different > server certificate, then the server MUST perform a full handshake, > in order to produce predictable/deterministic behaviour that is > not side-effected by session cache management / session cache lifetime > effects. The principle of least surprise. Within context of HTTP, the server authentication is about what authorities the server is allowed to assert. And in responses, the server always needs to pick the authority it asserts. As long as one takes care that no authorities get lost, or that lost authorities can be recovered if needed (and authroized), then the behaviour will remain deterministic (modulo possibly few extra RTTs to recover the lost authroties). Now, client authentication is entierely different beast. The client won't inherently assert its authority in HTTP, so the server view of client authority damn better be subset of what client intended, or you WILL get privilege escalation attacks. >From that it follows that the client needs per-request control of authorities it holds (if to assert them or to disclaim them). -Ilari From nobody Thu Jul 21 13:04:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943B212D7A4 for ; Thu, 21 Jul 2016 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=1.326] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta_vM2TJemp6 for ; Thu, 21 Jul 2016 13:04:34 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A838912D83C for ; Thu, 21 Jul 2016 13:04:28 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id 52so50413584qtq.3 for ; Thu, 21 Jul 2016 13:04:28 -0700 (PDT) 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-transfer-encoding:message-id; bh=e3uzpYIhh1TQPJEgc9veTyYl0Y8JuLqwDZ+29Ec/wdo=; b=XIjnMNc2QZLk8TK14pE5ORz1IdjuO20HrSZtqoGH97KU7egiUf8wR6Y8ANV67X17dV /LPa3e5mF/ZTwd4V+08nvv4r6S+v9ZZkh6IapVXp6+7JiXj0Vk3sp3E9gqisjnskVLuW +1kVsvV2WjjxPPEjF4Vr6yxc50QURDH31ZRTLcCbw6a05oxCFrOE2WH0cJ9IjAQFs7dL IERBGDZdpQ+COfbTpDEM3sqwwA2I5jH0GxDbmxOqmWqYXSZjXebh8LTOwTYO+HVHFS2K PLh4zG4yYpz/4hxdsZNzCAgOdJvvK0pMIYCS+9loRf0RMnnD+/v1fj+aMI3iZ2hYkSq8 xoqw== 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-transfer-encoding:message-id; bh=e3uzpYIhh1TQPJEgc9veTyYl0Y8JuLqwDZ+29Ec/wdo=; b=SsQVIH/80KYOorgzKs0m0DDL6atAC26ts3Mgf8V+DXqlonpqB1VYHsSAlW3N4vJA1d ACudJ6y8hP/jeLFkd3QMZHJjjMOR3cJ2Kfdim87VlRnLbT770lHRrm0M97EVXnxQ9l73 pvTRjrTbFOe/5p2AnhXw46hlwpUDAGkPAqoMTyJzK+WyyAx6JRCquV72b+8FuYlV4aix B+SGPuQunR0/9QGvZG1k27gh24v/SbWsCeBFjtmxfgCwPTdsMN+YVjKKcnB7GtT5n/WK FpgBxyUbYIbrI0dPvYjmbjUDERH4NoQFvjmJMbSWOSmJhoge7VurXXL/VzafrgIYyOvI uxJw== X-Gm-Message-State: AEkooutIS34ixkAQjBFNsOFzM2INhkIgPZIC0pfNG54c2W7l255dGAo/8qvu4OQMb/+Shw== X-Received: by 10.237.38.35 with SMTP id z32mr109487qtc.69.1469131467827; Thu, 21 Jul 2016 13:04:27 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id p94sm5238003qkp.44.2016.07.21.13.04.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Jul 2016 13:04:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 21 Jul 2016 16:04:25 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> In-Reply-To: <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201607211604.25745.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:04:35 -0000 On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. > > and which part of the standard says that it is "_perfectly_sane_" server > behaviour? On this specific type of issue, I agree with Martin here that sanity checks for over-the-top configurations are reasonable, however we should be standardizing this, not having every implementation do this ad hoc. We really should go through a list of these sort of implementation break points and start picking arbitrary lines to add to the spec. They don't have to be ideal numbers; just something better than an upper limit of 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for this example. Yes, certain fields have to stay open-ended, namely extensions, but reasonable limits should be added where appropriate. Dave From nobody Fri Jul 22 03:16:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712FF12DF93 for ; Fri, 22 Jul 2016 03:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3olQqVPvKWRq for ; Fri, 22 Jul 2016 03:16:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6EA12DF84 for ; Fri, 22 Jul 2016 03:16:40 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 434257733E; Fri, 22 Jul 2016 10:08:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6MA86Rm023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 06:08:07 -0400 From: Hubert Kario To: Dave Garrett Date: Fri, 22 Jul 2016 12:08:00 +0200 Message-ID: <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <201607211604.25745.davemgarrett@gmail.com> References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2282174.zjMWq0J3KQ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 22 Jul 2016 10:08:08 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 10:16:45 -0000 --nextPart2282174.zjMWq0J3KQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 21 July 2016 16:04:25 CEST Dave Garrett wrote: > On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > > Any ClientHello with > 200 Cipher suite code points indicates fairly > > > insane > > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviou= r. > >=20 > > and which part of the standard says that it is "_perfectly_sane_" server > > behaviour? >=20 > On this specific type of issue, I agree with Martin here that sanity chec= ks > for over-the-top configurations are reasonable, however we should be > standardizing this, not having every implementation do this ad hoc. We > really should go through a list of these sort of implementation break > points and start picking arbitrary lines to add to the spec. They don't > have to be ideal numbers; just something better than an upper limit of > 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for > this example. Yes, certain fields have to stay open-ended, namely > extensions, but reasonable limits should be added where appropriate. I don't think that limiting the client hello by just under 2^16 bytes will= =20 help much. =46or memory-limited applications, simply not noting the presence of unrecognised/unsupported ciphers is an easy and robust way of handling h= uge=20 cipher lists. So limiting it doesn't help much. As you've pointed out,=20 extension list needs to stay unlimited. There's nothing else - session_id=20 already is tiny and compression_methods is just a drop, everything else has= =20 static sizes. I'm quite sure that if I were sending a huge extension or many big extensio= ns,=20 the percentage of servers that are incompatible to them would be similar, i= f=20 not worse. A relatively small 3KiB client hello already causes issues and t= his=20 is not exactly something impossible to achieve with just TLSv1.2 and sessio= n=20 tickets.=20 (I'll try to have more concrete numbers on Monday) =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 Republic --nextPart2282174.zjMWq0J3KQ 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 iQIcBAABCgAGBQJXkfCAAAoJEJKo0bgB0vX1OnoP/0D7AzABJgMccIVaiWTe+S0g mnCR6I67ynNXLpS/CunrSvYq2QPKGJ2cYcmqYod53m6ax+Ut+qNsfcDEdFT8HpwX N+gjJzd2XaH29OkODOAVG2k04C+4mwy+GqcKn5nCjohZ/yGSlZitRQiDRovfDDMA GhlFRuKl6khVS+5vOM63Kkv4ybRqtsKbUpgU8DLTQVW3q2MTWwk1huu7dvw1dqOi MhdNUHzKbOYNWjs9a7EHEy7J5KZBIjdB0QcuTRNLnsIUaImWqgEvvzhAHUczJjNm 9IIWKkXG0KfW/AmFB/TngdZ1iXOk7pJuAqD7Gx2T92GIwX8KHqdd434bsHYg9hSf yjDZJLR8QA5t+btPo9A5APSO9q+dumBQHPO/Ktp4/45Czrt3HJt3bw9UI1TN/BRT PALagU/F4gSj54fsWqtTkmOaEnFqS0AWz/9010A4P/Zmp9grXqBle93zgWOC4pTM yZ9iqBuYdZPApZUdnrnCcx6ock/m/Hv9IcNsRyAmwgok4tOAaanJ3sw/8RD3xfLC UIRRpaTiTfDkpKUfdUcT3IqKguwqLw2iM3oOizoXoIoB21BTyqPgNuXu+im2Q9qu Fz5/9G44C3gg7y89BPeCQ3EE5YS6XtP3CT0Y93lIKDrqjLor64f4jkxyrcotM145 vU41dWhi66dENdeZCo5m =BeL8 -----END PGP SIGNATURE----- --nextPart2282174.zjMWq0J3KQ-- From nobody Fri Jul 22 18:37:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98312DBB6 for ; Fri, 22 Jul 2016 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_TBQhdEhbWC for ; Fri, 22 Jul 2016 18:37:25 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99ED12DBB5 for ; Fri, 22 Jul 2016 18:37:25 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so119643828ioi.2 for ; Fri, 22 Jul 2016 18:37:25 -0700 (PDT) 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:from:date:message-id:subject:to :cc; bh=Ezu4QXGIz6k1JGtFiEt0ei6Bw0wFfb9gwff33RUrKHE=; b=iRfRFnJh0fMdAYyhCFI9omlbyzjRfjaN50lbyjlyj1vIo8DRv4SJp1WQLcVnzIvcMr 7tXJ7K1cT/FB+Qsao+FKI5kaqkMJJHXwyxoyeHgnFYqJjsMuMhZ0cO7BGOyZZED2rAbI xH+F5MNnxwoaSUxdE9GqLB/2QnF7FbLrZqjaYpfK55UILEGLZoeRB0UHCKEtrRxxmugJ 1RBjVDrvjoA+Dqa36w0Z6wlB6UdUl0DqKRGAUpzvpJ29AeeKhTPl39nt3nDvSLhmVUem WGua35lZKK2djFmnV9e0aPX0CmzptGfmknQTrbWn/xoV3k70L1jycTK0dNZfO2J5b04q KJlA== 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; bh=Ezu4QXGIz6k1JGtFiEt0ei6Bw0wFfb9gwff33RUrKHE=; b=JxpLYENzUlf2qnv0yH0BuXWoRY/vEjgnswpkSSheWguU+woW1MkqZm01jIVkg2YS2n YTvBgSVFJDN2Gm4qrOu8HfjhB2zFjNhflMSlwPfs5ajwDEosX2Skzpeu/gWdXoMqMdaj oFZa6nzER7WJieS7ypN4fCuY56GXG52nb9+o4nlohidUOeh8aJU+pSCWhdrO4GQPj0Mn 2ES8opRMYvwA2pB1Y6nIoNRdJJDDg60r3drs49xG51AyM9pe80n6GEvons3tH1yvq16M GD9MZ7ecg/RjdzvLNXyx29Iw7IrPWu0k7J/JUSKzAmD7dvKFCvFiYDm65Au1EDPjRYNd v1Dw== X-Gm-Message-State: AEkoouvpxIlL1VMj+DyWOpCMK+kKaiS/FCe0i9GHSGZyyHuaKjEvbh89mXD+0Tdn7JNme40n2DwOenzy8Zi1og== X-Received: by 10.107.55.70 with SMTP id e67mr8189707ioa.51.1469237844979; Fri, 22 Jul 2016 18:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Fri, 22 Jul 2016 18:37:24 -0700 (PDT) In-Reply-To: <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> From: Brian Smith Date: Fri, 22 Jul 2016 15:37:24 -1000 Message-ID: To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 01:37:27 -0000 Hubert Kario wrote: > I'm quite sure that if I were sending a huge extension or many big extensions, > the percentage of servers that are incompatible to them would be similar, if > not worse. A relatively small 3KiB client hello already causes issues and this > is not exactly something impossible to achieve with just TLSv1.2 and session > tickets. Don't expect a server to accept a ClientHello with a session ticket it didn't produce. In particular, a server could very reasonably reject a session ticket larger than the ones it produces, and it might produce only very small ones. More generally, when assessing compatibility, generally it is better to consider only initial handshakes, using the data one would normally send in an initial handshake. And, if you are considering 0-RTT key shares, then it would be better to measure the case where only ECC key shares are used separately from the case where non-ECC (old-school DH) key shares are used. Cheers, Brian From nobody Fri Jul 22 23:03:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2257512D5AE for ; Fri, 22 Jul 2016 23:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nNlAVhlvs7H for ; Fri, 22 Jul 2016 23:03:54 -0700 (PDT) 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 A595212D17B for ; Fri, 22 Jul 2016 23:03:53 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id f93so98256881lfi.2 for ; Fri, 22 Jul 2016 23:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pJsV/dSDdzq8h2epWA6YVLMdlw+UJeIk60Y/lANLDKU=; b=IiDlzCCRgIbmz6Wy7B975i/h9UNCXy/yIj+SPr7pgsK0vOq0k3RaiZVL2cF4X99web D8r3E0gWUWtzEg4PM8VleKusLkj0BJNK8uToVLBqdsDFGgsMQSLptHfBrlop6J/p4q8Z gWbmAwBLvOT6MjDusOLUi9Mhyv1GvI0IbZDjM= 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; bh=pJsV/dSDdzq8h2epWA6YVLMdlw+UJeIk60Y/lANLDKU=; b=JKLuooP/M40CtJZWwMh5kYNgnCd3uPIDG5ifXL1Ut7KasKAS11acNBPySTHg54Kz9t nTgpcBAxES8ssUO2/i0lJoNK3R/rr7QuPdyiKUsx+mdWQARJIS0995qfo9iiRI0kHbfE vARNM7LsGOtjAcBaF6xWq0xDOub7F3o6LKQsfADcWh4KWfxlYtDB4y2eBM737Hlqum/d 1Ve9Thg3yubNWCyBBTnd2AigU3c9Y0GrgUwPwsZNRSFRD10AvClVtjNtSkIQkE0IBaTg xhxbBYdgXXRFyZeL1cv5jvZB6AG9xpfx/gwLBRjz4Ff09rhpkmx3hIlqg1gMAsWg51B2 J/PQ== X-Gm-Message-State: AEkoousCxlPRtX4QwC5ZWstrvX6LBjlmMn1ltcn4NEBBXHvYdQN1GNGI1sgfjYII61F7L7MnibVZaas78SiylZHI X-Received: by 10.25.168.212 with SMTP id r203mr4351665lfe.85.1469253831542; Fri, 22 Jul 2016 23:03:51 -0700 (PDT) MIME-Version: 1.0 References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Sat, 23 Jul 2016 06:03:41 +0000 Message-ID: To: Brian Smith , Hubert Kario Content-Type: multipart/alternative; boundary=001a114032a2b71ecd05384750d4 Archived-At: Cc: "" Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 06:03:56 -0000 --001a114032a2b71ecd05384750d4 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 23, 2016 at 3:37 AM Brian Smith wrote: > Hubert Kario wrote: > > I'm quite sure that if I were sending a huge extension or many big > extensions, > > the percentage of servers that are incompatible to them would be > similar, if > > not worse. A relatively small 3KiB client hello already causes issues > and this > > is not exactly something impossible to achieve with just TLSv1.2 and > session > > tickets. > > Don't expect a server to accept a ClientHello with a session ticket it > didn't produce. In particular, a server could very reasonably reject a > session ticket larger than the ones it produces, and it might produce > only very small ones. > > More generally, when assessing compatibility, generally it is better > to consider only initial handshakes, using the data one would normally > send in an initial handshake. And, if you are considering 0-RTT key > shares, then it would be better to measure the case where only ECC key > shares are used separately from the case where non-ECC (old-school DH) > key shares are used. Indeed I just finished a probe that tested many more handshake variations: 1. 1.2 ClientHello 2. 1.3 ClientHello with all curves predicted[*] 3. 1.3 ClientHello with only X25519 + P-256 predicted 4. 1.2 ClientHello with 1.3 sigalgs 5. 1.2 ClientHello with fake 1.3 version I still need to fully analyze the data and experiment with the servers that behave strangely, but the overwhelming majority of 1.3-intolerant servers are intolerant to just the version. (They fail to connect with only 2, 3, and 5.) (Note that one must complete the handshake to get a full picture. Sending the ClientHello isn't enough. Full analysis pending, but sending a 1.2 ServerHello and failing around the Finished message seems to happen often enough.) I did find one group of servers which is intolerant to the new signature algorithms in some inexplicable way. (It's not as straight-forward as avoiding numbers that end in 0-3 or having too many. Hopefully I'll manage to figure out what's up with them.) I have not found any servers which are sensitive to 2 vs 3. (That said, there is a group in my data which is consistent with being intolerant to large ClientHellos. But every one I've looked at so far was a transient network error in probing. I'll need to re-run a few of these hosts to get better data.) But the one thing that is extremely clear is the problem is ClientHello.version. This should not be surprising. We've done this three times already, and it's always been ClientHello.version. There may be the occasional satellite problem beyond it, but we will never be rid of fallbacks if we continue to try something which reality is desperately trying to tell us doesn't work. David [*] Our implementation doesn't do FFDHE. Although between X25519, P-256, P-384, and P-521, that's decently large. --001a114032a2b71ecd05384750d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 23= , 2016 at 3:37 AM Brian Smith <b= rian@briansmith.org> wrote:
= Hubert Kario <hka= rio@redhat.com> wrote:
> I'm quite sure that if I were sending a huge extension or many big= extensions,
> the percentage of servers that are incompatible to them would be simil= ar, if
> not worse. A relatively small 3KiB client hello already causes issues = and this
> is not exactly something impossible to achieve with just TLSv1.2 and s= ession
> tickets.

Don't expect a server to accept a ClientHello with a session ticket it<= br> didn't produce. In particular, a server could very reasonably reject a<= br> session ticket larger than the ones it produces, and it might produce
only very small ones.

More generally, when assessing compatibility, generally it is better
to consider only initial handshakes, using the data one would normally
send in an initial handshake. And, if you are considering 0-RTT key
shares, then it would be better to measure the case where only ECC key
shares are used separately from the case where non-ECC (old-school DH)
key shares are used.

Indeed I just finished= a probe that tested many more handshake variations:

1. 1.2 ClientHello
2. 1.3 ClientHello with all curves predicte= d[*]
3. 1.3 ClientHello with only X25519 + P-256 predicted
<= div>4. 1.2 ClientHello with 1.3 sigalgs
5. 1.2 ClientHello with f= ake 1.3 version

I still need to fully analyze the = data and experiment with the servers that behave strangely, but the overwhe= lming majority of 1.3-intolerant servers are intolerant to just the version= . (They fail to connect with only 2, 3, and 5.)

(Note that one must complete the handshake to get a full picture. Sendin= g the ClientHello isn't enough. Full analysis pending, but sending a 1.= 2 ServerHello and failing around the Finished message seems to happen often= enough.)

I did find one group of servers wh= ich is intolerant to the new signature algorithms in some inexplicable way.= (It's not as straight-forward as avoiding numbers that end in 0-3 or h= aving too many. Hopefully I'll manage to figure out what's up with = them.)

I have not found any servers which are sens= itive to 2 vs 3. (That said, there is a group in my data which is consisten= t with being intolerant to large ClientHellos. But every one I've looke= d at so far was a transient network error in probing. I'll need to re-r= un a few of these hosts to get better data.)

But t= he one thing that is extremely clear is the problem is ClientHello.version.= This should not be surprising. We've done this three times already, an= d it's always been ClientHello.version. There may be the occasional sat= ellite problem beyond it, but we will never be rid of fallbacks if we conti= nue to try something which reality is desperately trying to tell us doesn&#= 39;t work.

David

[*] Our = implementation doesn't do FFDHE. Although between X25519, P-256, P-384,= and P-521, that's decently large.
--001a114032a2b71ecd05384750d4-- From nobody Sat Jul 23 00:10:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF12112D145 for ; Sat, 23 Jul 2016 00:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtEkfJ0Kyadh for ; Sat, 23 Jul 2016 00:10:30 -0700 (PDT) Received: from BAY004-OMC4S24.hotmail.com (bay004-omc4s24.hotmail.com [65.54.190.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2B412D5E8 for ; Sat, 23 Jul 2016 00:10:30 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com ([65.54.190.201]) by BAY004-OMC4S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 23 Jul 2016 00:10:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5uhWzBiGZUtA7Cdnkkmlo21kAglna1gkqcWxdywulnk=; b=DCkAfs9Vwhcbuf4H4dzUpLVFRj80fcwagq4AyJ10ogXafPyD65/LRfybtstt51YB6piJ42cpwUgcWTcPk4wN4d8jOd/DmahXM+xrRZtuE4ZzcbGtXw5J5cb/h6wU0ip4TLZbHf5djY6dVI/7JGP8HU+19sGKhXI72vH/HTzK8XyQzwh/lI00yybvAhs5ma778lfvaqUEqa9K5JssJKSPogdlByC3n6UHEc2O7TbnlbejHBf3j4Xk3MCGbcDdbpRxj+aD305DN7+/7EgdTddwzX6GbFr0s65bxin/oQ1cSTMqyO/dnWPkZ4hjpWNE/9fiGaHLcrSRyFL09SFuUtYEWw== Received: from CO1NAM03FT036.eop-NAM03.prod.protection.outlook.com (10.152.80.59) by CO1NAM03HT202.eop-NAM03.prod.protection.outlook.com (10.152.81.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sat, 23 Jul 2016 07:10:29 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com (10.152.80.53) by CO1NAM03FT036.mail.protection.outlook.com (10.152.80.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Sat, 23 Jul 2016 07:10:30 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) by DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) with mapi id 15.01.0528.027; Sat, 23 Jul 2016 07:10:27 +0000 From: Yuhong Bao To: David Benjamin , Benjamin Kaduk , =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] Thoughts on Version Intolerance Thread-Index: AQHR4OTJ0GaEVOOFWEy8xwOWQyWt9KAeKQuAgALlKQCAAAtcgIAAX5yAgAE3ywCAAu/Leg== Date: Sat, 23 Jul 2016 07:10:27 +0000 Message-ID: References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.80.53) smtp.mailfrom=hotmail.com; chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=fail action=none header.from=hotmail.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 10.152.80.53 as permitted sender) x-tmn: [5g2vigHRBsGedvUvfvefkL3HsxVdL4xQ] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.80.53; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM03HT202; H:DM2PR07MB287.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:; x-ms-office365-filtering-correlation-id: c2b968e6-533a-446c-8efa-08d3b2c86c8c x-microsoft-antispam: UriScan:; BCL:1; PCL:0; RULEID:(1601124038)(1601125047); SRVR:CO1NAM03HT202; x-exchange-antispam-report-cfa-test: BCL:1; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM03HT202; BCL:1; PCL:0; RULEID:; SRVR:CO1NAM03HT202; x-forefront-prvs: 0012E6D357 Content-Type: multipart/alternative; boundary="_000_DM2PR07MB2874C3335F378B3B53185ECC30B0DM2PR07MB287namprd_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2016 07:10:27.2496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT202 X-OriginalArrivalTime: 23 Jul 2016 07:10:30.0520 (UTC) FILETIME=[4BF5CF80:01D1E4B1] Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 07:10:34 -0000 --_000_DM2PR07MB2874C3335F378B3B53185ECC30B0DM2PR07MB287namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was the one who found out about how they "fixed" TLS 1.1 version intolera= nce in Cisco CSS11503 equipment: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1143035 ________________________________ From: TLS on behalf of David Benjamin Sent: Thursday, July 21, 2016 3:19:34 AM To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk > wrote: On 07/20/2016 05:01 AM, Hanno B=F6ck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario > wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from I had some follow-up discussion with David and a few others later in the day. One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is futureproof could be done in the hot path, so that it is impossible to implement a server that works in a major browser and is (e.g., 1.4) version-intolerant. Right now, if a browser wants to probe for (e.g., 1.3) version intolerance, it essentially has to treat it as a data-collection step, either doing the fallback dance on failure or just doing the probe in parallel with a 1.2 clienthello that is actually used for the connection, since we know that 1.3-intolerance exists. With David's proposal (and potentially variants of the other ones), browsers could implement a check that sends nonexistent versions in their clienthello, so that once a server implements 1.3, it would not be 1.4-intolerant. If we just keep with the current version negotiation scheme, we'll always be stuck in the "data-collecting" mode and won't be able to strictly enforce the future-proofing, since there are existing servers that are intolerant to the current scheme, and the browsers will be blamed for breaking sites on those servers if the browsers try to introduce strict enforcement of version negotiation future-proofing. [Credit where credit is due, I was not the first to propose the version lis= t. I don't know who was first, but Dave Garrett had proposed the same thing= . The TLS 1.3 implementors effectively did so too with the draft version ex= tension. Though I think the fake versions idea is new?] I should also add that, even if we ever got to our prerequisite quiet point= , this scheme is still problematic. If we had a list, all clients could par= ticipate in this fuzzing and we have a shot at vaccinating the ecosystem. T= his one violates the specification, so only clients which can rapidly deplo= y changes can safely do it. (Some sort of field trial mechanism, for instan= ce.) And it requires manual work to sustain: I would probably only do it fo= r, say, 3 months at a time and manually extend so long as TLS 1.4 does not = exist. I would not want to cause problems by forgetting to turn it off. And as Hubert notes, there may well be other intolerance triggers to clear = through. 1.3 has a larger ClientHello. We have also never added a new signa= ture algorithm before. But I think that just means we have more rusted prot= ocol joints fix rather than just the one. Fortunately, most of our other joints admit this kind of fuzzing. It's just= the versioning scheme (fixable with a list), and large ClientHellos. I don= 't have a good answer to the second one, but I would be very happy if it we= re our only problem. It's much easier to understand. The version one is sur= prisingly difficult. The conversations usually go like this: "Hi, your server software appears to have a bug where you reject TLS 1.2 Cl= ientHellos rather than implementing the version negotiation right." "Okay, we will deploy TLS 1.2." "No, please don't fix this with 1.2. That's a different problem." "You don't want us to add 1.2?" "No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just emai= l you later for 1.3." I am obviously exaggerating for humor, but it's a very common confusion and= I think is part of why version intolerance keeps on existing. If you implement the latest version of TLS but are intolerant to N+1, even = if no clients did fallbacks, your bug will not be noticed and you'll thrive= in the ecosystem. Then when we go to deploy N+1, we have problems. We want= , as much as possible, turn tomorrow's interop failures into today's intero= p failures so the bugs are caught before software ships. David -Ben > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_DM2PR07MB2874C3335F378B3B53185ECC30B0DM2PR07MB287namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I was the one who found out about how they "fixed" TLS 1.1=  version intolerance in Cisco CSS11503 equipment:

https://bugzilla.mozilla.org/show_b= ug.cgi?id=3D1143035

From: TLS <tls-bounces@i= etf.org> on behalf of David Benjamin <davidben@chromium.org>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org
Subject: Re: [TLS] Thoughts on Version Intolerance
 
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <bkaduk@akamai.com> w= rote:
On 07/20/2016 05:01 AM, Hanno B=F6ck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario <hkario@redhat.com> wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by=
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> interesting proposal, but it was largely met with resistance. So from<= br>
I had some follow-up discussion with David and a few others later in the day.  One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.  With David's proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be able t= o
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the first to propose the versio= n list. I don't know who was first, but Dave Garrett had proposed the same = thing. The TLS 1.3 implementors effectively did so too with the draft versi= on extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet = point, this scheme is still problematic. If we had a list, all clients coul= d participate in this fuzzing and we have a shot at vaccinating the ecosyst= em. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some s= ort of field trial mechanism, for instance.) And it requires manual work to= sustain: I would probably only do it for, say, 3 months at a time and manu= ally extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off= .

And as Hubert notes, there may well be other intolerance triggers to c= lear through. 1.3 has a larger ClientHello. We have also never added a new = signature algorithm before. But I think that just means we have more rusted= protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's= just the versioning scheme (fixable with a list), and large ClientHellos. = I don't have a good answer to the second one, but I would be very happy if = it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conve= rsations usually go like this:

"Hi, your server software appears= to have a bug where you reject TLS 1.2 ClientHellos rather than implementi= ng the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem.&= quot;
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor,= but it's a very common confusion and I think is part of why version intole= rance keeps on existing.

If you implement the latest version of= TLS but are intolerant to N+1, even if no clients did fallbacks, your = bug will not be noticed and you'll thrive in the ecosystem. Then when we go= to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop= failures so the bugs are caught before software ships.

David
 
-Ben

> the WG discussion yesterday I had the impression that we will most
> likely stay with the existing clienthello version mechanism. While tha= t
> will cause us more trouble, it's probably the cleaner option anyway. S= o
> we definitely should continue investigating version intolerance and > tell people to fix their stuff.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--_000_DM2PR07MB2874C3335F378B3B53185ECC30B0DM2PR07MB287namprd_-- From nobody Sat Jul 23 00:16:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51F112D9FA for ; Sat, 23 Jul 2016 00:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKlxSLWl0vE for ; Sat, 23 Jul 2016 00:16:34 -0700 (PDT) Received: from SNT004-OMC4S12.hotmail.com (snt004-omc4s12.hotmail.com [65.55.90.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E346212D93E for ; Sat, 23 Jul 2016 00:16:30 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.90.199]) by SNT004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 23 Jul 2016 00:16:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pcNr0aKZCmyeZYsbYQv/PxLklwBUrZwbpOq54wBayJQ=; b=ljqLVXaDo8Ef8hnk1PF2TQlnLFX0CJd6Glz/NzLW7apyoGbjZ4zItsbJyx8WqsNI59a5zArs/TnIN5GorlH0YX0clztM5OXoOciSQ+mQKH318IvQORbfXUU0znQwZYfV8lQuySB7a/WS8nqj8RQxaIbLGnZzoj4eaN6+nawqheKvREtNiNO7BD+KONoYgYSC+FmiYvuG1zH67YTE0Iy3791YkkaKjlfUpxSCoANVI8GtJOUu3S2Q7O/IZhXaMkKhIm+iibaP7FUTh+nRne1Lb6TKv6k7qpUCYA2l07O7vUAd+ifdqZrnVxTGt1ebFFkdqQDUQUnrb5uaq0tJWcfolg== Received: from BL2NAM02FT004.eop-nam02.prod.protection.outlook.com (10.152.76.52) by BL2NAM02HT052.eop-nam02.prod.protection.outlook.com (10.152.77.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sat, 23 Jul 2016 07:16:28 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com (10.152.76.55) by BL2NAM02FT004.mail.protection.outlook.com (10.152.76.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Sat, 23 Jul 2016 07:16:26 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) by DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) with mapi id 15.01.0528.027; Sat, 23 Jul 2016 07:16:24 +0000 From: Yuhong Bao To: David Benjamin , Benjamin Kaduk , =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] Thoughts on Version Intolerance Thread-Index: AQHR4OTJ0GaEVOOFWEy8xwOWQyWt9KAeKQuAgALlKQCAAAtcgIAAX5yAgAE3ywCAAvDtug== Date: Sat, 23 Jul 2016 07:16:24 +0000 Message-ID: References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.76.55) smtp.mailfrom=hotmail.com; chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=fail action=none header.from=hotmail.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 10.152.76.55 as permitted sender) x-tmn: [hmohCWpugeC0/QUxEm9EGS1fqHrOl41k] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.76.55; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT052; H:DM2PR07MB287.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; BL2NAM02HT052; 6:xujYvLDOJe9Z1UHF+UgyqOYMF0JmnyI1Z5JDFeWW1Fc1hC1gCMHvTM3ZcXx/pQo43DpIuqnwZoRSlLVHZJ17Kc55zlIhLrtgljdEFkKNPRWa0A7w8+q70XklMHz+Ti6eZ4DFUoNPT0AhD1vTOTuhJFxEObLsIizcJCs4tM0Lds2nF76uOvY9AcCEu5ufbmqGUEirFruIHy8rlU5DfmALwPz9S6oAKTDpYmreRDVend2htvcDtfG2Ep/WdhR37zRDwhtRmSdMiSLDAzZ3f6aND7iOZDfd+kyi8gGRsLFunI2wfTdrMH5Dp8uLf28RWcfa; 5:S60shciNpSL+HiLVI2ylJ36GLoxN4/Uz7WKHG8WkOSNn6v7ptu672DJkHucJ+Mc7tQykfIeFinxU1saa7XB2+RBTWdIYEo94d60QGW9/+PbVf8KBBfKs9sejGTzv1BQAK57rbK9uH0B4N/81GXUyxg==; 24:0JMvpZSlOsybIYrsK5WnZOL0RZK3zPF71z9uF8MdDFm9kFeQOKSi8ey48XaANHpmTA7D03IWisfycJnGicB5GS1oVkI/X20QBMjenE8Cmzo=; 7:XLDcPDbkzcoI0KbwOfs3M/AWDFWvH446SZzCXDw98OToNy19rucrsGVP5UripgEqeREcII7Lwjg8tPwGxXEqDUvXtzqawum0U35fgo6Sieq3EUWydbOjGxe3Wqc8FS2LobqW3BPt6px2oUcv9NK/MBEke1b9OZ/kWoZUTHeUTvUnW47kPS/nai7rBU8hAa4d/nD0Amx2sPmAVQMcmErvX68MN9HQTdCUXXMXl+VzvXYJJrUU74h706W9XyS6eLPm x-ms-office365-filtering-correlation-id: fb8acfbf-b7da-47f6-70da-08d3b2c94168 x-microsoft-antispam: UriScan:; BCL:1; PCL:0; RULEID:(1601124038)(1601125047); SRVR:BL2NAM02HT052; x-exchange-antispam-report-cfa-test: BCL:1; PCL:0; RULEID:(432015012)(82015046); SRVR:BL2NAM02HT052; BCL:1; PCL:0; RULEID:; SRVR:BL2NAM02HT052; x-forefront-prvs: 0012E6D357 spamdiagnosticoutput: 1:5 spamdiagnosticmetadata: :1 Content-Type: multipart/alternative; boundary="_000_DM2PR07MB287A1EB5E3238008ACAAF6DC30B0DM2PR07MB287namprd_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2016 07:16:24.3916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT052 X-OriginalArrivalTime: 23 Jul 2016 07:16:30.0244 (UTC) FILETIME=[225F5640:01D1E4B2] Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 07:16:38 -0000 --_000_DM2PR07MB287A1EB5E3238008ACAAF6DC30B0DM2PR07MB287namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I should also mention the APC fiasco: http://www.apc.com/us/en/faqs/FA238115/ UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS) www.apc.com UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS) I wonder if anyone has tested the TLS 1.2 implementation they did later not= only for version intolerance but also for other bugs like GCM nonce reuse. ________________________________ From: TLS on behalf of David Benjamin Sent: Thursday, July 21, 2016 3:19:34 AM To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk > wrote: On 07/20/2016 05:01 AM, Hanno B=F6ck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario > wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from I had some follow-up discussion with David and a few others later in the day. One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is futureproof could be done in the hot path, so that it is impossible to implement a server that works in a major browser and is (e.g., 1.4) version-intolerant. Right now, if a browser wants to probe for (e.g., 1.3) version intolerance, it essentially has to treat it as a data-collection step, either doing the fallback dance on failure or just doing the probe in parallel with a 1.2 clienthello that is actually used for the connection, since we know that 1.3-intolerance exists. With David's proposal (and potentially variants of the other ones), browsers could implement a check that sends nonexistent versions in their clienthello, so that once a server implements 1.3, it would not be 1.4-intolerant. If we just keep with the current version negotiation scheme, we'll always be stuck in the "data-collecting" mode and won't be able to strictly enforce the future-proofing, since there are existing servers that are intolerant to the current scheme, and the browsers will be blamed for breaking sites on those servers if the browsers try to introduce strict enforcement of version negotiation future-proofing. [Credit where credit is due, I was not the first to propose the version lis= t. I don't know who was first, but Dave Garrett had proposed the same thing= . The TLS 1.3 implementors effectively did so too with the draft version ex= tension. Though I think the fake versions idea is new?] I should also add that, even if we ever got to our prerequisite quiet point= , this scheme is still problematic. If we had a list, all clients could par= ticipate in this fuzzing and we have a shot at vaccinating the ecosystem. T= his one violates the specification, so only clients which can rapidly deplo= y changes can safely do it. (Some sort of field trial mechanism, for instan= ce.) And it requires manual work to sustain: I would probably only do it fo= r, say, 3 months at a time and manually extend so long as TLS 1.4 does not = exist. I would not want to cause problems by forgetting to turn it off. And as Hubert notes, there may well be other intolerance triggers to clear = through. 1.3 has a larger ClientHello. We have also never added a new signa= ture algorithm before. But I think that just means we have more rusted prot= ocol joints fix rather than just the one. Fortunately, most of our other joints admit this kind of fuzzing. It's just= the versioning scheme (fixable with a list), and large ClientHellos. I don= 't have a good answer to the second one, but I would be very happy if it we= re our only problem. It's much easier to understand. The version one is sur= prisingly difficult. The conversations usually go like this: "Hi, your server software appears to have a bug where you reject TLS 1.2 Cl= ientHellos rather than implementing the version negotiation right." "Okay, we will deploy TLS 1.2." "No, please don't fix this with 1.2. That's a different problem." "You don't want us to add 1.2?" "No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just emai= l you later for 1.3." I am obviously exaggerating for humor, but it's a very common confusion and= I think is part of why version intolerance keeps on existing. If you implement the latest version of TLS but are intolerant to N+1, even = if no clients did fallbacks, your bug will not be noticed and you'll thrive= in the ecosystem. Then when we go to deploy N+1, we have problems. We want= , as much as possible, turn tomorrow's interop failures into today's intero= p failures so the bugs are caught before software ships. David -Ben > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_DM2PR07MB287A1EB5E3238008ACAAF6DC30B0DM2PR07MB287namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I should also mention the APC fiasco:

http://www.apc.com/us/en/faqs/FA238115/

www.apc.com
UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS)
I wonder if anyone has tested the TLS 1.2 implementation they did later not= only for version intolerance but also for other bugs like GCM nonce r= euse.

From: TLS <tls-bounces@i= etf.org> on behalf of David Benjamin <davidben@chromium.org>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org
Subject: Re: [TLS] Thoughts on Version Intolerance
 
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <bkaduk@akamai.com> w= rote:
On 07/20/2016 05:01 AM, Hanno B=F6ck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario <hkario@redhat.com> wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by=
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> interesting proposal, but it was largely met with resistance. So from<= br>
I had some follow-up discussion with David and a few others later in the day.  One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.  With David's proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be able t= o
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the first to propose the versio= n list. I don't know who was first, but Dave Garrett had proposed the same = thing. The TLS 1.3 implementors effectively did so too with the draft versi= on extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet = point, this scheme is still problematic. If we had a list, all clients coul= d participate in this fuzzing and we have a shot at vaccinating the ecosyst= em. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some s= ort of field trial mechanism, for instance.) And it requires manual work to= sustain: I would probably only do it for, say, 3 months at a time and manu= ally extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off= .

And as Hubert notes, there may well be other intolerance triggers to c= lear through. 1.3 has a larger ClientHello. We have also never added a new = signature algorithm before. But I think that just means we have more rusted= protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's= just the versioning scheme (fixable with a list), and large ClientHellos. = I don't have a good answer to the second one, but I would be very happy if = it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conve= rsations usually go like this:

"Hi, your server software appears= to have a bug where you reject TLS 1.2 ClientHellos rather than implementi= ng the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem.&= quot;
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor,= but it's a very common confusion and I think is part of why version intole= rance keeps on existing.

If you implement the latest version of= TLS but are intolerant to N+1, even if no clients did fallbacks, your = bug will not be noticed and you'll thrive in the ecosystem. Then when we go= to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop= failures so the bugs are caught before software ships.

David
 
-Ben

> the WG discussion yesterday I had the impression that we will most
> likely stay with the existing clienthello version mechanism. While tha= t
> will cause us more trouble, it's probably the cleaner option anyway. S= o
> we definitely should continue investigating version intolerance and > tell people to fix their stuff.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--_000_DM2PR07MB287A1EB5E3238008ACAAF6DC30B0DM2PR07MB287namprd_-- From nobody Sat Jul 23 08:59:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916D12D578 for ; Sat, 23 Jul 2016 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BafBql8O3q7x for ; Sat, 23 Jul 2016 08:59:39 -0700 (PDT) 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 8740F12D51A for ; Sat, 23 Jul 2016 08:59:39 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id q128so88323230wma.1 for ; Sat, 23 Jul 2016 08:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=xnBjoGT1IU6CbXpTZfwH4Spe0LMPEFh1l6eFEclsy+E=; b=TLg8YSJltbrmlrbPPNzupuX9aQ1I2mn8Q3G40+44wOqTrqTrpgoL83CYr8Dotr6evS LfULJqvYtN+KqiHYOF45L7NwO1rkavn7oGw7zAyvx0sppfYtPM9jfyG+ZgE+eCJmlRru MSDWvFo4hfA6WH8HRwIOPRrqMPKSVdXAfWauGugQgR/SEHS9C3yolRYm7eKARaURThkK Ayu/Cn/bnuJyg/OaiEBGs1sGVvPc3hcgu/Y6peVFtvvU5tR/vWJFJlOctbfzlxBLiN3p Y6+1RlszCOt57s9fwBGqKVu1bMXcUSODJW5rjp+ltd14C+H7nNIlfj4wEJkskcWC0iI4 s1bQ== 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-transfer-encoding; bh=xnBjoGT1IU6CbXpTZfwH4Spe0LMPEFh1l6eFEclsy+E=; b=AmSQuqQFUbSRouP5BhDFOB795LfJCZCS2ONBwkae8VXswrWDOAc4oRLuZurOy/f81p 0ZGIvbvZXzat7Vs5jSl01vXO1JGWSRu8k3lPCsy0vAS5QWKe4pqQJLnqEhlzRq+YQjs4 nh2JiBdUPuftpt6QpjrdJCCbQ3SN63rsR243xjwRbZtw8SJ/da8LA3vVyJovpPflE50M I5hAw56i8hSChkAyDWU9JCbrsPFgbsuCWuvr6O5TikGrFaK3AQ0Vcz5Sj0ayLNua56BJ +DM31d7UMNiybxoWdYNnY475dhhwxWXba4hDbdthov/ZDup1Fw4eIvfh8+lq2QXK34Yb cpsA== X-Gm-Message-State: AEkoousJhh04qFHUjOd8eAX7IBT07LFIHB3q9QJp3WAApfi37CM027Oz2EGbzdMEFBlP9Q== X-Received: by 10.28.146.211 with SMTP id u202mr11677748wmd.54.1469289577809; Sat, 23 Jul 2016 08:59:37 -0700 (PDT) Received: from qlue.local (178-222-95-201.dynamic.isp.telekom.rs. [178.222.95.201]) by smtp.gmail.com with ESMTPSA id c13sm6321296wjx.12.2016.07.23.08.59.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jul 2016 08:59:36 -0700 (PDT) To: tls@ietf.org References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> From: =?UTF-8?Q?Ivan_Risti=c4=87?= Message-ID: <96400281-f648-205c-39da-78e6b92166f1@gmail.com> Date: Sat, 23 Jul 2016 17:59:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720120125.43f61155@pc1> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 15:59:41 -0000 On 20/07/2016 12:01, Hanno Böck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. > > I'm now also collecting some data and have some preliminary > suspicion on affected devices. My numbers roughly match yours that we > are in the more or less 3% area of 1.3 intolerance. FYI: I am seeing TLS 1.3 intolerance at 3.2% in the most recent SSL Pulse scan (July 2016). I'll propose that a chart is added to the SSL Pulse monthly report so that we can track the percentage it in the following months. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Jul 23 14:52:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF60F12D597 for ; Sat, 23 Jul 2016 14:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.209 X-Spam-Level: X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3G5VeRkB8C3 for ; Sat, 23 Jul 2016 14:52:42 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6A112D50C for ; Sat, 23 Jul 2016 14:52:41 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u6NLqdrn009628; Sat, 23 Jul 2016 17:52:39 -0400 Date: Sat, 23 Jul 2016 17:52:38 -0400 (EDT) From: Hubert Kario To: Brian Smith Message-ID: <1347298854.18580677.1469310758848.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [94.112.188.164, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922) Thread-Topic: Thoughts on Version Intolerance Thread-Index: Xlx6qYJ38SwYGOsikFiTZa5LUIoHXw== Archived-At: Cc: tls Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:52:45 -0000 ----- Original Message ----- > From: "Brian Smith" > To: "Hubert Kario" > Cc: "Dave Garrett" , "" > Sent: Saturday, July 23, 2016 3:37:24 AM > Subject: Re: [TLS] Thoughts on Version Intolerance >=20 > Hubert Kario wrote: > > I'm quite sure that if I were sending a huge extension or many big > > extensions, > > the percentage of servers that are incompatible to them would be simila= r, > > if > > not worse. A relatively small 3KiB client hello already causes issues a= nd > > this > > is not exactly something impossible to achieve with just TLSv1.2 and > > session > > tickets. >=20 > Don't expect a server to accept a ClientHello with a session ticket it > didn't produce. In particular, a server could very reasonably reject a > session ticket larger than the ones it produces, and it might produce > only very small ones. oh, I agree, I don't plan to use session_ticket for testing client hello si= ze > More generally, when assessing compatibility, generally it is better > to consider only initial handshakes, using the data one would normally > send in an initial handshake. And, if you are considering 0-RTT key > shares, then it would be better to measure the case where only ECC key > shares are used separately from the case where non-ECC (old-school DH) > key shares are used. what I wanted to say, is that those limits are most likely hardcoded in the libraries (OpenSSL's certainly were), so they may well be ticking time bombs for the time when some user deploys such broken implementation with client certificates and for one reason or other connecting clients have very big certificates. Then you can hit those limits even if using TLSv1.2 protocol. --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Sat Jul 23 15:10:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B994E12D1BD for ; Sat, 23 Jul 2016 15:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGdidD_vf56u for ; Sat, 23 Jul 2016 15:10:55 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCFD12D0CA for ; Sat, 23 Jul 2016 15:10:55 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6NMAptP002090; Sat, 23 Jul 2016 18:10:51 -0400 Date: Sat, 23 Jul 2016 18:10:50 -0400 (EDT) From: Hubert Kario To: David Benjamin Message-ID: <1102073174.18586058.1469311850476.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [94.112.188.164, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF47 (Linux)/8.0.6_GA_5922) Thread-Topic: Thoughts on Version Intolerance Thread-Index: hie19C61y1WP9D2gxmOjBE8hB1CoPw== Archived-At: Cc: tls Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 22:10:58 -0000 ----- Original Message -----=20 > From: "David Benjamin" > To: "Brian Smith" , "Hubert Kario" > Cc: "" > Sent: Saturday, July 23, 2016 8:03:41 AM > Subject: Re: [TLS] Thoughts on Version Intolerance > On Sat, Jul 23, 2016 at 3:37 AM Brian Smith < brian@briansmith.org > wrot= e: > > Hubert Kario < hkario@redhat.com > wrote: >=20 > > > I'm quite sure that if I were sending a huge extension or many big > > > extensions, >=20 > > > the percentage of servers that are incompatible to them would be simi= lar, > > > if >=20 > > > not worse. A relatively small 3KiB client hello already causes issues= and > > > this >=20 > > > is not exactly something impossible to achieve with just TLSv1.2 and > > > session >=20 > > > tickets. >=20 > (Note that one must complete the handshake to get a full picture. Sending= the > ClientHello isn't enough. Full analysis pending, but sending a 1.2 > ServerHello and failing around the Finished message seems to happen often > enough.) technically, it's a regular bug, not intolerance intolerance is when we can't get Server Hello message On the other hand we have servers like clkmon.com, which seem to choke on m= easly 1356 byte long Client Hello messages... --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Sun Jul 24 02:45:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41FC12D626 for ; Sun, 24 Jul 2016 02:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TcVDTD-54aQ for ; Sun, 24 Jul 2016 02:45:50 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3214D12D5BF for ; Sun, 24 Jul 2016 02:45:50 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o67so134650921qke.1 for ; Sun, 24 Jul 2016 02:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=u82XU32UOoWJNKSCBbR5o0GzSGrjsC6+3dckG++1qzQ=; b=F51vAFFJuGMrcvLmDA9ZKnGC+jwkQIS0ro7E4HQHZNKW1gKWp0z66Ht30oWTs/oNI5 ygror+FVs2bDcEO74saIaUsv6LTSuwHqm+n5qQ9Hqo0YUBoBB4Fycrk31gxci8tvQb+N qmmOIeasRzS4SO1zGfCFH7PxJhmHm815/cJxqJzrpKKVmSvcIoB65CyC1+Z/pxiFYNm8 oRwNPgN9yd1NycSaZSepWqfUaa8hyzJZnd1jQpO0XyQEFTfJFPupCUvkrrvSo8u31NOc y6LDe8lF9PYI3J92RCI91UiDTtJgsShhrCTDwGE8R1aIrmBE/S1FjReaFmWWHDtBrEsJ agBw== 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; bh=u82XU32UOoWJNKSCBbR5o0GzSGrjsC6+3dckG++1qzQ=; b=QDdp1AP7bTTI45VqZsWoskxrtO6QN+c70VesI/FATr1tJK40+ZhmE90ENojf3IxlsM DdGHgsRNJ5P+PLWj1er/wXKNfUl6n+g2T3KRETBLOomzZCioi26PFh/0Iy0az13Cp3bI Et3kk25bCancvp0SHP5ded7j67os3NWFkxMZAqP0uDJcA8/MMhrSJjzIN0+shIPh2Wir sJvny6YLxuawzveXnLFHjyHsc5DAvkeSmGZG64fnJP2fymAWSO6JXP8B7fW7Ro2SCJ8k VedTFblsFWHlJuuttIUOR/XfabXpvOL7PnilYddrLcPhJ++0Ee2ESBq+980rlGSY7B27 D+3Q== X-Gm-Message-State: AEkoous5gQ120ozVG/nebSwI38XFIaaF5B7EF+owI6GTFJw3fRfKVwc0BDB0LyMuERjlpect/W+kH0MrDH3dOg== X-Received: by 10.55.152.135 with SMTP id a129mr15348324qke.199.1469353549222; Sun, 24 Jul 2016 02:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 24 Jul 2016 02:45:48 -0700 (PDT) From: Martin Thomson Date: Sun, 24 Jul 2016 11:45:48 +0200 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] PSS and 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:45:52 -0000 David Benjamin noted that we really need to decide whether PSS was something that we should have supported in TLS 1.2. We can't have a situation where there are two implementations of 1.3 that for some reason have 1.3 disabled where they disagree whether PSS is acceptable. I have opened a PR that makes it clear that PSS is defined for TLS 1.2. https://github.com/tlswg/tls13-spec/pull/557 From nobody Sun Jul 24 02:56:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21712D62C for ; Sun, 24 Jul 2016 02:56:55 -0700 (PDT) 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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjaqEyfltF0P for ; Sun, 24 Jul 2016 02:56:53 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 C083B12D5BF for ; Sun, 24 Jul 2016 02:56:53 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z8so116535448ywa.1 for ; Sun, 24 Jul 2016 02:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oSxhqjvEY9zrETW2CVtML6mABB4wxN68DqxG2VMjsDk=; b=Jfk1Hy53RIs51jrnsItpEPIRltgubCUt8aPAeYPFYh1IUaZcnj9f7XKjzB4ZBZ7/Dk 4H35pbCYM5ywFu6alNyWjAmZdLGeoh3/nimjVGKxl77T3eMj+NVLJyFcCYYZEPsWtUWg yof1VekZe+cbOpI/88wHqurCnrTPKQ5nfrU+PTTeu10TrngGDBDKVqlUCXcvrsbOWZ/U +a/WvHRhoeI6FvBYw9NEh70aNVC/DHTz2FAd1bYIveBRbl6BTi+sNoVqqeXgCUdm/ETV 1Ace42KteJq8gvaRDKaqakCFXnDzKsDeW6cd43sHM4/yav13MdydEwKgep5o8bgA1p+T mLJQ== 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; bh=oSxhqjvEY9zrETW2CVtML6mABB4wxN68DqxG2VMjsDk=; b=esM8sPiw/42r+FFXoY3cI74UBbZS7VtvQtBLpmScEDYjjF64AZZl5ft30c0ogGuM3D gyZTMCIBJ+rX2A6ECKup+JWso/gsplcqZTxRHIMsrVB4oO19RuMgxs7EjccJTQqwzMaY j27jsKNhnYG3u27RWtjZ6ozD1kZVzRoqxPJxX1yhPUVbSIlQNz1JcBpYwmPowqje6mEH +j0+aNvGZdwPKFHmo/TgUjokHuwePgD3s0c925wDq5hQ33FypInBlRG8Yh+E8VimcsFO cKgb8hx4OSKG2fA+CqRaqCHOPcnBCuLZIULDUV2ARu4UKuz1i1EGpAcWr6QdaKls1t73 Bt3Q== X-Gm-Message-State: AEkoouthLFyvRh1c/ntvzzgIjLPp/S8Qyv0vG9Q+Ako5WWsp0oOM+iW05ABw2Ow58DGvOFzwcyDhCuMDBuU4kw== X-Received: by 10.13.244.197 with SMTP id d188mr10963430ywf.276.1469354213014; Sun, 24 Jul 2016 02:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Sun, 24 Jul 2016 02:56:13 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 24 Jul 2016 11:56:13 +0200 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c086548eaaa8e05385eaf60 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS and 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 09:56:55 -0000 --94eb2c086548eaaa8e05385eaf60 Content-Type: text/plain; charset=UTF-8 I am in favor of this change. We should be trying to move to PSS in general and there's no reason why 1.3 clients which support PSS can't also support it for 1.2 -Ekr On Sun, Jul 24, 2016 at 11:45 AM, Martin Thomson wrote: > David Benjamin noted that we really need to decide whether PSS was > something that we should have supported in TLS 1.2. We can't have a > situation where there are two implementations of 1.3 that for some > reason have 1.3 disabled where they disagree whether PSS is > acceptable. > > I have opened a PR that makes it clear that PSS is defined for TLS 1.2. > > https://github.com/tlswg/tls13-spec/pull/557 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c086548eaaa8e05385eaf60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of this change. We should be trying to move = to PSS in general and there's no reason why 1.3 clients which support P= SS can't also support it for 1.2

-Ekr

=

On Su= n, Jul 24, 2016 at 11:45 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
David Benjamin= noted that we really need to decide whether PSS was
something that we should have supported in TLS 1.2.=C2=A0 We can't have= a
situation where there are two implementations of 1.3 that for some
reason have 1.3 disabled where they disagree whether PSS is
acceptable.

I have opened a PR that makes it clear that PSS is defined for TLS 1.2.

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

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

--94eb2c086548eaaa8e05385eaf60-- From nobody Sun Jul 24 04:26:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B7712D7F5 for ; Sun, 24 Jul 2016 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLjttB0odG7a for ; Sun, 24 Jul 2016 04:26:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44112D7DE for ; Sun, 24 Jul 2016 04:26:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7F63B4AEF; Sun, 24 Jul 2016 14:26:36 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id wLDHSs5Js2Yr; Sun, 24 Jul 2016 14:26:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 410BF2310; Sun, 24 Jul 2016 14:26:36 +0300 (EEST) Date: Sun, 24 Jul 2016 14:26:31 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160724112631.GC576@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS and 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:26:40 -0000 On Sun, Jul 24, 2016 at 11:45:48AM +0200, Martin Thomson wrote: > David Benjamin noted that we really need to decide whether PSS was > something that we should have supported in TLS 1.2. We can't have a > situation where there are two implementations of 1.3 that for some > reason have 1.3 disabled where they disagree whether PSS is > acceptable. My arguing about support for new signature algorithms predated the crypto negotiation revamp. Back then, one had to assign legacy type for each TLS 1.3-valid end-entity signature scheme, which for all practical purposes makes it work in TLS 1.2. However, since the revamped mechanism entierely dumps legacy types, it could be possible to have legacy-untyped signatures, which definitely are not allowed in TLS 1.2 (one could even assign legacy type post-hoc, which would make it legal for TLS 1.2, but would not affect TLS 1.3 in any way). However, it is separate matter if backport would make sense for other reasons... > I have opened a PR that makes it clear that PSS is defined for TLS 1.2. The legacy type of RSA-PSS is RSA, right? -Ilari From nobody Sun Jul 24 09:50:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4112D534 for ; Sun, 24 Jul 2016 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATzJwo4BoxYD for ; Sun, 24 Jul 2016 09:50:26 -0700 (PDT) Received: from COL004-OMC2S14.hotmail.com (col004-omc2s14.hotmail.com [65.55.34.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B6E12D14A for ; Sun, 24 Jul 2016 09:50:25 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.55.34.71]) by COL004-OMC2S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 24 Jul 2016 09:50:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k+bKnmbWclzSxJWkWzbrAGcDQhVzYCyWQtzZjrvVy3I=; b=jBoHdQlmz+GNMtc9v2l9nE2UMO92fDFsjOpigjQbcog9DNNVZT6HrjbI5if96lyqU48L0qQ+Im/9aqylzgVLWsla4MiYg7Z5U04ZNqg5PY42FS3+45AUHXyOSuB7qW2qoxMy2IjLBpdhaqq40JEm6qRAE94S2uA/qY4WoUVd6crL1dKhBaJWnvY3EfeY51iKt6RVQadA25NWMttIEYtf3rTU5G17OdZe+eD0JDLMDPYde+s2rHidIJWKj/r4UMOQG8T5P6Yprhsqa/OIOFStBTqfPgJfQbcAlUC0k3Q2Yr8RkRqDRGn7Pv1AvU4IStBTLzhapPueDzghbARXZA9lrQ== Received: from BN3NAM01FT036.eop-nam01.prod.protection.outlook.com (10.152.66.54) by BN3NAM01HT148.eop-nam01.prod.protection.outlook.com (10.152.66.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sun, 24 Jul 2016 16:50:24 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com (10.152.66.56) by BN3NAM01FT036.mail.protection.outlook.com (10.152.67.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Sun, 24 Jul 2016 16:50:22 +0000 Received: from DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.126]) by DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.126]) with mapi id 15.01.0528.029; Sun, 24 Jul 2016 16:50:21 +0000 From: Yuhong Bao To: Peter Gutmann , "tls@ietf.org" Thread-Topic: [TLS] Thoughts on Version Intolerance Thread-Index: AQHR4OTJ0GaEVOOFWEy8xwOWQyWt9KAeKQuAgALlKQCAAAtcgIAAX5yAgAE3ywCAAvDtuoAB4poAgABQHYU= Date: Sun, 24 Jul 2016 16:50:21 +0000 Message-ID: References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com>, , , <9A043F3CF02CD34C8E74AC1594475C73F4CD30BD@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CD30BD@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.66.56) smtp.mailfrom=hotmail.com; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; dmarc=fail action=none header.from=hotmail.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 10.152.66.56 as permitted sender) x-tmn: [chr6eIJXPeLMw5+bZP40Evtpye4c6zar] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.66.56; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT148; H:DM2PR07MB287.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; BN3NAM01HT148; 6:zp6BVbJP3j3Rqj4VfaPGv1c+jiR3dRa94vr9dae1d9RC66SOqfoIpQttVgrYGdAaYFGx87MMfpYU0b0cvuFOthvopN6c7lvB1X62k23RPAR54aKX2YzRRf9MYCN8JHZxAca/2yYfIGG1NgqKnvpmFfOlsRf/E4zihr8lO5em6SuEXPt9aAs6plNTZ8lswsvSXNa6vQPQ8UHcl9Eewwj6oxV7dhO+812tIBGkqmoyjNoZDQhaxKebpnWzxSQZJMJ7fmW9ekbxvDq51ZLvlca+VW/3rFrDYPcZRCyXfeVjLt4W9a8fyQThfqEdvUkSe0hI; 5:6+zOX88Bj3wkJyi4BOHEYBgskB3zVO/SCWGJr0eqqrJhxMO5q4FLEG+hfBKHPtAAEUBhZEC0bGitPOMtrM/sfIyk6bOY/5E+QiJ+mOXxoIutk/jjyuaDaTqSuUMJrNSvOZ2X12jFRjm+u34wc15Q/Q==; 24:I2+LAwWaZshstvb9I497SlkfAXcCY1AM6LDKL6RgQY/zSJTJw4gLxp1EU28cGUcKRTdgK+faTOIO7HU+l40FTlmFAqagk6+1XgaX/+T+i60=; 7:7yBHngcRVpXldtroreWhG/Im8zqURscjoIZm+gf4PCurXQLFdUHMSMS9LRFvgFzmgDxc8BwqPt7mJUKR9yt3yQjuW2lQrVwpqjyk5Nd79PaqxvHj1AZypyHkAwSBJCJbgQQ4rqZW0DZPW6JLqO22xpJUh0VGXL6QM1lqGvfj9eASwLj+vvroBBYVQYOpAwZYXtDDxNSdqiPSipK/SEqGs+3sdhW7hs2hpQAjhKIrAU/3rZk0h6J/X/iVn3GUqEC1 x-ms-office365-filtering-correlation-id: 440f8b36-f920-4c83-7673-08d3b3e29a1e x-microsoft-antispam: UriScan:; BCL:1; PCL:0; RULEID:(1601124038)(1601125047); SRVR:BN3NAM01HT148; x-exchange-antispam-report-cfa-test: BCL:1; PCL:0; RULEID:(432015012)(82015046); SRVR:BN3NAM01HT148; BCL:1; PCL:0; RULEID:; SRVR:BN3NAM01HT148; x-forefront-prvs: 0013079544 spamdiagnosticoutput: 1:5 spamdiagnosticmetadata: :1 Content-Type: multipart/alternative; boundary="_000_DM2PR07MB28789A17ED05C5F954CFCC9C30C0DM2PR07MB287namprd_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2016 16:50:21.8040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT148 X-OriginalArrivalTime: 24 Jul 2016 16:50:25.0412 (UTC) FILETIME=[79BEBC40:01D1E5CB] Archived-At: Subject: Re: [TLS] Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 16:50:29 -0000 --_000_DM2PR07MB28789A17ED05C5F954CFCC9C30C0DM2PR07MB287namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't have access unfortunately, but I wonder which companies on this mai= ling list are using the affected APC devices. ________________________________ From: Peter Gutmann Sent: Sunday, July 24, 2016 5:01:42 AM To: Yuhong Bao Subject: RE: [TLS] Thoughts on Version Intolerance Do you have access to a device running that software, or are you just passi= ng on the info? I'd like to run some test messages against it... Peter. ________________________________ From: TLS [tls-bounces@ietf.org] on behalf of Yuhong Bao [YuhongBao_386@hot= mail.com] Sent: Saturday, 23 July 2016 19:16 To: David Benjamin; Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance I should also mention the APC fiasco: http://www.apc.com/us/en/faqs/FA238115/ UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS) www.apc.com UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS) I wonder if anyone has tested the TLS 1.2 implementation they did later not= only for version intolerance but also for other bugs like GCM nonce reuse. ________________________________ From: TLS on behalf of David Benjamin Sent: Thursday, July 21, 2016 3:19:34 AM To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org Subject: Re: [TLS] Thoughts on Version Intolerance On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk > wrote: On 07/20/2016 05:01 AM, Hanno B=F6ck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario > wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from I had some follow-up discussion with David and a few others later in the day. One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is futureproof could be done in the hot path, so that it is impossible to implement a server that works in a major browser and is (e.g., 1.4) version-intolerant. Right now, if a browser wants to probe for (e.g., 1.3) version intolerance, it essentially has to treat it as a data-collection step, either doing the fallback dance on failure or just doing the probe in parallel with a 1.2 clienthello that is actually used for the connection, since we know that 1.3-intolerance exists. With David's proposal (and potentially variants of the other ones), browsers could implement a check that sends nonexistent versions in their clienthello, so that once a server implements 1.3, it would not be 1.4-intolerant. If we just keep with the current version negotiation scheme, we'll always be stuck in the "data-collecting" mode and won't be able to strictly enforce the future-proofing, since there are existing servers that are intolerant to the current scheme, and the browsers will be blamed for breaking sites on those servers if the browsers try to introduce strict enforcement of version negotiation future-proofing. [Credit where credit is due, I was not the first to propose the version lis= t. I don't know who was first, but Dave Garrett had proposed the same thing= . The TLS 1.3 implementors effectively did so too with the draft version ex= tension. Though I think the fake versions idea is new?] I should also add that, even if we ever got to our prerequisite quiet point= , this scheme is still problematic. If we had a list, all clients could par= ticipate in this fuzzing and we have a shot at vaccinating the ecosystem. T= his one violates the specification, so only clients which can rapidly deplo= y changes can safely do it. (Some sort of field trial mechanism, for instan= ce.) And it requires manual work to sustain: I would probably only do it fo= r, say, 3 months at a time and manually extend so long as TLS 1.4 does not = exist. I would not want to cause problems by forgetting to turn it off. And as Hubert notes, there may well be other intolerance triggers to clear = through. 1.3 has a larger ClientHello. We have also never added a new signa= ture algorithm before. But I think that just means we have more rusted prot= ocol joints fix rather than just the one. Fortunately, most of our other joints admit this kind of fuzzing. It's just= the versioning scheme (fixable with a list), and large ClientHellos. I don= 't have a good answer to the second one, but I would be very happy if it we= re our only problem. It's much easier to understand. The version one is sur= prisingly difficult. The conversations usually go like this: "Hi, your server software appears to have a bug where you reject TLS 1.2 Cl= ientHellos rather than implementing the version negotiation right." "Okay, we will deploy TLS 1.2." "No, please don't fix this with 1.2. That's a different problem." "You don't want us to add 1.2?" "No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just emai= l you later for 1.3." I am obviously exaggerating for humor, but it's a very common confusion and= I think is part of why version intolerance keeps on existing. If you implement the latest version of TLS but are intolerant to N+1, even = if no clients did fallbacks, your bug will not be noticed and you'll thrive= in the ecosystem. Then when we go to deploy N+1, we have problems. We want= , as much as possible, turn tomorrow's interop failures into today's intero= p failures so the bugs are caught before software ships. David -Ben > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_DM2PR07MB28789A17ED05C5F954CFCC9C30C0DM2PR07MB287namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don't have access unfortunately, but I wonder which companies on this = mailing list are using the affected APC devices.

From: Peter Gutmann <pgu= t001@cs.auckland.ac.nz>
Sent: Sunday, July 24, 2016 5:01:42 AM
To: Yuhong Bao
Subject: RE: [TLS] Thoughts on Version Intolerance
 
Do you have access to a device running that software, or are you jus= t passing on the info?  I'd like to run some test messages against it.= ..

Peter.

From: TLS [tls-bounces@ietf.org] on behal= f of Yuhong Bao [YuhongBao_386@hotmail.com]
Sent: Saturday, 23 July 2016 19:16
To: David Benjamin; Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org
Subject: Re: [TLS] Thoughts on Version Intolerance

I should also mention the APC fiasco:

http://www.apc.com/us/en/faqs/FA2381= 15/

www.apc.com
UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) e= nabled device via HTTPS (SSL/TLS)
I wonder if anyone has tested the TLS 1.2 implementation they did later not= only for version intolerance but also for other bugs like GCM nonce r= euse.

From: TLS <tls-bounces@= ietf.org> on behalf of David Benjamin <davidben@chromium.org>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno B=F6ck; tls@ietf.org
Subject: Re: [TLS] Thoughts on Version Intolerance
 
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <bkaduk@akamai.com> w= rote:
On 07/20/2016 05:01 AM, Hanno B=F6ck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario <hkario@redhat.com> wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by=
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> interesting proposal, but it was largely met with resistance. So from<= br>
I had some follow-up discussion with David and a few others later in the day.  One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.  With David's proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be able t= o
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the first to propose the versio= n list. I don't know who was first, but Dave Garrett had proposed the same = thing. The TLS 1.3 implementors effectively did so too with the draft versi= on extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet = point, this scheme is still problematic. If we had a list, all clients coul= d participate in this fuzzing and we have a shot at vaccinating the ecosyst= em. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some s= ort of field trial mechanism, for instance.) And it requires manual work to= sustain: I would probably only do it for, say, 3 months at a time and manu= ally extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off= .

And as Hubert notes, there may well be other intolerance triggers to c= lear through. 1.3 has a larger ClientHello. We have also never added a new = signature algorithm before. But I think that just means we have more rusted= protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's= just the versioning scheme (fixable with a list), and large ClientHellos. = I don't have a good answer to the second one, but I would be very happy if = it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conve= rsations usually go like this:

"Hi, your server software appears= to have a bug where you reject TLS 1.2 ClientHellos rather than implementi= ng the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem.&= quot;
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor,= but it's a very common confusion and I think is part of why version intole= rance keeps on existing.

If you implement the latest version of= TLS but are intolerant to N+1, even if no clients did fallbacks, your = bug will not be noticed and you'll thrive in the ecosystem. Then when we go= to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop= failures so the bugs are caught before software ships.

David
 
-Ben

> the WG discussion yesterday I had the impression that we will most
> likely stay with the existing clienthello version mechanism. While tha= t
> will cause us more trouble, it's probably the cleaner option anyway. S= o
> we definitely should continue investigating version intolerance and > tell people to fix their stuff.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--_000_DM2PR07MB28789A17ED05C5F954CFCC9C30C0DM2PR07MB287namprd_-- From nobody Sun Jul 24 13:35:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2E112B04F for ; Sun, 24 Jul 2016 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiboI1gyUrjk for ; Sun, 24 Jul 2016 13:35:23 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329E012B031 for ; Sun, 24 Jul 2016 13:35:23 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 52so87536778qtq.3 for ; Sun, 24 Jul 2016 13:35:23 -0700 (PDT) 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; bh=DwIRve7w/tFw6hln3GLuGHrzY24rIHeF1j1MNbl+X9Y=; b=Lu28KQXv6UowwTgFUFTJA63odC+LUEJVvptYqDn2tTp6CvhN1fsWJcmZvtc/9S6DzG 5wp4fwLWb7uf2jYZHTsarsWwN3OcKIWMXCFaynHzS0K8dGGjGLyKgVkqJmGCjDlTkdiw Vdk4NZn0rK+n1EWbCWoc/0rk1p4tk5lIa4bIwypB3/Z7TJHGlFnnpCO9Qx7YTPmeM7Ep d9PEKcVkecGE+F7++6hwE+XeH8j9TvpuMTM+mBjHp8FlSSXtH5N0zYRE5InAfr2QRONr RTxIMyyiSr2Z97tvTFghUFQXLzO76NMLE14ZguLpgN/lwSXTkx2DsNucVURZijJcK/+r I0vA== 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; bh=DwIRve7w/tFw6hln3GLuGHrzY24rIHeF1j1MNbl+X9Y=; b=erT2hgW8CqS7cVwBDQAPYkwN/hF2QIc3Kst+ItiPgXhd8wNI3ITmP+ovn+P529Morg c6xImnZRAmFDSKuYLcZiKZKlg7s+A8lFnqoQP+xUAhriE29Qs58kbRA2pJ/kzuG+3cP2 At0mgscwwtcCMhNGS2WabmrKsENLcSCy+Vv00ZRkuTg1bkFiT4eRfCiLf8EaLopmEQ4P 6N1GkRIodxHHltKwKKFQATH9wHmLL5xUTyjIwVXy4zGFywzlRDIYRbiTiY4icwAOEZFu 5B/gnycUqI8el9yKHGwrjJQzHSU9bfTm8vUmLDcn2jQPtM5qFmeupLicpuABiTRd1Zg/ OkkQ== X-Gm-Message-State: AEkoouuu3AbMrWZ8qQcF7EE2CLv+dS8hSsqh0WC1JhF0AWRO6JZizqH6lw4lFdQPqF8qL7xDu0dbwLyclqUW6w== X-Received: by 10.237.41.225 with SMTP id o88mr24824795qtd.18.1469392522294; Sun, 24 Jul 2016 13:35:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 24 Jul 2016 13:35:21 -0700 (PDT) In-Reply-To: References: <20160724112631.GC576@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Sun, 24 Jul 2016 22:35:21 +0200 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS and 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:35:25 -0000 Actually, I just realized that I should do this anyway. On 24 July 2016 at 22:33, Martin Thomson wrote: > On 24 July 2016 at 13:26, Ilari Liusvaara wrote: >> The legacy type of RSA-PSS is RSA, right? > > If I understand you correctly, then yes. When (if) the proposed > revamp goes ahead, we will have to qualify this with the note that > this can only be used with TLS_*_RSA_... We should probably say > something about Ed25519 and Ed448 matching ECDSA suites in the same > way if we decide to backport those too. From nobody Sun Jul 24 13:43:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5EA12B00B for ; Sun, 24 Jul 2016 13:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMSofSCNm4ny for ; Sun, 24 Jul 2016 13:43:14 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC11912B028 for ; Sun, 24 Jul 2016 13:33:27 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id u25so87475275qtb.1 for ; Sun, 24 Jul 2016 13:33:27 -0700 (PDT) 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; bh=h6FooUZuFaoXjmYmvV61zNhkz3rP2shAmY8BqJABFh0=; b=Q2D9vbAAwIjRZ94qocJW/RRmJM4pMKn5b775VjsU7eAc+VY17OjBdeY7W6l1CrxRYQ Fb9XUtzhR8ArDKRHhUj5TT4qd6pXCOEjpmQp34LL8eVu0/WREdibgxxIyDJfXqluzf1x zmqoAhGKE6aXQRWF3ecS3KNmTKbszW9Vi3g3VDlK4I1+BH2HS52YyiOy9A0ehsJnxTio fkqphevBzRNT8kkKY9JIrZ9Nh0wrXoUuDmZCWftyA195eA4kQk62jX6dABMu+gf+Qf+V Bx3WEUCdlnfw6UnlAtKiGb0r1CBdZkExEzrrY8V+TElq3eCS4E0F9zudupRXE3iPUJsM GlOA== 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; bh=h6FooUZuFaoXjmYmvV61zNhkz3rP2shAmY8BqJABFh0=; b=EI9RT6vUeVs+s51fNcB5s2V9V6eh94m4uFL1/2vsx5KNc0TtWJdmbnf1Iea5KHbCYd HdRFTKla3ccx0hcFoA5neIxD2o9NHxlJGhiCB4B/mNGKhViQXwD5Ag4KXHJbEkTukTOA yLnAl3e1kzkjxa9leTcuWLC/DmK8Qmf982UOtZZyExlywMSf3XXEAXMio7kTRkw5Drbs 2vqMDwOk7Q5XFVg6Of2AeOUzJ/3paZwlt5kzJlKmmwKqlG9xjT/kRPcQ4d7lxpbf+B9E NNPpJCY2pySC6Vw8Hj3DHr3w9A/UhiUQubu0rJsxvsiSCIuC846dMTDyHNLexhRy1D/V EQxA== X-Gm-Message-State: AEkooutE2Zqf07CwUlc8S1MbmND7gxF/jF6UCXPYBbzPSX6YlMHHbCSFy/YLQFvLpe3FiVfNYQxt01lv/IEraQ== X-Received: by 10.200.49.203 with SMTP id i11mr24161303qte.40.1469392406768; Sun, 24 Jul 2016 13:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 24 Jul 2016 13:33:26 -0700 (PDT) In-Reply-To: <20160724112631.GC576@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160724112631.GC576@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Sun, 24 Jul 2016 22:33:26 +0200 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS and 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 20:43:16 -0000 On 24 July 2016 at 13:26, Ilari Liusvaara wrote: > The legacy type of RSA-PSS is RSA, right? If I understand you correctly, then yes. When (if) the proposed revamp goes ahead, we will have to qualify this with the note that this can only be used with TLS_*_RSA_... We should probably say something about Ed25519 and Ed448 matching ECDSA suites in the same way if we decide to backport those too. From nobody Mon Jul 25 04:13:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0F12D7AC for ; Mon, 25 Jul 2016 04:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.189 X-Spam-Level: X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV4kqdce9Wd0 for ; Mon, 25 Jul 2016 04:13:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3696012D7AB for ; Mon, 25 Jul 2016 04:13:19 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C620364360; Mon, 25 Jul 2016 11:13:18 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6PBDGeV002795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2016 07:13:18 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 25 Jul 2016 13:13:11 +0200 Message-ID: <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; ) In-Reply-To: <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart209925102.4tRkumrgv7"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 25 Jul 2016 11:13:18 +0000 (UTC) Archived-At: Subject: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 11:13:28 -0000 --nextPart209925102.4tRkumrgv7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 22 July 2016 12:08:00 CEST Hubert Kario wrote: > (I'll try to have more concrete numbers on Monday) So I extended the scanning script to perform two tests - send a "Very=20 Compatible"[1] Client Hello and ones that was extended to be 64KiB long eit= her=20 through addition of padding extension or cipher suites[2]. Then the size th= at=20 was accepted by server was found through binary search by stripping the=20 additional cipher suites or reducing the size of the padding extension. Around first 4300 domains were scanned from the Alexa top 1 million this wa= y.=20 4388 hosts[3] answered to at least a single connection with an unexpired=20 certificate signed by a CA in Mozilla trust program. Of those, 45 (1.03%) could not be connected to (did not receive a Server=20 Hello/.../Server Hello Done reply) with the "Very Compatible" client hello.= =20 And one caused the scan script to abort. There were no TLSv1.2 client hello incompatible or TLS extension incompatib= le=20 hosts in the scan. 170 were detected as TLS 1.3 incompatible (3.9%) 183 were detected as TLS 1.4 incompatible (4.2%) 229 were detected as TLS 1.253 incompatible (5.22%) in the below excerpt (full list below, this is just entries that have at le= ast=20 4 servers with same behaviour), "e/" means that it's the smallest s= ize=20 of "Very Compatible" client hello extended through the padding extension th= at=20 causes its rejection by server, similarly "c/" indicates smallest s= ize=20 rejected by server when the client hello is made big through addition of=20 cipher suite IDs size e/17676 10 0.2279 size e/17676 c/16408 4 0.0912 size e/17676 c/16409 4 0.0912 size e/17520 251 5.7201 size e/17520 c/16408 122 2.7803 size e/17520 c/16409 124 2.8259 size e/17468 5 0.1139 size e/17468 c/16408 3 0.0684 size e/17468 c/16409 2 0.0456 size e/16389 3328 75.8432 size e/16389 c/16389 1750 39.8815 size e/16389 c/16390 1560 35.5515 size e/16385 339 7.7256 size e/16385 c/16385 178 4.0565 size e/16385 c/16386 153 3.4868 size e/16340 5 0.1139 size e/10245 41 0.9344 size e/10245 c/10245 28 0.6381 size e/10245 c/10246 12 0.2735 size e/4092 9 0.2051 size e/4092 c/4093 8 0.1823 size e/2049 4 0.0912 size e/1356 10 0.2279 size e/1356 c/1356 5 0.1139 size e/1356 c/1357 5 0.1139 size c/16646 5 0.1139 size c/16408 142 3.2361 size c/16409 142 3.2361 size c/16389 1760 40.1094 size c/16390 1571 35.8022 size c/16385 182 4.1477 size c/16386 155 3.5324 size c/10245 28 0.6381 size c/10246 12 0.2735 size c/4093 8 0.1823 size c/1356 5 0.1139 size c/1357 5 0.1139 size c/409 5 0.1139 Cumulative distribution function for size intolerancies looks like this: size =3Dc/8192 4064 92.5529 size =3De/8192 4077 92.849 so while there are about 3-4% of servers which are outright incompatible to= =20 TLSv1.3 version in Client Hello, there are also around 2% of servers which = are=20 problematic to connect to (with TLSv1.2 hello) or with a large (up to 4KiB)= =20 client hello =2D-=20 1 - few most common ciphers (ECDHE, ECDSA, DHE, AES, 3DES, RC4, with GCM,= =20 SHA-256, SHA-1 and MD5 HMACs, empty renegotiation info scsv) and common=20 extensions (SNI, supported groups, EC point formats, session ticket, NPN,=20 ALPN, status request and signature algorithms) with no non-standard or=20 uncommon values 2 - ciphersuites were addded from the 0x2000-0xa000 range (excluding=20 TLS_FALLBACK_SCSV) 3 - if different IPs serve the www.example.com and exmple.com domains, bot= h=20 were scanned =46ull list: Intolerancies Count Percent =2D---------------------------------------+---------+------- Huge Cipher List 4143 94.4166 Huge Cipher List (trunc c/16388) 2488 56.7001 SSL 3.254 229 5.2188 TLS 1.0 37 0.8432 TLS 1.1 8 0.1823 TLS 1.3 170 3.8742 TLS 1.4 183 4.1705 Very Compatible 45 1.0255 Xmas tree 687 15.6563 size c/10245 28 0.6381 size c/10246 12 0.2735 size c/10831 1 0.0228 size c/10953 1 0.0228 size c/11001 1 0.0228 size c/1153 3 0.0684 size c/1154 1 0.0228 size c/1155 1 0.0228 size c/11621 2 0.0456 size c/11634 1 0.0228 size c/11697 1 0.0228 size c/11710 2 0.0456 size c/11728 1 0.0228 size c/12044 1 0.0228 size c/12252 1 0.0228 size c/12289 1 0.0228 size c/12443 1 0.0228 size c/12444 1 0.0228 size c/13464 1 0.0228 size c/1356 5 0.1139 size c/1357 5 0.1139 size c/13839 1 0.0228 size c/14486 1 0.0228 size c/14487 3 0.0684 size c/15488 1 0.0228 size c/15503 1 0.0228 size c/15507 1 0.0228 size c/15675 1 0.0228 size c/15912 1 0.0228 size c/15931 1 0.0228 size c/15993 1 0.0228 size c/16008 1 0.0228 size c/16013 1 0.0228 size c/16015 1 0.0228 size c/16016 2 0.0456 size c/16020 1 0.0228 size c/16040 3 0.0684 size c/16094 1 0.0228 size c/16206 1 0.0228 size c/16209 1 0.0228 size c/16272 1 0.0228 size c/16273 1 0.0228 size c/16289 1 0.0228 size c/16353 1 0.0228 size c/16367 1 0.0228 size c/16369 2 0.0456 size c/16375 2 0.0456 size c/16385 182 4.1477 size c/16386 155 3.5324 size c/16387 1 0.0228 size c/16388 1 0.0228 size c/16389 1760 40.1094 size c/16390 1571 35.8022 size c/16404 1 0.0228 size c/16406 1 0.0228 size c/16408 142 3.2361 size c/16409 142 3.2361 size c/1645 1 0.0228 size c/16645 3 0.0684 size c/16646 5 0.1139 size c/1979 1 0.0228 size c/20420 1 0.0228 size c/2049 2 0.0456 size c/2050 1 0.0228 size c/24993 1 0.0228 size c/354 2 0.0456 size c/407 1 0.0228 size c/4076 1 0.0228 size c/4077 1 0.0228 size c/408 1 0.0228 size c/409 5 0.1139 size c/4092 1 0.0228 size c/4093 8 0.1823 size c/410 3 0.0684 size c/555 1 0.0228 size c/663 1 0.0228 size c/664 1 0.0228 size c/666 1 0.0228 size c/8360 1 0.0228 size c/8361 1 0.0228 size c/9853 1 0.0228 size c/9886 1 0.0228 size c/9961 1 0.0228 size c/9963 1 0.0228 size e/10245 41 0.9344 size e/10245 c/10245 28 0.6381 size e/10245 c/10246 12 0.2735 size e/10245 c/663 1 0.0228 size e/10953 1 0.0228 size e/10953 c/10953 1 0.0228 size e/11001 1 0.0228 size e/11001 c/11001 1 0.0228 size e/11404 1 0.0228 size e/11404 c/16375 1 0.0228 size e/11621 1 0.0228 size e/11621 c/11621 1 0.0228 size e/11634 1 0.0228 size e/11634 c/11634 1 0.0228 size e/11696 1 0.0228 size e/11696 c/11697 1 0.0228 size e/11709 2 0.0456 size e/11709 c/11710 2 0.0456 size e/11728 1 0.0228 size e/11728 c/11728 1 0.0228 size e/11763 1 0.0228 size e/11763 c/9886 1 0.0228 size e/11828 1 0.0228 size e/11828 c/1645 1 0.0228 size e/12232 1 0.0228 size e/12232 c/12252 1 0.0228 size e/12288 1 0.0228 size e/12288 c/12289 1 0.0228 size e/12318 1 0.0228 size e/12318 c/15931 1 0.0228 size e/12441 1 0.0228 size e/12441 c/16209 1 0.0228 size e/13378 1 0.0228 size e/13378 c/16375 1 0.0228 size e/1356 10 0.2279 size e/1356 c/1356 5 0.1139 size e/1356 c/1357 5 0.1139 size e/13927 1 0.0228 size e/13927 c/13839 1 0.0228 size e/14036 1 0.0228 size e/14036 c/12044 1 0.0228 size e/14297 1 0.0228 size e/14297 c/11621 1 0.0228 size e/14489 1 0.0228 size e/14489 c/12444 1 0.0228 size e/14490 2 0.0456 size e/14490 c/16390 2 0.0456 size e/14744 1 0.0228 size e/14744 c/16385 1 0.0228 size e/15313 1 0.0228 size e/15313 c/16094 1 0.0228 size e/15490 1 0.0228 size e/15490 c/16206 1 0.0228 size e/15892 1 0.0228 size e/15892 c/8361 1 0.0228 size e/15988 1 0.0228 size e/15988 c/16353 1 0.0228 size e/16006 1 0.0228 size e/16006 c/16013 1 0.0228 size e/16020 2 0.0456 size e/16020 c/15912 1 0.0228 size e/16020 c/16390 1 0.0228 size e/16021 2 0.0456 size e/16021 c/16389 1 0.0228 size e/16021 c/16390 1 0.0228 size e/16022 1 0.0228 size e/16022 c/16389 1 0.0228 size e/16040 3 0.0684 size e/16040 c/16040 3 0.0684 size e/16171 1 0.0228 size e/16171 c/16390 1 0.0228 size e/16271 1 0.0228 size e/16271 c/16008 1 0.0228 size e/16275 3 0.0684 size e/16275 c/15675 1 0.0228 size e/16275 c/16385 1 0.0228 size e/16275 c/16390 1 0.0228 size e/16289 1 0.0228 size e/16289 c/16289 1 0.0228 size e/16303 1 0.0228 size e/16303 c/16386 1 0.0228 size e/16319 1 0.0228 size e/16319 c/16389 1 0.0228 size e/16339 3 0.0684 size e/16339 c/16273 1 0.0228 size e/16339 c/16390 1 0.0228 size e/16339 c/407 1 0.0228 size e/16340 5 0.1139 size e/16340 c/16016 1 0.0228 size e/16340 c/408 1 0.0228 size e/16340 c/409 3 0.0684 size e/16341 3 0.0684 size e/16341 c/410 3 0.0684 size e/16343 1 0.0228 size e/16343 c/409 1 0.0228 size e/16372 1 0.0228 size e/16372 c/16390 1 0.0228 size e/16379 1 0.0228 size e/16379 c/16385 1 0.0228 size e/16385 339 7.7256 size e/16385 c/16385 178 4.0565 size e/16385 c/16386 153 3.4868 size e/16385 c/16390 2 0.0456 size e/16385 c/354 2 0.0456 size e/16385 c/409 1 0.0228 size e/16385 c/664 1 0.0228 size e/16385 c/666 1 0.0228 size e/16385 c/8360 1 0.0228 size e/16387 3 0.0684 size e/16387 c/16389 3 0.0684 size e/16388 3 0.0684 size e/16388 c/16386 1 0.0228 size e/16388 c/16388 1 0.0228 size e/16388 c/16389 1 0.0228 size e/16389 3328 75.8432 size e/16389 c/10831 1 0.0228 size e/16389 c/1154 1 0.0228 size e/16389 c/12443 1 0.0228 size e/16389 c/13464 1 0.0228 size e/16389 c/14486 1 0.0228 size e/16389 c/14487 3 0.0684 size e/16389 c/15488 1 0.0228 size e/16389 c/15503 1 0.0228 size e/16389 c/15507 1 0.0228 size e/16389 c/15993 1 0.0228 size e/16389 c/16015 1 0.0228 size e/16389 c/16016 1 0.0228 size e/16389 c/16367 1 0.0228 size e/16389 c/16369 2 0.0456 size e/16389 c/16387 1 0.0228 size e/16389 c/16389 1750 39.8815 size e/16389 c/16390 1560 35.5515 size e/16562 3 0.0684 size e/16562 c/16409 3 0.0684 size e/16645 1 0.0228 size e/16645 c/16646 1 0.0228 size e/16740 3 0.0684 size e/16740 c/16409 3 0.0684 size e/17297 1 0.0228 size e/17297 c/16408 1 0.0228 size e/17423 1 0.0228 size e/17423 c/16408 1 0.0228 size e/17424 1 0.0228 size e/17424 c/16408 1 0.0228 size e/17468 5 0.1139 size e/17468 c/16408 3 0.0684 size e/17468 c/16409 2 0.0456 size e/17512 3 0.0684 size e/17512 c/16408 3 0.0684 size e/17519 1 0.0228 size e/17519 c/16408 1 0.0228 size e/17520 251 5.7201 size e/17520 c/1153 2 0.0456 size e/17520 c/1155 1 0.0228 size e/17520 c/16404 1 0.0228 size e/17520 c/16406 1 0.0228 size e/17520 c/16408 122 2.7803 size e/17520 c/16409 124 2.8259 size e/17522 1 0.0228 size e/17522 c/16408 1 0.0228 size e/17529 1 0.0228 size e/17529 c/16408 1 0.0228 size e/17532 1 0.0228 size e/17532 c/16409 1 0.0228 size e/17537 1 0.0228 size e/17537 c/16408 1 0.0228 size e/17585 1 0.0228 size e/17585 c/16409 1 0.0228 size e/17676 10 0.2279 size e/17676 c/16408 4 0.0912 size e/17676 c/16409 4 0.0912 size e/17676 c/4076 1 0.0228 size e/17676 c/4077 1 0.0228 size e/17706 3 0.0684 size e/17706 c/16408 3 0.0684 size e/17720 1 0.0228 size e/17720 c/16272 1 0.0228 size e/18032 1 0.0228 size e/18032 c/16409 1 0.0228 size e/18174 1 0.0228 size e/18174 c/16409 1 0.0228 size e/18277 1 0.0228 size e/18277 c/16409 1 0.0228 size e/2046 1 0.0228 size e/2046 c/1979 1 0.0228 size e/2049 4 0.0912 size e/2049 c/1153 1 0.0228 size e/2049 c/2049 2 0.0456 size e/2049 c/2050 1 0.0228 size e/2053 1 0.0228 size e/2053 c/555 1 0.0228 size e/20615 1 0.0228 size e/20615 c/16409 1 0.0228 size e/21501 1 0.0228 size e/21501 c/20420 1 0.0228 size e/25785 1 0.0228 size e/25785 c/24993 1 0.0228 size e/3218 1 0.0228 size e/3218 c/16646 1 0.0228 size e/3219 1 0.0228 size e/3219 c/16646 1 0.0228 size e/3474 2 0.0456 size e/3474 c/16645 2 0.0456 size e/3475 1 0.0228 size e/3475 c/16645 1 0.0228 size e/3731 1 0.0228 size e/3731 c/16646 1 0.0228 size e/3735 1 0.0228 size e/3735 c/16646 1 0.0228 size e/4092 9 0.2051 size e/4092 c/4092 1 0.0228 size e/4092 c/4093 8 0.1823 size e/7866 1 0.0228 size e/7866 c/16020 1 0.0228 size e/8155 1 0.0228 size e/8155 c/16390 1 0.0228 size e/8362 1 0.0228 size e/8362 c/16385 1 0.0228 size e/8364 1 0.0228 size e/8364 c/16389 1 0.0228 size e/8365 1 0.0228 size e/8365 c/16389 1 0.0228 size e/8366 1 0.0228 size e/8366 c/16389 1 0.0228 size e/9853 1 0.0228 size e/9853 c/9853 1 0.0228 size e/9960 1 0.0228 size e/9960 c/9961 1 0.0228 size e/9963 1 0.0228 size e/9963 c/9963 1 0.0228 x:missing information 1 0.0228 =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 Republic --nextPart209925102.4tRkumrgv7 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 iQIcBAABCgAGBQJXlfRHAAoJEJKo0bgB0vX1IksP/2cAJzzas7U6Zr0Kqc4aa1cZ 0qU4YgCM/vdjtCILuuCGzuWAkncNQj2kqMY70qni165oZk1iJUmjRtcoRXXAEuLu dMUg4/VrRevMCrEg4VBJszjsOQOl90RPAKHvRWbXmnTFPv8YmCoosOeLezfzlosx TdzX37Hzwr7fCrHG1LwvYUjqJ++9xgqQShzKMLSyppD+q40FdI1dATFptkWvRYc2 JzbE9aUnkE4Bnru4Bes32z4D5Ec8ni29PcRi4WIIzHje6lb7fEFj4cHqtv1Gwxxb e32AOzCzkMKdmIPk89Bm/5iGLJ/R8OM00wNOekiOHUjoo99rRv7pE/j2yHlMYA4I wzx8PvY/cYK0TC97yd5Y6RmQey8A7iPzNAyJScD+pr73aVhmkO0YvdVR91Y12TfA BLV5hJZXZ1O/iddQfd12RKYNzM1KerHSYMa5ceSB3X5svJR2LGnm9lbPwHWcosBY diq30lbftSexSgDGbFrzW2ryseI107igvvNxnvaXCtAUVDTMvibT8AB9DbQeJ+jr GyKIkewiMvmEmiytNxpomZ65palFoEdQygiFBYACVOqxdpDYcS9R8inpyzobR9fE C/mDlko9WckjbWhqwMZwSVk39AqX9PEqwVMPMI44QgXWCllHIFTwfCyRmhsI7OHQ ulnWbzrZYzFy+vnPV3z8 =d8xj -----END PGP SIGNATURE----- --nextPart209925102.4tRkumrgv7-- From nobody Mon Jul 25 12:08:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416712D595 for ; Mon, 25 Jul 2016 12:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtJKdzy77BLW for ; Mon, 25 Jul 2016 12:08:51 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778B912D565 for ; Mon, 25 Jul 2016 12:08:51 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3ryrQ95DJbz1HqF for ; Mon, 25 Jul 2016 21:08:49 +0200 (CEST) X-purgate-ID: 152705::1469473729-0000082D-B47CE5D2/0/0 X-purgate-size: 1033 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3ryrQ93Yfjzl0BT for ; Mon, 25 Jul 2016 21:08:49 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 728521A508; Mon, 25 Jul 2016 21:08:49 +0200 (CEST) To: tls@ietf.org Date: Mon, 25 Jul 2016 21:08:49 +0200 (CEST) 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: <20160725190849.728521A508@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 25 Jul 2016 19:08:53 -0000 I've just run into a weird interoperability problem with an (alleged) cloudflare/nginx TLS server and my personal Firefox settings. https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg Traditionally I have all TLS ciphersuites with ECDSA disabled through about:config, but it seems that recently two new TLS ciphersuites were added to FF, which caused complete loss of interop with regmedia.co.uk for me with my existing configuration. (Loss of pictures&media on the www.theregister.co.uk news site). specifically, after the FF update, this new TLS ciphersuite: security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9) was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this kills connectivity (TLS handshake_failure alert) with regmedia.co.uk. It looks like a bug in the cloudflare/nginx cipher suites selection algorithm, which appears to blindly go for ECDSA, even though there is no actual ECDSA cipher suite available which the server supports. -Martin From nobody Mon Jul 25 12:37:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8C12D5BE for ; Mon, 25 Jul 2016 12:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjTzDEO5ZSzB for ; Mon, 25 Jul 2016 12:37:15 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 713A012D95D for ; Mon, 25 Jul 2016 12:37:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B87DE85C9; Mon, 25 Jul 2016 22:37:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id fLVSPDYmrtSR; Mon, 25 Jul 2016 22:37:13 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4DA5B21C; Mon, 25 Jul 2016 22:37:13 +0300 (EEST) Date: Mon, 25 Jul 2016 22:37:08 +0300 From: Ilari Liusvaara To: Martin Rex Message-ID: <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160725190849.728521A508@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160725190849.728521A508@ld9781.wdf.sap.corp> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 19:37:25 -0000 On Mon, Jul 25, 2016 at 09:08:49PM +0200, Martin Rex wrote: > I've just run into a weird interoperability problem with an (alleged) > cloudflare/nginx TLS server and my personal Firefox settings. > > https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg > > > Traditionally I have all TLS ciphersuites with ECDSA disabled through > about:config, but it seems that recently two new TLS ciphersuites were > added to FF, which caused complete loss of interop with regmedia.co.uk > for me with my existing configuration. (Loss of pictures&media on the > www.theregister.co.uk news site). > > It looks like a bug in the cloudflare/nginx cipher suites selection > algorithm, which appears to blindly go for ECDSA, even though there is > no actual ECDSA cipher suite available which the server supports. I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way that always negotiates something if at least one valid configuration exists, and respects TLS 1.2 rules. The resulting code was totally insane, and I am very much not surprised to see buggy implementations. Nor can I say my implementation is not buggy, as testing that mess is just about impossible (and it it will very much do GIGO in order to maximize interop). -Ilari From nobody Mon Jul 25 13:15:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA012D95D for ; Mon, 25 Jul 2016 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuQ8jSApK17Y for ; Mon, 25 Jul 2016 13:15:33 -0700 (PDT) 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 503CB12D5C9 for ; Mon, 25 Jul 2016 13:15:33 -0700 (PDT) Received: from [172.31.24.203] (unknown [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 74313284951 for ; Mon, 25 Jul 2016 20:15:31 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20160725190849.728521A508@ld9781.wdf.sap.corp> Date: Mon, 25 Jul 2016 16:15:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3505F9B2-586F-443E-9C03-5529523BE5DE@dukhovni.org> References: <20160725190849.728521A508@ld9781.wdf.sap.corp> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:15:35 -0000 > On Jul 25, 2016, at 3:08 PM, Martin Rex wrote: >=20 > = https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg FWIW, OpenSSL interoperates with this server: Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4169 bytes and written 310 bytes --- New, TLSv1.2, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256 Server public key is 256 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-ECDSA-AES128-GCM-SHA256 Session-ID: = 740096F3B8F9BD08D40028405CA2631E0348BE65BE7453635E1A970081CAE3CE Session-ID-ctx: Master-Key: = 17FDD891614358874800B6F152D4297E715FE20C74205A43BD803DA91CD891287677672AE4= E4F7FBCD989FFE675BF22F PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 64800 (seconds) The server then responds to an HTTP "HEAD" request: HTTP/1.1 404 Not Found Date: Mon, 25 Jul 2016 20:09:52 GMT Content-Type: text/html Connection: keep-alive Set-Cookie: __cfduid=3Ddc03aaa6d430491fcd2a736eaa790f5e11469477392; = expires=3DTue, 25-Jul-17 20:09:52 GMT; path=3D/; domain=3D.regmedia.co.uk;= HttpOnly Cache-Control: private, no-cache, no-store, max-age=3D0 Accept-Ranges: bytes Server: cloudflare-nginx CF-RAY: 2c8240858296187c-EWR --=20 Viktor. From nobody Mon Jul 25 13:36:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5F12DA13 for ; Mon, 25 Jul 2016 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSwi4OkGVR-x for ; Mon, 25 Jul 2016 13:36:29 -0700 (PDT) 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 B907A12D09A for ; Mon, 25 Jul 2016 13:36:29 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9F5C6284951 for ; Mon, 25 Jul 2016 20:36:28 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20160725190849.728521A508@ld9781.wdf.sap.corp> Date: Mon, 25 Jul 2016 16:36:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> References: <20160725190849.728521A508@ld9781.wdf.sap.corp> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jul 2016 20:36:31 -0000 > On Jul 25, 2016, at 3:08 PM, Martin Rex wrote: >=20 > specifically, after the FF update, this new TLS ciphersuite: >=20 > security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9) >=20 > was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this > kills connectivity (TLS handshake_failure alert) with regmedia.co.uk. OpenSSL lists "CC, A9" as: 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=3DECDH Au=3DECDSA= Enc=3DCHACHA20/POLY1305(256) Mac=3DAEAD Which is not AES_128_GCM. The IANA registry seems to agree: = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 0xCC,0xA9 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 Y = [RFC7905] --=20 Viktor. From nobody Mon Jul 25 14:00:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DF512D08E for ; Mon, 25 Jul 2016 14:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScB9VlIs8Czc for ; Mon, 25 Jul 2016 14:00:28 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA612DA25 for ; Mon, 25 Jul 2016 14:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id BC4F97B94 for ; Tue, 26 Jul 2016 00:00:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id ULYLD1jaTOju for ; Tue, 26 Jul 2016 00:00:26 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 157152310 for ; Tue, 26 Jul 2016 00:00:26 +0300 (EEST) Date: Tue, 26 Jul 2016 00:00:21 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160725210021.GA17403@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:00:34 -0000 On Mon, Jul 25, 2016 at 04:36:27PM -0400, Viktor Dukhovni wrote: > > > On Jul 25, 2016, at 3:08 PM, Martin Rex wrote: > > > > specifically, after the FF update, this new TLS ciphersuite: > > > > security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9) > > > > was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this > > kills connectivity (TLS handshake_failure alert) with regmedia.co.uk. > > OpenSSL lists "CC, A9" as: > > 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD I wonder what is happening is that having ECDSA ciphersuite enabled causes Firefox to include the ECDSA signatures in signature_algorithms and the server end sees ECDSA supported, tries to choose that, but then blows up when it does not find any enabled ciphersuites it knows that support ECDSA... -Ilari From nobody Mon Jul 25 14:19:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5F12DA43 for ; Mon, 25 Jul 2016 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtDPyGRAVO8d for ; Mon, 25 Jul 2016 14:19:39 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5D12D0CA for ; Mon, 25 Jul 2016 14:19:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 62BF4423709 for ; Mon, 25 Jul 2016 21:19: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 4214D423701 for ; Mon, 25 Jul 2016 21:19:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469481578; bh=PsaJ2B0AdMo03KG7AVtQyFxiuN/epAOabx8CNe2Ial0=; l=4262; h=To:References:From:Date:In-Reply-To:From; b=OsxOwZASyntM/6+Qp80PeF26h6ADcFBesTfVncZZ1HMBM5tVxWa29FVJ8WQKyfwvm /+pHrxplG2mE9StlmtXXNLz8ItHR6CurR+Lmar8apQV5YCSXbTRYTZ4ANcFbKSZrXo paZnlW5ALUUzDa0PRN5fNr6ZZiSn+BD5hIenWl0Q= 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 2437E1FCB3 for ; Mon, 25 Jul 2016 21:19:38 +0000 (GMT) To: tls@ietf.org References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160725210021.GA17403@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <4867e313-bc0f-43c9-f573-1ee2083211f9@akamai.com> Date: Mon, 25 Jul 2016 16:19:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160725210021.GA17403@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------C90C97F885227CECC1E19D49" Archived-At: Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Jul 2016 21:19:40 -0000 This is a multi-part message in MIME format. --------------C90C97F885227CECC1E19D49 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit If I remember/understand correctly, the cloudflare patch for chacha/poly would (when server preference is in use) only attempt to use it when it appeared first in the client's preference list, and would ignore it elsewhere. This could potentially lead to negotiation failures if, e.g., the server only supported chacha/poly but the client did not put it first in the list. That doesn't seem to match up with what is being described here, but could provide some insight into where to look. -Ben On 07/25/2016 04:00 PM, Ilari Liusvaara wrote: > On Mon, Jul 25, 2016 at 04:36:27PM -0400, Viktor Dukhovni wrote: >>> On Jul 25, 2016, at 3:08 PM, Martin Rex wrote: >>> >>> specifically, after the FF update, this new TLS ciphersuite: >>> >>> security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9) >>> >>> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this >>> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk. >> OpenSSL lists "CC, A9" as: >> >> 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD > I wonder what is happening is that having ECDSA ciphersuite enabled > causes Firefox to include the ECDSA signatures in signature_algorithms > and the server end sees ECDSA supported, tries to choose that, but > then blows up when it does not find any enabled ciphersuites it knows > that support ECDSA... > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------C90C97F885227CECC1E19D49 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit If I remember/understand correctly, the cloudflare patch for chacha/poly would (when server preference is in use) only attempt to use it when it appeared first in the client's preference list, and would ignore it elsewhere.  This could potentially lead to negotiation failures if, e.g., the server only supported chacha/poly but the client did not put it first in the list.  That doesn't seem to match up with what is being described here, but could provide some insight into where to look.

-Ben

On 07/25/2016 04:00 PM, Ilari Liusvaara wrote:
On Mon, Jul 25, 2016 at 04:36:27PM -0400, Viktor Dukhovni wrote:


        

          
On Jul 25, 2016, at 3:08 PM, Martin Rex <mrex@sap.com> wrote:

specifically, after the FF update, this new TLS ciphersuite:

  security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)

was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.


        

        
OpenSSL lists "CC, A9" as:

0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD


      

      
I wonder what is happening is that having ECDSA ciphersuite enabled
causes Firefox to include the ECDSA signatures in signature_algorithms
and the server end sees ECDSA supported, tries to choose that, but
then blows up when it does not find any enabled ciphersuites it knows
that support ECDSA...



-Ilari

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


    

    

  


--------------C90C97F885227CECC1E19D49--


From nobody Mon Jul 25 15:33:06 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C641F12DA5D for ; Mon, 25 Jul 2016 15:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQLhSCfmzALG for ; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010: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 88A1F12D578 for ; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id f93so138298909lfi.2 for ; Mon, 25 Jul 2016 15:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=YBcZy9tsBtKFnkYW4YNuh5uPI/tDFSAUwLnYOuH8LAY=; b=NH4ijZv+9Q7tg86Q5HXyvQynPqFnRzJypUvAcQBcYdwM1BDYG18fJvndiWQoapobOt OnAEL1Tr20qo+T7cUiQ2iAYjdGxE3z0C2ihiL78VvnQx0xJWyjKwgG/XH8RILuoX8f6Z QGt7BKQbO7dq4cxu4s921Cam4XjsZz5i4iTAw=
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; bh=YBcZy9tsBtKFnkYW4YNuh5uPI/tDFSAUwLnYOuH8LAY=; b=XPwWauCubxUbEtrc/8hBOZkIvucPwLNp/Xq2JLN4pCb7P/uEVoiJHJyk7jAfBV1Mpn cP4/FchTlh8nNvjJ6+mRw+Ef415YTFBItYju8C+VfG0lMfNTlxl0uqnjuYteXw0Y/PMR a92qS+jaSPvio/qtvkg6QAQy/sS3EaMh4UaGdFW4KYvEiU2XM1+VBjj1ij1SHdUX8por tpaLZuWH8vbw7l/wyHVkqAQx+kTuQLuWIT9VOD5kG3KByy3fVt1FVCOy3JoSqCIYhouR 89IgseALgmYKzTUJ/ZwQgKsZ4CbNYHeg2lIfmKbhAsEp7+60XcxVvSS62JQSZQtZ5iNx onaw==
X-Gm-Message-State: AEkoouuhL7B9Euwht7FTm2HjYORYj64rWW4UsefBQiqPG/4NnYTJ7KDL/MEDJStwi7WqBLPY6ayeD3zYi9fj3NwF
X-Received: by 10.25.216.26 with SMTP id p26mr8685541lfg.122.1469485959241; Mon, 25 Jul 2016 15:32:39 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin 
Date: Mon, 25 Jul 2016 22:32:29 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114024a49ab17c05387d5c58
Archived-At: 
Subject: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 22:32:46 -0000

--001a114024a49ab17c05387d5c58
Content-Type: text/plain; charset=UTF-8

Hi folks,

I'm not sure how this process usually works, but I would like to reserve a
bunch of values in the TLS registries to as part of an idea to keep our
extension points working. Here's an I-D:
https://tools.ietf.org/html/draft-davidben-tls-grease-00

(The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy
from https://www.imperialviolet.org/2016/05/16/agility.html )

One problem we repeatedly run into is servers failing to implement TLS's
various extension points correctly. The most obvious being version
intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
implementation. (Thankfully it was rare enough to not warrant a fallback or
revert!) It appears that signature algorithms maybe also be gathering rust.
Ciphers and extensions seem to have held up, but I would like to ensure
they stay that way.

The root problem here is these broken servers interoperate fine with
clients at the time they are deployed. It is only after new values get
defined do we notice, by which time it is too late.

I would like to fix this by reserving a few values in our registries so
that clients may advertise random ones and regularly exercise these
codepaths in servers. If enough of the client base does this, we can turn a
large class of tomorrow's interop failures into today's interop failures.
This is important because an bug will not thrive in the ecosystem if it
does not work against the current deployment.

If you were in Berlin, you may recognize this idea from the version
negotiation debate. Alas that all happened in the wrong order as I hadn't
written this up yet. This idea can't be applied to versioning without
giving up on ClientHello.version, but we can start with the rest of the
protocol.

David

PS: This is actually my first I-D, so apologies if I've messed it up
somewhere!

--001a114024a49ab17c05387d5c58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi folks,

I'm not s=
ure how this process usually works, but I would like to reserve a bunch of =
values in the TLS registries to as part of an idea to keep our extension po=
ints working. Here's an I-D:

(The name GREASE=
 is in honor of AGL's rusted vs. well-oiled joints analogy from https://www.imp=
erialviolet.org/2016/05/16/agility.html=C2=A0)

One problem we repeatedly run into is servers failing to implement T=
LS's various extension points correctly. The most obvious being version=
 intolerance. When we deployed X25519 in Chrome, we discovered an intoleran=
t implementation. (Thankfully it was rare enough to not warrant a fallback =
or revert!) It appears that signature algorithms maybe also be gathering ru=
st. Ciphers and extensions seem to have held up, but I would like to ensure=
 they stay that way.

The root problem here is thes=
e broken servers interoperate fine with clients at the time they are deploy=
ed. It is only after new values get defined do we notice, by which time it =
is too late.

I would like to fix this by=C2=A0reserving a few values in our registries so tha=
t clients may advertise random ones and regularly exercise these codepaths =
in servers. If enough of the client base does this, we can turn a large cla=
ss of tomorrow's interop failures into today's interop failures. Th=
is is important because an bug will not thrive in the ecosystem if it does =
not work against the current deployment.

If you were in Berlin, you may recognize this idea from the version nego=
tiation debate. Alas that all happened in the wrong order as I hadn't w=
ritten this up yet. This idea can't be applied to versioning without gi=
ving up on ClientHello.version, but we can start with the rest of the proto=
col.

David

=

PS: This is actually my first I-D, so apologies if I've messed it =
up somewhere!


--001a114024a49ab17c05387d5c58--


From nobody Mon Jul 25 15:35:53 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC5512D0B2 for ; Mon, 25 Jul 2016 15:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hm8Zl21ioem for ; Mon, 25 Jul 2016 15:35:49 -0700 (PDT)
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 8857912B029 for ; Mon, 25 Jul 2016 15:35:48 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id l69so138089969lfg.1 for ; Mon, 25 Jul 2016 15:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Cqien/fxRG2Xq+12qGWaS61nbICBl4UIjXanqOU66Jw=; b=MBk5C9ZLq7teq1zjQwmJKDGt+6a53NUZj102TPpV0NZ3hIgla6NViNZ6I1G/2x95gq BFAHq1wPLe+Ka5FbT7uhOsdX1uYljpCgsiTdFzPqsUPi20WR7p0PfXk7ByTPfaT04Zvp e8TYr1WDFiEiMNqJDTkDyHfJd/NEw7GuaxADY=
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; bh=Cqien/fxRG2Xq+12qGWaS61nbICBl4UIjXanqOU66Jw=; b=euodnFqmUlZecEYSvnGjl40fxMRmzICy94dY8qHCgQPp5ABIe9YaWYf4R4wKIPSFhH TtHZ6SqLGGAZdTt7EurHaI6NIKxqN/8xZMyYAt7ChER5b5Plx6rWG7XKK9Y200x2EvQt bvjAJyX7s5SlTqbl5RLAwZNgmQQQU7FpDL5aTAh7mDM7vUGkSgEECS5Xo8jQx7gxec52 /ua7YYmKkIqOXqsBBWNRnkqLHDQ/5Zb49nuIPimKP8zEhYlFHKMUBuXyNxKaTHiTjCYi TmuDRy2HMchD/EX87Tw813cIzT3t2uSJiyq1n13kjM2ZRKWajrDAknpPYCwr7FY2t8gh uVQw==
X-Gm-Message-State: AEkoousdqiWHyqQJOvFfSvqs00oXnZlmMKhHW0x3A04kzDdkN+JJJE4obhHTY4RN41G1Jl5Cokkh7frXb8yjD79Q
X-Received: by 10.25.145.135 with SMTP id t129mr8753756lfd.163.1469486146503;  Mon, 25 Jul 2016 15:35:46 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: David Benjamin 
Date: Mon, 25 Jul 2016 22:35:37 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11402830c4212405387d67dc
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 22:35:52 -0000

--001a11402830c4212405387d67dc
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 25, 2016 at 6:32 PM David Benjamin 
wrote:

> Hi folks,
>
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft-davidben-tls-grease-00
>
> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy
> from https://www.imperialviolet.org/2016/05/16/agility.html )
>
> One problem we repeatedly run into is servers failing to implement TLS's
> various extension points correctly. The most obvious being version
> intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
> implementation. (Thankfully it was rare enough to not warrant a fallback or
> revert!)
>

Er, I lost a sentence here, sorry.

I meant that, in addition to version intolerance other extension points
have also gathered rust. The X25519 trouble was an example of named curve
intolerance, not version. (Someone forgot a default in their switch-case.)


> It appears that signature algorithms maybe also be gathering rust. Ciphers
> and extensions seem to have held up, but I would like to ensure they stay
> that way.
>
> The root problem here is these broken servers interoperate fine with
> clients at the time they are deployed. It is only after new values get
> defined do we notice, by which time it is too late.
>
> I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn a
> large class of tomorrow's interop failures into today's interop failures.
> This is important because an bug will not thrive in the ecosystem if it
> does not work against the current deployment.
>
> If you were in Berlin, you may recognize this idea from the version
> negotiation debate. Alas that all happened in the wrong order as I hadn't
> written this up yet. This idea can't be applied to versioning without
> giving up on ClientHello.version, but we can start with the rest of the
> protocol.
>
> David
>
> PS: This is actually my first I-D, so apologies if I've messed it up
> somewhere!
>

--001a11402830c4212405387d67dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25=
, 2016 at 6:32 PM David Benjamin <davidben@chromium.org> wrote:
Hi folks,

I'm =
not sure how this process usually works, but I would like to reserve a bunc=
h of values in the TLS registries to as part of an idea to keep our extensi=
on points working. Here's an I-D:

(The name GREASE is in honor of AGL's rusted vs. well-oiled join=
ts analogy from https://www.imperialviolet.org/2016/05/16/agility=
.html=C2=A0)

One problem we repeatedly r=
un into is servers failing to implement TLS's various extension points =
correctly. The most obvious being version intolerance. When we deployed X25=
519 in Chrome, we discovered an intolerant implementation. (Thankfully it w=
as rare enough to not warrant a fallback or revert!)

Er, I lost a sentence here, sorry.

I meant that, in addition to version intolerance other extension poi=
nts have also gathered rust. The X25519 trouble was an example of named cur=
ve intolerance, not version. (Someone forgot a default in their switch-case=
.)
=C2=A0
It appears that signature algorithms maybe also be gathering rust. Ciphe=
rs and extensions seem to have held up, but I would like to ensure they sta=
y that way.

The root problem here is these broken =
servers interoperate fine with clients at the time they are deployed. It is=
 only after new values get defined do we notice, by which time it is too la=
te.

I would like to fix this by=C2=A0reserving a few values in our registries so that clien=
ts may advertise random ones and regularly exercise these codepaths in serv=
ers. If enough of the client base does this, we can turn a large class of t=
omorrow's interop failures into today's interop failures. This is i=
mportant because an bug will not thrive in the ecosystem if it does not wor=
k against the current deployment.

If y=
ou were in Berlin, you may recognize this idea from the version negotiation=
 debate. Alas that all happened in the wrong order as I hadn't written =
this up yet. This idea can't be applied to versioning without giving up=
 on ClientHello.version, but we can start with the rest of the protocol.

David

PS=
: This is actually my first I-D, so apologies if I've messed it up some=
where!


--001a11402830c4212405387d67dc--


From nobody Mon Jul 25 16:23:15 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D9712B00C for ; Mon, 25 Jul 2016 16:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9UH_bufbKmz for ; Mon, 25 Jul 2016 16:23:12 -0700 (PDT)
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 10B4C12D0ED for ; Mon, 25 Jul 2016 16:23:08 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DBF28284F25; Mon, 25 Jul 2016 23:23:07 +0000 (UTC)
Date: Mon, 25 Jul 2016 23:23:07 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20160725232307.GJ4670@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] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 25 Jul 2016 23:23:14 -0000

On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:

> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
>
> https://tools.ietf.org/html/draft-davidben-tls-grease-00

To really make this work, it would be necessary to expand the
reserved pool gradually, rather than all at once, so that servers
can't hard-code just the initially reserved pool, and still fail
with new "real" extensions later.  Add a new code point every year
for 5-10 years, and eventually servers will have extension tolerance.

-- 
	Viktor.


From nobody Mon Jul 25 16:33:08 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B912D8E1 for ; Mon, 25 Jul 2016 16:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWnIdPyN-XPZ for ; Mon, 25 Jul 2016 16:32:53 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010: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 E51CF12D94E for ; Mon, 25 Jul 2016 16:32:52 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id l69so138713997lfg.1 for ; Mon, 25 Jul 2016 16:32:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RrAfIjjZtxAVlg20FCcohbgaqytYMmkgzIZoqJepLIY=; b=SuGXN1Vw0s3jz+VByHeSR7u0Mapz/sFjsH9c8CIkZO75k5d5+KFvlKjqaHOAVGnwVV RZ2CfrE8/0cpgCtdYwIoK2yxvLZCFeo5REyKtmLxBBh6T/jaI58+cUohAou/8kJUriwl XTgwvuNC86pl7s/9dMAhTRKK3G/pOsPthECGk=
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; bh=RrAfIjjZtxAVlg20FCcohbgaqytYMmkgzIZoqJepLIY=; b=NhCuVAyoNC5neV2/k32v3MbHfmsfpBKa1BNgpWFXklqx94LU0QVC/n6GA5aMa8Dna6 XFKFBGhpBWcEZv3G47Rk37aaYoSK0fq6WAjU10dr2ngK/oFtppgw2wGJXzQm3R1GM44e sZhP98I5cCZJNWklpmQslxsjjp9nVvLb6ScozqxpZpFzwhMwTuHr9ERZ+A90G4OCmxn/ oU4avWi/jJsL2rMWwDDRFMoRaQcK1VNELKNINV4wxvlOBpyivVBSh+sBomTkNMO79ScB Esw2Wa4AoMcyLvgNlr7GggFPdCJElUvKkx6BpxOZ2nsjRlXkIb9+OUEzPPGkOTQj3dPu v1aw==
X-Gm-Message-State: AEkoous8NjiLaTBuwCsXXpQ0rOe2BObGjRhuVBwxDTSMsWMWihMeaPaAofkPw//ugwhAG+nylYjKqZMHbAIZsDUi
X-Received: by 10.25.168.212 with SMTP id r203mr9442546lfe.85.1469489570909; Mon, 25 Jul 2016 16:32:50 -0700 (PDT)
MIME-Version: 1.0
References:  <20160725232307.GJ4670@mournblade.imrryr.org>
In-Reply-To: <20160725232307.GJ4670@mournblade.imrryr.org>
From: David Benjamin 
Date: Mon, 25 Jul 2016 23:32:41 +0000
Message-ID: 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a114032a2e068fb05387e33a8
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 23:32:58 -0000

--001a114032a2e068fb05387e33a8
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni 
wrote:

> On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:
>
> > I'm not sure how this process usually works, but I would like to reserve
> a
> > bunch of values in the TLS registries to as part of an idea to keep our
> > extension points working. Here's an I-D:
> >
> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
>
> To really make this work, it would be necessary to expand the
> reserved pool gradually, rather than all at once, so that servers
> can't hard-code just the initially reserved pool, and still fail
> with new "real" extensions later.


My hope is that, especially with the values allocated sparsely, after
getting interop failure once or twice from unknown values, the servers will
quickly figure it out. I'm assuming the implementations simply made
mistakes or weren't paying enough attention to the specification rather
than being actively malicious.

But, you are right, one failure mode here is implementations may
"accidentally" hard-code the reserved pool... somehow.


> Add a new code point every year
> for 5-10 years, and eventually servers will have extension tolerance.
>

To clarify, this is about making sure new implementations don't ossify the
whatever set of named groups (etc.) they observe, not flushing intolerance
out of existing ones. For existing ones, it'd be equally difficult to
deploy, say, GREASE for named groups as it'd be to deploy a new named group
to begin with. (Fortunately, we successfully deployed a new named group
just this year, so this is the perfect time to do that.)

David

--001a114032a2e068fb05387e33a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 25=
, 2016 at 7:23 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:



> I'm not sure how this process usually works, but I would like to r=
eserve a

> bunch of values in the TLS registries to as part of an idea to keep ou=
r

> extension points working. Here's an I-D:

>

> https://tools.ietf.org/html/draft-david=
ben-tls-grease-00



To really make this work, it would be necessary to expand the

reserved pool gradually, rather than all at once, so that servers

can't hard-code just the initially reserved pool, and still fail

with new "real" extensions later. 

My hope is that, especially with the values allocated sparsely, afte=
r getting interop failure once or twice from unknown values, the servers wi=
ll quickly figure it out. I'm assuming the implementations simply made =
mistakes or weren't paying enough attention to the specification rather=
 than being actively malicious.

But, you=
 are right, one failure mode here is implementations may "accidentally=
" hard-code the reserved pool... somehow.
=C2=A0
Add a new code point every year

for 5-10 years, and eventually servers will have extension tolerance.

To clarify, this is about making sure new im=
plementations don't ossify the whatever set of named groups (etc.) they=
 observe, not flushing intolerance out of existing ones. For existing ones,=
 it'd be equally difficult to deploy, say, GREASE for named groups as i=
t'd be to deploy a new named group to begin with. (Fortunately, we succ=
essfully deployed a new named group just this year, so this is the perfect =
time to do that.)

David


--001a114032a2e068fb05387e33a8--


From nobody Tue Jul 26 00:19:44 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB81812B05B for ; Tue, 26 Jul 2016 00:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mklzovayI_GL for ; Tue, 26 Jul 2016 00:19:40 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05FF12B014 for ; Tue, 26 Jul 2016 00:19:40 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3rz8dQ5tfjz1HVF for ; Tue, 26 Jul 2016 09:19:38 +0200 (CEST)
X-purgate-ID: 152705::1469517578-00000827-9CE218E3/0/0
X-purgate-size: 1335
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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rz8dQ3yVdzl3Ks; Tue, 26 Jul 2016 09:19:38 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 815491A507; Tue, 26 Jul 2016 09:19:38 +0200 (CEST)
In-Reply-To: <20160725190849.728521A508@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 26 Jul 2016 09:19:38 +0200 (CEST)
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: <20160726071938.815491A507@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jul 2016 07:19:43 -0000

Correction--

I'm sorry, I mistyped the firefox config, this should have said
the chacha20_poly1305 (0xcc 0xa9) cipher suite was the only one enabled.


 
Martin Rex wrote:
> I've just run into a weird interoperability problem with an (alleged)
> cloudflare/nginx TLS server and my personal Firefox settings.
> 
> https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg
> 
> 
> Traditionally I have all TLS ciphersuites with ECDSA disabled through
> about:config, but it seems that recently two new TLS ciphersuites were
> added to FF, which caused complete loss of interop with regmedia.co.uk
> for me with my existing configuration. (Loss of pictures&media on the
> www.theregister.co.uk news site).
> 
> specifically, after the FF update, this new TLS ciphersuite:
> 
>    security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)

    security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256  (0xcc, 0xa9)
 
> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
> 
> It looks like a bug in the cloudflare/nginx cipher suites selection
> algorithm, which appears to blindly go for ECDSA, even though there is
> no actual ECDSA cipher suite available which the server supports.
> 
> 
> -Martin


From nobody Tue Jul 26 00:48:15 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE912B05B for ; Tue, 26 Jul 2016 00:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsdoWS_KzSCN for ; Tue, 26 Jul 2016 00:48:10 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E2712B028 for ; Tue, 26 Jul 2016 00:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1469519289; x=1501055289; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LKMFl1RATk9PW4xFQ21e5jeNKdYR3I2HeopnvNYHOc4=; b=k+R+BYzHYIaurPgwazdpIiFdj282gU82w5eCExmrimhsy3hBdHi7K4g+ nMMdeuceHm+7Adt744Bt+jmJSCwr2DpdSEjTVGdJrsAoULATbbQ+nATo5 oipnK+844sY87rJX9Bh5CZUbCyIiTThMh46pcn+PMRoc4L9J85LFs2ojA lIC4YTLesWMYx8pOlMlnhoazaimfQW+jWOo6TeDaWJWkQCVZeL3BRiq6/ oXjb+B8+0PJk0iQlcw4QXj9+2w829Y0VOQgmMK2HqHgXg0/gTkZl4d+cv 8pfVYFMLvZ+mHMIfvv0bMZSmXRsf41LQNAaiXCRwl+SGAtAUn03lXstUI A==;
X-IronPort-AV: E=Sophos;i="5.28,423,1464609600"; d="scan'208";a="98934869"
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; 26 Jul 2016 19:48:06 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 26 Jul 2016 19:48:06 +1200
From: Peter Gutmann 
To: Ilari Liusvaara , Martin Rex 
Thread-Topic: [TLS] weird ECDSA interop problem with cloudflare/nginx
Thread-Index: AQHR5qgCNz+FR8k/8Uif+jsgAebuiKAowWEAgAGVRQ4=
Date: Tue, 26 Jul 2016 07:48:05 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp>, <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.6.3.3]
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] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 07:48:13 -0000

Ilari Liusvaara  writes:=0A=
=0A=
>I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a w=
ay=0A=
>that always negotiates something if at least one valid configuration exist=
s,=0A=
>and respects TLS 1.2 rules.=0A=
>=0A=
>The resulting code was totally insane, and I am very much not surprised to=
=0A=
>see buggy implementations. Nor can I say my implementation is not buggy, a=
s=0A=
>testing that mess is just about impossible (and it it will very much do GI=
GO=0A=
>in order to maximize interop).=0A=
=0A=
Do you have any more details on some of the issues you ran into?  It'd be g=
ood=0A=
to know for anyone else in this situation.=0A=
=0A=
(I've had to do the same thing, with awkward logic that backs off and retri=
es=0A=
different options if an earlier attempt fails.  This was one of the motivat=
ors=0A=
for the Grigg's Law cipher-suite handling in TLS-LTS).=0A=
=0A=
Peter.=


From nobody Tue Jul 26 02:52:29 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2912D0B7 for ; Tue, 26 Jul 2016 02:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15jOjlWZMFWr for ; Tue, 26 Jul 2016 02:52:27 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6856312D09C for ; Tue, 26 Jul 2016 02:52:27 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3rzD1j5F6mz1H98 for ; Tue, 26 Jul 2016 11:52:25 +0200 (CEST)
X-purgate-ID: 152705::1469526745-0000082D-FBA0BBAD/0/0
X-purgate-size: 1445
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 mail06.wdf.sap.corp (Postfix) with ESMTP id 3rzD1j3sn8zl3Gt for ; Tue, 26 Jul 2016 11:52:25 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 7E1001A508; Tue, 26 Jul 2016 11:52:25 +0200 (CEST)
In-Reply-To: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org>
To: tls@ietf.org
Date: Tue, 26 Jul 2016 11:52:25 +0200 (CEST)
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: <20160726095225.7E1001A508@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jul 2016 09:52:29 -0000

Viktor Dukhovni wrote:
> 
>> On Jul 25, 2016, at 3:08 PM, Martin Rex  wrote:
>> 
>> specifically, after the FF update, this new TLS ciphersuite:
>> 
>>   security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)
>> 
>> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
>> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
> 
> OpenSSL lists "CC, A9" as:
> 
> 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
> 
> Which is not AES_128_GCM.  The IANA registry seems to agree:
> 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> 
>   0xCC,0xA9	TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256	Y	[RFC7905]


Sorry for the confusion about the cipher suite.

The issue seems a little weirder than what I thought, because the
failure seems to happen only for a particular cipher suite combo
(which happens to be the combo produced by my own Firefox config):

I can repro the handshake failure with openssl-1.1.0-pre5 with this
command line:

Failure:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305

Success:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256

Success:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-ECDSA-CHACHA20-POLY1305



-Martin


From nobody Tue Jul 26 03:09:15 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0E12D4FB for ; Tue, 26 Jul 2016 03:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzFvJkDeMLh2 for ; Tue, 26 Jul 2016 03:09:12 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 59B2312D1C0 for ; Tue, 26 Jul 2016 03:09:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id DBCC77B47; Tue, 26 Jul 2016 13:09:10 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id PclPAoBabCrG; Tue, 26 Jul 2016 13:09:09 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B1D67C4; Tue, 26 Jul 2016 13:09:09 +0300 (EEST)
Date: Tue, 26 Jul 2016 13:09:04 +0300
From: Ilari Liusvaara 
To: Martin Rex 
Message-ID: <20160726100904.GA24234@LK-Perkele-V2.elisa-laajakaista.fi>
References: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160726095225.7E1001A508@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20160726095225.7E1001A508@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 10:09:14 -0000

On Tue, Jul 26, 2016 at 11:52:25AM +0200, Martin Rex wrote:
> 
> Sorry for the confusion about the cipher suite.
> 
> The issue seems a little weirder than what I thought, because the
> failure seems to happen only for a particular cipher suite combo
> (which happens to be the combo produced by my own Firefox config):
> 
> I can repro the handshake failure with openssl-1.1.0-pre5 with this
> command line:
> 
> Failure:
> openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305

If you swap the order of these two ciphersuites, does it suceed or fail?

I.e.

openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256


Well, your test results certainly blow basic "negotiation accidentially
blows off all valid candidates and then fails" hypothesis out of the
water. So it has to be soemthing more complicated.

Succeeding with the ciphersuites swapped would suggest (as somebody
else in this thread already said) that it only considers Chacha in
the first place, not noticing that it may be the only choice after
certificate selection.


-Ilari


From nobody Tue Jul 26 03:33:08 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6703812D594 for ; Tue, 26 Jul 2016 03:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omt3_tJwXqyI for ; Tue, 26 Jul 2016 03:33:04 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F69D12D180 for ; Tue, 26 Jul 2016 03:33:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9294B833 for ; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 18u1TEnBakNq for ; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 426D9C4 for ; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
Date: Tue, 26 Jul 2016 13:32:57 +0300
From: Ilari Liusvaara 
To: tls@ietf.org
Message-ID: <20160726103257.GA24563@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 10:33:06 -0000

On Tue, Jul 26, 2016 at 07:48:05AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara  writes:
> 
> >I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way
> >that always negotiates something if at least one valid configuration exists,
> >and respects TLS 1.2 rules.
> >
> >The resulting code was totally insane, and I am very much not surprised to
> >see buggy implementations. Nor can I say my implementation is not buggy, as
> >testing that mess is just about impossible (and it it will very much do GIGO
> >in order to maximize interop).
> 
> Do you have any more details on some of the issues you ran into?  It'd be good
> to know for anyone else in this situation.
> 
> (I've had to do the same thing, with awkward logic that backs off and retries
> different options if an earlier attempt fails.  This was one of the motivators
> for the Grigg's Law cipher-suite handling in TLS-LTS).

The basic problem (let's ignore non-cert modes for a bit):

When choosing the certificate, you need to consider if you have a
ciphersuite that can use some supported group and protection/prf-hash
available.

Similarly, when choosing a group, you need to consider that you have
a ciphersuite that is consistent in other (possible) choices.

And protection/prf-hash also has to be consistent with other
choices.


The reason these choices couple is because the client can send
pretty much arbitrary combination of oters that depends on each
considered factor.

And the selections have to be consistent: The current leading
hypothesis about this interop issue is that certificate selection
consisers ciphersuite valid candidate when protection selection does
not.


TLS 1.3 negotiation revamp would solve this by ensuring that
whichever you choose first, you don't restrict choice on others
(PSK modes are special here, so need to be chosen first[1]), so
whatever you have chosen so far, there either is next valid
choice, or the whole problem has no solution.


[1] There are some couplings here too, but one only needs to check
group overlap for ke and signature/cert overlap for auth (and these
overlap decisions can be used for normal dhe/cert anyway). And one
does not need to consider interaction of those two.



-Ilari


From nobody Tue Jul 26 03:56:28 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E460912D51D for ; Tue, 26 Jul 2016 03:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level: 
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m23TsugYtkZj for ; Tue, 26 Jul 2016 03:56:24 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917DE12D1C8 for ; Tue, 26 Jul 2016 03:56:24 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D2216461C1; Tue, 26 Jul 2016 10:56:23 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6QAuMrX004521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 06:56:23 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Tue, 26 Jul 2016 12:56:12 +0200
Message-ID: <2695834.rtq9bPkfeJ@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1992926.SEj5avrmM5"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 26 Jul 2016 10:56:24 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 10:56:26 -0000

--nextPart1992926.SEj5avrmM5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn=
 a
> large class of tomorrow's interop failures into today's interop failures.
> This is important because an bug will not thrive in the ecosystem if it
> does not work against the current deployment.

What prevents an implementation from ignoring values from just those reserv=
ed=20
ranges and continuing to be intolerant to other values? After all, if they =
are=20
reserved for this, they just need to ignore those values (as no "real"=20
extension/value will ever use them) to "resolve the problem".

=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 Republic
--nextPart1992926.SEj5avrmM5
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

iQIcBAABCgAGBQJXl0HMAAoJEJKo0bgB0vX1RmcP/jYMpl+XbnLzk4oCJlxA08R7
gzyNGcySDnUoHqh9WjgF1PTyMV3LewPWWrMyiBQtG7PFj16Yprz67KzLGf7+i9z/
tP/unMSOlcj3jjsU+l8OrjVE0nn8Bpoy02nMNb4IxFwL7ez982rXuJTLIP8/0/0c
co3UUo7Ej1R+yb9LZg5eTDhXKJxNykX9C6eFERptxVXbJMcbRfyM6XAOfHlNR7B2
9u7qrXrqAXXdaagavhxoqm05Df0l89WHUvmik37Qk33nrpdaw1AQVtJVVGrkGWlx
7h3/vfTRIfaYI1V/s5PuHCRB/WMApw3Ygalg0rS1kgJ60PSyDxNHjA4HK8xSk21P
s5FafE2tEVrdH3mmcwate210kzJT1s+H3iOG9nrNs7JQJGSQxJWpdplki5ntWCyD
Ljv0AT1JUoucabNeuqNWRxW1PffYOZrQhZISC6KvbylT9RhDzuO/MFl9acmv7bVo
G6RYWaNOCGj0vuwVm/hFI4hTkxQuC/Ml2A4tQNcknqmm2X7EbGBFym5P6QPSDcEf
gQosSo3Xo08fH4WY7MnLfE0OfmshM4ulQnFjGtOeI4e/8bj7fw6J4/qWsz6cpQGb
wMhDYiZFkKUycNzSElo/zSd1MBKxpg4j5weKG23MGSbzjr1BaVrTVaz+TsvkLWDv
h1xk6ZV/SgziIPihDoa/
=iPKF
-----END PGP SIGNATURE-----

--nextPart1992926.SEj5avrmM5--


From nobody Tue Jul 26 04:03:55 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19012D1C0 for ; Tue, 26 Jul 2016 04:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVj4ny0Nue6I for ; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010: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 2ACEE12D0F5 for ; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id b199so2487941lfe.0 for ; Tue, 26 Jul 2016 04:03:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5a6310U9MZhQcaX9ACFYK2iM2A1K2VkMN2iYU6WSvBs=; b=eZi6A3GLNEMfy8bZdUtEGJvs+IGIJZQTJkQ4qwxtkMAg6YZda2lrSTTJfIggdR2LlX qDi9vJDu5DGbvgq/1nK6bwpCpGtPgUwxmGGl0X25Ef2XiP7eHGTmXAo4StSmFrSAYLGQ EQ5Cc2oorWjii1Vo8OQ0jPkL0AtzKMNWkZOOw=
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; bh=5a6310U9MZhQcaX9ACFYK2iM2A1K2VkMN2iYU6WSvBs=; b=Ryp4wxbmdviayvPkgS8r3R8I0S2hrNQLIOFQ3gX20SzaIvEsbRzQG+JIgA7mGt5wSc MKIFdEGaoXpEjstd3GMhGkNEuTQvJ9HqbTusywS7UEzlg2MhiTdwsWqZuOfqq7ZZNVfT +CMNjx/C5+CLPiCyn0sElb7BRkMnfk9veWgQ+DCJzySZtGiUZVdrani+CMrg9ru4HflF f5fX8AhObA4EPNkf5CgOvFOJos+yILx2MZZ4xC4MJfkI6RaKxTg6890UpZep5SPyXB6f z+XNP/ThNRZNBV0CD3y3NbBmrFqIgvjLh3+9lX/hzpLcp4aWEbp9wQ+BdTkYSNcoos9/ AJzg==
X-Gm-Message-State: AEkoousL5oD0XySW+tqI7l+9tSyev4RCmRAvkN7LPpPv5V7b1M/Ze0d4SlcLAoa8iBJJShG3ZlkmXBoOTpwfGmic
X-Received: by 10.25.168.212 with SMTP id r203mr10390373lfe.85.1469531030192;  Tue, 26 Jul 2016 04:03:50 -0700 (PDT)
MIME-Version: 1.0
References:  <2695834.rtq9bPkfeJ@pintsize.usersys.redhat.com>
In-Reply-To: <2695834.rtq9bPkfeJ@pintsize.usersys.redhat.com>
From: David Benjamin 
Date: Tue, 26 Jul 2016 11:03:39 +0000
Message-ID: 
To: Hubert Kario , tls@ietf.org
Content-Type: multipart/alternative; boundary=001a114032a20ae32b053887db1e
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 11:03:54 -0000

--001a114032a20ae32b053887db1e
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario  wrote:

> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> > I would like to fix this by reserving a few values in our registries so
> > that clients may advertise random ones and regularly exercise these
> > codepaths in servers. If enough of the client base does this, we can
> turn a
> > large class of tomorrow's interop failures into today's interop failures.
> > This is important because an bug will not thrive in the ecosystem if it
> > does not work against the current deployment.
>
> What prevents an implementation from ignoring values from just those
> reserved
> ranges and continuing to be intolerant to other values? After all, if they
> are
> reserved for this, they just need to ignore those values (as no "real"
> extension/value will ever use them) to "resolve the problem".
>

Nothing. Just as nothing prevents an implementation from taking every
ClientHello current browsers send (variable parts like client_random
normalized), hard-coding their SHA-256 hashes, and rejecting anything that
doesn't match.

The point is to catch honest mistakes, not to avoid servers that are
maliciously trying to mess up the ecosystem.

We can certainly increase the pool over time as Viktor suggested if
special-casing these becomes a problem. I don't expect it to be, but we'll
see. Whereas not ignoring unknown values has empirically been a problem.

David

--001a114032a20ae32b053887db1e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, Jul 26=
, 2016 at 6:56 AM Hubert Kario <hka=
rio@redhat.com> wrote:
On Mo=
nday, 25 July 2016 22:32:29 CEST David Benjamin wrote:

> I would like to fix this by reserving a few values in our registries s=
o

> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can t=
urn a

> large class of tomorrow's interop failures into today's intero=
p failures.

> This is important because an bug will not thrive in the ecosystem if i=
t

> does not work against the current deployment.



What prevents an implementation from ignoring values from just those reserv=
ed

ranges and continuing to be intolerant to other values? After all, if they =
are

reserved for this, they just need to ignore those values (as no "real&=
quot;

extension/value will ever use them) to "resolve the problem".
=


Nothing. Just as nothing prevents an imple=
mentation from taking every ClientHello current browsers send (variable par=
ts like client_random normalized), hard-coding their SHA-256 hashes, and re=
jecting anything that doesn't match.

The point=
 is to catch honest mistakes, not to avoid servers that are maliciously try=
ing to mess up the ecosystem.

We can certainly inc=
rease the pool over time as Viktor suggested if special-casing these become=
s a problem. I don't expect it to be, but we'll see. Whereas not ig=
noring unknown values has empirically been a problem.

<=
div>David


--001a114032a20ae32b053887db1e--


From nobody Tue Jul 26 04:15:14 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944512B00B for ; Tue, 26 Jul 2016 04:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEhKkRYQFvkz for ; Tue, 26 Jul 2016 04:15:11 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FB812D0F5 for ; Tue, 26 Jul 2016 04:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1469531711; x=1501067711; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ehTH4ODiRTXvCmdVt1Z29EJQIRuc6gEtGYQNJM3wqY8=; b=khcE7mArdL8mH19uyhZtmot78ugWEsERrP1sj3XuZulYRTB1qEfpnM7/ 4ao0JexcZMZYbkZ+oceIcxXo0+XA9XCNOkjjqp0bjumwVku2t6E4ulZz2 MzbjCXVDyGxA64mVYfXHWxSDHp7viCUsXycGwG4d/Ee7HUF167JCYC5X9 8Vg5oJjOaiz7IfuCmn6yQyI9Z6FcoLluscrNWpmJE08guhpQ2tm/D5Jt8 KbkxPp5uoS1WPlw0QUpkNzv8BnmUcx/66GyK1h2geeBJMB0un4R+XZP0O n70oIoit8S3gSO7KyZid5Tla5H8c1EJKINl4x7MPe61nrcN55n2GfQmAZ w==;
X-IronPort-AV: E=Sophos;i="5.28,424,1464609600"; d="scan'208";a="98956934"
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; 26 Jul 2016 23:15:09 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 26 Jul 2016 23:15:09 +1200
From: Peter Gutmann 
To: Ilari Liusvaara , "tls@ietf.org" 
Thread-Topic: [TLS] weird ECDSA interop problem with cloudflare/nginx
Thread-Index: AQHR5qgCNz+FR8k/8Uif+jsgAebuiKAowWEAgAGVRQ7//2UFgIAA1L6+
Date: Tue, 26 Jul 2016 11:15:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CD7BA9@uxcn10-5.UoA.auckland.ac.nz>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>, <20160726103257.GA24563@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160726103257.GA24563@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.6.3.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 11:15:13 -0000

Ilari Liusvaara  writes:=0A=
=0A=
>The basic problem (let's ignore non-cert modes for a bit):=0A=
>=0A=
>When choosing the certificate, you need to consider if you have a ciphersu=
ite=0A=
>that can use some supported group and protection/prf-hash available.=0A=
>=0A=
>Similarly, when choosing a group, you need to consider that you have a=0A=
>ciphersuite that is consistent in other (possible) choices.=0A=
>=0A=
>And protection/prf-hash also has to be consistent with other choices.=0A=
>=0A=
>The reason these choices couple is because the client can send pretty much=
=0A=
>arbitrary combination of oters that depends on each considered factor.=0A=
=0A=
OK, so that's pretty much the same stuff I ran into.  What makes it really=
=0A=
ugly is that you can no longer decide, based on a cipher suite offered,=0A=
whether you can actually continue with that, but then have to tunnel down i=
nto=0A=
the extensions that follow the suites to see what's there.  If there's noth=
ing=0A=
appropriate you go back to the cipher suites and find the next-best match, =
try=0A=
that against the extensions, and so on.  Mostly things appear to work now=
=0A=
because virtually everything supports the de facto standard of P256 + SHA-2=
56=0A=
with ECDSA and ECDH (which is why TLS-LTS specifies it as one of its two su=
ite=0A=
choices), but once you start veering away from that de facto universal=0A=
standard you run into problems.  Rather than spend forever trying various=
=0A=
poke-and-hope strategies, my code looks for the default form (P/SHA-256) an=
d=0A=
if that's not found falls back to DHE + RSA.  That seems to work well enoug=
h,=0A=
and I don't have to debug weird failures with oddball combinations.=0A=
=0A=
Peter.=


From nobody Tue Jul 26 04:20:10 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB312D19B for ; Tue, 26 Jul 2016 04:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level: 
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJHI0YJkqHhb for ; Tue, 26 Jul 2016 04:20:06 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE3A12B00B for ; Tue, 26 Jul 2016 04:20:06 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 29D607F3ED; Tue, 26 Jul 2016 11:20:06 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6QBK4I0018874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 07:20:05 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Tue, 26 Jul 2016 13:20:04 +0200
Message-ID: <5978094.xVKia22VZX@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: 
References:  <20160725232307.GJ4670@mournblade.imrryr.org> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1792138.q83CGEY1Ds"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 26 Jul 2016 11:20:06 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 11:20:08 -0000

--nextPart1792138.q83CGEY1Ds
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 25 July 2016 23:32:41 CEST David Benjamin wrote:
> On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni 
>=20
> wrote:
> > On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:
> > > I'm not sure how this process usually works, but I would like to rese=
rve
> >=20
> > a
> >=20
> > > bunch of values in the TLS registries to as part of an idea to keep o=
ur
> > > extension points working. Here's an I-D:
> > >=20
> > > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> >=20
> > To really make this work, it would be necessary to expand the
> > reserved pool gradually, rather than all at once, so that servers
> > can't hard-code just the initially reserved pool, and still fail
> > with new "real" extensions later.
>=20
> My hope is that, especially with the values allocated sparsely, after
> getting interop failure once or twice from unknown values, the servers wi=
ll
> quickly figure it out. I'm assuming the implementations simply made
> mistakes or weren't paying enough attention to the specification rather
> than being actively malicious.
>=20
> But, you are right, one failure mode here is implementations may
> "accidentally" hard-code the reserved pool... somehow.

Then we have "pet-projects" of which the primary/only developer walks away/
changes jobs well after it was tightly integrated with already deployed=20
systems, code that is passed over to interns as nobody either has time,=20
inclination or knows much about  anyway[1]=
=2E..

Thus I don't think it solves the problem even for non malicious programmers

While the idea of code points that MUST NOT be negotiated by servers is not=
=20
bad one from testing perspective, we already have few values like this=20
(0x00,0x14 for cipher, 15 for supported groups, just of the top of my head)=
=2E=20
And for a test suite any value not defined by IANA already has this functio=
n=20
(and you do need to test all those values to search for undocumented featur=
es,=20
backdoors, etc. anyway).

 1 - talking purely hypothetically here, even if I wanted, I wouldn't know=
=20
where to point fingers in realm of TLS implementations
=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 Republic
--nextPart1792138.q83CGEY1Ds
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

iQIcBAABCgAGBQJXl0dkAAoJEJKo0bgB0vX1kIIP/3hZqtCVhRbMeIBZtKQbrlzn
7czFcnpRH+RjI664k3Wa9GpDgUp1ULcu6C4Y2LvLaTXBWDiElG6Bxm/nbSbk5a5C
RFeHmpvzCwlJNjT4iovYR2oQy4pT3NxiwvPhzae+kW/vjlN4uGK2bxhA/7lpyMmj
RAZnmUHJp7ZaRA53n+nHLW28zAPsBouQfaMzDMUVjbzoTQpY4dWNjcUp8JZTbVuL
CdlQM9LIaDv8KGI3MujgBA2JIAQnIoFLFpaglOkfUjYRC1FrfJNzp2ueNlCJMCjy
fK5ONFkwsO2EG37WZeWpkpcDZABeboX0GM4ohhWibo4bc/wA3yP3V1jlwIEnKMUs
D4rL5FHyn1z8kETRoWc19Pz1tXP0O8MCbpn+J4vawnmhqwZW4+GeBon2gm/OhNkb
dYFSdZYDRvrVQ0FY3Qbjs+M5q8ysQXhxMxty4D03erOKA7F9KdqeDOMpgu0+mpdV
tg9GCD091orlyTXpER7VMrioedcShBN0dJKFdCZ9FIFiqDCbeXe55TJvlJCyjrlk
wJB7eDaUhSrDoW6LOuDk1l4GCIvxEFlx9W5cNe1dnQPjH4pewVWLRR8rvUCEZpLd
JgOg5f8VwNlwN+BE88fw0r0EvPzK9kP+2kiDwcnXREuexWH47VkgGQKspd0CfIYO
+M2omk34BFWicvyRrpSX
=B0Fx
-----END PGP SIGNATURE-----

--nextPart1792138.q83CGEY1Ds--


From nobody Tue Jul 26 04:28:18 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3575F12D548 for ; Tue, 26 Jul 2016 04:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 818GFMBTF_YL for ; Tue, 26 Jul 2016 04:28:15 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B4D12D6A8 for ; Tue, 26 Jul 2016 04:28:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1469532494; x=1501068494; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=idS+Hxgo+7ULezqqZMaELpN9Ai6NFr5V0U6pdryw0a4=; b=M3FL/jyvX1Or4kCiOIB/+oQdjFiYX/WaXp57HX2mqUGOurNb8rIQxkwf f0Yt/l57FKmstO0RxDB/ZE+NW/cM9WXQKEpfXJ0AkvO+p8nNRrwY0eB/T g1eT9YlOg9I2IsNScCo0x8xbT7I47hrWZviNyA/Fzsk7xt0xVY9Qa48Vi 2dUWvakYtk4eDnA1Fr2rsf+h6gaobCOY1Uix+ie1mPjp5V/W7hBUmxYIn 4g4nk7xsJJD7WzVIJfuqm4dqsA2eblV7K9iOGcZFrmOhCB3rG5jdxFIYU Cdv2bZBFHHLKrPF9/o/gL6jW8aMJ5RWNR170dW7gOmbVWNvbQ9SXqqpXR g==;
X-IronPort-AV: E=Sophos;i="5.28,424,1464609600"; d="scan'208";a="98958095"
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/DHE-RSA-AES256-SHA; 26 Jul 2016 23:28:06 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 26 Jul 2016 23:28:06 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] weird ECDSA interop problem with cloudflare/nginx
Thread-Index: AQHR5qgCNz+FR8k/8Uif+jsgAebuiKAowWEAgAGVRQ7//2UFgIAA2HnA
Date: Tue, 26 Jul 2016 11:28:05 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CD7DAB@uxcn10-5.UoA.auckland.ac.nz>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>, <20160726103257.GA24563@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160726103257.GA24563@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.6.3.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 11:28:17 -0000

Since I've referred to TLS-LTS a couple of times now I should mention that=
=0A=
I've just posted an update, with the following changes:=0A=
=0A=
- Clarified what happens during a session resumption.=0A=
=0A=
- Fixed the ServerKeyExchange text to indicate what happens when the hash=
=0A=
  isn't the default SHA-256.  Is the resulting text comprehensible?  That i=
s,=0A=
  does it make clear what's signed, and with what hash?=0A=
=0A=
- Added an alternative, quicker way to verify domain parameters that doesn'=
t=0A=
  require the full FIPS 186 checks.=0A=
=0A=
- Reworked the text about the handling of extensions yet again.  I'm still =
not=0A=
  happy with this, or certain that it's sufficiently unambiguous, can peopl=
e=0A=
  see if they can pick holes in it?=0A=
=0A=
- Reworked the rationale.=0A=
=0A=
Peter.=0A=


From nobody Tue Jul 26 04:29:12 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74C12D0F5 for ; Tue, 26 Jul 2016 04:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level: 
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FJmOXE0kExq for ; Tue, 26 Jul 2016 04:29:08 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EF312D5DE for ; Tue, 26 Jul 2016 04:29:08 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA5FC883AA; Tue, 26 Jul 2016 11:29:07 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6QBT6h1004584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 07:29:07 -0400
From: Hubert Kario 
To: tls@ietf.org, mrex@sap.com
Date: Tue, 26 Jul 2016 13:29:05 +0200
Message-ID: <25341155.UaJz9LbDt0@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: <20160725190849.728521A508@ld9781.wdf.sap.corp>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1517808.u7iBchVPd0"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 26 Jul 2016 11:29:08 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 11:29:11 -0000

--nextPart1517808.u7iBchVPd0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 25 July 2016 21:08:49 CEST Martin Rex wrote:
> I've just run into a weird interoperability problem with an (alleged)
> cloudflare/nginx TLS server and my personal Firefox settings.
>=20
> https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg
>=20
>=20
> Traditionally I have all TLS ciphersuites with ECDSA disabled through
> about:config, but it seems that recently two new TLS ciphersuites were
> added to FF, which caused complete loss of interop with regmedia.co.uk
> for me with my existing configuration. (Loss of pictures&media on the
> www.theregister.co.uk news site).
>=20
> specifically, after the FF update, this new TLS ciphersuite:
>=20
>    security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)
>=20
> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
>=20
> It looks like a bug in the cloudflare/nginx cipher suites selection
> algorithm, which appears to blindly go for ECDSA, even though there is
> no actual ECDSA cipher suite available which the server supports.

could you post packet capture (pcap format, if possible) that shows that=20
problem?

=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 Republic
--nextPart1517808.u7iBchVPd0
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

iQIcBAABCgAGBQJXl0mBAAoJEJKo0bgB0vX1fc8P/374His264E7Q/B9fi6Wk3ra
vL2ilKl/HrgG5zIaUCc8yjlfcGpvXo7OmVk4ubRjsFMJjYPRSSsNPmke/OLsfR+S
R7uhblhmEsMBI9UFXsFb5alKwGz3IzCQwiAmtgSYC7geC4u8rM4u2H77OWTK88CN
hSvxlPpHXPAUWUCuzQ6q8wtTp6eNY8FtYu3wkk7HipinVHOevu5nD0w3Pkv4eG2A
CkSUdr+65l+XU2PLTohxZB41Vh5znYpSDyGtwsDOhqXUAppf+npC8VTTlyT3ztS6
Ih8L6B8hEoL6QpFvQpYsBxpsSep/+Rg5gW5MacQwtutE0JEIEk9kha6V4kVeh5uw
+Fwy1zQqlcax23yNCVri/7yWp3pOyfhRBc6IhuU+psv7hkkg0gdLeAzP2DIWR0Mp
3xpI5yuWycUpS1SOJMOIDdLqClEnkuLWBTBi2oiGekU+NNr4rVFgQgZFTUkKOzDT
nVCte3HgLdasHvDgV8jC333lQEJILwxmiydGwEgUG0LKCcm3LglLBxueVGeJYhUp
FVYm++mr45shSpwMHdSPCff1bnVOvm+wMfNH9CstK/NDQH/Swjin+HKIxHf9lLCP
V4oRHOhdWQjh0d3CCeOj2qoQlQBZ2D2kpzOS5nh6a5huG2tghDRb95oUizpjF50n
HTP0ICkP0xCdiXayy2iV
=F5Rs
-----END PGP SIGNATURE-----

--nextPart1517808.u7iBchVPd0--


From nobody Tue Jul 26 05:08:38 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274E512D745 for ; Tue, 26 Jul 2016 05:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmoLvLjY-G4g for ; Tue, 26 Jul 2016 05:08:34 -0700 (PDT)
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 D7E8A12D73D for ; Tue, 26 Jul 2016 05:08:34 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8DAED284F26; Tue, 26 Jul 2016 12:08:33 +0000 (UTC)
Date: Tue, 26 Jul 2016 12:08:33 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20160726120833.GL4670@mournblade.imrryr.org>
References: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160726095225.7E1001A508@ld9781.wdf.sap.corp> <20160726100904.GA24234@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160726100904.GA24234@LK-Perkele-V2.elisa-laajakaista.fi>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jul 2016 12:08:36 -0000

On Tue, Jul 26, 2016 at 01:09:04PM +0300, Ilari Liusvaara wrote:

> > Failure:
> > openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
> 
> If you swap the order of these two ciphersuites, does it suceed or fail?
> 
> I.e.
> 
> openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

I can reproduce the reported failure in the original order, and at
least for me the swapped variant succeeds.

> Well, your test results certainly blow basic "negotiation accidentially
> blows off all valid candidates and then fails" hypothesis out of the
> water. So it has to be soemthing more complicated.
> 
> Succeeding with the ciphersuites swapped would suggest (as somebody
> else in this thread already said) that it only considers Chacha in
> the first place, not noticing that it may be the only choice after
> certificate selection.

Perhaps that's the issue.

-- 
	Viktor.


From nobody Tue Jul 26 07:21:49 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429C712DDE1 for ; Tue, 26 Jul 2016 07:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level: 
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z0ILNM6DtFw for ; Tue, 26 Jul 2016 07:21:23 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3B412DDE6 for ; Tue, 26 Jul 2016 07:01:18 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB4908B11B; Tue, 26 Jul 2016 14:01:17 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6QE1Fu9005714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 10:01:17 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Tue, 26 Jul 2016 16:01:15 +0200
Message-ID: <14000022.JQvKyvFqq9@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: <20160726120833.GL4670@mournblade.imrryr.org>
References: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160726100904.GA24234@LK-Perkele-V2.elisa-laajakaista.fi> <20160726120833.GL4670@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2730809.OUEuMdJQlU"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 26 Jul 2016 14:01:18 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 14:21:36 -0000

--nextPart2730809.OUEuMdJQlU
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Tuesday, 26 July 2016 12:08:33 CEST Viktor Dukhovni wrote:
> On Tue, Jul 26, 2016 at 01:09:04PM +0300, Ilari Liusvaara wrote:
> > > Failure:
> > > openssl s_client -connect regmedia.co.uk:443 -cipher
> > > ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305>=20
> > If you swap the order of these two ciphersuites, does it suceed or fail?
> >=20
> > I.e.
> >=20
> > openssl s_client -connect regmedia.co.uk:443 -cipher
> > ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
> I can reproduce the reported failure in the original order, and at
> least for me the swapped variant succeeds.
>=20
> > Well, your test results certainly blow basic "negotiation accidentially
> > blows off all valid candidates and then fails" hypothesis out of the
> > water. So it has to be soemthing more complicated.
> >=20
> > Succeeding with the ciphersuites swapped would suggest (as somebody
> > else in this thread already said) that it only considers Chacha in
> > the first place, not noticing that it may be the only choice after
> > certificate selection.
>=20
> Perhaps that's the issue.

if you send the AES-GCM then Chacha but do NOT include signature algorithms=
,=20
it allows you to connect (other extensions are irrelevant).

If you send AES-GCM then Chacha in ciphers but in signatures algorithms don=
't=20
include the SHA256/ecdsa pair, it works too.

in other words, this connects:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA512:RSA+SHA256

and this connects:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA512:RSA+SHA512

but this doesn't:
openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-
SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 -sigalgs ECDSA+SHA256:RSA+SHA256

(using openssl-1.1.0-pre5)
=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 Republic
--nextPart2730809.OUEuMdJQlU
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

iQIcBAABCgAGBQJXl20rAAoJEJKo0bgB0vX1r5MQAJ0X4TkuURWkgSV8TVpHVXWa
YiP3PMK+zuqMv0t8GZ0kIlORotJ99RpoMf9uVbvadPVzFExoE8GElOXIkz3d451W
lGvWcgK/nyO0KV1ggFtvYgmTY/LCIR+RkHSo9HFU/FvSV16yW3cI9CbngpPLAsQ0
kc227ww51Sj7LIYQdc9LxOJoI71yxk3OtSPqp5LwEi7k0GvBrBaMLO05MPqHTUH3
q+odowNkdSl2fL8zE0//6JF6NZJFJKdzZCThOCGF6q/fR3eNUlzQbKwj8PXptMT6
RjsKt2RO/uZungwBoT2wZ20K2f3KVQVPFddLmyvjz21soxVm6dHxkxvosAg04I/8
4/PSFwXuOpr/sjwDHSqFQ86mJAyMHZ7NfvMAKkyrWI/JUX2hd1+4VpImE8DWQXe4
HIn/ogi/Sedu2lVOipWugGBrnOTSnk253k+wklJzKuvG6MOPFDr4jfIcxXtLXc0y
06XumX9MB/b/Yb7uSCx2brMpuSnCVki2C9AlhE6Fc4G8kZyqUuj0aEmkz3X0Vj7k
r1khqlzhb0dxmMjL9/9kL+7E27xjCAx3toqGzcmZxVurLkRevDVIJKMwe/EIoWps
Vufs0xwTP3Tjsw9JgqTyrAw8n6F5XnffhhMiZPhbfYRRSYzqIzupyhWOTHdxDduq
fFB3v4cpHQPpV+VS9xyQ
=ZzBw
-----END PGP SIGNATURE-----

--nextPart2730809.OUEuMdJQlU--


From nobody Tue Jul 26 07:35:57 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D439212DEBB for ; Tue, 26 Jul 2016 07:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q51zX1LYY-2L for ; Tue, 26 Jul 2016 07:35:51 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F212DB5F for ; Tue, 26 Jul 2016 07:09:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 0C05D53D1 for ; Tue, 26 Jul 2016 17:09:12 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id a5p6E6VXX3K9 for ; Tue, 26 Jul 2016 17:09:11 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 776102313 for ; Tue, 26 Jul 2016 17:09:11 +0300 (EEST)
Date: Tue, 26 Jul 2016 17:09:06 +0300
From: Ilari Liusvaara 
To: tls@ietf.org
Message-ID: <20160726140906.GB24563@LK-Perkele-V2.elisa-laajakaista.fi>
References: <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160726095225.7E1001A508@ld9781.wdf.sap.corp> <20160726100904.GA24234@LK-Perkele-V2.elisa-laajakaista.fi> <20160726120833.GL4670@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20160726120833.GL4670@mournblade.imrryr.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 14:35:56 -0000

On Tue, Jul 26, 2016 at 12:08:33PM +0000, Viktor Dukhovni wrote:
> On Tue, Jul 26, 2016 at 01:09:04PM +0300, Ilari Liusvaara wrote:
> 
> > > Failure:
> > > openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
> > 
> > If you swap the order of these two ciphersuites, does it suceed or fail?
> > 
> > I.e.
> > 
> > openssl s_client -connect regmedia.co.uk:443 -cipher ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
> 
> I can reproduce the reported failure in the original order, and at
> least for me the swapped variant succeeds.

Thank you.
 
> > Well, your test results certainly blow basic "negotiation accidentially
> > blows off all valid candidates and then fails" hypothesis out of the
> > water. So it has to be soemthing more complicated.
> > 
> > Succeeding with the ciphersuites swapped would suggest (as somebody
> > else in this thread already said) that it only considers Chacha in
> > the first place, not noticing that it may be the only choice after
> > certificate selection.
> 
> Perhaps that's the issue.

Oops, that should have been:

Chacha ciphersuites are considered for certificate selection in any
position, but only in first position for protection selection.


-Ilari


From nobody Tue Jul 26 08:26:33 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A0912DD7F for ; Tue, 26 Jul 2016 08:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIW8AlElodwr for ; Tue, 26 Jul 2016 08:26:17 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D76F12DAD3 for ; Tue, 26 Jul 2016 07:52:49 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id w38so8419696qtb.0 for ; Tue, 26 Jul 2016 07:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yUMj+K/3nhFWQA6/9zd/aI7+52d2Mds5vftkjMtb+RU=; b=LtyOa+L3EHg6UxiT8KhahlubTUrmRL2t1YRFQAciv8Mu+Q9f/FLEx3VPmp4/UZnG3d LMYhsdA6MXP67KpC/+j7yaPJXRYeQX0aIiXf0CTtj8RAl9kRrVWQNghFdoZPUzg6P6+R rzkR2U7GJ0idobHEqWyzyUyDAiwW6s9EiYFic=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yUMj+K/3nhFWQA6/9zd/aI7+52d2Mds5vftkjMtb+RU=; b=JERqCyULYSkuN0kYXjicguMe0gPihBziKnlA/7lRB9IG6LKYvzrx0KAQOcAqfl3zN2 Kqcu2Q/UCnNcJiavc6e0zDjQMak4+BomOHIVlTHtO4f33hKE01Arzi1viPhiEJ5szq/D 0OAAN4dQBZncU5Xgp5A7FkxO5VdfNZdtE+jp9TuTKf/YrkzCWLeIW8zlRSamEhrVH74g NLD4c5VUuCHZ/NjcQ6aGgTJ74cpOM2h705cQg9gOlD0JgD1m8MDA6obsNx+tZ3/JXriV h1cnYvf7EVI5pgBnMh7r2EGGAsEMIRc9oU+y/gg9I+7+BXsCgJ7CzvlwI/s9FDI/AkgA lVig==
X-Gm-Message-State: AEkoouuN3ZiCdNq0HDtEZN7tlsEvJFah+1Eg8h/2lUizWRSpibklD8HcECjC1S3YlCB+lg==
X-Received: by 10.237.37.99 with SMTP id w32mr38312558qtc.59.1469544768242; Tue, 26 Jul 2016 07:52:48 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.220.41]) by smtp.gmail.com with ESMTPSA id c23sm747747qtc.45.2016.07.26.07.52.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jul 2016 07:52:47 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Tue, 26 Jul 2016 10:52:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>
References: 
To: David Benjamin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 15:26:32 -0000

David,

Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to =
make via the IANA considerations section.  They enforce the registry =
policy established when we (the IETF/TLS WG) originally established the =
registry; the available policies are found in RFC 5226 (and there=E2=80=99=
s some more rules in RFC 7120).  So, I=E2=80=99m hoping that you could =
tweak your draft somewhat to be instructional and then suggest some =
values (this purely procedural dance has worked in the past and it=E2=80=99=
s what we=E2=80=99re doing for draft-ietf-tls-ecdhe-psk-aead):

0) In s2, replace the two lists with something like:

The draft reservers the following X cipher suite values: Values TBD

The following X values are reserved as both GREASE extension values and =
GREASE named group values: Values TBD

1) In 5, add a {TBD} sub-column to the 1st column for each value in the =
tables (apologies for the formatting):

+-------------------------+-------------+---------+-----------------+
|    Value                   | Description | DTLS-OK |    Reference    |
+-------------------------+-------------+---------+-----------------+
| {TBD} {0x0A,0x0A} |   Reserved  |    Y    | (this document) |

And then add something like this to the end of the section:

  The cipher suite numbers listed in the second column in the
  values column are numbers used for cipher suite interoperability
  testing and it's suggested that IANA use these values for assignment.


I=E2=80=99m sure somebody will eventually comment on the following =
header fields:

0) =E2=80=9CStatus: Informational=E2=80=9D because some of the =
registries right now require standards track RFCs to do the assignments. =
 But, everybody should momentarily suspend reality because we=E2=80=99re =
going to change the registry rules for the registries you are adding =
values you to be something that would allow an draft intended for =
=E2=80=9Cinformational=E2=80=9D to do the updates, i.e., just leave it =
alone for now.

1) =E2=80=9CUpdates: 5246 (if approved)=E2=80=9D because typically =
extension documents don=E2=80=99t =E2=80=9Cupdate=E2=80=9D the base =
specification.  If you are suggesting that all implementations must =
support these values then an updates header makes sense.  Note I=E2=80=99m=
 sure somewhere along the way an extension that isn=E2=80=99t expected =
to be supported by all implementation has an updates header but what I =
described is how we=E2=80=99re doing it now.

Cheers,

spt

PS: As chair, I try to deal with/deflect as many of these procedural =
issues as possible, but if you want to know more please let me know =
off-list.  This actually goes for anybody on the list.

> On Jul 25, 2016, at 18:32, David Benjamin  =
wrote:
>=20
> Hi folks,
>=20
> I'm not sure how this process usually works, but I would like to =
reserve a bunch of values in the TLS registries to as part of an idea to =
keep our extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft-davidben-tls-grease-00
>=20
> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints =
analogy from https://www.imperialviolet.org/2016/05/16/agility.html )
>=20
> One problem we repeatedly run into is servers failing to implement =
TLS's various extension points correctly. The most obvious being version =
intolerance. When we deployed X25519 in Chrome, we discovered an =
intolerant implementation. (Thankfully it was rare enough to not warrant =
a fallback or revert!) It appears that signature algorithms maybe also =
be gathering rust. Ciphers and extensions seem to have held up, but I =
would like to ensure they stay that way.
>=20
> The root problem here is these broken servers interoperate fine with =
clients at the time they are deployed. It is only after new values get =
defined do we notice, by which time it is too late.
>=20
> I would like to fix this by reserving a few values in our registries =
so that clients may advertise random ones and regularly exercise these =
codepaths in servers. If enough of the client base does this, we can =
turn a large class of tomorrow's interop failures into today's interop =
failures. This is important because an bug will not thrive in the =
ecosystem if it does not work against the current deployment.
>=20
> If you were in Berlin, you may recognize this idea from the version =
negotiation debate. Alas that all happened in the wrong order as I =
hadn't written this up yet. This idea can't be applied to versioning =
without giving up on ClientHello.version, but we can start with the rest =
of the protocol.
>=20
> David
>=20
> PS: This is actually my first I-D, so apologies if I've messed it up =
somewhere!
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jul 26 08:43:43 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251012D8DA for ; Tue, 26 Jul 2016 08:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdF-7mQQetX1 for ; Tue, 26 Jul 2016 08:43:39 -0700 (PDT)
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 C1B9712D88A for ; Tue, 26 Jul 2016 08:11:51 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id f93so7412229lfi.2 for ; Tue, 26 Jul 2016 08:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OmAX46XCT6Ajfhi2Vs2pY4An7BpOI3aEnms32NKpCp4=; b=XmMKRPdJcCg6XOWz5tChKCWxp0Az9mW0vX/a3Qnu/MbP20vZcpao+i6w55CF4vuy9d lMDEsH//URnpAaMRNkPyAaJN5ArumbMgIAGy6tnvm1jbe5z7OFIC8yfBZt42twSlnETh B6tFmD+jFWP+vXXPS0Vfx0YwHyZUiF/9f+g8U=
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; bh=OmAX46XCT6Ajfhi2Vs2pY4An7BpOI3aEnms32NKpCp4=; b=TJPr3pv1jycuxE1Wk5wymxAQM8euYGx5eQdrVLO1xnn+U/rVrUQ7SXIUu5KbHShATI VjGLa8XNJHzas1w0uGUJ9DCww5CHbIPrRae0DsKR5AjzOKkd/ZnaY7RTRfAuxxV/iiPE kEqnnxZF60NegcZOW3gcJUmZX4ZL0eIEsmg+hjZLAo6VgPqV74eeWKdkXftI9ZSNVh5+ phNadfKUVNrSEEskESW3zqP37WLbZNsiP62c7SaAmIztZxnB68vQcs2llZzR6tTEB0FO z+tB8g0+SiaKqxQgjaLJ922VWgwVIaGvPQlfaeIU3YvXoDb3P7hmjgESHdKoDOtZVmhd jyYA==
X-Gm-Message-State: AEkoousJ43w+/wTihwiIn/H7sGU/uCbtMFpsNXmCOd3JlpW8+q1wIZjLIeujdci1RlXk0YeZh69uQiFtzZC4fppT
X-Received: by 10.25.216.26 with SMTP id p26mr10100357lfg.122.1469545909716; Tue, 26 Jul 2016 08:11:49 -0700 (PDT)
MIME-Version: 1.0
References:  <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>
In-Reply-To: <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>
From: David Benjamin 
Date: Tue, 26 Jul 2016 15:11:40 +0000
Message-ID: 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=001a114024a4ee7ac505388b5194
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 15:43:42 -0000

--001a114024a4ee7ac505388b5194
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 26, 2016 at 10:52 AM Sean Turner  wrote:

> David,
>
> Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to
> make via the IANA considerations section.  They enforce the registry poli=
cy
> established when we (the IETF/TLS WG) originally established the registry=
;
> the available policies are found in RFC 5226 (and there=E2=80=99s some mo=
re rules
> in RFC 7120).  So, I=E2=80=99m hoping that you could tweak your draft som=
ewhat to
> be instructional and then suggest some values (this purely procedural dan=
ce
> has worked in the past and it=E2=80=99s what we=E2=80=99re doing for
> draft-ietf-tls-ecdhe-psk-aead):
>

Got it. Will switch things to TBD. Thanks!


> 0) In s2, replace the two lists with something like:
>
> The draft reservers the following X cipher suite values: Values TBD
>
> The following X values are reserved as both GREASE extension values and
> GREASE named group values: Values TBD
>
> 1) In 5, add a {TBD} sub-column to the 1st column for each value in the
> tables (apologies for the formatting):
>
> +-------------------------+-------------+---------+-----------------+
> |    Value                   | Description | DTLS-OK |    Reference    |
> +-------------------------+-------------+---------+-----------------+
> | {TBD} {0x0A,0x0A} |   Reserved  |    Y    | (this document) |
>
> And then add something like this to the end of the section:
>
>   The cipher suite numbers listed in the second column in the
>   values column are numbers used for cipher suite interoperability
>   testing and it's suggested that IANA use these values for assignment.
>
>
> I=E2=80=99m sure somebody will eventually comment on the following header=
 fields:
>
> 0) =E2=80=9CStatus: Informational=E2=80=9D because some of the registries=
 right now
> require standards track RFCs to do the assignments.  But, everybody shoul=
d
> momentarily suspend reality because we=E2=80=99re going to change the reg=
istry
> rules for the registries you are adding values you to be something that
> would allow an draft intended for =E2=80=9Cinformational=E2=80=9D to do t=
he updates, i.e.,
> just leave it alone for now.
>

Oh, this wasn't a conscious decision. I actually didn't even notice that
was a field to set. I just ended up with whatever defaults the template I
was using picked. Like I said, I'm new to this game. :-)

Pending registry rule change aside, is "Informational" correct for this
sort of thing or should I switch it?


> 1) =E2=80=9CUpdates: 5246 (if approved)=E2=80=9D because typically extens=
ion documents
> don=E2=80=99t =E2=80=9Cupdate=E2=80=9D the base specification.  If you ar=
e suggesting that all
> implementations must support these values then an updates header makes
> sense.  Note I=E2=80=99m sure somewhere along the way an extension that i=
sn=E2=80=99t
> expected to be supported by all implementation has an updates header but
> what I described is how we=E2=80=99re doing it now.
>

I wasn't sure and mimicked RFC 7507 and RFC 7685 which both did this.

I expect that all servers will "support" this specification in so far as it
says nothing useful for servers. TLS servers are supposed to ignore unknown
values. I would certainly like for as many clients to do it as possible so
the ecosystem effects work out, but I certainly don't intend for it to be
any kind of requirement. (I suppose the text says MAY so existing clients
also "support" it by default.)

Is it better to remove that line in this case? Happy to do whatever works.


> Cheers,
>
> spt
>
> PS: As chair, I try to deal with/deflect as many of these procedural
> issues as possible, but if you want to know more please let me know
> off-list.  This actually goes for anybody on the list.
>
>

> > On Jul 25, 2016, at 18:32, David Benjamin  wrote=
:
> >
> > Hi folks,
> >
> > I'm not sure how this process usually works, but I would like to reserv=
e
> a bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> >
> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints
> analogy from https://www.imperialviolet.org/2016/05/16/agility.html )
> >
> > One problem we repeatedly run into is servers failing to implement TLS'=
s
> various extension points correctly. The most obvious being version
> intolerance. When we deployed X25519 in Chrome, we discovered an intolera=
nt
> implementation. (Thankfully it was rare enough to not warrant a fallback =
or
> revert!) It appears that signature algorithms maybe also be gathering rus=
t.
> Ciphers and extensions seem to have held up, but I would like to ensure
> they stay that way.
> >
> > The root problem here is these broken servers interoperate fine with
> clients at the time they are deployed. It is only after new values get
> defined do we notice, by which time it is too late.
> >
> > I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn=
 a
> large class of tomorrow's interop failures into today's interop failures.
> This is important because an bug will not thrive in the ecosystem if it
> does not work against the current deployment.
> >
> > If you were in Berlin, you may recognize this idea from the version
> negotiation debate. Alas that all happened in the wrong order as I hadn't
> written this up yet. This idea can't be applied to versioning without
> giving up on ClientHello.version, but we can start with the rest of the
> protocol.
> >
> > David
> >
> > PS: This is actually my first I-D, so apologies if I've messed it up
> somewhere!
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114024a4ee7ac505388b5194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, Jul 26=
, 2016 at 10:52 AM Sean Turner <sean@sn3rd.com> wrote:
David,



Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to ma=
ke via the IANA considerations section.=C2=A0 They enforce the registry pol=
icy established when we (the IETF/TLS WG) originally established the regist=
ry; the available policies are found in RFC 5226 (and there=E2=80=99s some =
more rules in RFC 7120).=C2=A0 So, I=E2=80=99m hoping that you could tweak =
your draft somewhat to be instructional and then suggest some values (this =
purely procedural dance has worked in the past and it=E2=80=99s what we=E2=
=80=99re doing for draft-ietf-tls-ecdhe-psk-aead):
Got it. Will =
switch things to TBD. Thanks!
=C2=A0

0) In s2, replace the two lists with something like:



The draft reservers the following X cipher suite values: Values TBD



The following X values are reserved as both GREASE extension values and GRE=
ASE named group values: Values TBD



1) In 5, add a {TBD} sub-column to the 1st column for each value in the tab=
les (apologies for the formatting):



+-------------------------+-------------+---------+-----------------+

|=C2=A0 =C2=A0 Value=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0| Description | DTLS-OK |=C2=A0 =C2=A0 Reference=C2=A0 =C2=A0=
 |

+-------------------------+-------------+---------+-----------------+

| {TBD} {0x0A,0x0A} |=C2=A0 =C2=A0Reserved=C2=A0 |=C2=A0 =C2=A0 Y=C2=A0 =C2=
=A0 | (this document) |



And then add something like this to the end of the section:



=C2=A0 The cipher suite numbers listed in the second column in the

=C2=A0 values column are numbers used for cipher suite interoperability

=C2=A0 testing and it's suggested that IANA use these values for assign=
ment.





I=E2=80=99m sure somebody will eventually comment on the following header f=
ields:



0) =E2=80=9CStatus: Informational=E2=80=9D because some of the registries r=
ight now require standards track RFCs to do the assignments.=C2=A0 But, eve=
rybody should momentarily suspend reality because we=E2=80=99re going to ch=
ange the registry rules for the registries you are adding values you to be =
something that would allow an draft intended for =E2=80=9Cinformational=E2=
=80=9D to do the updates, i.e., just leave it alone for now.

Oh, this wasn't a conscious decision. I actually didn't even not=
ice that was a field to set. I just ended up with whatever defaults the tem=
plate I was using picked. Like I said, I'm new to this game. :-)
<=
div>
Pending registry rule change aside, is "Information=
al" correct for this sort of thing or should I switch it?
<=
/div>
=C2=A0

1) =E2=80=9CUpdates: 5246 (if approved)=E2=80=9D because typically extensio=
n documents don=E2=80=99t =E2=80=9Cupdate=E2=80=9D the base specification.=
=C2=A0 If you are suggesting that all implementations must support these va=
lues then an updates header makes sense.=C2=A0 Note I=E2=80=99m sure somewh=
ere along the way an extension that isn=E2=80=99t expected to be supported =
by all implementation has an updates header but what I described is how we=
=E2=80=99re doing it now.

I wasn't sure and mimicked R=
FC 7507 and RFC 7685 which both did this.

I expect=
 that all servers will "support" this specification in so far as =
it says nothing useful for servers. TLS servers are supposed to ignore unkn=
own values. I would certainly like for as many clients to do it as possible=
 so the ecosystem effects work out, but I certainly don't intend for it=
 to be any kind of requirement. (I suppose the text says MAY so existing cl=
ients also "support" it by default.)

Is =
it better to remove that line in this case? Happy to do whatever works.
=C2=A0
=


Cheers,



spt



PS: As chair, I try to deal with/deflect as many of these procedural issues=
 as possible, but if you want to know more please let me know off-list.=C2=
=A0 This actually goes for anybody on the list.


=C2=A0

> On Jul 25, 2016, at 18:32, David Benjamin <davidben@chromium.org> wrote:

>

> Hi folks,

>

> I'm not sure how this process usually works, but I would like to r=
eserve a bunch of values in the TLS registries to as part of an idea to kee=
p our extension points working. Here's an I-D:

> https://tools.ietf.org/html/draft-david=
ben-tls-grease-00

>

> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints=
 analogy from https://www.imperialviolet.org/2=
016/05/16/agility.html )

>

> One problem we repeatedly run into is servers failing to implement TLS=
's various extension points correctly. The most obvious being version i=
ntolerance. When we deployed X25519 in Chrome, we discovered an intolerant =
implementation. (Thankfully it was rare enough to not warrant a fallback or=
 revert!) It appears that signature algorithms maybe also be gathering rust=
. Ciphers and extensions seem to have held up, but I would like to ensure t=
hey stay that way.

>

> The root problem here is these broken servers interoperate fine with c=
lients at the time they are deployed. It is only after new values get defin=
ed do we notice, by which time it is too late.

>

> I would like to fix this by reserving a few values in our registries s=
o that clients may advertise random ones and regularly exercise these codep=
aths in servers. If enough of the client base does this, we can turn a larg=
e class of tomorrow's interop failures into today's interop failure=
s. This is important because an bug will not thrive in the ecosystem if it =
does not work against the current deployment.

>

> If you were in Berlin, you may recognize this idea from the version ne=
gotiation debate. Alas that all happened in the wrong order as I hadn't=
 written this up yet. This idea can't be applied to versioning without =
giving up on ClientHello.version, but we can start with the rest of the pro=
tocol.

>

> David

>

> PS: This is actually my first I-D, so apologies if I've messed it =
up somewhere!

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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






--001a114024a4ee7ac505388b5194--


From nobody Tue Jul 26 18:40:16 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCB012DAA5 for ; Tue, 26 Jul 2016 18:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.889
X-Spam-Level: 
X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNwjozoNRaFa for ; Tue, 26 Jul 2016 18:40:14 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D42B12DA9C for ; Tue, 26 Jul 2016 18:40:14 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F056DB80362; Tue, 26 Jul 2016 18:40:13 -0700 (PDT)
To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160727014013.F056DB80362@rfc-editor.org>
Date: Tue, 26 Jul 2016 18:40:13 -0700 (PDT)
Archived-At: 
Cc: adrien@qbik.com, tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Editorial Errata Reported] RFC5246 (4750)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 01:40:15 -0000

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4750

--------------------------------------
Type: Editorial
Reported by: Adrien de Croy 

Section: 4.3 Vectors

Original Text
-------------
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).

Corrected Text
--------------
The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes
-----
Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements.  The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.

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. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Jul 26 19:33:16 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440BE12DD36 for ; Tue, 26 Jul 2016 19:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTUpYU7P-rZk for ; Tue, 26 Jul 2016 19:33:14 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F73912DCA8 for ; Tue, 26 Jul 2016 19:27:33 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id q83so57462094iod.1 for ; Tue, 26 Jul 2016 19:27:33 -0700 (PDT)
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:from:date:message-id:subject:to :cc; bh=1CU/9A05TvfILyIDgKDBOzq6v57QA5XE3V4O93d0vFo=; b=HIgj4mgendpM8am3fvP/0IAxsoC9QwpYyTcbN3VF3JSpXkjHSRoEng2ZKOc7z2kd7T ZtaKbHKTQwL51Kb1Igqwb2lCofRG+amadFWEImX8s3/pDbQ4ZsGpC9Reu7mOwdHJHhv9 ZlNoRhgLhWDERnDTYL8QiNbSYGHxxv6UrGXYd40T0VrG4s/icXFAfWZD5D89c4ilKcIm m6zdV5iL6EdffsfCMg/R08tB9sr4bmhokr4sVSPBx64V2LEldeIqntvzFrzTp/BUGwWW 5K8PGKrPxKxM5ygeopIb9r2XDmzmMO3MFQFNUeb4dZxd+C7LSSCtNGoM0mLV8bzyQhh1 6reQ==
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; bh=1CU/9A05TvfILyIDgKDBOzq6v57QA5XE3V4O93d0vFo=; b=Uc0pOSgM7shhuB5rNkKcTL3kBu7QFiiaqtAI252D8tY5fOxLSxZObzuBErVUNLrI1F WUwFJpCDKmIuTk0xH9wQxfPxH1j+fahx/3WAlXZIkhVWTZ5F1quHpS9BOhY5f+QskfAh W2WuujSjyvNlz6iethibzGasYcwR6F3sXmvbNRHzO/A3nIjeLc+aSBr+RWXOFD4Tr0SF mfHc+hkrslCfz7VB/szErMH/dCl5lfHOPxJq43QG5E6JzddbIgvwyEwB5wU0uDzsULBp dCgIk4GWc9RjvLfni3D/ayFkowkYwOTP7hqnxTr9jr9znFiVeI7/xEOUg/NIJEiZNaJe MimA==
X-Gm-Message-State: AEkoouvwqoZbvOabgcgqq4/YkpE5bpoLyuFnSSjbJFFxDojU7vLisLX6cNN8d9XBJi4kCL0Rm14qYMgEp8C3DA==
X-Received: by 10.107.9.231 with SMTP id 100mr30383500ioj.196.1469586453033; Tue, 26 Jul 2016 19:27:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.74.73 with HTTP; Tue, 26 Jul 2016 19:27:32 -0700 (PDT)
In-Reply-To: <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com>
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <201607211604.25745.davemgarrett@gmail.com> <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com> <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com>
From: Brian Smith 
Date: Tue, 26 Jul 2016 16:27:32 -1000
Message-ID: 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 02:33:15 -0000

Hubert Kario  wrote:
> 170 were detected as TLS 1.3 incompatible (3.9%)
> 183 were detected as TLS 1.4 incompatible (4.2%)
> 229 were detected as TLS 1.253 incompatible (5.22%)
>
> in the below excerpt (full list below, this is just entries that have at least
> 4 servers with same behaviour), "e/" means that it's the smallest size
> of "Very Compatible" client hello extended through the padding extension that
> causes its rejection by server, similarly "c/" indicates smallest size
> rejected by server when the client hello is made big through addition of
> cipher suite IDs

> Cumulative distribution function for size intolerancies looks like this:
>
> size  size  size  size  size  size >=c/8192                            4064      92.5529

This seems like a good indication that clients should limit the number
of cipher suites in the client hello.

>
> size  size  size  TLS 1.3                                  170       3.8742
> TLS 1.4                                  183       4.1705

> size e/1356                              10        0.2279
> size e/1356 c/1356                       5         0.1139
> size e/1356 c/1357                       5         0.1139
> size e/2046                              1         0.0228
> size e/2046 c/1979                       1         0.0228
> size e/2049                              4         0.0912
> size e/2049 c/1153                       1         0.0228
> size e/2049 c/2049                       2         0.0456
> size e/2049 c/2050                       1         0.0228
> size e/2053                              1         0.0228
> size e/2053 c/555                        1         0.0228

When we consider the most reasonable (initial) ClientHello sizes, it
seems that the ClientHello version number intolerance is a much more
significant problem than size intolerance, if I'm understanding your
numbers correctly.

Cheers,
Brian
-- 
https://briansmith.org/


From nobody Wed Jul 27 03:11:07 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDC412DE58 for ; Wed, 27 Jul 2016 03:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level: 
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TOD3w4ZPrp5 for ; Wed, 27 Jul 2016 03:11:05 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5764112DE57 for ; Wed, 27 Jul 2016 03:11:05 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 093DF61E46; Wed, 27 Jul 2016 10:11:05 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6RAB3in015344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2016 06:11:04 -0400
From: Hubert Kario 
To: Brian Smith 
Date: Wed, 27 Jul 2016 12:10:58 +0200
Message-ID: <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: 
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1707201.2DXUWuQ52S"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 27 Jul 2016 10:11:05 +0000 (UTC)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 10:11:06 -0000

--nextPart1707201.2DXUWuQ52S
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Tuesday, 26 July 2016 16:27:32 CEST Brian Smith wrote:
> Hubert Kario  wrote:
> > TLS 1.3                                  170       3.8742
> > TLS 1.4                                  183       4.1705
> >=20
> > size e/1356                              10        0.2279
> > size e/1356 c/1356                       5         0.1139
> > size e/1356 c/1357                       5         0.1139
> > size e/2046                              1         0.0228
> > size e/2046 c/1979                       1         0.0228
> > size e/2049                              4         0.0912
> > size e/2049 c/1153                       1         0.0228
> > size e/2049 c/2049                       2         0.0456
> > size e/2049 c/2050                       1         0.0228
> > size e/2053                              1         0.0228
> > size e/2053 c/555                        1         0.0228
>=20
> When we consider the most reasonable (initial) ClientHello sizes, it
> seems that the ClientHello version number intolerance is a much more
> significant problem than size intolerance, if I'm understanding your
> numbers correctly.

you've missed one more number:

> > Of those, 45 (1.03%) could not be connected to (did not receive a Serve=
r=20
> > Hello/.../Server Hello Done reply) with the "Very Compatible" client he=
llo

so while TLS1.3 intolerance it is a bigger problem, it's a bigger problem b=
y a=20
factor of two or three (depending what sizes you consider problematic), not=
 by=20
an order of magnitude

And given that the "best"[1] key share for post quantum crypto now is 1824=
=20
bytes in size, going above 2048 byte for client hello's on first connect is=
=20
not unreasonable. That is *if* rlwe with those parameters turns out to be g=
ood=20
enough and we won't need something even larger.

 1 - https://www.imperialviolet.org/2015/12/24/rlwe.html
=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 Republic
--nextPart1707201.2DXUWuQ52S
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

iQIcBAABCgAGBQJXmIiyAAoJEJKo0bgB0vX10MIP/2UPrKnFHOCNpG9LQXwx/OI+
4kv0U+aBpMMXQzz/vhBAg3uk95jwxCD4GEQFhH53QbuHHBwSq5A6+G/KXVy1lwIg
MuXfvh/l9MiyoXFqP4aDw6AhjeVenL1WWMt92pkvMnD3DKy4uQvSTF5T1xk9L3NS
Hzuot0gdzHZxoYw8Hl3o4369vxj/BP2/voKuRF+DnqNO3nzIiL5gZTyrQrdAlv3q
jCP2BGj7wz2O/ybasiVpOhx9Ie9HMK/Pztfmwg7IjhiX1RjtSWnnHhtUmhc/pV4O
7HbA8yNTe3pQ5IejHV1uDiaCsWVk6JgNoFtIdIj9fU3c9ED0OaQMAiAw6Kr25MFT
feeqgM2Y6FIubvia7PFZzInffJF7Mt57Gug5xiTSXGpY5ZebUQaRLyD47ikE1Ow8
XASVBnLqpU+pI5EjptRv3ov8HoLyJr3aLkmzFdmHPtgI+Fv4SrsRfdq66Nzm76SR
6tDx9R4BE/NDA4zMBrjIJ3QHK5MyHVLg9iiaxexOIxyXaf2CQR//UZXs6FeLFly+
6fry0YbwMYn5nhyRgvQwYDTtkDWMPG1YOquH8fxw+fdDEKWnpC8fhdEzslOyTj8a
sWvABzmqL/l6O0brWT2ftkeBmFFU19lNyoygsaEHivog7vOMD7o5JUnrEnK6c6Ob
mcsMx5cThx0K0jOudccJ
=Vmxl
-----END PGP SIGNATURE-----

--nextPart1707201.2DXUWuQ52S--


From nobody Wed Jul 27 05:48:45 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4660C12D753 for ; Wed, 27 Jul 2016 05:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF3tpJzLZTxN for ; Wed, 27 Jul 2016 05:48:40 -0700 (PDT)
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 B940E12D74F for ; Wed, 27 Jul 2016 05:48:39 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id l69so26562937lfg.1 for ; Wed, 27 Jul 2016 05:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0DR9UJKYv578o/hZlZWELlVaXZ1l/v0HQXMlc6iVVlo=; b=Yv4Rc2GVBtsXUUy1dwxHrbosv6L42LKyK2eYDK5kh4igppVjoYhZhUk+LlLJ0fAr9m H5b3vZhp4nY4AWTgomhWMgY+zgrBoZ2cMcctFzN0pmpCeJmsswKHV+8oQGeyDug/8DmL P9eC3wDaLJzop1PHdy6mdj2bl+wri1UoR6Ne4=
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; bh=0DR9UJKYv578o/hZlZWELlVaXZ1l/v0HQXMlc6iVVlo=; b=hD3SJFI9P0bB0WJnkq6JMtPLH17F/XYYM6IAtKzByRkwr+AYWiiC+wd0DRR8dJoUdK HVO7ewWv/98ND9Ah+frf1AFlVxGm33gEevrpZ7OgWxzuA+Ah2s0QGn9SPi+xR0/bdovf rqnaPncmbojO/92UhC5Jwwki+ptjrIXCZUUTLCPCYHF7nGmFeZiZP8QIBFnGnNoPwUKZ RxrRIxXzgAr3jdy7FOV2G2x55KN/YijayhBeV+5mBRIpSKtKzrroDTJkbdQiOttrn7+S xSViB39t5u10JJxzV57JiXaZEruQGUUb3ZvYM1K7M4JTCAh7kW6OOyoS4xVsFQ3iaRrK lr8Q==
X-Gm-Message-State: AEkoouty/6jGm8FdWlt/a5KToxn2CvwcrtUu+pyro4Fg0tsBW+L6xPdB/SSRDv0acJLMBDrUzUd0+aZQaDpfW+H/
X-Received: by 10.25.168.212 with SMTP id r203mr12960477lfe.85.1469623717784;  Wed, 27 Jul 2016 05:48:37 -0700 (PDT)
MIME-Version: 1.0
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com>  <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
In-Reply-To: <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
From: David Benjamin 
Date: Wed, 27 Jul 2016 12:48:28 +0000
Message-ID: 
To: Hubert Kario , Brian Smith 
Content-Type: multipart/alternative; boundary=001a114032a2a742f205389d6f60
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 12:48:43 -0000

--001a114032a2a742f205389d6f60
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 27, 2016 at 6:11 AM Hubert Kario  wrote:

> On Tuesday, 26 July 2016 16:27:32 CEST Brian Smith wrote:
> > Hubert Kario  wrote:
> > > TLS 1.3                                  170       3.8742
> > > TLS 1.4                                  183       4.1705
> > >
> > > size e/1356                              10        0.2279
> > > size e/1356 c/1356                       5         0.1139
> > > size e/1356 c/1357                       5         0.1139
> > > size e/2046                              1         0.0228
> > > size e/2046 c/1979                       1         0.0228
> > > size e/2049                              4         0.0912
> > > size e/2049 c/1153                       1         0.0228
> > > size e/2049 c/2049                       2         0.0456
> > > size e/2049 c/2050                       1         0.0228
> > > size e/2053                              1         0.0228
> > > size e/2053 c/555                        1         0.0228
> >
> > When we consider the most reasonable (initial) ClientHello sizes, it
> > seems that the ClientHello version number intolerance is a much more
> > significant problem than size intolerance, if I'm understanding your
> > numbers correctly.
>
> you've missed one more number:
>
> > > Of those, 45 (1.03%) could not be connected to (did not receive a
> Server
> > > Hello/.../Server Hello Done reply) with the "Very Compatible" client
> hello
>
> so while TLS1.3 intolerance it is a bigger problem, it's a bigger problem
> by a
> factor of two or three (depending what sizes you consider problematic),
> not by
> an order of magnitude
>
> And given that the "best"[1] key share for post quantum crypto now is 1824
> bytes in size, going above 2048 byte for client hello's on first connect is
> not unreasonable. That is *if* rlwe with those parameters turns out to be
> good
> enough and we won't need something even larger.
>
>  1 - https://www.imperialviolet.org/2015/12/24/rlwe.html


While we will indeed someday need to deal with that problem, it is still a
ways out. Even with no intolerance of any kind, I do not expect any
reasonable client to be willing to waste that much bandwidth on a key share
that the vast majority of servers will not use. (HelloRetryRequest exists,
so there is no need to predict all groups.)

Checking numbers from Chrome, the overwhelming majority of today's ECDHE[*]
servers select P-256, though one can expect X25519 to start coming up.
(Google servers select it today, and I believe OpenSSL 1.1.0 is expected to
as well. Probably others too.) With no prior knowledge, those two groups
seem by far the most reasonable to send in an initial ClientHello. For
reference, our in-progress TLS 1.3 implementation in Chrome does this with
a 517-byte ClientHello, of which 186 bytes are the padding to bring it up
to 5 + 512.

With prior knowledge, of course, many things are possible. Perhaps a client
will remember the group a server used last time (or use the
ServerHello.supported_groups extension) and, if we believe the server
prefers an unpredicted group, even if much much larger, predict that one.
With prior knowledge, endpoint intolerance is less of a concern.

I can imagine various unpleasant options should we need to balance
predicting a widely-used large key share with intolerance, but by then any
plans we make now will no longer be valid anyway.

David

[*] Negotiated FFDHE exists in TLS 1.3 and server-fiat DHE in TLS 1.2, but
this irrelevant as those two are totally different animals anyway. All they
have in common is the last three letters.

--001a114032a2a742f205389d6f60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Jul 27=
, 2016 at 6:11 AM Hubert Kario <hka=
rio@redhat.com> wrote:
On Tu=
esday, 26 July 2016 16:27:32 CEST Brian Smith wrote:

> Hubert Kario <hkario@redhat.com> wrote:

> > TLS 1.3=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 =C2=A0 170=C2=A0 =
=C2=A0 =C2=A0 =C2=A03.8742

> > TLS 1.4=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 =C2=A0 183=C2=A0 =
=C2=A0 =C2=A0 =C2=A04.1705

> >

> > size e/1356=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 10=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 0.2279

> > size e/1356 c/1356=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
1139

> > size e/1356 c/1357=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
1139

> > size e/2046=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 1=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00.0228

> > size e/2046 c/1979=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
0228

> > size e/2049=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 4=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00.0912

> > size e/2049 c/1153=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
0228

> > size e/2049 c/2049=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
0456

> > size e/2049 c/2050=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.=
0228

> > size e/2053=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 1=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00.0228

> > size e/2053 c/555=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.02=
28

>

> When we consider the most reasonable (initial) ClientHello sizes, it
> seems that the ClientHello version number intolerance is a much more
> significant problem than size intolerance, if I'm understanding yo=
ur

> numbers correctly.



you've missed one more number:



> > Of those, 45 (1.03%) could not be connected to (did not receive a=
 Server

> > Hello/.../Server Hello Done reply) with the "Very Compatible=
" client hello



so while TLS1.3 intolerance it is a bigger problem, it's a bigger probl=
em by a

factor of two or three (depending what sizes you consider problematic), not=
 by

an order of magnitude



And given that the "best"[1] key share for post quantum crypto no=
w is 1824

bytes in size, going above 2048 byte for client hello's on first connec=
t is

not unreasonable. That is *if* rlwe with those parameters turns out to be g=
ood

enough and we won't need something even larger.



=C2=A01 - https://www.imperialviolet.org/2015/12/=
24/rlwe.html

While we will indeed somed=
ay need to deal with that problem, it is still a ways out. Even with no int=
olerance of any kind, I do not expect any reasonable client to be willing t=
o waste that much bandwidth on a key share that the vast majority of server=
s will not use. (HelloRetryRequest exists, so there is no need to predict a=
ll groups.)

C=
hecking numbers from Chrome, the overwhelming majority of today's ECDHE=
[*] servers select P-256, though one can expect X25519 to start coming up. =
(Google servers select it today, and I believe OpenSSL 1.1.0 is expected to=
 as well. Probably others too.) With no prior knowledge, those two groups s=
eem by far the most reasonable to send in an initial ClientHello. For reference, our in-progress TLS 1.3 implem=
entation in Chrome does this with a 517-byte ClientHello, of which 186 byte=
s are the padding to bring it up to 5 + 512.

With prior knowledge, of course, many things are possible. Perhaps =
a client will remember the group a server used last time (or use the Server=
Hello.supported_groups extension) and, if we believe the server prefers an =
unpredicted group, even if much much larger, predict that one. With prior k=
nowledge, endpoint intolerance is less of a concern.

I can imagine various unpleasant options should we need to balance predi=
cting a widely-used large key share with intolerance, but by then any plans=
 we make now will no longer be valid anyway.

David=


[*] Negotiated FFDHE exists in TLS 1.3 and server=
-fiat DHE in TLS 1.2, but this irrelevant as those two are totally differen=
t animals anyway. All they have in common is the last three letters.
<=
/div>


--001a114032a2a742f205389d6f60--


From nobody Wed Jul 27 09:50:25 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693412B04E for ; Wed, 27 Jul 2016 09:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.988
X-Spam-Level: 
X-Spam-Status: No, score=-3.988 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZyvAlnAMxG1 for ; Wed, 27 Jul 2016 09:50:23 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360BB12B03D for ; Wed, 27 Jul 2016 09:50:23 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id u134so62546633ywg.3 for ; Wed, 27 Jul 2016 09:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M00ZlNKi7qYwRSdZzudkVKviOSthbc2WNeZxCYyrOfw=; b=GtPCitqj+X2a7Xtcko1oJrXplnxy0wzg19+4lWxJ3wXhJWjyfg65y9eV1Qm8TORfv6 Q4Xu5nVg33TKCizCrcb3FNnNeqzEjg8u4JTlx79weWTO/+rhmAq+B8BDmUWsUyZHYpVW q5ArJ2PHjy24KWJpZGad/gDhKXAc+rlXtTu4UNbNaeI7512JSmPVcmpgIBgXSVksjbRE uQam0ufzKUdink0HEMumjSurDNLdRbALG7ouxbmIDrFRXwuK9+XXV1OtfibQZnxjuuFh 35A82GooLRm4UsiG/6xCE7ohQigtw0v97X3d0Y/9l+a4Jb4wwvuLUPvsQmhfOX3fvq51 WWBg==
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; bh=M00ZlNKi7qYwRSdZzudkVKviOSthbc2WNeZxCYyrOfw=; b=HZRucA67X2sInJ7TDoU7fMm0E0Ru0ikgvTZNAWC8uTlbvTlPTzgZ5BE0JjMfe+SkTB JzVx1qCJfNIsH+BvEERsxqZakB77R6oiWSAK8RNuEOw8w460gIlE+E4IvYCtO4nN6DHO XJdr2HpHA9A30mXAUpFfzayWNYolWB/QGIDzpdUkzTQnWU+1gtJn64zTU4MyndM0K36g E0LhimcjS2CiwADw40TXA0orjv+DWWzkUdukwapFpBf3fsvh+dMUmUX568sJTp9+eErL u6a4YmT5DgVKG9vD9ynEGifQmN2yulCBdsXdHRdS4pZOq2fvyawh6I/fVAdrz9njcTjA TEnQ==
X-Gm-Message-State: AEkooutdVAEu/+JbhxgIv/J0QDklxoEDAvjGl8R+v40q9LnM+kBtTgPWoNVxjKMU7Xarth34SpkLxGMLxPwX13pz
X-Received: by 10.129.93.197 with SMTP id r188mr26551110ywb.286.1469638222374;  Wed, 27 Jul 2016 09:50:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.219.78 with HTTP; Wed, 27 Jul 2016 09:50:18 -0700 (PDT)
In-Reply-To: 
References:  <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com> 
From: Wan-Teh Chang 
Date: Wed, 27 Jul 2016 09:50:18 -0700
Message-ID: 
To: David Benjamin 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 16:50:24 -0000

On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin  wrote:
> Hi folks,
>
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft-davidben-tls-grease-00
>
> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy
> from https://www.imperialviolet.org/2016/05/16/agility.html )
>
> One problem we repeatedly run into is servers failing to implement TLS's
> various extension points correctly. The most obvious being version
> intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
> implementation. (Thankfully it was rare enough to not warrant a fallback or
> revert!) It appears that signature algorithms maybe also be gathering rust.
> Ciphers and extensions seem to have held up, but I would like to ensure they
> stay that way.
>
> The root problem here is these broken servers interoperate fine with clients
> at the time they are deployed. It is only after new values get defined do we
> notice, by which time it is too late.
>
> I would like to fix this by reserving a few values in our registries so that
> clients may advertise random ones and regularly exercise these codepaths in
> servers. If enough of the client base does this, we can turn a large class
> of tomorrow's interop failures into today's interop failures. This is
> important because an bug will not thrive in the ecosystem if it does not
> work against the current deployment.

Hi David,

In general I like your idea. Thank you for writing up a proposal.

Another source of interop failures is the firewall devices that do
anomaly detection. Some of them will abort TLS handshakes if they see
unknown TLS protocol versions or extensions in ClientHello. (They all
seem to allow unknown cipher suite values.) I suspect they will treat
the GREASE cipher suite, extension, and named group values as "normal"
and continue to abort the handshake if they see truly new values. I
can only hope that these network security devices are updated
regularly.

Wan-Teh Chang


From nobody Wed Jul 27 12:41:11 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5BB12D8E6 for ; Wed, 27 Jul 2016 12:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdW3ILN-WUcJ for ; Wed, 27 Jul 2016 12:41:08 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D12C12D8D0 for ; Wed, 27 Jul 2016 12:41:08 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id p74so43957354qka.0 for ; Wed, 27 Jul 2016 12:41:07 -0700 (PDT)
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; bh=QcRjEGLxY0PWxJnZNBC4OS72m+a/LF/C1RtIaAmBwnU=; b=tKbD/l/VQDcpC0rKafiD+4mOSh1Qdfa3P9t7gKP7CNYqxSn9WJK8Qd17Y5Puc+I8G7 3ZrQSORQf2q2dpwRQYNKoiBu9wgLma1jFFtJ+40HHrE/LhgJwFCEWd2SKBL4aan/CaYP 8fXD1jcGeOXnwMgNTSaB7df+W2gmse4ieC/nk/notKZkcwhoIo+HirlgGqXzHzFqAT8+ PrVDp5QUY92QemGgYnCvcil9xhzYMwiGaOR0U29L0B2u58W/efi21mfdV7UK4aCkSBUm kBB0WYlGtFYJsOwsgAFJkHs6gbMFPQ4F38+DY3PKoLBSoqNX+A5H5ZUTlJNF8HbvjQAW pnXg==
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; bh=QcRjEGLxY0PWxJnZNBC4OS72m+a/LF/C1RtIaAmBwnU=; b=IGqkJvJG6TwecEVTKWR1SaphUX2ZUtlMHlGRMWhhkrz3fBdYqJTig75ebfQlscUwlN ChcgGSN1eOe8/qQvxkWKGf4G/G1QiHOp/2olk2dES5HX9Zxjt64HiAsIGAuxQ2k/Xgwf dK5c2twEWm7qpNhiH6C/iRHUu30xx2gpqPdJKoNL9YIG+GzOo3twyFsmTIoEqUxKC7Na 29JxgWiRC74UEA4IC2xpjVFkbTsBZeTDXo+8cfGZMCBIKDWYB0w4WSDMCbTiZYxY5UuB gr2gbXVyxHBkR4BrQj8IANRit3rfWDaYQM8jfWwhLNTnumsMydSxTUYU9epf2r8eveFm uGtQ==
X-Gm-Message-State: AEkoouu6PoAZ3dP6BsA6EQHn/MSQ+atXIUArubInh0UhIGiStSb7dASSe9p+lBnR5Fxhb2328lsufkYd87HXiA==
X-Received: by 10.55.16.222 with SMTP id 91mr5824180qkq.151.1469648467199; Wed, 27 Jul 2016 12:41:07 -0700 (PDT)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.200.36.199 with HTTP; Wed, 27 Jul 2016 12:41:06 -0700 (PDT)
In-Reply-To: 
References:  <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>  
From: Adam Langley 
Date: Wed, 27 Jul 2016 12:41:06 -0700
X-Google-Sender-Auth: mJGkfvuiNTWLgQb4UG0ChOSURmE
Message-ID: 
To: Wan-Teh Chang 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 19:41:10 -0000

On Wed, Jul 27, 2016 at 9:50 AM, Wan-Teh Chang  wrote:
> Another source of interop failures is the firewall devices that do
> anomaly detection. Some of them will abort TLS handshakes if they see
> unknown TLS protocol versions or extensions in ClientHello. (They all
> seem to allow unknown cipher suite values.) I suspect they will treat
> the GREASE cipher suite, extension, and named group values as "normal"
> and continue to abort the handshake if they see truly new values. I
> can only hope that these network security devices are updated
> regularly.

Sadly there's very little that we can do to address aggressively bad
devices. None the less, there are several instances of unintentional
bugs in implementations that have caused problems with new-feature
deployment that I believe could have been caught with this proposal.
As ever, bugs are much less costly when found earlier and I believe
that applies equally to the developer and the world as a whole.

I have mind the cases of extension intolerance that we've thankfully
mostly managed to drive out now (because new extensions have been
added for other reasons) and the bug that led to the padding extension
(RFC 7685).

On the other hand, we've seen what's happened to the version field,
which is moving too slowly to resist rusting.


Cheers

AGL

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


From nobody Wed Jul 27 13:02:09 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2E12D91B for ; Wed, 27 Jul 2016 13:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL4YNHQZHkTH for ; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DB912D8F9 for ; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id f6so59414800ith.0 for ; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOBfn/MZrP2/p8+dpKTeDjFfWThGQiR4OZzRD7mzTes=; b=jxxpUompRwY7sOAn8SsrzB64djaglqGS9cQZFPXU4ctmsAD86UWqqyhMRC5rUlJ+RR /thXEQAeFhRzPdqmUJTXzbQAH6lSxmG277T4SAdr6lzf3c/YyLjU4/hploGItRGoLUpV RF32TRSMy606Sx11Tqp6rvUIx1QoI105Rx9Bk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOBfn/MZrP2/p8+dpKTeDjFfWThGQiR4OZzRD7mzTes=; b=msJzuehXzMLyeLbfPeV8Il8T8CFkp8lhZZZjbnzRX8/u4o0+BLvUNDMU2bDAXPjsWs DF1UTVFgWgVH0Mk2JHMkNWPoDmFRlnl60FBQJsDtWvVJioEOa7MvB4XLj+yCPQtxZwE6 4Ks13dDannwF9un9ka1l04wHvenSj87vZxe6/kdcyIvOUmXr+juBXSzryKdEYspo+9x9 gukCPOrHq/aesZNc6+DqenMWovo2j1WWh6ICnzX7Fq0e3sxCEjJlwQ3KtUGWkuOMuOmF 9Hzzfzg5Jj/LHtOjEc1h5mWbCKiD/A60a1QBaXleJWKCrotsU5q09j+1SvtlW6RwFphz SrwA==
X-Gm-Message-State: AEkoouulSynUvWi38L/rEYEOyB0VmSbgL1XQ/5/i2OBy+sJ3OLJn8tESQUJZustJWEvuFg==
X-Received: by 10.36.33.208 with SMTP id e199mr36385343ita.41.1469649725558; Wed, 27 Jul 2016 13:02:05 -0700 (PDT)
Received: from [5.5.33.74] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id l195sm3461876itl.17.2016.07.27.13.02.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jul 2016 13:02:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Wed, 27 Jul 2016 16:02:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <67E72566-5389-4AD2-8965-4FF85F9F42FD@sn3rd.com>
References:  <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com> 
To: David Benjamin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 20:02:07 -0000

> On Jul 26, 2016, at 11:11, David Benjamin  =
wrote:
>=20
> 1) =E2=80=9CUpdates: 5246 (if approved)=E2=80=9D because typically =
extension documents don=E2=80=99t =E2=80=9Cupdate=E2=80=9D the base =
specification.  If you are suggesting that all implementations must =
support these values then an updates header makes sense.  Note I=E2=80=99m=
 sure somewhere along the way an extension that isn=E2=80=99t expected =
to be supported by all implementation has an updates header but what I =
described is how we=E2=80=99re doing it now.
>=20
> I wasn't sure and mimicked RFC 7507 and RFC 7685 which both did this.
>=20
> I expect that all servers will "support" this specification in so far =
as it says nothing useful for servers. TLS servers are supposed to =
ignore unknown values. I would certainly like for as many clients to do =
it as possible so the ecosystem effects work out, but I certainly don't =
intend for it to be any kind of requirement. (I suppose the text says =
MAY so existing clients also "support" it by default.)
>=20
> Is it better to remove that line in this case? Happy to do whatever =
works.

I=E2=80=99d probably lean towards removing it.

spt=


From nobody Thu Jul 28 03:29:06 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1392512DD98 for ; Thu, 28 Jul 2016 03:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level: 
X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuhohXN4RNea for ; Thu, 28 Jul 2016 03:29:02 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20F212DE84 for ; Thu, 28 Jul 2016 03:29:00 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C06B3919A0; Thu, 28 Jul 2016 10:29:00 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6SASwM0027314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2016 06:28:59 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 28 Jul 2016 12:28:52 +0200
Message-ID: <1484484.N0J803EhZs@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: 
References:   
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart25788663.7R4STH9poa"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 28 Jul 2016 10:29:00 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 10:29:05 -0000

--nextPart25788663.7R4STH9poa
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin =20
wrote:
> > Hi folks,
> >=20
> > I'm not sure how this process usually works, but I would like to reserv=
e a
> > bunch of values in the TLS registries to as part of an idea to keep our
> > extension points working. Here's an I-D:
> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> >=20
> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints anal=
ogy
> > from https://www.imperialviolet.org/2016/05/16/agility.html )
> >=20
> > One problem we repeatedly run into is servers failing to implement TLS's
> > various extension points correctly. The most obvious being version
> > intolerance. When we deployed X25519 in Chrome, we discovered an
> > intolerant
> > implementation. (Thankfully it was rare enough to not warrant a fallback
> > or
> > revert!) It appears that signature algorithms maybe also be gathering
> > rust.
> > Ciphers and extensions seem to have held up, but I would like to ensure
> > they stay that way.
> >=20
> > The root problem here is these broken servers interoperate fine with
> > clients at the time they are deployed. It is only after new values get
> > defined do we notice, by which time it is too late.
> >=20
> > I would like to fix this by reserving a few values in our registries so
> > that clients may advertise random ones and regularly exercise these
> > codepaths in servers. If enough of the client base does this, we can tu=
rn
> > a large class of tomorrow's interop failures into today's interop
> > failures. This is important because an bug will not thrive in the
> > ecosystem if it does not work against the current deployment.
>=20
> Hi David,
>=20
> In general I like your idea. Thank you for writing up a proposal.
>=20
> Another source of interop failures is the firewall devices that do
> anomaly detection. Some of them will abort TLS handshakes if they see
> unknown TLS protocol versions or extensions in ClientHello. (They all
> seem to allow unknown cipher suite values.) I suspect they will treat
> the GREASE cipher suite, extension, and named group values as "normal"
> and continue to abort the handshake if they see truly new values. I
> can only hope that these network security devices are updated
> regularly.

how about adding a section that explicitly says what they are allowed to do=
,=20
and what they should not do?

i.e. it is acceptable for them to reject messages that are malformed (data =
in=20
client hello past extensions field, odd sizes for arrays that contain just=
=20
double-byte values, etc.) but not "undefined" extensions or "undefined" val=
ues=20
in them

in other words, how they can still provide added value without breaking TLS=
 in=20
the future
=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 Republic
--nextPart25788663.7R4STH9poa
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

iQIcBAABCgAGBQJXmd5kAAoJEJKo0bgB0vX1xj8P/2DhiXTiqZQgBcTOl1DVFIhw
uMh/IZvm49PpWA1XjRb/7ajFLLpufvOZIOKInYPMQtdO/7uC7Q4JNFn93Mx+Iees
7MfBJXurpwgYY6CwiImJwVijiOkuVcWB6BQ9xUEsL4aYUwMDq1blBt9V3XSoB9if
pDowlOPncucr+Hb7b5OC6s7kXMH59Dwo1AHAbBWsJzSc8brcqcjGrnRulMj5/tci
jUmD+oB0W7iSdArZaodQcZpOEVWeyyyG4U44D+qjNM+IrWF1aPFUpKzV7ufPXlVp
IhF3GxIzjzwhW5UHFt4OAFfZ5Jy63v9scvHqsFv+IVW0Z5URyDDbDDhIQTQdYxRN
aaSaWtJkzz8jv0vwVLACOgz7KVmxYOuAAmbACP2vE0Iv7n9JAo8NYJOs3SpnyHp7
ozCbB/hJ6uxWogfZpoPcTiSIg+XHkw5YsC0HK66Gx3nUb3QaxRS38Wm9FKYJPSv5
ILwNnBe6H686eG3PVeExOYSZm/BPmEpA0POnL+K9vLN8aDINMYM1qgNyQ8NOjERQ
pmXmWbm6lzy/5E2H2XmLTeyUQ6H4Pdldz4XV8gZon34Boo2x910t2SZm1j0VQcBt
vZ3yV5TLVAkwwPcMj7rcDkVMwA7P27bAcm/0MqRF9dD8gG1Xms33P1hS3XaVWlzI
zMGoXFaNLWcXlR033Vez
=WK14
-----END PGP SIGNATURE-----

--nextPart25788663.7R4STH9poa--


From nobody Thu Jul 28 06:12:54 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97412D0F1 for ; Thu, 28 Jul 2016 06:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTtQpIVK34qT for ; Thu, 28 Jul 2016 06:12:50 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFB012DFD1 for ; Thu, 28 Jul 2016 06:12:50 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id x130so31579590vkc.0 for ; Thu, 28 Jul 2016 06:12:50 -0700 (PDT)
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-transfer-encoding; bh=JxN8xQ1b6frp3MMBHjBeRN3kMRbOOVbF+iHlPInl5a0=; b=AHH++iPZ5y3hq9DazoU/e1GohxrRFE0VQBYsBBttxoTOyrGvwNwmO+0CrMfqBTivSm Tlc+JIOzL5QtTMiqW2BNKgFKDx7uMjd6AAvIuB38YxFz/HbqB5uPAnUjypBettf9lhLr zWwGg9TBEe6M/noLwqNn50vDsgALWt4bmAsQVisKgMPoKtK9lj+791RBPMhjqOizyLQp KW3RehYj1mKQecIqJWm0EfH3ebojQ0wUneIieCY0yc5L/xEVsyUZON5LgCcm8cqI9GqJ 2WLS3nF+2KNqhrtKPoJBnvdL5M8bf8TfA+NOGSEIxjrfJe054834dy4yzKLt3g0/UqGX CSsA==
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-transfer-encoding; bh=JxN8xQ1b6frp3MMBHjBeRN3kMRbOOVbF+iHlPInl5a0=; b=boym4Fc9wbzIapKfUaEj3Jud0c7h7M+S7V3fgEpTK+vzxBLtgK8myr+PIAxICoZsJ9 tZoXa810zX3xE7r1CPxHM2mW4hhLxIUonkvERLSRObxd3Akz4A/JwH9qyCLJ+MFn/2Q2 0+rb3WfTGO4AeDl34PW5IoMWmQfY78L3yIB3YU0rsHWm4IbvbPku9BoQ8bnO/rQ8fWP7 yIqwUqotTyHrEwe00Hdazeenx0ScZmuk5Apnk+F0qFqqG57JFd8l9ldQSM3ynHzY0dsY 9ZdsCVG2hvl+tVd1ZcrVAqIYhRmi+ROABOfDoZX3KlgpbS5+lLnrlpmwBH6cVPevcTHP mIsw==
X-Gm-Message-State: AEkooutD64kqM+/UZn56zLRpRIum9haswt2ci50Y/47FQcLuekLJVedHKO2ShcxFoooK0LJ5FlrN8kXokbWXgQ==
X-Received: by 10.31.186.77 with SMTP id k74mr13791794vkf.26.1469711569190; Thu, 28 Jul 2016 06:12:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.39.194 with HTTP; Thu, 28 Jul 2016 06:12:48 -0700 (PDT)
In-Reply-To: <1484484.N0J803EhZs@pintsize.usersys.redhat.com>
References:    <1484484.N0J803EhZs@pintsize.usersys.redhat.com>
From: Watson Ladd 
Date: Thu, 28 Jul 2016 06:12:48 -0700
Message-ID: 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 13:12:53 -0000

On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario  wrote:
> On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
>> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin 
> wrote:
>> > Hi folks,
>> >
>> > I'm not sure how this process usually works, but I would like to reser=
ve a
>> > bunch of values in the TLS registries to as part of an idea to keep ou=
r
>> > extension points working. Here's an I-D:
>> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
>> >
>> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints ana=
logy
>> > from https://www.imperialviolet.org/2016/05/16/agility.html )
>> >
>> > One problem we repeatedly run into is servers failing to implement TLS=
's
>> > various extension points correctly. The most obvious being version
>> > intolerance. When we deployed X25519 in Chrome, we discovered an
>> > intolerant
>> > implementation. (Thankfully it was rare enough to not warrant a fallba=
ck
>> > or
>> > revert!) It appears that signature algorithms maybe also be gathering
>> > rust.
>> > Ciphers and extensions seem to have held up, but I would like to ensur=
e
>> > they stay that way.
>> >
>> > The root problem here is these broken servers interoperate fine with
>> > clients at the time they are deployed. It is only after new values get
>> > defined do we notice, by which time it is too late.
>> >
>> > I would like to fix this by reserving a few values in our registries s=
o
>> > that clients may advertise random ones and regularly exercise these
>> > codepaths in servers. If enough of the client base does this, we can t=
urn
>> > a large class of tomorrow's interop failures into today's interop
>> > failures. This is important because an bug will not thrive in the
>> > ecosystem if it does not work against the current deployment.
>>
>> Hi David,
>>
>> In general I like your idea. Thank you for writing up a proposal.
>>
>> Another source of interop failures is the firewall devices that do
>> anomaly detection. Some of them will abort TLS handshakes if they see
>> unknown TLS protocol versions or extensions in ClientHello. (They all
>> seem to allow unknown cipher suite values.) I suspect they will treat
>> the GREASE cipher suite, extension, and named group values as "normal"
>> and continue to abort the handshake if they see truly new values. I
>> can only hope that these network security devices are updated
>> regularly.
>
> how about adding a section that explicitly says what they are allowed to =
do,
> and what they should not do?
>
> i.e. it is acceptable for them to reject messages that are malformed (dat=
a in
> client hello past extensions field, odd sizes for arrays that contain jus=
t
> double-byte values, etc.) but not "undefined" extensions or "undefined" v=
alues
> in them

This is what parsing is for.

>
> in other words, how they can still provide added value without breaking T=
LS in
> the future

Maybe they can't, and you shouldn't buy those products.

> --
> 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
>
> _______________________________________________
> 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 Thu Jul 28 07:59:34 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832D212D5D2 for ; Thu, 28 Jul 2016 07:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP1Jt0ioqggk for ; Thu, 28 Jul 2016 07:59:31 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4012B042 for ; Thu, 28 Jul 2016 07:59:30 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CED64433447; Thu, 28 Jul 2016 14:59:29 +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 A934443340B; Thu, 28 Jul 2016 14:59:29 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469717969; bh=qX8GpZ5wmx0dODRSDS5EywBqdWigpKECNXv1JY+F9Vc=; l=5571; h=To:References:Cc:From:Date:In-Reply-To:From; b=fQYixfcfBdx69BK8E836c+AboxdcLo/0x/YExkxdXPIA2p640gR+EyR7u8yFux3Sf lI4eFP//diMshDZ/n+ObFXV0P7YVXcsO+UvCiEd9trwFaY6JUXrttDN/xRBnNzwyp2 6F3HdLLIynEQzbbFC0lXrph8TZ6IX8b8yRTRPy70=
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 1502E1FCD1;  Thu, 28 Jul 2016 14:59:29 +0000 (GMT)
To: RFC Errata System , tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net
References: <20160727014013.F056DB80362@rfc-editor.org>
From: Benjamin Kaduk 
Message-ID: 
Date: Thu, 28 Jul 2016 09:59:28 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160727014013.F056DB80362@rfc-editor.org>
Content-Type: multipart/alternative; boundary="------------0DF8510D72FA6A79C3DDF69A"
Archived-At: 
Cc: adrien@qbik.com, tls@ietf.org
Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (4750)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 14:59:33 -0000

This is a multi-part message in MIME format.
--------------0DF8510D72FA6A79C3DDF69A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Jeff Hodges came up with a slightly different proposed rewording at
https://www.ietf.org/mail-archive/web/tls/current/msg19092.html the last
time this came up, which apparently was just a mail on the list and not
an erratum submission.

-Ben

On 07/26/2016 08:40 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4750
>
> --------------------------------------
> Type: Editorial
> Reported by: Adrien de Croy 
>
> Section: 4.3 Vectors
>
> Original Text
> -------------
> 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).
>
> Corrected Text
> --------------
> The length of
>    an encoded vector must be a whole multiple of the length of a single
>    element (for example, a 17-byte vector of uint16 would be illegal).
>
> Notes
> -----
> Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements.  The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.
>
> 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. 
>
> --------------------------------------
> RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> --------------------------------------
> Title               : The Transport Layer Security (TLS) Protocol Version 1.2
> Publication Date    : August 2008
> Author(s)           : T. Dierks, E. Rescorla
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------0DF8510D72FA6A79C3DDF69A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jeff Hodges came up with a slightly different proposed rewording
      at

      https://www.ietf.org/mail-archive/web/tls/current/msg19092.html
      the last time this came up, which apparently was just a mail on
      the list and not an erratum submission.

      

      -Ben

    

    
On 07/26/2016 08:40 PM, RFC Errata
      System wrote:

    

    

      
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4750

--------------------------------------
Type: Editorial
Reported by: Adrien de Croy <adrien@qbik.com>

Section: 4.3 Vectors

Original Text
-------------
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).

Corrected Text
--------------
The length of
   an encoded vector must be a whole multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

Notes
-----
Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements.  The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.

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. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

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


    

    

  


--------------0DF8510D72FA6A79C3DDF69A--


From nobody Thu Jul 28 08:08:00 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59712D7FF for ; Thu, 28 Jul 2016 08:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level: 
X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y396SlLr5pf1 for ; Thu, 28 Jul 2016 08:07:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EEE12D647 for ; Thu, 28 Jul 2016 08:07:57 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5EC2685A06; Thu, 28 Jul 2016 14:59:53 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6SExpHN016446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2016 10:59:53 -0400
From: Hubert Kario 
To: Watson Ladd 
Date: Thu, 28 Jul 2016 16:59:41 +0200
Message-ID: <7502983.MiB8z2zUIC@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: 
References:  <1484484.N0J803EhZs@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3478932.FigcROExuq"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 28 Jul 2016 14:59:53 +0000 (UTC)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 15:07:59 -0000

--nextPart3478932.FigcROExuq
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario  wrote:
> > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> >> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin 
> >=20
> > wrote:
> >> > Hi folks,
> >> >=20
> >> > I'm not sure how this process usually works, but I would like to
> >> > reserve a
> >> > bunch of values in the TLS registries to as part of an idea to keep =
our
> >> > extension points working. Here's an I-D:
> >> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> >> >=20
> >> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints
> >> > analogy
> >> > from https://www.imperialviolet.org/2016/05/16/agility.html )
> >> >=20
> >> > One problem we repeatedly run into is servers failing to implement
> >> > TLS's
> >> > various extension points correctly. The most obvious being version
> >> > intolerance. When we deployed X25519 in Chrome, we discovered an
> >> > intolerant
> >> > implementation. (Thankfully it was rare enough to not warrant a
> >> > fallback
> >> > or
> >> > revert!) It appears that signature algorithms maybe also be gathering
> >> > rust.
> >> > Ciphers and extensions seem to have held up, but I would like to ens=
ure
> >> > they stay that way.
> >> >=20
> >> > The root problem here is these broken servers interoperate fine with
> >> > clients at the time they are deployed. It is only after new values g=
et
> >> > defined do we notice, by which time it is too late.
> >> >=20
> >> > I would like to fix this by reserving a few values in our registries=
 so
> >> > that clients may advertise random ones and regularly exercise these
> >> > codepaths in servers. If enough of the client base does this, we can
> >> > turn
> >> > a large class of tomorrow's interop failures into today's interop
> >> > failures. This is important because an bug will not thrive in the
> >> > ecosystem if it does not work against the current deployment.
> >>=20
> >> Hi David,
> >>=20
> >> In general I like your idea. Thank you for writing up a proposal.
> >>=20
> >> Another source of interop failures is the firewall devices that do
> >> anomaly detection. Some of them will abort TLS handshakes if they see
> >> unknown TLS protocol versions or extensions in ClientHello. (They all
> >> seem to allow unknown cipher suite values.) I suspect they will treat
> >> the GREASE cipher suite, extension, and named group values as "normal"
> >> and continue to abort the handshake if they see truly new values. I
> >> can only hope that these network security devices are updated
> >> regularly.
> >=20
> > how about adding a section that explicitly says what they are allowed to
> > do, and what they should not do?
> >=20
> > i.e. it is acceptable for them to reject messages that are malformed (d=
ata
> > in client hello past extensions field, odd sizes for arrays that contain
> > just double-byte values, etc.) but not "undefined" extensions or
> > "undefined" values in them
>=20
> This is what parsing is for.

yes, and bugs in parsing may very well be exploitable
=20
> > in other words, how they can still provide added value without breaking
> > TLS in the future
>=20
> Maybe they can't, and you shouldn't buy those products.

pragmatist would say that double checking is defence in depth

and whatever we think, doesn't change the fact that people do make them=20
because people do buy them, so at least we can tell them how they can play=
=20
nice

=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 Republic
--nextPart3478932.FigcROExuq
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

iQIcBAABCgAGBQJXmh3dAAoJEJKo0bgB0vX1xfQQAJRZ9o/OBXr2BUfZK3KjQPDg
j18o02TiHCpPt9jflzx7U+NAvYIdXXW2cNjMEzgFLEPWcrX/wuPwVilEXYKpsu40
hZqj92ILTwEQw9qI+3akBo+B3fg2ej5kkrmBzZDoCf2ls2oXTkyK3vGnRDk/+yxq
k+h6rCDWu6cjAPC0cYUXnmaiKDPCCE9RSLA/l/HwWacXVjrqxLfK/tGmUZFp7FYG
iRiLBbmf58l4H5c/DesMdq1mO7l/1F4GDaGHGCi8OvXkeo8j7MTqmhe59yXN/bbh
02ZJ86Qa89MiIb4uKAC9eyQhFWpkh6wJW3T3AHpKhXPgtjFlmeRQlJ6OiFH4QPp5
RXO+f/uZ+f0OsfKJ6aRRhLumeiRUEAjpOay+qLSXLR7J5URUASuKDU7VrdO0uqOs
uej1p9Pm/rtw28nPQ+yAnkmUCko15JTwmKl7NLtqtZUz5zYU2X5tCqCb++YQtAZ6
JEbEiqnfVnmzzytyE3oV2C1aP9wcOhjRZ253rfbPTFFF9LmB8hUxxv2nX4LzYvUz
YzKRHbu7BgJiELQwzuBE0PwfVVwjo44TWyPVJckH8JZcknb2DDZUg+AOojtB57qL
GSZ2iI9YoLX+c5EwS5lBJHIYzHDTlNh9v8eWYhaNUsBT4f2GT5D7y5Ia81a/ecoY
ilyeRm88tnlvE3i0yoZK
=iG+G
-----END PGP SIGNATURE-----

--nextPart3478932.FigcROExuq--


From nobody Thu Jul 28 11:01:43 2016
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889412DB1B for ; Thu, 28 Jul 2016 11:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQmOZupwSP82 for ; Thu, 28 Jul 2016 11:01:40 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F12512DB22 for ; Thu, 28 Jul 2016 11:01:40 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C307F33D23B; Thu, 28 Jul 2016 18:01:39 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Hubert Kario 
References:  <1484484.N0J803EhZs@pintsize.usersys.redhat.com>  <7502983.MiB8z2zUIC@pintsize.usersys.redhat.com>
From: Geoffrey Keating 
Date: 28 Jul 2016 11:01:39 -0700
In-Reply-To: <7502983.MiB8z2zUIC@pintsize.usersys.redhat.com>
Message-ID: 
Lines: 33
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: "tls@ietf.org" 
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list 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 Jul 2016 18:01:41 -0000

Hubert Kario  writes:

> On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> > On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario  wrote:
> > > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> > >> Another source of interop failures is the firewall devices that do
> > >> anomaly detection.
> > > 
> > > how about adding a section that explicitly says what they are allowed to
> > > do, and what they should not do?
> > 
> > This is what parsing is for.
> 
> yes, and bugs in parsing may very well be exploitable
>  
> > > in other words, how they can still provide added value without breaking
> > > TLS in the future
> > 
> > Maybe they can't, and you shouldn't buy those products.
> 
> pragmatist would say that double checking is defence in depth
> 
> and whatever we think, doesn't change the fact that people do make them 
> because people do buy them, so at least we can tell them how they can play 
> nice

I don't think 'playing nice' is the point of these devices; the
concept is that unusual is bad, and so should be blocked.  They don't
just block new or unknown features, but sometimes also known features
being used in unusual combinations.  I've seen these devices raise a
security alert because of a ciphersuite list which contained only
ciphersuites used by browsers, but not in the expected
combination/order---at least, that's what I think it was.