From nobody Mon May 2 13:43: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 D027212D518 for ; Mon, 2 May 2016 13:43:51 -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 NDUq6fpW972k for ; Mon, 2 May 2016 13:43:50 -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 1FF4612D1AD for ; Mon, 2 May 2016 13:43:50 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g133so266837232ywb.2 for ; Mon, 02 May 2016 13:43:50 -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=xv4vstSL0wiEbvFBIkCSTHoE9Kw/iyUD3vyPC0g6acQ=; b=UHHjeljOvMHNQdkif/MqHTPUFDp8/XBykpiA3RJi1XJCgRX+f9663DRh61yC5EoUkM 3rg6ZYiD0jmK5u7Ktj7IVqo3HkK8mba2LVsNqftMH0QXGQ/sRIVlBcxgDqNnwSyobbyw qlG6kuVn7xXUA282E2dEclm7VOyE3wTrI4qfiXYdQ7VV7ki696XR+yXqp9aYAd3HnQXW d24WL/aQsvAnMte/MMQTrf9/hUk1IEdbdQpX9QfvlqnoOXOyPT/mDEB9jZzHhwPO+NJp RksE6KG3omcJ/tsboZwGKiOPVtSZmL33AFNx15BMKRZskPEVENPH7bwf+bOOtX4LC9c1 bRbw== 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=xv4vstSL0wiEbvFBIkCSTHoE9Kw/iyUD3vyPC0g6acQ=; b=WEYuWjqsFjva1ZbOk05Y6p62wiZWBONQj0uwkdsnRqf2gPW90UlHaF+cUcbqHbJSpl iR7rcpsDsbsMTtrtv+XFGSPLEplDV/V4uc/ZtO8jZvFEjnojIL+PQgxvsEAAP/peHwfT JNp92vbYgzUm5DHzL41eHblhxkUwFX73AlHor3T/BHcvhWbJJE8fgWE6mWwSOR2NXk3Q A7YEZZ52f2IZEVAWkqtsPRAFxlQky8MUVE0P4w74UedJG9kdD1Xb/ZHtjcC3veA/C02X 0kVdrrVM0As9hzCAZqRhHGYBnaROoJQj8pWAVgcpuXVuhvBs2pemTxg1LrM3+wl07p92 3r2A== X-Gm-Message-State: AOPr4FU1LITB/xGJ6dWrt1edbxjxQJrJTtT7W18NMl2fgVSUB0ggdKmgCvUX3n1NpzT1HZV0a9kga0iqlXbx9Q== X-Received: by 10.129.51.140 with SMTP id z134mr19591958ywz.322.1462221829276; Mon, 02 May 2016 13:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 13:43:09 -0700 (PDT) From: Eric Rescorla Date: Mon, 2 May 2016 13:43:09 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140746eb7aca60531e20ca8 Archived-At: Subject: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 20:43:51 -0000 --001a1140746eb7aca60531e20ca8 Content-Type: text/plain; charset=UTF-8 PR: https://github.com/tlswg/tls13-spec/pull/448 Targe landing date: Wednesday In Buenos Aires we discussed moving CertificateStatus to part of the Certificate message. In offline conversations, it started to look like that wasn't optimal in part because it created an asymmetry wrt Signed Certificate Timestamps. Instead, I propose just carrying the response in the response extensions. I just created PR#443, which moves the CertificateStatus response to an extension in EncryptedExtensions. Comments welcome. -Ekr --001a1140746eb7aca60531e20ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date:= Wednesday

In Buenos Aires we discussed moving Certi= ficateStatus to part of the Certificate message. In offline conversations, = it started to look like that wasn't optimal in part because it created = an asymmetry wrt Signed Certificate Timestamps. Instead, I propose just car= rying the response in the response extensions.

I just cr= eated PR#443, which moves the CertificateStatus response to an extension in= EncryptedExtensions. Comments welcome.

-Ekr
=



--001a1140746eb7aca60531e20ca8-- From nobody Mon May 2 14:05: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 E605B12D63C for ; Mon, 2 May 2016 14:05:30 -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 kexo9Ob1sYpF for ; Mon, 2 May 2016 14:05:28 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::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 3E9B612D64C for ; Mon, 2 May 2016 14:05:28 -0700 (PDT) Received: from 137.71.202.84.customer.cdi.no ([84.202.71.137]:55951 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1axL1y-0001aY-Bz for tls@ietf.org; Mon, 02 May 2016 23:05:26 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Mon, 02 May 2016 23:04:59 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) Archived-At: Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:05:31 -0000 Hi, On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/448 > Targe landing date: Wednesday > > In Buenos Aires we discussed moving CertificateStatus to part of the > Certificate message. In offline conversations, it started to look like > that > wasn't optimal in part because it created an asymmetry wrt Signed > Certificate Timestamps. Instead, I propose just carrying the response in > the response extensions. > > I just created PR#443, which moves the CertificateStatus response to an > extension in EncryptedExtensions. Comments welcome. > > -Ekr Regarding Certificate Status, is it such a good idea to keep both the original extension and the newer status_request_v2 extension in TLS 1.3? The client may have to signal the original extension in order to be interoperable with older TLS implementations, but wouldn't it be best if TLS 1.3 mandated the v2 extension in the server response? -- Sincerely, Yngve N. Pettersen From nobody Mon May 2 14:12: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 A2E2E12D654 for ; Mon, 2 May 2016 14:12:11 -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 9wNT7jv-X6EI for ; Mon, 2 May 2016 14:12:10 -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 0510E12D64A for ; Mon, 2 May 2016 14:12:10 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o66so705796ywc.3 for ; Mon, 02 May 2016 14:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pr5DHPrV8Mja3viEuTQnhJNPAGa/t79jHXQzreMkgKY=; b=ouFj78m91XoLaxgnteLEgpxWX1O4VbF5nbrVqUullgARojZBKb+uXfmIPLi7xJUT23 EPu2fKF34gFmsXHLGrMOHbBuLmXOvDmjoE3QE+EmWHtgyIbUIr+c8MGyliM79yVvfwPN VuVDB/KMi36v2vpbXU9wAOheePjLDwPjYv1AGYB9f4W+jY2KoRFgPkcha7Svsj4gWICU 66IURgDiomulahyiomFwSsRjUEDZijNcDeRNmieS3LQ+/G4dNnp9Lq1gS8/2nK8an5gq Ys5TtQplWwZryxm6THJ/TTJh+7nQOKDAOOLtBWu2yjA7rayLcnuaWon1WgKeT2Gg1gnj O53w== 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=pr5DHPrV8Mja3viEuTQnhJNPAGa/t79jHXQzreMkgKY=; b=iJ1PxmgcXJe3pjqbVrChjw5RtVYtrFPzD2TLqlK4GkSf+U7hXg24VLDOZjlWD7zvoi NPLgzOCQfz1cT86JGoIPpiw3Ke6UhL+RWFWfjjCbBGMwB4F0AHYiupcjvO3etdtMSTUu z+XL1Hl6iCSfIxvxkwEY1dsN1S4k9GBGzDAI+q5AaonTLQN1+1rkOaCW7qKYidts1J4+ B1qm6ZEEDCZFXaDIiMHdkBvkIcBZzghBsJp3wnO13KjwPLWZFE2QsZXY+scnaonZ7y/I 3cmg7eHzZNTsKN2XibhzxRM0MqC2IXdeTOCDXbRmy6AO1Xqb4VzDTEEgemoUwSi4gv3o ZNjw== X-Gm-Message-State: AOPr4FUyY0oFzaXZrkmzEvGmYV/zEvWWc6F/hhuFjpNDhrw5iX+B8LIKfPDEx36KPvU9+hIPvkWoMTJFM5Ow2g== X-Received: by 10.13.222.1 with SMTP id h1mr23587608ywe.171.1462223529300; Mon, 02 May 2016 14:12:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 14:11:29 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 May 2016 14:11:29 -0700 Message-ID: To: "Yngve N. Pettersen" Content-Type: multipart/alternative; boundary=94eb2c07c4120c05470531e272d6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:12:11 -0000 --94eb2c07c4120c05470531e272d6 Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen wrote: > Hi, > > > On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/448 >> Targe landing date: Wednesday >> >> In Buenos Aires we discussed moving CertificateStatus to part of the >> Certificate message. In offline conversations, it started to look like >> that >> wasn't optimal in part because it created an asymmetry wrt Signed >> Certificate Timestamps. Instead, I propose just carrying the response in >> the response extensions. >> >> I just created PR#443, which moves the CertificateStatus response to an >> extension in EncryptedExtensions. Comments welcome. >> >> -Ekr >> > > Regarding Certificate Status, is it such a good idea to keep both the > original extension and the newer status_request_v2 extension in TLS 1.3? > The client may have to signal the original extension in order to be > interoperable with older TLS implementations, but wouldn't it be best if > TLS 1.3 mandated the v2 extension in the server response? I don't think it's a good idea to have the server responding with extensions that the client didn't offer. If we're going to prefer v2, I would rather forbid the v1 version in TLS 1.3 -Ekr > > -- > Sincerely, > Yngve N. Pettersen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c07c4120c05470531e272d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen &l= t;yngve@spec-work.= net> wrote:
Hi,


On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com> wrote:

PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date: Wednesday

In Buenos Aires we discussed moving CertificateStatus to part of the
Certificate message. In offline conversations, it started to look like that=
wasn't optimal in part because it created an asymmetry wrt Signed
Certificate Timestamps. Instead, I propose just carrying the response in the response extensions.

I just created PR#443, which moves the CertificateStatus response to an
extension in EncryptedExtensions. Comments welcome.

-Ekr

Regarding Certificate Status, is it such a good idea to keep both the origi= nal extension and the newer status_request_v2 extension in TLS 1.3? The cli= ent may have to signal the original extension in order to be interoperable = with older TLS implementations, but wouldn't it be best if TLS 1.3 mand= ated the v2 extension in the server response?

I don't think it's a good idea to have the server responding wit= h extensions
that the client didn't offer. If we're going= to prefer v2, I would rather forbid
the v1 version in TLS 1.3

-Ekr



--
Sincerely,
Yngve N. Pettersen

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

--94eb2c07c4120c05470531e272d6-- From nobody Mon May 2 14:31: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 ED8F012D643 for ; Mon, 2 May 2016 14:31:11 -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 NH-KWVEvMBKO for ; Mon, 2 May 2016 14:31:10 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::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 371D812D59D for ; Mon, 2 May 2016 14:31:10 -0700 (PDT) Received: from 137.71.202.84.customer.cdi.no ([84.202.71.137]:55979 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1axLQq-00072Q-Ij; Mon, 02 May 2016 23:31:08 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Eric Rescorla" References: Date: Mon, 02 May 2016 23:30:42 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:31:12 -0000 On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wrote: > On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen > wrote: > >> Hi, >> >> >> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote: >> >> PR: https://github.com/tlswg/tls13-spec/pull/448 >>> Targe landing date: Wednesday >>> >>> In Buenos Aires we discussed moving CertificateStatus to part of the >>> Certificate message. In offline conversations, it started to look like >>> that >>> wasn't optimal in part because it created an asymmetry wrt Signed >>> Certificate Timestamps. Instead, I propose just carrying the response >>> in >>> the response extensions. >>> >>> I just created PR#443, which moves the CertificateStatus response to an >>> extension in EncryptedExtensions. Comments welcome. >>> >>> -Ekr >>> >> >> Regarding Certificate Status, is it such a good idea to keep both the >> original extension and the newer status_request_v2 extension in TLS 1.3? >> The client may have to signal the original extension in order to be >> interoperable with older TLS implementations, but wouldn't it be best if >> TLS 1.3 mandated the v2 extension in the server response? > > > I don't think it's a good idea to have the server responding with > extensions > that the client didn't offer. If we're going to prefer v2, I would rather > forbid > the v1 version in TLS 1.3 I was thinking along the lines of saying that TLS 1.3 clients that support certificate status MUST send v2, MAY send v1 (to be interoperable with older servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 session) MUST respond with v2 and MUST NOT respond with v1. -- Sincerely, Yngve N. Pettersen From nobody Mon May 2 14:41: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 A350A12D528 for ; Mon, 2 May 2016 14:41: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 YZsHlcYThVIG for ; Mon, 2 May 2016 14:41:26 -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 9A59E12D126 for ; Mon, 2 May 2016 14:41:25 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j74so1368076ywg.1 for ; Mon, 02 May 2016 14:41:25 -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=ghazZhmOgETyr7yMgzXImNvTrX4SUTaPQorHBaMwaL0=; b=EouofcNYKIyxHq8jiUSpmyvPF+iM20e1mYHH5EYizVf8Ui0Z4F6vpGWdOsIxD0b0m/ /RjoYIKi9YRKTEZdjojf2G3ZeAZwx6SCbqhQvK+mdumPtDbIK3HjGCQnrRqd1LOGiFKJ fFREXRPq3vcIea1+kjD47UVoK24WTavkvk5Mtgz288BuIFc++t0gU3iPV6VLWn3DsAIF TEZKgCuiJ8tBOWphZKz+I1ht9WicVU0vdM4ngmsrns9iE8Wp86gOE7FgAw+PmnSVmXK8 ZAaXOrWF4RsN+UBfPXvH+mCxM0gGrevAIXzf/6YJKT25L7rONZ2E16MSqh8w8olcdbJS JS+w== 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=ghazZhmOgETyr7yMgzXImNvTrX4SUTaPQorHBaMwaL0=; b=I9WpTwgcpJKJBM3jyPhJHR0cafQsSBGvPm227/N2i690uu2xXlChsjU0tQ+DF6GYLC 8y5pCIxFIYD77O42jt0u95mgr97sVwBmkNpfihmiNLh4dUy0tv0B942GGBF2LFUtPeRe HVK0jzAJrXfkMYf3i+CIPXg9ZxfVc7uLqh5S9sSBPpaPhKNKb04r9vzPLmjHX4psINNZ JZwEzOyyzXfVDhnXOiJQGs3WEyH9nHMGun67ovNwOkHvyx+I/69MFXRX0ITu2/IqnGM8 FdNdC9ddHeRZRamadwC6lsUHWssVTLGa6kHBDEEVwzNl8ZpJfOqGZMEUJMNj3ADqeG11 3MVQ== X-Gm-Message-State: AOPr4FVinOZ7Z00bnlJXWCHwz72LuuF9KOBTWX7URc5APdjqvtO4xQh4CVWVz1E35iL8EQb2qti8gpaFX/f0Dg== X-Received: by 10.37.203.16 with SMTP id b16mr20798478ybg.130.1462225284934; Mon, 02 May 2016 14:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 14:40:45 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 May 2016 14:40:45 -0700 Message-ID: To: "Yngve N. Pettersen" Content-Type: multipart/alternative; boundary=94eb2c05c358b0da5f0531e2da74 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:41:28 -0000 --94eb2c05c358b0da5f0531e2da74 Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen wrote: > On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wrote: > > On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen >> wrote: >> >> Hi, >>> >>> >>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote: >>> >>> PR: https://github.com/tlswg/tls13-spec/pull/448 >>> >>>> Targe landing date: Wednesday >>>> >>>> In Buenos Aires we discussed moving CertificateStatus to part of the >>>> Certificate message. In offline conversations, it started to look like >>>> that >>>> wasn't optimal in part because it created an asymmetry wrt Signed >>>> Certificate Timestamps. Instead, I propose just carrying the response in >>>> the response extensions. >>>> >>>> I just created PR#443, which moves the CertificateStatus response to an >>>> extension in EncryptedExtensions. Comments welcome. >>>> >>>> -Ekr >>>> >>>> >>> Regarding Certificate Status, is it such a good idea to keep both the >>> original extension and the newer status_request_v2 extension in TLS 1.3? >>> The client may have to signal the original extension in order to be >>> interoperable with older TLS implementations, but wouldn't it be best if >>> TLS 1.3 mandated the v2 extension in the server response? >>> >> >> >> I don't think it's a good idea to have the server responding with >> extensions >> that the client didn't offer. If we're going to prefer v2, I would rather >> forbid >> the v1 version in TLS 1.3 >> > > I was thinking along the lines of saying that TLS 1.3 clients that support > certificate status MUST send v2, MAY send v1 (to be interoperable with > older servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 > session) MUST respond with v2 and MUST NOT respond with v1. Well, what if the client doesn't want the OCSP response? -Ekr > > -- > Sincerely, > Yngve N. Pettersen > --94eb2c05c358b0da5f0531e2da74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen &l= t;yngve@spec-work.= net> wrote:
On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla = <ekr@rtfm.com> = wrote:

On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <yngve@spec-work.net>
wrote:

Hi,


On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com> wrote:

PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date: Wednesday

In Buenos Aires we discussed moving CertificateStatus to part of the
Certificate message. In offline conversations, it started to look like
that
wasn't optimal in part because it created an asymmetry wrt Signed
Certificate Timestamps. Instead, I propose just carrying the response in the response extensions.

I just created PR#443, which moves the CertificateStatus response to an
extension in EncryptedExtensions. Comments welcome.

-Ekr


Regarding Certificate Status, is it such a good idea to keep both the
original extension and the newer status_request_v2 extension in TLS 1.3? The client may have to signal the original extension in order to be
interoperable with older TLS implementations, but wouldn't it be best i= f
TLS 1.3 mandated the v2 extension in the server response?


I don't think it's a good idea to have the server responding with e= xtensions
that the client didn't offer. If we're going to prefer v2, I would = rather
forbid
the v1 version in TLS 1.3

I was thinking along the lines of saying that TLS 1.3 clients that support = certificate status MUST send v2, MAY send v1 (to be interoperable with olde= r servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 ses= sion) MUST respond with v2 and MUST NOT respond with v1.
<= br>
Well, what if the client doesn't want the OCSP response?<= /div>

-Ekr



--
Sincerely,
Yngve N. Pettersen

--94eb2c05c358b0da5f0531e2da74-- From nobody Mon May 2 14:45: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 1164A12D523 for ; Mon, 2 May 2016 14:45:45 -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 mu29UHs1kY5O for ; Mon, 2 May 2016 14:45:43 -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 0878812D126 for ; Mon, 2 May 2016 14:45:43 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id b189so1748788vkh.2 for ; Mon, 02 May 2016 14:45:42 -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=lzWIZuUaARcC+MoWnfMll1P31tOGQpG80haHi5/SI0w=; b=Z1UwrMrPDD9kcepbT04Z4J/ACeynQwp6TJpO+f50W4scbymDNgJqiV47n802w+SfjW IZs36YcdkONt58MRNktnpLPVRIXqqjgvyMgYAdX7WVEtZasJijQkOrh+CXoXp4viXkbl qIzDr0skYVsCl3tCKj+gSyjXp/6DpdMo4PVFn9amIsf5xrxm7DT4MSdvBotuRBqlm+i6 YRowpaohbMyxtp6kAEdD4dlLwBFal1SNdqjLv5cSCpT7Z/pot/NhqKpR53lFClXL8bpf yF0jNG66pDf2yybVg3hXRb+SGlUgliR+XBMgHzh3oJaFnukZ/ltMTGxFVmbg9sp9bHDM sUCQ== 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=lzWIZuUaARcC+MoWnfMll1P31tOGQpG80haHi5/SI0w=; b=jq9nl7gwHHyMA/6fi83HFAI3sDMvIAdwoc+POGNsNZ/vkj8cBzgFAMUeOwKkuCJNf9 jqBgWHXSYsuNHUYtaDZVBiGpx/9FBFpM68kCkP3wo/8fhNV/xV/la7B6VwG+U7CwCVYk BVn5zJqxschtj7ObGx+nNyl/K85NMH40NCBH1gmzGVRQGSP4esWLSaDTSjOVMHVr9MUJ CDrKUt0GunufkNjn77srTIimnK3OWL2JJnPJZ2kKN1tpMpDJuFcrFmv95Jv1awK6Wn08 C97CC7YdOZ83w9d6zhH5PKYM10LKOErT5tYIsKXO2LxVk31ljz2SO49mpXYZ2A6+JGBw L4Qg== X-Gm-Message-State: AOPr4FXYjjPch4CTvS8y3TTQtK6GvI85xxPkH12RGEMJC7IQJ8wFv1hQ5vBP+7+qaOQvz+t6+Ck9w/SNxIJVAg== MIME-Version: 1.0 X-Received: by 10.31.92.193 with SMTP id q184mr821485vkb.31.1462225542060; Mon, 02 May 2016 14:45:42 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Mon, 2 May 2016 14:45:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 May 2016 14:45:41 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:45:45 -0000 On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla wrote: > > > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen > wrote: >> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wrote: >> >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen >>> wrote: >>> >>>> Hi, >>>> >>>> >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote: >>>> >>>> PR: https://github.com/tlswg/tls13-spec/pull/448 >>>>> >>>>> Targe landing date: Wednesday >>>>> >>>>> In Buenos Aires we discussed moving CertificateStatus to part of the >>>>> Certificate message. In offline conversations, it started to look like >>>>> that >>>>> wasn't optimal in part because it created an asymmetry wrt Signed >>>>> Certificate Timestamps. Instead, I propose just carrying the response >>>>> in >>>>> the response extensions. >>>>> >>>>> I just created PR#443, which moves the CertificateStatus response to an >>>>> extension in EncryptedExtensions. Comments welcome. >>>>> >>>>> -Ekr >>>>> >>>> >>>> Regarding Certificate Status, is it such a good idea to keep both the >>>> original extension and the newer status_request_v2 extension in TLS 1.3? >>>> The client may have to signal the original extension in order to be >>>> interoperable with older TLS implementations, but wouldn't it be best if >>>> TLS 1.3 mandated the v2 extension in the server response? >>> >>> >>> >>> I don't think it's a good idea to have the server responding with >>> extensions >>> that the client didn't offer. If we're going to prefer v2, I would rather >>> forbid >>> the v1 version in TLS 1.3 >> >> >> I was thinking along the lines of saying that TLS 1.3 clients that support >> certificate status MUST send v2, MAY send v1 (to be interoperable with older >> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 >> session) MUST respond with v2 and MUST NOT respond with v1. > > > Well, what if the client doesn't want the OCSP response? Wouldn't the client then not send the certificate status extension, which the proposed text seems to include as an option? Or am I missing something? > > -Ekr > >> >> >> -- >> Sincerely, >> Yngve N. Pettersen > > > > _______________________________________________ > 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 May 2 14:55: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 088A512D662 for ; Mon, 2 May 2016 14:55:15 -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 cgpFgj75n3ut for ; Mon, 2 May 2016 14:55:12 -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 B314012D126 for ; Mon, 2 May 2016 14:55:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t10so1944246ywa.0 for ; Mon, 02 May 2016 14:55:12 -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=rtpxRDrkRHdg/7m3zL9mbxMAG+CCE/ompph+q3id2Fg=; b=Jyq+h3peOif1irkT/s1laAww34aFLNZ0a+Qj2/FGaLFdTbzDAQ5zmOYFmaefz4ogEk oq2zg71R3n60nI73FcRWrdMZ6xf61r6EyfWmWbklISKCBURiy22KP+vyYet6YpWryyuq Ejbx/Af9AwLUs8co4zS4RNbZe85lgVtils82w3TwhPdjiP9stJ6mecjhJ9SodyMC7rWL IQ5Yg/PzVl/5LgJ6RbZEyaoEIo/jwUuy6IwjKghCxjHDOlZOCNcGHlWNbvmeO+6Uhe7o V5aKC4JfCQ0DMSx8DeneWUBnBfzKKgyvhi+cSZW1VKxYtW5VtYlT5FpQ7tyuVo7zMS6D qJDA== 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=rtpxRDrkRHdg/7m3zL9mbxMAG+CCE/ompph+q3id2Fg=; b=K0M9zfkHWAGyaaMuwdCQ56clZ1s1Zl4Nak+vlXxjH7IlnpdGBdbQBzdZTUKxKlmFKn 7QlcQDrA0PiHacNKymLDGzEWXSHR2KcHGCLksA9nLOY2+05zBr1ymvagd9DqN0Sk0z1x JQN2M6sMVxeBC5f8T7JMPfMytbTJhJBKM7GmaBJF7gcBzhLRdGyahbk2MX0a74rD+EN+ i0MFy6qwD1oHn9oDRUQvEJF/3xvSFPGYTTxUSr2EGblO+UUneLvsj9G/R2tF1G/PYvV1 ePDY0R7Z398pukv5OtR5uASs6Kjfva37A/HivfEggX9AcjoFrLEWBAT2I3PTB54rMEXZ 2GMw== X-Gm-Message-State: AOPr4FX98J5tf9zlLqkOKVqci9vmdzgkrDg7DDY0CJWNfKFPXHbVQYVWfx8ykEKC7ZvRDZmpJj0Is7IUGiuG6Q== X-Received: by 10.37.223.210 with SMTP id w201mr21260451ybg.74.1462226111998; Mon, 02 May 2016 14:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 14:54:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 May 2016 14:54:32 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c088c88fcd8ee0531e30b5f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 21:55:15 -0000 --94eb2c088c88fcd8ee0531e30b5f Content-Type: text/plain; charset=UTF-8 Sorry, I'm responding to Yngve's "MUST" suggestion. I think what would be reasonable would be: - clients MAY send either {(v1,v2), (v2), or ()} - servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the client sent {(v1,v2), (v2)} That I could live with... -Ekr On Mon, May 2, 2016 at 2:45 PM, Watson Ladd wrote: > On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla wrote: > > > > > > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen > > wrote: > >> > >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wrote: > >> > >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen < > yngve@spec-work.net> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> > >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla > wrote: > >>>> > >>>> PR: https://github.com/tlswg/tls13-spec/pull/448 > >>>>> > >>>>> Targe landing date: Wednesday > >>>>> > >>>>> In Buenos Aires we discussed moving CertificateStatus to part of the > >>>>> Certificate message. In offline conversations, it started to look > like > >>>>> that > >>>>> wasn't optimal in part because it created an asymmetry wrt Signed > >>>>> Certificate Timestamps. Instead, I propose just carrying the response > >>>>> in > >>>>> the response extensions. > >>>>> > >>>>> I just created PR#443, which moves the CertificateStatus response to > an > >>>>> extension in EncryptedExtensions. Comments welcome. > >>>>> > >>>>> -Ekr > >>>>> > >>>> > >>>> Regarding Certificate Status, is it such a good idea to keep both the > >>>> original extension and the newer status_request_v2 extension in TLS > 1.3? > >>>> The client may have to signal the original extension in order to be > >>>> interoperable with older TLS implementations, but wouldn't it be best > if > >>>> TLS 1.3 mandated the v2 extension in the server response? > >>> > >>> > >>> > >>> I don't think it's a good idea to have the server responding with > >>> extensions > >>> that the client didn't offer. If we're going to prefer v2, I would > rather > >>> forbid > >>> the v1 version in TLS 1.3 > >> > >> > >> I was thinking along the lines of saying that TLS 1.3 clients that > support > >> certificate status MUST send v2, MAY send v1 (to be interoperable with > older > >> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 > >> session) MUST respond with v2 and MUST NOT respond with v1. > > > > > > Well, what if the client doesn't want the OCSP response? > > Wouldn't the client then not send the certificate status extension, > which the proposed text seems to include as an option? Or am I missing > something? > > > > > -Ekr > > > >> > >> > >> -- > >> Sincerely, > >> Yngve N. Pettersen > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --94eb2c088c88fcd8ee0531e30b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I'm responding to Yngve's "MUST" = suggestion.

I think what would be reasonable would be:

- clients MAY send either {(v1,v2), (v2), or ()}
- servers MUST send either {(v2 ) or ()} and MUST only send (v2) if= the client sent {(v1,v2), (v2)}

That I could live= with...
-Ekr


On Mon, May 2, 2= 016 at 2:45 PM, Watson Ladd <watsonbladd@gmail.com> wrot= e:
On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen <yngve@spec-work.net>
> wrote:
>>
>> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <yngve@spec-work.net>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> PR: https://github.com/tlswg/tls13-spec= /pull/448
>>>>>
>>>>> Targe landing date: Wednesday
>>>>>
>>>>> In Buenos Aires we discussed moving CertificateStatus = to part of the
>>>>> Certificate message. In offline conversations, it star= ted to look like
>>>>> that
>>>>> wasn't optimal in part because it created an asymm= etry wrt Signed
>>>>> Certificate Timestamps. Instead, I propose just carryi= ng the response
>>>>> in
>>>>> the response extensions.
>>>>>
>>>>> I just created PR#443, which moves the CertificateStat= us response to an
>>>>> extension in EncryptedExtensions. Comments welcome. >>>>>
>>>>> -Ekr
>>>>>
>>>>
>>>> Regarding Certificate Status, is it such a good idea to ke= ep both the
>>>> original extension and the newer status_request_v2 extensi= on in TLS 1.3?
>>>> The client may have to signal the original extension in or= der to be
>>>> interoperable with older TLS implementations, but wouldn&#= 39;t it be best if
>>>> TLS 1.3 mandated the v2 extension in the server response?<= br> >>>
>>>
>>>
>>> I don't think it's a good idea to have the server resp= onding with
>>> extensions
>>> that the client didn't offer. If we're going to prefer= v2, I would rather
>>> forbid
>>> the v1 version in TLS 1.3
>>
>>
>> I was thinking along the lines of saying that TLS 1.3 clients that= support
>> certificate status MUST send v2, MAY send v1 (to be interoperable = with older
>> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS = 1.3
>> session) MUST respond with v2 and MUST NOT respond with v1.
>
>
> Well, what if the client doesn't want the OCSP response?

Wouldn't the client then not send the certificate status ex= tension,
which the proposed text seems to include as an option? Or am I missing
something?

>
> -Ekr
>
>>
>>
>> --
>> Sincerely,
>> Yngve N. Pettersen
>
>
>
> _______________________= ________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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

--94eb2c088c88fcd8ee0531e30b5f-- From nobody Mon May 2 15: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 E6D8B12D1A3 for ; Mon, 2 May 2016 15:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9OAHKzRh-LJ for ; Mon, 2 May 2016 15:01:40 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::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 99FB512D5B7 for ; Mon, 2 May 2016 15:01:33 -0700 (PDT) Received: from 137.71.202.84.customer.cdi.no ([84.202.71.137]:56596 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1axLuF-00059E-QF; Tue, 03 May 2016 00:01:31 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Watson Ladd" , "Eric Rescorla" References: Date: Tue, 03 May 2016 00:01:03 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 22:01:42 -0000 On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla wrote: > Sorry, I'm responding to Yngve's "MUST" suggestion. > > I think what would be reasonable would be: > > - clients MAY send either {(v1,v2), (v2), or ()} > - servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the > client sent {(v1,v2), (v2)} Which is what I suggested; note that I said "clients that support certificate status", with "support" meaning "enabled". > That I could live with... > -Ekr > > > On Mon, May 2, 2016 at 2:45 PM, Watson Ladd > wrote: > >> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla wrote: >> > >> > >> > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen >> >> > wrote: >> >> >> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla >> wrote: >> >> >> >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen < >> yngve@spec-work.net> >> >>> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> >> >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla >> wrote: >> >>>> >> >>>> PR: https://github.com/tlswg/tls13-spec/pull/448 >> >>>>> >> >>>>> Targe landing date: Wednesday >> >>>>> >> >>>>> In Buenos Aires we discussed moving CertificateStatus to part of >> the >> >>>>> Certificate message. In offline conversations, it started to look >> like >> >>>>> that >> >>>>> wasn't optimal in part because it created an asymmetry wrt Signed >> >>>>> Certificate Timestamps. Instead, I propose just carrying the >> response >> >>>>> in >> >>>>> the response extensions. >> >>>>> >> >>>>> I just created PR#443, which moves the CertificateStatus response >> to >> an >> >>>>> extension in EncryptedExtensions. Comments welcome. >> >>>>> >> >>>>> -Ekr >> >>>>> >> >>>> >> >>>> Regarding Certificate Status, is it such a good idea to keep both >> the >> >>>> original extension and the newer status_request_v2 extension in TLS >> 1.3? >> >>>> The client may have to signal the original extension in order to be >> >>>> interoperable with older TLS implementations, but wouldn't it be >> best >> if >> >>>> TLS 1.3 mandated the v2 extension in the server response? >> >>> >> >>> >> >>> >> >>> I don't think it's a good idea to have the server responding with >> >>> extensions >> >>> that the client didn't offer. If we're going to prefer v2, I would >> rather >> >>> forbid >> >>> the v1 version in TLS 1.3 >> >> >> >> >> >> I was thinking along the lines of saying that TLS 1.3 clients that >> support >> >> certificate status MUST send v2, MAY send v1 (to be interoperable >> with >> older >> >> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 >> >> session) MUST respond with v2 and MUST NOT respond with v1. >> > >> > >> > Well, what if the client doesn't want the OCSP response? >> >> Wouldn't the client then not send the certificate status extension, >> which the proposed text seems to include as an option? Or am I missing >> something? >> >> > >> > -Ekr >> > >> >> >> >> >> >> -- >> >> Sincerely, >> >> Yngve N. Pettersen >> > >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> -- Sincerely, Yngve N. Pettersen From nobody Mon May 2 15:10: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 1531012D64A for ; Mon, 2 May 2016 15:10:14 -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 riyLVQMDv21Q for ; Mon, 2 May 2016 15:10:12 -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 3175812D64C for ; Mon, 2 May 2016 15:10:12 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g133so1941055ywb.2 for ; Mon, 02 May 2016 15:10:12 -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=H5yZTIkh9w1OeFO3M+DTtB3FPyokIatfu8FM1lOx2+k=; b=nTY2GVBAgdmn0AF1WPts2EOvfoDvxbNeMvKWplbjbM/XJ6/KzM6bLW+daMb2vjU2Jx sbNc7KIfzbIMMsrsnOdd9BunX/R6GhY3oqdWW8KZRDi6KVmshf3XNMMryvUnKWiWbFYv qwH/X2nluPPEavzhEe/X/MQKQfQooVK5BRm+l2xFBzcFf75GeRWJZ72pf4y6AjNtpy6Z 4dzPU+aMGqTI5CE0aQqjVVxobrc/PL7rFt+8og3SohNC/VXk3vADGPI24/n6E8eLzU/8 P0Hx1sOiEWW+64AB2wT7CYw2kIsA1h/INuZuSu1z6hFXDxq1YO4YB9rlNz6nsZ2Nez9J ULbg== 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=H5yZTIkh9w1OeFO3M+DTtB3FPyokIatfu8FM1lOx2+k=; b=PcWT89zADUOSH/1kM63mUT0sBwMqHQoiMGffwbpBKq2nHVJMHULesD9Bik5aWMCOXf 1TLVbnH6VkpnWsKa/7x9hhlhQtoeV82ahZ3pZJnbg1nxw/J9RQ22t/LXWLlFCLSlCBaA OvBJFkUUOIwRARdZG3/fe5ZtGJQ4wk3VK19+g4rr8EmIa5JIRErqe0gXPboPTfWlLYAI 9TSJrSXjD2ZQxo+EBGBSEJRQK7RP5kzsY7pxqg1bml0Kcpd1vjxXChSMbXdEPaSh96Nj Gbk+hlLf4D0UQffOLjeVv9iScSEq2vYkYe5jT93DZrK866OhNofBskD3Wa4gBTbWnK/w g6Ww== X-Gm-Message-State: AOPr4FX8+ds+sq8bA3J7rR5Qb1X2q4nNFXojq0Xzr32A6JTEW3uXREKHJjGvsgs/msQUmV0I37fa2sSIZ5qjVQ== X-Received: by 10.129.46.193 with SMTP id u184mr19994700ywu.180.1462227011527; Mon, 02 May 2016 15:10:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 15:09:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 May 2016 15:09:32 -0700 Message-ID: To: "Yngve N. Pettersen" Content-Type: multipart/alternative; boundary=001a11408a1c9a99290531e34179 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#448: CertificateStatus to 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: Mon, 02 May 2016 22:10:14 -0000 --001a11408a1c9a99290531e34179 Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2016 at 3:01 PM, Yngve N. Pettersen wrote: > On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla wrote: > > Sorry, I'm responding to Yngve's "MUST" suggestion. >> >> I think what would be reasonable would be: >> >> - clients MAY send either {(v1,v2), (v2), or ()} >> - servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the >> client sent {(v1,v2), (v2)} >> > > Which is what I suggested; note that I said "clients that support > certificate status", with "support" meaning "enabled". My mistake for misreading you. Sounds like we're on the same page. I'll modify as you suggest. -Ekr > > That I could live with... >> -Ekr >> >> >> On Mon, May 2, 2016 at 2:45 PM, Watson Ladd >> wrote: >> >> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla wrote: >>> > >>> > >>> > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen < >>> yngve@spec-work.net> >>> > wrote: >>> >> >>> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla >>> wrote: >>> >> >>> >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen < >>> yngve@spec-work.net> >>> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> >>> >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla >>> wrote: >>> >>>> >>> >>>> PR: https://github.com/tlswg/tls13-spec/pull/448 >>> >>>>> >>> >>>>> Targe landing date: Wednesday >>> >>>>> >>> >>>>> In Buenos Aires we discussed moving CertificateStatus to part of >>> the >>> >>>>> Certificate message. In offline conversations, it started to look >>> like >>> >>>>> that >>> >>>>> wasn't optimal in part because it created an asymmetry wrt Signed >>> >>>>> Certificate Timestamps. Instead, I propose just carrying the >>> response >>> >>>>> in >>> >>>>> the response extensions. >>> >>>>> >>> >>>>> I just created PR#443, which moves the CertificateStatus response >>> to >>> an >>> >>>>> extension in EncryptedExtensions. Comments welcome. >>> >>>>> >>> >>>>> -Ekr >>> >>>>> >>> >>>> >>> >>>> Regarding Certificate Status, is it such a good idea to keep both >>> the >>> >>>> original extension and the newer status_request_v2 extension in TLS >>> 1.3? >>> >>>> The client may have to signal the original extension in order to be >>> >>>> interoperable with older TLS implementations, but wouldn't it be >>> best >>> if >>> >>>> TLS 1.3 mandated the v2 extension in the server response? >>> >>> >>> >>> >>> >>> >>> >>> I don't think it's a good idea to have the server responding with >>> >>> extensions >>> >>> that the client didn't offer. If we're going to prefer v2, I would >>> rather >>> >>> forbid >>> >>> the v1 version in TLS 1.3 >>> >> >>> >> >>> >> I was thinking along the lines of saying that TLS 1.3 clients that >>> support >>> >> certificate status MUST send v2, MAY send v1 (to be interoperable with >>> older >>> >> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 >>> >> session) MUST respond with v2 and MUST NOT respond with v1. >>> > >>> > >>> > Well, what if the client doesn't want the OCSP response? >>> >>> Wouldn't the client then not send the certificate status extension, >>> which the proposed text seems to include as an option? Or am I missing >>> something? >>> >>> > >>> > -Ekr >>> > >>> >> >>> >> >>> >> -- >>> >> Sincerely, >>> >> Yngve N. Pettersen >>> > >>> > >>> > >>> > _______________________________________________ >>> > TLS mailing list >>> > TLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tls >>> > >>> >>> >>> >>> -- >>> "Man is born free, but everywhere he is in chains". >>> --Rousseau. >>> >>> > > -- > Sincerely, > Yngve N. Pettersen > --001a11408a1c9a99290531e34179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2016 at 3:01 PM, Yngve N. Pettersen &l= t;yngve@spec-work.= net> wrote:
On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla <ekr@rtfm.com> wrote:

Sorry, I'm responding to Yngve's "MUST" suggestion.

I think what would be reasonable would be:

- clients MAY send either {(v1,v2), (v2), or ()}
- servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the
client sent {(v1,v2), (v2)}

 Which is what I suggested; note that I said "clients that support cert= ificate status", with "support" meaning "enabled".=

My mistake for misreading you. Sounds like= we're on the same page. I'll modify
as you suggest.

-Ekr



That I could live with...
-Ekr


On Mon, May 2, 2016 at 2:45 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen <yngve@spec-work.net>
> wrote:
>>
>> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen <
yngve@spec-work.ne= t>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com>
wrote:
>>>>
>>>> PR: https://github.com/tlswg/tls13-spec= /pull/448
>>>>>
>>>>> Targe landing date: Wednesday
>>>>>
>>>>> In Buenos Aires we discussed moving CertificateStatus = to part of the
>>>>> Certificate message. In offline conversations, it star= ted to look
like
>>>>> that
>>>>> wasn't optimal in part because it created an asymm= etry wrt Signed
>>>>> Certificate Timestamps. Instead, I propose just carryi= ng the response
>>>>> in
>>>>> the response extensions.
>>>>>
>>>>> I just created PR#443, which moves the CertificateStat= us response to
an
>>>>> extension in EncryptedExtensions. Comments welcome. >>>>>
>>>>> -Ekr
>>>>>
>>>>
>>>> Regarding Certificate Status, is it such a good idea to ke= ep both the
>>>> original extension and the newer status_request_v2 extensi= on in TLS
1.3?
>>>> The client may have to signal the original extension in or= der to be
>>>> interoperable with older TLS implementations, but wouldn&#= 39;t it be best
if
>>>> TLS 1.3 mandated the v2 extension in the server response?<= br> >>>
>>>
>>>
>>> I don't think it's a good idea to have the server resp= onding with
>>> extensions
>>> that the client didn't offer. If we're going to prefer= v2, I would
rather
>>> forbid
>>> the v1 version in TLS 1.3
>>
>>
>> I was thinking along the lines of saying that TLS 1.3 clients that=
support
>> certificate status MUST send v2, MAY send v1 (to be interoperable = with
older
>> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS = 1.3
>> session) MUST respond with v2 and MUST NOT respond with v1.
>
>
> Well, what if the client doesn't want the OCSP response?

Wouldn't the client then not send the certificate status extension,
which the proposed text seems to include as an option? Or am I missing
something?

>
> -Ekr
>
>>
>>
>> --
>> Sincerely,
>> Yngve N. Pettersen
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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



--
Sincerely,
Yngve N. Pettersen

--001a11408a1c9a99290531e34179-- From nobody Thu May 5 07:20: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 B0FB812DAF1; Thu, 5 May 2016 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 WujfYingVMcU; Thu, 5 May 2016 07:20:10 -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 016DF12DA02; Thu, 5 May 2016 07:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE2F6BE2F; Thu, 5 May 2016 15:14:13 +0100 (IST) 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 pkETKzzxTylr; Thu, 5 May 2016 15:14:13 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 18ABEBE2D; Thu, 5 May 2016 15:14:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462457653; bh=Rlrz0e4BVaKKkZE7E4OhYbKPD1+IIqsGRTEYj04/D8k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ON7kksbHq1N/H/C+/dDgzMOGJOY1eoWOxg0GNS9s8XU+oCjpP6m3IlAdiXggEwxIf FYEB43xloeRW1asmYVhBKrJwqdo53gQpODDo22/2PGZ+tzyGMmsmGqiyq/Zu8K37Pr Eqr626Hm2GLvkfyeybgfVGNAy+i6pkU67fO4XKcI= To: Alexey Melnikov , The IESG References: <20160424162332.6957.99300.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572B553B.8050805@cs.tcd.ie> Date: Thu, 5 May 2016 15:14:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160424162332.6957.99300.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050605000405000601080407" Archived-At: Cc: draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:20:17 -0000 This is a cryptographically signed message in MIME format. --------------ms050605000405000601080407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/04/16 17:23, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tls-chacha20-poly1305-04: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Nit: SHA-256 probably needs a normative reference. I added an RFC editor note. If someone has the right reference to add handy I can add that too. Or I'll get to it in a bit, Cheers, S. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms050605000405000601080407 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDUx NDE0MTlaMC8GCSqGSIb3DQEJBDEiBCDSJnA7CmVjB9SZf5yojc71sUpVqBz4c1pTnB8K3kpb 1DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA6JsaXl5mQzvVFhM91lKcy+XOtzV0taGPhkPiZYD+DUTTPIs3lqR87 f0TA+ivdluwYKiuZy6rp5hN/iZodJsBLHlm4MHZhUT8oYM3LD91tCgIlVffXibDCHLy8HH20 PMsry5IYg6RVIVNqePNSFEacaGjt8s+7giVlp+85e8q1oJ/sUiNjhGJStXEZZJp9XW7Bhn3a vfKU5ojfqK8bIeggxWWQH5hqnOND90av8EpYIIZFLLCWB01OGo/OMXOWNW0eMFgcolNBTEmk 97C8lksD9to+HpyOR2HQwhAQEFuYGs/QzuqiNznLr1CxO3curwapsJ4RVMgJePRX2NY+6DLS AAAAAAAA --------------ms050605000405000601080407-- From nobody Thu May 5 07:41: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 3F81812D79A; Thu, 5 May 2016 07:41:16 -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 leUcf9iOrgiZ; Thu, 5 May 2016 07:41:14 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0138.outbound.protection.outlook.com [23.103.200.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297ED12D97D; Thu, 5 May 2016 07:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T9RxWR9hi2eepluLtI2vhrsI2BGItTyGxeNH0eZnnWs=; b=nGk019WljDqUiaw9nOQfYPmkQRCPPCAZJxyyJm463sKlrR6PCF4GKxj2Aq3szbP3l7VGNwpxY55r851/nwRIefP6h4BtdTvlbmDB3vVDIcQY+bTSN3Ty8W1GJssMDfOJ95MQznskYKX43/r9XzK/4inkg09df0GBDkzeI9O+3fM= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 5 May 2016 14:34:00 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0477.017; Thu, 5 May 2016 14:33:59 +0000 From: "Dang, Quynh (Fed)" To: Stephen Farrell , The IESG Thread-Topic: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) Thread-Index: AQHRnkWvMTGC7q87e0edGSs7TJBnwJ+qdEiAgAAEVgM= Date: Thu, 5 May 2016 14:33:59 +0000 Message-ID: References: <20160424162332.6957.99300.idtracker@ietfa.amsl.com>, <572B553B.8050805@cs.tcd.ie> In-Reply-To: <572B553B.8050805@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.198] x-ms-office365-filtering-correlation-id: 63f77a5e-39a9-4c8f-30cd-08d374f24c44 x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:6ONS9t0q4jfzR2KFyF4f+8C1PzdyHqPN6fbVr/8eB5zgeqn00j6D0oHTgCnCP0NvfDzND69PxFjIU+WAl2zq/YV5bDod0xZPLFKaJgqmkMlmVoaTfWhsy8ImuWA3v1lnoElKJPAqHvM3OlPj2fdP9A==; 24:QIV2glPpqbNNcXIqEog8E8VhDwp4fDTDkUUadUhKylUyZ1EBpRQIOcwnXcOfwyWLiZNoBsImWOud4PImFS4qJ9tBlMD3nyl+cdB5GKssl8Y=; 7:WniODErh74XRAg+zpR2uFQT9ST4wyp6pzRkDs2cFS/3eMUJCZOmUk9s2XeIyPbavKNso+DGwcqaOYVd7jjageEO+G4m2Yib5qmMYQrDmaUsfcSPGuwKIzq1mkXQKEoo2YLNCOI2ihE3YqHt8tbZWD4xJHyANIcT5yREZpj0MOgXqb9F9Oq221uPWO2HSxj/q x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52044002)(24454002)(87936001)(2950100001)(3280700002)(5008740100001)(3660700001)(2906002)(189998001)(122556002)(92566002)(15975445007)(77096005)(86362001)(2900100001)(8936002)(99286002)(4326007)(3846002)(10400500002)(19580395003)(19580405001)(5001770100001)(106116001)(1220700001)(586003)(5002640100001)(102836003)(6116002)(33656002)(66066001)(9686002)(5004730100002)(74316001)(230783001)(76176999)(54356999)(5003600100002)(81166005)(50986999)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2016 14:33:59.7160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: "draft-ietf-tls-chacha20-poly1305@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:41:16 -0000 Hi Stephen, The one below can be used. [FIPS 180-4] Federal Information Processing Standards Publication (FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015. Regards, Quynh. ________________________________________ From: TLS on behalf of Stephen Farrell Sent: Thursday, May 5, 2016 10:14:19 AM To: Alexey Melnikov; The IESG Cc: draft-ietf-tls-chacha20-poly1305@ietf.org; tls-chairs@ietf.org; tls@iet= f.org Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly130= 5-04: (with COMMENT) On 24/04/16 17:23, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tls-chacha20-poly1305-04: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Nit: SHA-256 probably needs a normative reference. I added an RFC editor note. If someone has the right reference to add handy I can add that too. Or I'll get to it in a bit, Cheers, S. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu May 5 07:46: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 70B1D12DBC4; Thu, 5 May 2016 07:46: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 PhKHOMIAsszv; Thu, 5 May 2016 07:46:14 -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 9C60012D881; Thu, 5 May 2016 07:39:14 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n129so23291541wmn.1; Thu, 05 May 2016 07:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=cuJuoqrZ0PAlCVQT7grZZpcouFCckK5HSRMqjmzVIYM=; b=iBYkNz2kdqBbtKUm1IXZJgyU4af+ZqNnEJMkUQGDLP+Q0/a++fsjNQ73WOuxVBlY8S UzuCtbQ4g6Mj0Fz4tT38VDVEYAm3BfnEGaoRLlT7auMhR0pL8vrYNeB5KBiI9pTEciJR BJI14WJp0D7BIHZcdoqSmDiaH0Q+VwMRpHGlNT4KgZc0Sr1FfHqk0GBtWFUupT4mc2gU DnXruyQUbZGJlAl8r1P1v0qDXLAw6m8R3q4b4qosOIE6DIiKPRmydN3GMA9O6Ur7qTHP qDs8WYVaiLHIEsuF1E/Qzp/d3v5TeDSTdmaDgz0oYmF0wCG2TO9qkEZ4GWIH0x2Vf4QP 3cCg== 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 :message-id:references:to; bh=cuJuoqrZ0PAlCVQT7grZZpcouFCckK5HSRMqjmzVIYM=; b=ZjRd8Aqr6aPRTD67K3IRVLgzu2P2k7FxuEpZD2MPfNTEhcFVTVBRKbO4nyeZ9+yvK3 a+C+gpiAvjyIqBqsdZ1NYazut9hdUxHeV6IGc3AaMI6DsqXS7nZNUEU0MSvC0KFWwyRD vhVYpsAE+xgJFmgPl/mk48iKmCbtGx3Q+UPFFXnBVbZzQq+vbp3NqGwvpcEC4oacff20 fxI1HYeXEl2MU43Tb/5XIL0SGRGv/d/JGTCpmcZlQK1GiAS/hr8PPn++ATWeQa96qmE8 Eg216VutamHgPKnE5TCO2PtrmtWz/U2AAdUhbCg5gtskLTtQk8xpNSz8tcYZEUz16dYI Dfog== X-Gm-Message-State: AOPr4FXXk6rsMsT+q0wOOTQ4KEfpKfSXSKTKqzPVHzaU97hYZCStbryk4/YoSsxtJUBMWA== X-Received: by 10.28.12.8 with SMTP id 8mr3865661wmm.6.1462459153161; Thu, 05 May 2016 07:39:13 -0700 (PDT) Received: from [192.168.4.111] ([199.203.248.154]) by smtp.gmail.com with ESMTPSA id d79sm3466584wmi.23.2016.05.05.07.39.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 May 2016 07:39:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6FE66235-245E-47AB-AD9A-7D21515682DF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <572B553B.8050805@cs.tcd.ie> Date: Thu, 5 May 2016 17:39:09 +0300 Message-Id: <98D9DECB-222B-448D-BB9E-2A2DAC5CBAE9@gmail.com> References: <20160424162332.6957.99300.idtracker@ietfa.amsl.com> <572B553B.8050805@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls-chairs@ietf.org, draft-ietf-tls-chacha20-poly1305@ietf.org, The IESG , tls@ietf.org, Alexey Melnikov Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:46:28 -0000 --Apple-Mail=_6FE66235-245E-47AB-AD9A-7D21515682DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 May 2016, at 5:14 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 24/04/16 17:23, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-chacha20-poly1305-04: Yes >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Nit: SHA-256 probably needs a normative reference. >=20 > I added an RFC editor note. If someone has the right reference > to add handy I can add that too. Or I'll get to it in a bit, RFC 6234 works. Or: =E2=80=9CSecure Hash Standard (SHS)=E2=80=9D, FIPS PUB 180-4, August = 2015, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf --Apple-Mail=_6FE66235-245E-47AB-AD9A-7D21515682DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXK1sOAAoJECXR4BOacZZUkUAIALsmC6AXCrjwxQVWYNrT7GEV 0gUNPtjStdC3W5kD0rMHV9HlnNnAEGM/ge04ISnY9aeY4WFSgZRsOH+tJsf03+pQ V3JwBpYTNxn6G2DLYLN6yJSajmdQfcqKP96cK+iUoK6BMiNTexlZuYlk/9zFtrY9 hv4YM0Ezn8X5uU4hW11sasRGrZUSRmK173QNMS05XCPrgEq6SzquBoEu0ZD1ijI+ TVJ4vDmcBW/ZAnxusN7/2Ro67Z1Dmwl+cWhyVIQNCHUwvqwWeipCOEBDdDI/H7By MGbKUfnbW1NNa8sMiNV7aiIFbsjkGzym5KQsEucJtSGdQhg31dAs8Wqy/3fiF0Y= =3g0/ -----END PGP SIGNATURE----- --Apple-Mail=_6FE66235-245E-47AB-AD9A-7D21515682DF-- From nobody Thu May 5 07:56: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 35D3312D1CE; Thu, 5 May 2016 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 G8jE5bRoN7oy; Thu, 5 May 2016 07:56:05 -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 45E4C12DAB1; Thu, 5 May 2016 07:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11524BE32; Thu, 5 May 2016 15:48:58 +0100 (IST) 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 F4dP7laedLtQ; Thu, 5 May 2016 15:48:57 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4ACD7BE2D; Thu, 5 May 2016 15:48:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462459737; bh=LJZkqDtvJf2MGfNQcO4Dg+cw6BPwqPS8n83P39OdNDE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=M1O7OIjAKs4I3ZsDxVvkL2+3HlaT9UHMc4AKvYc+j4CFjFg/PFeXghbW+dtvyGWco 2DyB6cLE37YgJYJZ9GSKvBxL5aco+4q6Bx+DNzCuie9LRV8NSJROzWr4E4EX5a3s6o pnQvHvZ1Lgs410s2cU0hUdR80fTD2sZjYL4sEOwc= To: Alexey Melnikov , "Dang, Quynh (Fed)" , The IESG References: <572B553B.8050805@cs.tcd.ie> <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <572B5D61.3020600@cs.tcd.ie> Date: Thu, 5 May 2016 15:49:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060502010906090104030009" Archived-At: Cc: draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:56:07 -0000 This is a cryptographically signed message in MIME format. --------------ms060502010906090104030009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks all. I updated the RFC editor note to add the FIPS reference. Cheers, S. On 05/05/16 15:45, Alexey Melnikov wrote: > On Thu, May 5, 2016, at 03:33 PM, Dang, Quynh (Fed) wrote: >> >> Hi Stephen, >> >> The one below can be used. >> >> [FIPS 180-4] Federal Information Processing Standards Publication >> (FIPS PUB) 180-4, Secure Hash Standard (SHS), August >> 2015. >=20 > There is also RFC 4634, but I am not sure which reference is better. >=20 >> Regards, >> Quynh. >> ________________________________________ >> From: TLS on behalf of Stephen Farrell >> >> Sent: Thursday, May 5, 2016 10:14:19 AM >> To: Alexey Melnikov; The IESG >> Cc: draft-ietf-tls-chacha20-poly1305@ietf.org; tls-chairs@ietf.org; >> tls@ietf.org >> Subject: Re: [TLS] Alexey Melnikov's Yes on >> draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) >> >> On 24/04/16 17:23, Alexey Melnikov wrote: >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-tls-chacha20-poly1305-04: Yes >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> COMMENT: >>> ---------------------------------------------------------------------= - >>> >>> Nit: SHA-256 probably needs a normative reference. >> >> I added an RFC editor note. If someone has the right reference >> to add handy I can add that too. Or I'll get to it in a bit, >> >> Cheers, >> S. >> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> --------------ms060502010906090104030009 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDUx NDQ5MDVaMC8GCSqGSIb3DQEJBDEiBCC9eE0CFW/4+qnGzd5gvd+sCh0VvtA+dWSuAHP74/Bp CDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB7n1KXDeeuRBORZJi/YUHtabbpzFcqcNVrSKdyo1EfJenI72aiWB47 IsLcp8oUrRQYCfl+OVCPinq+XcCy27d0VLFNR1AjylCftKHi9bLKaBt5TlsTtiyekPpC4BGG 1dzc1wH9HTYtXD7BkIMfxdMdnXr8GIAD+S0UzXEIo3p2XyLMAyBa5eqh5qb6v5ZZyGBCBU9P Sctcl5gtX4TsDNUbWRh0BEPd6HILNPufyNkStxDcAFh7245zYXE4tYKIZy/XmdzzvmJcoFd1 0p8Z84NR2ITQhQnMB9XjCPNV8x+lBeva7TSq065fQqA2ZHAM2XgL9Y2/Y7cfFClRf0nX3C0G AAAAAAAA --------------ms060502010906090104030009-- From nobody Thu May 5 07:58: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 4808F12D745 for ; Thu, 5 May 2016 07:58:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=krO4OcaM; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=pNWN4rEo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZRa9rjnDMzM for ; Thu, 5 May 2016 07:58:20 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37E912DAC7 for ; Thu, 5 May 2016 07:51:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1E38321042 for ; Thu, 5 May 2016 10:45:10 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 05 May 2016 10:45:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=FPG3bs8J2XYDbdvoeIKwP6KeHwc=; b=krO4Oc aMHBiLX1ibLR66mYcK8sj4bzwqtqyL9Yh9QUVyLDo/FKQMnB+PB1hkhOxFobcq7V XKkO+fw3x3QmNQpu1/7iMeaZRaYqfVIqxzZdRy2UtZ5OGEUYzgz93Aom8KT2a5vA Pi9EC1PdFgNJMLhoz0PMZDJ6VVErGwa4caOTE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=FPG3bs8J2XYDbdv oeIKwP6KeHwc=; b=pNWN4rEo9r7a1ExyqQsJJQtkdq+UivzxBVByZll5yUbDsgD D5sDgcg/mYX3xRNq76XZtfV7eueZ3mJb+QCclKxMCOx/hMlRHsIxwfJFhe/PK7ce sRvTAVmXNTmDSHp2QfhEXTvEj6Ph9c+yGEMRSn3pLKv80VjhJhrIhak0UkhQ= Received: by web5.nyi.internal (Postfix, from userid 99) id E3AFEA8A1A9; Thu, 5 May 2016 10:45:09 -0400 (EDT) Message-Id: <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> X-Sasl-Enc: VWaNDN/tV2/K8bTiuUwVB3gIVaEVjueeq+964De55Guy 1462459509 From: Alexey Melnikov To: "Dang, Quynh (Fed)" , Stephen Farrell , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-140377c4 In-Reply-To: References: <572B553B.8050805@cs.tcd.ie> Date: Thu, 05 May 2016 15:45:09 +0100 Archived-At: Cc: draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:58:22 -0000 On Thu, May 5, 2016, at 03:33 PM, Dang, Quynh (Fed) wrote: > > Hi Stephen, > > The one below can be used. > > [FIPS 180-4] Federal Information Processing Standards Publication > (FIPS PUB) 180-4, Secure Hash Standard (SHS), August > 2015. There is also RFC 4634, but I am not sure which reference is better. > Regards, > Quynh. > ________________________________________ > From: TLS on behalf of Stephen Farrell > > Sent: Thursday, May 5, 2016 10:14:19 AM > To: Alexey Melnikov; The IESG > Cc: draft-ietf-tls-chacha20-poly1305@ietf.org; tls-chairs@ietf.org; > tls@ietf.org > Subject: Re: [TLS] Alexey Melnikov's Yes on > draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) > > On 24/04/16 17:23, Alexey Melnikov wrote: > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-tls-chacha20-poly1305-04: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Nit: SHA-256 probably needs a normative reference. > > I added an RFC editor note. If someone has the right reference > to add handy I can add that too. Or I'll get to it in a bit, > > Cheers, > S. > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > From nobody Thu May 5 09:39: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 A421C12D70C; Thu, 5 May 2016 09:39:42 -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 6ygngvMkC7vp; Thu, 5 May 2016 09:39:40 -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 AE45712D70B; Thu, 5 May 2016 09:39:40 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f89so89801045ioi.0; Thu, 05 May 2016 09:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=Id1gn82Bqqgpp8CyMlD+Qt79qfydMAaTWz2vmGqmzG8=; b=avGdbmWjlVXlY3gzhsH8UhTYtdnOfVlpiQMgHIjBIhGDKZbupwZoYz+zu65kuIYj+v RaUFlDCZ4HwEtf1PXL2T2m6j7YR2+2TJuay4QBzHhVpwqO8JzimX79dXLi9W6JURuxnF HyuhvC52VEGM+sQ/62ulTu7MO/1+XYHgl6VcgIhHZYDY0MtzYB06MoiPpZTAYSI5zU8a NE1IaqdTl1fvmKmGjnB+pdQZn4/ZJV6dcXeL1RFdwUp3oJ/r161dHCnWxF5rn6PgSwgX 6hS7gfdijCVpzVlkrHLkToLpEGGJDnqXt4A8J5R/7enAqgl6pB7wTVA0mxVJ28Z0Pd8Q b5QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=Id1gn82Bqqgpp8CyMlD+Qt79qfydMAaTWz2vmGqmzG8=; b=Sd9ihALhT93Gpp8ZncBNKVultUN1YpkmVSxl+GfnYdiLpIkyh9vgshiZbXLIG+12FU TMw/+hsjWp10NxiWOy+jBrVywL/GCO5k9zvqqHHXIg6w+XCNIyCOIxxHhoTJzzsLnS5j 2L0nQfy4HtmY92Dnytsp2FZ7iTnfPgFKkpo55/7srEYYF5PMucLzaMdqtCTOc0NUmBUz 5Zi5T5X1635Wg0BuHRZHiY1toOAOQXi8ZMab0s4LTQ5B8LvlQ4HLxzFvOm62EFYqBf0T TyUjZxKZvo0gvTPMf6cY9oQcvPtpguYX55d3dRQo9al/bmvYVk6jLx8j3abBOEmOdS1K s1kA== X-Gm-Message-State: AOPr4FWA6F/CbUbijjDCIHLQl7YEyqplHPC8guCE0s5CAxu42uH8Ji8gIXRKDqpup/7EFbO/2vIFrJXypDbdcg== MIME-Version: 1.0 X-Received: by 10.107.56.198 with SMTP id f189mr18590510ioa.156.1462466380062; Thu, 05 May 2016 09:39:40 -0700 (PDT) Received: by 10.64.245.99 with HTTP; Thu, 5 May 2016 09:39:39 -0700 (PDT) In-Reply-To: <572B5D61.3020600@cs.tcd.ie> References: <572B553B.8050805@cs.tcd.ie> <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> <572B5D61.3020600@cs.tcd.ie> Date: Thu, 5 May 2016 12:39:39 -0400 Message-ID: From: Jeffrey Walton To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" , Alexey Melnikov , draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, The IESG Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.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, 05 May 2016 16:39:43 -0000 On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell wrote: > > Thanks all. I updated the RFC editor note to add the FIPS > reference. > You might also consider mentioning the interop problems that are going to occur when diverging from Bernstein's reference implementation. Its already creating open questions on other mailing lists. For example, linux-crypto and https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1137554.html: > + chacha20_block(&crng->state[0], out); > + if (crng->state[12] == 0) > + crng->state[13]++; state[12]++? Or why do you increment the nonce? Jeff From nobody Fri May 6 00: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 9CD9612D59D; Fri, 6 May 2016 00:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.918 X-Spam-Level: X-Spam-Status: No, score=-7.918 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=-0.996, 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 Cc8QMKWcGZUD; Fri, 6 May 2016 00:08:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C6312D12B; Fri, 6 May 2016 00:08:35 -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 00F0E80096; Fri, 6 May 2016 07:08:34 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4678VVo009455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 May 2016 03:08:32 -0400 Message-ID: <1462518511.2994.8.camel@redhat.com> From: Nikos Mavrogiannopoulos To: noloader@gmail.com, Stephen Farrell Date: Fri, 06 May 2016 09:08:31 +0200 In-Reply-To: References: <572B553B.8050805@cs.tcd.ie> <1462459509.3180577.599095937.04C39339@webmail.messagingengine.com> <572B5D61.3020600@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 Archived-At: Cc: "tls@ietf.org" , Alexey Melnikov , draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, The IESG Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:08:37 -0000 On Thu, 2016-05-05 at 12:39 -0400, Jeffrey Walton wrote: > On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell > wrote: > > > > > > Thanks all. I updated the RFC editor note to add the FIPS > > reference. > > > You might also consider mentioning the interop problems that are > going > to occur when diverging from Bernstein's reference implementation. > Its > already creating open questions on other mailing lists. For example, > linux-crypto and > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1137554. > html: > >     > +     chacha20_block(&crng->state[0], out); >     > +     if (crng->state[12] == 0) >     > +             crng->state[13]++; > >     state[12]++? Or why do you increment the nonce? I wondered the same when I saw the comment. However, I'm not sure that is an issue. Chacha20 as a stream cipher is not defined anywhere by IETF (as far as I know). RFC7539 defines Chacha20-poly1305 AEAD (authenticated encryption) mechanism which uses a modified chacha20 than the reference algorithm. However, that doesn't really affect any other uses for the stream cipher. That's maybe the reason for the confusion. Bottom line, the comment relates more to RFC7539 rather than this draft. regards, Nikos From nobody Sun May 8 06:12: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 601B512B004 for ; Sun, 8 May 2016 06:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfEYMj6LmRcv for ; Sun, 8 May 2016 06:12:09 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1212D09E for ; Sun, 8 May 2016 06:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 70C0C366B for ; Sun, 8 May 2016 16:12:03 +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 v55f-p0ni04r for ; Sun, 8 May 2016 16:12:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1C9E0289 for ; Sun, 8 May 2016 16:12:03 +0300 (EEST) Date: Sun, 8 May 2016 16:12:01 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160508131201.GA4844@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 13:12:11 -0000 On Thu, Apr 28, 2016 at 10:32:52PM +0300, Ilari Liusvaara wrote: > > - The requirement for server to validate its extensions... Hopefully > there is no security reason for that... I really don't see it being > implemented correctly (and the description looks completely screwy[1]). Thinking some more about this, I now consider such validation to be a bad idea for _any_ current extension. Take all current extensions. Drop the following categories: - Connection control (ServerHello or hint for future) - Server auth control (no server auth) - Client auth control (CertificateRequest can alter things in all sorts of ways). - Disallowed in TLS 1.3. As these categories pretty obviously don't need to match. This leaves the following: 1) use_srtp 2) heartbeat 3) token_binding 4) application_layer_protocol_negotiation 5) server_name Looking into each in turn: 1) use_srtp This extension is arguably very much connection control (it negotiates if use of TLS-EXPORTER and TLS-MUX is OK and crypto algorithms for sideband data). It does not appear to have anything to do with 0-RTT. The type of extension in TLS 1.2 is unknown (couldn't find it in the spec). Presumably connection-type. 2) heartbeat Oh yes, this infamous extension... Also arguably very much connection control (negotiates if heartbeat mechnaism can be used). The type of extension in TLS 1.2 is unknown (couldn't find it in the spec). Presumably connection-type. 3) token_binding This extension is negotiating application-layer matters (it is TLS extension only to imporove performance). It is explicitly connection- type for TLS 1.2 (so forget reusing "session cache"). Applying this extension to 0-RTT runs into obvious difficulties, and I would not be happy to see complications in base TLS to handle the mess. It isn't published RFC yet, either. 4) application_layer_protocol_negotiation This is connection-type in TLS 1.2. Also the fact that accepted 0-RTT locks the ALP, while this extension negotiates ALP is a good reason why this extension MUST NOT be allowed in presence of accepted 0-RTT. That is, the ALP of the 0-RTT context needs to become the ALP of the new connection that accepts the context without negotiation, because there is exactly one ALP that can possibly work. 5) server_name Now this is a fun one... Serverside, this is merely ACK'd, so one would have to look at client request, not server response. This also seems like that if you get some problems with 0-RTT with different SNI, you get the same problem with just PSK without 0-RTT with different SNI. To make matters more fun, this interacts with middleboxes that sometimes route connections based on this. -Ilari From nobody Mon May 9 13:37:36 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 9D65912D620; Mon, 9 May 2016 13:37:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509203723.18381.92455.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 13:37:23 -0700 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-chacha20-poly1305@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [TLS] Protocol Action: 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-chacha20-poly1305-04.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, 09 May 2016 20:37:30 -0000 The IESG has approved the following document: - 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' (draft-ietf-tls-chacha20-poly1305-04.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ 1. Summary This draft specifies seven (7) chacha20-poly1305 ciphers that can be used with TLS and DTLS. This is the “how to do chacha20-poly1305 with TLS†draft, where chacha20-poly1305 is defined in RFC 7539. These cipher suites are intended to be a back up to the AES-based suites in case of compromise. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Stephen Farrell is the responsible Area Director. 2. Review and Consensus There’s probably on the order of 100 messages about this draft, and that shouldn’t come as a surprise because this draft is really just specifying IANA code points. The real fireworks were on the CFRG list, and we thank them for taking that bullet(s). The cipher suites proposed in the individual draft were modified based on WG input. There were two WGLCs for this draft; the first didn’t generate the expected amount of review so a second WGLC was issued that did. There was a debate as to whether the PRF digest should be changed to SHA-512 from SHA-256, but there was no consensus to make this change. 3. Intellectual Property All disclosed as confirmed by the authors on 20160310. 4. Other Points: IANA has already assigned the cipher suites and we thank them. These algorithms are expected to be very widely implemented due their high performance in software implementations. It’s currently in the deployed branches of BoringSSL GnuTLS, OpenSSL, and others. RFC Editor Note 1) Please add the following to the end of the abstract: "This document updates RFCs 5246 and 6347." 2) Please add a normative reference for SHA256 at the end of section 3, thusly... OLD: The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 as the hash function. NEW: The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 [FIPS 180-4] as the hash function. The reference to add to section 6.1 is: [FIPS 180-4] Federal Information Processing Standards Publication (FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015. From nobody Tue May 10 06:51: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 73C2A12D17C; Tue, 10 May 2016 06:51: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 aqH0RdamyIjQ; Tue, 10 May 2016 06:51: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 1D57D12D6CA; Tue, 10 May 2016 06:51:02 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id f66so16500138vkh.2; Tue, 10 May 2016 06:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=COeMMyxZK6xzlu68oedZBuY8Hyv0oBCVpPj0VK8E3CI=; b=V+eOgSuwvtQLwaHDpkUBVii8AlNFqLO/RV6BDfBcMjmJxEL+7E8KbaFVTi+NkfWyfJ xOREEuJ36C0/5KHwtSUPICoiR7ThZfCTNONPuT7elJA7sizk1nGJ3NostlIu0sBw/TzA GSOgA4R7CVKXF21yFGlSu6C3cHCEKdfxpl9wR7xIpukWi94yHWAaItO/7/bOi6stbe6y cqid32csIBFqGoKSwdExh230ziT0OWBf3TH09yL5CuoHYQU97kTZyO+2KMZgEX7VULSt XEWfJZFzpZGSf5Gz+mOkLduZh5lcV3adlqvOB3nbujA59E0PbS8k+DZuImURMs1BoQLu aIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=COeMMyxZK6xzlu68oedZBuY8Hyv0oBCVpPj0VK8E3CI=; b=N3QalvnWs5QZ/qzj6Plhgvx1nKUy+t9PuMEPxeqBK0A9Pok7UnGwbiSskWgRpZ+7d4 4pez+Z05jgH4Kj/JVWPkrNgAC3XSzTwkmIawOfFK/S0TpA1DGCcJE3hYXI47XG/1Pn3l 5f8A+dV9CUphFkPRPsYr/jA2WjrCYog7FB6sCWosMNZo7giMEoMFHvRxt/kq0f1HrnPj 4cndC0mO959ufiRliwCFj5e5tZlUMKqXeEB/PdjwLJUEmYvUmKCiODPp+Us9tnVYMczJ DG7B/hOmqp6PEb1VKsle//ptNWHWTam2ExnYmMCgKHQU5b5g51s/yR7x5TzHaGDq8pqb GOgw== X-Gm-Message-State: AOPr4FXzfSj3EWwas+Yk1W2fOQyLMIgVgOX3vwBf7jtWEbo2dL5ZvnhN0IBdNKbGlAZw8CUklDEDWPaiA4Pckw== MIME-Version: 1.0 X-Received: by 10.31.98.135 with SMTP id w129mr8793192vkb.106.1462888261130; Tue, 10 May 2016 06:51:01 -0700 (PDT) Received: by 10.31.98.195 with HTTP; Tue, 10 May 2016 06:51:01 -0700 (PDT) Date: Tue, 10 May 2016 15:51:01 +0200 Message-ID: From: Naeem Khademi To: Uta@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c094e6826a71505327d37f3 Archived-At: Cc: taps@ietf.org Subject: [TLS] Minimal API for the basic (D)TLS operation? (concerns draft-ietf-taps-transports-usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 13:51:10 -0000 --94eb2c094e6826a71505327d37f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I am writing this as one of the authors of the draft-ietf-taps-transports-usage and as a result of our WG discussions during the TAPS meeting in Buenos Aires. This draft tries to derive a list of transport service features and primitives (function-calls) provided by the transport protocols to the application. This is an initial milestone for building a TAPS system. It proposes a 3-pass process as a systematic way to derive the primitives and transport service features based on the IETF-based (abstract) APIs of transport protocols that are currently covered by the draft. - The draft can be found here (currently covering TCP and SCTP only): https://tools.ietf.org/html/draft-ietf-taps-transports-usage-00 - A companion draft covering UDP/UDP-Lite (to be merged with above draft eventually): https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-01 The WG=E2=80=99s plan is to have (D)TLS included, initially as an independe= nt draft which applies the same exact process (Appendix B of draft-ietf-taps-transports-usage-00) and eventually merging into our draft as it matures. However we have some questions with regards to this: *A) Is there a definition of minimal API available that covers the basic operation? B) If not, is there enough energy in the WG(s) (UTA, TLS) to define such an API? * To clarify: we would like to make our lives easier by being able to just say that (D)TLS can run OVER our TAPS system - but then it may make sense to layer (D)TLS under a transport that we would base the TAPS system on, so this is why things get a bit more complicated here. Cheers, Naeem --94eb2c094e6826a71505327d37f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

I am writing this as one = of the authors of the draft-ietf-taps-transports-usage and as a result of o= ur WG discussions during the TAPS meeting in Buenos Aires. This draft tries= to derive a list of transport service features and primitives (function-ca= lls) provided by the transport protocols to the application. This is an ini= tial milestone for building a TAPS system. It proposes a 3-pass process as = a systematic way to derive the primitives and transport service features ba= sed on the IETF-based (abstract) APIs of transport protocols that are curre= ntly covered by the draft.=C2=A0
The WG=E2=80=99s plan is to have (D)TLS included, initial= ly as an independent draft which applies the same exact process (Appendix B= of draft-ietf-taps-transports-usage-00) and eventually merging into our dr= aft as it matures. However we have some questions with regards to this:=C2= =A0

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px">A) Is = there a definition of minimal API available that covers the basic ope= ration?=C2=A0

B) If not, is there enough energy in the WG(s) (UTA, TLS) to define= such an API?=C2=A0

To clarify: we would like to make our lives easier by being able= to just say that (D)TLS can run OVER our TAPS system - but then it may mak= e sense to layer (D)TLS under a transport that we would base the TAPS syste= m on, so this is why things get a bit more complicated here.

Cheers,
Naeem
--94eb2c094e6826a71505327d37f3-- From nobody Tue May 10 09:01: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 7D31712D52A for ; Tue, 10 May 2016 09:01:01 -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, RCVD_IN_MSPIKE_H2=-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 yj2CXFFVDsAH for ; Tue, 10 May 2016 09:00:59 -0700 (PDT) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEB912D4FD for ; Tue, 10 May 2016 09:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462896028; bh=yuLjKSWmnEB3CiysM6u2Q21AILcZv2+eplrf2YvnT58=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=HtR/hmYhftlTqyY6IKHTSajHOPicD0mjm5UBsGOhHrmIpuYOLiszFmMFihX58n1AX5pAq1bxnp+/Qg5fnnvTa4dfJkpdatkrjxcM+eqs/4bEm7Vk8MKHNOTfhGlps6yw8J8B2f+2zZaYfG9vvwsgjjlvqC7m4uCzHog1PXKTGUfyDfWTcecJ4XRFjJxPG1o1PK3/MxP0Q4FlzFeUuRzZP4jXq/HXS/JaVif7uGlwdiE4aNiIkDuDcNdG1VGwv56gQ09X/pZLzSN9ocDWJjEdsNBIwSULUhzqeWRKQIO6pgZ6mVN1tb1ffwcQ+juZEumpI1lqEpikvjjRkEtZOpvslw== Received: from [98.138.100.115] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2016 16:00:28 -0000 Received: from [98.138.87.8] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 10 May 2016 16:00:28 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 10 May 2016 16:00:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 87857.60407.bm@omp1008.mail.ne1.yahoo.com X-YMail-OSG: 6CpocEUVM1mAMMRX3.b7b5l37tmcFNscrb_pZ_vCX9diFS8FtYICGeWMkRtFKp2 dZd7u5y_nkTHLhlaDFABlq6H33uK91Nr5h0plOOub.1_nc5SSC2iK5e1E5d_ZapzmoJbcsjOvigh qB0eLJYAanwlaJzrqe5gORGPGkwulUN_qMafsoKaY4ypv6H_82XYlgbXgzzAYOfBH4UYOgxSeWdD IWA5z8ZhaaV_pXscHLbv3TX0D4uj6_oWS8e48YagGraNF1_Gn5aXTz3AD2ETLk3RDqHB1f8JT8.y KpZFCaTY65bUBslWrMibz.NELxhitDwvrjFUsnbHT6ncYAlwwOgImB_M4akzLFkMnqQzxk6WaXQU Z7CY603sURHVtanhCWIVGHu3COBs6b8V80huyGhqSNXtBOk3FOMvMTCnIJfionNCH6WHx1h_u_TA 6Bjk6YEVAJ_F0sZIA_Nr7x5om29w2ac9xfEpK66XtNqAN_wacjL6Iq.9MWFvnSv4zrSTbjLIY2ER 9imDk80lxCSidGfSE9P64T3oM_.wecMbKBplGNjw9I6LA3kMOKReH3IBYg8Yb2fmvUrXUTiU- Received: from jws10036.mail.ne1.yahoo.com by sendmailws162.mail.ne1.yahoo.com; Tue, 10 May 2016 16:00:27 +0000; 1462896027.620 Date: Tue, 10 May 2016 16:00:27 +0000 (UTC) From: To: Tls Message-ID: <886089111.1623873.1462896027238.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1459732673.1664099.1462895921403.JavaMail.yahoo@mail.yahoo.com> References: <1459732673.1664099.1462895921403.JavaMail.yahoo.ref@mail.yahoo.com> <1459732673.1664099.1462895921403.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1623872_593345573.1462896027235" Archived-At: Cc: Martin Thomson , Christian O'Flaherty Subject: [TLS] Volunteers to Alpha Test Wireshark Dissector for (D)TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:01:01 -0000 ------=_Part_1623872_593345573.1462896027235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, I have modified the Wireshark dissectors for TLS and DTLS to recognize and = parse a fair amount of (D)TLS1.3 traffic. I took a debug trace that Martin Thomson gave me with (D)TLS1.3 payload dat= a only & created PCAP traces with fake IP and TCP/UDP headers so that I cou= ld have something to dissect. I think I am ready for some other people to l= ook at this, if they would like to next week. =C2=A0Would love to have you = guys let me know what you think of the decoding & if anything should be cha= nged. Also, if anyone else has PCAP files with (D)TLS1.3, that will be wonderful.= =C2=A0I have only two trace files! =C2=A0 Down the road, I would like to h= ave quite a few that are set up. =C2=A0If you even have debug output with p= ayload, I can use that. =C2=A0But, it has to be what actually is sent on th= e wire. =C2=A0(Pls let me know if questions.) We have set up a server that we will make available to the entire TLS group= once the bugs are shaken out. =C2=A0We will put the various traces on that= server so that people can see actual packet traffic. =C2=A0We will also mo= dify the dissectors as needed as the spec finalizes. What I have done for both TLS and DTLS:=C2=A0 - Client Hello should be good (including Random bytes decoding) - Server Hello should be good (including Random bytes decoding) - New Key Share extension added - New PSK extension added- New Version Negotiation extension added- New cip= her suites added - New alert types added What is left to be done: - Bug Martin found in TLS1.2 and before for Server Key Share - I think there may be some problems with some DTLS packets. =C2=A0Could us= e some help in figuring out exactly what.=C2=A0 Please let me know unicast if you would like to help. =C2=A0I am thinking 3= or 4 people will be good. =C2=A0The Alpha testing will start Wed. May 18th= .=C2=A0 Please let me know if you want some screen shots of a TLS1.3 Client Hello /= Server Hello. =C2=A0I am not able to attach to email.=C2=A0 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ------=_Part_1623872_593345573.1462896027235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,


I have modified the Wireshark dissectors for TLS and DTL= S to recognize and parse a fair amount of (D)TLS1.3 traffic.

I took = a debug trace that Martin Thomson gave me with (D)TLS1.3 payload data only = & created PCAP traces with fake IP and TCP/UDP headers so that I could = have something to dissect. I think I am ready for some other people to look= at this, if they would like to next week.  Would love to have you guy= s let me know what you think of the decoding & if anything should be ch= anged.

Also, if anyone else has PCAP files with (D)TLS1.3, that will= be wonderful.  I have only two trace files!   Down the road, I w= ould like to have quite a few that are set up.  If you even have debug= output with payload, I can use that.  But, it has to be what actually= is sent on the wire.  (Pls let me know if questions.)

We have = set up a server that we will make available to the entire TLS group once th= e bugs are shaken out.  We will put the various traces on that server = so that people can see actual packet traffic.  We will also modify the= dissectors as needed as the spec finalizes.

What I have done for bo= th TLS and DTLS: 

- Client Hello should be good (including Rand= om bytes decoding)
- Server Hello should be good (including Random bytes= decoding)
- New Key Share extension added
- New PSK extension added
- New Version Negoti= ation extension added
- New cipher suites added
- New alert types a= dded

What is left to be done:

- Bug Martin found in TLS1.2 an= d before for Server Key Share
- I think there may be some problems with some DTLS pac= kets.  Could use some help in figuring out exactly what. 

Please let me know= unicast if you would like to help.  I am thinking 3 or 4 people will = be good.  The Alpha testing will start Wed. May 18th. 

Please let me know if you want som= e screen shots of a TLS1.3 Client Hello / Server Hello.  I am not able= to attach to email.
 
Thanks,

Nalini Elkins
= Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


------=_Part_1623872_593345573.1462896027235-- From nobody Wed May 11 04:38: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 86B0F12D9E7 for ; Wed, 11 May 2016 04:38:20 -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 Dj0flv7w1Ujn for ; Wed, 11 May 2016 04:38:18 -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 DC0AF12D9F6 for ; Wed, 11 May 2016 04:36:53 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g133so39408054ywb.2 for ; Wed, 11 May 2016 04:36: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=B1sigkVen/E8vO3DrPSm0eI9k5AjD3ZVue/hTVQt6ZI=; b=U7lJYkbJl8ZkFRmlPQfTTUrcQKnV1lRkZkTtUrPVTHH0vmwt4u8PzOD7g4O9W3dxWa +sXN3VHrEZAXctCcz0yQaYoaiWieLwrEVzbs2eT2cI3r1uq7Enm1E+eAt0fm/zcOyYcH uZ7nSD4/0jk3jajmI31u9IkBGJErJAr2cVMjpBpFIZJxrY+1CQ9GKeVb+G58JPa6nUkZ 4ll6Wp2BObI1aLWZPuEXbcevDF6zfN0gQCHo9aPZMWybD1EWm2FYz3D6N7J+4r3ZcWpi 1E3CczRvgR7aRrnls2ozcUC7gPC9hvUTNNictqOZI9nzu40hj4jmKFZnKwtioGuneyqa jFVw== 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=B1sigkVen/E8vO3DrPSm0eI9k5AjD3ZVue/hTVQt6ZI=; b=CbY0DFOycYESY/RX0A+rX8u4K6IU64ik5J6e26UiXpa7ITb0t0rQG6eT5I7Qe34dbB cU9QxRNj4TJsSs6fAqovbPU7glRFU65lkdVEddYGymxDlhAX6XpBBZPa5Uh5de+Yy6zv L7NuS/POV06OHyAfo6JQeJlHgWDe0zP3wxR9ip4sZrZXeXwNyaMtk7c/p5uepDQaHIh5 iwGNbiy0hyo1OVApzNKUZzbLzkNfQ3wuQ6LIkb+eBPc5R3FvTGWEHOIqj49gTAn98pSp /4YFpXmmzLUa0kxpFyKthhaee9StoyoHLnGPoiqJN2kqIvf6w1sCp3r+hxcJbnDUtEY+ BCMQ== X-Gm-Message-State: AOPr4FUH+EJyJYIOPRecM10+2SU2PuAFPhSby8B+zBbTmR/rkWlKjQ0AHd6xc9vwVIODykL+J8BFm5QN01zXvA== X-Received: by 10.129.46.193 with SMTP id u184mr1224714ywu.180.1462966613192; Wed, 11 May 2016 04:36:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Wed, 11 May 2016 04:36:13 -0700 (PDT) From: Eric Rescorla Date: Wed, 11 May 2016 13:36:13 +0200 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11408a1c4c687d05328f759c Archived-At: Subject: [TLS] PR#449 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 11:38:20 -0000 --001a11408a1c4c687d05328f759c Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/449 In Buenos Aires, we agreed to add EncryptedExtensions from the client in 0-RTT to carry the ticket age/elapsed_time. I have written this up in the PR above. Comments welcome. Target Merge date: Friday. -Ekr --001a11408a1c4c687d05328f759c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In Buenos Aires, we agreed to add EncryptedExtensions from the clien= t
in 0-RTT to carry the ticket age/elapsed_time. I have written t= his up in
the PR above. Comments welcome.

Target Merge date: Friday.

-Ekr

--001a11408a1c4c687d05328f759c-- From nobody Wed May 11 11:26:59 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 D72BD12D581; Wed, 11 May 2016 11:26:57 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511182657.15211.66298.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 11:26:57 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-23.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: Wed, 11 May 2016 18:26:58 -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 : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-23.txt Pages : 17 Date : 2016-05-11 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-cached-info-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-23 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 Wed May 11 11:33: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 C5EA112D733 for ; Wed, 11 May 2016 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 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=-0.996, 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 EIe-s8hWY0gH for ; Wed, 11 May 2016 11:33:20 -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 712E812D730 for ; Wed, 11 May 2016 11:33:19 -0700 (PDT) Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MRB8F-1bBjCG3uuN-00UZNO for ; Wed, 11 May 2016 20:33:16 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57337AEA.2020202@gmx.net> Date: Wed, 11 May 2016 20:33:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O11U0JAHbepQQtWP2EPosgXTBBvP6hIoD" X-Provags-ID: V03:K0:Mt50WVTGSVslLZXeNMZhXxs9uupf5MaHQVdVJzSVXyyTedywwnT LVjbmf8xP8hdLUgFEb4ZsiRu1Ri5oDZgIBoBIA2kozKDdnMOcp9RKI8vI0n6+4neTsJ8uv+ gYbRpi2ALCaUWXdqmrqxmfWxRQj6Cls7GJwr9WXaaxWtgoR+wkAyq8UuemHbWhw/r+mnodw GAAYPSTWdawzaGxi337nQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:dKfXT7yJMdo=:5dBcekV7xHHA5fgKGna6Mp EXo0n6I71f9PJ+A48DGDikCvjkouhz2ClPrXp6EYOlQCNJEd32BPJu9wmyLblcIBqU9WyU4sl pWyE8ur1Lvwlr/Js+dk1vV+C894Mw3XrS9HJmgwcCdToSSLgbCkGooHk8F3WyR/MsEzNNxPoO gQu2W5AX8N540PoMEprlqvyOgAdHr1TfTWQoDCDEudbBWJWunPDc7/i1KaYUJMR2FHTSBECyG 1ATJCLRLY+xzjWZa1tw5IX7SYIzemct6YaQpDqs7Hi7IG8g4/zrK3ecJNVG6IZozvcG9WNffn LruZMOjYrsMu0La0L7nnE50KVokgwjy/6+QlgamMOvoWJV1V4M/0D3iWdGzZfAwZlp7+q1rmK FsDMNrfGXGaF+0RezPzf8dWyYGMIfKsIwiaWcUlINliqex3wtgrGXLNBajmUrU3zevot94tMq VoOsoKqW68BEuPS3Cc8ckPJ/6WT2lfS1isldKEvwH+N1OETVWXML9tHu9aTXqZt8+952kZSCU 7yJCXw5cltkhpTQLFK7ns/6hpD7i8qoXUBbv84TfChNYqfIw78GjUVRvKca2UMlK2q3Fv+cHV ZyuMNglhhNYX5Szjqi3PL1fj4vwgE9vTJoNv2ef6U0kUOR0V8x5vLQJTcgp3HeOF5kbWFdc/f l+U3GW+DgVvVAsxD3Od+8hDX8FQeKW2g6tOi9pUz/J2RvzHc94JHFKkKZQs6aLd7lM/pJDLmO dfUdkqQFELwFHS280T/iAMpdMx5sdcAv1Ey6o8PNPsTH7fVwaR3FWmsmsZY= Archived-At: Subject: [TLS] Updated TLS Cached Info Document X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 18:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O11U0JAHbepQQtWP2EPosgXTBBvP6hIoD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all I have just posted an updated version of the TLS Cached Info document reflecting the discussions from the last IETF meeting (and the feedback received from Karthik before) regarding the size of the fingerprint. The fingerprint is not truncated anymore, which reflects what we had in an earlier version of the document. Here is the document: https://tools.ietf.org/html/draft-ietf-tls-cached-info-23 Ciao Hannes --O11U0JAHbepQQtWP2EPosgXTBBvP6hIoD 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 iQEcBAEBCgAGBQJXM3rrAAoJEGhJURNOOiAtlmcH/iVrkle6Re8+qS/vZ5T5fMSq ePEXmch+joPPY1Ne7b2Z39goneXWZtlo/riMYzKkm7ma2Hi8geM8UjhE3bI+0VR2 71bvao9Jqp1q4BbdlhP83NEz55/16HjD36/qEcFqHW4tdh+I56BF6DHQKmB54IdF Cb61VNWjftjm7GCTmVvUsaF5dMuDJe4ep5bR0Ok/T979HGIw74mgwPwa06S9H2ss H8AGyn+cFR9R2JFI4AO9yUXX+MBoCfwJMP60cYz2w1d3NEKueMgwWc9zHn5HaCt7 3GKLIuPXLOVfh3rQM5NlO+NvVZohJVpEKaii7PgAJ5HyI8L4yiU0n+nDsMmhJ3U= =kTAM -----END PGP SIGNATURE----- --O11U0JAHbepQQtWP2EPosgXTBBvP6hIoD-- From nobody Wed May 11 12:22: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 1500312D58B for ; Wed, 11 May 2016 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 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=-0.996, 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=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 RzMwcNfFjjci for ; Wed, 11 May 2016 12:21:57 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 A316012D767 for ; Wed, 11 May 2016 12:21:57 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id u5so24061012igk.1 for ; Wed, 11 May 2016 12:21:57 -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=H6+j3F+q2lNfornlsNXFcvRdet7UadldujCrFO4EJdI=; b=a4YsItztBjil+dtZXcmXyncKMX3MUS5d4zYF3kMWgt8IQ1UG3xejezewPstcc/K/GJ XvbQkxN3HKBv/mkH0H8ZuhUFPseqiCo2qhluHYUSkOvpl95hVvevhA9mACv9dnVlmwwz xMi0KQAyfc01BIw0kjcOaHGZv3MCV665foc8c= 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=H6+j3F+q2lNfornlsNXFcvRdet7UadldujCrFO4EJdI=; b=cG8MTSnt/XW3Dy4/XE96KaUh0NVWw6wTBvKL51K/SFqXaeGi3HyDCE5BkLeDUAnNtv B6TkOCDLHamMTc7d9tmcyTYn0VFC2OReqjPBl4YPdcdpIsLGy3fvoE8H3LvzBQgdpdO4 kCyztVs/9TK9BDvdSD3jzpBQyQOYXzdvMJ4KuKU1yaRkO96Vj57rxbccy4zouKGr2xmI nqnbn00v5J1EOAOKKDa3I6EB4sPbWCVkczyeH01hRGC40DPicJxQEQDlicF/4O9IMNrX CSoYsETonl985/9/KtFuRABp2WOAcDRmhDLCJTo38FNp+drzTfLDqmJXUC5lgKq4JBXx 4mYw== X-Gm-Message-State: AOPr4FXeL19gZn0FRXlTzMOypzPQxD2lvi/6I87HZz3QqLYQDCR0NZiRk3kQCV+dCfo0Ol/Qbn4xery7bT9JVumk X-Received: by 10.50.18.132 with SMTP id w4mr4866187igd.83.1462994516881; Wed, 11 May 2016 12:21:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 11 May 2016 19:21:46 +0000 Message-ID: To: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=14dae93b57d27d21c3053295f4a6 Archived-At: Subject: Re: [TLS] PR#449 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:22:01 -0000 --14dae93b57d27d21c3053295f4a6 Content-Type: text/plain; charset=UTF-8 This change has a non-obvious consequence for server implementation complexity. I don't have an especially good alternate proposal though. Putting ticket_age in EncryptedExtensions means there are two ways a server may reject 0-RTT. It might reject ClientHello because the ticket is invalid (or if ALPN doesn't match the client and server's new preferences, etc.), or it might reject at EncryptedExtensions because the ticket_age is bad. But rejecting at the second point requires going back to the ClientHello and re-negotiating parameters, etc., as in a full handshake. This is a fairly involved part of the handshake and adding a state machine transition (TLS stacks often look like asynchronous state machines driven by handshake messages) in the middle of it invites a lot of bugs. Options I see: 1. Leave it as-is and implementations just deal with it. The simplest way out would be to buffer and defer processing the ClientHello until after EncryptedExtensions (or lack thereof) is known. Note this is a little subtle because you may not have a ticket to decrypt EncryptedExtensions. 2. A bad ticket_age is a fatal error, not a 0-RTT reject. This requires that the server timeout be fairly generous to avoid the slowest RTT anyone might care about. Roughly match the timeout for the client's second leg. But if the client's clock changes between getting the ticket and trying 0-RTT, we'd punish them with connection error rather than a full handshake. That seems poor. 3. Smuggle an encrypted ticket_age inside the ClientHello. This means avoids the complex framing, but now we need some ad-hoc encryption inside an extension. It needn't be very complicated, but it's a wart. (Silliest option is NewSessionTicket contains 4 random bytes or you derive something from the resumption secret and XOR it into the data since this is something we were otherwise okay with sending in the clear anyway. It's just about avoiding a vague correlator when tickets are only used once. Or we could do something less silly and more heavyweight like actually run the record layer.) I'm not thrilled about #2 or #3 and getting #1 right isn't impossible, but it would be nice to avoid these sorts of sharp edges if we can. David On Wed, May 11, 2016 at 7:38 AM Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/449 > > In Buenos Aires, we agreed to add EncryptedExtensions from the client > in 0-RTT to carry the ticket age/elapsed_time. I have written this up in > the PR above. Comments welcome. > > Target Merge date: Friday. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --14dae93b57d27d21c3053295f4a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This change has a non-obvious consequence for server = implementation complexity. I don't have an especially good alternate pr= oposal though.

Putting ticket_age in EncryptedExte= nsions means there are two ways a server may reject 0-RTT. It might reject = ClientHello because the ticket is invalid (or if ALPN doesn't match the= client and server's new preferences, etc.), or it might reject at Encr= yptedExtensions because the ticket_age is bad.

But= rejecting at the second point requires going back to the ClientHello and r= e-negotiating parameters, etc., as in a full handshake. This is a fairly in= volved part of the handshake and adding a state machine transition (TLS sta= cks often look like asynchronous state machines driven by handshake message= s) in the middle of it invites a lot of bugs.

Opti= ons I see:

1. Leave it as-is and implementations j= ust deal with it. The simplest way out would be to buffer and defer process= ing the ClientHello until after EncryptedExtensions (or lack thereof) is kn= own. Note this is a little subtle because you may not have a ticket to decr= ypt EncryptedExtensions.

2. A bad ticket_age is a = fatal error, not a 0-RTT reject. This requires that the server timeout be f= airly generous to avoid the slowest RTT anyone might care about. Roughly ma= tch the timeout for the client's second leg. But if the client's cl= ock changes between getting the ticket and trying 0-RTT, we'd punish th= em with connection error rather than a full handshake. That seems poor.

3. Smuggle an encrypted ticket_age inside the ClientH= ello. This means avoids the complex framing, but now we need some ad-hoc en= cryption inside an extension. It needn't be very complicated, but it= 9;s a wart. (Silliest option is NewSessionTicket contains 4 random bytes or= you derive something from the resumption secret and XOR it into the data s= ince this is something we were otherwise okay with sending in the clear any= way. It's just about avoiding a vague correlator when tickets are only = used once. Or we could do something less silly and more heavyweight like ac= tually run the record layer.)

I'm not thrilled= about #2 or #3 and getting #1 right isn't impossible, but it would be = nice to avoid these sorts of sharp edges if we can.

David

On Wed, May 11= , 2016 at 7:38 AM Eric Rescorla <ekr@rtf= m.com> wrote:

=
In Buenos Aires, we agreed to add EncryptedExtensions from the c= lient
in 0-RTT to carry the ticket age/elapsed_time. I have writt= en this up in
the PR above. Comments welcome.

Target Merge date: Friday.

-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--14dae93b57d27d21c3053295f4a6-- From nobody Wed May 11 13:45: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 E9E1212D7FE for ; Wed, 11 May 2016 13:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.695 X-Spam-Level: X-Spam-Status: No, score=-3.695 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=-0.996, 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 6IWuNVJ3qcRO for ; Wed, 11 May 2016 13:44:58 -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 BECC712D5C0 for ; Wed, 11 May 2016 13:44:58 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 190so70253034iow.1 for ; Wed, 11 May 2016 13:44:58 -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=/P7WDR+722Rs+VGZp/ToRZOS30RBgsjo6P+o7hZdcy0=; b=aGczyjPHk4iFdM2iozdoYyhgeAc4uOsRGeAteAhFolwzUfCPs+Qt0ZzMUJIOTupIEC QwrHN1LENxvcVXl8KDAV0xxPTzAp70EK8LdMR8MUEzJOXKhCceJHDYti6dhGV+o2s1SX Nb76tRiGEASwNkNfJmBxG7IFYCXqOq8PPNBt0= 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=/P7WDR+722Rs+VGZp/ToRZOS30RBgsjo6P+o7hZdcy0=; b=a00b7nsrh9sRym0QD4fG0/YrF7zWyrSyeLEb5thNfUKA+SqUWN/5GW8ABilDngxnNb ddEQkF9ED693FusJ/4wMMwnuJdCqOKtfJ9XO+DIanR5j56jLnxjob2p74I1ZbRnHshHk /NLp6zXZoQ2rM9Xu/l84hLV5I3ZeESA+szwTGViApR5kBze5Xg9YGhUS6kPfPUBev99a 6sgHrCnF9zwLjV6uLXgsnhx1W9sMNv6ugOLgyOA9JBk6rEcES1EOZ5rueLtyD1d/2c97 gBK7Xc+AAvn2vZEl5CcDUXhWx3w013UgrqWHwON2X6pabXs+H+jMvaqVWI8JjqRPsIHn fJiQ== X-Gm-Message-State: AOPr4FVjZI9OjNiObf8z52CFj1wt443ZlDi79FCnvLYMNL3ZY79Yftk2qpIzHBeBkXcz4l+L8eoZzza13dsKnAfj X-Received: by 10.36.11.84 with SMTP id 81mr6531857itd.76.1462999498014; Wed, 11 May 2016 13:44:58 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Wed, 11 May 2016 20:44:47 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140c338630a730532971d73 Archived-At: Subject: [TLS] In-handshake CertificateRequest and 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: Wed, 11 May 2016 20:45:01 -0000 --001a1140c338630a730532971d73 Content-Type: text/plain; charset=UTF-8 The 0-RTT handshake originally had two places with a client Certificate + CertificateVerify: in the 0-RTT flow and in the second Finished block in response to a server CertificateRequest. We've dropped the first now. I propose we drop the second too. Client auth with 0-RTT is solely carried over via resumption. (I mentioned this previously, but with 0-RTT looking closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the case is clearer.) This makes 6.2.3 more consistent with 6.2.2 where neither side authenticates in a resumption handshake. 0-RTT is much more similar to resumption with most parameters carrying over anyway. 1-RTT client auth in a 0-RTT handshake also invites more of the retroactive auth confusion as with post-handshake auth. The client stream switches from unauthenticated to authenticated. I believe this was one of the reasons we agreed at IETF 95 to discourage/forbid (not sure which) sending 0.5-RTT data following a CertificateRequest. In-handshake CertificateRequest either requires this discouraged situation or accepting 0-RTT data without sending 0.5-RTT data, which is largely pointless. We accepted the retroactive auth issue in post-handshake auth, but I think we should limit it to that. For implementations, BoringSSL made accepting renego an opt-in feature. I expect we'd do the same for post-handshake auth. For specs, one might specify that post-handshake authentication is forbidden. HTTP/2 did this for renegotiation. I haven't been following the HTTP/2 client cert saga as closely, but draft-thomson-http2-client-certs-02 is the current plan, right? If so, HTTP/2 should forbid TLS-level post-handshake auth too. In both cases, excluding post-handshake auth should exclude any transition from unauthenticated to authenticated in the stream. Instead, if you want to change authentication state, send a post-handshake CertificateRequest, as you would have normally. David --001a1140c338630a730532971d73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The 0-RTT handshake originally had two places with a clien= t Certificate=C2=A0+ CertificateVerify: in the 0-RTT flow and in the second= Finished block in response to a server CertificateRequest.=C2=A0We've dropped the first now. I propose we drop th= e second too. Client auth with 0-RTT is solely carried over via resumption.= (I mentioned this previously, but with 0-RTT looking closer to resumption = and the IETF 95 decision on 0.5-RTT data, I think the case is clearer.)

This makes 6.2.3 more consistent with 6.2.2 where neit= her side authenticates in a resumption handshake. 0-RTT is much more simila= r to resumption with most parameters carrying over anyway.

1-RTT client auth in= a 0-RTT handshake also invites more of the retroactive auth confusion as w= ith post-handshake auth. The client stream switches from unauthenticated to= authenticated.=C2=A0I believe this was one= of the reasons we agreed at IETF 95 to discourage/forbid (not sure which) = sending 0.5-RTT data following a CertificateRequest. In-handshake Certifica= teRequest either requires this discouraged situation or accepting 0-RTT dat= a without sending 0.5-RTT data, which is largely pointless.

We accepted the retroactiv= e auth issue in post-handshake auth, but I think we should limit it to that= . For implementations, BoringSSL mad= e accepting renego an opt-in feature. I expect we'd do the same for pos= t-handshake auth.=C2=A0For specs, on= e might specify that post-handshake authentication is forbidden. HTTP/2 did= this for renegotiation.=C2=A0I haven't been following the HTTP/= 2 client cert saga as closely, but draft-thomson-http2-client-certs-02 is t= he current plan, right? If so, HTTP/2 should forbid TLS-level post-handshak= e auth too.

In both cases, excluding post-handshake au= th should exclude any transition from unauthenticated to authenticated in t= he stream. Instead, if you want to change authentication state, send a post= -handshake CertificateRequest, as you would have normally.

David
--001a1140c338630a730532971d73-- From nobody Wed May 11 18:25: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 CC16B12D1A5 for ; Wed, 11 May 2016 18:25:35 -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 Qjf3ck9ziNF5 for ; Wed, 11 May 2016 18:25:34 -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 D811712D0A5 for ; Wed, 11 May 2016 18:25:33 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id d62so77061968iof.2 for ; Wed, 11 May 2016 18:25:33 -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=wNpotMAZ6oWGAsoM/YkbkF22iPrxQStMdKyLiqyh7TA=; b=KYxCd5E4W0znJjvLXzooebcVUgolu5w6q57ky1Kgk8dhES08MiIuXgaZFsoCLOKWeN w1OTt/a1JU7wY8njimz5/Rk0n505GzWt4uaMvf32ZfexY9DccvGnSaxhUbbc2pyxfnRx GQhrsGauz9wN4uZjM8qckm8En5Yr+1zjN+ygr7q+/aBHkpmksJUUK7RU1ZKaIaPcBhSb xQTDoBH3SL+H0MCRzBlKkTYyd7x30iJfgh5scUIZ/tmWRQX9kM6mDj4F0jeM/14N/urV Ozj11qDZpAi6gpi7j+2n6wxym7xD+zQCCF/wmDMIar0PJ2R/dwNYBMEQ84QzjQIsTp8U AAHQ== 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=wNpotMAZ6oWGAsoM/YkbkF22iPrxQStMdKyLiqyh7TA=; b=BeKegKZOZSrifK4V7h8YYdpWHDbgTs0u8aTap5mG7yMa/+zIz2/mvj+ZVsV3lZrc+g PNWLss/Y6mWSZf+zLwKREKWJMn3X27hq18BUQGLzWoJJjm3Ehp0oZ61xU0HJvPvtuqB2 lVbFXEmSbvpuPMbzsREzJ/VgsGxKt2mgiuNw9MF+cjlSTIDqklk0DO/3yA43unnx4tuf RgQkhPsChxL0p5zlKdh9HSpnRe7gBAAoHFsemINFbQGqmJ6Te6MKJVJvz5UKsymTB3/U czszfEgY/QanTLE3tKDnt21OiYozMXcsazej+hLb3W3722uU4myF3pn1DoY7w0P3EPRo nvZw== X-Gm-Message-State: AOPr4FXZu/IXSpBNvGT4MCx2x9YhaXNyw9olyVCZmOYGJB9ZrS3hklk3ezNo0Xc/MImsfGDVDNI34ZdRf+BP3g== MIME-Version: 1.0 X-Received: by 10.107.136.76 with SMTP id k73mr5878769iod.100.1463016333183; Wed, 11 May 2016 18:25:33 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 11 May 2016 18:25:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 11:25:33 +1000 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 01:25:36 -0000 I think that this is a fine way to simplify, but I have a wrinkle to add. I would rather this be formulated as: a client cannot authenticate using Certificate[+Verify] unless the server does so first. The reason that I want that is this issue https://github.com/tlswg/tls13-spec/issues/443 I want to be able to do 0-RTT but have the server continue to prove that it has the private key (maybe some clients will do that occasionally). For those, I think that reciprocating is reasonable. It doesn't significantly change the state machine in that case. I hope to write a draft explaining this soon, so that folks can see what it costs/looks like. On 12 May 2016 at 06:44, David Benjamin wrote: > The 0-RTT handshake originally had two places with a client Certificate + > CertificateVerify: in the 0-RTT flow and in the second Finished block in > response to a server CertificateRequest. We've dropped the first now. I > propose we drop the second too. Client auth with 0-RTT is solely carried > over via resumption. (I mentioned this previously, but with 0-RTT looking > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the > case is clearer.) > We accepted the retroactive auth issue in post-handshake auth, but I think > we should limit it to that. For implementations, BoringSSL made accepting > renego an opt-in feature. I expect we'd do the same for post-handshake auth. I totally agree about the post-handshake stuff. I'm somewhat inclined to ask that it be made an extension so that you can cleanly opt out. > For specs, one might specify that post-handshake authentication is > forbidden. HTTP/2 did this for renegotiation. I haven't been following the > HTTP/2 client cert saga as closely, but draft-thomson-http2-client-certs-02 > is the current plan, right? If so, HTTP/2 should forbid TLS-level > post-handshake auth too. We're doubling down on that idea and considering allowing the server to authenticate too. See https://mikebishop.github.io/http2-client-certs/ (you might recognize some similarity to the SPDY CREDENTIAL frame if you squint hard enough). From nobody Wed May 11 19:39:48 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 E465A12D153; Wed, 11 May 2016 19:39:46 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512023946.15251.57807.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 19:39:46 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-falsestart-02.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: Thu, 12 May 2016 02:39:47 -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 : Transport Layer Security (TLS) False Start Authors : Adam Langley Nagendra Modadugu Bodo Moeller Filename : draft-ietf-tls-falsestart-02.txt Pages : 10 Date : 2016-05-11 Abstract: This document specifies an optional behavior of TLS client implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-falsestart-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-falsestart-02 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 Wed May 11 19:42: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 0362012D5BE for ; Wed, 11 May 2016 19:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.695 X-Spam-Level: X-Spam-Status: No, score=-3.695 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=-0.996, 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 F2G0H9IbT2y4 for ; Wed, 11 May 2016 19:42:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BBC12D177 for ; Wed, 11 May 2016 19:42:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id d62so78675844iof.2 for ; Wed, 11 May 2016 19:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LzrYhLZljvDNh1sbiHB6O9qX+A6aTHcAVW8ZmAp09xI=; b=cxnBm4sLR3u5qBLSPuXSjmCv7lj/R6cjZ+5Wpuf6ZsaHLnI3IeNBhDr3VqR6W7YKjZ OmfZYwQJU6MG1Suj2hxSydL7ZGi+fXbumtQtiK/NIY/PzmhJqVilD9bqBs1KeilGeN+o 3PHiBvE7tGXwvzmhtN0BFziJZl1t4OmGqTp4s= 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=LzrYhLZljvDNh1sbiHB6O9qX+A6aTHcAVW8ZmAp09xI=; b=NqcktOA63vv5Km2NvINvwC6uUHiZj+v2WmqwHeUSuqX1fL4Xlq+3he3ftS/ze1+uMa zbAcuaGRGh0BfqqFDhP3t3m/hFPAUPB3pm9JrbY5CcUK6Jql+eXL2NkkECpETHdOYwyj Xl9BHpwcch3lEMSh4ByVGOyDY3Y5yfuncv9KL+oKAbmV/U7Jn01d2QiawS8rnSJc8yBo CbsUhTEXmdtUtlh5zsbzN3ReorEwKMSh4nPMyzx6XysEhEF9mU4opMLcol6MlJFzuDJ2 YpA/5u/xAIHIyQFkhNPJmMnaZlldajxoHGuSnyjTaW9x5JMdeeFfgABY+9qASrzezmb/ ebVg== X-Gm-Message-State: AOPr4FUA018ti52eZM6yk1x9jWlz68/xbZzKcUJKc4iNX29ulbOYW5SNnoAngAWC3Em+ObtgaiOb6ci524T+aOIs X-Received: by 10.107.161.68 with SMTP id k65mr6488679ioe.110.1463020927850; Wed, 11 May 2016 19:42:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 12 May 2016 02:41:58 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140f96ab47e6605329c1a15 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 02:42:11 -0000 --001a1140f96ab47e6605329c1a15 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 9:25 PM Martin Thomson wrote: > I think that this is a fine way to simplify, but I have a wrinkle to add. > > I would rather this be formulated as: a client cannot authenticate > using Certificate[+Verify] unless the server does so first. > > The reason that I want that is this issue > https://github.com/tlswg/tls13-spec/issues/443 I want to be able to > do 0-RTT but have the server continue to prove that it has the private > key (maybe some clients will do that occasionally). For those, I > think that reciprocating is reasonable. It doesn't significantly > change the state machine in that case. > > I hope to write a draft explaining this soon, so that folks can see > what it costs/looks like. > Sure, if we end up doing something on the server, mirroring sounds reasonable enough. (This would just be for re-asserting the private key and not switching certificates, right?) > On 12 May 2016 at 06:44, David Benjamin wrote: > > The 0-RTT handshake originally had two places with a client Certificate + > > CertificateVerify: in the 0-RTT flow and in the second Finished block in > > response to a server CertificateRequest. We've dropped the first now. I > > propose we drop the second too. Client auth with 0-RTT is solely carried > > over via resumption. (I mentioned this previously, but with 0-RTT looking > > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think > the > > case is clearer.) > > > We accepted the retroactive auth issue in post-handshake auth, but I > think > > we should limit it to that. For implementations, BoringSSL made accepting > > renego an opt-in feature. I expect we'd do the same for post-handshake > auth. > > I totally agree about the post-handshake stuff. I'm somewhat inclined > to ask that it be made an extension so that you can cleanly opt out. > For HTTP, doing it in an extension the obvious way doesn't quite work. Whether Chrome is willing to do renego depends on how ALPN resolves (we leave it at its default off state and, after the initial handshake but before we could consume a HelloRequest, toggle it off). Supposing post-handshake auth is still used for HTTP/1.1 + TLS 1.3 (am I right that this is the plan?), we'd be in a similar situation. The ClientHello would say post-handshake auth is allowed, but we may end up in a state where it isn't anyway. (I think implicitness is fine, though an extension seem fine too. The application already gets to impose other restrictions on the use of TLS like "the first application data record should begin with G, E, T, space".) > > For specs, one might specify that post-handshake authentication is > > forbidden. HTTP/2 did this for renegotiation. I haven't been following > the > > HTTP/2 client cert saga as closely, but > draft-thomson-http2-client-certs-02 > > is the current plan, right? If so, HTTP/2 should forbid TLS-level > > post-handshake auth too. > > We're doubling down on that idea and considering allowing the server > to authenticate too. See > https://mikebishop.github.io/http2-client-certs/ (you might recognize > some similarity to the SPDY CREDENTIAL frame if you squint hard > enough). > --001a1140f96ab47e6605329c1a15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 11= , 2016 at 9:25 PM Martin Thomson <martin.thomson@gmail.com> wrote:
I think that this is a fine way to simplify, but I have a wrinkl= e to add.

I would rather this be formulated as: a client cannot authenticate
using Certificate[+Verify] unless the server does so first.
=C2=A0
The reason that I want that is this issue
https://github.com/tlswg/tls13-spec/issues/443=C2= =A0 I want to be able to
do 0-RTT but have the server continue to prove that it has the private
key (maybe some clients will do that occasionally).=C2=A0 For those, I
think that reciprocating is reasonable.=C2=A0 It doesn't significantly<= br> change the state machine in that case.

I hope to write a draft explaining this soon, so that folks can see
what it costs/looks like.

Sure, if we e= nd up doing something on the server, mirroring sounds reasonable enough. (T= his would just be for re-asserting the private key and not switching certif= icates, right?)
=C2=A0
On 12 May 2016 at 06:44, David Benjamin <davidben@chromium.org> wrote:
> The 0-RTT handshake originally had two places with a client Certificat= e +
> CertificateVerify: in the 0-RTT flow and in the second Finished block = in
> response to a server CertificateRequest. We've dropped the first n= ow. I
> propose we drop the second too. Client auth with 0-RTT is solely carri= ed
> over via resumption. (I mentioned this previously, but with 0-RTT look= ing
> closer to resumption and the IETF 95 decision on 0.5-RTT data, I think= the
> case is clearer.)

> We accepted the retroactive auth issue in post-handshake auth, but I t= hink
> we should limit it to that. For implementations, BoringSSL made accept= ing
> renego an opt-in feature. I expect we'd do the same for post-hands= hake auth.

I totally agree about the post-handshake stuff.=C2=A0 I'm somewhat incl= ined
to ask that it be made an extension so that you can cleanly opt out.

For HTTP, doing it in an extension the obviou= s way doesn't quite work. Whether Chrome is willing to do renego depend= s on how ALPN resolves (we leave it at its default off state and, after the= initial handshake but before we could consume a HelloRequest, toggle it of= f).

Supposing post-handshake auth is still used fo= r HTTP/1.1=C2=A0+ TLS 1.3 (am I right that this is the plan?), we'd be = in a similar situation. The ClientHello would say post-handshake auth is al= lowed, but we may end up in a state where it isn't anyway.
(I think implicitness is fine, though an extension seem fine t= oo. The application already gets to impose other restrictions on the use of= TLS like "the first application data record should begin with G, E, T= , space".)
=C2=A0
> For specs, one might specify that post-handshake authentication is
> forbidden. HTTP/2 did this for renegotiation. I haven't been follo= wing the
> HTTP/2 client cert saga as closely, but draft-thomson-http2-client-cer= ts-02
> is the current plan, right? If so, HTTP/2 should forbid TLS-level
> post-handshake auth too.

We're doubling down on that idea and considering allowing the server to authenticate too.=C2=A0 See
https://mikebishop.github.io/http2-client-certs/= =C2=A0 (you might recognize
some similarity to the SPDY CREDENTIAL frame if you squint hard
enough).

=C2=A0
--001a1140f96ab47e6605329c1a15-- From nobody Wed May 11 19:46: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 8D73C12D845 for ; Wed, 11 May 2016 19:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgozoMLD93xU for ; Wed, 11 May 2016 19:46:46 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 9C9EC12D5BE for ; Wed, 11 May 2016 19:46:45 -0700 (PDT) Received: from mail-lb0-f173.google.com ([209.85.217.173]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0Mex5B-1bFkgk1E8v-00OYO0 for ; Thu, 12 May 2016 04:46:43 +0200 Received: by mail-lb0-f173.google.com with SMTP id n11so4395672lbh.1 for ; Wed, 11 May 2016 19:46:43 -0700 (PDT) X-Gm-Message-State: AOPr4FVW5/zqlmxymjoViEtfNWITyKXaCmsvHpYNSJAt1QFwRljbgb0EjvM4s1pRpnrVgwU2mYLIOm4X9Cq62g== MIME-Version: 1.0 X-Received: by 10.112.170.201 with SMTP id ao9mr2757374lbc.38.1463021202707; Wed, 11 May 2016 19:46:42 -0700 (PDT) Received: by 10.112.74.135 with HTTP; Wed, 11 May 2016 19:46:42 -0700 (PDT) In-Reply-To: <20160512023946.15251.57807.idtracker@ietfa.amsl.com> References: <20160512023946.15251.57807.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 19:46:42 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36bdc161d6d05329c2bfb X-Provags-ID: V03:K0:bkGIsn2Cf2hUXyGD9BB7oOLFevHM1fJ5ueX9882KCeYLwvG+tUR 3EDgfT5iiAJFW5EYp54IotfcHYEdq1jxdGQwKXDp0ihsAKhwY7nD1umySW68xwZOQU5kJ9S EZc//fMU4q6bCy7TyVjh6CeBZt4rBiQ6Pdutwu5r68qwash+4BrEhVoSVAMowkfIOE+i4lc Nuhp+hD3Bepuh/JgHvBZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:sTozhHrrjDw=:Er8PFhdX42CqTL2i/oVbfZ PFIzMexZb+z0kS7P6SOdiIym39dt2dI6x0XVZprh3DFikE/WMuxM1A9Q6cgb6FjS9Gui+pd+5 FeRbwfdNSo9Rcz/35kP5NLiSGMRq3eVjmp6AV8XwHy/Eo/x5T4bEB8w/nS7MQAgha7Xxf6s+k md3XsOd1NnwxrxzGRcJOsGtqUx5abZMMXP7qijJPmucH5XrNwiM4cDKCNAQIxHh4pD0qj3T7W B//8u+b0UfHuwdCNv3PaZlC9z1ZO7bWXWbnxZ28X8fXLM/XgAvjIvm5Chw7y//HL7OK4Ul0Vj 4guB5ZfZjCsGsb9pGIX052MZht1bu8sPKiv2S05SEM0GV/GQKHZVMJVc5a8vmHFXe3DBa9BXL +zHzEbrG+pLMtV06JxI/3aVBs9Z8KuFya9cQ2cC6i5sLYufXcTcmSIeuUN3xFejueshXUK/U2 PbCQmxoNSqxo+nV7S7xThkrfSvZqplawXrvH4V3f8vvFnJvDvi2wa2pyRcbMdGUtSXieqPBAw MxPC/Op2YKyDJyXDx6n0lR0CWXDQdIMzUaWbDSrTQpYoJfS3Cn4ZZKWhxMhZYlm3Q2oLSs0MJ PMANsFWoosbPZXGy8kMYA3zcmUaCAabLxrl6c8Pgt/g8ROFeNhIvEqkKfKy6/RKtzZFs3Ttly MuFBlB5nP6c6t6tEZY9mA/FCpaZH9xpz4gmWGCZPJFH92OqoqaNoAU+pnMAqcBlgNOaAFAUD+ aH5gFnPdPQHf942h Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-falsestart-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: Thu, 12 May 2016 02:46:49 -0000 --001a11c36bdc161d6d05329c2bfb Content-Type: text/plain; charset=UTF-8 > > 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 : Transport Layer Security (TLS) False Start > Authors : Adam Langley > Nagendra Modadugu > Bodo Moeller > Filename : draft-ietf-tls-falsestart-02.txt > Pages : 10 > Date : 2016-05-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-falsestart-02 See https://www.ietf.org/mail-archive/web/secdir/current/msg06479.html (and https://www.ietf.org/mail-archive/web/secdir/current/msg06564.html) for context. Bodo --001a11c36bdc161d6d05329c2bfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
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 =C2=A0:= Transport Layer Security (TLS) False Start
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Adam= Langley
=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 Nagendra Modadugu
=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 Bodo Moeller
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-falsestart-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-05-11
=C2=A0
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-tls-falsestart-02

See ht= tps://www.ietf.org/mail-archive/web/secdir/current/msg06479.html (and <= a href=3D"https://www.ietf.org/mail-archive/web/secdir/current/msg06564.htm= l">https://www.ietf.org/mail-archive/web/secdir/current/msg06564.html) = for context.

Bodo

=
--001a11c36bdc161d6d05329c2bfb-- From nobody Thu May 12 00:42: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 C44D412D0A7 for ; Thu, 12 May 2016 00:42: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 GSGR1sHplsBj for ; Thu, 12 May 2016 00:42:39 -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 485E712B015 for ; Thu, 12 May 2016 00:42:39 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id i75so79529599ioa.3 for ; Thu, 12 May 2016 00:42:39 -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=87yKSnRwvZ1uMYBPRZxFoMndzLn3HxCL1rmu6wu/hh4=; b=euCsBKh+etehY3klcS3gqIJt+2EHiZuxy5/i5/nNEmtThO2grke9rxDbaeVwBmbZ/2 XEdZ+fbA6WVI/QSv7KMojRbikVqovq1xUJB2iikF16GwW09BoXk/Uzj2fsiuIII6AlpS 9s1kBo8r928WKkVGX4juu30p5tLpb4o3wFnhmNrnYXnrtCU3nTLHiYGCMZIAxAGoi2kj l1gBsN3zH+GMNnnx7X1x1qlwPRmvvaM/ag1UFz8Md7ucw4HoafFa9y7nIyAe/DfKfEkE RJ0UyY5hrutGuxdCjbRzdaq1TP2ufQl5dlC1ocZGR9eLqv/4taYkU1xLHOsAovSlO85c oqqA== 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=87yKSnRwvZ1uMYBPRZxFoMndzLn3HxCL1rmu6wu/hh4=; b=Iw+gJp7F+5myMQG6Pfc9GWePJUKxVvkaxD8dAJABB0MkI54NC9j8Lx39va0f9G+9em uYorLdVQ9u1oZtyZk/jJ7B7A0RzxaC90rtCDhbncDcmGyqLDjdl/aVHMq11vPILEzogm 72L9ufv/nvZH+nnYPMh0NL3ZlOd5gjlWT2uryOqimIbVTKdGb9YT9tAoalShZ6MCyGUh 5dT7YvS8WbTipmRgXTSBQP36NnspKN/xOhVCYjCwe+fERb2AohClcitefTsr51NhfauC PiSsEXYRu9Ke0MRCI+N8WPaxuLAoIuhkn5IrQz1q58JqmhLJIqARfg8ctL2eKRjb9qng 1dvQ== X-Gm-Message-State: AOPr4FXs/NX6YYZ243lO6iBO+1MbwNA2kX637dglH9iCYrn07UPFiXoEmPXTBm73oZ35e1XFIheh1ynB44YGlA== MIME-Version: 1.0 X-Received: by 10.36.139.71 with SMTP id g68mr3586529ite.68.1463038958526; Thu, 12 May 2016 00:42:38 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 12 May 2016 00:42:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 17:42:38 +1000 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 07:42:42 -0000 On 12 May 2016 at 12:41, David Benjamin wrote: > Sure, if we end up doing something on the server, mirroring sounds > reasonable enough. (This would just be for re-asserting the private key and > not switching certificates, right?) Not planning to allow it :) >[re: post handshake as an extension] > For HTTP, doing it in an extension the obvious way doesn't quite work. > Whether Chrome is willing to do renego depends on how ALPN resolves (we > leave it at its default off state and, after the initial handshake but > before we could consume a HelloRequest, toggle it off). Yeah, it's not ideal, but you could advertise support, then refuse to respond when it is requested of you in situations that you don't like. But Chrome is, as ever, somewhat special in this regard. Everyone else would be sort of protected from accidents unless they took the same rather extraordinary steps to enable the feature. From nobody Thu May 12 01:10: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 440C512B044 for ; Thu, 12 May 2016 01:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRY4_OiDQd5G for ; Thu, 12 May 2016 01:10:24 -0700 (PDT) Received: from smtp2.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3997B12B02D for ; Thu, 12 May 2016 01:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=HA30fozqNz3sV/R0ow4hjrX7o8ppWOQCt6TXKM9SSIY=; b=BA9CYcw3TVsm01bkeO3r5SuRSNwu8WqZXHkxUTWgjjEU1cVvhtzJt6jmOH2VzUJ1VOmL05gRhC6Xv8yk9opjojYEjK1T2Jn5+F5H/mwuevaZcuDOSVppQPD2oTt4433qtEY7BjOanJsV5ALnyKDy3wuMEGSzcbgikWWUwXlfqz8=; Received: from smtp-02-auth.e.etech.sk ([10.11.2.101] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1b0lhO-00084s-NJ for from ; Thu, 12 May 2016 10:10:22 +0200 Received: from 127.0.0.1 (orion1626.startdedicated.com [85.25.44.141]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 3A4F28B for ; Thu, 12 May 2016 10:10:13 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 3A4F28B Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: tls@ietf.org From: Fedor Brunner X-Enigmail-Draft-Status: N1110 Message-ID: <57343A63.9040605@azet.sk> Date: Thu, 12 May 2016 10:10:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailCleaner-DMARC: quarantine Archived-At: Subject: [TLS] removing 128-bit ciphers 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: Thu, 12 May 2016 08:10:27 -0000 Because of this attacks: https://blog.cr.yp.to/20151120-batchattacks.html could please consider to obsoleting 128-bit ciphers in TLS 1.3. For example AES-128 encryption has been removed from Suite B https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml More discussions on AES-128 vs. AES-256 https://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions https://www.schneier.com/blog/archives/2009/07/another_new_aes.html https://www.reddit.com/r/crypto/comments/39211m/is_really_aes256_less_secure_than_aes128/ https://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/ Kind regards, Fedor From nobody Thu May 12 01: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 BF6E812B02D for ; Thu, 12 May 2016 01:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g110mmPhytOz for ; Thu, 12 May 2016 01:23:02 -0700 (PDT) Received: from smtp2.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB20412B029 for ; Thu, 12 May 2016 01:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=HA30fozqNz3sV/R0ow4hjrX7o8ppWOQCt6TXKM9SSIY=; b=Owzlub3nIdhahveg/HU3YjRqSWdHQGYq+Qy7DZmNt+MH9jBASadoEJkdgNyj4Wk01pEh3CwX2ltAm9ZbUCjpKXdXK5+umQcuH7PlSupBWJCMA6KlM20PQ5XXeDlU20ds/1d9/PucpVh2t5znt3D63RM/XDw+OUOdGMTgI50DnCc=; Received: from smtp-01-auth.e.etech.sk ([10.11.2.100] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1b0ltc-0000US-RE for from ; Thu, 12 May 2016 10:23:00 +0200 Received: from 127.0.0.1 (unknown [91.109.29.120]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 1B29087 for ; Thu, 12 May 2016 10:22:51 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 1B29087 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: tls@ietf.org From: Fedor Brunner X-Enigmail-Draft-Status: N1110 Message-ID: <57343D58.2090909@azet.sk> Date: Thu, 12 May 2016 10:22:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailCleaner-DMARC: quarantine Archived-At: Subject: [TLS] removing 128-bit ciphers 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: Thu, 12 May 2016 08:23:05 -0000 Because of this attacks: https://blog.cr.yp.to/20151120-batchattacks.html could please consider to obsoleting 128-bit ciphers in TLS 1.3. For example AES-128 encryption has been removed from Suite B https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml More discussions on AES-128 vs. AES-256 https://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions https://www.schneier.com/blog/archives/2009/07/another_new_aes.html https://www.reddit.com/r/crypto/comments/39211m/is_really_aes256_less_secure_than_aes128/ https://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/ Kind regards, Fedor From nobody Thu May 12 07:40: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 E084C12B046 for ; Thu, 12 May 2016 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 q_GJB5DaCcFf for ; Thu, 12 May 2016 07:40:42 -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 6B8BE12B022 for ; Thu, 12 May 2016 07:40:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA081BE32; Thu, 12 May 2016 15:40:40 +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 sHrA7rPcusGf; Thu, 12 May 2016 15:40:39 +0100 (IST) Received: from [172.20.10.8] (mb62436d0.tmodns.net [208.54.36.182]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2CCEBE29; Thu, 12 May 2016 15:40:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463064039; bh=gTdI64XJCxtUxbIoLhG4uSp7+sFXDXr9r0cyMZ4Ua4Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jjIpULB82QapwgjLQLRdwlDA2pNjVqkM6duVdh71YemPMt8dFc1PkgAbfBRstj7rO DK3/Jk3xm12hzZwPwdm8HogXNR/D9iIcRYRBEtLab/DKQ8gKJzjJ9J7YLx+Sdt3Ntz e4ZeYJ/VIx8bC5Mli2/JTVmK2KeR16/0EHJ2oabM= To: Hannes Tschofenig , "" References: <57337AEA.2020202@gmx.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573495E3.1060500@cs.tcd.ie> Date: Thu, 12 May 2016 15:40:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57337AEA.2020202@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i0pSvEIjKqlit3cleedraXbjABEXStGa3" Archived-At: Subject: Re: [TLS] Updated TLS Cached Info Document X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:40:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i0pSvEIjKqlit3cleedraXbjABEXStGa3 Content-Type: multipart/mixed; boundary="bDXAvJ5pUKicwM98UjJtCnM8nONN9bi5G" From: Stephen Farrell To: Hannes Tschofenig , "" Message-ID: <573495E3.1060500@cs.tcd.ie> Subject: Re: [TLS] Updated TLS Cached Info Document References: <57337AEA.2020202@gmx.net> In-Reply-To: <57337AEA.2020202@gmx.net> --bDXAvJ5pUKicwM98UjJtCnM8nONN9bi5G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes. This document was already approved by the IESG and we were just waiting on this particular change to be made. AFAIK, this change, while affecting the bits on the wire, is ok with those who care about this document so I don't propose to put it back through IETF LC or IESG approval unless someone really thinks that's needed. So I'll send the approval message in a day or two and get this sent to the RFC editor if nobody yells. Cheers, S. On 11/05/16 19:33, Hannes Tschofenig wrote: > Hi all >=20 > I have just posted an updated version of the TLS Cached Info document > reflecting the discussions from the last IETF meeting (and the feedback= > received from Karthik before) regarding the size of the fingerprint. Th= e > fingerprint is not truncated anymore, which reflects what we had in an > earlier version of the document. >=20 > Here is the document: > https://tools.ietf.org/html/draft-ietf-tls-cached-info-23 >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --bDXAvJ5pUKicwM98UjJtCnM8nONN9bi5G-- --i0pSvEIjKqlit3cleedraXbjABEXStGa3 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 iQEcBAEBCAAGBQJXNJXjAAoJEC88hzaAX42inS0IAIt3t7CmW11TSLYvBpeXgjz+ o+7RYaQkRodO1nvrOpsHhsG76cldt0Tonj7HPDJ2c2YVJbkyDWv+/kv1Qp0Zwg+A CCnZuTbD7HF8GTQ0JXWguafTPrLILtSjss9OyFV7QpyGDKk3XW+sjQnKIBY20vz3 bdStxd9JUZxCHMgrBAs39xdRVTot4b6EY5OYMXAvznLbxV8C3R5i4gpE4HXxF3w0 sR4EQUCU7kJWA1MazhJNTB0zgnOGjV7cpCRYKdx28W8rlk0D3ZO+wsi/CSY9Cu2V Wya5DQEQx3dXfxZkUm4mswO/en/EHMzPT3LhLA1UZahbSeVstsej2PwjlvhmYoU= =k7If -----END PGP SIGNATURE----- --i0pSvEIjKqlit3cleedraXbjABEXStGa3-- From nobody Thu May 12 07:43: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 B1D7912D0BA for ; Thu, 12 May 2016 07:43:37 -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 OI_nSZBQdUZ8 for ; Thu, 12 May 2016 07:43:35 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD8312D170 for ; Thu, 12 May 2016 07:43:35 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id n63so44178685qkf.0 for ; Thu, 12 May 2016 07:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O04IbkpRefDdeBustX3lvEVHeQZ3XmHSEuKfQ+OcMyU=; b=l4qCUDy2L1vmIK1mDPsV6yxJbyebF2kf48dmBMp2FNDErwgzaxTGkgsWsSXpTWWAxu h8fY1Iw/vISPApmml3Iiw0syvWCBc7UaQzxBeaIFF76Sd1KSVmOv84nbVt4WFpyAI8ZI /C5B8ohksT7nqP5xgEuTgO9p7ci9FXDsbVRKg= 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=O04IbkpRefDdeBustX3lvEVHeQZ3XmHSEuKfQ+OcMyU=; b=nIkVJTHbVwdSFqxyC2X75DHwA5kVPZcIp0Do40krVrPknuWVx8/int1AxWRY20m2eX c4Vd5E+TMBG/c4AWgw6D7lMKfQPvMREGq2kJMnBaUMnnXnJuiBtLUfjfCooUeOyHj9XA /8ceFmaZgw6S5rlrM+nCrd8fNTpHpVZW8Nqi3mHlWjXs4v7pB3vgNJnYxrTuFi/u2/4C 4vosSAWTsXGS97xkMNXcnofgVB5gFAGHAt7WL6ujY2P3XWrnsJx//ZpCquF+krgnXKb/ gQB5Ct+Mb4tzQ3O1rHQL8F5lcW0d1RSkIfdatwN7Fs5UjWTaR5LTPjs7+CRlL56ROQ/R 5b0Q== X-Gm-Message-State: AOPr4FWbCi38sh2K8Njj/gZoTPo3GjYUZcpEsmQlGi6KNlvdAx4BCBismL/r7EVM5kkfaQ== X-Received: by 10.55.117.10 with SMTP id q10mr10831664qkc.103.1463064214627; Thu, 12 May 2016 07:43:34 -0700 (PDT) Received: from [172.16.0.112] ([96.231.223.55]) by smtp.gmail.com with ESMTPSA id c206sm6132868qha.45.2016.05.12.07.43.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 May 2016 07:43:34 -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: <573495E3.1060500@cs.tcd.ie> Date: Thu, 12 May 2016 10:43:31 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <57337AEA.2020202@gmx.net> <573495E3.1060500@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] Updated TLS Cached Info Document X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:43:38 -0000 On May 12, 2016, at 10:40, Stephen Farrell wrote: > > > Thanks Hannes. > > This document was already approved by the IESG and we were > just waiting on this particular change to be made. AFAIK, > this change, while affecting the bits on the wire, is ok > with those who care about this document so I don't propose > to put it back through IETF LC or IESG approval unless > someone really thinks that's needed. For the record, this matches my thinking. spt > So I'll send the approval message in a day or two and get > this sent to the RFC editor if nobody yells. > > Cheers, > S. > > On 11/05/16 19:33, Hannes Tschofenig wrote: >> Hi all >> >> I have just posted an updated version of the TLS Cached Info document >> reflecting the discussions from the last IETF meeting (and the feedback >> received from Karthik before) regarding the size of the fingerprint. The >> fingerprint is not truncated anymore, which reflects what we had in an >> earlier version of the document. >> >> Here is the document: >> https://tools.ietf.org/html/draft-ietf-tls-cached-info-23 >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 12 08:19: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 0F75812B057 for ; Thu, 12 May 2016 08:19:08 -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 rAuCbed0X1u5 for ; Thu, 12 May 2016 08:19:06 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 BA16E12D6A3 for ; Thu, 12 May 2016 08:19:05 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id o66so85539948ywc.3 for ; Thu, 12 May 2016 08:19: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=KjnBg9Pmpk3TAwHsEK8rcjXV2Q8PqRYIMsuBqp7V9MQ=; b=kE79nkN0B95JtzdNom7orIkv5iqH2AzlOWIIINUDzEJ8tEJbtQhR5ZbpOYAedHRjN+ 6Gl/JWCa5BtFXC0Lzzvk5HQOG0DPXrBIN/pO9ofqtSqbV+PmwE1lRBRkjtTUeGXDseNM JxWjG5JYMD9CNFdPoBaiBIF5/NElANyvgYahbt/fR0cMv4eJd9G0fdhW9KV5zMLVgax5 xqfR0DO5auwnmkpBpOqvB2rcxrvGyKbS33k63DWi2nbW47fZDV7e7r34Tfr5eFariv1F pPSfG7A3f0qLpQTs+N0qs60rCy4BR48+Uyq3dCYHsFAJjWNJwMmznJTgfuC+oa0Hf/Po G/2w== 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=KjnBg9Pmpk3TAwHsEK8rcjXV2Q8PqRYIMsuBqp7V9MQ=; b=Ko7B6GpP3YvtINiGHK1Hechuge4CibKJNM9BfYKq9ZlDXTc4h1Wit5mHA5zUkrqeQS P7wIiLJKWL6JfASrhBTyPf3gUNx4hsv2vAb1lyuXpKNz1bKny/5OGBIWhJDV0RCQO8v7 jo86JonI0GApQckxqEL5qkcj/zznj/Rf0Mm//a6YEds5S5iGcqVFWFUQhz3YwWZe5VZR xbEzG5oH61sv0kjFjZWh1SGhXA1BmPfWMM2su0W8fp5aUUWZ9zOwExt3aKIYx9n13/fU m7NsrTv2MtpR9fILL6pv2CnQjrNDR5fIYkFYMrl5cc1R/lFZ5DRAPWqxtC7SuxE8+7PS KUeQ== X-Gm-Message-State: AOPr4FVvJ+YjuNHZ5yk3yQCqXh7WTJYaG8FcFkplBEMIPLNqwlkmSCepgybIlnhKbza1O2sonQMGI8zhPQfABg== X-Received: by 10.129.86.8 with SMTP id k8mr4808368ywb.286.1463066344973; Thu, 12 May 2016 08:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 12 May 2016 08:18:25 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 May 2016 17:18:25 +0200 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11431a64c6e1f00532a6ad59 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 15:19:08 -0000 --001a11431a64c6e1f00532a6ad59 Content-Type: text/plain; charset=UTF-8 Interesting suggestion. I see what you mean about symmetry with the server The symmetry I was optimizing for is that the PSK and non-PSK handshake, and I think from that perspective the current design is simpler, so I see it both ways. WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing this case and I think we're starting to get more comfort with that. So, not sure what I think... -Ekr On Wed, May 11, 2016 at 10:44 PM, David Benjamin wrote: > The 0-RTT handshake originally had two places with a client Certificate + > CertificateVerify: in the 0-RTT flow and in the second Finished block in > response to a server CertificateRequest. We've dropped the first now. I > propose we drop the second too. Client auth with 0-RTT is solely carried > over via resumption. (I mentioned this previously, but with 0-RTT looking > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the > case is clearer.) > > This makes 6.2.3 more consistent with 6.2.2 where neither side > authenticates in a resumption handshake. 0-RTT is much more similar to > resumption with most parameters carrying over anyway. > > 1-RTT client auth in a 0-RTT handshake also invites more of the > retroactive auth confusion as with post-handshake auth. The client stream > switches from unauthenticated to authenticated. I believe this was one of > the reasons we agreed at IETF 95 to discourage/forbid (not sure which) > sending 0.5-RTT data following a CertificateRequest. In-handshake > CertificateRequest either requires this discouraged situation or accepting > 0-RTT data without sending 0.5-RTT data, which is largely pointless. > > We accepted the retroactive auth issue in post-handshake auth, but I think > we should limit it to that. For implementations, BoringSSL made accepting > renego an opt-in feature. I expect we'd do the same for post-handshake > auth. For specs, one might specify that post-handshake authentication is > forbidden. HTTP/2 did this for renegotiation. I haven't been following > the HTTP/2 client cert saga as closely, but > draft-thomson-http2-client-certs-02 is the current plan, right? If so, > HTTP/2 should forbid TLS-level post-handshake auth too. > > In both cases, excluding post-handshake auth should exclude any transition > from unauthenticated to authenticated in the stream. Instead, if you want > to change authentication state, send a post-handshake CertificateRequest, > as you would have normally. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11431a64c6e1f00532a6ad59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting suggestion. I see what you mean about symmetry= with the server

The symmetry I was optimizing for is th= at the PSK and non-PSK handshake, and I think from that perspective the cur= rent design is simpler, so I see it both ways.

WRT= to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing thi= s case and I think we're starting to get more comfort with that.
<= div>
So, not sure what I think...

-E= kr





On Wed, May 11= , 2016 at 10:44 PM, David Benjamin <davidben@chromium.org> wrote:
The 0-RTT hand= shake originally had two places with a client Certificate=C2=A0+ Certificat= eVerify: in the 0-RTT flow and in the second Finished block in response to = a server CertificateRequest.=C2=A0We've= dropped the first now. I propose we drop the second too. Client auth with = 0-RTT is solely carried over via resumption. (I mentioned this previously, = but with 0-RTT looking closer to resumption and the IETF 95 decision on 0.5= -RTT data, I think the case is clearer.)

This makes 6= .2.3 more consistent with 6.2.2 where neither side authenticates in a resum= ption handshake. 0-RTT is much more similar to resumption with most paramet= ers carrying over anyway.
=
1-RTT client auth in a 0-RTT handshake also invites m= ore of the retroactive auth confusion as with post-handshake auth. The clie= nt stream switches from unauthenticated to authenticated.=C2=A0I believe this was one of the reasons we agreed at IET= F 95 to discourage/forbid (not sure which) sending 0.5-RTT data following a= CertificateRequest. In-handshake CertificateRequest either requires this d= iscouraged situation or accepting 0-RTT data without sending 0.5-RTT data, = which is largely pointless.

We accepted the retroactive auth issue in post-handshake a= uth, but I think we should limit it to that. For implementations, BoringSSL made accepting renego an opt-in fea= ture. I expect we'd do the same for post-handshake auth.=C2=A0For specs, one might specify that post-handsh= ake authentication is forbidden. HTTP/2 did this for renegotiation.=C2=A0I haven't been following the HTTP/2 client cert saga as closely, b= ut draft-thomson-http2-client-certs-02 is the current plan, right? If so, H= TTP/2 should forbid TLS-level post-handshake auth too.

In both cases, excluding post-handshake auth should exclude any transition= from unauthenticated to authenticated in the stream. Instead, if you want = to change authentication state, send a post-handshake CertificateRequest, a= s you would have normally.

David

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


--001a11431a64c6e1f00532a6ad59-- From nobody Thu May 12 12:05: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 9DFD712D11D for ; Thu, 12 May 2016 12:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, 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 XEX9JslAJFYH for ; Thu, 12 May 2016 12:05:47 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1EA12B054 for ; Thu, 12 May 2016 12:05:47 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x201so135486362oif.3 for ; Thu, 12 May 2016 12:05:47 -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:cc; bh=fWbjw529FTN4UehTp958CJk77PKC/DYvp0/ELBhC4zA=; b=gVwAR2hILI9PYiRcrPI+8/D8bC7EUiUCmkvdkS1VOOcWw5WiawtQfRdfI6Fuuc7H1I OjDuYwddNT3TW/CVgExrzD/9L8vm1Al6MufDyV557mFRapQsVbbiL7Tyli+SFhHLtKcQ r9B0ZcV+NdsZT7eYng5viIYPDWi+SMsVGK5SaKmA3fRLt4aGQgOXrgg2CKZ87Hnper/S Fmm7lgIXbcZLSRGgv1oVSsONztj1KPgW3Fpijov+QQZhTQxRAb4JuZTOrFAdoW3RAc7o sIlvlWaFN3+GuEqNOZFMFI8+dlMlXWQJuYnBSn6lM1CvrsOQTgMo95hwHVuTgp9m2FHj p9yg== 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=fWbjw529FTN4UehTp958CJk77PKC/DYvp0/ELBhC4zA=; b=MKRn5YJbjwoUEzC+KamLzS0qoHyyx/oCSL/XKmg5QOd2HdsSXCAf+RDewqRV14i/Q+ coLswfmo+QteArgqPH+qNCKRMwoU0YXicWNJ+2WtTDUg7JIBMu+duL76jw3y7NDi+nOk 4Uz6UWJOZr/OT3awjrstWlStUsZ2lf8vBPiDHOK3BJBvjTMPYML+QqkGIjsOe1iikUao fFVkeFHYQSNVH9h1T80afLaPS9j4xzDoo5x4WC7Wba3SR5cQE/RuYUaGDiq3ViQ0Vojz J9x7guVJ/nToqtX06dCfP8qIatEQYklJVhJo6Hg5LKmAeshTCQoia5HC9FOih3syJNX+ bESg== X-Gm-Message-State: AOPr4FVl8x/MvL0erusvdW0zigAYtzleXmBDNO6HTXYnBQQnTMBc0bleOivL9nrvm/V6nN9MfRZ/Qfuz+qoPOg== X-Received: by 10.202.187.212 with SMTP id l203mr6344662oif.53.1463079947220; Thu, 12 May 2016 12:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Thu, 12 May 2016 12:05:27 -0700 (PDT) From: Ted Hardie Date: Thu, 12 May 2016 12:05:27 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113cf17a883d3c0532a9d865 Archived-At: Cc: Jana Iyengar Subject: [TLS] QUIC BoF for Berlin X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 19:05:49 -0000 --001a113cf17a883d3c0532a9d865 Content-Type: text/plain; charset=UTF-8 Howdy, I wanted to let folks know that we (the cc'ed folks) have proposed a BoF on QUIC for Berlin. The BoF proposal is here: https://tools.ietf.org/bof/trac/ . This effort, if approved, will split the current approach (which is currently described in pretty monolithic terms) into a set of components, one stream of which would be to describe how the QUIC transport can re-use the facilities of TLS 1.3 ( https://tools.ietf.org/html/draft-thomson-quic-tls-00 is an input to the BoF). The IETF mailing list for discussion of this proposal has been set up at quic@ietf.org. The intent is to form a working group, so a charter will be posted there for review soon. If you're interested in the topic, please join the list. thanks, Ted --001a113cf17a883d3c0532a9d865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I wanted to let folks know t= hat we (the cc'ed folks) have proposed a BoF on QUIC for Berlin.=C2=A0 = The BoF proposal is here: https://tools.ietf.= org/bof/trac/ .

This effort, if approved, will split the current approach (which is=20 currently described in pretty monolithic terms)=C2=A0 into a set of=20 components, one stream of which would be to describe how the QUIC transport= can re-use the facilities of TLS 1.3 (https://tools.ietf.org/html/draft-thomson-qui= c-tls-00 is an input to the BoF).

The IETF mailing list for= discussion of this proposal has been set up at quic@ietf.org.=C2=A0 T= he intent is to form a working group, so a charter will be posted there for= review soon.

If you're interested in the topic, plea= se join the list.

thanks,

Ted
--001a113cf17a883d3c0532a9d865-- From nobody Thu May 12 12:06: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 90DFE12B054 for ; Thu, 12 May 2016 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.695 X-Spam-Level: X-Spam-Status: No, score=-3.695 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=-0.996, 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 CmDwu9ij77sz for ; Thu, 12 May 2016 12:06:50 -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 4A3D812D515 for ; Thu, 12 May 2016 12:06:46 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id d62so107259638iof.2 for ; Thu, 12 May 2016 12:06: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 :cc; bh=e7f6Bg4Pc7MwhenrUgK/I7rnW9OGS3oM8Fhin3uW8I8=; b=aQFW8TPgc/81ddfFMM6X6xDzST/wPjU/ghDTtsh6uNZsJUpmXdqdSaEuvJmv355cwu Ycx5iHYs05Mq5MFj2p0LxtSqn+itLImCTZo0L7NjUwhYuD+f3sbPVZYwvk+qRCLjKBC0 WAYHZ3ZtKc/nNxRrwXDfIjdz2lLNNFfFeZasQ= 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=e7f6Bg4Pc7MwhenrUgK/I7rnW9OGS3oM8Fhin3uW8I8=; b=XCo4/7ZfvQDwYSl8ADw/AsAS7DHkuzuj/yLbVB1iB6wo353F4lrPt+ZDzVIU3SmbuU Qap/Vutp+VXGxH7XQfhSsRzjk/+4G4ZKfgRT76wcnUBaWm5y5JHy5f/tXcfaYqVtsT4Y NeZIPkC6bph8nfPCLB4o4J5YRbkWXM6A9XN1m0/JbH5OYxPPqMBEeNU3UGiRAmtUb43S Bbvei0REOd0s/sbLIcbnyOtBaCQwrPPfhlixLI4Y6DuJcaoAc0MIvVzdqWSwZwmVxmSA yCDJdG1HyONzhzC6XIBBpiZV5HtXAM5FdaAeoztEUvqYxF9xFV/qPBEmOfWuAHPN8571 7FGg== X-Gm-Message-State: AOPr4FUtZ0982DmXrfuqo3poH97ls057BgHmlAhjhI20LAdQXsAwYKh1f1JCLeP04RaaLocBFEm+DoHSD7O7Bje4 X-Received: by 10.107.183.139 with SMTP id h133mr9828946iof.97.1463080005414; Thu, 12 May 2016 12:06:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 12 May 2016 19:06:36 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0ba1820099880532a9dc79 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 19:06:53 -0000 --94eb2c0ba1820099880532a9dc79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3 currently allowed CertificateRequest in a PSK handshake either, or are you referring to something else? Actually, looking at the text again, it's a little confusing right now where CertificateRequest is and isn't allowed. The message flow in 6.2.2 implies a PSK resumption handshake does not send CertificateRequest. The flow in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT handshake as: """ When resuming via a PSK, clients can also send data on their first flight (=E2=80=9Cearly data=E2=80=9D). This data is encrypted solely under keys de= rived using the PSK as the static secret. As shown in Figure 4, the Zero-RTT data is just added to the 1-RTT handshake in the first flight, the rest of the handshake uses the same messages. """ This suggests it should match 6.2.2 in whether CertificateRequest is allowed. Arguably the rules should be in text, not diagrams, but the text in 6.3.3.2 just says: """ A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will follow EncryptedExtensions. """ (I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.) In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's not clear whether that applies to DHE_PSK, but I think that combined with 1.2's "non-anonymous" rule gives client auth =3D> certificate-based cipher as the most reasonable interpretation. David On Thu, May 12, 2016 at 11:19 AM Eric Rescorla wrote: > Interesting suggestion. I see what you mean about symmetry with the serve= r > > The symmetry I was optimizing for is that the PSK and non-PSK handshake, > and I think from that perspective the current design is simpler, so I see > it both ways. > > WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzin= g > this case and I think we're starting to get more comfort with that. > > So, not sure what I think... > > -Ekr > > > > > > On Wed, May 11, 2016 at 10:44 PM, David Benjamin > wrote: > >> The 0-RTT handshake originally had two places with a client Certificate = + >> CertificateVerify: in the 0-RTT flow and in the second Finished block in >> response to a server CertificateRequest. We've dropped the first now. I >> propose we drop the second too. Client auth with 0-RTT is solely carried >> over via resumption. (I mentioned this previously, but with 0-RTT lookin= g >> closer to resumption and the IETF 95 decision on 0.5-RTT data, I think t= he >> case is clearer.) >> >> This makes 6.2.3 more consistent with 6.2.2 where neither side >> authenticates in a resumption handshake. 0-RTT is much more similar to >> resumption with most parameters carrying over anyway. >> >> 1-RTT client auth in a 0-RTT handshake also invites more of the >> retroactive auth confusion as with post-handshake auth. The client strea= m >> switches from unauthenticated to authenticated. I believe this was one >> of the reasons we agreed at IETF 95 to discourage/forbid (not sure which= ) >> sending 0.5-RTT data following a CertificateRequest. In-handshake >> CertificateRequest either requires this discouraged situation or accepti= ng >> 0-RTT data without sending 0.5-RTT data, which is largely pointless. >> >> We accepted the retroactive auth issue in post-handshake auth, but I >> think we should limit it to that. For implementations, BoringSSL made >> accepting renego an opt-in feature. I expect we'd do the same for >> post-handshake auth. For specs, one might specify that post-handshake >> authentication is forbidden. HTTP/2 did this for renegotiation. I >> haven't been following the HTTP/2 client cert saga as closely, but >> draft-thomson-http2-client-certs-02 is the current plan, right? If so, >> HTTP/2 should forbid TLS-level post-handshake auth too. >> >> In both cases, excluding post-handshake auth should exclude any >> transition from unauthenticated to authenticated in the stream. Instead,= if >> you want to change authentication state, send a post-handshake >> CertificateRequest, as you would have normally. >> >> David >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c0ba1820099880532a9dc79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Which PSK/non-PSK symmetry are you referring to? I didn= 9;t think 1.3 currently allowed CertificateRequest in a PSK handshake eithe= r, or are you referring to something else?

Actually, loo= king at the text again, it's a little confusing right now where Certifi= cateRequest is and isn't allowed. The message flow in 6.2.2 implies a P= SK resumption handshake does not send CertificateRequest. The flow in 6.2.3= implies a 0-RTT handshake does, but it describes the 0-RTT handshake as:

"""
When resuming via a PS= K, clients can also send data on their first flight (=E2=80=9Cearly data=E2= =80=9D). This data is encrypted solely under keys derived using the PSK as = the static secret. As shown in Figure 4, the Zero-RTT data is just added to= the 1-RTT handshake in the first flight, the rest of the handshake uses th= e same messages.
"""

This sugges= ts it should match 6.2.2 in whether CertificateRequest is allowed.=C2=A0Arguably the rules should be in text, not diag= rams, but the text in 6.3.3.2 just says:

"""
A non-ano= nymous server can optionally request a certificate from the client, if appr= opriate for the selected cipher suite. This message, if sent, will follow E= ncryptedExtensions.
"""

(I'm guessing "non-anonymous" is a holdover from TLS 1.2&#= 39;s text.)

In TLS 1.2, I believe CertificateRequest i= n a PSK-based cipher wasn't allowed. RFC 4279 explicitly says it's = not allowed in plain PSK. It's not clear whether that applies to DHE_PS= K, but I think that combined with 1.2's "non-anonymous" rule = gives client auth =3D> certificate-based cipher as the most reasonable i= nterpretation.

David

=
On Thu, May 12, 2016= at 11:19 AM Eric Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">Interesting suggestion. I see what you mean about symmetry = with the server

The symmetry I was optimizing for is tha= t the PSK and non-PSK handshake, and I think from that perspective the curr= ent design is simpler, so I see it both ways.

WRT = to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing this= case and I think we're starting to get more comfort with that.

So, not sure what I think...

-Ek= r





On Wed, May 11, 2016 at = 10:44 PM, David Benjamin <davidben@chromium.org> wrote:<= br>
The 0-RTT handshake originally ha= d two places with a client Certificate=C2=A0+ CertificateVerify: in the 0-R= TT flow and in the second Finished block in response to a server Certificat= eRequest.=C2=A0We've dropped the first = now. I propose we drop the second too. Client auth with 0-RTT is solely car= ried over via resumption. (I mentioned this previously, but with 0-RTT look= ing closer to resumption and the IETF 95 decision on 0.5-RTT data, I think = the case is clearer.)

This makes 6.2.3 more consisten= t with 6.2.2 where neither side authenticates in a resumption handshake. 0-= RTT is much more similar to resumption with most parameters carrying over a= nyway.

1-RTT client auth in a 0-RTT handshake also invites more of the retroact= ive auth confusion as with post-handshake auth. The client stream switches = from unauthenticated to authenticated.=C2=A0I believe this was one of the reasons we agreed at IETF 95 to discourage/f= orbid (not sure which) sending 0.5-RTT data following a CertificateRequest.= In-handshake CertificateRequest either requires this discouraged situation= or accepting 0-RTT data without sending 0.5-RTT data, which is largely poi= ntless.

We = accepted the retroactive auth issue in post-handshake auth, but I think we = should limit it to that. For impleme= ntations, BoringSSL made accepting renego an opt-in feature. I expect we= 9;d do the same for post-handshake auth.=C2=A0For specs, one might specify that post-handshake authentication i= s forbidden. HTTP/2 did this for renegotiation.=C2=A0I haven't b= een following the HTTP/2 client cert saga as closely, but draft-thomson-htt= p2-client-certs-02 is the current plan, right? If so, HTTP/2 should forbid = TLS-level post-handshake auth too.

In both cases, excl= uding post-handshake auth should exclude any transition from unauthenticate= d to authenticated in the stream. Instead, if you want to change authentica= tion state, send a post-handshake CertificateRequest, as you would have nor= mally.

David<= /div>

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


--94eb2c0ba1820099880532a9dc79-- From nobody Thu May 12 12:26: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 E4CD012D0EE for ; Thu, 12 May 2016 12:26:36 -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 oSpuOikHceTF for ; Thu, 12 May 2016 12:26:33 -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 9BD7012B039 for ; Thu, 12 May 2016 12:26:33 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id o66so93234306ywc.3 for ; Thu, 12 May 2016 12:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u7p545iU5droTeZ82mRme1lz/Hj+h8wY4aDQDYjcjG8=; b=i2bGL31hVnCjHinDHepUvsOAvCC+seocZfmPrbnAsb5w7UWSwuqJsCDhaafe6mIAW6 Er7cIbnZL1uTyVxlJVAFu6LY+0SxPvXbTCB+qJjwegknNhJLJK0N/kKUb2P/eTzh94P7 EOi51SQ6IuejPpkpq5Crxa0hmeNY9kE1qzOEehVxp9zTgwnfsindoeACZIYuZAi+ku5B LMPqGKFrPYCaQ4Txo6KyeabAp6wJXilUz2jL+NNRjsHHbTul8HRv6u7vMPYt2Md7/XjD RS4ZOxfX4R1C6c3Rn9DuE6XPxPSlyy0ad7gbx5hlKMFCsBi+DVxRWFo6wiPc7IVu6Q7u F08g== 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=u7p545iU5droTeZ82mRme1lz/Hj+h8wY4aDQDYjcjG8=; b=D/jvycnkRptPx+9sWgwU5bQWE6c78vrKetloYyCMntcTaPBb3VK56RBp/Mr9+vT09p Yr8ZW9B0pBJetPGu5casRJWfEZHeNNf2lgMn8IorSGy8YjbXQbhJsKuo/ltXH6PSa0A/ jBSTQkDMsAxfTBoxFV36yDj0ZM51nS6ZF6PhgoMeoB8lo2JjCdW50o6FneHYm0cHqsZB zAZc2fS1CJ52l5P90PTU5CNGAkULBFo+7B1qMCpZbZtpVBEu/MB1D2EqTj9aZN2p1vyU UqbyvchSlPIUcIioFN2nKYmdPM5++zuJciUb5E2ucc2ligQJLFuN2eoEHxx8M+TiLLpk 2gEg== X-Gm-Message-State: AOPr4FUFWFNIkYhqFvr4nxmw6FWUNX6gv5U/naLBbTxCRSuzRfXRJ7KtfGZVt2SDK0bDRz2fNEbRyqtddGcZwg== X-Received: by 10.37.203.68 with SMTP id b65mr5427183ybg.130.1463081192840; Thu, 12 May 2016 12:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 12 May 2016 12:25:53 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 May 2016 21:25:53 +0200 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c059e16c7124a0532aa2253 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 19:26:37 -0000 --94eb2c059e16c7124a0532aa2253 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that the current draft is ambiguous on this point but I think the question is what the right thing is. My intuition here is that we should try to make the client's side and the server's side more independent so that you can have client auth in either case. Given that we're going to allow post-handshake client auth when you resume, it's just not clear to me why you wouldn't allow in-handshake client-auth. I'm not sure it's a hill I'm willing to die on though. -Ekr On Thu, May 12, 2016 at 9:06 PM, David Benjamin wrote: > Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3 > currently allowed CertificateRequest in a PSK handshake either, or are yo= u > referring to something else? > > Actually, looking at the text again, it's a little confusing right now > where CertificateRequest is and isn't allowed. The message flow in 6.2.2 > implies a PSK resumption handshake does not send CertificateRequest. The > flow in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT > handshake as: > > """ > When resuming via a PSK, clients can also send data on their first flight > (=E2=80=9Cearly data=E2=80=9D). This data is encrypted solely under keys = derived using the > PSK as the static secret. As shown in Figure 4, the Zero-RTT data is just > added to the 1-RTT handshake in the first flight, the rest of the handsha= ke > uses the same messages. > """ > > This suggests it should match 6.2.2 in whether CertificateRequest is > allowed. Arguably the rules should be in text, not diagrams, but the text > in 6.3.3.2 just says: > > """ > A non-anonymous server can optionally request a certificate from the > client, if appropriate for the selected cipher suite. This message, if > sent, will follow EncryptedExtensions. > """ > > (I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.) > > In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't > allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's not > clear whether that applies to DHE_PSK, but I think that combined with 1.2= 's > "non-anonymous" rule gives client auth =3D> certificate-based cipher as t= he > most reasonable interpretation. > > David > > On Thu, May 12, 2016 at 11:19 AM Eric Rescorla wrote: > >> Interesting suggestion. I see what you mean about symmetry with the serv= er >> >> The symmetry I was optimizing for is that the PSK and non-PSK handshake, >> and I think from that perspective the current design is simpler, so I se= e >> it both ways. >> >> WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on >> analyzing this case and I think we're starting to get more comfort with >> that. >> >> So, not sure what I think... >> >> -Ekr >> >> >> >> >> >> On Wed, May 11, 2016 at 10:44 PM, David Benjamin >> wrote: >> >>> The 0-RTT handshake originally had two places with a client >>> Certificate + CertificateVerify: in the 0-RTT flow and in the second >>> Finished block in response to a server CertificateRequest. We've >>> dropped the first now. I propose we drop the second too. Client auth wi= th >>> 0-RTT is solely carried over via resumption. (I mentioned this previous= ly, >>> but with 0-RTT looking closer to resumption and the IETF 95 decision on >>> 0.5-RTT data, I think the case is clearer.) >>> >>> This makes 6.2.3 more consistent with 6.2.2 where neither side >>> authenticates in a resumption handshake. 0-RTT is much more similar to >>> resumption with most parameters carrying over anyway. >>> >>> 1-RTT client auth in a 0-RTT handshake also invites more of the >>> retroactive auth confusion as with post-handshake auth. The client stre= am >>> switches from unauthenticated to authenticated. I believe this was one >>> of the reasons we agreed at IETF 95 to discourage/forbid (not sure whic= h) >>> sending 0.5-RTT data following a CertificateRequest. In-handshake >>> CertificateRequest either requires this discouraged situation or accept= ing >>> 0-RTT data without sending 0.5-RTT data, which is largely pointless. >>> >>> We accepted the retroactive auth issue in post-handshake auth, but I >>> think we should limit it to that. For implementations, BoringSSL made >>> accepting renego an opt-in feature. I expect we'd do the same for >>> post-handshake auth. For specs, one might specify that post-handshake >>> authentication is forbidden. HTTP/2 did this for renegotiation. I >>> haven't been following the HTTP/2 client cert saga as closely, but >>> draft-thomson-http2-client-certs-02 is the current plan, right? If so, >>> HTTP/2 should forbid TLS-level post-handshake auth too. >>> >>> In both cases, excluding post-handshake auth should exclude any >>> transition from unauthenticated to authenticated in the stream. Instead= , if >>> you want to change authentication state, send a post-handshake >>> CertificateRequest, as you would have normally. >>> >>> David >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> --94eb2c059e16c7124a0532aa2253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that the current draft is ambiguous on this point = but I think the question is what the right
thing is. My intuition here = is that we should try to make the client's side and the server's si= de
more independent so that you can have client auth in either ca= se. Given that we're going to
allow post-handshake client aut= h when you resume, it's just not clear to me why you wouldn't
=
allow in-handshake client-auth. I'm not sure it's a hill I'= ;m willing to die on though.

-Ekr



On Thu, May 12, 2016 at 9:06 PM, David Benjamin &= lt;davidben@chro= mium.org> wrote:
Which PSK/non-PSK symmetry are you referring to? I didn't thin= k 1.3 currently allowed CertificateRequest in a PSK handshake either, or ar= e you referring to something else?

Actually, looking at = the text again, it's a little confusing right now where CertificateRequ= est is and isn't allowed. The message flow in 6.2.2 implies a PSK resum= ption handshake does not send CertificateRequest. The flow in 6.2.3 implies= a 0-RTT handshake does, but it describes the 0-RTT handshake as:

"""
When resuming via a PSK, clien= ts can also send data on their first flight (=E2=80=9Cearly data=E2=80=9D).= This data is encrypted solely under keys derived using the PSK as the stat= ic secret. As shown in Figure 4, the Zero-RTT data is just added to the 1-R= TT handshake in the first flight, the rest of the handshake uses the same m= essages.
"""

This suggests it sh= ould match 6.2.2 in whether CertificateRequest is allowed.=C2=A0Arguably the rules should be in text, not diagrams, bu= t the text in 6.3.3.2 just says:

"""
A non-anonymous s= erver can optionally request a certificate from the client, if appropriate = for the selected cipher suite. This message, if sent, will follow Encrypted= Extensions.
"""

(I= 9;m guessing "non-anonymous" is a holdover from TLS 1.2's tex= t.)

In TLS 1.2, I believe CertificateRequest in a PSK-= based cipher wasn't allowed. RFC 4279 explicitly says it's not allo= wed in plain PSK. It's not clear whether that applies to DHE_PSK, but I= think that combined with 1.2's "non-anonymous" rule gives cl= ient auth =3D> certificate-based cipher as the most reasonable interpret= ation.

David
<= /font>

On Thu, May 12, 2016 at 11:19 AM = Eric Rescorla <ekr@rtf= m.com> wrote:
Interesting suggestion. I see what you mean about symmetry with the serv= er

The symmetry I was optimizing for is that the PSK and= non-PSK handshake, and I think from that perspective the current design is= simpler, so I see it both ways.

WRT to the 0.5RTT= data, Hugo Krawczyk has done some nice work on analyzing this case and I t= hink we're starting to get more comfort with that.

=
So, not sure what I think...

-Ekr





On Wed, May 11, 2016 at 10:44 PM, Da= vid Benjamin <davidben@chromium.org> wrote:
The 0-RTT handshake originally had two place= s with a client Certificate=C2=A0+ CertificateVerify: in the 0-RTT flow and= in the second Finished block in response to a server CertificateRequest.= =C2=A0We've dropped the first now. I pr= opose we drop the second too. Client auth with 0-RTT is solely carried over= via resumption. (I mentioned this previously, but with 0-RTT looking close= r to resumption and the IETF 95 decision on 0.5-RTT data, I think the case = is clearer.)

This makes 6.2.3 more consistent with 6.= 2.2 where neither side authenticates in a resumption handshake. 0-RTT is mu= ch more similar to resumption with most parameters carrying over anyway.

1-RTT = client auth in a 0-RTT handshake also invites more of the retroactive auth = confusion as with post-handshake auth. The client stream switches from unau= thenticated to authenticated.=C2=A0I believ= e this was one of the reasons we agreed at IETF 95 to discourage/forbid (no= t sure which) sending 0.5-RTT data following a CertificateRequest. In-hands= hake CertificateRequest either requires this discouraged situation or accep= ting 0-RTT data without sending 0.5-RTT data, which is largely pointless.

We accepted = the retroactive auth issue in post-handshake auth, but I think we should li= mit it to that. For implementations,= BoringSSL made accepting renego an opt-in feature. I expect we'd do th= e same for post-handshake auth.=C2=A0For specs, one might specify that post-handshake authentication is forbidd= en. HTTP/2 did this for renegotiation.=C2=A0I haven't been follo= wing the HTTP/2 client cert saga as closely, but draft-thomson-http2-client= -certs-02 is the current plan, right? If so, HTTP/2 should forbid TLS-level= post-handshake auth too.

In both cases, excluding pos= t-handshake auth should exclude any transition from unauthenticated to auth= enticated in the stream. Instead, if you want to change authentication stat= e, send a post-handshake CertificateRequest, as you would have normally.

David

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



--94eb2c059e16c7124a0532aa2253-- From nobody Thu May 12 12: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 5304012B053 for ; Thu, 12 May 2016 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.695 X-Spam-Level: X-Spam-Status: No, score=-3.695 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=-0.996, 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 Wz-4wIUeU2Uy for ; Thu, 12 May 2016 12:41:03 -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 5EB2012B039 for ; Thu, 12 May 2016 12:41:03 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 190so108281493iow.1 for ; Thu, 12 May 2016 12:41:03 -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=tRxM+kjhAPPF0hrgQDIMM4JpBchp5vnUpfICs4gpEjs=; b=nv5EmJhCD04vakz4iOK7PWb0pv3sTlnoxfZgsvrnTKkTTzbRo+SXQxBhaaW2Z3fOpu r/tn9QevrwzpeswD1oROMYJ0C3bVuNgtfq1p7iTikcNCTKp1X5HF28RM9vq8OTL9UDl7 KDgl4j9SeiJnnbZPHQ3lMbqLGcG9pT7lZvf/8= 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=tRxM+kjhAPPF0hrgQDIMM4JpBchp5vnUpfICs4gpEjs=; b=OdEkzkPFD9sShE1CfiecIr+ccihreXDZvOoRf3LMrOPXgnJj4h9NbU3uy/pDmshwN8 +2m1VpV7289Q1wmpLS4rHLXyDavO7C2kS1UzTv7c2DWDiNTRj3MR6qi54BXUe6EadRFO e5JgVL0mnrX0wte5keTVxDZ3Gybmhb9l/709yTMLyksf7U2rH5kME1VSvdHZXWdTu3jh ZhNxA3sx6eodU6ajvWPfXzkiWw5eXY79AbY7m9YWPsLjzIlSuVxpsFpPlMb0/U4sQPDW dsut/ddot6OSXtofgYoIMrWqPOgXLvJ0FQT8bdiQzFFvpnvdXbzVAo4wSHPneBhhvPmt XOjQ== X-Gm-Message-State: AOPr4FV/YVILFuJoVRyh8qpeYzmHXya4ttNTC3BmWx2XJjT46z7IXfzQoD7kOj1+Fu4y4gK9Upm/sZQ9/3xqq4AB X-Received: by 10.107.183.139 with SMTP id h133mr9964263iof.97.1463082062511; Thu, 12 May 2016 12:41:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 12 May 2016 19:40:52 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0ba1829d47df0532aa5623 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 19:41:06 -0000 --94eb2c0ba1829d47df0532aa5623 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, I want to forbid it precisely because I don't want to allow post-handshake client auth. :-) Or rather, I expect most TLS applications will not want post-handshake client auth enabled as it significantly changes the authentication picture (TLS-level auth can change mid-stream) and would have it off. I would like disabling post-handshake client auth to, as a result, disable all such TLS-level mid-stream switches. For some legacy uses of HTTP/1.1, sure, post-handshake auth will be enabled and this feature doesn't do much harm. (But it also doesn't help. The server can just as easily send post-handshake CertificateRequest right after the handshake.) For 1-RTT, there's no mid-stream transition problem. Though it is kind of weird for PSK-resumption. PSK-resumption already implicitly carries a set of certificate-based identities from the previous run, but we're saying the server may ask the client to pick a different one (but not vice versa). Is the client still authenticated as the previous one too, or just the new one= ? David On Thu, May 12, 2016 at 3:26 PM Eric Rescorla wrote: > I agree that the current draft is ambiguous on this point but I think the > question is what the right > thing is. My intuition here is that we should try to make the client's > side and the server's side > more independent so that you can have client auth in either case. Given > that we're going to > allow post-handshake client auth when you resume, it's just not clear to > me why you wouldn't > allow in-handshake client-auth. I'm not sure it's a hill I'm willing to > die on though. > > -Ekr > > > > On Thu, May 12, 2016 at 9:06 PM, David Benjamin > wrote: > >> Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3 >> currently allowed CertificateRequest in a PSK handshake either, or are y= ou >> referring to something else? >> >> Actually, looking at the text again, it's a little confusing right now >> where CertificateRequest is and isn't allowed. The message flow in 6.2.2 >> implies a PSK resumption handshake does not send CertificateRequest. The >> flow in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT >> handshake as: >> >> """ >> When resuming via a PSK, clients can also send data on their first fligh= t >> (=E2=80=9Cearly data=E2=80=9D). This data is encrypted solely under keys= derived using the >> PSK as the static secret. As shown in Figure 4, the Zero-RTT data is jus= t >> added to the 1-RTT handshake in the first flight, the rest of the handsh= ake >> uses the same messages. >> """ >> >> This suggests it should match 6.2.2 in whether CertificateRequest is >> allowed. Arguably the rules should be in text, not diagrams, but the >> text in 6.3.3.2 just says: >> >> """ >> A non-anonymous server can optionally request a certificate from the >> client, if appropriate for the selected cipher suite. This message, if >> sent, will follow EncryptedExtensions. >> """ >> >> (I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.) >> >> In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't >> allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's no= t >> clear whether that applies to DHE_PSK, but I think that combined with 1.= 2's >> "non-anonymous" rule gives client auth =3D> certificate-based cipher as = the >> most reasonable interpretation. >> >> David >> >> On Thu, May 12, 2016 at 11:19 AM Eric Rescorla wrote: >> >>> Interesting suggestion. I see what you mean about symmetry with the >>> server >>> >>> The symmetry I was optimizing for is that the PSK and non-PSK handshake= , >>> and I think from that perspective the current design is simpler, so I s= ee >>> it both ways. >>> >>> WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on >>> analyzing this case and I think we're starting to get more comfort with >>> that. >>> >>> So, not sure what I think... >>> >>> -Ekr >>> >>> >>> >>> >>> >>> On Wed, May 11, 2016 at 10:44 PM, David Benjamin >>> wrote: >>> >>>> The 0-RTT handshake originally had two places with a client >>>> Certificate + CertificateVerify: in the 0-RTT flow and in the second >>>> Finished block in response to a server CertificateRequest. We've >>>> dropped the first now. I propose we drop the second too. Client auth w= ith >>>> 0-RTT is solely carried over via resumption. (I mentioned this previou= sly, >>>> but with 0-RTT looking closer to resumption and the IETF 95 decision o= n >>>> 0.5-RTT data, I think the case is clearer.) >>>> >>>> This makes 6.2.3 more consistent with 6.2.2 where neither side >>>> authenticates in a resumption handshake. 0-RTT is much more similar to >>>> resumption with most parameters carrying over anyway. >>>> >>>> 1-RTT client auth in a 0-RTT handshake also invites more of the >>>> retroactive auth confusion as with post-handshake auth. The client str= eam >>>> switches from unauthenticated to authenticated. I believe this was one >>>> of the reasons we agreed at IETF 95 to discourage/forbid (not sure whi= ch) >>>> sending 0.5-RTT data following a CertificateRequest. In-handshake >>>> CertificateRequest either requires this discouraged situation or accep= ting >>>> 0-RTT data without sending 0.5-RTT data, which is largely pointless. >>>> >>>> We accepted the retroactive auth issue in post-handshake auth, but I >>>> think we should limit it to that. For implementations, BoringSSL made >>>> accepting renego an opt-in feature. I expect we'd do the same for >>>> post-handshake auth. For specs, one might specify that post-handshake >>>> authentication is forbidden. HTTP/2 did this for renegotiation. I >>>> haven't been following the HTTP/2 client cert saga as closely, but >>>> draft-thomson-http2-client-certs-02 is the current plan, right? If so, >>>> HTTP/2 should forbid TLS-level post-handshake auth too. >>>> >>>> In both cases, excluding post-handshake auth should exclude any >>>> transition from unauthenticated to authenticated in the stream. Instea= d, if >>>> you want to change authentication state, send a post-handshake >>>> CertificateRequest, as you would have normally. >>>> >>>> David >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> > --94eb2c0ba1829d47df0532aa5623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, I want to forbid it precisely because I don= 9;t want to allow post-handshake client auth. :-)

= Or rather, I expect most TLS applications will not want post-handshake clie= nt auth enabled as it significantly changes the authentication picture (TLS= -level auth can change mid-stream) and would have it off. I would like disa= bling post-handshake client auth to, as a result, disable all such TLS-leve= l mid-stream switches. For some legacy uses of HTTP/1.1, sure, post-handsha= ke auth will be enabled and this feature doesn't do much harm. (But it = also doesn't help. The server can just as easily send post-handshake Ce= rtificateRequest right after the handshake.)

For 1= -RTT, there's no mid-stream transition problem. Though it is kind of we= ird for PSK-resumption. PSK-resumption already implicitly carries a set of = certificate-based identities from the previous run, but we're saying th= e server may ask the client to pick a different one (but not vice versa). I= s the client still authenticated as the previous one too, or just the new o= ne?

David

=
On Thu, May 12, 2016 at 3:26 PM Eric Rescorla <ekr@rtfm.com> wrote:
I agree that the current draft is ambigu= ous on this point but I think the question is what the right
thing is. = My intuition here is that we should try to make the client's side and t= he server's side
more independent so that you can have client= auth in either case. Given that we're going to
allow post-ha= ndshake client auth when you resume, it's just not clear to me why you = wouldn't
allow in-handshake client-auth. I'm not sure it&= #39;s a hill I'm willing to die on though.

-Ek= r



<= div class=3D"gmail_quote">On Thu, May 12, 2016 at 9:06 PM, David Benjamin <= span dir=3D"ltr"><davidben@chromium.org> wrote:
Which PSK/non-PSK symmetry are you referring to? I= didn't think 1.3 currently allowed CertificateRequest in a PSK handsha= ke either, or are you referring to something else?

Actua= lly, looking at the text again, it's a little confusing right now where= CertificateRequest is and isn't allowed. The message flow in 6.2.2 imp= lies a PSK resumption handshake does not send CertificateRequest. The flow = in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT handsha= ke as:

"""
When resuming = via a PSK, clients can also send data on their first flight (=E2=80=9Cearly= data=E2=80=9D). This data is encrypted solely under keys derived using the= PSK as the static secret. As shown in Figure 4, the Zero-RTT data is just = added to the 1-RTT handshake in the first flight, the rest of the handshake= uses the same messages.
"""

Thi= s suggests it should match 6.2.2 in whether CertificateRequest is allowed.= =C2=A0Arguably the rules should be in text,= not diagrams, but the text in 6.3.3.2 just says:

"""
= A non-anonymous server can optionally request a certificate from the client= , if appropriate for the selected cipher suite. This message, if sent, will= follow EncryptedExtensions.
"""
(I'm guessing "non-anonymous" is a holdover from = TLS 1.2's text.)

<= /div>
In TLS 1.2, I believe Certificate= Request in a PSK-based cipher wasn't allowed. RFC 4279 explicitly says = it's not allowed in plain PSK. It's not clear whether that applies = to DHE_PSK, but I think that combined with 1.2's "non-anonymous&qu= ot; rule gives client auth =3D> certificate-based cipher as the most rea= sonable interpretation.

David

On Thu, May 12, 2016 at 11:19 AM Eric Rescorla <ekr@rtfm.com> wrote:
=
Interesting suggestion. I s= ee what you mean about symmetry with the server

The symm= etry I was optimizing for is that the PSK and non-PSK handshake, and I thin= k from that perspective the current design is simpler, so I see it both way= s.

WRT to the 0.5RTT data, Hugo Krawczyk has done = some nice work on analyzing this case and I think we're starting to get= more comfort with that.

So, not sure what I think= ...

-Ekr





On Wed, May 11, 2016 at 10:44 PM, David Benjamin = <davidben@chr= omium.org> wrote:
<= div class=3D"gmail_quote">
T= he 0-RTT handshake originally had two places with a client Certificate=C2= =A0+ CertificateVerify: in the 0-RTT flow and in the second Finished block = in response to a server CertificateRequest.=C2=A0We've dropped the first now. I propose we drop the second too. Cl= ient auth with 0-RTT is solely carried over via resumption. (I mentioned th= is previously, but with 0-RTT looking closer to resumption and the IETF 95 = decision on 0.5-RTT data, I think the case is clearer.)

This makes 6.2.3 more consistent with 6.2.2 where neither side authentic= ates in a resumption handshake. 0-RTT is much more similar to resumption wi= th most parameters carrying over anyway.

1-RTT client auth in a 0-RTT handshake= also invites more of the retroactive auth confusion as with post-handshake= auth. The client stream switches from unauthenticated to authenticated.=C2= =A0I believe this was one of the reasons we= agreed at IETF 95 to discourage/forbid (not sure which) sending 0.5-RTT da= ta following a CertificateRequest. In-handshake CertificateRequest either r= equires this discouraged situation or accepting 0-RTT data without sending = 0.5-RTT data, which is largely pointless.

<= span style=3D"line-height:1.5">We accepted the retroactive auth issue in po= st-handshake auth, but I think we should limit it to that. For implementations, BoringSSL made accepting renego= an opt-in feature. I expect we'd do the same for post-handshake auth.= =C2=A0For specs, one might specify t= hat post-handshake authentication is forbidden. HTTP/2 did this for renegot= iation.=C2=A0I haven't been following the HTTP/2 client cert sag= a as closely, but draft-thomson-http2-client-certs-02 is the current plan, = right? If so, HTTP/2 should forbid TLS-level post-handshake auth too.
=

In both cases, excluding post-handshake auth should exclude= any transition from unauthenticated to authenticated in the stream. Instea= d, if you want to change authentication state, send a post-handshake Certif= icateRequest, as you would have normally.

David

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



--94eb2c0ba1829d47df0532aa5623-- From nobody Thu May 12 12:53: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 0A70C12D159 for ; Thu, 12 May 2016 12:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 fYgz2X4JYlAa for ; Thu, 12 May 2016 12:53:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A533212B039 for ; Thu, 12 May 2016 12:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gANtdd2HHB4Q3u7YBjxp+uE2qSXvv/8Eq47xD6AA8tc=; b=LTWyHLFvhJI6Hv2cU2ZZERTCdmKaxmIY8vuW9q2GS2HSKIwQrXtbZU5p54HXDaV/nU38sHNgM4lfpIRLEMLNoq8N06Z2FiU+z+aCW0OMjPwlIoq3dUH4p769z8X1qNhPk50UTH4Sm+cg1g0Vk75LoFLxNtPaO6JjLNKY+7KBvSU= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 19:52:53 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0492.019; Thu, 12 May 2016 19:52:53 +0000 From: Andrei Popov To: David Benjamin , Eric Rescorla Thread-Topic: [TLS] In-handshake CertificateRequest and 0-RTT Thread-Index: AQHRq8YKJ6vbePADq0yCRqtFxjAW9J+1a4KAgAA/wQCAAAVjgIAABDAAgAACqBA= Date: Thu, 12 May 2016 19:52:53 +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: chromium.org; dkim=none (message not signed) header.d=none; chromium.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: d873081f-e589-4fde-093e-08d37a9f01c4 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:YGagPjZCtl6zRiKaGQjaLUYgeUcR7TKS7pojrUVgmKVviorZvNh8DMNmY8XMhVLn/rpE6lJ/NVIA97YoffcmlCIF+ogTrT9WKk3N7NDcV09Q81ACCS8RLhveHnb0QeHBUnDxaQUT9v/QPUeT53JUAg==; 24:Fca8/I4MJUTrFcB3lGgKGaPluqr7PCeQQM4L/qsqWNZwoKLw1YkGN2kcL+CtdL2zM35D7x+2Oml6X4HlLWEQoZT9BFiA0PDxJMhhDHIuWeM=; 7:dEt80XnkEY9v9iU0/4///sqsWTDVAaBykGdpZKO1n5fZKN6PMNqeLn3Bu7RG9GsgrM4ue+lMh3+0+UYo3svn2Y/wRr6HhZBDPJ7FxWvxiwqKmCnG1GVoa/hemdkRIzF8VKwk4ctYuFyAMYZyNwMHGENYoE+7cduIgl/V0gwTAvlaOwh87qQkSDYUjI8Cu/Y6g7JlgZkc+UfAJndSz1KahA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(24454002)(50986999)(102836003)(6116002)(4326007)(790700001)(5004730100002)(5001770100001)(10400500002)(86362001)(1220700001)(5005710100001)(99286002)(16236675004)(19300405004)(19580405001)(19580395003)(81166006)(92566002)(76176999)(106116001)(8990500004)(5002640100001)(54356999)(33656002)(2906002)(74316001)(15975445007)(2900100001)(10090500001)(2950100001)(11100500001)(9686002)(5008740100001)(3660700001)(10290500002)(189998001)(8936002)(93886004)(77096005)(86612001)(19625215002)(5003600100002)(87936001)(19617315012)(122556002)(3280700002)(76576001)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB14459AC22FD4529B1E246F7A8C730BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 19:52:53.6447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] In-handshake CertificateRequest and 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: Thu, 12 May 2016 19:53:22 -0000 --_000_BN3PR03MB14459AC22FD4529B1E246F7A8C730BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElzIHRoZSBjbGllbnQgc3RpbGwgYXV0aGVudGljYXRlZCBhcyB0aGUgcHJldmlvdXMgb25l IHRvbywgb3IganVzdCB0aGUgbmV3IG9uZT8NCkkgdGhpbmsgdGhlIGNsaWVudCB0aGF0IGhhcyBh dXRoZW50aWNhdGVkIGFzIEEgYW5kIHRoZW4gQiBpbiB0aGUgc2FtZSBUTFMgc2Vzc2lvbiwgY2Fu 4oCZdCBjbGFpbSB0byBub3QgYmUgQSBhbnltb3JlLg0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIEJlbmphbWluDQpTZW50OiBUaHVy c2RheSwgTWF5IDEyLCAyMDE2IDEyOjQxIFBNDQpUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIEluLWhhbmRzaGFrZSBD ZXJ0aWZpY2F0ZVJlcXVlc3QgYW5kIDAtUlRUDQoNClJpZ2h0LCBJIHdhbnQgdG8gZm9yYmlkIGl0 IHByZWNpc2VseSBiZWNhdXNlIEkgZG9uJ3Qgd2FudCB0byBhbGxvdyBwb3N0LWhhbmRzaGFrZSBj bGllbnQgYXV0aC4gOi0pDQoNCk9yIHJhdGhlciwgSSBleHBlY3QgbW9zdCBUTFMgYXBwbGljYXRp b25zIHdpbGwgbm90IHdhbnQgcG9zdC1oYW5kc2hha2UgY2xpZW50IGF1dGggZW5hYmxlZCBhcyBp dCBzaWduaWZpY2FudGx5IGNoYW5nZXMgdGhlIGF1dGhlbnRpY2F0aW9uIHBpY3R1cmUgKFRMUy1s ZXZlbCBhdXRoIGNhbiBjaGFuZ2UgbWlkLXN0cmVhbSkgYW5kIHdvdWxkIGhhdmUgaXQgb2ZmLiBJ IHdvdWxkIGxpa2UgZGlzYWJsaW5nIHBvc3QtaGFuZHNoYWtlIGNsaWVudCBhdXRoIHRvLCBhcyBh IHJlc3VsdCwgZGlzYWJsZSBhbGwgc3VjaCBUTFMtbGV2ZWwgbWlkLXN0cmVhbSBzd2l0Y2hlcy4g Rm9yIHNvbWUgbGVnYWN5IHVzZXMgb2YgSFRUUC8xLjEsIHN1cmUsIHBvc3QtaGFuZHNoYWtlIGF1 dGggd2lsbCBiZSBlbmFibGVkIGFuZCB0aGlzIGZlYXR1cmUgZG9lc24ndCBkbyBtdWNoIGhhcm0u IChCdXQgaXQgYWxzbyBkb2Vzbid0IGhlbHAuIFRoZSBzZXJ2ZXIgY2FuIGp1c3QgYXMgZWFzaWx5 IHNlbmQgcG9zdC1oYW5kc2hha2UgQ2VydGlmaWNhdGVSZXF1ZXN0IHJpZ2h0IGFmdGVyIHRoZSBo YW5kc2hha2UuKQ0KDQpGb3IgMS1SVFQsIHRoZXJlJ3Mgbm8gbWlkLXN0cmVhbSB0cmFuc2l0aW9u IHByb2JsZW0uIFRob3VnaCBpdCBpcyBraW5kIG9mIHdlaXJkIGZvciBQU0stcmVzdW1wdGlvbi4g UFNLLXJlc3VtcHRpb24gYWxyZWFkeSBpbXBsaWNpdGx5IGNhcnJpZXMgYSBzZXQgb2YgY2VydGlm aWNhdGUtYmFzZWQgaWRlbnRpdGllcyBmcm9tIHRoZSBwcmV2aW91cyBydW4sIGJ1dCB3ZSdyZSBz YXlpbmcgdGhlIHNlcnZlciBtYXkgYXNrIHRoZSBjbGllbnQgdG8gcGljayBhIGRpZmZlcmVudCBv bmUgKGJ1dCBub3QgdmljZSB2ZXJzYSkuIElzIHRoZSBjbGllbnQgc3RpbGwgYXV0aGVudGljYXRl ZCBhcyB0aGUgcHJldmlvdXMgb25lIHRvbywgb3IganVzdCB0aGUgbmV3IG9uZT8NCg0KRGF2aWQN Cg0KT24gVGh1LCBNYXkgMTIsIDIwMTYgYXQgMzoyNiBQTSBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB0aGF0IHRoZSBjdXJy ZW50IGRyYWZ0IGlzIGFtYmlndW91cyBvbiB0aGlzIHBvaW50IGJ1dCBJIHRoaW5rIHRoZSBxdWVz dGlvbiBpcyB3aGF0IHRoZSByaWdodA0KdGhpbmcgaXMuIE15IGludHVpdGlvbiBoZXJlIGlzIHRo YXQgd2Ugc2hvdWxkIHRyeSB0byBtYWtlIHRoZSBjbGllbnQncyBzaWRlIGFuZCB0aGUgc2VydmVy J3Mgc2lkZQ0KbW9yZSBpbmRlcGVuZGVudCBzbyB0aGF0IHlvdSBjYW4gaGF2ZSBjbGllbnQgYXV0 aCBpbiBlaXRoZXIgY2FzZS4gR2l2ZW4gdGhhdCB3ZSdyZSBnb2luZyB0bw0KYWxsb3cgcG9zdC1o YW5kc2hha2UgY2xpZW50IGF1dGggd2hlbiB5b3UgcmVzdW1lLCBpdCdzIGp1c3Qgbm90IGNsZWFy IHRvIG1lIHdoeSB5b3Ugd291bGRuJ3QNCmFsbG93IGluLWhhbmRzaGFrZSBjbGllbnQtYXV0aC4g SSdtIG5vdCBzdXJlIGl0J3MgYSBoaWxsIEknbSB3aWxsaW5nIHRvIGRpZSBvbiB0aG91Z2guDQoN Ci1Fa3INCg0KDQoNCk9uIFRodSwgTWF5IDEyLCAyMDE2IGF0IDk6MDYgUE0sIERhdmlkIEJlbmph bWluIDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc8bWFpbHRvOmRhdmlkYmVuQGNocm9taXVtLm9yZz4+ IHdyb3RlOg0KV2hpY2ggUFNLL25vbi1QU0sgc3ltbWV0cnkgYXJlIHlvdSByZWZlcnJpbmcgdG8/ IEkgZGlkbid0IHRoaW5rIDEuMyBjdXJyZW50bHkgYWxsb3dlZCBDZXJ0aWZpY2F0ZVJlcXVlc3Qg aW4gYSBQU0sgaGFuZHNoYWtlIGVpdGhlciwgb3IgYXJlIHlvdSByZWZlcnJpbmcgdG8gc29tZXRo aW5nIGVsc2U/DQoNCkFjdHVhbGx5LCBsb29raW5nIGF0IHRoZSB0ZXh0IGFnYWluLCBpdCdzIGEg bGl0dGxlIGNvbmZ1c2luZyByaWdodCBub3cgd2hlcmUgQ2VydGlmaWNhdGVSZXF1ZXN0IGlzIGFu ZCBpc24ndCBhbGxvd2VkLiBUaGUgbWVzc2FnZSBmbG93IGluIDYuMi4yIGltcGxpZXMgYSBQU0sg cmVzdW1wdGlvbiBoYW5kc2hha2UgZG9lcyBub3Qgc2VuZCBDZXJ0aWZpY2F0ZVJlcXVlc3QuIFRo ZSBmbG93IGluIDYuMi4zIGltcGxpZXMgYSAwLVJUVCBoYW5kc2hha2UgZG9lcywgYnV0IGl0IGRl c2NyaWJlcyB0aGUgMC1SVFQgaGFuZHNoYWtlIGFzOg0KDQoiIiINCldoZW4gcmVzdW1pbmcgdmlh IGEgUFNLLCBjbGllbnRzIGNhbiBhbHNvIHNlbmQgZGF0YSBvbiB0aGVpciBmaXJzdCBmbGlnaHQg KOKAnGVhcmx5IGRhdGHigJ0pLiBUaGlzIGRhdGEgaXMgZW5jcnlwdGVkIHNvbGVseSB1bmRlciBr ZXlzIGRlcml2ZWQgdXNpbmcgdGhlIFBTSyBhcyB0aGUgc3RhdGljIHNlY3JldC4gQXMgc2hvd24g aW4gRmlndXJlIDQsIHRoZSBaZXJvLVJUVCBkYXRhIGlzIGp1c3QgYWRkZWQgdG8gdGhlIDEtUlRU IGhhbmRzaGFrZSBpbiB0aGUgZmlyc3QgZmxpZ2h0LCB0aGUgcmVzdCBvZiB0aGUgaGFuZHNoYWtl IHVzZXMgdGhlIHNhbWUgbWVzc2FnZXMuDQoiIiINCg0KVGhpcyBzdWdnZXN0cyBpdCBzaG91bGQg bWF0Y2ggNi4yLjIgaW4gd2hldGhlciBDZXJ0aWZpY2F0ZVJlcXVlc3QgaXMgYWxsb3dlZC4gQXJn dWFibHkgdGhlIHJ1bGVzIHNob3VsZCBiZSBpbiB0ZXh0LCBub3QgZGlhZ3JhbXMsIGJ1dCB0aGUg dGV4dCBpbiA2LjMuMy4yIGp1c3Qgc2F5czoNCg0KIiIiDQpBIG5vbi1hbm9ueW1vdXMgc2VydmVy IGNhbiBvcHRpb25hbGx5IHJlcXVlc3QgYSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSBjbGllbnQsIGlm IGFwcHJvcHJpYXRlIGZvciB0aGUgc2VsZWN0ZWQgY2lwaGVyIHN1aXRlLiBUaGlzIG1lc3NhZ2Us IGlmIHNlbnQsIHdpbGwgZm9sbG93IEVuY3J5cHRlZEV4dGVuc2lvbnMuDQoiIiINCg0KKEknbSBn dWVzc2luZyAibm9uLWFub255bW91cyIgaXMgYSBob2xkb3ZlciBmcm9tIFRMUyAxLjIncyB0ZXh0 LikNCg0KSW4gVExTIDEuMiwgSSBiZWxpZXZlIENlcnRpZmljYXRlUmVxdWVzdCBpbiBhIFBTSy1i YXNlZCBjaXBoZXIgd2Fzbid0IGFsbG93ZWQuIFJGQyA0Mjc5IGV4cGxpY2l0bHkgc2F5cyBpdCdz IG5vdCBhbGxvd2VkIGluIHBsYWluIFBTSy4gSXQncyBub3QgY2xlYXIgd2hldGhlciB0aGF0IGFw cGxpZXMgdG8gREhFX1BTSywgYnV0IEkgdGhpbmsgdGhhdCBjb21iaW5lZCB3aXRoIDEuMidzICJu b24tYW5vbnltb3VzIiBydWxlIGdpdmVzIGNsaWVudCBhdXRoID0+IGNlcnRpZmljYXRlLWJhc2Vk IGNpcGhlciBhcyB0aGUgbW9zdCByZWFzb25hYmxlIGludGVycHJldGF0aW9uLg0KDQpEYXZpZA0K DQpPbiBUaHUsIE1heSAxMiwgMjAxNiBhdCAxMToxOSBBTSBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KSW50ZXJlc3Rpbmcgc3VnZ2VzdGlv bi4gSSBzZWUgd2hhdCB5b3UgbWVhbiBhYm91dCBzeW1tZXRyeSB3aXRoIHRoZSBzZXJ2ZXINCg0K VGhlIHN5bW1ldHJ5IEkgd2FzIG9wdGltaXppbmcgZm9yIGlzIHRoYXQgdGhlIFBTSyBhbmQgbm9u LVBTSyBoYW5kc2hha2UsIGFuZCBJIHRoaW5rIGZyb20gdGhhdCBwZXJzcGVjdGl2ZSB0aGUgY3Vy cmVudCBkZXNpZ24gaXMgc2ltcGxlciwgc28gSSBzZWUgaXQgYm90aCB3YXlzLg0KDQpXUlQgdG8g dGhlIDAuNVJUVCBkYXRhLCBIdWdvIEtyYXdjenlrIGhhcyBkb25lIHNvbWUgbmljZSB3b3JrIG9u IGFuYWx5emluZyB0aGlzIGNhc2UgYW5kIEkgdGhpbmsgd2UncmUgc3RhcnRpbmcgdG8gZ2V0IG1v cmUgY29tZm9ydCB3aXRoIHRoYXQuDQoNClNvLCBub3Qgc3VyZSB3aGF0IEkgdGhpbmsuLi4NCg0K LUVrcg0KDQoNCg0KDQoNCk9uIFdlZCwgTWF5IDExLCAyMDE2IGF0IDEwOjQ0IFBNLCBEYXZpZCBC ZW5qYW1pbiA8ZGF2aWRiZW5AY2hyb21pdW0ub3JnPG1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5v cmc+PiB3cm90ZToNClRoZSAwLVJUVCBoYW5kc2hha2Ugb3JpZ2luYWxseSBoYWQgdHdvIHBsYWNl cyB3aXRoIGEgY2xpZW50IENlcnRpZmljYXRlICsgQ2VydGlmaWNhdGVWZXJpZnk6IGluIHRoZSAw LVJUVCBmbG93IGFuZCBpbiB0aGUgc2Vjb25kIEZpbmlzaGVkIGJsb2NrIGluIHJlc3BvbnNlIHRv IGEgc2VydmVyIENlcnRpZmljYXRlUmVxdWVzdC4gV2UndmUgZHJvcHBlZCB0aGUgZmlyc3Qgbm93 LiBJIHByb3Bvc2Ugd2UgZHJvcCB0aGUgc2Vjb25kIHRvby4gQ2xpZW50IGF1dGggd2l0aCAwLVJU VCBpcyBzb2xlbHkgY2FycmllZCBvdmVyIHZpYSByZXN1bXB0aW9uLiAoSSBtZW50aW9uZWQgdGhp cyBwcmV2aW91c2x5LCBidXQgd2l0aCAwLVJUVCBsb29raW5nIGNsb3NlciB0byByZXN1bXB0aW9u IGFuZCB0aGUgSUVURiA5NSBkZWNpc2lvbiBvbiAwLjUtUlRUIGRhdGEsIEkgdGhpbmsgdGhlIGNh c2UgaXMgY2xlYXJlci4pDQoNClRoaXMgbWFrZXMgNi4yLjMgbW9yZSBjb25zaXN0ZW50IHdpdGgg Ni4yLjIgd2hlcmUgbmVpdGhlciBzaWRlIGF1dGhlbnRpY2F0ZXMgaW4gYSByZXN1bXB0aW9uIGhh bmRzaGFrZS4gMC1SVFQgaXMgbXVjaCBtb3JlIHNpbWlsYXIgdG8gcmVzdW1wdGlvbiB3aXRoIG1v c3QgcGFyYW1ldGVycyBjYXJyeWluZyBvdmVyIGFueXdheS4NCg0KMS1SVFQgY2xpZW50IGF1dGgg aW4gYSAwLVJUVCBoYW5kc2hha2UgYWxzbyBpbnZpdGVzIG1vcmUgb2YgdGhlIHJldHJvYWN0aXZl IGF1dGggY29uZnVzaW9uIGFzIHdpdGggcG9zdC1oYW5kc2hha2UgYXV0aC4gVGhlIGNsaWVudCBz dHJlYW0gc3dpdGNoZXMgZnJvbSB1bmF1dGhlbnRpY2F0ZWQgdG8gYXV0aGVudGljYXRlZC4gSSBi ZWxpZXZlIHRoaXMgd2FzIG9uZSBvZiB0aGUgcmVhc29ucyB3ZSBhZ3JlZWQgYXQgSUVURiA5NSB0 byBkaXNjb3VyYWdlL2ZvcmJpZCAobm90IHN1cmUgd2hpY2gpIHNlbmRpbmcgMC41LVJUVCBkYXRh IGZvbGxvd2luZyBhIENlcnRpZmljYXRlUmVxdWVzdC4gSW4taGFuZHNoYWtlIENlcnRpZmljYXRl UmVxdWVzdCBlaXRoZXIgcmVxdWlyZXMgdGhpcyBkaXNjb3VyYWdlZCBzaXR1YXRpb24gb3IgYWNj ZXB0aW5nIDAtUlRUIGRhdGEgd2l0aG91dCBzZW5kaW5nIDAuNS1SVFQgZGF0YSwgd2hpY2ggaXMg bGFyZ2VseSBwb2ludGxlc3MuDQoNCldlIGFjY2VwdGVkIHRoZSByZXRyb2FjdGl2ZSBhdXRoIGlz c3VlIGluIHBvc3QtaGFuZHNoYWtlIGF1dGgsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBsaW1pdCBp dCB0byB0aGF0LiBGb3IgaW1wbGVtZW50YXRpb25zLCBCb3JpbmdTU0wgbWFkZSBhY2NlcHRpbmcg cmVuZWdvIGFuIG9wdC1pbiBmZWF0dXJlLiBJIGV4cGVjdCB3ZSdkIGRvIHRoZSBzYW1lIGZvciBw b3N0LWhhbmRzaGFrZSBhdXRoLiBGb3Igc3BlY3MsIG9uZSBtaWdodCBzcGVjaWZ5IHRoYXQgcG9z dC1oYW5kc2hha2UgYXV0aGVudGljYXRpb24gaXMgZm9yYmlkZGVuLiBIVFRQLzIgZGlkIHRoaXMg Zm9yIHJlbmVnb3RpYXRpb24uIEkgaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyB0aGUgSFRUUC8yIGNs aWVudCBjZXJ0IHNhZ2EgYXMgY2xvc2VseSwgYnV0IGRyYWZ0LXRob21zb24taHR0cDItY2xpZW50 LWNlcnRzLTAyIGlzIHRoZSBjdXJyZW50IHBsYW4sIHJpZ2h0PyBJZiBzbywgSFRUUC8yIHNob3Vs ZCBmb3JiaWQgVExTLWxldmVsIHBvc3QtaGFuZHNoYWtlIGF1dGggdG9vLg0KDQpJbiBib3RoIGNh c2VzLCBleGNsdWRpbmcgcG9zdC1oYW5kc2hha2UgYXV0aCBzaG91bGQgZXhjbHVkZSBhbnkgdHJh bnNpdGlvbiBmcm9tIHVuYXV0aGVudGljYXRlZCB0byBhdXRoZW50aWNhdGVkIGluIHRoZSBzdHJl YW0uIEluc3RlYWQsIGlmIHlvdSB3YW50IHRvIGNoYW5nZSBhdXRoZW50aWNhdGlvbiBzdGF0ZSwg c2VuZCBhIHBvc3QtaGFuZHNoYWtlIENlcnRpZmljYXRlUmVxdWVzdCwgYXMgeW91IHdvdWxkIGhh dmUgbm9ybWFsbHkuDQoNCkRhdmlkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRM U0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoN Cg0K --_000_BN3PR03MB14459AC22FD4529B1E246F7A8C730BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI1MDA0Mjc4MDsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQzNzUxMTk4MCAtMTA4ODc0 NTcyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6ODsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklzIHRoZSBjbGllbnQgc3RpbGwg YXV0aGVudGljYXRlZCBhcyB0aGUgcHJldmlvdXMgb25lIHRvbywgb3IganVzdCB0aGUgbmV3IG9u ZT88c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgdGhlIGNsaWVudCB0aGF0IGhhcyBhdXRoZW50aWNhdGVkIGFzIEEgYW5kIHRoZW4gQiBpbiB0 aGUgc2FtZSBUTFMgc2Vzc2lvbiwgY2Fu4oCZdCBjbGFpbSB0byBub3QgYmUgQSBhbnltb3JlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+RGF2aWQgQmVuamFtaW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAxMiwg MjAxNiAxMjo0MSBQTTxicj4NCjxiPlRvOjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbVExTXSBJbi1oYW5kc2hha2UgQ2VydGlmaWNhdGVSZXF1ZXN0IGFuZCAwLVJUVDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodCwgSSB3YW50IHRv IGZvcmJpZCBpdCBwcmVjaXNlbHkgYmVjYXVzZSBJIGRvbid0IHdhbnQgdG8gYWxsb3cgcG9zdC1o YW5kc2hha2UgY2xpZW50IGF1dGguIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PciByYXRoZXIsIEkgZXhwZWN0IG1vc3QgVExTIGFwcGxp Y2F0aW9ucyB3aWxsIG5vdCB3YW50IHBvc3QtaGFuZHNoYWtlIGNsaWVudCBhdXRoIGVuYWJsZWQg YXMgaXQgc2lnbmlmaWNhbnRseSBjaGFuZ2VzIHRoZSBhdXRoZW50aWNhdGlvbiBwaWN0dXJlIChU TFMtbGV2ZWwgYXV0aCBjYW4gY2hhbmdlIG1pZC1zdHJlYW0pIGFuZCB3b3VsZCBoYXZlIGl0IG9m Zi4gSSB3b3VsZCBsaWtlIGRpc2FibGluZyBwb3N0LWhhbmRzaGFrZQ0KIGNsaWVudCBhdXRoIHRv LCBhcyBhIHJlc3VsdCwgZGlzYWJsZSBhbGwgc3VjaCBUTFMtbGV2ZWwgbWlkLXN0cmVhbSBzd2l0 Y2hlcy4gRm9yIHNvbWUgbGVnYWN5IHVzZXMgb2YgSFRUUC8xLjEsIHN1cmUsIHBvc3QtaGFuZHNo YWtlIGF1dGggd2lsbCBiZSBlbmFibGVkIGFuZCB0aGlzIGZlYXR1cmUgZG9lc24ndCBkbyBtdWNo IGhhcm0uIChCdXQgaXQgYWxzbyBkb2Vzbid0IGhlbHAuIFRoZSBzZXJ2ZXIgY2FuIGp1c3QgYXMg ZWFzaWx5IHNlbmQgcG9zdC1oYW5kc2hha2UNCiBDZXJ0aWZpY2F0ZVJlcXVlc3QgcmlnaHQgYWZ0 ZXIgdGhlIGhhbmRzaGFrZS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciAxLVJUVCwgdGhlcmUncyBubyBtaWQtc3RyZWFtIHRyYW5zaXRp b24gcHJvYmxlbS4gVGhvdWdoIGl0IGlzIGtpbmQgb2Ygd2VpcmQgZm9yIFBTSy1yZXN1bXB0aW9u LiBQU0stcmVzdW1wdGlvbiBhbHJlYWR5IGltcGxpY2l0bHkgY2FycmllcyBhIHNldCBvZiBjZXJ0 aWZpY2F0ZS1iYXNlZCBpZGVudGl0aWVzIGZyb20gdGhlIHByZXZpb3VzIHJ1biwgYnV0IHdlJ3Jl IHNheWluZyB0aGUgc2VydmVyIG1heSBhc2sNCiB0aGUgY2xpZW50IHRvIHBpY2sgYSBkaWZmZXJl bnQgb25lIChidXQgbm90IHZpY2UgdmVyc2EpLiBJcyB0aGUgY2xpZW50IHN0aWxsIGF1dGhlbnRp Y2F0ZWQgYXMgdGhlIHByZXZpb3VzIG9uZSB0b28sIG9yIGp1c3QgdGhlIG5ldyBvbmU/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSAx MiwgMjAxNiBhdCAzOjI2IFBNIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JA cnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhh dCB0aGUgY3VycmVudCBkcmFmdCBpcyBhbWJpZ3VvdXMgb24gdGhpcyBwb2ludCBidXQgSSB0aGlu ayB0aGUgcXVlc3Rpb24gaXMgd2hhdCB0aGUgcmlnaHQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj50aGluZyBpcy4gTXkgaW50dWl0aW9uIGhlcmUgaXMgdGhhdCB3 ZSBzaG91bGQgdHJ5IHRvIG1ha2UgdGhlIGNsaWVudCdzIHNpZGUgYW5kIHRoZSBzZXJ2ZXIncyBz aWRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5t b3JlIGluZGVwZW5kZW50IHNvIHRoYXQgeW91IGNhbiBoYXZlIGNsaWVudCBhdXRoIGluIGVpdGhl ciBjYXNlLiBHaXZlbiB0aGF0IHdlJ3JlIGdvaW5nIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbGxvdyBwb3N0LWhhbmRzaGFrZSBjbGllbnQg YXV0aCB3aGVuIHlvdSByZXN1bWUsIGl0J3MganVzdCBub3QgY2xlYXIgdG8gbWUgd2h5IHlvdSB3 b3VsZG4ndDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+YWxsb3cgaW4taGFuZHNoYWtlIGNsaWVudC1hdXRoLiBJJ20gbm90IHN1cmUgaXQncyBhIGhp bGwgSSdtIHdpbGxpbmcgdG8gZGllIG9uIHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXkgMTIsIDIwMTYg YXQgOTowNiBQTSwgRGF2aWQgQmVuamFtaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZGJlbkBj aHJvbWl1bS5vcmciIHRhcmdldD0iX2JsYW5rIj5kYXZpZGJlbkBjaHJvbWl1bS5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hpY2ggUFNLL25vbi1QU0sgc3ltbWV0cnkgYXJlIHlvdSByZWZlcnJpbmcgdG8/ IEkgZGlkbid0IHRoaW5rIDEuMyBjdXJyZW50bHkgYWxsb3dlZCBDZXJ0aWZpY2F0ZVJlcXVlc3Qg aW4gYSBQU0sgaGFuZHNoYWtlIGVpdGhlciwgb3IgYXJlIHlvdSByZWZlcnJpbmcgdG8gc29tZXRo aW5nIGVsc2U/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Y3R1YWxseSwgbG9va2luZyBhdCB0aGUgdGV4dCBhZ2FpbiwgaXQncyBhIGxpdHRsZSBjb25mdXNp bmcgcmlnaHQgbm93IHdoZXJlIENlcnRpZmljYXRlUmVxdWVzdCBpcyBhbmQgaXNuJ3QgYWxsb3dl ZC4gVGhlIG1lc3NhZ2UgZmxvdyBpbiA2LjIuMiBpbXBsaWVzIGEgUFNLIHJlc3VtcHRpb24gaGFu ZHNoYWtlIGRvZXMgbm90IHNlbmQgQ2VydGlmaWNhdGVSZXF1ZXN0LiBUaGUgZmxvdyBpbiA2LjIu MyBpbXBsaWVzDQogYSAwLVJUVCBoYW5kc2hha2UgZG9lcywgYnV0IGl0IGRlc2NyaWJlcyB0aGUg MC1SVFQgaGFuZHNoYWtlIGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gcmVzdW1pbmcgdmlhIGEgUFNLLCBj bGllbnRzIGNhbiBhbHNvIHNlbmQgZGF0YSBvbiB0aGVpciBmaXJzdCBmbGlnaHQgKOKAnGVhcmx5 IGRhdGHigJ0pLiBUaGlzIGRhdGEgaXMgZW5jcnlwdGVkIHNvbGVseSB1bmRlciBrZXlzIGRlcml2 ZWQgdXNpbmcgdGhlIFBTSyBhcyB0aGUgc3RhdGljIHNlY3JldC4gQXMgc2hvd24gaW4gRmlndXJl IDQsIHRoZSBaZXJvLVJUVCBkYXRhIGlzIGp1c3QgYWRkZWQgdG8gdGhlDQogMS1SVFQgaGFuZHNo YWtlIGluIHRoZSBmaXJzdCBmbGlnaHQsIHRoZSByZXN0IG9mIHRoZSBoYW5kc2hha2UgdXNlcyB0 aGUgc2FtZSBtZXNzYWdlcy48YnI+DQomcXVvdDsmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzdWdnZXN0cyBpdCBz aG91bGQgbWF0Y2ggNi4yLjIgaW4gd2hldGhlciBDZXJ0aWZpY2F0ZVJlcXVlc3QgaXMgYWxsb3dl ZC4mbmJzcDtBcmd1YWJseSB0aGUgcnVsZXMgc2hvdWxkIGJlIGluIHRleHQsIG5vdCBkaWFncmFt cywgYnV0IHRoZSB0ZXh0IGluIDYuMy4zLjIganVzdCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbm9uLWFu b255bW91cyBzZXJ2ZXIgY2FuIG9wdGlvbmFsbHkgcmVxdWVzdCBhIGNlcnRpZmljYXRlIGZyb20g dGhlIGNsaWVudCwgaWYgYXBwcm9wcmlhdGUgZm9yIHRoZSBzZWxlY3RlZCBjaXBoZXIgc3VpdGUu IFRoaXMgbWVzc2FnZSwgaWYgc2VudCwgd2lsbCBmb2xsb3cgRW5jcnlwdGVkRXh0ZW5zaW9ucy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90 OyZxdW90OyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4oSSdtIGd1ZXNzaW5nICZxdW90O25vbi1hbm9ueW1vdXMmcXVvdDsgaXMgYSBo b2xkb3ZlciBmcm9tIFRMUyAxLjIncyB0ZXh0Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gVExTIDEuMiwgSSBiZWxpZXZlIENlcnRpZmlj YXRlUmVxdWVzdCBpbiBhIFBTSy1iYXNlZCBjaXBoZXIgd2Fzbid0IGFsbG93ZWQuIFJGQyA0Mjc5 IGV4cGxpY2l0bHkgc2F5cyBpdCdzIG5vdCBhbGxvd2VkIGluIHBsYWluIFBTSy4gSXQncyBub3Qg Y2xlYXIgd2hldGhlciB0aGF0IGFwcGxpZXMgdG8gREhFX1BTSywgYnV0IEkgdGhpbmsgdGhhdCBj b21iaW5lZCB3aXRoIDEuMidzICZxdW90O25vbi1hbm9ueW1vdXMmcXVvdDsNCiBydWxlIGdpdmVz IGNsaWVudCBhdXRoID0mZ3Q7IGNlcnRpZmljYXRlLWJhc2VkIGNpcGhlciBhcyB0aGUgbW9zdCBy ZWFzb25hYmxlIGludGVycHJldGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+RGF2aWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSAxMiwgMjAxNiBhdCAx MToxOSBBTSBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJl c3Rpbmcgc3VnZ2VzdGlvbi4gSSBzZWUgd2hhdCB5b3UgbWVhbiBhYm91dCBzeW1tZXRyeSB3aXRo IHRoZSBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBzeW1tZXRyeSBJIHdhcyBvcHRpbWl6aW5nIGZvciBpcyB0aGF0IHRoZSBQU0sgYW5kIG5v bi1QU0sgaGFuZHNoYWtlLCBhbmQgSSB0aGluayBmcm9tIHRoYXQgcGVyc3BlY3RpdmUgdGhlIGN1 cnJlbnQgZGVzaWduIGlzIHNpbXBsZXIsIHNvIEkgc2VlIGl0IGJvdGggd2F5cy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V1JUIHRvIHRoZSAw LjVSVFQgZGF0YSwgSHVnbyBLcmF3Y3p5ayBoYXMgZG9uZSBzb21lIG5pY2Ugd29yayBvbiBhbmFs eXppbmcgdGhpcyBjYXNlIGFuZCBJIHRoaW5rIHdlJ3JlIHN0YXJ0aW5nIHRvIGdldCBtb3JlIGNv bWZvcnQgd2l0aCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Tbywgbm90IHN1cmUgd2hhdCBJIHRoaW5rLi4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIE1heSAxMSwgMjAxNiBhdCAxMDo0NCBQTSwgRGF2aWQgQmVuamFtaW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmciIHRhcmdldD0iX2JsYW5r Ij5kYXZpZGJlbkBjaHJvbWl1bS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIDAtUlRUIGhhbmRzaGFrZSBvcmlnaW5hbGx5IGhhZCB0d28gcGxhY2Vz IHdpdGggYSBjbGllbnQgQ2VydGlmaWNhdGUmbmJzcDsmIzQzOyBDZXJ0aWZpY2F0ZVZlcmlmeTog aW4gdGhlIDAtUlRUIGZsb3cgYW5kIGluIHRoZSBzZWNvbmQgRmluaXNoZWQgYmxvY2sgaW4gcmVz cG9uc2UgdG8gYSBzZXJ2ZXIgQ2VydGlmaWNhdGVSZXF1ZXN0LiZuYnNwO1dlJ3ZlIGRyb3BwZWQg dGhlIGZpcnN0IG5vdy4gSSBwcm9wb3NlIHdlIGRyb3AgdGhlDQogc2Vjb25kIHRvby4gQ2xpZW50 IGF1dGggd2l0aCAwLVJUVCBpcyBzb2xlbHkgY2FycmllZCBvdmVyIHZpYSByZXN1bXB0aW9uLiAo SSBtZW50aW9uZWQgdGhpcyBwcmV2aW91c2x5LCBidXQgd2l0aCAwLVJUVCBsb29raW5nIGNsb3Nl ciB0byByZXN1bXB0aW9uIGFuZCB0aGUgSUVURiA5NSBkZWNpc2lvbiBvbiAwLjUtUlRUIGRhdGEs IEkgdGhpbmsgdGhlIGNhc2UgaXMgY2xlYXJlci4pPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG1ha2VzIDYuMi4zIG1vcmUgY29uc2lzdGVudCB3aXRo IDYuMi4yIHdoZXJlIG5laXRoZXIgc2lkZSBhdXRoZW50aWNhdGVzIGluIGEgcmVzdW1wdGlvbiBo YW5kc2hha2UuIDAtUlRUIGlzIG11Y2ggbW9yZSBzaW1pbGFyIHRvIHJlc3VtcHRpb24gd2l0aCBt b3N0IHBhcmFtZXRlcnMgY2Fycnlpbmcgb3ZlciBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEtUlRUIGNsaWVudCBhdXRoIGluIGEg MC1SVFQgaGFuZHNoYWtlIGFsc28gaW52aXRlcyBtb3JlIG9mIHRoZSByZXRyb2FjdGl2ZSBhdXRo IGNvbmZ1c2lvbiBhcyB3aXRoIHBvc3QtaGFuZHNoYWtlIGF1dGguIFRoZSBjbGllbnQgc3RyZWFt IHN3aXRjaGVzIGZyb20gdW5hdXRoZW50aWNhdGVkIHRvIGF1dGhlbnRpY2F0ZWQuJm5ic3A7SSBi ZWxpZXZlIHRoaXMgd2FzIG9uZSBvZiB0aGUgcmVhc29ucyB3ZSBhZ3JlZWQgYXQNCiBJRVRGIDk1 IHRvIGRpc2NvdXJhZ2UvZm9yYmlkIChub3Qgc3VyZSB3aGljaCkgc2VuZGluZyAwLjUtUlRUIGRh dGEgZm9sbG93aW5nIGEgQ2VydGlmaWNhdGVSZXF1ZXN0LiBJbi1oYW5kc2hha2UgQ2VydGlmaWNh dGVSZXF1ZXN0IGVpdGhlciByZXF1aXJlcyB0aGlzIGRpc2NvdXJhZ2VkIHNpdHVhdGlvbiBvciBh Y2NlcHRpbmcgMC1SVFQgZGF0YSB3aXRob3V0IHNlbmRpbmcgMC41LVJUVCBkYXRhLCB3aGljaCBp cyBsYXJnZWx5IHBvaW50bGVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2UgYWNjZXB0ZWQgdGhlIHJldHJvYWN0aXZlIGF1dGggaXNzdWUg aW4gcG9zdC1oYW5kc2hha2UgYXV0aCwgYnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGxpbWl0IGl0IHRv IHRoYXQuIEZvciBpbXBsZW1lbnRhdGlvbnMsIEJvcmluZ1NTTCBtYWRlIGFjY2VwdGluZyByZW5l Z28gYW4gb3B0LWluIGZlYXR1cmUuIEkgZXhwZWN0IHdlJ2QgZG8gdGhlIHNhbWUgZm9yIHBvc3Qt aGFuZHNoYWtlIGF1dGguJm5ic3A7Rm9yIHNwZWNzLA0KIG9uZSBtaWdodCBzcGVjaWZ5IHRoYXQg cG9zdC1oYW5kc2hha2UgYXV0aGVudGljYXRpb24gaXMgZm9yYmlkZGVuLiBIVFRQLzIgZGlkIHRo aXMgZm9yIHJlbmVnb3RpYXRpb24uJm5ic3A7SSBoYXZlbid0IGJlZW4gZm9sbG93aW5nIHRoZSBI VFRQLzIgY2xpZW50IGNlcnQgc2FnYSBhcyBjbG9zZWx5LCBidXQgZHJhZnQtdGhvbXNvbi1odHRw Mi1jbGllbnQtY2VydHMtMDIgaXMgdGhlIGN1cnJlbnQgcGxhbiwgcmlnaHQ/IElmIHNvLCBIVFRQ LzIgc2hvdWxkDQogZm9yYmlkIFRMUy1sZXZlbCBwb3N0LWhhbmRzaGFrZSBhdXRoIHRvby48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYm90 aCBjYXNlcywgZXhjbHVkaW5nIHBvc3QtaGFuZHNoYWtlIGF1dGggc2hvdWxkIGV4Y2x1ZGUgYW55 IHRyYW5zaXRpb24gZnJvbSB1bmF1dGhlbnRpY2F0ZWQgdG8gYXV0aGVudGljYXRlZCBpbiB0aGUg c3RyZWFtLiBJbnN0ZWFkLCBpZiB5b3Ugd2FudCB0byBjaGFuZ2UgYXV0aGVudGljYXRpb24gc3Rh dGUsIHNlbmQgYSBwb3N0LWhhbmRzaGFrZSBDZXJ0aWZpY2F0ZVJlcXVlc3QsIGFzIHlvdSB3b3Vs ZA0KIGhhdmUgbm9ybWFsbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkRhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRM U0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB14459AC22FD4529B1E246F7A8C730BN3PR03MB1445namp_-- From nobody Thu May 12 14:23: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 CC28512B01B for ; Thu, 12 May 2016 14:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 6tYQt4od0IBJ for ; Thu, 12 May 2016 14:23:52 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B1612B034 for ; Thu, 12 May 2016 14:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2003; q=dns/txt; s=iport; t=1463088232; x=1464297832; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Q3hIufiQEC0tbyfy2Gx/1SLZ0hKRAF5zZ4eX7SQ6mgY=; b=H0vUWAYEsvXGyhsaFYsTTcSEfY6kUFCSOwp4QGcfFrgt+ZRAJurHhPmh dCmFEYizt82wlK1DpGXlUed/8mh1FQDBa3pD/UpeWUfh7CeHp8T8CdwE5 XnQM3l9xw5y9azInvmIG/03CbdVilc0FtWppm71v15KXgJNYeKU9yf19Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgA78zRX/5xdJa1egzhVfga5UQENg?= =?us-ascii?q?XYihXICgTk4FAEBAQEBAQFlJ4RCAQEBAwE6SwQCAQgRBAEBHwkHMhQJCAIEARI?= =?us-ascii?q?IiB8IDr1UAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJYRMihgFkxuFDAGFfYgZg?= =?us-ascii?q?XCET4QlhDyPQAEeAQFCg2tuAYcxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208";a="272850587" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2016 21:23:51 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4CLNpMd026002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 21:23:51 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.1104.5; Thu, 12 May 2016 17:23:50 -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.1104.009; Thu, 12 May 2016 17:23:50 -0400 From: "Scott Fluhrer (sfluhrer)" To: Fedor Brunner , "tls@ietf.org" Thread-Topic: [TLS] removing 128-bit ciphers in TLS 1.3 Thread-Index: AQHRrCXDChyzKKM8dU2iRR/8CCOBAZ+1xuWg Date: Thu, 12 May 2016 21:23:50 +0000 Message-ID: References: <57343A63.9040605@azet.sk> In-Reply-To: <57343A63.9040605@azet.sk> 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.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] removing 128-bit ciphers 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: Thu, 12 May 2016 21:23:55 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Fedor Brunner > Sent: Thursday, May 12, 2016 4:10 AM > To: tls@ietf.org > Subject: [TLS] removing 128-bit ciphers in TLS 1.3 >=20 > Because of this attacks: >=20 > https://blog.cr.yp.to/20151120-batchattacks.html >=20 > could please consider to obsoleting 128-bit ciphers in TLS 1.3. But that attack isn't effective against the GCM-based cipher suite in TLS 1= .2. GCM (as implemented in TLS 1.2) has both sides agree on a 32 bit salt as a = part of the key agreement; a batch attack (such as Bernstein describes) doe= sn't work unless you happen to guess the 128 bit key *and* the 32 bit salt;= hence if you've collected 2**N TLS sessions, then the attacker would need = a work effort of about 2**{160-N) to happen to be able to decrypt 1 random = session. If we estimate N=3D50 (literally, 1 quadrillion TLS sessions, whi= ch I suspect is in the ballpark for number of TLS sessions world-wide), thi= s would put the work effort at 2**110. I suspect that's a bit much, even for the NSA. >=20 >=20 > For example AES-128 encryption has been removed from Suite B >=20 > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml One could argue that perhaps the reason NSA removed it from Suite B because= they couldn't break it; hence that would be an excellent reason to keep it= :-) Attempts at humor aside, I believe their reason was that they think AES-128= was insufficiently strong against a Quantum Computer. Now, I rather think= that we should be moving TLS to use Quantum Resistant cryptography; but as= of right now, TLS is rather far from that goal, and the symmetric key size= is a minor issue; how we perform key exchange and authentication are much = harder, and much more immediately important. Now, I wouldn't be against going only to AES-256 (the cost delta isn't that= much); however if we do it, it should be for valid reasons... From nobody Thu May 12 17:09: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 04CE312B049 for ; Thu, 12 May 2016 17:09:45 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrEZQodczQS5 for ; Thu, 12 May 2016 17:09:44 -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 8DD2312D0A3 for ; Thu, 12 May 2016 17:02:08 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x7so52492542qkd.3 for ; Thu, 12 May 2016 17:02:08 -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=keJEugJCs6WsY9UQf+XId9AW5EZueoTPeTWpXsz98a0=; b=KdUkdYGKaIDEVIo3Qrag7QvnS/T/xSEs270draC6VWn6TzJBRNTkq1EMfeGCenHB8F tMNPaikYiWhnZkc3Sx0sf08cvvasXwaytReyLjoWbsKSD7NXO3IQnwt6SPXj2r2lFAFa QMbwV2gYwzvOnfUAJoJRdISi4ec+orpZ8aah8= 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=keJEugJCs6WsY9UQf+XId9AW5EZueoTPeTWpXsz98a0=; b=NbSEL4gFljPp0P/gpoWOw0LM1Wql9+DRL8TgUDWdl7g7eNymWiBFHDmxWO0DvAihFe b+RSK/Wkdaa082pGGNK0lhM+9mXxlzYANuzDu79H/P5QBz6UfJqEnmxzAqH6YHE4bJ0V FJTzseuL+Qikm1EQ1ydd58tKhFqvXSO1t4cs0/+ceqBtp5L5KfStqJVMaXZfP7nazbng ughtN7/fSfMO4xQA3mZaKOjHYobgBo20asTfGmvLahJK8Cfo41c6FLtozm30T95KsOul 97mg1ckus/HSRMfb0vYrQbkyHhulG6NQ7vKn5FFSYDRS95fwJbnInV6Wz815JXU8sOkk qKlg== X-Gm-Message-State: AOPr4FUhe4ReBUlZoqVLPd1TVoPGUHE7ONFucNOmOV3C7IiZ3x0znuNRyI2TuSYPcPPXzA== X-Received: by 10.55.108.7 with SMTP id h7mr13218594qkc.136.1463097727739; Thu, 12 May 2016 17:02:07 -0700 (PDT) Received: from [172.16.0.112] ([96.231.223.55]) by smtp.gmail.com with ESMTPSA id d12sm7126702qhd.13.2016.05.12.17.02.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 May 2016 17:02:07 -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: Date: Thu, 12 May 2016 20:02:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] QUIC BoF for Berlin X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 00:09:46 -0000 On May 12, 2016, at 15:05, Ted Hardie wrote: >=20 > The IETF mailing list for discussion of this proposal has been set up = at quic@ietf.org.=20 To subscribe via the web: https://www.ietf.org/mailman/listinfo/quic spt= From nobody Fri May 13 06:02: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 93C4512D501 for ; Fri, 13 May 2016 06:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=2.299, RP_MATCHES_RCVD=-0.996, 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 x4zvy--n5GKc for ; Fri, 13 May 2016 06:02:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4510A12D1E7 for ; Fri, 13 May 2016 06:02:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 383119267; Fri, 13 May 2016 16:02: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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 2jRnnIMaInIB; Fri, 13 May 2016 16:02:32 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B33812310; Fri, 13 May 2016 16:02:32 +0300 (EEST) Date: Fri, 13 May 2016 16:02:30 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160513130230.GA22096@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] PR#449 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 13:02:37 -0000 On Wed, May 11, 2016 at 01:36:13PM +0200, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/449 > > In Buenos Aires, we agreed to add EncryptedExtensions from the client > in 0-RTT to carry the ticket age/elapsed_time. I have written this up in > the PR above. Comments welcome. How do clock rate errors affect the mechanism? It occurs to me that if clock isn't NTP-synced, clock rate can be quite a bit off, not just the time being off. On my main desktop, I estimate that if the clock wasn't NTP-synced, it would drift about 140ms per day (and I have seen a LOT worse clocks). -Ilari From nobody Sat May 14 15: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 ACAB712D6D8 for ; Sat, 14 May 2016 01:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, 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 372fwplTg8ri for ; Sat, 14 May 2016 01:28:22 -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 1496712D0C8 for ; Sat, 14 May 2016 01:28:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7997D180004; Sat, 14 May 2016 01:27:17 -0700 (PDT) To: jsalowey@cisco.com, abhijitc@cisco.com, mcgrew@cisco.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: <20160514082717.7997D180004@rfc-editor.org> Date: Sat, 14 May 2016 01:27:17 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 14 May 2016 15:09:36 -0700 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 May 2016 08:28:24 -0000 The following errata report has been submitted for RFC5288, "AES Galois Counter Mode (GCM) Cipher Suites for TLS". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5288&eid=4694 -------------------------------------- Type: Technical Reported by: Aaron Zauner Section: 6.1 Original Text ------------- AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse. Implementers should also understand the practical considerations of IV handling outlined in Section 9 of [GCM]. Corrected Text -------------- Security of AES-GCM requires that the "nonce" (number used once) is never reused. The IV construction in Section 3 does not prevent implementers from reusing the nonce by mistake. It is paramount that the implementer be aware of the security implications when a nonce is re-used even once. Nonce re-use in AES-GCM results in catastrophic failure of it's authenticity. Hence, TLS sessions can be effectively attacked through forgery by an adversary. In the case of e.g. HTTPS sessions content injection is possible, XSS and other attack vectors. Notes ----- Obviously the original wording is so ambiguous that implementers got it wrong in the real world. Related to: https://www.blackhat.com/us-16/briefings.html#nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls It may be worth adding a reference to [JOUX] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/...38.../GCM/Joux_comments.pdf and maybe the paper we're intending to release on the actual HTTPS forgery/injection attack. I'd actually like to change the nonce construction to that of the ChaCha20/Poly1305 document, but I figure this will cause massive breakage for already deployed implementations. TLS 1.3 fixes this issue per design. 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. -------------------------------------- RFC5288 (draft-ietf-tls-rsa-aes-gcm-03) -------------------------------------- Title : AES Galois Counter Mode (GCM) Cipher Suites for TLS Publication Date : August 2008 Author(s) : J. Salowey, A. Choudhury, D. McGrew Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat May 14 20:28: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 C847312D09C for ; Sat, 14 May 2016 20:28:03 -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 sRVHyReHf64E for ; Sat, 14 May 2016 20:28:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073A012B02F for ; Sat, 14 May 2016 20:27:58 -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=1463282880; x=1494818880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2+MIw0iV/HnNXpFsJxBmjTnK+msFHhr8JtsKlh8MUeg=; b=Qer9gfFmvaaxfWwkWUJ2sY0HQHe8H4uqcoagAx/wlGfrD7d6/0rxha4y v27h/YsjdGIZvoqq4oX/4ZyKyqnmw004uGxDROzYNoWy3xlK1szKmH2wh fXACt4KRPRQ+P3nr8etQJ/eyPrdtJpNmgar2ge5jjwj1ymMsPHkOySO/F SuLxDDKDAPPI0q3QB1RfGhFJaH2fiqvKAxkOtfX6EAjzh+skR4MGIZc06 YB4HvRIXpOZ92BMgoQoDm5e620P8ZdS6dtQi9RGvTV/o55//WYieuBt6g vX90H2HZWGSJg41EiVtjFGC0YFvaHdJ3eI5GogCCoEHLJQAoVyM/DBUl1 A==; X-IronPort-AV: E=Sophos;i="5.24,621,1454929200"; d="scan'208";a="85897089" 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; 15 May 2016 15:27:56 +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; Sun, 15 May 2016 15:27:56 +1200 From: Peter Gutmann To: RFC Errata System , "jsalowey@cisco.com" , "abhijitc@cisco.com" , "mcgrew@cisco.com" , "stephen.farrell@cs.tcd.ie" , "Kathleen.Moriarty.ietf@gmail.com" , "sean+ietf@sn3rd.com" , "joe@salowey.net" Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1VhVjCQK4OfkSA69GbEmT/Zp+5VwH6 Date: Sun, 15 May 2016 03:27:55 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> In-Reply-To: <20160514082717.7997D180004@rfc-editor.org> 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] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 May 2016 03:28:04 -0000 RFC Errata System writes:=0A= =0A= >The following errata report has been submitted for RFC5288, "AES Galois=0A= >Counter Mode (GCM) Cipher Suites for TLS".=0A= =0A= I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "numbe= r=0A= used once", and secondly nonce re-use in AES-GCM doesn't just result in=0A= "catastrophic failure of it's authenticity", it results in catastrophic=0A= failure of the entire mode, both confidentiality and integrity/authenticity= .=0A= =0A= Peter.= From nobody Sun May 15 17:37: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 4B43D12D1BB for ; Sun, 15 May 2016 11:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Pyn0kb32rP7P for ; Sun, 15 May 2016 11:43:50 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0662C12D1AC for ; Sun, 15 May 2016 11:43:49 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id uijg1s00610HQrX01ijh06; Sun, 15 May 2016 20:43:47 +0200 Message-ID: <5738C35B.2070504@openfortress.nl> Date: Sun, 15 May 2016 20:43:39 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Peter Gutmann References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 15 May 2016 17:37:10 -0700 Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , RFC Errata System , "abhijitc@cisco.com" Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 May 2016 18:43:55 -0000 Hi, > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number > used once", and secondly nonce re-use in AES-GCM doesn't just result in > "catastrophic failure of it's authenticity", it results in catastrophic > failure of the entire mode, both confidentiality and integrity/authenticity. I'd like to add that I don't see a difference between a "failure" and a "catastrophic failure". It's probably better to stay away from subjective words like that. -Rick From nobody Sun May 15 17:37: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 B10BC12D12C for ; Sun, 15 May 2016 01:53:03 -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 YiPBzkh_60_O for ; Sun, 15 May 2016 01:53:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8C512B077 for ; Sun, 15 May 2016 01:52:59 -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=1463302379; x=1494838379; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oQ5ewUgRsNwcWKpwjWQpsdjrxLun9rmq3zzaU1uXdgo=; b=zlVnRW/OfRBVeDw1hTxlhe7b5nEpshhP/768KSXK8Gvj5XEQjOppuzJv S+Ur+wRFMVrr6BzUOfZuBmfswfxEGqxcqdusBngSOFCPlhZ9Q71thjR9u Q0bqqmhHJnVVmlfv4Gs6SMlV4CWlmhHEQoIb4hVz9SVh03IcJ+8C7uOxc MeJ8R0GKr2imXsWnCl3dF3Du3l/YH3au/BWDIjHleZqQerZvwSDxVrIBv QmW25HN8WWM21g0LMJ8BHClGUJTRlShMrQqyq97fuQZGp2NUPQlt7dOEi vfaXYDlHCrWarRNB/M5+ATStp5RtCObxZar5jaV29jnI0c3oEEaF+yi4i g==; X-IronPort-AV: E=Sophos;i="5.24,622,1454929200"; d="scan'208";a="85917528" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 May 2016 20:52:57 +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; Sun, 15 May 2016 20:52:57 +1200 From: Peter Gutmann To: Aaron Zauner Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1VhVjCQK4OfkSA69GbEmT/Zp+5VwH6//9seYCAAO5MMg== Date: Sun, 15 May 2016 08:52:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 15 May 2016 17:37:51 -0700 Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , RFC Errata System , "abhijitc@cisco.com" Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 May 2016 08:53:04 -0000 Aaron Zauner writes:=0A= =0A= >What do you think nonce stands for?=0A= >https://en.wikipedia.org/wiki/Cryptographic_nonce=0A= =0A= Well there's your first mistake, you're using Wikipedia as a reference.=0A= "nonce" is from medieval English, and predates modern cryptography and IVs = by=0A= about 800 years.=0A= =0A= >In TLS nonce reuse allows us to attack the authentication key of GCM. Not = the=0A= >actual master secret. There's no direct break of the confidentiality, =0A= =0A= If you reuse the IV/nonce in GCM (or more specifically CTR mode), you repea= t=0A= the cipher stream. An XOR makes it go away, so you lose any confidentialit= y.=0A= =0A= Peter.=0A= =0A= From nobody Sun May 15 17:38: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 D5A8612B033 for ; Sat, 14 May 2016 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 KifSblzvL-6D for ; Sat, 14 May 2016 23:39:16 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B3412B00D for ; Sat, 14 May 2016 23:39:16 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id w36so76750415qge.3 for ; Sat, 14 May 2016 23:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3v0j4Wt1bh0bbdnkB+lLN0g+BH6gF3Vhh0mFmKQOl7M=; b=jJyScSJPRWB2uaUNJpyK018csedMKq1lkQp2Q1zUpDEkpUCa0KFH/7+N4DuFIYkgUp gpx5N7V6YgrzAC+ajtmVpYGwdhhABEv+co7LO0gluYKJRxG/3oDmYJ23fYGIJc5ag3kC SXb/8mTyMPRMBdQ46lK861iTLbo9jWHFgIGus= 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=3v0j4Wt1bh0bbdnkB+lLN0g+BH6gF3Vhh0mFmKQOl7M=; b=ivvoHQnUxKT9y/PVRPZHnDExUBOHxIFIfT66WIJLnmd+FyoGxQN8KeVrdNnvOTAtzC 1WasBfTMVkJiEsvi0npZD3FnSqFycv+rYP1xqvf2mbStDkvn/FZyscbaDJpXUGiFBWCz /co94r0Xw3nR4bislfXAArPq+NNkQi3Nse8oIfMEgPT+nRbS0lWMc+LDYU3/4xXmUhxi Si/0Pywjn5sBKWvYVDhg+XOo9z7g/Iwt+1fnANVKQvfrwHf7mi2J//2qclkGwI2W3/z3 dixrfWv50ZUid9bm4pT2TDKOzcj7myyEhgX57jFxrXIvGPGv4U4xYHMe0kJORCoALklu rAgw== X-Gm-Message-State: AOPr4FVKmtJYi87W25AAuS1e0v542kNsuIOoSmjpQgv8dDfezjJEsm9sZhrHo0nw18R1Cfq93IvV99LDdMhomQ== MIME-Version: 1.0 X-Received: by 10.140.163.85 with SMTP id j82mr24603363qhj.40.1463294355516; Sat, 14 May 2016 23:39:15 -0700 (PDT) Received: by 10.200.40.69 with HTTP; Sat, 14 May 2016 23:39:15 -0700 (PDT) Received: by 10.200.40.69 with HTTP; Sat, 14 May 2016 23:39:15 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 15 May 2016 13:39:15 +0700 Message-ID: From: Aaron Zauner To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a113a3a344346510532dbc458 Archived-At: X-Mailman-Approved-At: Sun, 15 May 2016 17:38:32 -0700 Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , RFC Errata System , "abhijitc@cisco.com" Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 May 2016 06:39:20 -0000 --001a113a3a344346510532dbc458 Content-Type: text/plain; charset=UTF-8 Hi, On May 15, 2016 10:28, "Peter Gutmann" wrote: > > RFC Errata System writes: > > >The following errata report has been submitted for RFC5288, "AES Galois > >Counter Mode (GCM) Cipher Suites for TLS". > > I think the erratum needs an erratum. No problem, but: >Firstly, "nonce" doesn't mean "number > used once", and secondly nonce re-use in AES-GCM doesn't just result in > "catastrophic failure of it's authenticity", it results in catastrophic > failure of the entire mode, both confidentiality and integrity/authenticity. > What do you think nonce stands for? https://en.wikipedia.org/wiki/Cryptographic_nonce In TLS nonce reuse allows us to attack the authentication key of GCM. Not the actual master secret. There's no direct break of the confidentiality, just authenticity (and thus integrity). For HTTPS this allows us to inject content which then may lead to a compromise of the session confidentiality. Maybe I misunderstood what you meant. Aaron > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a113a3a344346510532dbc458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On May 15, 2016 10:28, "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wro= te:
>
> RFC Errata System <rfc= -editor@rfc-editor.org> writes:
>
> >The following errata report has been submitted for RFC5288, "= AES Galois
> >Counter Mode (GCM) Cipher Suites for TLS".
>
> I think the erratum needs an erratum.=C2=A0

No problem, but:
>Firstly, "nonce" doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just= result in
> "catastrophic failure of it's authenticity", it results = in catastrophic
> failure of the entire mode, both confidentiality and integrity/authent= icity.
>

What do you think nonce stands for? https://en.wikipedia.org/wiki/Cryptog= raphic_nonce

In TLS nonce reuse allows us to attack the authentication ke= y of GCM. Not the actual master secret. There's no direct break of the = confidentiality, just authenticity (and thus integrity). For HTTPS this all= ows us to inject content which then may lead to a compromise of the session= confidentiality.

Maybe I misunderstood what you meant.

Aaron

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

--001a113a3a344346510532dbc458-- From nobody Sun May 15 17:38: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 D018D12D194 for ; Sun, 15 May 2016 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 gIP2HV_XDcBf for ; Sun, 15 May 2016 06:50:22 -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 BEA8512D18F for ; Sun, 15 May 2016 06:50:21 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id r184so83462052qkc.1 for ; Sun, 15 May 2016 06:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dTI3PflU4xhQBg/BDO4g4eZDTgrqhFtNeu8GKPq1O/0=; b=QiVVLYId7riV8ubj9n5dhYLyF23Kwo9cp32pDNHgXyRZP5eZD9lJikiSX3lYYC3i+k 5Q/ned2SEJhCfINiiwojyBh9UyH0hX6R/Owo/vTzNsCmC2SyuNM578/JnG21cwWbGdHa 33351X5o5dkG/3Zt14aG03R4893MX4rWdRH30= 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=dTI3PflU4xhQBg/BDO4g4eZDTgrqhFtNeu8GKPq1O/0=; b=X8JRnbsLtqCzxhMkgCa96PJAnFfy83OBl9IsmhJvDFrXnjOzJLUBSl6V0RbVaiyPsK lE6cq8/DmQfPKBcsU44Ox+nxndnfY8ru//KhCU3KvpmMqWnbCr0SKQb59DIapCj2nJFn jHtELRRu3cbtm3yecKigGbUem/Oxj7TclMtpnr8TXnosfosya2m1enkBfmHRELDmIbuS N84iOH85h5hkNhlzTLwb42wMkdU8+ZMbqqxlU63K1c2EPtClzcjLYqKnVmxkojNUUhaX Us0G4eX3e0ucB6KzcM/b0wcmQUC3mRyHlTmioVle7ORhYeipMxwNUye/m39rpLDcbzsc /KHw== X-Gm-Message-State: AOPr4FWH2yPMtE8K4cSoAGrUQdrTaxBdAGlUvXSzNwwuL7iS4wmcNaErwEpMT0q+mprbEft2jdJBD73lUD/Pgw== MIME-Version: 1.0 X-Received: by 10.55.77.202 with SMTP id a193mr26429781qkb.48.1463320220887; Sun, 15 May 2016 06:50:20 -0700 (PDT) Received: by 10.200.40.69 with HTTP; Sun, 15 May 2016 06:50:20 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 15 May 2016 20:50:20 +0700 Message-ID: From: Aaron Zauner To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11488f5ef588070532e1c9f2 Archived-At: X-Mailman-Approved-At: Sun, 15 May 2016 17:38:32 -0700 Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , RFC Errata System , "abhijitc@cisco.com" Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 May 2016 13:50:24 -0000 --001a11488f5ef588070532e1c9f2 Content-Type: text/plain; charset=UTF-8 On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann wrote: > Aaron Zauner writes: > > >What do you think nonce stands for? > >https://en.wikipedia.org/wiki/Cryptographic_nonce > > Well there's your first mistake, you're using Wikipedia as a reference. > "nonce" is from medieval English, and predates modern cryptography and IVs > by > about 800 years. > Sure, I wouldn't cite Wikipedia in an academic publication, but it's what pops up first if someone looks for "nonce" via a Google search. That was my point. In general I think the wording should be more clear and a little less of crypto-only nomenclature, thus -- maybe -- more convenient for engineers. I suspect this was one of the issues with the document and why we found vulnerable implementations in the first place. If you read carefully and do your home-work the RFC in current form pretty much tells you that you shouldn't re-use the nonce. Compared to TLS 1.3 and the ChaCha20/Poly1305 document (and my OCB draft): the construction does not prevent implementers from re-using the same nonce by mistake. Ideally it would be handled in such a way that human error results in non-interoperable implementations, like with said drafts and 1.3. But as noted: it'll probably cause massive breakage among deployed implementations and may even be the cause for more security issues with implementations to pop up. I know that the word "nonce" does have another meaning as well (BTW I'm not a native english speaker, as you may have guessed). But do you think that is really relevant in this case? If so, could you suggest better wording for this specific paragraph? > > >In TLS nonce reuse allows us to attack the authentication key of GCM. Not > the > >actual master secret. There's no direct break of the confidentiality, > > If you reuse the IV/nonce in GCM (or more specifically CTR mode), you > repeat > the cipher stream. An XOR makes it go away, so you lose any > confidentiality. > This document is on TLS cipher-suites, not AES-GCM in general. This attack isn't applicable here for various reasons. But I agree that the errata could be clearer here. What'd be your suggestion as an addition or change? I'm sure the relevant editors will be willing to amend/change my wording in this errata. More feedback is always appreciated. I suggest people on this list comment as much as they think is relevant to this errata, we should get it perfect this time around. It should be as clear as possible and be understood by everyone - otherwise the errata doesn't make any sense. Thanks, Aaron --001a11488f5ef588070532e1c9f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann <pgut001@cs.auc= kland.ac.nz> wrote:
Aaron Zauner <azet@azet.org> writes:

>What do you think nonce stands for?
>https://en.wikipedia.org/wiki/Cryptographic_non= ce

Well there's your first mistake, you're using Wikipedia as a= reference.
"nonce" is from medieval English, and predates modern cryptograph= y and IVs by
about 800 years.

Sure, I wouldn't c= ite Wikipedia in an academic publication, but it's what pops up first i= f someone looks for "nonce" via a Google search. That was my poin= t. In general I think the wording should be more clear and a little less of= crypto-only nomenclature, thus -- maybe -- more convenient for engineers. = I suspect this was one of the issues with the document and why we found vul= nerable implementations in the first place. If you read carefully and do yo= ur home-work the RFC in current form pretty much tells you that you shouldn= 't re-use the nonce. Compared to TLS 1.3 and the ChaCha20/Poly1305 docu= ment (and my OCB draft): the construction does not prevent implementers fro= m re-using the same nonce by mistake. Ideally it would be handled in such a= way that human error results in non-interoperable implementations, like wi= th said drafts and 1.3. But as noted: it'll probably cause massive brea= kage among deployed implementations and may even be the cause for more secu= rity issues with implementations to pop up.

I know= that the word "nonce" does have another meaning as well (BTW I&#= 39;m not a native english speaker, as you may have guessed). But do you thi= nk that is really relevant in this case? If so, could you suggest better wo= rding for this specific paragraph?
=C2=A0

>In TLS nonce reuse allows us to attack the authentication key of GCM. N= ot the
>actual master secret. There's no direct break of the confidentialit= y,

If you reuse the IV/nonce in GCM (or more specifically CTR mode), yo= u repeat
the cipher stream.=C2=A0 An XOR makes it go away, so you lose any confident= iality.

This document is on TLS cipher-= suites, not AES-GCM in general. This attack isn't applicable here for v= arious reasons. But I agree that the errata could be clearer here. What'= ;d be your suggestion as an addition or change? I'm sure the relevant e= ditors will be willing to amend/change my wording in this errata.

More feedback is always appreciated. I suggest people on th= is list comment as much as they think is relevant to this errata, we should= get it perfect this time around. It should be as clear as possible and be = understood by everyone - otherwise the errata doesn't make any sense.

Thanks,
Aaron
=C2=A0
--001a11488f5ef588070532e1c9f2-- From nobody Sun May 15 17:50: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 406DD12D57A for ; Sun, 15 May 2016 17:49:59 -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 aEYwGqTRC54o for ; Sun, 15 May 2016 17:49:58 -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 1B91B12D577 for ; Sun, 15 May 2016 17:49:58 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id s184so195994794vkb.3 for ; Sun, 15 May 2016 17:49: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:from:date:message-id:subject:to :cc; bh=OiwfyYimwp1QivbYiuDBms48mD8FnKYMlZ1kEefZmPo=; b=i3D9wt5jvss3maNiMqy05ncfD+0KAvKUFlZqYjuBtIMNFYR43yCNXfe1Gpm+l/L2Mq MukAF+LC7KJtJ/iYE/xPYKcIjHsveO4jK80BpZ+b1EqoY8h7ZQRTFjKJyY4I29bpafqR tg4KDTp190KuW95TV4W+iH8m7AGp2tUElq83ml+fi6MZxWT8+AMUw4jKZgR8UC0dbVHa GM+z56S1sKxg2xXNVJboHsN0VH+3YjaakrYCBMhap2bo/VZSMpLg0QsRAj10Mm8v4efh 4y96JUKVx5HgCZjDnvjBH1lU6pyp0BstqutzXdXvf5GAiTI48IImDDS7TzEmxyrNANE+ 1oAg== 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=OiwfyYimwp1QivbYiuDBms48mD8FnKYMlZ1kEefZmPo=; b=i9s/Oauege+VYuvKoj7ODfXVvPfTyZ7zN9YonUu91Qxm10X+jw/St/EEgctLXaJrcO wPY7fymRvwxvVl93Uk52ZDUHJ801N5XX/E0E/EQVA1yuvy+i6D3ui29j/Vre//dD9PvC lBMnPwFNxH1NuZ6YTeKKCLo8MLga+0kROiVECtcJWuI21Ux3+rHjI8qu1VWMlVqKALuV ysyT8uVsvjFxDQrt7KoBJC3WeTogk4Z8wPiUGrh8yOB4RZS419viMbk/2ZxWO5A3Htci sRCa24MQuo/k+X7jzPraqLTkcwmDIK8oEEtkZxLoU82z4hXx3vwV+O5XJhiEd+BlNp0P R4GA== X-Gm-Message-State: AOPr4FWN4+u05nYcTKK0UmJ9OPCVN5xKj54XxJCCid3lht1k9YTb7OXQuPi0UhnveCkPllajXLPfXatfV3KCDw== X-Received: by 10.159.35.116 with SMTP id 107mr1541936uae.39.1463359797200; Sun, 15 May 2016 17:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.89 with HTTP; Sun, 15 May 2016 17:49:37 -0700 (PDT) In-Reply-To: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> From: Tony Arcieri Date: Sun, 15 May 2016 17:49:37 -0700 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=001a1136e2f8e40d890532eb00e5 Archived-At: Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , "abhijitc@cisco.com" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 00:49:59 -0000 --001a1136e2f8e40d890532eb00e5 Content-Type: text/plain; charset=UTF-8 On Sun, May 15, 2016 at 6:50 AM, Aaron Zauner wrote: > I know that the word "nonce" does have another meaning as well (BTW I'm > not a native english speaker, as you may have guessed). But do you think > that is really relevant in this case? If so, could you suggest better > wording for this specific paragraph? > I think "nonce" meaning number used once is fine for cryptographic purposes. I'd also note Adam Langley has taken to pronouncing the word nonce as "n-once", at least at this year's RWC. -- Tony Arcieri --001a1136e2f8e40d890532eb00e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, May 15, 2016 at 6:50 AM, Aaron Zauner <azet@azet.org> wrote:=
I know that the word "nonce" = does have another meaning as well (BTW I'm not a native english speaker= , as you may have guessed). But do you think that is really relevant in thi= s case? If so, could you suggest better wording for this specific paragraph= ?

I think "non= ce" meaning number used once is fine for cryptographic purposes.=C2=A0=

I'd also note Adam Langley has taken= to pronouncing the word nonce as "n-once", at least at this year= 's RWC.

--
Tony = Arcieri
--001a1136e2f8e40d890532eb00e5-- From nobody Sun May 15 19:24: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 F3D4712D58B for ; Sun, 15 May 2016 19:23:42 -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 KMCKvmRGrL3S for ; Sun, 15 May 2016 19:23:41 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638D212D56F for ; Sun, 15 May 2016 19:23:41 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id w36so83874727qge.3 for ; Sun, 15 May 2016 19:23:41 -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=MFk5cEBnNm9z2Fg/erL22uqbL0kTiRizrQ1WawxyjJM=; b=NOhfvV3TFjqe1PYcf2JvQ9kBRieYNtO18h16Ww5R1YxUFO909jYRlfif2LU5QRzYl5 ZsbspOG0S1gSyiTK3S93psQNvMhEYnRVvF9QqmWauOa0HojE4QiWTvrL2TWJi3H3lwrf 8g19yCt7LApBnhmphAhd5Q/hxNTUE7Y6yBjhGMJdceVSL7aKfpyLQ81npwVgMRpdAVnX cOckyrWu5dqk2DrwldFjNQSGZNAeTSyYY2NKtlCU6lLshJCwtV+xzBIRFsCBB56iVgOf koYO2K+YZkMVmijMt3r9Jbg0XTDTQdCeiN7RE4Fs614SLz8GVIGe0qVvrLHLAqZtQ2Le 8d4g== 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=MFk5cEBnNm9z2Fg/erL22uqbL0kTiRizrQ1WawxyjJM=; b=G+5ysA5nT8xpgtv3YENvpy+Cg7TIhBJbs94tMjOaRiSLaH6zta3Z19yuFGW0K7saL0 KDbxcv7OWHwmlutIRRdjApDGZLFZyVLFIUW2Nc/fZBdCeTiKA5JBRaGIi7N8IlukZ2Rh OM2VMSIuX2F3JEPJliSdIAV+JNLCgJw3SHXZKY+3ekr9YgR7yTJkPWIdstRZVOVNIbVo zc4TSp13irJJmuKl6PJvItUb8hTan/GtEKv3aeWdv1ZDqshCQRx+WiO8nVRVHuu+HsP2 0PgtGHx+i2Uh1l7+qSCLW4PqL/rEn2Bkp4khQ6DJJ3n/MT4KidnMXgTL43TVFs6suQZA 43Ew== X-Gm-Message-State: AOPr4FUQB7yVwqpg+oMdPTEgHJXeepRBv9ENkInk/AksTK5wgFwhOBJf3PtHF94B37L2Wv0SwC2dPFMtQgTMag== X-Received: by 10.140.159.143 with SMTP id f137mr28320427qhf.61.1463365420539; Sun, 15 May 2016 19:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.175.196 with HTTP; Sun, 15 May 2016 19:23:21 -0700 (PDT) In-Reply-To: <5738C35B.2070504@openfortress.nl> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <5738C35B.2070504@openfortress.nl> From: Joseph Salowey Date: Sun, 15 May 2016 19:23:21 -0700 Message-ID: To: Rick van Rein Content-Type: multipart/alternative; boundary=001a113992721178e60532ec50b6 Archived-At: X-Mailman-Approved-At: Sun, 15 May 2016 19:24:36 -0700 Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , RFC Errata System , "abhijitc@cisco.com" Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 02:23:43 -0000 --001a113992721178e60532ec50b6 Content-Type: text/plain; charset=UTF-8 On Sun, May 15, 2016 at 11:43 AM, Rick van Rein wrote: > Hi, > > > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean > "number > > used once", and secondly nonce re-use in AES-GCM doesn't just result in > > "catastrophic failure of it's authenticity", it results in catastrophic > > failure of the entire mode, both confidentiality and > integrity/authenticity. > > I'd like to add that I don't see a difference between a "failure" and a > "catastrophic failure". It's probably better to stay away from subjective > words like that. > > [Joe] It would be better to state what actually fails: "Nonce re-use in AES-GCM allows for the recovery of the authentication key resulting in complete failure of the mode's authenticity. Hence, TLS sessions can be effectively attacked through forgery by an adversary. This enables an attacker to inject data into the TLS allowing for XSS and other attack vectors. " > -Rick > --001a113992721178e60532ec50b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, May 15, 2016 at 11:43 AM, Rick van Rein <rick@openfortress.nl> wrote:
Hi,

> I think the erratum needs an erratum.=C2=A0 Firstly, "nonce"= doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just= result in
> "catastrophic failure of it's authenticity", it results = in catastrophic
> failure of the entire mode, both confidentiality and integrity/authent= icity.

I'd like to add that I don't see a difference between a &quo= t;failure" and a
"catastrophic failure".=C2=A0 It's probably better to stay aw= ay from subjective
words like that.



--001a113992721178e60532ec50b6-- From nobody Sun May 15 20:24: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 6A32212D0C1 for ; Sun, 15 May 2016 20:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 GSj0uBR5axEO for ; Sun, 15 May 2016 20:24:13 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F3212D0A4 for ; Sun, 15 May 2016 20:24:13 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d62so195622853iof.2 for ; Sun, 15 May 2016 20:24:13 -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=DDadoGSkRJKEdsAVMFuju8Cyax/Y6UzsHhhBHOlozoA=; b=d48EcMjQ1LHpLaz5VdCV6OwQ/Mm/13WhsW0ruBZCTqtCiPwyg4gEG4oy9u76myw5un a22cysKcDodnDxqiJfI1Ur5RbW501MRwdZFT6fLZqLUO2eM0xRLRh8eeyK9yl484Nh03 nyjkyS6BpHL6Fx86p62CmKEynBxJqdqlPvNxL6LMxHnqfcnFWXeeAaS+pAfweMo/14cR guWcvdtywPX7rKXIEDxWvuZKQlBknROGtZAxEMvfeCaF3Qba6fuh6C5VDkIFCIe1CEAS cNAHqUA0bE/L95ZD/IeKOgD3C4/h/e0qNJvLAa82tl2Ebzhb9GTGGWe61KyIYASOiXSI CW9w== 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=DDadoGSkRJKEdsAVMFuju8Cyax/Y6UzsHhhBHOlozoA=; b=fRz5mVmeXxrWyKcOYfcFXsBj1suY2++phQHjy8zvocorIbUGptC48SqR2mFD4HrCsM 0HPNB8SwcMde0ZNILPPMZnioIeJvJFgDdDEDGNdvnsZzSSLHOD/NgWYJ+BWfXaEm1FLc W9hTxklRzC4Mt0n3a/+MRom2x/slibQ+3y+N6r4TCTd1U5MOJ8BviAqJvtDzz3M+DuSx swNtkjdUs9tSwrkwPQEN87Cy+STXWPF+zlBCnYcGsBYdoO9QeuobFot1sdsljgnYoeSx x804jb6KBWxs4RcTuMR3do8tC/gdJr8EURQMNvVaxgW6iGXO3czs7j8817Qos2r+VO22 wI+Q== X-Gm-Message-State: AOPr4FV6ySJeoB5KOQUm23gznDVfZqHjSZ+iVV9JUKilcBE/f7Puaa03SooRbuC2cz+3HY7XJ/Ildi4q40ARZA== MIME-Version: 1.0 X-Received: by 10.107.146.134 with SMTP id u128mr18333880iod.189.1463369052892; Sun, 15 May 2016 20:24:12 -0700 (PDT) Received: by 10.64.16.132 with HTTP; Sun, 15 May 2016 20:24:12 -0700 (PDT) In-Reply-To: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <5738C35B.2070504@openfortress.nl> Date: Sun, 15 May 2016 20:24:12 -0700 Message-ID: From: Judson Wilson To: Joseph Salowey Content-Type: multipart/alternative; boundary=94eb2c055bfa92baa30532ed2817 Archived-At: Cc: "sean+ietf@sn3rd.com" , "Kathleen.Moriarty.ietf@gmail.com" , "mcgrew@cisco.com" , "jsalowey@cisco.com" , "tls@ietf.org" , "abhijitc@cisco.com" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 03:24:15 -0000 --94eb2c055bfa92baa30532ed2817 Content-Type: text/plain; charset=UTF-8 The way I read the first draft, the wording made it sound like "nonce" was a contraction of the words "(N)umber used (once)". I thought I learned something. Then I looked it up, and unfortunately, that is not the case, as cute as it would be. That is the problem with the wording. Even if a nonce is number that is only used once, the word is not derived from omitting letters from the phrase, so we shouldn't mislead people into believing that. Removing the scare quotes is sufficient to prevent this misunderstanding. On Sun, May 15, 2016 at 7:23 PM, Joseph Salowey wrote: > > On Sun, May 15, 2016 at 11:43 AM, Rick van Rein > wrote: > >> Hi, >> >> > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean >> "number >> > used once", and secondly nonce re-use in AES-GCM doesn't just result in >> > "catastrophic failure of it's authenticity", it results in catastrophic >> > failure of the entire mode, both confidentiality and >> integrity/authenticity. >> >> I'd like to add that I don't see a difference between a "failure" and a >> "catastrophic failure". It's probably better to stay away from subjective >> words like that. >> >> > [Joe] It would be better to state what actually fails: > > "Nonce re-use in AES-GCM allows for the recovery of the authentication > key resulting in complete failure of the mode's authenticity. Hence, TLS > sessions can be effectively attacked through forgery by an adversary. > This enables an attacker to inject data into the TLS allowing for XSS and > other attack vectors. " > > > >> -Rick >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c055bfa92baa30532ed2817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The way I read the first draft, the wording made it sound = like "nonce" was a contraction of the words "(N)umber used (= once)". I thought I learned something. Then I looked it up, and unfort= unately, that is not the case, as cute as it would be.

T= hat is the problem with the wording. Even if a nonce is number that is only= used once, the word is not derived from omitting letters from the phrase, = so we shouldn't mislead people into believing that. Removing the scare = quotes is sufficient to prevent this misunderstanding.

On Sun, May 15, 2016 at 7:= 23 PM, Joseph Salowey <joe@salowey.net> wrote:

On Sun, May 15, 2016 at 11:43 AM, Rick = van Rein <rick@openfortress.nl> wrote:
Hi,

> I think the erratum needs an erratum.=C2=A0 Firstly, "nonce"= doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just= result in
> "catastrophic failure of it's authenticity", it results = in catastrophic
> failure of the entire mode, both confidentiality and integrity/authent= icity.

I'd like to add that I don't see a difference between a &quo= t;failure" and a
"catastrophic failure".=C2=A0 It's probably better to stay aw= ay from subjective
words like that.


[Joe] It would be better to state what actually fails:

"Nonce re-use in AE= S-GCM allows for the recovery of the authentication key resulting in comple= te failure of the mode's=C2=A0a= uthenticity.=C2=A0 Hence, TLS sessions can be effectively attacked through= =C2=A0forgery by an adversary.=C2= =A0 This enables an attacker to inject data into the TLS allowing for XSS and other attack vectors. "

=C2=A0
-Rick


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


--94eb2c055bfa92baa30532ed2817-- From nobody Sun May 15 20:32: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 60CAB12D0FF for ; Sun, 15 May 2016 20:32:52 -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 bkLmr26fy1Gp for ; Sun, 15 May 2016 20:32:49 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C3E12B01E for ; Sun, 15 May 2016 20:32:48 -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=1463369568; x=1494905568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PiI7LRmAleWNhLS/f0JN8DP+l1Q83irf0VaWKcqWyAY=; b=VH/PmPSolznUNB+oxHAJ5640iIq04ZcDkqSwramhP7DgHU4MjeLDpQmB n005VhrphH3sArvDW4ewlkVRlO8E6T5f3xAqwS8JpRrkNw67eHsDRKhDm HUI/eT3J3SZr+2qf/hFm2GAzi8iueAA+wFsg1T9LiYOLaNMaZ6pVrOBG7 CITSXXOhmN+HdxpN4Fs4sKwNiGV8+d8rtfnn1MhrZ3s5bUo/prVjNzFk4 7mHPcgDu3TU8BngurOZnspXa6zPDXDE2js1HSZZB8CE5vYupZrXohHjzP j4j/TQqEfgnmqz0GVMW35sMx+Upc79ucrrAhfizkdiJYZMeKm6ezmfyAS g==; X-IronPort-AV: E=Sophos;i="5.24,625,1454929200"; d="scan'208";a="86098912" 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; 16 May 2016 15:32:46 +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; Mon, 16 May 2016 15:32:46 +1200 From: Peter Gutmann To: Aaron Zauner Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1VhVjCQK4OfkSA69GbEmT/Zp+5VwH6//9seYCAAO5MMv//iiUAgAGuf0g= Date: Mon, 16 May 2016 03:32:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 03:32:52 -0000 Aaron Zauner writes:=0A= =0A= >If so, could you suggest better wording for this specific paragraph?=0A= =0A= I would just leave it as "nonce", with no attempt at a definition. If ther= e=0A= are any cryptographers who don't know what a nonce is they can look it up. = If=0A= they use an authoritative source they'll get the correct definition, and if= =0A= they use Wikipedia they'll get Wikipedia's definition.=0A= =0A= >I wouldn't cite Wikipedia in an academic publication, but it's what pops u= p=0A= >first if someone looks for "nonce" via a Google search=0A= =0A= That doesn't make it correct, it just makes it the most popular misconcepti= on.=0A= For another crypto example, look up HDCP and Blom's Scheme on Wikipedia, an= d=0A= see how much resemblance that bears to reality.=0A= =0A= >This document is on TLS cipher-suites, not AES-GCM in general. This attack= =0A= >isn't applicable here for various reasons. But I agree that the errata cou= ld=0A= >be clearer here. What'd be your suggestion as an addition or change? I'm s= ure=0A= >the relevant editors will be willing to amend/change my wording in this=0A= >errata.=0A= =0A= Since the paper for the Black Hat talk hasn't been published, I don't know= =0A= what the actual problem is (and by extension what the various reasons are),= =0A= but if you reuse a nonce I can't see how it would affect auth but not=0A= confidentiality, since you'd be generating a repeated cipher stream. If=0A= confidentiality isn't affected then there should probably be a note explain= ing=0A= why, since my immediate reaction to a comment about nonce reuse would be=0A= "complete failure of the entire mode".=0A= =0A= Peter.= From nobody Sun May 15 20:51: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 B8C2012D599 for ; Sun, 15 May 2016 20:51:03 -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, RCVD_IN_DNSWL_MED=-2.3, 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 hBypuNclueYA for ; Sun, 15 May 2016 20:51:01 -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 944A912D10E for ; Sun, 15 May 2016 20:51:01 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: E5B6212802D.A3CCF 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 cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id E5B6212802D; Mon, 16 May 2016 05:50:52 +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 E1E4C403B; Mon, 16 May 2016 05:50:52 +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 DC37A60030; Mon, 16 May 2016 05:50:52 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id D57C440; Mon, 16 May 2016 05:50:52 +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); Mon, 16 May 2016 05:50:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 May 2016 05:50:52 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> Message-ID: X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99 at cobalt X-Virus-Status: Clean Archived-At: Cc: mcgrew@cisco.com, tls@ietf.org, RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 03:51:03 -0000 Here's a possible re-write of the second paragraph: Nonce re-use in AES-GCM results in failure of both confidentiality and authenticity. Not only will confidentiality be breached by leaking the XOR of any two packets processed under the same nonce, but TLS sessions can also be attacked through forgery by an adversary. For example, in the case of HTTPS sessions content injection, XSS, and other attack vectors are possible. Original text: Security of AES-GCM requires that the "nonce" (number used once) is never reused. The IV construction in Section 3 does not prevent implementers from reusing the nonce by mistake. It is paramount that the implementer be aware of the security implications when a nonce is re-used even once. Nonce re-use in AES-GCM results in catastrophic failure of it's authenticity. Hence, TLS sessions can be effectively attacked through forgery by an adversary. In the case of e.g. HTTPS sessions content injection is possible, XSS and other attack vectors. On 2016-05-16 05:32, Peter Gutmann wrote: > Aaron Zauner writes: > >> If so, could you suggest better wording for this specific paragraph? > > I would just leave it as "nonce", with no attempt at a definition. If > there > are any cryptographers who don't know what a nonce is they can look it > up. If > they use an authoritative source they'll get the correct definition, > and if > they use Wikipedia they'll get Wikipedia's definition. > >> I wouldn't cite Wikipedia in an academic publication, but it's what >> pops up >> first if someone looks for "nonce" via a Google search > > That doesn't make it correct, it just makes it the most popular > misconception. > For another crypto example, look up HDCP and Blom's Scheme on > Wikipedia, and > see how much resemblance that bears to reality. > >> This document is on TLS cipher-suites, not AES-GCM in general. This >> attack >> isn't applicable here for various reasons. But I agree that the errata >> could >> be clearer here. What'd be your suggestion as an addition or change? >> I'm sure >> the relevant editors will be willing to amend/change my wording in >> this >> errata. > > Since the paper for the Black Hat talk hasn't been published, I don't > know > what the actual problem is (and by extension what the various reasons > are), > but if you reuse a nonce I can't see how it would affect auth but not > confidentiality, since you'd be generating a repeated cipher stream. > If > confidentiality isn't affected then there should probably be a note > explaining > why, since my immediate reaction to a comment about nonce reuse would > be > "complete failure of the entire mode". > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun May 15 21:02: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 EEA3912D59F for ; Sun, 15 May 2016 21:02:57 -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 n3WPd4BuZVzn for ; Sun, 15 May 2016 21:02:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335D512D59B for ; Sun, 15 May 2016 21:02: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=1463371376; x=1494907376; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c38wK/vYqdNvQzY7gdlZPNi0vWeihLf6FJs5tS7QhmI=; b=hmMs1PQYM5baXyZyu9Ypk6+Ul+QK/2MBEI2aDJkedQH+Vv09c05l9Oo3 y5DclCgbbRbJ118TZ+zXGKIbiXl4B7hKdA7WJx5CqYCB0sZNoiW9HjfZj 7aSCfZbhNIlhFybMzp+ip9CHr6jZezjiNqiy9Q9/EzQXu/fLgJemI5ie6 s+uIsyfLMCx2fmms0XtBh8gyU5kMraViGHjejz6dbkPSPhdTddKBg/xT8 X2m8zYSlZaemKmuKTs0TbYJt0KZBZqD/bArzkRSesdkMy7dNhqOu7ZeDP IR3c6o2hPRJqUvmOdfumg61XBhzFGy3jLmOOAyiZr0JsN7yOxdHEyxao+ A==; X-IronPort-AV: E=Sophos;i="5.24,626,1454929200"; d="scan'208";a="86104494" 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; 16 May 2016 16:02:54 +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; Mon, 16 May 2016 16:02:53 +1200 From: Peter Gutmann To: Atul Luykx Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1VhVjCQK4OfkSA69GbEmT/Zp+5VwH6//9seYCAAO5MMv//iiUAgAGuf0j//zxZAAAZjQsy Date: Mon, 16 May 2016 04:02:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C81815@uxcn10-5.UoA.auckland.ac.nz> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 04:02:58 -0000 Atul Luykx writes:=0A= =0A= >Here's a possible re-write of the second paragraph:=0A= =0A= That looks good.=0A= =0A= Peter.= From nobody Sun May 15 22:42: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 80D5A12D168 for ; Sun, 15 May 2016 22:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVJD3BNrQ7ws for ; Sun, 15 May 2016 22:42:53 -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 AC37412B02F for ; Sun, 15 May 2016 22:42:52 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n129so87390718wmn.1 for ; Sun, 15 May 2016 22:42:52 -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=5yH3wvlmdNpkojYETIhYpiHwOdFG7E2GYdkECH3FLKA=; b=Lh5PXOfqK2jUXgJI4g+JOA93U1/IOFzOzO5COaDzVtWwKDLJP4XhmhpUsBEahQhJ1O cw80gRttqseAybUiXSyYP/uaPihIooG4hNgDx38pkuMO0JBe8SCCnS9qNsPOw4s3NFUo RoR9Ls3WPbxqlX/HGjm6+xL/K6pU7ywKmspPdeLYRpeVEJDh7kh22Suj+AugKWuP6/M6 aeQcsEyXPnbCYavzzxnz4GXo88dh283dc4nfCy6v0vhScCafIJ9oou7j2NA4iHXJfKdJ /VWfzMHrWwgQAM2iMv6YxhppsuQjPdoLErhl8eyW7CuOGRzqtcw+g0C7JCPToEIgT+bI cr/Q== 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=5yH3wvlmdNpkojYETIhYpiHwOdFG7E2GYdkECH3FLKA=; b=mROnMBfwQ3FNEAsV4flZZZcCkABloQnQZGOdTI2y9AqfYKHpgbjQDVeeXn4kRTZ9lR ug5rHU4w+YHOH7LSxPOE4c8CLDv4vGt+8tUqYpMya5gxY9sQe48vMOOzKSLB5+3meKQc LV8zJJGrqLqNJC/376+nXXo8H7PCAJpV3qsEGq7Y0hBFd3Ny2Z8rJsuTAkfd5QGMb1Fc f8CJOhtNQyQArXj5SAI7pnjeMj7hicnYX6WN+nM8c2LrSnS1g/+xA7GjaPdWrn4FbPUE 4tygKK0dCV3gV6JE6RTtpxlt7dB8Z9kKzxiR4LyWAsTC7MDii/T5Bfw9tcBdUmmXIWSj /M2w== X-Gm-Message-State: AOPr4FUQQ8M7E9ltEpntz8sp5g2Ib5YgCaHCWQFuDW17hvmwH2H5oQlYUanHa3C++pp+uA== X-Received: by 10.28.151.133 with SMTP id z127mr14992476wmd.79.1463377371258; Sun, 15 May 2016 22:42:51 -0700 (PDT) Received: from [192.168.137.191] ([176.13.4.131]) by smtp.gmail.com with ESMTPSA id n66sm16456478wmn.7.2016.05.15.22.42.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 22:42:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 16 May 2016 08:42:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> To: Atul Luykx X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RFC Errata System , mcgrew@cisco.com, tls@ietf.org Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 05:42:55 -0000 > On 16 May 2016, at 6:50 AM, Atul Luykx = wrote: >=20 > Here's a possible re-write of the second paragraph: >=20 > Nonce re-use in AES-GCM results in failure of both confidentiality and = authenticity. Not only will confidentiality be breached by leaking the = XOR of any two packets processed under the same nonce, but TLS sessions = can also be attacked through forgery by an adversary. For example, in = the case of HTTPS sessions content injection, XSS, and other attack = vectors are possible. s/XOR of any two packets/XOR of any two records/ This is TLS, not IPsec. And yes, this looks fine. Yoav >=20 >=20 > Original text: >=20 > Security of AES-GCM requires that the "nonce" (number used once) is > never reused. The IV construction in Section 3 does not prevent > implementers from reusing the nonce by mistake. It is paramount that > the implementer be aware of the security implications when a nonce > is re-used even once. >=20 > Nonce re-use in AES-GCM results in catastrophic failure of it's > authenticity. Hence, TLS sessions can be effectively attacked through > forgery by an adversary. In the case of e.g. HTTPS sessions content > injection is possible, XSS and other attack vectors. >=20 >=20 > On 2016-05-16 05:32, Peter Gutmann wrote: >> Aaron Zauner writes: >>> If so, could you suggest better wording for this specific paragraph? >> I would just leave it as "nonce", with no attempt at a definition. = If there >> are any cryptographers who don't know what a nonce is they can look = it up. If >> they use an authoritative source they'll get the correct definition, = and if >> they use Wikipedia they'll get Wikipedia's definition. >>> I wouldn't cite Wikipedia in an academic publication, but it's what = pops up >>> first if someone looks for "nonce" via a Google search >> That doesn't make it correct, it just makes it the most popular = misconception. >> For another crypto example, look up HDCP and Blom's Scheme on = Wikipedia, and >> see how much resemblance that bears to reality. >>> This document is on TLS cipher-suites, not AES-GCM in general. This = attack >>> isn't applicable here for various reasons. But I agree that the = errata could >>> be clearer here. What'd be your suggestion as an addition or change? = I'm sure >>> the relevant editors will be willing to amend/change my wording in = this >>> errata. >> Since the paper for the Black Hat talk hasn't been published, I don't = know >> what the actual problem is (and by extension what the various reasons = are), >> but if you reuse a nonce I can't see how it would affect auth but not >> confidentiality, since you'd be generating a repeated cipher stream. = If >> confidentiality isn't affected then there should probably be a note = explaining >> why, since my immediate reaction to a comment about nonce reuse would = be >> "complete failure of the entire mode". >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon May 16 02:05: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 007AA12B064 for ; Mon, 16 May 2016 02:05: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 DVCJabvdDjFY for ; Mon, 16 May 2016 02:05:30 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 0043412D095 for ; Mon, 16 May 2016 02:05:29 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id xk12so63384350pac.0 for ; Mon, 16 May 2016 02:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=8/CuM+wkU/2ZAUHmttlvuK0f3wLiTySS7+UGpXbRRyU=; b=RQEVC1M0mzOmD9zWfmXpFxOOBtONOnG7LOc13+0UxklB9CpZanlmZkakDWEnAszZrr D7LEVKEbCl49V5wjMXMKTZtGqJFu0pvA0yB/QfQs3es6wBVUAiHu5fxUTPqaG/79+BAp zx//E7yZY4wJpKMMlb/HHfglbkg/EHppzh6ws= 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 :message-id:references:to; bh=8/CuM+wkU/2ZAUHmttlvuK0f3wLiTySS7+UGpXbRRyU=; b=Wtp8iCgsTAmc8F+dTiYttj0N49tmujaYgnKI1UzYPQyt/fsa7w5Bo03Rvp9nKhFpqK vzhf7Wl5Szw76YgCiq9K1QPWMYvNcZ5sYyzy5IQY9CKy9SgykiAUzVHQa7BPw0NVPVm0 re+ovLc9r5R3nNA0x0AvU0jZcAcSISbEXq5qKdNexZ12QOpZOU5wsmglMi4uFeytli+T mKJaVdl8/UgcKqMhZ2FFiyCO1svGhX3jlHnv+k6zHGn0t5h5vuX1yC9BYFzMjXdvfAG0 BoIvZdWZXp/jfAhg0EMlAPo//0cXtOtZJZf9pqfjalh/IEkuk/gz2Pzug5dKBqTfICGv RmhQ== X-Gm-Message-State: AOPr4FXqxlev37lDXUOGBnyvSobM5ycfO/R6sk8eZ/YrI2A9ZcTw4qqu0jtqhZPZyX4yuQ== X-Received: by 10.67.21.144 with SMTP id hk16mr9833029pad.138.1463389529469; Mon, 16 May 2016 02:05:29 -0700 (PDT) Received: from [10.57.13.44] (wf-171-99-101-238.revip9.asianet.co.th. [171.99.101.238]) by smtp.gmail.com with ESMTPSA id 7sm45642843pfe.88.2016.05.16.02.05.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 02:05:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F9F58F16-54C1-44D2-8350-6AFCC384FE46"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Mon, 16 May 2016 16:04:57 +0700 Message-Id: <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> To: Yoav Nir X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org, mcgrew@cisco.com, RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:05:31 -0000 --Apple-Mail=_F9F58F16-54C1-44D2-8350-6AFCC384FE46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, In the TLS case, RFC5288 defines the following IV construction (Section = 3): ``` struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets. ``` As you can see the salt is is implicitly derived from the *_write_IV. We = have no influence on this part of the IV construction, whereas the = `nonce_explicit` is generated by the implementer. I don't see a way how = we could XOR some records and compromise confidentiality, we've checked, = believe me. If somebody can come up with an attack though, that'd be = nice. On the catastrophic part: I'd like to keep it around. I don't think it = deserves a name like a hurricane, but catastrophic is pretty spot on in = this regard. w.r.t. nonce/n-nonce: either we keep the parentheses with "number used = once" around or we change it to n-once as suggested by Tony and = beautifully pronounced by Adam Langley :) Aaron --Apple-Mail=_F9F58F16-54C1-44D2-8350-6AFCC384FE46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXOY06AAoJEOTbZJL9ubXV+kYQAMUQRTHi51lTj8RdyW+l1jVg mvoFrduqdGCWsOBcEOadLEbFmC5SxH5doyOXyqFxfNk+foViGDaqU/Q+o+rpx1GO IperHnMv+WBci5/QkBz4BgRwYnPFjHKJHgGyUh9XXupDYngcMH7S+fkJ2EzW/EJb /BbCla6ygJ3/dc4mwMlIDqBC30DTKNY29os3aoslXlvFuS49F/pCgZnRBylttSt0 S8m4ZcQnYyNlTpAH677HW8dfwuzkaVdEghtw7blKDhZf5aYBYcSibpiVJ43/6UwN nibBEOUVL9s6L8jn79F63Tu8ctyyLa5YvxrdLrIOCot8aD5Q5hG2G5DC2Pe+Hhha HhM84ILR9ebBkCVVaGKSb0S03LRQxImXt+gWsTG99DD+OdDTu5xpiFFxMDSWHQ4E CeyRLFQDKdBGmngzJd4wQksNSPEjO12jJO4+MBkRn/LBv5TVlJ8RZBdJuLcny6Xv v426TJTR0/o08B245cjCD3Q0l0XXVFLjIeIG/zTsriUiEiX2mnTSc6yW/kb0YWQl Y9uau3/cZSwG8shqXux8KJB976vn6WOgRxB2Q66aOnd+e1R8iBq+KQ4C/Fjavi4L vLxNrd00wDo0xu9p3FcEmvTcsNwww+c9eqfa6phixpV16TXF+ue72nsxvHtg5bM6 4gkthJ1eUaQxOeD/vvgy =Lyum -----END PGP SIGNATURE----- --Apple-Mail=_F9F58F16-54C1-44D2-8350-6AFCC384FE46-- From nobody Mon May 16 02:18: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 8684812D0AD for ; Mon, 16 May 2016 02:18:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 oCpt5fJUIuOo for ; Mon, 16 May 2016 02:18:25 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4FF12D09A for ; Mon, 16 May 2016 02:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pvUX4hNc0VyaMuKeS7OKnyAfCQFBAVEqAZkKaWN80fA=; b=Eipm9FH9iD0qqADpV3H9TrPEg9xhzPRPxEi6Ldvsj0xVAiOTgAhw7We/LU45aSl9mDSiyAxt/z+H0t5q0F75F0aOb/pzRX8EOJnTi+7r92cMdmL/FUnM9tt0/7N8mN7CsRAShwAmQR7R3zlpx4bjVuC+GuWUuAI27P3SQNDKL00= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 09:18:02 +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.0497.017; Mon, 16 May 2016 09:18:02 +0000 From: "Paterson, Kenny" To: Aaron Zauner , Yoav Nir Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1W38UTfUlAuUKfMuT++e8QN5+5VwH6//9seYCAAO5MMoAAU08AgADlyICAAAUQAIAAH0OAgAA4foCAABTQAA== Date: Mon, 16 May 2016 09:18:02 +0000 Message-ID: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> In-Reply-To: <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 6cf346d1-caaa-4e49-642f-08d37d6afb33 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:EmwFrBP0tKEOSJEBQfRmOdn1sjUEKGgx9oEdpbGjhsWpzf99GbPBqQ8o7Db3vCfJgRy7QXToUyqtMh9qsJtqDu5briXfp9O3Kc/gii7u66B7TTdh+lBEH8/hhlzJjPf6RE3MTJ+0uoHnZa9ycqoNfw==; 24:WghHyY1SfDNflUvVhE3awSn0JGL6N6EpWafXwKiJNa/CQdY6P1eCyGdbtFA7KSICT/YaQ4j26dfy3/N/PJwUndccUwYBvq/l8dtMiJLtiPs=; 7:X+XBZDMcVNo+dT9PxXAUtPKBPsRqWoWW7IUi8a0VKiFzf/S+Z9MQjwOOXSxkUT6ULfO49YXDYCNd/tDqyoS8UCE7VDgOF2o76Bm9tt2YFVtctY5CPXbwSZ7fpHo95cWaTokoocoeGYq5WJA+lzKDKfms6GTp+Hz/tquS+BKTR2Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(81166006)(106116001)(76176999)(5001770100001)(8936002)(77096005)(2950100001)(122556002)(87936001)(8676002)(102836003)(6116002)(66066001)(19580395003)(19580405001)(74482002)(5002640100001)(3846002)(50986999)(2900100001)(1220700001)(54356999)(3660700001)(2906002)(189998001)(86362001)(36756003)(93886004)(5004730100002)(5008740100001)(11100500001)(586003)(4326007)(4001350100001)(10400500002)(3280700002)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <6635B809C9CEA14D93C7FE30EBB58C31@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 09:18:02.3357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824 Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:18:27 -0000 SGkgQWFyb24sDQoNCklmIEFFUy1HQ00gZXZlciBnZW5lcmF0ZXMgdHdvIGNpcGhlcnRleHRzIHVz aW5nIHRoZSBzYW1lIGtleSBhbmQgdGhlIHNhbWUNCjk2LWJpdCBub25jZSwgdGhlbiB0aGUgdW5k ZXJseWluZyBDVFItbW9kZSBrZXlzdHJlYW1zIHdpbGwgYmUgdGhlIHNhbWUuDQpYT1JpbmcgdGhl IGNpcGhlcnRleHRzIHRvZ2V0aGVyIHRoZW4gcHJvZHVjZXMgdGhlIFhPUiBvZiB0aGUgcGxhaW50 ZXh0cywNCmZyb20gd2hpY2ggdGhlIHR3byBpbmRpdmlkdWFsIHBsYWludGV4dHMgY2FuIGJlIHJl Y292ZXJlZCAodXN1YWxseSkgd2l0aA0KaGlnaCBwcm9iYWJpbGl0eSB1c2luZyBzdGFuZGFyZCB0 ZWNobmlxdWVzIChzZWUgdGhlIHBhcGVyIGJ5IE1hc29uIGV0IGFsDQphdCBDQ1MgMjAwNiBmb3Ig YSBmdWxsIGFjY291bnQgb2YgdGhpcyBzdGVwKS4NCg0KSW4gdGhlIFRMUyBjb250ZXh0LCB0aGlz IG1lYW5zIHVzaW5nIHRoZSBzYW1lIDY0LWJpdCBub25jZV9leHBsaWNpdCBpbiBhDQpnaXZlbiBj b25uZWN0aW9uIC0gYmVjYXVzZSB0aGVuIG9wYXF1ZSBzYWx0IHdpbGwgYmUgdGhlIHNhbWUgMzIt Yml0IHZhbHVlLg0KDQpUaGlzIGNvbmRpdGlvbiBpcyBkZXRlY3RhYmxlIGJ5IGFuIGFkdmVyc2Fy eSBiZWNhdXNlIHRoZSBub25jZV9leHBsaWNpdA0KcGFydCBpcyBzZW50IG9uIHRoZSB3aXJlICh0 aGUgY2x1ZSBpcyBpbiB0aGUgbmFtZSEpLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBrbm93IHRoZSBm dWxsIDk2LWJpdCBub25jZSB0byBjYXJyeSBvdXQgdGhlIGF0dGFjay4NCg0KT25jZSB5b3UndmUg cmVjb3ZlcmVkIGEgcGxhaW50ZXh0LCB5b3UgY2FuIGFsc28gcmVjb3ZlciB0aGUgY29ycmVzcG9u ZGluZw0KQ1RSLW1vZGUga2V5c3RyZWFtLiBUb2dldGhlciB3aXRoIHRoZSBpbnRlZ3JpdHkga2V5 LCB0aGlzIG5vdyBlbmFibGVzDQpwYWNrZXQgZm9yZ2VyeSBhdHRhY2tzIGZvciBhcmJpdHJhcnkg cGxhaW50ZXh0cyAob2YgbGVuZ3RoIGxpbWl0ZWQgYnkgdGhhdA0Kb2YgdGhlIGtub3duIGtleXN0 cmVhbSkuDQoNCklJUkMsIHdlIGRpc2N1c3NlZCB0aGlzIGJ5IGUtbWFpbCBzb21lIG1vbnRocyBi YWNrLi4uDQoNClJlZ2FyZHMsDQoNCktlbm55DQoNCg0KDQpPbiAxNi8wNS8yMDE2IDEwOjA0LCAi VExTIG9uIGJlaGFsZiBvZiBBYXJvbiBaYXVuZXIiIDx0bHMtYm91bmNlc0BpZXRmLm9yZw0Kb24g YmVoYWxmIG9mIGF6ZXRAYXpldC5vcmc+IHdyb3RlOg0KDQo+SGksDQo+DQo+SW4gdGhlIFRMUyBj YXNlLCBSRkM1Mjg4IGRlZmluZXMgdGhlIGZvbGxvd2luZyBJViBjb25zdHJ1Y3Rpb24gKFNlY3Rp b24NCj4zKToNCj4NCj5gYGANCj4gICAgICAgICAgICAgc3RydWN0IHsNCj4gICAgICAgICAgICAg ICAgb3BhcXVlIHNhbHRbNF07DQo+ICAgICAgICAgICAgICAgIG9wYXF1ZSBub25jZV9leHBsaWNp dFs4XTsNCj4gICAgICAgICAgICAgfSBHQ01Ob25jZTsNCj4NCj4NCj4gICBUaGUgc2FsdCBpcyB0 aGUgImltcGxpY2l0IiBwYXJ0IG9mIHRoZSBub25jZSBhbmQgaXMgbm90IHNlbnQgaW4gdGhlDQo+ ICAgcGFja2V0LiAgSW5zdGVhZCwgdGhlIHNhbHQgaXMgZ2VuZXJhdGVkIGFzIHBhcnQgb2YgdGhl IGhhbmRzaGFrZQ0KPiAgIHByb2Nlc3M6IGl0IGlzIGVpdGhlciB0aGUgY2xpZW50X3dyaXRlX0lW ICh3aGVuIHRoZSBjbGllbnQgaXMNCj4gICBzZW5kaW5nKSBvciB0aGUgc2VydmVyX3dyaXRlX0lW ICh3aGVuIHRoZSBzZXJ2ZXIgaXMgc2VuZGluZykuICBUaGUNCj4gICBzYWx0IGxlbmd0aCAoU2Vj dXJpdHlQYXJhbWV0ZXJzLmZpeGVkX2l2X2xlbmd0aCkgaXMgNCBvY3RldHMuDQo+YGBgDQo+DQo+ QXMgeW91IGNhbiBzZWUgdGhlIHNhbHQgaXMgaXMgaW1wbGljaXRseSBkZXJpdmVkIGZyb20gdGhl ICpfd3JpdGVfSVYuIFdlDQo+aGF2ZSBubyBpbmZsdWVuY2Ugb24gdGhpcyBwYXJ0IG9mIHRoZSBJ ViBjb25zdHJ1Y3Rpb24sIHdoZXJlYXMgdGhlDQo+YG5vbmNlX2V4cGxpY2l0YCBpcyBnZW5lcmF0 ZWQgYnkgdGhlIGltcGxlbWVudGVyLiBJIGRvbid0IHNlZSBhIHdheSBob3cNCj53ZSBjb3VsZCBY T1Igc29tZSByZWNvcmRzIGFuZCBjb21wcm9taXNlIGNvbmZpZGVudGlhbGl0eSwgd2UndmUgY2hl Y2tlZCwNCj5iZWxpZXZlIG1lLiBJZiBzb21lYm9keSBjYW4gY29tZSB1cCB3aXRoIGFuIGF0dGFj ayB0aG91Z2gsIHRoYXQnZCBiZSBuaWNlLg0KPg0KPk9uIHRoZSBjYXRhc3Ryb3BoaWMgcGFydDog SSdkIGxpa2UgdG8ga2VlcCBpdCBhcm91bmQuIEkgZG9uJ3QgdGhpbmsgaXQNCj5kZXNlcnZlcyBh IG5hbWUgbGlrZSBhIGh1cnJpY2FuZSwgYnV0IGNhdGFzdHJvcGhpYyBpcyBwcmV0dHkgc3BvdCBv biBpbg0KPnRoaXMgcmVnYXJkLg0KPg0KPncuci50LiBub25jZS9uLW5vbmNlOiBlaXRoZXIgd2Ug a2VlcCB0aGUgcGFyZW50aGVzZXMgd2l0aCAibnVtYmVyIHVzZWQNCj5vbmNlIiBhcm91bmQgb3Ig d2UgY2hhbmdlIGl0IHRvIG4tb25jZSBhcyBzdWdnZXN0ZWQgYnkgVG9ueSBhbmQNCj5iZWF1dGlm dWxseSBwcm9ub3VuY2VkIGJ5IEFkYW0gTGFuZ2xleSA6KQ0KPg0KPkFhcm9uDQoNCg== From nobody Mon May 16 02:37: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 CABFD128E19 for ; Mon, 16 May 2016 02:37: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 2jGZQ-aQROu9 for ; Mon, 16 May 2016 02:37:14 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 A08B412D0B7 for ; Mon, 16 May 2016 02:37:14 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id xk12so63657929pac.0 for ; Mon, 16 May 2016 02:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=JOj7B2BWyp6EfOZRxdCswNiRxlCR3tBlX2P88tU+AeQ=; b=ENSgLsrOjbJDIjAp7kJEsBNUaphuq/B5nHa5qtKN32g35TlyL66y5JKI2gp/Z9orML /4od0ryrvCgYHk57MXhLpBmj4l4L+7QKmec/thFo/cNVi2b+OO8ZvW72/a7a42f1kKk+ fZmKJcHUwoxG5eIeQLn4gFC+MuSeqjoZvhVnw= 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 :message-id:references:to; bh=JOj7B2BWyp6EfOZRxdCswNiRxlCR3tBlX2P88tU+AeQ=; b=Xa3WfEhHv9fJLtKvHeYWED/cYIXxQy+aS/UjODqD+yB36nwoB5vVTj0ed4gjwDVlQI 9ga3LiWSLd0oE7O5i14zphJhrJUz62bE7t30jilYr329WGPCw/ZbxLMNzuiisb+iFoL/ kZJkdOZZkRWC9ZXlIIiJxlP2yumUPKR8BL/QtiEyYIa493n51RBPY6f5o2Lko1uEF8JQ Y8VxSFOWx1FWec7RH/C6qvJMPPlYlm7RL/0SnUTOo60+tA5ai13DCa0WQ0h+wppF5RxT 6x6dPrYD41eIFLL1RTSXbxwxRr7Nir3wEBmTnlGdPWy5tSnzN5ZAst1yv2x/uHnS2xya PUdQ== X-Gm-Message-State: AOPr4FUqjGQ8XuQkv+ehCDT7dShLqhIhOlhuRy89II89oEWsa0vwHFvMxG9gN+ECS9VyHQ== X-Received: by 10.66.89.228 with SMTP id br4mr43615480pab.110.1463391434145; Mon, 16 May 2016 02:37:14 -0700 (PDT) Received: from [10.57.13.44] (wf-171-99-101-238.revip9.asianet.co.th. [171.99.101.238]) by smtp.gmail.com with ESMTPSA id pw3sm61207pac.6.2016.05.16.02.37.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 02:37:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6E01BA23-C756-4E86-9D41-24FA8702B7D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Mon, 16 May 2016 16:37:00 +0700 Message-Id: <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:37:16 -0000 --Apple-Mail=_6E01BA23-C756-4E86-9D41-24FA8702B7D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kenny, > On 16 May 2016, at 16:18, Paterson, Kenny = wrote: >=20 > Hi Aaron, >=20 > If AES-GCM ever generates two ciphertexts using the same key and the = same > 96-bit nonce, then the underlying CTR-mode keystreams will be the = same. > XORing the ciphertexts together then produces the XOR of the = plaintexts, > from which the two individual plaintexts can be recovered (usually) = with > high probability using standard techniques (see the paper by Mason et = al > at CCS 2006 for a full account of this step). >=20 > In the TLS context, this means using the same 64-bit nonce_explicit in = a > given connection - because then opaque salt will be the same 32-bit = value. >=20 > This condition is detectable by an adversary because the = nonce_explicit > part is sent on the wire (the clue is in the name!). >=20 > You don't need to know the full 96-bit nonce to carry out the attack. Yes, I understood that, of course. But: > Once you've recovered a plaintext, you can also recover the = corresponding > CTR-mode keystream. Together with the integrity key, this now enables > packet forgery attacks for arbitrary plaintexts (of length limited by = that > of the known keystream). Right. Joux's attack doesn't recover a plaintext of the actual TLS = session, we attack GHASH in this case and factor possible candidate = polynomials of the /authentication key/. In this context I assume = 'confidentiality compromise' with: somebody can recover plaintext from = captured TLS records. At least in our attack this isn't the case. We're = merely able to inject malicious content. Am I amiss? Or am I just = confused about nomenclature? Thank you, Aaron --Apple-Mail=_6E01BA23-C756-4E86-9D41-24FA8702B7D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXOZS9AAoJEOTbZJL9ubXVXToQAOTLKaPTPOOB9Md5tVm7qV4o DpwM9g5SJ0UEq69gMNKjukHYlUb2I4RksxlQi8YmBRIHYA2R/kzEfaRAsKQiost1 IjjUaoCCdPbIcnOActT+T82jThCa4d2LxG3uh6WAT6hcU+r/Rz+NmSCwxmmltvfE Bt2Qsqudc0DRCNIjxaH8KM4uPGs/vR26MfjQHpGAupwLFfgxD+VIRrgStU2uLhlT 0c97GLrcy36pv7+wHqzHCFj3aZLwwpmelf5eqS58RuiCSY268MAz6wMp27F9U9R/ W4ivTr7/2xp5d+2nr3vvw5qZmzy+IrKSlNXfoBDkVfYjjD62vYvcYaK4jjLSgAaD jY9iesmCxdXYgy0GcpyRNfoP+Goxlp0QjnPtFhytYtwTzLtJVhoV+nFntODrsM/s DN3W4Nyn7IICwoxEavCjHXlHTzpF+4jDg2nCd7PZRVE0G246dqyMR2eNwdLRPlv3 1o0IqyYaDNWm+KS65UEqofKXBocJzpjoOBNS6rqTIPBdy2YT+ABGjvIsb7bsNWI6 bFso7SKimK/0SuowIwm2DNdaO5M23+Z0ydN9sd27aAaMaYW6Fky0BOCZ8oDmz385 YDrQ4G1T+fyBv05tWv9tGulX3E3iWHkLps8bqaKSs7Ow6djZt4Qvq4RUY20OB4F+ KY/EO81nh8OzNne5ksQX =VZ/y -----END PGP SIGNATURE----- --Apple-Mail=_6E01BA23-C756-4E86-9D41-24FA8702B7D0-- From nobody Mon May 16 02:48: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 7258412D0BC for ; Mon, 16 May 2016 02:48:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MYdaKqDdPDGE for ; Mon, 16 May 2016 02:48:52 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0695.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE61D12D0B0 for ; Mon, 16 May 2016 02:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p8rVZG+xelvJdB4wIzEhMu2WKCuO3dJREYjbxO2Ipos=; b=NanvI7wifpTbjoYyG5IDCWHKhU0dakcASgkAKk9uLGljN/1w3YCS+LULOfQyHQ0BEQaQ05paxuYnSblADCS9JZr488zrh+MtjNlS7dIj27/x7fL+BCY4o8xOu+i+yQhFk8UtA5nUJV2neZ/w6MoOGJ6x/8O9h1Frjct46KIgTTA= 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.497.12; Mon, 16 May 2016 09:48:32 +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.0497.017; Mon, 16 May 2016 09:48:31 +0000 From: "Paterson, Kenny" To: Aaron Zauner Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1W38UTfUlAuUKfMuT++e8QN5+5VwH6//9seYCAAO5MMoAAU08AgADlyICAAAUQAIAAH0OAgAA4foCAABTQAP//9CQAgAAUZ4A= Date: Mon, 16 May 2016 09:48:31 +0000 Message-ID: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> In-Reply-To: <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 72c94029-f399-4b90-9ab7-08d37d6f3da8 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1823; 5:sXe8wHH/RUGroM+95FtqkBotRpLGI6eT0ErQGVuTpyaQM1CmR6CqLz3l2Hs3MMoqfs5VGu28FaW5uNjQxaORJ/XvLLol0dP/uICQGxcrkqpUCk+i8qtOBGBfowYaj+C/JFp9ArRGdjx21+ZhjwAdNg==; 24:dEabUD1/wcQxgBEStynL6dMVEA7hQeWeWnKkUKe6RN3KU3DB5Q8DjOSCUrN1OeOWdf/9K3Z0mgKOZejVpwN1zu/hlNWRSZafeg3eQ92QJrs=; 7:xxzRWlZNLc2UJQx56xN4sOxH8chqss8MYcHsT2hE2EZXZE2glRQllo8mCfvjbtPR9AZjxHeFFz5z/FO8Ncu1Is8WT5dyV378olllxmFfIQ/8Aia58PW7i/eFKuEz9GDrgh3aF3LVWziIybVWXp7icKiOqGskUktJyBW77+v6M04= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1823; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR03MB1823; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1823; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(24454002)(87936001)(586003)(83506001)(122556002)(3280700002)(86362001)(5008740100001)(4326007)(3660700001)(8936002)(3846002)(102836003)(1220700001)(77096005)(54356999)(76176999)(36756003)(81166006)(2906002)(8676002)(5004730100002)(101416001)(189998001)(110136002)(4001350100001)(50986999)(6116002)(106116001)(5002640100001)(66066001)(93886004)(2950100001)(92566002)(10400500002)(19580395003)(74482002)(2900100001)(19580405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1823; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 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: 16 May 2016 09:48:31.7423 (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: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:48:54 -0000 SGkNCg0KT24gMTYvMDUvMjAxNiAxMDozNywgIkFhcm9uIFphdW5lciIgPGF6ZXRAYXpldC5vcmc+ IHdyb3RlOg0KDQo+SGkgS2VubnksDQo+DQo+PiBPbiAxNiBNYXkgMjAxNiwgYXQgMTY6MTgsIFBh dGVyc29uLCBLZW5ueSA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4NCj4+d3JvdGU6DQo+PiAN Cj4+IEhpIEFhcm9uLA0KPj4gDQo+PiBJZiBBRVMtR0NNIGV2ZXIgZ2VuZXJhdGVzIHR3byBjaXBo ZXJ0ZXh0cyB1c2luZyB0aGUgc2FtZSBrZXkgYW5kIHRoZQ0KPj5zYW1lDQo+PiA5Ni1iaXQgbm9u Y2UsIHRoZW4gdGhlIHVuZGVybHlpbmcgQ1RSLW1vZGUga2V5c3RyZWFtcyB3aWxsIGJlIHRoZSBz YW1lLg0KPj4gWE9SaW5nIHRoZSBjaXBoZXJ0ZXh0cyB0b2dldGhlciB0aGVuIHByb2R1Y2VzIHRo ZSBYT1Igb2YgdGhlIHBsYWludGV4dHMsDQo+PiBmcm9tIHdoaWNoIHRoZSB0d28gaW5kaXZpZHVh bCBwbGFpbnRleHRzIGNhbiBiZSByZWNvdmVyZWQgKHVzdWFsbHkpIHdpdGgNCj4+IGhpZ2ggcHJv YmFiaWxpdHkgdXNpbmcgc3RhbmRhcmQgdGVjaG5pcXVlcyAoc2VlIHRoZSBwYXBlciBieSBNYXNv biBldCBhbA0KPj4gYXQgQ0NTIDIwMDYgZm9yIGEgZnVsbCBhY2NvdW50IG9mIHRoaXMgc3RlcCku DQo+PiANCj4+IEluIHRoZSBUTFMgY29udGV4dCwgdGhpcyBtZWFucyB1c2luZyB0aGUgc2FtZSA2 NC1iaXQgbm9uY2VfZXhwbGljaXQgaW4gYQ0KPj4gZ2l2ZW4gY29ubmVjdGlvbiAtIGJlY2F1c2Ug dGhlbiBvcGFxdWUgc2FsdCB3aWxsIGJlIHRoZSBzYW1lIDMyLWJpdA0KPj52YWx1ZS4NCj4+IA0K Pj4gVGhpcyBjb25kaXRpb24gaXMgZGV0ZWN0YWJsZSBieSBhbiBhZHZlcnNhcnkgYmVjYXVzZSB0 aGUgbm9uY2VfZXhwbGljaXQNCj4+IHBhcnQgaXMgc2VudCBvbiB0aGUgd2lyZSAodGhlIGNsdWUg aXMgaW4gdGhlIG5hbWUhKS4NCj4+IA0KPj4gWW91IGRvbid0IG5lZWQgdG8ga25vdyB0aGUgZnVs bCA5Ni1iaXQgbm9uY2UgdG8gY2Fycnkgb3V0IHRoZSBhdHRhY2suDQo+DQo+WWVzLCBJIHVuZGVy c3Rvb2QgdGhhdCwgb2YgY291cnNlLiBCdXQ6DQo+DQo+PiBPbmNlIHlvdSd2ZSByZWNvdmVyZWQg YSBwbGFpbnRleHQsIHlvdSBjYW4gYWxzbyByZWNvdmVyIHRoZQ0KPj5jb3JyZXNwb25kaW5nDQo+ PiBDVFItbW9kZSBrZXlzdHJlYW0uIFRvZ2V0aGVyIHdpdGggdGhlIGludGVncml0eSBrZXksIHRo aXMgbm93IGVuYWJsZXMNCj4+IHBhY2tldCBmb3JnZXJ5IGF0dGFja3MgZm9yIGFyYml0cmFyeSBw bGFpbnRleHRzIChvZiBsZW5ndGggbGltaXRlZCBieQ0KPj50aGF0DQo+PiBvZiB0aGUga25vd24g a2V5c3RyZWFtKS4NCj4NCj5SaWdodC4gSm91eCdzIGF0dGFjayBkb2Vzbid0IHJlY292ZXIgYSBw bGFpbnRleHQgb2YgdGhlIGFjdHVhbCBUTFMNCj5zZXNzaW9uLCB3ZSBhdHRhY2sgR0hBU0ggaW4g dGhpcyBjYXNlIGFuZCBmYWN0b3IgcG9zc2libGUgY2FuZGlkYXRlDQo+cG9seW5vbWlhbHMgb2Yg dGhlIC9hdXRoZW50aWNhdGlvbiBrZXkvLiBJbiB0aGlzIGNvbnRleHQgSSBhc3N1bWUNCj4nY29u ZmlkZW50aWFsaXR5IGNvbXByb21pc2UnIHdpdGg6IHNvbWVib2R5IGNhbiByZWNvdmVyIHBsYWlu dGV4dCBmcm9tDQo+Y2FwdHVyZWQgVExTIHJlY29yZHMuIEF0IGxlYXN0IGluIG91ciBhdHRhY2sg dGhpcyBpc24ndCB0aGUgY2FzZS4gV2UncmUNCj5tZXJlbHkgYWJsZSB0byBpbmplY3QgbWFsaWNp b3VzIGNvbnRlbnQuIEFtIEkgYW1pc3M/IE9yIGFtIEkganVzdA0KPmNvbmZ1c2VkIGFib3V0IG5v bWVuY2xhdHVyZT8NCg0KSSB0aGluayB5b3UgYXJlIGFtaXNzLg0KDQpNYXliZSB0aGUgY29uZnVz aW9uIGlzIHRoaXM6IGluIHlvdXIgYXV0aGVudGljaXR5IGF0dGFjaywgeW91IGRvIHJlY292ZXIN CnRoZSBHSEFTSCBrZXksIGFuZCB0aGUgZWZmZWN0IGlzIGNhdGFzdHJvcGhpYy4gSW4gdGhlIGNv bmZpZGVudGlhbGl0eQ0KYXR0YWNrLCBvbmUgY2FuIHJlY292ZXIgcGxhaW50ZXh0cyBmb3IgdGhl IHJlY29yZHMgd2l0aCByZXBlYXRlZCBub25jZXMsDQpidXQgbm90IHRoZSBlbmNyeXB0aW9uIGtl eS4gVGhlIGVmZmVjdCBtYXkgYmUgYmFkIC0gYnV0IGl0J3MgcGVyaGFwcyBub3QNCmFzIGNhdGFz dHJvcGhpYyBpbiBwcmFjdGljZSBhcyB0aGUgYXV0aGVudGljaXR5IGF0dGFjay4NCg0KVGhpbmsg YWJvdXQgaXQgdGhpcyB3YXk6IGZvciB5b3VyIGluamVjdGlvbiBhdHRhY2ssIHlvdSBuZWVkIHRv IHJlY292ZXINCnRoZSBDVFIga2V5c3RyZWFtIC0gb3RoZXJ3aXNlIHlvdSBjb3VsZG4ndCBwcm9w ZXJseSBBRVMtR0NNLWVuY3J5cHQgeW91cg0KY2hvc2VuIHBsYWludGV4dCByZWNvcmQgZm9yIHRo ZSBpbmplY3Rpb24uIEJ1dCBpZiB5b3UgcmVjb3ZlcmVkIHRoZQ0Ka2V5c3RyZWFtIGFzIHBhcnQg b2YgeW91ciBhdHRhY2ssIHRoZW4geW91J3ZlIGFsc28gcmVjb3ZlcmVkIHRoZSBwbGFpbnRleHQN CmZvciB0aGUgb3JpZ2luYWwgcmVjb3JkLg0KDQpPciBtYXliZSBpbiB5b3VyIGluamVjdGlvbiBh dHRhY2sgeW91IHdlcmUgYXNzdW1pbmcgeW91IGFscmVhZHkgKmtuZXcqIHRoZQ0KcGxhaW50ZXh0 PyBUaGF0IHdvdWxkIG1ha2Ugc2Vuc2UsIEkgZ3Vlc3MgLSBhIGxvdCBlYXNpZXIgdGhlbiB0byBy ZWNvdmVyDQp0aGUga2V5c3RyZWFtIHRoYW4gZG9pbmcgdGhlICJ1bmRvaW5nIHRoZSBYT1IiIGF0 dGFjayBuZWVkZWQgdG8gcmVjb3Zlcg0KUF8xIGFuZCBQXzIgZnJvbSBQXzEgWE9SIFBfMi4NCg0K Q2hlZXJzDQoNCktlbm55ICANCg0KDQo+DQo+VGhhbmsgeW91LA0KPkFhcm9uDQoNCg== From nobody Mon May 16 02:51: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 CCB6212B077; Mon, 16 May 2016 02:51:34 -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 8-wsMaZdhT3H; Mon, 16 May 2016 02:51:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB69C12B015; Mon, 16 May 2016 02:51:30 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-8a-57399820340f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.30.12516.02899375; Mon, 16 May 2016 11:51:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Mon, 16 May 2016 11:51:28 +0200 To: "tls@ietf.org" From: Magnus Westerlund Message-ID: <5739981E.501@ericsson.com> Date: Mon, 16 May 2016 11:51:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM2K7uq7CDMtwg30rlCxe9qxkt/h0vovR gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZax80MhYcl6pYc7yygfGASBcjJ4eEgInEwxftrBC2 mMSFe+vZuhi5OIQEjjBKvH/4ngnCWc4ocfr9NEaQKhEBRYkdV7vZQWxmASWJuUtfM4PYbAIW Ejd/NLKB2MICHhLLOtrB6nkF1CWev3kMtoFFQFXixb5nLCC2qECMROODU0wQNYISJ2c+AYpz AM20l3iwtQxivLxE89bZYOOFBLQlGpo6WCcw8s9C0jELoWMWko4FjMyrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQID7uCW37o7GFe/djzEKMDBqMTDu0DTMlyINbGsuDL3EKMEB7OSCK/Y ZKAQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGxvKNJtFH uazyeWRa96vqKAZekpi16YjiEfa/By6VLexyTw1v2z8h8foiwflJax/MOFdXdGDnK65i5eSX J542ev7mW1Nguam95YPztifX6viWW4ls8ZcR+Vh1snHNH3bBpPLAkw/D1L9/YBKu1nlSl6t+ pFdh5RmjJ7Vb7IrOZd7con4mPvxnhhJLcUaioRZzUXEiAGVRHOA0AgAA Archived-At: Cc: IETF AVTCore WG Subject: [TLS] Updated text in regards to draft-ietf-avtcore-rfc5764-mux-fixes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:51:35 -0000 TLS WG, (Cc AVTCORE WG) When AVTCORE run a WG last call earlier this year on "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)": https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ There was several comments from the TLS WG in regards to the update of the TLS content type registry as well as the limited applicability of the multiplexing scheme used. The authors have written an updated text proposal. I would really appreciate if you could review these changes and provide any feedback. A diff between the previously WG version and the current one: https://www.ietf.org/rfcdiff?url1=draft-ietf-avtcore-rfc5764-mux-fixes-05&url2=draft-ietf-avtcore-rfc5764-mux-fixes-07 The update TLS related text is: 4. Implicit Allocation of New Codepoints for TLS ContentTypes The demultiplexing scheme in [RFC5764] dictates that if the value of the first byte is between 20 and 63 (inclusive), then the packet is identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347] that first byte corresponds to the TLS ContentType field. Considerations must be taken into account when assigning additional ContentTypes in the code point ranges 0 to 19 and 64 to 255 so this does not prevent demultiplexing when this functionality is desirable. Note that [RFC5764] describes a narrow use of DTLS that works as long as the specific DTLS version used abides by the restrictions on the demultiplexing byte (the ones that this document imposes on the TLS ContentType Registry). Any extension or revision to DTLS that causes it to no longer meet these constraints should consider what values may occur in the first byte of the DTLS message and what impact it would have on the multiplexing that [RFC5764] describes. With respect to TLS packet identification, this document explicitly adds a warning to the codepoints from 0 to 19 and from 64 to 255 indicating that allocations in these ranges require coordination, as described in this document. The proposed changes to the TLS ContentType Registry are: OLD: 0-19 Unassigned 20 change_cipher_spec 21 alert 22 handshake 23 application_data 24 heartbeat 25-255 Unassigned NEW: 0-19 Unassigned (Requires coordination, see RFCXXXX) 20 change_cipher_spec 21 alert 22 handshake 23 application_data 24 heartbeat 25-63 Unassigned 64-255 Unassigned (Requires coordination, see RFCXXXX) As document shepherd I intended to run a new WG last call in a weeks time, so please provide feedback quickly so that we know if this update is okay, or needs additional revisions. Cheers Magnus Westerlund AVTCORE WG chair ---------------------------------------------------------------------- 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 Mon May 16 03:17: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 156C412D10B for ; Mon, 16 May 2016 03:17: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 8Cg9rWBiN9Cd for ; Mon, 16 May 2016 03:17:09 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 CBD5B12D0DD for ; Mon, 16 May 2016 03:17:09 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 77so66014935pfv.2 for ; Mon, 16 May 2016 03:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=S6kWIO4Pr5mXghyO7iXc2fuQ/QhyH0GbtaFAPOh2EQo=; b=MLo7dp9docFoFtzXcZ3ccDvRhyfY1h/AUloGicqzld9SemrUJojeFOP5KD5dWCq9u8 YhPpyLnsQTnaWTDBrc+Lo9ZW+ZoKQn6Dh571Pyux2I7auSxCif27euOkfYxGdE6AQwpj VZauy9FLk8fBx8O3j4AECAIkAXD2gucVJZ6SE= 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 :message-id:references:to; bh=S6kWIO4Pr5mXghyO7iXc2fuQ/QhyH0GbtaFAPOh2EQo=; b=eOnBE6Jn4vmyoYz+hHCSWtBk3MGM9yOhwwbXq7wCP4g0oV8MVRKAF//dUpXpzJQwie 4PntvaZqLdbxuduP9+3jwiq5vpJ/49onOGF9/0QrphUFuwi17Bff/6+ir9eixboabeKN cTbcO3tSWJmc6FLhGb7PmEGUwtB2j8XsDhYfY3D7VV0OofftFFBLCTrqwsRPtokAYNmp gYTz9uKSlyZDj4Y1FIYuoyTZwBCfjqzFkEpsNDKt+d/N/cTNbq4/HnMluC5zrKCxQxKs iVNgfn02Na6HFLm7EZWujny+5YeXbpsHdwGJroEK6WDmr/ipdfx9tLOgNPTIHNhzTlaX TKKw== X-Gm-Message-State: AOPr4FXdG0Uog4PJgsQm/yO8gVU672KXuuEOSxAyg24Dk/Ra1ovWv78t0ar9REQ5I0J1Ug== X-Received: by 10.98.71.80 with SMTP id u77mr44262263pfa.119.1463393829290; Mon, 16 May 2016 03:17:09 -0700 (PDT) Received: from [192.168.1.234] (ppp-49-237-229-67.revip6.asianet.co.th. [49.237.229.67]) by smtp.gmail.com with ESMTPSA id q186sm46174036pfq.96.2016.05.16.03.17.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 03:17:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1BB6933F-351D-43DC-97F0-E4763286E6C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Mon, 16 May 2016 17:15:05 +0700 Message-Id: <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:17:11 -0000 --Apple-Mail=_1BB6933F-351D-43DC-97F0-E4763286E6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kenny, > On 16 May 2016, at 16:48, Paterson, Kenny = wrote: >=20 > Maybe the confusion is this: in your authenticity attack, you do = recover > the GHASH key, and the effect is catastrophic. In the confidentiality > attack, one can recover plaintexts for the records with repeated = nonces, > but not the encryption key. The effect may be bad - but it's perhaps = not > as catastrophic in practice as the authenticity attack. Ah, I see. Yes and we do not consider this in our paper at all. Maybe we = should? Not sure how practical this is. > Think about it this way: for your injection attack, you need to = recover > the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt = your > chosen plaintext record for the injection. But if you recovered the > keystream as part of your attack, then you've also recovered the = plaintext > for the original record. >=20 > Or maybe in your injection attack you were assuming you already *knew* = the > plaintext? That would make sense, I guess - a lot easier then to = recover > the keystream than doing the "undoing the XOR" attack needed to = recover > P_1 and P_2 from P_1 XOR P_2. The first step of our attack involves attacker controlled content. So = yes (phishing, unauthenticated HTTP, selective company DPI etc.). In our = example we use a local proxy to carry out the attack. I hope I can post = a full version of the actual paper and PoC to this thread soon. Aaron --Apple-Mail=_1BB6933F-351D-43DC-97F0-E4763286E6C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXOZ2pAAoJEOTbZJL9ubXV3VYQAOa+Rn1uZi49tKyIxBklR97Z UBFc6QgtNVlCG+OaaUpYVZcvyGydKv5h8SLjE/GfuHwPVRXrvFlK2WhBjGjF/Ma+ x77IeWzIduR/NYeeEu3z2E6DAaCKCCzGTJP9cga0dMlAG9E3wRXFfLj5ZQAw1+f6 AwxvB5ux4/AhujPhMN8gqQk7+CR/ITk+nouAJtN+pskP2DyMGe1tY788zbPjwpm6 3snWnraOIvoloz8cKnbFjbuKIHGKniNuDNpsQgyUhKUc27zomwsl+hg5MfZ4hV0S 8zyZvvzRADKqpIICIno4RF87735l8AF0eZ9ZN2ON0HYmCNFmjSJu1nsCDBFUISJm qDCVBYHCaHKQxea3pVG6eytTxOMB5DBnTkrnskiBGnrGIqg1SF4vBCqXDV6s3OTw uVp/gN1Q7oYJSv2a8+32VJBoNog+zwvr2EpSQ4+eoVb9K1rpXv4OdvUxlLXZevNK kQv5dC95KfRvw+KRqh0R3l4wpwZ6JfQaX7K4niGBlSG/Oqxh0iJk/d99ckBsZ5am qxVJ97IPsP9J1w3o8gCkijrnFf/WqHhJ3567IL2diAYu5TIroUlxh2ZRbx+sdfXI GU6HW6oUA4r/evFngu0PD/wXIKKab7KdPOCfE8hKyg1zVfcKoBNNwGSwjz8M6nDr XYKOzciLnLjvdj5DHJst =D0ry -----END PGP SIGNATURE----- --Apple-Mail=_1BB6933F-351D-43DC-97F0-E4763286E6C5-- From nobody Mon May 16 03:24: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 206F412D0EF for ; Mon, 16 May 2016 03:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 NngERpktNAcl for ; Mon, 16 May 2016 03:24:54 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C7F12D0CE for ; Mon, 16 May 2016 03:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FMCZApLSmxk8NwqDOS3a5TyKvBkT8tI7OS9WuidCHsU=; b=nmG3uAyV3wyGUrTF0UxydT8beFJBajhnp6uEEXLCoM10j5QWN4pAlY06swB5OTz4PQm+BUF3sky9RhUis9LTNVJFYTJkZT++kLH3c5Jc13nyieyNs6Jc1c0l1g6Jsheo6a8z+Qa+5WjlnnVJ9Twk4LkJ5fMkioxl1wpP9JoxsTU= 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.497.12; Mon, 16 May 2016 10:24:35 +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.0497.017; Mon, 16 May 2016 10:24:35 +0000 From: "Paterson, Kenny" To: Aaron Zauner Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694) Thread-Index: AQHRri1W38UTfUlAuUKfMuT++e8QN5+5VwH6//9seYCAAO5MMoAAU08AgADlyICAAAUQAIAAH0OAgAA4foCAABTQAP//9CQAgAAUZ4D///Y9gAACesAA Date: Mon, 16 May 2016 10:24:35 +0000 Message-ID: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> In-Reply-To: <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-ms-office365-filtering-correlation-id: 7ce96d9a-d281-4b95-1128-08d37d744779 x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 5:N7twpS4YTokT3AZKzLvKrbHzKgS2eQ7of+AlKyHrq3euesF318XuPnimDUvDmzz1XlUVCxI0/EkmeSuG7mjepdWXwQEHiC77Lc89GoWodY6peZr5XGni6U53Q0gRfE00sjP3EptPS7z581TAEglrnQ==; 24:7FO/ydNGBCnmjrkKpo6hgB1VfS8Cu7AV7zLFWKB58gFeOSNIm5aqBZlcGR2qyVVTylFUpWA9BGRPNLtoLsnvnmm+wFAs2N5BNgaP4bM8qqw=; 7:G6VYl40rrHyNUSoX6Q8aZn0hOQaArD/kS53dwag1t6SKV3XXEvejA1E+aSUdVU3YSmx2kh1hIu6y46LbgzoMwOYlKhRXd3O+1ukglJ78z5zkUvDKtli0gt6Yht/U+rHRSgYei+gB/NYuDZZNL4Xa19gD23vHHLwC+jwadm3rUp0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(54356999)(2900100001)(2950100001)(5004730100002)(11100500001)(8936002)(87936001)(5002640100001)(10400500002)(93886004)(586003)(76176999)(19580405001)(19580395003)(5008740100001)(189998001)(122556002)(77096005)(110136002)(3846002)(92566002)(50986999)(3280700002)(3660700001)(4001350100001)(106116001)(74482002)(36756003)(102836003)(6116002)(86362001)(2906002)(4326007)(81166006)(8676002)(66066001)(1220700001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <5950725919BA644392D4FB636B211649@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 10:24:35.6760 (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: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:24:56 -0000 SGkNCg0KT24gMTYvMDUvMjAxNiAxMToxNSwgIkFhcm9uIFphdW5lciIgPGF6ZXRAYXpldC5vcmc+ IHdyb3RlOg0KDQo+SGkgS2VubnksDQo+DQo+PiBPbiAxNiBNYXkgMjAxNiwgYXQgMTY6NDgsIFBh dGVyc29uLCBLZW5ueSA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4NCj4+d3JvdGU6DQo+PiAN Cj4+IE1heWJlIHRoZSBjb25mdXNpb24gaXMgdGhpczogaW4geW91ciBhdXRoZW50aWNpdHkgYXR0 YWNrLCB5b3UgZG8gcmVjb3Zlcg0KPj4gdGhlIEdIQVNIIGtleSwgYW5kIHRoZSBlZmZlY3QgaXMg Y2F0YXN0cm9waGljLiBJbiB0aGUgY29uZmlkZW50aWFsaXR5DQo+PiBhdHRhY2ssIG9uZSBjYW4g cmVjb3ZlciBwbGFpbnRleHRzIGZvciB0aGUgcmVjb3JkcyB3aXRoIHJlcGVhdGVkIG5vbmNlcywN Cj4+IGJ1dCBub3QgdGhlIGVuY3J5cHRpb24ga2V5LiBUaGUgZWZmZWN0IG1heSBiZSBiYWQgLSBi dXQgaXQncyBwZXJoYXBzIG5vdA0KPj4gYXMgY2F0YXN0cm9waGljIGluIHByYWN0aWNlIGFzIHRo ZSBhdXRoZW50aWNpdHkgYXR0YWNrLg0KPg0KPkFoLCBJIHNlZS4gWWVzIGFuZCB3ZSBkbyBub3Qg Y29uc2lkZXIgdGhpcyBpbiBvdXIgcGFwZXIgYXQgYWxsLiBNYXliZSB3ZQ0KPnNob3VsZD8gTm90 IHN1cmUgaG93IHByYWN0aWNhbCB0aGlzIGlzLg0KDQpHb29kIHRvIGdldCB0aGlzIGNsZWFyZWQg dXAuIFllcywgaXQncyBlbWluZW50bHkgcHJhY3RpY2FsIHRvIHJlY292ZXIgdGhlDQp0d28gcGxh aW50ZXh0cyBmcm9tIHRoZWlyIFhPUiBhc3N1bWluZyB5b3UgaGF2ZSBhIGdvb2QgbGFuZ3VhZ2Ug bW9kZWwNCihlLmcuIG9uZSBjYW4gdXNlIGEgTWFya292IG1vZGVsIHdpdGggYSBzdWl0YWJsZSBt ZW1vcnkgbGVuZ3RoOyB0aGlzIHdvdWxkDQp3b3JrIGZvciBIVFRQIHJlY29yZHMsIG5hdHVyYWwg bGFuZ3VhZ2UsIGV0YykuIFRvIGNvZGUgaXQgYWxsIHVwIGlzIG5vdA0KdHJpdmlhbCAtIEkgY3Vy cmVudGx5IHNldCBpdCBhcyBhIGZpbmFsIHllYXIgcHJvamVjdCBmb3Igb3VyIHVuZGVyZ3JhZA0K c3R1ZGVudHMsIGZvciBleGFtcGxlLiBUaGUgcGFwZXIgYnkgTWFzb24gZXQgYWwgZnJvbSBDQ1Mg MjAwNiBnaXZlcyBhIG5pY2UNCmFjY291bnQgb2YgdGhlIHdob2xlIGJ1c2luZXNzLg0KDQo+DQo+ PiBUaGluayBhYm91dCBpdCB0aGlzIHdheTogZm9yIHlvdXIgaW5qZWN0aW9uIGF0dGFjaywgeW91 IG5lZWQgdG8gcmVjb3Zlcg0KPj4gdGhlIENUUiBrZXlzdHJlYW0gLSBvdGhlcndpc2UgeW91IGNv dWxkbid0IHByb3Blcmx5IEFFUy1HQ00tZW5jcnlwdCB5b3VyDQo+PiBjaG9zZW4gcGxhaW50ZXh0 IHJlY29yZCBmb3IgdGhlIGluamVjdGlvbi4gQnV0IGlmIHlvdSByZWNvdmVyZWQgdGhlDQo+PiBr ZXlzdHJlYW0gYXMgcGFydCBvZiB5b3VyIGF0dGFjaywgdGhlbiB5b3UndmUgYWxzbyByZWNvdmVy ZWQgdGhlDQo+PnBsYWludGV4dA0KPj4gZm9yIHRoZSBvcmlnaW5hbCByZWNvcmQuDQo+PiANCj4+ IE9yIG1heWJlIGluIHlvdXIgaW5qZWN0aW9uIGF0dGFjayB5b3Ugd2VyZSBhc3N1bWluZyB5b3Ug YWxyZWFkeSAqa25ldyoNCj4+dGhlDQo+PiBwbGFpbnRleHQ/IFRoYXQgd291bGQgbWFrZSBzZW5z ZSwgSSBndWVzcyAtIGEgbG90IGVhc2llciB0aGVuIHRvIHJlY292ZXINCj4+IHRoZSBrZXlzdHJl YW0gdGhhbiBkb2luZyB0aGUgInVuZG9pbmcgdGhlIFhPUiIgYXR0YWNrIG5lZWRlZCB0byByZWNv dmVyDQo+PiBQXzEgYW5kIFBfMiBmcm9tIFBfMSBYT1IgUF8yLg0KPg0KPlRoZSBmaXJzdCBzdGVw IG9mIG91ciBhdHRhY2sgaW52b2x2ZXMgYXR0YWNrZXIgY29udHJvbGxlZCBjb250ZW50LiBTbyB5 ZXMNCj4ocGhpc2hpbmcsIHVuYXV0aGVudGljYXRlZCBIVFRQLCBzZWxlY3RpdmUgY29tcGFueSBE UEkgZXRjLikuIEluIG91cg0KPmV4YW1wbGUgd2UgdXNlIGEgbG9jYWwgcHJveHkgdG8gY2Fycnkg b3V0IHRoZSBhdHRhY2suIEkgaG9wZSBJIGNhbiBwb3N0IGENCj5mdWxsIHZlcnNpb24gb2YgdGhl IGFjdHVhbCBwYXBlciBhbmQgUG9DIHRvIHRoaXMgdGhyZWFkIHNvb24uDQoNCk9LLCBtYWtlcyBz ZW5zZSBub3cuDQoNCkNoZWVycw0KDQpLZW5ueSANCg0KPg0KPkFhcm9uDQoNCg== From nobody Mon May 16 11:41: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 D0CC612D92C for ; Mon, 16 May 2016 11:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 k3fT8Mcu3zq0 for ; Mon, 16 May 2016 11:41:47 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 B6FD812D5FC for ; Mon, 16 May 2016 11:41:47 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id qo8so25069686pab.1 for ; Mon, 16 May 2016 11:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=OJ+Gpvgb6O6UxE3LKoVU03+VyKPcI0CF4z7vyK9sjFo=; b=IMaVwT9ZW/vT0SWjzuuCgmNHk9FVRsv3KYAJyEbpPOlfZpcXWlYuwvAvDVKbZwsBrP OqVX0We+u1AFacptZ54Gow4LWSU4aVhT41iHSHqizvgoXBDsen1dF5dSio+bm5oOVU3p I1bf7URF/b8UflFG7EaIKGqjnNiwDI5TAth8o= 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 :message-id:references:to; bh=OJ+Gpvgb6O6UxE3LKoVU03+VyKPcI0CF4z7vyK9sjFo=; b=ekrgWaA++nuhtKUDAetURMA6Qs6o4IyRsCy07lRkejV/c1nMEucL7MXxjAwkdaRJkj rg9LLGk3t/u5zhMg8RdidzuCIgmAZ8FEiZTByaXnbnOrvdHxdQV33qqxF5jqS495xWM4 umxBuD+imt1RPo+iPTDm+xVVRDCq3jBtZA0JLb0KJiBaxnP0IupMZKfubornywqX3B6g xxpgff5ptACNZmbVDmcSN8wRhErWxqgvd0pWJlnjzLyIctGXrH2kA/s0Jvcz3dntG/Mp Nh7OHBBVXfbKA3tuIJdHEUiVSO/yyXiPXXirWzSjvpycsGONlHvmAR5roNaLewk9LxOh sLiw== X-Gm-Message-State: AOPr4FWX4d9tw+yGDg4nuJdrvpVi57Ry8EaMBGeON5Vqb1H7W8dcNzg7lhKb1hK3t0DdTg== X-Received: by 10.66.66.234 with SMTP id i10mr48254103pat.114.1463424107304; Mon, 16 May 2016 11:41:47 -0700 (PDT) Received: from [10.0.0.149] ([202.44.229.67]) by smtp.gmail.com with ESMTPSA id o2sm48851871pfi.85.2016.05.16.11.41.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 11:41:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_858C3C42-5445-4DB6-893E-D12A6E147BD4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Tue, 17 May 2016 01:41:39 +0700 Message-Id: References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "mcgrew@cisco.com" , "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:41:49 -0000 --Apple-Mail=_858C3C42-5445-4DB6-893E-D12A6E147BD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kenny, > On 16 May 2016, at 17:24, Paterson, Kenny = wrote: >=20 > Good to get this cleared up. Yes, it's eminently practical to recover = the > two plaintexts from their XOR assuming you have a good language model > (e.g. one can use a Markov model with a suitable memory length; this = would > work for HTTP records, natural language, etc). To code it all up is = not > trivial - I currently set it as a final year project for our undergrad > students, for example. The paper by Mason et al from CCS 2006 gives a = nice > account of the whole business. Yes, we (I?) mixed up two different attack vectors. I wasn't aware of the CCS 2006 paper, that was long before I got into = TLS, to be honest. I'll certainly read up on it. It's a really nice = undergrad project, I'm always happy to hear that universities do teach = practical attacks, let their students write PoC for them etc., = unfortunately I've seen quite the opposite on a lot of occasions and = lecturers teaching on out-dated crypto protocols and primitives or = trying to explain simple designs with very "esoteric" slide-decks. Anyhow: what has been said in the thread already on the attack does of = course make sense to me, but it isn't what I was referring to w.r.t. our = attack contribution. So I think I'm to blame for the confusion here. I = think both attacks are worth noting in the Errata as some implicitly = already mentioned before. Does anyone disagree on that? > OK, makes sense now. Perfect :) Thank you for the feedback, Aaron --Apple-Mail=_858C3C42-5445-4DB6-893E-D12A6E147BD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXOhRkAAoJEOTbZJL9ubXVAPMP/1Dt/5arnB0KFTPBKq81Ldpk pIOOOwcVWl11ESn/u8lIKKJZJkubpEtAlx5OpzrmiqiB+RMF3GnuXDfnV01QU0JX 2SVke1uY8kaTIKAz5XeQE7awBR76x2pwj8+D8NJSeA6kVtg+0yJ5JhI1cFF5+oEO B/6Of1KS9l8HSSlaaj3u30fwzqNZCS3ZAilzkzkw3cIDTKc1NonbgW4rG7hq7D3T 6Tn569/rCbx/G3J4hBdAwXK4lzrYR4iSG6WSEbd59HEdo2PMmuW8jyf8MWh6mSUI vmric4CVksKCpjvzoJdgsXXOxbncoZb3UbF3YPNjMLrexkH+HnnnUNt8pLOP4XM2 r6ru4rz2FzgNVea2/XQ6KqF38rCBsVAIod/6ah2sceKxg0d4Q9FykASMYDCsAOff VFwhky4SKz+CyXXqQUWkq0oSzflYpICxxAqmjWL3vepgcuIoIEwf/vOvOCxadrOQ NBYnjaBAQnnrFgJmZzIyKc1/pjDxtb/0qkBV91+fl96bpvnNMope17GRFSrUk508 0WGw6BEEK/EtYiQRj8RYKOWy1OdgFTlMF8ApI4WmfLFaexzXDHoHZ43nBTiIdyTO bT2hoom+qHW9HoaTG7pkjx/Du7T1maQZ3GdWcm9oOlJPMAHGzdL/okIV7tLi76Yo zvfZ954mwh6rnp30CbE2 =VBRS -----END PGP SIGNATURE----- --Apple-Mail=_858C3C42-5445-4DB6-893E-D12A6E147BD4-- From nobody Tue May 17 12:01:42 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 430DB12DD67; Tue, 17 May 2016 12:01:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517190137.24747.63798.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 12:01:37 -0700 Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Kathleen Moriarty's No Objection on draft-ietf-tls-falsestart-02: (with COMMENT) 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: Tue, 17 May 2016 19:01:38 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tls-falsestart-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a little confused by the experimental status given the shepherd write up. This is just a comment though... From nobody Tue May 17 13:14: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 8895712DDC3 for ; Tue, 17 May 2016 13:14:24 -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 LeitIhx11B8p for ; Tue, 17 May 2016 13:14:22 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBFE12DDC1 for ; Tue, 17 May 2016 13:14:21 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id bi2so81435070igb.0 for ; Tue, 17 May 2016 13:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ra94i833KV0ktPaDBXcuD+pN6xJPvThmMuN4+WVkxgU=; b=IOZ08p/DKbbFsdTl04889qzE2lTcCAuqnx/XuTWoWLYSKQQfEb4AGuDDsloGiK5VMh KU4wEhy52QyAfOf1Xkh/aNthiuRq6ikkR7OMpTt8C04W9lDorWYxtquEDUO7p2tuvCAu wuuuDR6pcP4/DAAtTnvy2yyDod2+SNvC2dMc0= 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=ra94i833KV0ktPaDBXcuD+pN6xJPvThmMuN4+WVkxgU=; b=VKb2cY6y4wpmIY22vYjHameYPDuvTgpOD7XdWbHP1KZJH3bumzBXyeEj4ZTkfZbxNc r3MUhtY7P8YeR+c6JCJPCQmb1VcPFuWB/el0gCa7PFY2P9iJpv7IVKBpwMDiqy4YRC6d sB7f6riR13o8J4R96WHVXpNKQoDAAk9qcQOa9qS79ZGmJMqKOaoAzbKBFsbrIzABwWJH acKpKw1NRTKc/IrpKsevt9IgxV1wFYv9DXLbPiacEqS7o67PJuBbJ/j05lJnDcHOGYfg 3/yD1/OCviJH+hyIwG5yxlgqP7gRbm4O2QDQi9uP5B8nrAZx651LkbVHoLs+L4JWdaqT SNcA== X-Gm-Message-State: AOPr4FXkG0O1KTiWOm+r0VjKOAGi1PnxltpK+fBgt/yWc6YNqyWy+GSxxxXfn04EqaShoK1jQdEBKqzCTdVkxVDu X-Received: by 10.50.18.132 with SMTP id w4mr2619171igd.83.1463516061113; Tue, 17 May 2016 13:14:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 17 May 2016 20:14:11 +0000 Message-ID: To: Russ Housley , Maarten Bodewes Content-Type: multipart/alternative; boundary=14dae93b57d2f29b9705330f62b3 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 May 2016 20:14:24 -0000 --14dae93b57d2f29b9705330f62b3 Content-Type: text/plain; charset=UTF-8 Reviving this thread, I also think it would also be a good idea if 1.3 did not stripping zeros from Z. Having this logic is rather dubious w.r.t. treating secret data in constant-time. And as Bill Cox mentioned elsewhere in this thread, this odd behavior has caused interoperability issues in the past. I don't think we have to be worried about inconsistency with 1.2 as, by the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE is already a very different beast from TLS 1.2 DHE. At this point, the only thing they meaningfully share is they happen to use the same code points. David On Thu, Apr 7, 2016 at 10:37 AM Russ Housley wrote: > I would prefer to always use the full, known-length byte string for Z. In > my experience, it is better to know the lengths of byte strings instead of > stripping leading zeroes. The difference in the speed of the HKDF > computation by omitting the leading zeros is not significant. Alignment > with NIST SP 800-56A is nice, but it is not the reason for my preference. > > Russ > > > On Mar 28, 2016, at 11:56 AM, Maarten Bodewes > wrote: > > > Hi all, > > > > I see that the leading zero is stripped off of the value of Z (the > shared secret) before it is used as input to HKDF. This seems to be > compatible with TLS 1.2. Then again, it is not compatible with e.g. > NISP800-56A which uses the value of Z with the same size of the prime in > octets. Furthermore, it is also different with regards to handling the > coordinate X as used in ECDH. > > > > Was this a conscious decision to keep compatibility with TLS? Has the > use of the value of Z including zero octets been considered? > > > > Regards, > > Maarten > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --14dae93b57d2f29b9705330f62b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reviving this thread, I also think it would also be a good= idea if 1.3 did not stripping zeros from Z. Having this logic is rather du= bious w.r.t. treating secret data in constant-time.=C2=A0And as Bill Cox mentioned elsewhere in this thread, this odd = behavior has caused interoperability issues in the past.

I don't think we have to be worried about inconsistency with 1.= 2 as, by the time this happens, we will already know we're speaking 1.3= . TLS 1.3 DHE is already a very different beast from TLS 1.2 DHE. At this p= oint, the only thing they meaningfully share is they happen to use the same= code points.

David

=
On Thu, Apr 7, 2016 at 10:37 AM= Russ Housley <housley@vigilsec.com> wrote:
maarten.bodewes@gmail.com> wro= te:

> Hi all,
>
> I see that the leading zero is stripped off of the value of Z (the sha= red secret) before it is used as input to HKDF. This seems to be compatible= with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which= uses the value of Z with the same size of the prime in octets. Furthermore= , it is also different with regards to handling the coordinate X as used in= ECDH.
>
> Was this a conscious decision to keep compatibility with TLS? Has the = use of the value of Z including zero octets been considered?
>
> Regards,
> Maarten

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--14dae93b57d2f29b9705330f62b3-- From nobody Tue May 17 14:07: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 A0D8C12D615 for ; Tue, 17 May 2016 14:07:07 -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 Trfaf-l0uZn6 for ; Tue, 17 May 2016 14:07:04 -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 6F55D12D1DF for ; Tue, 17 May 2016 14:07:04 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id n63so16356748qkf.0 for ; Tue, 17 May 2016 14:07:04 -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=MpDejFVdzXRMlhi3UwAuCgy+LfcPDe2Us2az5bmMBak=; b=uSSEYN1UHoOmpWv4UN+6uDRZTu+/u+kwhdWvUnoHjQluswhkWcMwCyIY3IJmzdi+NE 6cJfSnK/jqS1Dw57NDxAE6TbdLvq44WFGHu8ceGXtGOTtMAOURvE+KFsSarBxL/J73Tp L7aVGJplzdyTzeVBjfL60XtnCzA8k8dcBylHFpOQGm81PkhRSPeLDENnbHdtTTdkTf8s 3GO2al59qtCSL11JqEAb/L8BQTMt3WtsLzJ7oUMvLoAYK70xSugp9QaC9i6pxC/rva23 wC013SwmSLTH0RCIgGOAtMcWAhny4CIsO6UulsPWkKqPbJkVPkMZWYH5ocoGMPfKRZUQ +QaQ== 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=MpDejFVdzXRMlhi3UwAuCgy+LfcPDe2Us2az5bmMBak=; b=KeZMNTo393e13dojCiIbwXSR4Wpsc+pSAmTK6MJ5y85wqft/BMcUYcqueKxpAZlDf9 Y9wl0HO7XeSpeOVkiFzzZaO6eU9hO0zRQ+paEKr9vL1AorW2uMT0EMU+kHKf62iS3FlM CvITabbRaSJGa245JyYmMlX0xOt78gKxgHSIiffr9rYSvvnyFZC5HAbeq226k5IT2P8n i+vC73RcEc3DUGBoIFjmxX7wiYV/3u3QWzp4kNcKWeBcFTZK312vxaaYFAJNatWWvTsb SGNMgahXSArT9HjcOdVo2VGplTq7lgzF2kB3Qjee2I0GM4EPgTu9TgYq1ZmqIsZUYswj GsxA== X-Gm-Message-State: AOPr4FULKcPFWXr3NxP/sy4PQ6VFVA5c67R64HBUdjCaZgya1L7o3eAcjKbPRA+6UenDUY+iIZI2sAEnNTfKEQ== X-Received: by 10.55.203.132 with SMTP id u4mr4125935qkl.12.1463519223477; Tue, 17 May 2016 14:07:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.175.196 with HTTP; Tue, 17 May 2016 14:06:44 -0700 (PDT) In-Reply-To: <5739981E.501@ericsson.com> References: <5739981E.501@ericsson.com> From: Joseph Salowey Date: Tue, 17 May 2016 14:06:44 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11416c707030e90533101f81 Archived-At: Cc: "tls@ietf.org" , IETF AVTCore WG Subject: Re: [TLS] Updated text in regards to draft-ietf-avtcore-rfc5764-mux-fixes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 May 2016 21:07:07 -0000 --001a11416c707030e90533101f81 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, The revision addresses the comments I had. If anyone else still has concerns please respond this week. Thanks, Joe On Mon, May 16, 2016 at 2:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > TLS WG, > (Cc AVTCORE WG) > > When AVTCORE run a WG last call earlier this year on "Multiplexing Scheme > Updates for Secure Real-time Transport Protocol (SRTP) Extension for > Datagram Transport Layer Security (DTLS)": > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > There was several comments from the TLS WG in regards to the update of th= e > TLS content type registry as well as the limited applicability of the > multiplexing scheme used. > > The authors have written an updated text proposal. I would really > appreciate if you could review these changes and provide any feedback. > > A diff between the previously WG version and the current one: > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-avtcore-rfc5764-mux-fixes-= 05&url2=3Ddraft-ietf-avtcore-rfc5764-mux-fixes-07 > > The update TLS related text is: > > 4. Implicit Allocation of New Codepoints for TLS ContentTypes > > The demultiplexing scheme in [RFC5764] dictates that if the value of > the first byte is between 20 and 63 (inclusive), then the packet is > identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347] > that first byte corresponds to the TLS ContentType field. > Considerations must be taken into account when assigning additional > ContentTypes in the code point ranges 0 to 19 and 64 to 255 so this > does not prevent demultiplexing when this functionality is desirable. > Note that [RFC5764] describes a narrow use of DTLS that works as long > as the specific DTLS version used abides by the restrictions on the > demultiplexing byte (the ones that this document imposes on the TLS > ContentType Registry). Any extension or revision to DTLS that causes > it to no longer meet these constraints should consider what values > may occur in the first byte of the DTLS message and what impact it > would have on the multiplexing that [RFC5764] describes. > > With respect to TLS packet identification, this document explicitly > adds a warning to the codepoints from 0 to 19 and from 64 to 255 > indicating that allocations in these ranges require coordination, as > described in this document. The proposed changes to the TLS > ContentType Registry are: > > OLD: > > 0-19 Unassigned > 20 change_cipher_spec > 21 alert > 22 handshake > 23 application_data > 24 heartbeat > 25-255 Unassigned > > NEW: > > 0-19 Unassigned (Requires coordination, see RFCXXXX) > 20 change_cipher_spec > 21 alert > 22 handshake > 23 application_data > 24 heartbeat > 25-63 Unassigned > 64-255 Unassigned (Requires coordination, see RFCXXXX) > > As document shepherd I intended to run a new WG last call in a weeks time= , > so please provide feedback quickly so that we know if this update is okay= , > or needs additional revisions. > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11416c707030e90533101f81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Magnus,

The revision addresses the c= omments I had.=C2=A0 If anyone else still has concerns please respond this = week. =C2=A0

Thanks,
Joe
=

On Mon, May 16, 2= 016 at 2:51 AM, Magnus Westerlund <magnus.westerlund@ericsson= .com> wrote:
TLS WG,
(Cc AVTCORE WG)

When AVTCORE run a WG last call earlier this year on "Multiplexing Sch= eme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Da= tagram Transport Layer Security (DTLS)":
https://datatracker.ietf.org/d= oc/draft-ietf-avtcore-rfc5764-mux-fixes/

There was several comments from the TLS WG in regards to the update of the = TLS content type registry as well as the limited applicability of the multi= plexing scheme used.

The authors have written an updated text proposal. I would really appreciat= e if you could review these changes and provide any feedback.

A diff between the previously WG version and the current one:
https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-av= tcore-rfc5764-mux-fixes-05&url2=3Ddraft-ietf-avtcore-rfc5764-mux-fixes-= 07

The update TLS related text is:

4.=C2=A0 Implicit Allocation of New Codepoints for TLS ContentTypes

=C2=A0 =C2=A0The demultiplexing scheme in [RFC5764] dictates that if the va= lue of
=C2=A0 =C2=A0the first byte is between 20 and 63 (inclusive), then the pack= et is
=C2=A0 =C2=A0identified to be DTLS.=C2=A0 For DTLS 1.0 [RFC4347] and DTLS 1= .2 [RFC6347]
=C2=A0 =C2=A0that first byte corresponds to the TLS ContentType field.
=C2=A0 =C2=A0Considerations must be taken into account when assigning addit= ional
=C2=A0 =C2=A0ContentTypes in the code point ranges 0 to 19 and 64 to 255 so= this
=C2=A0 =C2=A0does not prevent demultiplexing when this functionality is des= irable.
=C2=A0 =C2=A0Note that [RFC5764] describes a narrow use of DTLS that works = as long
=C2=A0 =C2=A0as the specific DTLS version used abides by the restrictions o= n the
=C2=A0 =C2=A0demultiplexing byte (the ones that this document imposes on th= e TLS
=C2=A0 =C2=A0ContentType Registry).=C2=A0 Any extension or revision to DTLS= that causes
=C2=A0 =C2=A0it to no longer meet these constraints should consider what va= lues
=C2=A0 =C2=A0may occur in the first byte of the DTLS message and what impac= t it
=C2=A0 =C2=A0would have on the multiplexing that [RFC5764] describes.

=C2=A0 =C2=A0With respect to TLS packet identification, this document expli= citly
=C2=A0 =C2=A0adds a warning to the codepoints from 0 to 19 and from 64 to 2= 55
=C2=A0 =C2=A0indicating that allocations in these ranges require coordinati= on, as
=C2=A0 =C2=A0described in this document.=C2=A0 The proposed changes to the = TLS
=C2=A0 =C2=A0ContentType Registry are:

=C2=A0 =C2=A0OLD:

=C2=A0 =C2=A00-19=C2=A0 =C2=A0 Unassigned
=C2=A0 =C2=A020=C2=A0 =C2=A0 =C2=A0 change_cipher_spec
=C2=A0 =C2=A021=C2=A0 =C2=A0 =C2=A0 alert
=C2=A0 =C2=A022=C2=A0 =C2=A0 =C2=A0 handshake
=C2=A0 =C2=A023=C2=A0 =C2=A0 =C2=A0 application_data
=C2=A0 =C2=A024=C2=A0 =C2=A0 =C2=A0 heartbeat
=C2=A0 =C2=A025-255=C2=A0 Unassigned

=C2=A0 =C2=A0NEW:

=C2=A0 =C2=A00-19=C2=A0 =C2=A0 Unassigned (Requires coordination, see RFCXX= XX)
=C2=A0 =C2=A020=C2=A0 =C2=A0 =C2=A0 change_cipher_spec
=C2=A0 =C2=A021=C2=A0 =C2=A0 =C2=A0 alert
=C2=A0 =C2=A022=C2=A0 =C2=A0 =C2=A0 handshake
=C2=A0 =C2=A023=C2=A0 =C2=A0 =C2=A0 application_data
=C2=A0 =C2=A024=C2=A0 =C2=A0 =C2=A0 heartbeat
=C2=A0 =C2=A025-63=C2=A0 =C2=A0Unassigned
=C2=A0 =C2=A064-255=C2=A0 Unassigned (Requires coordination, see RFCXXXX)
As document shepherd I intended to run a new WG last call in a weeks time, = so please provide feedback quickly so that we know if this update is okay, = or needs additional revisions.

Cheers

Magnus Westerlund
AVTCORE WG chair


----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--001a11416c707030e90533101f81-- From nobody Tue May 17 17:15:27 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 5911B12D54A; Tue, 17 May 2016 17:15:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518001524.24828.34990.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 17:15:24 -0700 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org, The IESG , draft-ietf-tls-cached-info@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] Protocol Action: 'Transport Layer Security (TLS) Cached Information Extension' to Proposed Standard (draft-ietf-tls-cached-info-23.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: Wed, 18 May 2016 00:15:24 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) Cached Information Extension' (draft-ietf-tls-cached-info-23.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ Technical Summary This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. Working Group Summary This document has gone through a long working group process and many revisions. We believe the document has had sufficient review and is ready for publication. The TLS working group consensus around the document is not strong, as the main body of interest for this work is in the DICE group. Document Quality This document has had extensive review over a long period of time in the TLS working group. The document is a dependency of the DICE working group. Personnel Joseph Salowey is the document shepherd. The responsible AD is Stephen Farrell. IANA Note In section 8.2, please mark the value zero (0) as reserved. (As suggested by Barry Leiba in his IESG review.) From nobody Tue May 17 21:19: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 30B3A12D10C for ; Tue, 17 May 2016 21:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 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, URIBL_RHS_DOB=1.514] 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 F_H_-q5u_ps5 for ; Tue, 17 May 2016 21:19:06 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747BF12D512 for ; Tue, 17 May 2016 21:19:06 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id w36so19732663qge.3 for ; Tue, 17 May 2016 21:19:06 -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=rGR8upTFh3P1S5LCXA4nN7VT9ryVcc6sVsiPEIgdkKE=; b=zxccOjoFU/BkDlcmGaBMiC6SyZmCphxkp6mx0k7dBjuffYfRnlAk8GMWASPZwxaaC4 V5uxdvh+5cVtlBjJjXotNk2VUJdMmtfjyd0ifTP9IRXMqz8J8ZpzaKQYFpsFfcxVowyp /Gl9qHQgPRKKehqOVdbIKZlxC9oKZ1s4R3Fdts3bt2d7QwVTeUpqs0Yf6jL7n0FGwMI5 oOX3kjyz2PDZWs50BUoCE2t9j4uRX6s/Qz36/AUZQZLKshoA2UBh4x02E1v73WLK14PU fVgK0kOT3qCDMH5WOJExMr9BjYMCK5rBcmJqL25VnDy53LfE6mGUKgX+badmv8YvJ4rL E8+Q== 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=rGR8upTFh3P1S5LCXA4nN7VT9ryVcc6sVsiPEIgdkKE=; b=bmSJB7vk3QAwUccc97A2L75CKXdMh1NWNEWWz2cvPfNXn9RJVUYVX7Ld/8v1+psyyn 7u+13YI8V5bOb0Ijgw1/Vuucphcv/udbBjeHlN6VN+E8jDjdRmqrJfKTWeFAEUQUR5vm IvsMquc/gKQVl8rTWvpHeVRNOd1kGBuMXK65QKUgyqj63GljCH1sRW3KoPrsqpbpSk5W ARSss+uZwE06RxhWBB5owHs47df5H6y9w/QaNaOnU52O6+QZqNVagXlbYZb15/VXxwqb G1nBY1mabCYkMB0N+zGlvHPzvD2kE1H1LAb4mE+EC/Bqf1QGezrYCFIJE1/oBRmx+iae aRWQ== X-Gm-Message-State: AOPr4FWtMyn/+bVliNtSzR5Z+teId5f6JDCmSoKuorv8B86Eg/0FnLAqEcfb8VwMlD1jl2SLUXi6gJOM53FRmA== X-Received: by 10.140.32.161 with SMTP id h30mr5309791qgh.51.1463545145607; Tue, 17 May 2016 21:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.175.196 with HTTP; Tue, 17 May 2016 21:18:46 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Tue, 17 May 2016 21:18:46 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a113a797c845e8a053316289b Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 04:19:08 -0000 --001a113a797c845e8a053316289b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The discussion on the list has not changed the consensus from the IETF 95 meeting, 0-RTT client authentication should be removed from the draft. Cheers, J&S On Tue, Mar 29, 2016 at 5:59 AM, Sean Turner wrote: > All, > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA s= essions, > we need to make sure there=E2=80=99s consensus on a couple of outstanding= issues. > So... > > It seems that there is a clear consensus not to support 0-RTT client > authentication in TLS 1.3 at this time. If you think 0-RTT client > authentication needs to be supported please indicate so now and provide > your rationale. > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113a797c845e8a053316289b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The discussion on the list= has not changed the consensus from the IETF 95 meeting, 0-RTT client authe= ntication should be removed from the draft. =C2=A0

Cheers,

J&S<= /div>

On Tue= , Mar 29, 2016 at 5:59 AM, Sean Turner <sean@sn3rd.com> wrote:<= br>
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

It seems that there is a clear consensus not to support 0-RTT client authen= tication in TLS 1.3 at this time.=C2=A0 If you think 0-RTT client authentic= ation needs to be supported please indicate so now and provide your rationa= le.

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

--001a113a797c845e8a053316289b-- From nobody Wed May 18 07:10: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 0255112D1D9 for ; Wed, 18 May 2016 07:10: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 uDQYkFEHPJIE for ; Wed, 18 May 2016 07:10:30 -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 6309F12D1BB for ; Wed, 18 May 2016 07:10:30 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id d62so66297468iof.2 for ; Wed, 18 May 2016 07:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=R4FOu4hOsor9WDqJpXOasJg39leXbBFLz3izWuH9V5Q=; b=GmyR8ZGLJMBt0Xu+P5qM//B+v4bTqtCqbcg8iP4lcMyBQqimtqVBXRAUZswY4DHemD NGkwMNA67H0nFz9So9s2yLarLv/Qfgwc/SPLt7LrN1H+nfH1b6qGXzbzn7Kki7z07FUa Lf5cBKpB8sVi1mnNZNlT09umpFSKzuVCAC4NNKF8dnfh/mcBmgSkfoyRtlrh7Nv2mfMP aFRm03/eZjTvzjbXi/F63X3DO6FxebLvrfGsJF6qcwmev+YP040XSGYbCWJR0pCWca53 izOEixQG2QY3KW5eB0PDB4BF2qNoJ31w3TvnLw3MVG1bgE7lC4l5kjWC38Vzr96euUV7 2q2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=R4FOu4hOsor9WDqJpXOasJg39leXbBFLz3izWuH9V5Q=; b=m5/Xi1tNd1Mp8g0DfIjQZy22GsIRsAxQdy0md7QIcXZgYRx+Aqjpeep4kuE9e9zu32 N0cqfX1ebNHNqRa1djKtAjy5DF4NUPsBYnAeUtX4OMYJdATFzRM4XJIaVIBN876iiuS9 Vz76x/Yv29UNa+6SD4/6Mgs5ubQPelaH1E4wz/fo6BAAMQz/6a/vTH34uS0r2mNtXTYL slTjUMp/90r+eDBflmjQXZQMJszfMpP801Oap5leUB108qYV4fVxdh/vFE39s7jGjyGU rs2Ef0bJzP0n44klEps3aIzQZFiF+ApVGULIlU1rguvl6+xSEgKppOiS1S4euZv2XyFG HsQQ== X-Gm-Message-State: AOPr4FV98WJJk8RIKyFF3JCzfeviLYjeiNtrnHquftz3Cq2AB4Zcx4CMVWY/FPsmZorsKbXYu2NTATYROSmnRg== MIME-Version: 1.0 X-Received: by 10.36.139.71 with SMTP id g68mr17843342ite.68.1463580629597; Wed, 18 May 2016 07:10:29 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 18 May 2016 07:10:29 -0700 (PDT) Date: Wed, 18 May 2016 10:10:29 -0400 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Asking for certificate authentication when doing 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: Wed, 18 May 2016 14:10:33 -0000 I just posted this: https://datatracker.ietf.org/doc/draft-thomson-tls-0rtt-and-certs/ It's fairly self explanatory. The idea is to create a way to signal that the client wants the server to re-authenticate itself, even if it successful in using a pre-shared key. From nobody Wed May 18 10:16: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 6C9C012D5A9 for ; Wed, 18 May 2016 10:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 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, URIBL_RHS_DOB=1.514] 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 lmCVJ46sD8Oo for ; Wed, 18 May 2016 10:15:59 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B050512D566 for ; Wed, 18 May 2016 10:15:59 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id 90so29484551qgz.1 for ; Wed, 18 May 2016 10:15:59 -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=KaXLWTJbcnEpz1XRZenuaN3Zj5UU3adGmHnrYn7Z4GM=; b=OxI0UjTku5KGIiYvKYzrZwp3glL17k5UqHpm+YTRzv8qgrGTYgZYP1rG5uUJeT876R 9LRLXWrEVkPJWkXZQG8WpDsPirZw53vJ9uLmChgDyVh2BL4vFgbzvRfJkZ5ZF2ob1tW7 oGBWmzPR+j0tN3i2TrzePFlJNOR6SomuQVzeNoSZdmJ52bkqWWffQKfMjMXauhB5nEkI 7454cZqmYCOe6uKiN1azLhtLcUUhP6FneQourYgLXFKLsGK1pgxV/KOhWuWoSB2Bia9C bdcYffzWvIX11mMdU6v2QH3Ez86eAVn5JWee+l+36pEceVj8mAmvIu8IuuJrdQ4v9kRW v6pw== 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=KaXLWTJbcnEpz1XRZenuaN3Zj5UU3adGmHnrYn7Z4GM=; b=Y4Eyhw5ZqU1C7eORktxoP5p8yDMY+uZn/Ir1U3Q7jWuXvSs7INfUc/Iptqg5NPeCat ZEOlq3306GnRKZ8nZ9kmIpSRg/OKjZaTfwTxR7RhHdgZd4Fsh2T5H3H8VpuE0MSGY3tM ZeihVvyue3Mo4tASBmXd2bLJWCuudavc1vf/YCoqZz7/KpWGKnc11/BdSgnikb3kXQzw V4K6DTemgsgVAiyoCXzTJARwqNvnSb9y0JoLolmDbBr0xfvAQagZ5ofSDNaWa4ckSuaD tm7GmDktWR+g8gV5g4L/g32DvqaorsKdY+4VK5vYmSaI2bpzALrCPSpgSN/cAr2FWqZr ovbw== X-Gm-Message-State: AOPr4FUtVLAd4KsaXQ9F31rJDJ48q3TUmpHAwcl7X9Q/EbiefjvtRnJnOy8w42ebssbGV7kI+7I+H7iXXMaD1g== X-Received: by 10.140.235.14 with SMTP id g14mr8866137qhc.86.1463591758718; Wed, 18 May 2016 10:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.175.196 with HTTP; Wed, 18 May 2016 10:15:39 -0700 (PDT) In-Reply-To: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Joseph Salowey Date: Wed, 18 May 2016 10:15:39 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a11355fd8e0005105332102b9 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 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: Wed, 18 May 2016 17:16:01 -0000 --001a11355fd8e0005105332102b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The discussion on the list supports the consensus in the IETF 95 meeting to remove DHE-based 0-RTT modes. The mode should be removed from the draft. Cheers, J&S On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > All, > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA s= essions, > we need to make sure there=E2=80=99s consensus on a couple of outstanding= issues. > So... > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mo= de > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT ar= e > almost identical, but 0-RTT PSK has better performance properties and is > simpler to specify and implement. Note that this does not permanently > preclude supporting DHE-based 0-RTT in a future extension, but it would n= ot > be in the initial TLS 1.3 RFC. > > If you think that we should keep DHE-based 0-RTT please indicate so now > and provide your rationale. > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11355fd8e0005105332102b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The dis= cussion on the list supports the consensus in the IETF 95 meeting to remove= DHE-based 0-RTT modes.=C2=A0 The mode should be removed from the draft.=C2= =A0

Cheers,

J&S

On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <sean@sn3= rd.com> wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE=C2= =A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT= are almost identical, but 0-RTT PSK has better performance properties and = is simpler to specify and implement. Note that this does not permanently pr= eclude supporting DHE-based 0-RTT in a future extension, but it would not b= e in the initial TLS 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and= provide your rationale.

J&S

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

--001a11355fd8e0005105332102b9-- From nobody Wed May 18 18:16:56 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 881E412B068; Wed, 18 May 2016 18:16:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519011652.14629.36754.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 18:16:52 -0700 Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Alia Atlas' No Objection on draft-ietf-tls-falsestart-02: (with COMMENT) 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: Thu, 19 May 2016 01:16:52 -0000 Alia Atlas has entered the following ballot position for draft-ietf-tls-falsestart-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- For Stephen, yes, I noticed :-) In support of Kathleen's comment and based on the shepherd's write-up, why is this experimental and what is the experiment? From nobody Wed May 18 18:30: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 09EAF12B032; Wed, 18 May 2016 18:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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] 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 66tT7zwWM-XC; Wed, 18 May 2016 18:30:50 -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 84C9012D14B; Wed, 18 May 2016 18:30:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27178BE2C; Thu, 19 May 2016 02:30:49 +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 oHJ9etFI8EZ2; Thu, 19 May 2016 02:30:47 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40DE8BDF9; Thu, 19 May 2016 02:30:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463621447; bh=FPR3UqTqhPP8pxzZzQ3UkeHXgPn94JmpmHFjwcnAUOg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ISWiCXB1UwKGIHiTQG/L/xkrU5+iJdsg8sq0uH8DGoTMLwpyZsPZFhAQdMPKpgN1L l2lwD3LhzXpq6o8EgN3wepJMMiRlojrHiTVN19xyxd6CZPfJmmyXYr8Le1DXYANNT/ KLMOoG7T04n7dsfQtBJm+cNuTQllwUvPcuqNnR7E= To: Alia Atlas , The IESG References: <20160519011652.14629.36754.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573D1746.2000301@cs.tcd.ie> Date: Thu, 19 May 2016 02:30:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519011652.14629.36754.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010802090306020501040507" Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: Re: [TLS] Alia Atlas' No Objection on draft-ietf-tls-falsestart-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 01:30:52 -0000 This is a cryptographically signed message in MIME format. --------------ms010802090306020501040507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/05/16 02:16, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-tls-falsestart-02: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > For Stephen, yes, I noticed :-) Great. Sean's is better though:-) >=20 > In support of Kathleen's comment and based on the shepherd's write-up, > why is this experimental and what is > the experiment? There's no good answer, sorry. I knew folks would ask, so I asked the WG and it seems to me to be a case that nobody cares really so they just picked one and aren't much energised to talk more about it. That's not too unreasonable. See the thread at [1] for some more. Given that this is widely deployed and a similar feature is being included in TLS1.3, there is no real experiment here, what the WG care about is that this RFC be not-PS I reckon. S. [1] https://mailarchive.ietf.org/arch/msg/tls/UDiFtVrQhjP9MXMW45tiYHrCDn8= >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms010802090306020501040507 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkw MTMwNDZaMC8GCSqGSIb3DQEJBDEiBCDFJapw3VtDN+ilmC2s8BTDGLs3xORKKHvFxikRgraQ 7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB4DrpAA80CX+4Qs1ZnhGhbMRPfQYZdwYQE88XXm+6AdC3/sqDlpnDa Hx37fXxfZGnDqPnefXjVvooZcrCvVDkcE69oPPln2TxKaatmZNxCtdA9jryk+0qFof81XClO So20m4VwbaMePW3ihQ0sGVaNOAHLkIQcHIcg/9uBFM+S51RZH9kAl1S6VXdzXy76/um3Dwj2 60M6Os8SsfaIYB/9VJQ4/EFMQO3WeCvv3xIe731n+rI6Vu04C5tKfuLxN2CiKA84earpr0vB Dwgs14X6T2HbYhKGoIKGdreEGew/S3vq8gszX2FE47kINdnQMaEWgVR1AHyrLpuNHSHMBfjG AAAAAAAA --------------ms010802090306020501040507-- From nobody Thu May 19 02: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 C1CD312D512; Thu, 19 May 2016 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPa3X_SnA2Bf; Thu, 19 May 2016 02:46:04 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 115B512D542; Thu, 19 May 2016 02:46:03 -0700 (PDT) Received: from mail-lf0-f44.google.com ([209.85.215.44]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MGiBd-1apuGW3wgr-00DW07; Thu, 19 May 2016 11:46:02 +0200 Received: by mail-lf0-f44.google.com with SMTP id u64so32976197lff.3; Thu, 19 May 2016 02:46:00 -0700 (PDT) X-Gm-Message-State: AOPr4FUbbXhvnwN2KRjbrASEAtDf3TpgsydPDtA4cRRK71A1K7VNAhOSBWKJkK9JSoOvslNz/R87r66g1J7nCw== MIME-Version: 1.0 X-Received: by 10.25.211.11 with SMTP id k11mr4246875lfg.153.1463651160093; Thu, 19 May 2016 02:46:00 -0700 (PDT) Received: by 10.25.33.129 with HTTP; Thu, 19 May 2016 02:46:00 -0700 (PDT) In-Reply-To: <573D1746.2000301@cs.tcd.ie> References: <20160519011652.14629.36754.idtracker@ietfa.amsl.com> <573D1746.2000301@cs.tcd.ie> Date: Thu, 19 May 2016 11:46:00 +0200 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1140d43478fd5a05332ed7e8 X-Provags-ID: V03:K0:bKEIW4LdR+3bV//gGzPjgKxaNP3s4b6NK2P0tL0ADuTZA/YlUMo X2fR/+W12IzxdzruZk0iEmnyyclKOmewrgJtCkYI45sHo/2aHrIyG0HnNTWaqmN5Qm9zJyG onOyp94BYGcLv9j4cDKUJQomu0pPiZ1GbhCEOuuRHLJLIGWOeSlCMZr/jIwUJizxBkYcJfm kbSh7JCBmBX+mjenfMnBw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5idGczCxz7c=:4IS8RqzgrivC6AP7eHe50P XtU7RAMXhPlbCBhXC82AbaTBe2Z23E9z0aL2lHzkUhcdZTcTTHN2+g621IXzho9mZaR3f0k0Z 5ytYj+BLxJAcHiWRfJb3G8EwCeSF7s+sEWTep1YCd35GusJbE4D1hkvn9QEpP8PCQ7dmfZ0YA owDAu6+51iK68ONdddG1A6CKL8VtiOs32yi7q9oT9I7QlARZ6KeLAU56Q8I9Jl9ic6s6wMLuW 2RefFx3jGw3/89SRpTqGwMruOwwTmXOk8m9ycvfWE3MFz/GzYJlK4joeQGrOlL86nBXLJK94f uUrmcfYO0nYbLVs89kg00vWCY8wrArdvzUXibYfpiP2GulKOx8sHwART/Q+XE3o5vrkpUHUPW pZTX6X6smyvcfghXt4+cYTLg1g/p+BDZMZBEH205XJ6BSn0g/qUe5u+hTIqJK7+bvDrzEgmgx Hh/RZlF4iR0cQA843i72uWWdKPeO5hNvPvlsCapRRT99AE4r9waxEVz1PbsT1IMCgrs/2bt9b xAtG8fu4KsfWnHE4JqehY8HfulraRtGTInsnlXxKSF2308exjtW8hH5b4HzFZFpMriR/eNLp8 NLBha+lCbxoRWsjUdh7yk7tlsArTBxECz8qR1JcA2xzZ+u3+J6WePVePShRypGNhZWmLS0+m8 JyQzEwPZ9bLcnyM2dY/jc44Tdqo316qACdashf5HbzgWYWjD7SCIIj1RE9YfD0taquIdZj6p1 CSnZfgV8/2rsb5/b/4aExxQLrD2wtOwlHakrEA== Archived-At: Cc: tls-chairs@ietf.org, draft-ietf-tls-falsestart@ietf.org, The IESG , "tls@ietf.org" , Alia Atlas Subject: Re: [TLS] Alia Atlas' No Objection on draft-ietf-tls-falsestart-02: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:46:06 -0000 --001a1140d43478fd5a05332ed7e8 Content-Type: text/plain; charset=UTF-8 Stephen Farrell : > In support of Kathleen's comment and based on the shepherd's write-up, > > why is this experimental and what is > > the experiment? > > There's no good answer, sorry. I knew folks would ask, so I asked > the WG and it seems to me to be a case that nobody cares really so > they just picked one and aren't much energised to talk more about > it. That's not too unreasonable. See the thread at [1] for some > more. > > Given that this is widely deployed and a similar feature is being > included in TLS1.3, there is no real experiment here, what the WG > care about is that this RFC be not-PS I reckon. > [1] https://mailarchive.ietf.org/arch/msg/tls/UDiFtVrQhjP9MXMW45tiYHrCDn8 I'm certainly completely fine with "Informational". Based on the criteria in https://www.ietf.org/iesg/informational-vs-experimental.html Section 3 (specifically, #4), I decided last year that "Experimental" seemed more appropriate than "Informational" (revising what I'd said a bit earlier in https://www.ietf.org/mail-archive/web/tls/current/msg16193.html). Given the current wide deployment, however, I agree that this isn't really an experiment at this point. As far as I am aware, no one really would prefer "Experimental" over "Informational" for this spec, while I've seen the opposite a few times (and most, presumably, just don't care one way or the other). Thus, the document probably should be "Informational" after all. Bodo Bodo --001a1140d43478fd5a05332ed7e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Step= hen Farrell <stephen.farrell@cs.tcd.ie>:

> In support of Kathleen's comment and based on the shepherd's w= rite-up,
> why is this experimental and what is
> the experiment?
=C2=A0
There's no good answer, sorry. I knew folks would ask, so I aske= d
the WG and it seems to me to be a case that nobody cares really so
they just picked one and aren't much energised to talk more about
it. That's not too unreasonable. See the thread at [1] for some
more.

Given that this is widely deployed and a similar feature is being
included in TLS1.3, there is no real experiment here, what the WG
care about is that this RFC be not-PS I reckon.
=C2=A0
[1] https://mailarchive.ietf.or= g/arch/msg/tls/UDiFtVrQhjP9MXMW45tiYHrCDn8

<= div>I'm certainly completely fine with "Informational".
=

Based on the criteria in=C2=A0https://www.ietf.org/iesg/i= nformational-vs-experimental.html Section 3 (specifically, #4), I decid= ed last year that "Experimental" seemed more appropriate than &qu= ot;Informational" (revising what I'd said a bit earlier in=C2=A0h= ttps://www.ietf.org/mail-archive/web/tls/current/msg16193.html).
<= div>
Given the current wide deployment, however, I agree that= this isn't really an experiment at this point. As far as I am aware, n= o one really would prefer "Experimental" over "Informational= " for this spec, while I've seen the opposite a few times (and mos= t, presumably, just don't care one way or the other). Thus, the documen= t probably should be "Informational" after all.

Bodo


Bodo

--001a1140d43478fd5a05332ed7e8-- From nobody Thu May 19 07:41: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 A0C0312B024; Thu, 19 May 2016 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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] 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 yjVaWXFxIbFn; Thu, 19 May 2016 07:41:08 -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 70144127058; Thu, 19 May 2016 07:41:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 678B6BE38; Thu, 19 May 2016 15:41:06 +0100 (IST) 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 K_zRsyfhgdZl; Thu, 19 May 2016 15:41:06 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C9BA5BE2D; Thu, 19 May 2016 15:41:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463668866; bh=L6xVRHl9boRPZPDDpzZg08GUUMXnzq2RRjawLCXjrYk=; h=To:From:Subject:Date:From; b=RtZ4AT+p+06LhPYhvfWTDKYG7zxzTpSy3k8s+gy+Dk1G1kol/+K62Vu6j0Ainsear XP2PjfgkAozqEb/x8XXgJ8GypYIgBf65ufylKoc1OsliM2/IKKLM1yPeXbS4e77a3g HT1+47NIb3TpfwaxeeyzlQ1Pnp60MyiAR1lSSIm4= To: IESG , tls chair , "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573DD080.6050605@cs.tcd.ie> Date: Thu, 19 May 2016 15:41:04 +0100 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; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040005000005010506070600" Archived-At: Subject: [TLS] draft-ietf-tls-falsestart rfc editor note done X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:41:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040005000005010506070600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear IESG secretariat, (bcc'd), As discussed on the telechat I've updated the intended status in the tracker, added an RFC editor note asking them to change the header and cut'n'pasted the writeup into it's proper place. So I think this one is ready for you to send the usual approval announcement on Monday. (If anyone sees a glitch there, just ping me and I'll fix stuff.) Thanks, S. --------------ms040005000005010506070600 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkx NDQxMDRaMC8GCSqGSIb3DQEJBDEiBCBLJsw+EZXv6SZ4fWozHAnUW9YqtS4fawlRW8SLzPli STBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQARJY8M1xXjOyCisEEl1TpmBdI2dX6DWV1KQ4dX1EPIFRLAY6bj9Qzv BAdBGg+T9WvdpsS3OgDUvZ4pkhEuQxACjW/cnCxytho9yaBuErGNaQGaWE/IjZaCM/w0QzE9 tvX2iCOK1S6GLLztFIXeYVPjrzrV0V3PNJbCCi8UZhfzlqi6lMlztooj+OU/5nYHHjNuccdd Cm1XJfA3F0wId51rFENJPRxX+q2qfmAMogbQe5YyoYtoXqyOrUARD9lB+z+ztvZTmzgp3MmW jIipBdxImG1yB9ye7jTQcqOcgugL/ZuXHCwYyUpIcWpQtVHIFHutKjpD+DISMbXLtP0j51lK AAAAAAAA --------------ms040005000005010506070600-- From nobody Thu May 19 10:11: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 DF69C12D5C0 for ; Thu, 19 May 2016 10:11: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 o_q6epFk0GNG for ; Thu, 19 May 2016 10:11:32 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3D512D5C1 for ; Thu, 19 May 2016 10:11:31 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 206so32295477pfu.0 for ; Thu, 19 May 2016 10:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=zDRUn57igitgGyjc7Npt/Hw0+BGSA45WK+2zJz6WXj8=; b=Iwd1HoQ/+IayEVDzjVVINb026bKNawxZhxh/hoOV98xraCxpmet4ftaHZTsvRjrT/K EFIl3hJWGva4V5zUzS4Nhe3Or8GV0J3e6IzhEMirC/N29oPoEXwtl3VQ+HDxsSdfU/RR n/stnNa8NELssxTqgyGWWxRUXeJHM4UN9XuMQ= 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 :message-id:references:to; bh=zDRUn57igitgGyjc7Npt/Hw0+BGSA45WK+2zJz6WXj8=; b=fEpkc0SJk1MPV8KhMlPe19hQHKwZoDKIGE5LvoXAMTE1vkjGWSCCsQKXdeDW6Oc1U2 RFmaTvdUZk6fejhZj89bUkeDtX9vDipogqB0D2olTlNW4+hXBFzzs2kn8tYWMxCTdG/T Q1r3+ouTL/0xWUIGi60Tt3i5wvQHwtAKgny7q2GwgFO1udpTre62/Sqm4gRgxQc0a7G0 cScSCxrGRK9u8/2XFz7YJm1zJGolA/dBq13EW+W55NW3i+QIRjMk3p2CZLt0uaqfG2qO WcXIYfQsiw+mPOho0IlE8Qfq40dxW8UPF8O7aab3oqNK0wcTRay/rjZBM81knS5kn61/ sr9Q== X-Gm-Message-State: AOPr4FUHrCsUzFPjbmg/kwxsqq8ECrXCb9ypBpQB2XDYjJ05U8+ez22KwpKpVNlxbxv0nw== X-Received: by 10.98.23.211 with SMTP id 202mr21463678pfx.122.1463677876607; Thu, 19 May 2016 10:11:16 -0700 (PDT) Received: from [192.168.1.156] ([183.88.180.192]) by smtp.gmail.com with ESMTPSA id s14sm19965375pag.7.2016.05.19.10.11.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 10:11:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3D0E040A-B7FE-40C1-98F3-EDF5E5F9E5B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> Date: Fri, 20 May 2016 00:11:12 +0700 Message-Id: <96CBAD0F-0F0A-4095-81FD-09EE804EB7F6@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:11:34 -0000 --Apple-Mail=_3D0E040A-B7FE-40C1-98F3-EDF5E5F9E5B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > The first step of our attack involves attacker controlled content. So = yes (phishing, unauthenticated HTTP, selective company DPI etc.). In our = example we use a local proxy to carry out the attack. I hope I can post = a full version of the actual paper and PoC to this thread soon. https://eprint.iacr.org/2016/475 https://github.com/nonce-disrespect/nonce-disrespect (data-sets should be indexed by scans.io in a bit) Aaron --Apple-Mail=_3D0E040A-B7FE-40C1-98F3-EDF5E5F9E5B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXPfOwAAoJEOTbZJL9ubXVbBMQALeVr2nrCvzqyKJkWgh6pXeL AV2cJSvzSa41jYJqihMJ+pD3NxV8/X7DZl+sG8BAV6Y88zgh41cTmtU2inSIINHp 50fCpwrW2yFM/IureUruyy2is1bU7SZF1ITUudv/8JRas1fMP5SSQOq/X0PKIwNM ZUs87De9Aa96LtQTOQXvGKukMqG4RI1Q1ensReBIJUJCLJm/WynNn1kTQt9HkKul HCHex7fmS7tnv2HwAd2mkCtTv5Q7l4tw/fh+VBE2LvO5S1gM8nR4M4+oqF+qTcf/ nIhKUzkkqLm3984mM8gFe5JCVxYhLG3X9LmsbvEv9x2Am37v85NOQ6M08dXyEUHb pMSWGtHLjOd2ortmipy7EtBx4f/Tn6ZyY4E/K0FbRH+v8cG4KMfM0ypS4/vISihQ pxggzWw+NgcBI62Om9m+RJbMIXBNwyiuRy38zkdTvNdl26JbzZuGPvdnlUz153Pq JrgzAWNAYzku1jXsSvC2lWOzsbx87twWyy4sob04mZuP/zO8E7bPjGO6V5qvtH4t wvjtaRmumk7ev2ENpVP7d4CTz0fExmFkgmflK/3Zs4WUtUqgmPLJb2eQM13Zpc11 XE/jp4BKyVw88NvYBLloci9rxcaoGw4Y1ZMz/xFIt81UKKUl0G4nd85j835zM5/6 Ba+UnkxPf1LziAcJp9SX =q9VS -----END PGP SIGNATURE----- --Apple-Mail=_3D0E040A-B7FE-40C1-98F3-EDF5E5F9E5B3-- From nobody Thu May 19 10:42: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 0E06F12DB3F for ; Thu, 19 May 2016 10:42:05 -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 dUoPOewwouJP for ; Thu, 19 May 2016 10:42: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 75BBF12DB45 for ; Thu, 19 May 2016 10:41:56 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id x194so85543516ywd.0 for ; Thu, 19 May 2016 10:41:56 -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=MmBrUFZ2Sjce8it4lupFJLHiGhqo0/JvLjeYicEyNlU=; b=krqNl+4P+5zavX2aLGwOyCYkhrlMpwZmpPEMk1uk85A6TSjMTQ4t92h2RHmOnGIO08 0iQhytcH1gtKOfXm4y0pztqdqrfpdj0kwA3+E/Y+x5RoZHAEE64yT4h5nilDglx5h5rF yAJ2Xwi4G0X9NQmY16AW6c6erCpn4kLKeSLTukMr0ehQvBGl7mVCyzLDv9iA7eU+aHBY 0cmqjJ2qU0CarGWUIjrEPpbCV/z4JN+keQXKb1Pmp20rVVaVoP7Hgyea0K9AxVSxKwnK +KZdDMVnQHOFAbAC0PWtZc9rMfjxal+hlCUxJt7eOXEMAKNbDiyanC9YBcY8tGuPCCm1 C2PA== 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=MmBrUFZ2Sjce8it4lupFJLHiGhqo0/JvLjeYicEyNlU=; b=BkrYpv5RRK3W86DHd9zCDfcftYCZf4N8iWM7r8I32N4tGvD5qNltRvl4dzeiWS9yCO PrqIsCsYC23j0Uww0odrA8y+6ziG+WJVJzFZB/KMks0kcwXRbJVEXdH5vPfsdxoreKbK q8pgR2aAfXkxa9v9OVi05dsYwYNpyQbENW+23PuB+csKCQK32VdM/jhvQTcryLs5DbIz Nhm1NA6uQbklzGkPLAAS1J41Q6RQZBbWMcJl8zrI4oImVikdlB9RWG+Nm+Cjg2r4AqpU s874Pu+cBx5C5+UXpXhWEC8XHOh3fOKWQ2UfpmsOMZ0Odcio0+bGdV8+f1rt/9GZ58Mq A5LA== X-Gm-Message-State: AOPr4FUYMSHpjtFH1KHTMcrxEro36XHp8S/+0m57UMVd7WStDHcwt1O9PipVEfce/J/uABSYAUmohtfBH5mlog== X-Received: by 10.37.49.193 with SMTP id x184mr7849264ybx.57.1463679715616; Thu, 19 May 2016 10:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 19 May 2016 10:41:16 -0700 (PDT) From: Eric Rescorla Date: Thu, 19 May 2016 10:41:16 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1148af1883da580533357d07 Archived-At: Subject: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:42:05 -0000 --001a1148af1883da580533357d07 Content-Type: text/plain; charset=UTF-8 PR: https://github.com/tlswg/tls13-spec/pull/454 I have uploaded a PR [technically two PRs, but one builds on the other, so easier to just read the composition] which resolves two out of the three significant remaining crypto issues (the remaining one is the long-running discussion of post-handshake keys). The following message lays out the changes, which are: - Adopt a more linear key schedule - Add a context identifier for resumption KEY SCHEDULE We had a lot of comments that the existing key schedule was too hard to understand and implement and could be simplified under the assumption that keys were available in a specific order (PSK then DH ZZ). I've been working together with Karthik, Hugo, Antoine, and others to produce something cleaner. (Note: I believe they consider this acceptable, but that doesn't mean they wouldn't have designed every piece exactly as I have.) The overall key schedule looks like this: 0 | v PSK -> HKDF-Extract | v Early Secret --> Derive-Secret(., "early traffic secret", | ClientHello) | = early_traffic_secret v (EC)DHE -> HKDF-Extract | v Handshake Secret -----> Derive-Secret(., "handshake traffic secret", | ClientHello + ServerHello) | = handshake_traffic_secret v 0 -> HKDF-Extract | v Master Secret | +---------> Derive-Secret(., "application traffic secret", | ClientHello...Server Finished) | = traffic_secret_0 | +---------> Derive-Secret(., "exporter master secret", | ClientHello...Client Finished) | = exporter_secret | +---------> Derive-Secret(., "resumption master secret", ClientHello...Client Finished) = resumption_secret Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Hash(Messages) + resumption_context, L)) Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons indicated below. If a key is missing you just use 0s. The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include handshake context and therefore can be used to derive working keys without additional context. All the working keys (both encryption keys and finished keys) are generated using HKDF-Expand-Label off of the traffic secrets. This design is motivated by the following principles: - Separate out adding entropy from adding context. - Incorporate the transcript once and then derive from there. - Have a narrow, consistent interface for generating the leaf keys so they can just start with a base key. - Derive from keys as soon as practical so that you can destroy them (thus the final call to Add-Secret, which isolates the Finished keys from the MS). An additional nice point about this design is that it easily accomodates additional keys. For instance, if we had some post-quantum key exchange method, we could easily add its key in the final Add-Secret or add an extra Add-Secret stage before HS. Similarly, if we had a long-term DH key as in OPTLSv1, it could replace the 0 in the final Add-Secret. One thing I want to call out explicitly is that we are using HKDF-Expand-Label with the output of HKDF-Expand-Label. This is cryptographically fine, but means that you need an implementation of the individual HKDF Expand/Extract primitives. As far as I can tell, this isn't a hardship for anyone, but please speak up if it is. The advantage of this is that you remove unnecessary crypto operations. CONTEXT IDENTIFIER PR: https://github.com/tlswg/tls13-spec/pull/454 Hugo and Karthik both independently suggested that it would be nice to have some identity/context bound into the PSK handshake. The second PR accomodates that by deriving two values from the RMS: resumption_psk = HKDF-Expand-Label(resumption_secret, "resumption psk", "", L) resumption_context = HKDF-Expand-Label(resumption_secret, "resumption context", "", L) The resumption_psk is then used as the PSK for resumption and the resumption_context is added to the hash of the handshake messages whenever you use them, currently just by appending to the hash, as in: Hash(handshake messages) +resumption_context This is used *both* to derive the keys and for the input to the CertificateVerify/Finished. For convenience, I've Note: the reason for separately deriving RMS and then computing the context and PSK from RMS is to allow the server to just store RMS in the ticket. If we used MS the server would need to store MS in the ticket and then compromise of the ticket key would threaten the original handshake. One nit question, would it be better to hash twice, as in: Hash(Hash(handshake messages) + resumption_context) I can't see a reason to, but maybe I've missed something. Comments welcome. In the interest of not having too many outstanding changes, I'll probably merge this tomorrow unless someone strongly objects or we find something really egregious (which is always possible because there's a lot of text here). Best, -Ekr --001a1148af1883da580533357d07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have uploaded a PR [technically two PRs, but one builds on the
other, so easier to just read the composition] which resolves two ou= t
of the three significant remaining crypto issues (the remaining= one is
the long-running discussion of post-handshake keys). The = following
message lays out the changes, which are:

=
- Adopt a more linear key schedule
- Add a context ide= ntifier for resumption


KEY SCHEDULE=
We had a lot of comments that the existing key schedule was too = hard
to understand and implement and could be simplified under th= e
assumption that keys were available in a specific order (PSK th= en DH
ZZ). I've been working together with Karthik, Hugo, Ant= oine, and
others to produce something cleaner. (Note: I believe t= hey consider
this acceptable, but that doesn't mean they woul= dn't have designed
every piece exactly as I have.)
=

The overall key schedule looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00
=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=A0v
=C2=A0 =C2=A0PSK -> =C2=A0HKDF-Extract
= =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=A0v
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Early Secret =C2=A0--> Derive-S= ecret(., "early traffic 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 ClientHello)
=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 = =3D early_traffic_secret=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0v
(EC)DHE -> HKDF-Extract
=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=A0v
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Handshake
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secret -----> Derive-Se= cret(., "handshake traffic 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 ClientHello + Serve= rHello)
=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 =3D handshake_traffic_secret
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2= =A0 0 -> HKDF-Extract
=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=A0v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 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+---------> Derive-Secret(., "application traffic = 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=A0 =C2=A0 ClientHello...Server Finished)
=
=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=A0 =C2=A0 =3D traffic_secret_0
=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=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------> Derive-Secre= t(., "exporter 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 ClientHello...Client Finis= hed)
=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 =3D exporter_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=A0+---------> D= erive-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=A0Client= Hello...Client Finished)
=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=A0=3D resumption_secret
=C2=A0 Derive-Secret(Secret, Label, Messages) =3D
= =C2=A0 =C2=A0 =C2=A0 =C2=A0HKDF-Expand-Label(Secret, Label,
=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=A0Hash(Messages) + resumption_context, L))

<= div>
Derive-Secret is just a wrapper around HKDF-Expand-Label= , for reasons
indicated below. If a key is missing you just use 0= s.

The general pattern here is that the secrets sh= own down the left side
of the diagram are just raw entropy withou= t context, whereas the
secrets down the right side include handsh= ake context and therefore
can be used to derive working keys with= out additional context.=C2=A0 All
the working keys (both encrypti= on keys and finished keys) are
generated using HKDF-Expand-Label = off of the traffic secrets.

This design is motivat= ed by the following principles:

- Separate out add= ing entropy from adding context.
- Incorporate the transcript onc= e and then derive from there.
- Have a narrow, consistent interfa= ce for generating the leaf keys
=C2=A0 so they can just start wit= h a base key.
- Derive from keys as soon as practical so that you= can destroy them
=C2=A0 (thus the final call to Add-Secret, whic= h isolates the
=C2=A0 Finished keys from the MS).

<= /div>
An additional nice point about this design is that it easily
accomodates additional keys. For instance, if we had some post-quantu= m
key exchange method, we could easily add its key in the final
Add-Secret or add an extra Add-Secret stage before HS. Similarly, = if
we had a long-term DH key as in OPTLSv1, it could replace the = 0 in the
final Add-Secret.

One thing I w= ant to call out explicitly is that we are using
HKDF-Expand-Label= with the output of HKDF-Expand-Label. This is
cryptographically = fine, but means that you need an implementation of
the individual= HKDF Expand/Extract primitives. As far as I can tell,
this isn&#= 39;t a hardship for anyone, but please speak up if it is. The
adv= antage of this is that you remove unnecessary crypto operations.
=

CONTEXT IDENTIFIER

Hugo and Karthik both independe= ntly suggested that it would be nice to
have some identity/contex= t bound into the PSK handshake. The second PR
accomodates that by= deriving two values from the RMS:

=C2=A0 =C2=A0re= sumption_psk =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 =C2=A0 =C2=A0 =C2=A0 "resumption psk"= , "", L)

=C2=A0 =C2=A0resumption_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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "resumption conte= xt", "", L)

The resumption_psk is t= hen used as the PSK for resumption and the
resumption_context is = added to the hash of the handshake messages
whenever you use them= , currently just by appending to the hash, as in:

= =C2=A0 =C2=A0Hash(handshake messages) +resumption_context

This is used *both* to derive the keys and for the input to
the CertificateVerify/Finished. For convenience, I've=C2=A0


Note: the reason for separately deriving RM= S and then computing the
context and PSK from RMS is to allow the= server to just store RMS in
the ticket. If we used MS the server= would need to store MS in the
ticket and then compromise of the = ticket key would threaten the
original handshake.

<= /div>
One nit question, would it be better to hash twice, as in:
<= div>
=C2=A0 Hash(Hash(handshake messages) + resumption_contex= t)

I can't see a reason to, but maybe I've= missed something.

Comments welcome. In the intere= st of not having too many outstanding
changes, I'll probably = merge this tomorrow unless someone strongly
objects or we find so= mething really egregious (which is always possible
because there&= #39;s a lot of text here).
=C2=A0=C2=A0
Best,
-Ekr











=C2=A0=C2=A0









--001a1148af1883da580533357d07-- From nobody Thu May 19 11:26: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 1821D12DC5C for ; Thu, 19 May 2016 11:24:45 -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=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 6odDFzGYIFnG for ; Thu, 19 May 2016 11:23:57 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8967B12DB89 for ; Thu, 19 May 2016 11:19:49 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id y126so17758816qke.1 for ; Thu, 19 May 2016 11:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:date:message-id:subject:from:to; bh=4Mqt3jZOcFEsVkRwxClydDqdOiH1TVpYoaqaJ6QlRlM=; b=XyGpfeKBdhaqReXac+qm/1Nbd3Jwq/OW/Jb8Sc1eYfh9UaBBnfwfiiBFZA+sUq2Jhm rOG0Bw40if3UeNz6alSIkJXNTTLqZXFvRif2a6GI5OE1JQOF2IExbyOmo4HDc+Wj3dB6 7d32EKekHExjZW2B9yPlTGmNGHJ2nccNPm6JM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=4Mqt3jZOcFEsVkRwxClydDqdOiH1TVpYoaqaJ6QlRlM=; b=D6Wb+uVQIx672U94bDe/VcRpzyqUWh4kTH21vumiBJ8A6HAugfeKLlklFFiQuDJFY5 WIJ/ReqWfU75zQnIMnKwJWV8mUSpChkGBiZe5+rzQam/sE7DFJYezHgUuSxMOvoskUTR l0q7ipoqeAPot3LId2IgFf3ex/kIbnNU4jDR59CNV+B2CHW7WZlqvCs7J0JQf4Of6Xuc EHvKbPK5XueoL/AmFAUXfb/qDp9H+6fuD4hz/73Rv7fKQUQ8zRMNBG8ltyx420Vyogu6 ITHVdSDkc+k8SqOvz8mgFLAjUhwgPEokBTXk1ZRP3gnypqI0EXC2TV557MCM9T7uTGz9 7mPQ== X-Gm-Message-State: AOPr4FXkiGxEtilRVGA+S1JqHW01Z7FqhDUOuyjckQnwrptgRQFpp7wRiewKIupMRSAoNzDB3hMBU4c8FCc+/g== MIME-Version: 1.0 X-Received: by 10.200.52.171 with SMTP id w40mr104548qtb.31.1463681988479; Thu, 19 May 2016 11:19:48 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 11:19:48 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef] Date: Thu, 19 May 2016 14:19:48 -0400 Message-ID: From: Kyle Rose To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 18:25:39 -0000 Regarding the ability for passive observers' tracking of clients across connections (and potentially across IPs) via a session ticket used more than once, should there be any language around recommended practice here, especially for clients? An appropriately-configured server can help the client avoid this problem without performance penalty by issuing a new session ticket on every connection (for non-overlapping handshakes) and/or multiple on one (to cover that gap), and a client can help by keeping only the most recent ticket for a particular session and/or using a given ticket only once. Thoughts on adding language under "Implementation Notes" such as: "Clients concerned with privacy against tracking by passive observers SHOULD use a PSK/session ticket at most once. Servers SHOULD issue more than one session ticket per handshake, or issue a new session ticket on every resumption handshake, to assist in the privacy of the client while maintaining the performance advantage of session resumption." For pure PSK I assume tracking is less of an issue, but I'm happy to entertain thoughts there, as well. Kyle From nobody Thu May 19 11:36: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 549AD12DC07 for ; Thu, 19 May 2016 11:35: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 QTzLxllVkG-s for ; Thu, 19 May 2016 11:35:45 -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 A636312DBA0 for ; Thu, 19 May 2016 11:32:33 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x194so86966355ywd.0 for ; Thu, 19 May 2016 11:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VC93bRNMz9iD5RkPPCKtgodi+SPOlVl1IPgAMJqAlwo=; b=CjH92ONoL79Eq8WT2Jeg4ijlxHpTI+eBSDlhav29xO8Iw3TcrzkRXq9/WtMwCisXlM JGqhVmuq7Huo+p0XA2sYzeKzYqXI7mH8iaH4ujyXYYWzmzD8rRB7FiltrhQSvNgealQv zvRO9Eo9R7eLS8Ob7g1+yDeS8wzVMf+qgNOBx1918eBM+gXOSr5dSqyzQ8OBrtasLZPV jK1wtujj/HwfxAcgEV6iK8ttfJWQL7HCkKQ9sJbABHs/VWPwSj0ZW82TQS1P2ozc9d43 ih9gR0qwut20t9uLaiSnGe72T/dkCaW7beiVHACHslNUC5sP5oy6fvf89O34Gg5i37eC k/rg== 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=VC93bRNMz9iD5RkPPCKtgodi+SPOlVl1IPgAMJqAlwo=; b=ZbmhwTBIdymjxVHEP5tlM6Ct1THc+QbbAdQyMPZAoRbzvJ0+T558Yi9fCMU1D2BhXa qZkUq8sPCZeKtAY5/pNGyh/LYpADdQzY/34qRO6bJD7pVNsADPnC4t3V61CTTD/7rzwQ HnQX7dOxM3NqTi2lb7S4HFSQuWpSn/rzpP9ZIn0WyngymJOQ2VE6gQ/ou/MxRFF1rI3a DOL45Yq/Nn1dxFQkQwbMmUS6ggjmsCPQmWRuuAFK9VNGY4QUdTpa9QpEvsIOA5NIJ+ur rT4BTOhbCpWEOAmonMeZ7svRgr/u9N4buFvSWWK+gv7NENq1QLuFB2HX6XkcDGXVKK4B QtVA== X-Gm-Message-State: AOPr4FVMqGLMa29IQEZScJKBFw5fZCz6Tfgku202WJR1RNeFhDvpMJgqi1gCXPJKBUZI5PjVfnTq/v1d9PCdTw== X-Received: by 10.37.208.16 with SMTP id h16mr782598ybg.82.1463682752931; Thu, 19 May 2016 11:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 19 May 2016 11:31:53 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 19 May 2016 11:31:53 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c0553ee8d9a0005333632f2 Archived-At: Cc: "" Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 18:35:55 -0000 --94eb2c0553ee8d9a0005333632f2 Content-Type: text/plain; charset=UTF-8 Yes, I think this would be good text. PR wanted :) -Ekr On Thu, May 19, 2016 at 11:19 AM, Kyle Rose wrote: > Regarding the ability for passive observers' tracking of clients > across connections (and potentially across IPs) via a session ticket > used more than once, should there be any language around recommended > practice here, especially for clients? > > An appropriately-configured server can help the client avoid this > problem without performance penalty by issuing a new session ticket on > every connection (for non-overlapping handshakes) and/or multiple on > one (to cover that gap), and a client can help by keeping only the > most recent ticket for a particular session and/or using a given > ticket only once. > > Thoughts on adding language under "Implementation Notes" such as: > > "Clients concerned with privacy against tracking by passive observers > SHOULD use a PSK/session ticket at most once. Servers SHOULD issue > more than one session ticket per handshake, or issue a new session > ticket on every resumption handshake, to assist in the privacy of the > client while maintaining the performance advantage of session > resumption." > > For pure PSK I assume tracking is less of an issue, but I'm happy to > entertain thoughts there, as well. > > Kyle > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0553ee8d9a0005333632f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think this would be good= text. PR wanted :)

-Ekr

On Thu, May 19, 2016 at 11:19 AM, Kyle Rose <krose@krose.org><= /span> wrote:
Regarding the ability for p= assive observers' tracking of clients
across connections (and potentially across IPs) via a session ticket
used more than once, should there be any language around recommended
practice here, especially for clients?

An appropriately-configured server can help the client avoid this
problem without performance penalty by issuing a new session ticket on
every connection (for non-overlapping handshakes) and/or multiple on
one (to cover that gap), and a client can help by keeping only the
most recent ticket for a particular session and/or using a given
ticket only once.

Thoughts on adding language under "Implementation Notes" such as:=

"Clients concerned with privacy against tracking by passive observers<= br> SHOULD use a PSK/session ticket at most once. Servers SHOULD issue
more than one session ticket per handshake, or issue a new session
ticket on every resumption handshake, to assist in the privacy of the
client while maintaining the performance advantage of session
resumption."

For pure PSK I assume tracking is less of an issue, but I'm happy to entertain thoughts there, as well.

Kyle

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

--94eb2c0553ee8d9a0005333632f2-- From nobody Thu May 19 12:00: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 479CE12DBD6 for ; Thu, 19 May 2016 12:00:03 -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=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 NyOBwO00G8MW for ; Thu, 19 May 2016 11:59:54 -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 DF55A12DBDE for ; Thu, 19 May 2016 11:59:52 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n63so53807357qkf.0 for ; Thu, 19 May 2016 11:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=s3E6oB33N/uplq/HBSMz/ewvbCSDHFEqLOZkPoxwpCI=; b=WMZMLlnWY3v1DK30XjuGVjNIkeC+ZO1jeRuymA0RYPS7/qXe+vpsSGJ8a1HjgjE75q yQauPmoqnxIkJI2mn0Xfiv6CFDq2g2zWOi5AB14uXooWxrc5ilJxMQf2oDXrlSyRFc3H h88J9hZNI5wcSG0OrBlXCQvSVBwO2I35Aorkw= 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=s3E6oB33N/uplq/HBSMz/ewvbCSDHFEqLOZkPoxwpCI=; b=gI1xfZb5IoQxsneW1Uw8eknTEeVUMSiLsX5UlWe1qpvVh7aXj2IBk+KZDyUC2z1PVl tySU/VfGpG5T5cHEUmDM4KnsnN9yZcPAfJLwrzLF2f0gT0EJucQbklHF12AUzukJN46o o42MDTkHBncghZ4n0RpJSVSFQ7uTAPZAo/jzXKBD6B+3oAaUQdfwvVouN8eMaOBHMU4w YT+mL2S1GxzjXBNwVewguakqPMschrabTENq6fUOMbivBVFVJmgSUMVenIVyd2L2d5AH pyOPA7ygbq1a+MOA6ew7PzVOU62910BrtPFLYqnF9v2isgqDOK60nT410b72fpOqqNCy vRNw== X-Gm-Message-State: AOPr4FVhMcSnMMRULrxgMAalidBZfq5UzW1XABzD33pH/0B4C8nye/a19mR+UUhIq9cS86v3bIl9KYc3tDfgTA== MIME-Version: 1.0 X-Received: by 10.200.52.171 with SMTP id w40mr123542qtb.31.1463684391866; Thu, 19 May 2016 11:59:51 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 11:59:51 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef] In-Reply-To: References: Date: Thu, 19 May 2016 14:59:51 -0400 Message-ID: From: Kyle Rose To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:00:03 -0000 https://github.com/tlswg/tls13-spec/pull/461 It could probably use some cleaning up ("PSK/session ticket"). Do we also want a sentence explaining the issue? Kyle On Thu, May 19, 2016 at 2:31 PM, Eric Rescorla wrote: > Yes, I think this would be good text. PR wanted :) > > -Ekr > > On Thu, May 19, 2016 at 11:19 AM, Kyle Rose wrote: >> >> Regarding the ability for passive observers' tracking of clients >> across connections (and potentially across IPs) via a session ticket >> used more than once, should there be any language around recommended >> practice here, especially for clients? >> >> An appropriately-configured server can help the client avoid this >> problem without performance penalty by issuing a new session ticket on >> every connection (for non-overlapping handshakes) and/or multiple on >> one (to cover that gap), and a client can help by keeping only the >> most recent ticket for a particular session and/or using a given >> ticket only once. >> >> Thoughts on adding language under "Implementation Notes" such as: >> >> "Clients concerned with privacy against tracking by passive observers >> SHOULD use a PSK/session ticket at most once. Servers SHOULD issue >> more than one session ticket per handshake, or issue a new session >> ticket on every resumption handshake, to assist in the privacy of the >> client while maintaining the performance advantage of session >> resumption." >> >> For pure PSK I assume tracking is less of an issue, but I'm happy to >> entertain thoughts there, as well. >> >> Kyle >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu May 19 12:05: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 5AC2312DBED for ; Thu, 19 May 2016 12:05:12 -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 XD31sq62yrof for ; Thu, 19 May 2016 12:05:10 -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 B810512DBCC for ; Thu, 19 May 2016 12:05:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A94D8284F26; Thu, 19 May 2016 19:05:08 +0000 (UTC) Date: Thu, 19 May 2016 19:05:08 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160519190508.GE3300@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] Resumption ticket/PSK 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: Thu, 19 May 2016 19:05:12 -0000 On Thu, May 19, 2016 at 11:31:53AM -0700, Eric Rescorla wrote: > Yes, I think this would be good text. PR wanted :) I think this is much too complicated. Simpler solution is for clients (browsers and the like for which tracking is an issue) to not reuse sessions when their IP address changes, and/or keep session lifetime suitably short on the client end. In addition implementing a short "idle timeout" for sessions on the client side would be quite effective. The burden of tracking counter-measures should fall squarely on the client. -- Viktor. From nobody Thu May 19 12:09: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 1EA0A12D638 for ; Thu, 19 May 2016 12:09: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=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 lWmaCQkcv-xr for ; Thu, 19 May 2016 12:09:25 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C597C12D5B8 for ; Thu, 19 May 2016 12:09:24 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id 90so48904062qgz.1 for ; Thu, 19 May 2016 12:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=BnSN2tEkMdLFoh0LDaiG6CZwOGw4t4imHxqb2ZtrIJU=; b=SSDjI5eYSxlYiDyCoRwA6hKrHugbiy/XM2kNiqAt0/7fONph0TyUPRbep+euNa9emp XLmBq4ufVBr4kwyBqVUtD4Llku68UoqEJBO91itDmyhgKZ5pJ/loamFd71+0KwUTaltl 5X2uFoJQPodvUq3jpmdiu9zsUu45Cu4XzLjMo= 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; bh=BnSN2tEkMdLFoh0LDaiG6CZwOGw4t4imHxqb2ZtrIJU=; b=YyNdo0Z2Ct9W9hlBYbUGJBtOHp0rMmXU10Su6GLaRKdy17QfZ2g1Jv+sVe827oR8u0 FIE2RfDWdHZ+NaQo5wv8ZqjclvaZERsXOk8l9kGudh0/grTNi0W7HfovptDunElGQ7Ii OdLxxtznj1yRwq0AYfInQ+XifwY5SplBljxTAjmbTuaRoeXXeXC1Kf/WcrlRHQW0T00g ww/q7nvbFbYxsRmGXNp8r7lt5wpnMwoVzMD2gnCNkWKP2wJA8Zt3RJXo6IZv3ywFPC4p zKzFO8B7B/VsqumQCtR3TUyIrppTKO4XdamZYvnJP0/5/zwuy29B2WPfPDJeN1drjjtN m7cw== X-Gm-Message-State: AOPr4FWPNxWBr0LPYPi0q3+WtNaADsMExPURiGBUWNEkWH6l+T7tb2qyZCz4aVJrh9NLe4jfLjvvZDnjPB+vLg== MIME-Version: 1.0 X-Received: by 10.140.42.78 with SMTP id b72mr15100280qga.48.1463684963880; Thu, 19 May 2016 12:09:23 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 12:09:23 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef] In-Reply-To: <20160519190508.GE3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> Date: Thu, 19 May 2016 15:09:23 -0400 Message-ID: From: Kyle Rose To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:09:26 -0000 On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni wrote: > I think this is much too complicated. Simpler solution is for > clients (browsers and the like for which tracking is an issue) to > not reuse sessions when their IP address changes I don't think this is sufficient. Reusing session tickets will reveal distinguishing information about individual clients behind NAT exit points, for instance, even when their internal/RFC1918 addresses don't change. > The burden of tracking counter-measures should fall squarely on > the client. I agree that it's up to the client, but there are measures the server can take to assist the client while not adding to its full handshake burden. IOW, it helps the server, as well. Kyle From nobody Thu May 19 12:12: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 7DB4712D62D for ; Thu, 19 May 2016 12:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, 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 8TDW42nLH8mp for ; Thu, 19 May 2016 12:11:57 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5170F12DAFD for ; Thu, 19 May 2016 12:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3CF1DF923; Thu, 19 May 2016 22:11:56 +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 VeMEbA50A9K4; Thu, 19 May 2016 22:11:55 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D85AA2310; Thu, 19 May 2016 22:11:55 +0300 (EEST) Date: Thu, 19 May 2016 22:11:53 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160519191152.GA4667@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] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:11:59 -0000 On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > An additional nice point about this design is that it easily > accomodates additional keys. For instance, if we had some post-quantum > key exchange method, we could easily add its key in the final > Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the > final Add-Secret. Just one thing to be careful of: If one has off-handshake counter- keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash those in, or one gets all kinds of crypto screw (which may or may not be actually exploitable...) The "context identifier" looks real handy for that purpose... > CONTEXT IDENTIFIER > > The resumption_psk is then used as the PSK for resumption and the > resumption_context is added to the hash of the handshake messages > whenever you use them, currently just by appending to the hash, as in: > > Hash(handshake messages) +resumption_context > > This is used *both* to derive the keys and for the input to > the CertificateVerify/Finished. For convenience, I've Oh, even better than the original "contexts" proposal, as this is non-checked. As said, if you ever need off-handshake counterkeys (as above, and you most probably do for adding any sort of realistic post-quantum capabilities[2]), this looks real handy for mixing those in. [1] Any server-side key that isn't explicitly sent as part of the hand- shake (most probably having been sent before in prior handshake) but still is involved in the handshake. [2] There does exist PQ Key Agreement, but it currently just provoded by one system that is relatively slow (through not completely impractical) and severly underanalyzed (major problem). -Ilari From nobody Thu May 19 12:14: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 530AF12D62D for ; Thu, 19 May 2016 12:14:29 -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 6vIk0GxaxlEF for ; Thu, 19 May 2016 12:14:28 -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 C6D2512DBC4 for ; Thu, 19 May 2016 12:14:25 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g133so88150197ywb.2 for ; Thu, 19 May 2016 12:14:25 -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=Xa8Wk4NbVFs/cVQ9N8fDUK73+BypT4yjiU8ZdHQDFoU=; b=mxKIayr15XzOjg3R87+ay5wFF8LPGGlKaRmnUeRqLXDqL4O/WSrtNoUtpx2uslI7VA 75gAKgn2nR5W7uX9x06s8U7BNjwnfVX3RjigbvIqP4mkcja5YFcPJkTlmLPr8beoAzG4 rhI7eKlzofrEHbWLM8Z9KgSDaKHBkXiU1nJ6U3KItR2+7NPWZt0cEvafa3qpunULFHmN sUz+qHce9DoTLKUlmV5WFUjDVzZHnFEh0qfTb94bZwN9jr+6gD5qFZsVSir9Wd6H6FwF K+1QmnIuCPimB+D+9CwJ8aATriKYaHtX2Q/tayC8AUdbGlpCvsdi5vOb2GrmiaRtImLA svyw== 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=Xa8Wk4NbVFs/cVQ9N8fDUK73+BypT4yjiU8ZdHQDFoU=; b=AFCRB6lnSFby+WMVV0gf+ZIyNKZbOg2qa/+//C4g5pk/Yl7BAIGeH/pJQe+byja03R IdFnVl8KEzC0Og9uzLKBcuNeIZc7BN9hj0FrJmaebZPpWfs+/loNiuHjuYj2JM46H/Xp LCJk0A7vaObNJLZdvJHIuxROpBJFmB71r7A0GUWPE8zECjoy1I0QVtnM2NtcsnQlSrJo 1mzQj4Y6+nSTmp3/+2+mVBQfbBOJccm/Bpe0Up+nBnIkRLb5O4Ig+o1YHp0zCOY7r16D vJIudct8RDf1DM1kaKCSMp7q12cH4EC8vs7WrmnmEjUCFdmpa6oJ2kB5gBoa22eLHQy0 77Kw== X-Gm-Message-State: AOPr4FV3bdTsn6cryafTamNtT5MXNMa91xrx6npXf3p7J6Yi4NRJ1JFCeDgm7T/MEpq92ikti8a5nantETeKFw== X-Received: by 10.13.233.1 with SMTP id s1mr8205976ywe.286.1463685264999; Thu, 19 May 2016 12:14:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 19 May 2016 12:13:45 -0700 (PDT) In-Reply-To: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 19 May 2016 12:13:45 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07cfb448bc4b053336c81d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:14:29 -0000 --94eb2c07cfb448bc4b053336c81d Content-Type: text/plain; charset=UTF-8 On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara wrote: > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > > > An additional nice point about this design is that it easily > > accomodates additional keys. For instance, if we had some post-quantum > > key exchange method, we could easily add its key in the final > > Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the > > final Add-Secret. > > Just one thing to be careful of: If one has off-handshake counter- > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash > those in, or one gets all kinds of crypto screw (which may or may not > be actually exploitable...) > > The "context identifier" looks real handy for that purpose.. Yep. We were thinking that too! Thanks for the quick look. -Ekr > > > CONTEXT IDENTIFIER > > > > The resumption_psk is then used as the PSK for resumption and the > > resumption_context is added to the hash of the handshake messages > > whenever you use them, currently just by appending to the hash, as in: > > > > Hash(handshake messages) +resumption_context > > > > This is used *both* to derive the keys and for the input to > > the CertificateVerify/Finished. For convenience, I've > > Oh, even better than the original "contexts" proposal, as this is > non-checked. As said, if you ever need off-handshake counterkeys > (as above, and you most probably do for adding any sort of realistic > post-quantum capabilities[2]), this looks real handy for mixing those > in. > > > [1] Any server-side key that isn't explicitly sent as part of the hand- > shake (most probably having been sent before in prior handshake) but > still is involved in the handshake. > > [2] There does exist PQ Key Agreement, but it currently just provoded by > one system that is relatively slow (through not completely impractical) > and severly underanalyzed (major problem). > > > -Ilari > --94eb2c07cfb448bc4b053336c81d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: >
> An additional nice point about this design is that it easily
> accomodates additional keys. For instance, if we had some post-quantum=
> key exchange method, we could easily add its key in the final
> Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the=
> final Add-Secret.

Just one thing to be careful of: If one has off-handshake counter- keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash
those in, or one gets all kinds of crypto screw (which may or may not
be actually exploitable...)

The "context identifier" looks real handy for that purpose..

Yep. We were thinking that too!

<= /div>

Thanks for the quick look.

-Ekr
=C2=A0
=C2=A0
> CONTEXT IDENTIFIER
>
> The resumption_psk is then used as the PSK for resumption and the
> resumption_context is added to the hash of the handshake messages
> whenever you use them, currently just by appending to the hash, as in:=
>
>=C2=A0 =C2=A0 Hash(handshake messages) +resumption_context
>
> This is used *both* to derive the keys and for the input to
> the CertificateVerify/Finished. For convenience, I've

Oh, even better than the original "contexts" proposal, as = this is
non-checked. As said, if you ever need off-handshake counterkeys
(as above, and you most probably do for adding any sort of realistic
post-quantum capabilities[2]), this looks real handy for mixing those
in.


[1] Any server-side key that isn't explicitly sent as part of the hand-=
shake (most probably having been sent before in prior handshake) but
still is involved in the handshake.

[2] There does exist PQ Key Agreement, but it currently just provoded by one system that is relatively slow (through not completely impractical)
and severly underanalyzed (major problem).


-Ilari

--94eb2c07cfb448bc4b053336c81d-- From nobody Thu May 19 12:19: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 881B012DBD1 for ; Thu, 19 May 2016 12:19:33 -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 QX15pGt98yTf for ; Thu, 19 May 2016 12:19:32 -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 3F0FB12D639 for ; Thu, 19 May 2016 12:19:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2B8A5284F26; Thu, 19 May 2016 19:19:31 +0000 (UTC) Date: Thu, 19 May 2016 19:19:31 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160519191930.GF3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Resumption ticket/PSK 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: Thu, 19 May 2016 19:19:33 -0000 On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote: > On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni wrote: > > > I think this is much too complicated. Simpler solution is for > > clients (browsers and the like for which tracking is an issue) to > > not reuse sessions when their IP address changes > > I don't think this is sufficient. Reusing session tickets will reveal > distinguishing information about individual clients behind NAT exit > points, for instance, even when their internal/RFC1918 addresses don't > change. It is good enough. Clients that want strong protection against tracking by session ids can disable session caching entirely, or set an idle timeout of ~5 seconds, Ensuring that session re-use happens only for a quick burst of connections to the same server. This is only relevant to a particular type of client, and should not be default protocol behaviour. > > The burden of tracking counter-measures should fall squarely on > > the client. > > I agree that it's up to the client, but there are measures the server > can take to assist the client while not adding to its full handshake > burden. IOW, it helps the server, as well. I don't see how constantly generating and transmitting new tickets helps the server, or helps clients (at fixed network addresses) that don't need this protection. Just a waste of bandwidth and needless churn in the client's session cache. There are clients where limiting ticket re-use makes sense, these clients can take appropriate measures. If some clients desperately want a fresh ticket with every resumption, I think they should explicitly signal that via an optional new extension. I'd have no objection to a zero-length payload extension that indicates that a fresh ticket is desired even if the session is resumed. -- Viktor. From nobody Thu May 19 12:23: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 84C5112DBF5 for ; Thu, 19 May 2016 12:23:00 -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 AYx-ucWhMkm2 for ; Thu, 19 May 2016 12:22:58 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1F712DBEC for ; Thu, 19 May 2016 12:22:58 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id s8so49942925ign.0 for ; Thu, 19 May 2016 12:22:58 -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=WynOd7vX1JIJulQq8HQYICSmMvfaK6ybXK4XLONDtco=; b=n+drDRqoaKYzTu8UOe8iaLbsDm5ko1xgE2rR9hWfc3f7Xs83tarEGmYA0qk8IX4gtd 1OV69SHk3WUlxZ1urj5AgDDSiAo9zwf649170/wJQcEETFdFe/jasscJoHy53Kpr6mj/ d+gvUJdq5r42oLAs7+u4enWl8ZE/9jlRnHfKI= 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=WynOd7vX1JIJulQq8HQYICSmMvfaK6ybXK4XLONDtco=; b=Ya06tHpIi8UEW3jZ51rS0gMzSzOWjLXbS5DnrZN9uFqQFlWmqoOhemwyCXcycc74Tt 2AlwIMbkIM8ntsTsgMsdg6XD3mvRB290cVhVvBf9sKIlwO/bQ1MRF6xEbBjZ5tza1frv a6dD8B+NdXlbfrw4x8Udy7wo6iZ40Ab0+ThqF+HjaHPTxLgm/ctp0dAhV+S2bw0QwtTH Fj6IMaRmkPBIv8Tqtozf4KCBERXPGXdTi1CrDWAk8XPxiysFnPNEKLFDcpIRiliGhC5e 3aJk4wfksVUUNz0UcaULiY584M8JkqmBDrKY6hlsKnmFCRrdJXjaE2Ak18b8cAT9BODF Y3mA== X-Gm-Message-State: AOPr4FWRARLGSJRf4Ia/SUzBArtMTqNwZSC6tkCOBprMlBuQ6tXAY+56Jl6lQz9ctvrA2PzI+7gLd+BVUSsFoI3K X-Received: by 10.50.170.40 with SMTP id aj8mr4377448igc.83.1463685777772; Thu, 19 May 2016 12:22:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 19 May 2016 19:22:47 +0000 Message-ID: To: Russ Housley , Maarten Bodewes Content-Type: multipart/alternative; boundary=e89a8f23440bd93cdd053336e622 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:23:00 -0000 --e89a8f23440bd93cdd053336e622 Content-Type: text/plain; charset=UTF-8 If the WG agrees with this change, I've put together a PR here: https://github.com/tlswg/tls13-spec/pull/462 On Tue, May 17, 2016 at 4:14 PM David Benjamin wrote: > Reviving this thread, I also think it would also be a good idea if 1.3 did > not stripping zeros from Z. Having this logic is rather dubious w.r.t. > treating secret data in constant-time. And as Bill Cox mentioned > elsewhere in this thread, this odd behavior has caused interoperability > issues in the past. > > I don't think we have to be worried about inconsistency with 1.2 as, by > the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE > is already a very different beast from TLS 1.2 DHE. At this point, the only > thing they meaningfully share is they happen to use the same code points. > > David > > On Thu, Apr 7, 2016 at 10:37 AM Russ Housley wrote: > >> I would prefer to always use the full, known-length byte string for Z. >> In my experience, it is better to know the lengths of byte strings instead >> of stripping leading zeroes. The difference in the speed of the HKDF >> computation by omitting the leading zeros is not significant. Alignment >> with NIST SP 800-56A is nice, but it is not the reason for my preference. >> >> Russ >> >> >> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes >> wrote: >> >> > Hi all, >> > >> > I see that the leading zero is stripped off of the value of Z (the >> shared secret) before it is used as input to HKDF. This seems to be >> compatible with TLS 1.2. Then again, it is not compatible with e.g. >> NISP800-56A which uses the value of Z with the same size of the prime in >> octets. Furthermore, it is also different with regards to handling the >> coordinate X as used in ECDH. >> > >> > Was this a conscious decision to keep compatibility with TLS? Has the >> use of the value of Z including zero octets been considered? >> > >> > Regards, >> > Maarten >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --e89a8f23440bd93cdd053336e622 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the WG agrees with this change, I've put together a= PR here:
https= ://github.com/tlswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin <davidben@chromium.org> wrote:
Reviving this threa= d, I also think it would also be a good idea if 1.3 did not stripping zeros= from Z. Having this logic is rather dubious w.r.t. treating secret data in= constant-time.=C2=A0And as Bill Cox mentio= ned elsewhere in this thread, this odd behavior has caused interoperability= issues in the past.

I don't think we have to= be worried about inconsistency with 1.2 as, by the time this happens, we w= ill already know we're speaking 1.3. TLS 1.3 DHE is already a very diff= erent beast from TLS 1.2 DHE. At this point, the only thing they meaningful= ly share is they happen to use the same code points.

Davi= d

On Thu, Apr 7, 2016 a= t 10:37 AM Russ Housley <housley@vigilsec.com> wrote:
I would prefer to always use the full, known-length byte stri= ng for Z.=C2=A0 In my experience, it is better to know the lengths of byte = strings instead of stripping leading zeroes.=C2=A0 The difference in the sp= eed of the HKDF computation by omitting the leading zeros is not significan= t.=C2=A0 Alignment with NIST SP 800-56A is nice, but it is not the reason f= or my preference.

Russ


On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com> wro= te:

> Hi all,
>
> I see that the leading zero is stripped off of the value of Z (the sha= red secret) before it is used as input to HKDF. This seems to be compatible= with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which= uses the value of Z with the same size of the prime in octets. Furthermore= , it is also different with regards to handling the coordinate X as used in= ECDH.
>
> Was this a conscious decision to keep compatibility with TLS? Has the = use of the value of Z including zero octets been considered?
>
> Regards,
> Maarten

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--e89a8f23440bd93cdd053336e622-- From nobody Thu May 19 12: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 0654112D63D for ; Thu, 19 May 2016 12:35:25 -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 yZ06LFEWPLUz for ; Thu, 19 May 2016 12:35:23 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id D40B912D182 for ; Thu, 19 May 2016 12:35:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 23E12A6BD; Thu, 19 May 2016 22:35:21 +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 KrmZXJ4V-5nd; Thu, 19 May 2016 22:35:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id CE5072310; Thu, 19 May 2016 22:35:20 +0300 (EEST) Date: Thu, 19 May 2016 22:35:18 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160519193518.GA4755@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160519191152.GA4667@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] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:35:25 -0000 On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote: > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara > wrote: > > > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > > > Just one thing to be careful of: If one has off-handshake counter- > > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash > > those in, or one gets all kinds of crypto screw (which may or may not > > be actually exploitable...) > > > > The "context identifier" looks real handy for that purpose.. > > > Yep. We were thinking that too! > > > Thanks for the quick look. In very quick'n'dirty security analysis the other thing I noticed was that if server handshake needs something to be nonce w.r.t. "SS", (e.g. happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts anyway, even with just "SS" being PSK. -Ilari From nobody Thu May 19 12:40: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 7EBB912D65F for ; Thu, 19 May 2016 12:40:13 -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 ihv4fHz-hbla for ; Thu, 19 May 2016 12:40:11 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4001012DC0A for ; Thu, 19 May 2016 12:40:11 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B9B94F24035; Thu, 19 May 2016 15:40:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 8VnmWyQmFw2Z; Thu, 19 May 2016 15:22:50 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id E55C4F2402A; Thu, 19 May 2016 15:40:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FA6D59C-E20E-44D6-8ABC-D3648037081A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 19 May 2016 15:40:07 -0400 Message-Id: <0FCFE9D6-7396-4BBF-B161-E1ACC36E18CD@vigilsec.com> References: To: David Benjamin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:40:13 -0000 --Apple-Mail=_0FA6D59C-E20E-44D6-8ABC-D3648037081A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for doing the text. Russ On May 19, 2016, at 3:22 PM, David Benjamin = wrote: > If the WG agrees with this change, I've put together a PR here: > https://github.com/tlswg/tls13-spec/pull/462 >=20 > On Tue, May 17, 2016 at 4:14 PM David Benjamin = wrote: > Reviving this thread, I also think it would also be a good idea if 1.3 = did not stripping zeros from Z. Having this logic is rather dubious = w.r.t. treating secret data in constant-time. And as Bill Cox mentioned = elsewhere in this thread, this odd behavior has caused interoperability = issues in the past. >=20 > I don't think we have to be worried about inconsistency with 1.2 as, = by the time this happens, we will already know we're speaking 1.3. TLS = 1.3 DHE is already a very different beast from TLS 1.2 DHE. At this = point, the only thing they meaningfully share is they happen to use the = same code points. >=20 > David >=20 > On Thu, Apr 7, 2016 at 10:37 AM Russ Housley = wrote: > I would prefer to always use the full, known-length byte string for Z. = In my experience, it is better to know the lengths of byte strings = instead of stripping leading zeroes. The difference in the speed of the = HKDF computation by omitting the leading zeros is not significant. = Alignment with NIST SP 800-56A is nice, but it is not the reason for my = preference. >=20 > Russ >=20 >=20 > On Mar 28, 2016, at 11:56 AM, Maarten Bodewes = wrote: >=20 > > Hi all, > > > > I see that the leading zero is stripped off of the value of Z (the = shared secret) before it is used as input to HKDF. This seems to be = compatible with TLS 1.2. Then again, it is not compatible with e.g. = NISP800-56A which uses the value of Z with the same size of the prime in = octets. Furthermore, it is also different with regards to handling the = coordinate X as used in ECDH. > > > > Was this a conscious decision to keep compatibility with TLS? Has = the use of the value of Z including zero octets been considered? > > > > Regards, > > Maarten >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_0FA6D59C-E20E-44D6-8ABC-D3648037081A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks = for doing the = text.

Russ


On = May 19, 2016, at 3:22 PM, David Benjamin <davidben@chromium.org> = wrote:

If the WG agrees with this change, I've = put together a PR here:
https://github.com/t= lswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin <davidben@chromium.org> = wrote:
Reviving this thread, I also think it would also be a good = idea if 1.3 did not stripping zeros from Z. Having this logic is rather = dubious w.r.t. treating secret data in constant-time. And as Bill Cox mentioned elsewhere in this = thread, this odd behavior has caused interoperability issues in the = past.

I don't think we have to be worried = about inconsistency with 1.2 as, by the time this happens, we will = already know we're speaking 1.3. TLS 1.3 DHE is already a very different = beast from TLS 1.2 DHE. At this point, the only thing they meaningfully = share is they happen to use the same code points.

David

On Thu, Apr = 7, 2016 at 10:37 AM Russ Housley <housley@vigilsec.com> = wrote:
I would prefer to = always use the full, known-length byte string for Z.  In my = experience, it is better to know the lengths of byte strings instead of = stripping leading zeroes.  The difference in the speed of the HKDF = computation by omitting the leading zeros is not significant.  = Alignment with NIST SP 800-56A is nice, but it is not the reason for my = preference.

Russ


On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com> wrote:

> Hi all,
>
> I see that the leading zero is stripped off of the value of Z (the = shared secret) before it is used as input to HKDF. This seems to be = compatible with TLS 1.2. Then again, it is not compatible with e.g. = NISP800-56A which uses the value of Z with the same size of the prime in = octets. Furthermore, it is also different with regards to handling the = coordinate X as used in ECDH.
>
> Was this a conscious decision to keep compatibility with TLS? Has = the use of the value of Z including zero octets been considered?
>
> Regards,
> Maarten

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

= --Apple-Mail=_0FA6D59C-E20E-44D6-8ABC-D3648037081A-- From nobody Thu May 19 12:45: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 D452012D633 for ; Thu, 19 May 2016 12:45:31 -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=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 3rIFBROvawuK for ; Thu, 19 May 2016 12:45:28 -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 D26C612D63B for ; Thu, 19 May 2016 12:45:27 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y126so19263761qke.1 for ; Thu, 19 May 2016 12:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=1tpX43rNkJEhLjFSzGHIwJ12/gmXZtf6i/EUbhb8gKM=; b=R2yA2c0LtwnQWvnxFtMS+NJUCIwl5yid9IjHXiOhv1gQTrZcTROXzykBYJy4INKEHN Vogix13jEbbv9/J5eayl2NO76sIP0kR8A6Y+d2CxRA9sh8wX5HjSh2vLqBKk/oRLBzUh dQzBnjwfnZHGpeF+ToPtxjSjszykImvTjD5E0= 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; bh=1tpX43rNkJEhLjFSzGHIwJ12/gmXZtf6i/EUbhb8gKM=; b=ZyfMsw7Gnv+lWElt2KOrrVY+NAjigENRvIGsCpLXrQfCKWAS6JPo2MPjemQ44oDgG4 gJkcnS5YmIABRUP240mioHLj6zX6JJYobwQrsLw6FjFcrwoTbu8uA+je7xfKcNKZQQR9 89+YIrcyU7T9+I3rbUBSGcol56MZ1xK4SHSxstSgR/Blef2/okHjWKsME4jRZZ1B4EfN wJMlh/i2/SMmoyqI/fejPTvzChClXV2g8/ocTz0VJpOyCIQqdO9Cwtw+yJrYjh/WX1N3 mMiB53y4jVboHGbr9zrtwN4qwdZm67nozcoOW7RIJ2YtZst6TF9AV2Uei7kdz3HIpBQW /+VQ== X-Gm-Message-State: AOPr4FW2HQQcQufS6mC3jTnSWU9viWvS/CHmBTKsRxD6Tj8pIAWh7chVPvOjqqLgghVhlz90RBLoVoQS4NaYmQ== MIME-Version: 1.0 X-Received: by 10.55.76.84 with SMTP id z81mr16598184qka.17.1463687126832; Thu, 19 May 2016 12:45:26 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 12:45:26 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef] In-Reply-To: <20160519191930.GF3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> <20160519191930.GF3300@mournblade.imrryr.org> Date: Thu, 19 May 2016 15:45:26 -0400 Message-ID: From: Kyle Rose To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:45:32 -0000 On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni wrote: > It is good enough. Clients that want strong protection against > tracking by session ids can disable session caching entirely, or > set an idle timeout of ~5 seconds, Ensuring that session re-use > happens only for a quick burst of connections to the same server. > > This is only relevant to a particular type of client, and should > not be default protocol behaviour. I suspect the root of arguments for/against this proposal are philosophical more than technical. I disagree with your contention above that client-behavior-only is sufficient, because my definition of "sufficient" includes something about resource usage on the server in pursuit of the privacy desires of the client, which you implicitly admit to below: > If some clients desperately want a fresh ticket with every resumption, > I think they should explicitly signal that via an optional new > extension. I'd have no objection to a zero-length payload extension > that indicates that a fresh ticket is desired even if the session > is resumed. This IMO *would* be good enough from a technical standpoint. I can't give you a technical argument for my proposal, because the question fundamentally isn't a technical one: it's a philosophical one regarding which properties we want this protocol to have by default. I can only suggest a requirement that TLS, as a privacy protocol, must at the very least not add to the ability to track clients. Reuse of session tickets violates this requirement by adding an identifier transmitted in the clear that allows a passive observer to track a client much more easily than it would otherwise be able to do. > I don't see how constantly generating and transmitting new tickets > helps the server, or helps clients (at fixed network addresses) > that don't need this protection. Just a waste of bandwidth and > needless churn in the client's session cache. I'm not sympathetic to the bandwidth argument, given how typically small these things are. I'm also not sympathetic to concerns about generation, as session ticket generation is logically limited to low-cost crypto operations (i.e., not public key crypto) that are probably not significant in comparison to the rest of the key derivation schedule: certainly, in the typical case thousands or tens of thousands can be generated for the cost of a single extra PKC operation. And nothing about this proposal suggests that a client MUST not use a session ticket more than once, only that the server offer it the opportunity to resume a session without doing so. > There are clients where limiting ticket re-use makes sense, these > clients can take appropriate measures. My goal is to make it easy for the client to do this in a way that is efficient for the server. A client can already simply turn off session caching to gain added privacy, but there are ways to tweak implementations to help resource-constrained servers, as well. Kyle From nobody Thu May 19 13:01: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 E255B12D6D3 for ; Thu, 19 May 2016 13:01:26 -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 fAIUm8RjW1Dd for ; Thu, 19 May 2016 13:01:25 -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 6CD7212D66C for ; Thu, 19 May 2016 13:01:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 69037284F26; Thu, 19 May 2016 20:01:24 +0000 (UTC) Date: Thu, 19 May 2016 20:01:24 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160519200124.GG3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> <20160519191930.GF3300@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Resumption ticket/PSK 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: Thu, 19 May 2016 20:01:27 -0000 On Thu, May 19, 2016 at 03:45:26PM -0400, Kyle Rose wrote: > > This is only relevant to a particular type of client, and should > > not be default protocol behaviour. > > I suspect the root of arguments for/against this proposal are > philosophical more than technical. I disagree with your contention > above that client-behavior-only is sufficient, because my definition > of "sufficient" includes something about resource usage on the server > in pursuit of the privacy desires of the client, which you implicitly > admit to below: Well, if a client is not behind a carrier-grade NAT, it is readily identified by its network address until it obtains a new one. So the tracking identifier is at layer 3 and TLS won't change that. Nevertheless, some clients may want to attempt to gain fine-grained protection against correlating back to back or parallel resumption requests. For this they'd have to ensure that all session tickets are single use, and either perform new handshakes when increasing the number of parallel connections to the server, or somehow obtain more than one ticket within a single session. The proposal is rather complex, and often still not effective. For this reason, I'm suggesting that the complexity should not be specified as a default behaviour. There's a lot clients can do unilaterally, and a new extension can be designed to close any gaps for clients with "greater needs". -- Viktor. From nobody Thu May 19 13:37: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 56A5E12D5CB for ; Thu, 19 May 2016 13:37: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 I0fHpYapAzSN for ; Thu, 19 May 2016 13:37:31 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BE2128B44 for ; Thu, 19 May 2016 13:37:31 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id bi2so123859452igb.0 for ; Thu, 19 May 2016 13:37:30 -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; bh=nA+O40rBKNqhH54O/gVe21eSF2mSmnvqgLq59vmq6OE=; b=mnvgL6/1vRb10a00J+yx0kBNCsdmfRjiy6cCrXzWEd87ds7JGTWa+TfMOqWIj90NAh IKIpG6/241Fl/AUkEkmg+3LWP3ECIPDQj50Hzd7TXr2Ndb+PfiNkYRkVDq2n/aWD9C21 IqspasXlA3hg00CoQXnQ2dxn8dfku0u3jhPpXnLopyM1/g2t1V+aJybMdUpo8mXM9m+p YJk3cfd7oZMD45HwW2hGToyw9YZ6aoBLOcpIAzvQxWRqVQOOZ0N+t6swoIveNWu7Aogx v57YkENpmT/Up46ZLG+JzlV1aTD8QjPSrugxKwy4DHW8k6ZveN00fYOxSoXK0rc2BLuu QjMA== 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; bh=nA+O40rBKNqhH54O/gVe21eSF2mSmnvqgLq59vmq6OE=; b=PpbrT406EKPAyGzif5TX4wBGD668TT+Swi+E2AAOeXYA+UL2NMPpbneFSk4C3JWpYa ZKCJO6d04CrKK9vYT3OzAOuwrlKqW72jguWMf7WbGXBSz1x/MjaM5uGcRa9wya4mZ3UE 9pOFqgSrBWGxDotMhzPm5aMHUNllRcZ8TAHcLwSiTth7pylROM1Kp51lficb1ukI2lHq pmfagLcKP/IEgIxylXN/hlII1e+T+xWkD29edGGoNGjiqvlN5T5faYtdOYK7fPTY+lkM /JtzkZf2WPh45obpirYqdQ0DD36+yutfOq/xDFP/WR7GB+jI7H2UV5cwacSvF8NuUtc/ 26DQ== X-Gm-Message-State: AOPr4FWK8h0uln9lmhl21W1eOhAFnasswY2izQr+7wBdGpwltJKc3cIOCn8+FzBYu6o9P4a+ZN6reQN7e81G2g== MIME-Version: 1.0 X-Received: by 10.50.122.68 with SMTP id lq4mr2207240igb.77.1463690250335; Thu, 19 May 2016 13:37:30 -0700 (PDT) Received: by 10.36.142.4 with HTTP; Thu, 19 May 2016 13:37:30 -0700 (PDT) In-Reply-To: <20160519200124.GG3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> <20160519191930.GF3300@mournblade.imrryr.org> <20160519200124.GG3300@mournblade.imrryr.org> Date: Thu, 19 May 2016 16:37:30 -0400 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 20:37:32 -0000 On 19 May 2016 at 16:01, Viktor Dukhovni wrote: > Nevertheless, some clients may want to attempt to gain fine-grained > protection against correlating back to back or parallel resumption > requests. For this they'd have to ensure that all session tickets > are single use, and either perform new handshakes when increasing > the number of parallel connections to the server, or somehow obtain > more than one ticket within a single session. I believe that this is the intent of the PR. I've suggested an alternative wording that cleaves closer to your text above. From nobody Thu May 19 13:50: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 20A1E12D688 for ; Thu, 19 May 2016 13:50:25 -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 j_xp86mXiw-i for ; Thu, 19 May 2016 13:50:23 -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 9E4E912D67C for ; Thu, 19 May 2016 13:50:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8C6A5284F26; Thu, 19 May 2016 20:50:22 +0000 (UTC) Date: Thu, 19 May 2016 20:50:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160519205022.GI3300@mournblade.imrryr.org> References: <20160519190508.GE3300@mournblade.imrryr.org> <20160519191930.GF3300@mournblade.imrryr.org> <20160519200124.GG3300@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Resumption ticket/PSK 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: Thu, 19 May 2016 20:50:25 -0000 On Thu, May 19, 2016 at 04:37:30PM -0400, Martin Thomson wrote: > On 19 May 2016 at 16:01, Viktor Dukhovni wrote: > > Nevertheless, some clients may want to attempt to gain fine-grained > > protection against correlating back to back or parallel resumption > > requests. For this they'd have to ensure that all session tickets > > are single use, and either perform new handshakes when increasing > > the number of parallel connections to the server, or somehow obtain > > more than one ticket within a single session. > > I believe that this is the intent of the PR. I've suggested an > alternative wording that cleaves closer to your text above. I'm suggesting that instead of servers guessing that clients want this, it might make more sense to employ an extension to request single-use tickets. Session tickets will often encapsulate the client certificate, and issuing them on every resumption can considerably increase the size of the server response. Many clients will not benefit, so I'm suggesting that this should be optional. I've not heard many others chime-in yet, so it is not yet clear where WG consensus may lie on this question. -- Viktor. From nobody Thu May 19 14:13: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 8F87C12B017 for ; Thu, 19 May 2016 14:13:53 -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=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 XcS0bAGzasYw for ; Thu, 19 May 2016 14:13:52 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0B5128B44 for ; Thu, 19 May 2016 14:13:51 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id 90so50803326qgz.1 for ; Thu, 19 May 2016 14:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OvNFKzue4Cy6eTVWVESI+Em8O59PC1LH5Cl6DRf9AWE=; b=dioAOSYKpaasUOQp1JOSOPbTC8Af7y4ohS8SlekJ4lQMTK7MOwXd/T8+VBxNGkGM0l UPWNGCApGnSZSk7SYK21b3MhwOtO0Tq7ZpgMgbPuB1UXLRluV2jt/8QKd9DZ3pnQg93Z JxJBSaq5klJju31LCXNwfRDQVIqVoPVsy8kAw= 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=OvNFKzue4Cy6eTVWVESI+Em8O59PC1LH5Cl6DRf9AWE=; b=YQxqqX8pe93+/8VHGOggumORMRmnKczJpMnO+MWK27sxbNONb5jpBCBkyXWx9dbZks 0Qf3CMQJjA2XeTjQ6rI+iU1aAvvUoBP36MAUgJL7GJZpn+Gk3GH7Thp1UAa9EQnkVwY5 u2ltOxEVYDTX5GsEFgYMkZN7A7xXIoIx57aqyoW+CJryBnrMieUqu2EajbBWm0POj8cl Tnsnii3roCskaooqE2VqUT1BBJqltUaF8QghW8+LVOdQ2Lbz1fDLKjXrn9CP9ak3a4B8 QVbOW3Z9cGCfhdiWHmOm3JS+8wc1QMLNft5XNczSl1sEKH8sQW8bFz1nhpiNF5hJOmI2 nIrg== X-Gm-Message-State: AOPr4FX6wPk9fghf68ZVPXWFJFLmCwVua4YoFH8BZoZVRNnsgA/RyBMctBngiZjaSxbJmUvDTRg96zMdh7RVpQ== MIME-Version: 1.0 X-Received: by 10.140.148.208 with SMTP id 199mr17283367qhu.3.1463692430988; Thu, 19 May 2016 14:13:50 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Thu, 19 May 2016 14:13:50 -0700 (PDT) X-Originating-IP: [2001:4878:8000:50:fc46:bf8d:218d:1fef] In-Reply-To: References: <20160519190508.GE3300@mournblade.imrryr.org> <20160519191930.GF3300@mournblade.imrryr.org> <20160519200124.GG3300@mournblade.imrryr.org> Date: Thu, 19 May 2016 17:13:50 -0400 Message-ID: From: Kyle Rose To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption ticket/PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:13:53 -0000 I've modified the branch to use your wording. As Viktor said, it doesn't address his objection, but it's still a more precise starting point for further discussion. Kyle On Thu, May 19, 2016 at 4:37 PM, Martin Thomson wrote: > On 19 May 2016 at 16:01, Viktor Dukhovni wrote: >> Nevertheless, some clients may want to attempt to gain fine-grained >> protection against correlating back to back or parallel resumption >> requests. For this they'd have to ensure that all session tickets >> are single use, and either perform new handshakes when increasing >> the number of parallel connections to the server, or somehow obtain >> more than one ticket within a single session. > > I believe that this is the intent of the PR. I've suggested an > alternative wording that cleaves closer to your text above. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 19 14: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 6F57812D694 for ; Thu, 19 May 2016 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUVFkgizxV3Y for ; Thu, 19 May 2016 14:39: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 E624312D692 for ; Thu, 19 May 2016 14:39:15 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id x194so91822475ywd.0 for ; Thu, 19 May 2016 14:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jXJHqk9HbvJsa3SwoczgAm3urOt03CYpLqHOeXr9s1k=; b=p0S7eVZVQNeWSCiWzFriyj97DQ5POZ64IvgUnO2f0eb9ONKn90nlrbqQiDwmNeXfKu 20MUuaLWi0LQc40qG+ODsmoyL1VV7pnRbKPDDpoJJLZYO+BxsX87pe0Vvevy9b0sVhIw AXIiXgUojiBCDSloTdWrMJY5eGrXi16XBNA6ww39gcCAiwZ9wGeOQL4OViffi7RLBpNk 39BX+c57YLA9Lnz6+iBK42Szxe9PWwS+lDotg1CxzU2Kv0iOuc+dOmVrnE6MQMNcXE4V o/2tBI5ocYsT5OU7lzHAdRPTUWiIJ0zBKIBzjWXvgTdfp9HqGbm//p9UklJnT+g8tLP1 K+1w== 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=jXJHqk9HbvJsa3SwoczgAm3urOt03CYpLqHOeXr9s1k=; b=gw74klft4Q1qekaEu7R1/FgjBDpI2eCrvjNRocivprUYVaFVciH2y5fVq7QiPDHY+n L7XwdZRkr3J0wF0TYzAwOLp4XPf4ulkKVgKtaIdh/o8Oe6hgW/qr2JrZsUaXKlDy66Ip pOMzFlo3motGm7NbBWbn7/YgV7RfhgmFVJDkVRipIBiPT3bKM7DmllmBryk4xTwNaM4/ EWdh5JaQlI1HO2AUm4PTDy6NStfglrVm+Xfw93VZGmucOQcmO45hQITGY2tU9xYagtDq zV0/GBD6W37fRtCmSjBpLEVIYg9DUmmGgqYF9md0ROAyVXrqfhSQLj/hyyqE2uUnPg+4 hVKA== X-Gm-Message-State: AOPr4FX2vFqh+ygHTYq6UFU+iduJ/6/KKndPAKQnvJVwH7kjHeUCFtT0sBt77x2jtDekwZph/5XSjZD5u5eYWA== X-Received: by 10.129.163.146 with SMTP id a140mr8659386ywh.254.1463693955172; Thu, 19 May 2016 14:39:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 19 May 2016 14:38:35 -0700 (PDT) In-Reply-To: <20160519193518.GA4755@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> <20160519193518.GA4755@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 19 May 2016 14:38:35 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c1287ee423b5f053338ce43 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:39:17 -0000 --94eb2c1287ee423b5f053338ce43 Content-Type: text/plain; charset=UTF-8 Sorry, I think you lost me there. Can you rephrase? -Ekr On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara wrote: > On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote: > > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > > > > > Just one thing to be careful of: If one has off-handshake counter- > > > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash > > > those in, or one gets all kinds of crypto screw (which may or may not > > > be actually exploitable...) > > > > > > The "context identifier" looks real handy for that purpose.. > > > > > > Yep. We were thinking that too! > > > > > > Thanks for the quick look. > > In very quick'n'dirty security analysis the other thing I noticed was > that if server handshake needs something to be nonce w.r.t. "SS", (e.g. > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts > anyway, even with just "SS" being PSK. > > > -Ilari > --94eb2c1287ee423b5f053338ce43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I think you lost me there. Can you rephrase?
-Ekr


=
On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaar= a <ilariliusvaara@welho.com> wrote:
On Thu, May 19, 2016 at 12:13:45PM -0700= , Eric Rescorla wrote:
> On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > >
> > Just one thing to be careful of: If one h= as off-handshake counter-
> > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to h= ash
> > those in, or one gets all kinds of crypto screw (which may or may= not
> > be actually exploitable...)
> >
> > The "context identifier" looks real handy for that purp= ose..
>
>
> Yep. We were thinking that too!
>
>
> Thanks for the quick look.

In very quick'n'dirty security analysis the other thing I no= ticed was
that if server handshake needs something to be nonce w.r.t. "SS",= (e.g.
happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts
anyway, even with just "SS" being PSK.


-Ilari

--94eb2c1287ee423b5f053338ce43-- From nobody Thu May 19 23:34: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 5223412D6AE for ; Thu, 19 May 2016 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, 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 9WUYRLUeTu1z for ; Thu, 19 May 2016 23:34:06 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B36E312D6A7 for ; Thu, 19 May 2016 23:34:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A1E94A71E; Fri, 20 May 2016 09:34:03 +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 7BnlLb2EmUFR; Fri, 20 May 2016 09:34:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 36D61C4; Fri, 20 May 2016 09:34:03 +0300 (EEST) Date: Fri, 20 May 2016 09:34:00 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160520063400.GB4755@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> <20160519193518.GA4755@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] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 06:34:08 -0000 On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote: > On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara > wrote: > > > > In very quick'n'dirty security analysis the other thing I noticed was > > that if server handshake needs something to be nonce w.r.t. "SS", (e.g. > > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts > > anyway, even with just "SS" being PSK. > > Sorry, I think you lost me there. Can you rephrase? Basically, I think that without contexts, PSK+ServerCert modes like MT proposed (for 0-RTT with server certificate auth) run into cryptographic issues. -Ilari From nobody Fri May 20 06: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 D77FC12D922 for ; Fri, 20 May 2016 06:05:51 -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 W1zcK3VxiRIn for ; Fri, 20 May 2016 06:05:50 -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 33D5A12D921 for ; Fri, 20 May 2016 06:05:50 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g133so108257463ywb.2 for ; Fri, 20 May 2016 06:05:50 -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=dBcc2+4hqUJkdbm+ES/klnlSxwWDJOT1OX/xJYjYFrk=; b=BGp83yWHO55DOOoD3SmL0g9C8GyoE1xa7Jw2MQPvmoctMHSPa2yKArPRhjw6Gz21bB OfSBJKWls8c3QQlH0095gUWItYoTVk/NBEmnAI+F6j5lUkYASA9iTMP9YhBx2IJkvuFn TPpJOrH71dWPR9jbnKzaGtIUNSNwj/44HDuioh2wKcJ4PNQf9uDqEOAtqp6lEx/dm53x 3Zq6ICCxvBouwiLFRSynxkisd3NHZYAnMisYRZ44w+smnUelr1dlRe9pvhthmwqkFkFe Cc23ob4CucLuZL4BfhYwdE3J70ADOXhJoGwiVicUBM+1KBLKasDsTnKutGqZf67Dyicw g1vg== 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=dBcc2+4hqUJkdbm+ES/klnlSxwWDJOT1OX/xJYjYFrk=; b=kysKPLknS28SYuHyqXTXIgIysQ9mQ1lcx0ZL+QwPD0m+4mZW/vxFJV+DMULdD4ilw+ nApEjKH3zwC1NfXLVTu41FnexWPklu6FpRhiOFRfJAiHBuDaHmWMM664ZsttFuKGRs5v w7UzkXf0JZ+H76ozn9hjJGa3X1IhJh2kLFGht9yg3THvte4W5YJbLnOX+JUt4Iw+ebM3 fq+YrT9sUKDgTQtmBxqnaDjldWtLYfok2JZUkNSzfzkLjZMiz0dzQXpCsnBycRhmRUH7 5KYwYuu0eTcSso6eGPttS9u9mc6ngfGEMwKrXryS9cSlVnJ9oLZTZO7apP+ViPZYRWvc CLig== X-Gm-Message-State: AOPr4FXpQS+aP6QyElbwQ+nhiztLb+kOFcFQqdCVvWLhZ2jANT2EDhQ/ZfHEkfxN/zocZvU9+QMTmIkBIy8OQw== X-Received: by 10.129.51.140 with SMTP id z134mr1711338ywz.322.1463749549382; Fri, 20 May 2016 06:05:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 20 May 2016 06:05:09 -0700 (PDT) In-Reply-To: <20160520063400.GB4755@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> <20160519193518.GA4755@LK-Perkele-V2.elisa-laajakaista.fi> <20160520063400.GB4755@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 20 May 2016 06:05:09 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1140746eee8a41053345bf7c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:05:52 -0000 --001a1140746eee8a41053345bf7c Content-Type: text/plain; charset=UTF-8 Thanks for the clarification. Yes, I believe that is true. -Ekr On Thu, May 19, 2016 at 11:34 PM, Ilari Liusvaara wrote: > On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote: > > On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > > In very quick'n'dirty security analysis the other thing I noticed was > > > that if server handshake needs something to be nonce w.r.t. "SS", (e.g. > > > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts > > > anyway, even with just "SS" being PSK. > > > > Sorry, I think you lost me there. Can you rephrase? > > Basically, I think that without contexts, PSK+ServerCert modes like MT > proposed (for 0-RTT with server certificate auth) run into cryptographic > issues. > > > -Ilari > --001a1140746eee8a41053345bf7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the clarification. Yes, I believe that is true.=

-Ekr


On Thu, May 19, 2016 at 11:34 PM, Ilari L= iusvaara <ilariliusvaara@welho.com> wrote:
On Thu, May 19, 2016 at 02:38:35PM= -0700, Eric Rescorla wrote:
> On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> >
> > In very quick'n'dirty security an= alysis the other thing I noticed was
> > that if server handshake needs something to be nonce w.r.t. "= ;SS", (e.g.
> > happens in GDHE-PSK-CERT modes MT posted I-D about), you need con= texts
> > anyway, even with just "SS" being PSK.
>
> Sorry, I think you lost me there. Can you reph= rase?

Basically, I think that without contexts, PSK+ServerCert modes like = MT
proposed (for 0-RTT with server certificate auth) run into cryptographic issues.


-Ilari

--001a1140746eee8a41053345bf7c-- From nobody Fri May 20 10:25: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 7281612D597 for ; Fri, 20 May 2016 10:25:35 -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 Yx78bLGiyLTi for ; Fri, 20 May 2016 10:25:33 -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 BFA0412D18E for ; Fri, 20 May 2016 10:25:33 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id t40so61478778ioi.0 for ; Fri, 20 May 2016 10:25:33 -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=Hk5Qct6wOT/akcfoQuyufxPgtcmszMArXqBKat3WjmU=; b=nlvJYuCDRPplFY42o97eF0P1MTeAl35WEktdqgpFWO5JM1SyVB/CARr7on/0L9I//N 6ox0ikSc4HZk04AVnB7cMiuZ9uPRPfKgLkKUf2IU4wITtYIgCuhx+NrK45TIG1AePq35 01g3niBZZ6UvJrqvfwx16eXhq5ktl/QT25qTfh8uaf8l0jIZpiXS1+amvpQUbtwDcg37 NqFsMnwdLClOueVrnhKXvdAtNsEuhFxddkt6AppQ9uuQXW53CHy2SVNXLSibftcTvFT9 aZMMP1wE6xWAd00rq1pwHrth9yQadk05gZpiomEfmg0pw5qlcR8hI2emfMta7+LIZI/5 KpMg== 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=Hk5Qct6wOT/akcfoQuyufxPgtcmszMArXqBKat3WjmU=; b=gZEdangpPadcfWuAxEwx4MBFxi2NGLf7TNIPE8x1JSlkNx8z7W4a9TmhuKM0pUwcLy I2Bpzny8cB8Z0MqUr7ewTXUWeT5Pc9K2DX2v6bRPQWjShUHCto/VgK+sgn/iK72yolbJ LyMBLyfkuvN4PHI4tlk3neyNRx65PdJhB7GCe26zgnr7luDGV5h9HqOTCq+K3JgBDbvg k17iqgSLBw02PMkeARAjP9m8j0IFoZU2XO5d9DIKTKi4eKFusCTk+kBBw2O/J6LAPc42 vi8NWf1G0EIIk4Q7xE1n981VpOXtgQ8EozyFWX7Q078IJNiwQKe/FmR/vwUqETzqh7QI IkFg== X-Gm-Message-State: AOPr4FXT84b03GwLsLv4G/aCiyCSf4S/wpNXPmZOX82A5Q4liTX7zKLfAFghnY/WV1laefN/oJlwWdpWiWjc4g== MIME-Version: 1.0 X-Received: by 10.36.196.11 with SMTP id v11mr3957226itf.49.1463765133114; Fri, 20 May 2016 10:25:33 -0700 (PDT) Received: by 10.36.43.23 with HTTP; Fri, 20 May 2016 10:25:33 -0700 (PDT) In-Reply-To: References: <20160519191152.GA4667@LK-Perkele-V2.elisa-laajakaista.fi> <20160519193518.GA4755@LK-Perkele-V2.elisa-laajakaista.fi> <20160520063400.GB4755@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 20 May 2016 13:25:33 -0400 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 17:25:35 -0000 I also agree, FWIW, but expected that this would be addressed by any changes to 0-RTT and PSK in general. On 20 May 2016 at 09:05, Eric Rescorla wrote: > Thanks for the clarification. Yes, I believe that is true. > > -Ekr > > > On Thu, May 19, 2016 at 11:34 PM, Ilari Liusvaara > wrote: >> >> On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote: >> > On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara >> > >> > wrote: >> > > >> > > In very quick'n'dirty security analysis the other thing I noticed was >> > > that if server handshake needs something to be nonce w.r.t. "SS", >> > > (e.g. >> > > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts >> > > anyway, even with just "SS" being PSK. >> > >> > Sorry, I think you lost me there. Can you rephrase? >> >> Basically, I think that without contexts, PSK+ServerCert modes like MT >> proposed (for 0-RTT with server certificate auth) run into cryptographic >> issues. >> >> >> -Ilari > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri May 20 10:41: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 4348C12DA9D for ; Fri, 20 May 2016 10:41:51 -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 R0ivTU5EQ8R8 for ; Fri, 20 May 2016 10:41:48 -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 925F112D614 for ; Fri, 20 May 2016 10:41:48 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id j74so116173847ywg.1 for ; Fri, 20 May 2016 10:41: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; bh=nQopiEW33ImTqMfP/9DgYMGysDGzWFx1KNDn7XNEjFU=; b=YlQA8PKpt+fxEuCdIkbYnNEasXQ1KnuBdO3aHKl32HfjKwdx6p8DdNt8oGf7Nlgp2X eLZR8cq/2VdP0jGnD+pC8PZ2PK5IQkp6sQRpnEd+7L7RytKnM/BnicqpXX6lywJvjGaa /PwCbOax2uMzZHxtu8WR6G0a8l8H3lx/aTyMOoPLXlk0N+TkyJrmAmVR4YGJJnudexaF e0PIE6u6KUKTL3GSHabcwIRGuLwZRUiwgVPrNJ7piUt7DH0HSbKB9NwitCyjCa5Q2dKP mC07K97MKxWH6rAmIWu6EOqlQNQjNkSo5RMdred7fVhW9Ol0bnTqXF61ZEb87tjr8FYN 2MxQ== 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=nQopiEW33ImTqMfP/9DgYMGysDGzWFx1KNDn7XNEjFU=; b=L70Lh5cHHQPQ97rknM8m1YxcfZjI9VSWQbXELV4Cy8ttvmJ4JfwbXjn+dSqLUZxQMV AZL3bNwf3KPbxvwHTossqq0B+lCBjV1M/SJ6ZtVFBb9Mion+KySdRcXmOCxdTgLUHFTp 83/IVcdVpwcUipNOlA2eHECuoahJ0z+hg8I/VwoX5zeT9+fJQJdop5TxIbAES2JzzlO6 UmBv/w9ltYQrvDtToNeedr/Q+UlLXld6bTAWklu11cbDAhdntxlzIVIDfhM1Sg4xQTM6 Im6nI3uFrcbXKn6WtO4HNDScbSsSNYgnowB6h+rj7MHWbZ05R+otjWzPVj02L0jijWbL ZFdQ== X-Gm-Message-State: AOPr4FUlBhB1l5V6zypdyErHMN2wY3TruClxKwjRvrCXqY40i0H27L1gEmzALiARe67u3VckJlMraiUXCbvl5Q== X-Received: by 10.129.46.141 with SMTP id u135mr2472967ywu.180.1463766107750; Fri, 20 May 2016 10:41:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 20 May 2016 10:41:08 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 20 May 2016 10:41:08 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114089e2e342d80533499ac6 Archived-At: Subject: Re: [TLS] Key Schedule (PRs #453, #454). X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 17:41:51 -0000 --001a114089e2e342d80533499ac6 Content-Type: text/plain; charset=UTF-8 Merged. On Thu, May 19, 2016 at 10:41 AM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/454 > > I have uploaded a PR [technically two PRs, but one builds on the > other, so easier to just read the composition] which resolves two out > of the three significant remaining crypto issues (the remaining one is > the long-running discussion of post-handshake keys). The following > message lays out the changes, which are: > > - Adopt a more linear key schedule > - Add a context identifier for resumption > > > KEY SCHEDULE > We had a lot of comments that the existing key schedule was too hard > to understand and implement and could be simplified under the > assumption that keys were available in a specific order (PSK then DH > ZZ). I've been working together with Karthik, Hugo, Antoine, and > others to produce something cleaner. (Note: I believe they consider > this acceptable, but that doesn't mean they wouldn't have designed > every piece exactly as I have.) > > > The overall key schedule looks like this: > > 0 > | > v > PSK -> HKDF-Extract > | > v > Early Secret --> Derive-Secret(., "early traffic secret", > | ClientHello) > | = early_traffic_secret > v > (EC)DHE -> HKDF-Extract > | > v > Handshake > Secret -----> Derive-Secret(., "handshake traffic secret", > | ClientHello + ServerHello) > | = handshake_traffic_secret > v > 0 -> HKDF-Extract > | > v > Master Secret > | > +---------> Derive-Secret(., "application traffic secret", > | ClientHello...Server > Finished) > | = traffic_secret_0 > | > +---------> Derive-Secret(., "exporter master secret", > | ClientHello...Client Finished) > | = exporter_secret > | > +---------> Derive-Secret(., "resumption master secret", > ClientHello...Client Finished) > = resumption_secret > > Derive-Secret(Secret, Label, Messages) = > HKDF-Expand-Label(Secret, Label, > Hash(Messages) + resumption_context, L)) > > > Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons > indicated below. If a key is missing you just use 0s. > > The general pattern here is that the secrets shown down the left side > of the diagram are just raw entropy without context, whereas the > secrets down the right side include handshake context and therefore > can be used to derive working keys without additional context. All > the working keys (both encryption keys and finished keys) are > generated using HKDF-Expand-Label off of the traffic secrets. > > This design is motivated by the following principles: > > - Separate out adding entropy from adding context. > - Incorporate the transcript once and then derive from there. > - Have a narrow, consistent interface for generating the leaf keys > so they can just start with a base key. > - Derive from keys as soon as practical so that you can destroy them > (thus the final call to Add-Secret, which isolates the > Finished keys from the MS). > > An additional nice point about this design is that it easily > accomodates additional keys. For instance, if we had some post-quantum > key exchange method, we could easily add its key in the final > Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the > final Add-Secret. > > One thing I want to call out explicitly is that we are using > HKDF-Expand-Label with the output of HKDF-Expand-Label. This is > cryptographically fine, but means that you need an implementation of > the individual HKDF Expand/Extract primitives. As far as I can tell, > this isn't a hardship for anyone, but please speak up if it is. The > advantage of this is that you remove unnecessary crypto operations. > > > CONTEXT IDENTIFIER > PR: https://github.com/tlswg/tls13-spec/pull/454 > > Hugo and Karthik both independently suggested that it would be nice to > have some identity/context bound into the PSK handshake. The second PR > accomodates that by deriving two values from the RMS: > > resumption_psk = HKDF-Expand-Label(resumption_secret, > "resumption psk", "", L) > > resumption_context = HKDF-Expand-Label(resumption_secret, > "resumption context", "", L) > > The resumption_psk is then used as the PSK for resumption and the > resumption_context is added to the hash of the handshake messages > whenever you use them, currently just by appending to the hash, as in: > > Hash(handshake messages) +resumption_context > > This is used *both* to derive the keys and for the input to > the CertificateVerify/Finished. For convenience, I've > > > Note: the reason for separately deriving RMS and then computing the > context and PSK from RMS is to allow the server to just store RMS in > the ticket. If we used MS the server would need to store MS in the > ticket and then compromise of the ticket key would threaten the > original handshake. > > One nit question, would it be better to hash twice, as in: > > Hash(Hash(handshake messages) + resumption_context) > > I can't see a reason to, but maybe I've missed something. > > Comments welcome. In the interest of not having too many outstanding > changes, I'll probably merge this tomorrow unless someone strongly > objects or we find something really egregious (which is always possible > because there's a lot of text here). > > Best, > -Ekr > > > > > > > > > > > > > > > > > > > > > > --001a114089e2e342d80533499ac6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Merged.

On Thu, May 19, 2016 at 10:41 AM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:

I have uploaded a PR [technically two PRs, but one builds on the
other, so easier to just read the composition] which resolves two out
of the three significant remaining crypto issues (the remaining one = is
the long-running discussion of post-handshake keys). The follo= wing
message lays out the changes, which are:

- Adopt a more linear key schedule
- Add a context identifi= er for resumption


KEY SCHEDULE
We had a lot of comments that the existing key schedule was too hard<= /div>
to understand and implement and could be simplified under the
assumption that keys were available in a specific order (PSK then DH=
ZZ). I've been working together with Karthik, Hugo, Antoine,= and
others to produce something cleaner. (Note: I believe they c= onsider
this acceptable, but that doesn't mean they wouldn= 9;t have designed
every piece exactly as I have.)

<= /div>

The overall key schedule looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A00
=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=A0v
=C2=A0 =C2=A0PSK -> =C2=A0HKDF-Extract
=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=A0v
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Early Secret =C2=A0--> Derive-Secr= et(., "early traffic 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 ClientHello)
=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 =3D e= arly_traffic_secret=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0v
(EC)DHE -> HKDF-Extract
= =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=A0v
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Handshake
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secret -----> Derive-Se= cret(., "handshake traffic 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 ClientHello + Serve= rHello)
=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 =3D handshake_traffic_secret
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2= =A0 0 -> HKDF-Extract
=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=A0v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 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+---------> Derive-Secret(., "application traffic = 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=A0 =C2=A0 ClientHello...Server Finished)
=
=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=A0 =C2=A0 =3D traffic_secret_0
=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=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------> Derive-Secre= t(., "exporter 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 ClientHello...Client Finis= hed)
=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 =3D exporter_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=A0+---------> D= erive-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=A0Client= Hello...Client Finished)
=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=A0=3D resumption_secret
=C2=A0 Derive-Secret(Secret, Label, Messages) =3D
= =C2=A0 =C2=A0 =C2=A0 =C2=A0HKDF-Expand-Label(Secret, Label,
=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=A0Hash(Messages) + resumption_context, L))

<= div>
Derive-Secret is just a wrapper around HKDF-Expand-Label= , for reasons
indicated below. If a key is missing you just use 0= s.

The general pattern here is that the secrets sh= own down the left side
of the diagram are just raw entropy withou= t context, whereas the
secrets down the right side include handsh= ake context and therefore
can be used to derive working keys with= out additional context.=C2=A0 All
the working keys (both encrypti= on keys and finished keys) are
generated using HKDF-Expand-Label = off of the traffic secrets.

This design is motivat= ed by the following principles:

- Separate out add= ing entropy from adding context.
- Incorporate the transcript onc= e and then derive from there.
- Have a narrow, consistent interfa= ce for generating the leaf keys
=C2=A0 so they can just start wit= h a base key.
- Derive from keys as soon as practical so that you= can destroy them
=C2=A0 (thus the final call to Add-Secret, whic= h isolates the
=C2=A0 Finished keys from the MS).

<= /div>
An additional nice point about this design is that it easily
accomodates additional keys. For instance, if we had some post-quantu= m
key exchange method, we could easily add its key in the final
Add-Secret or add an extra Add-Secret stage before HS. Similarly, = if
we had a long-term DH key as in OPTLSv1, it could replace the = 0 in the
final Add-Secret.

One thing I w= ant to call out explicitly is that we are using
HKDF-Expand-Label= with the output of HKDF-Expand-Label. This is
cryptographically = fine, but means that you need an implementation of
the individual= HKDF Expand/Extract primitives. As far as I can tell,
this isn&#= 39;t a hardship for anyone, but please speak up if it is. The
adv= antage of this is that you remove unnecessary crypto operations.
=

CONTEXT IDENTIFIER

Hugo and Kart= hik both independently suggested that it would be nice to
have so= me identity/context bound into the PSK handshake. The second PR
a= ccomodates that by deriving two values from the RMS:

=C2=A0 =C2=A0resumption_psk =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 =C2=A0 =C2=A0 =C2=A0 "re= sumption psk", "", L)

=C2=A0 =C2=A0= resumption_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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;resumption context", "", L)

The re= sumption_psk is then used as the PSK for resumption and the
resum= ption_context is added to the hash of the handshake messages
when= ever you use them, currently just by appending to the hash, as in:

=C2=A0 =C2=A0Hash(handshake messages) +resumption_context<= /div>

This is used *both* to derive the keys and for the= input to
the CertificateVerify/Finished. For convenience, I'= ve=C2=A0


Note: the reason for separ= ately deriving RMS and then computing the
context and PSK from RM= S is to allow the server to just store RMS in
the ticket. If we u= sed MS the server would need to store MS in the
ticket and then c= ompromise of the ticket key would threaten the
original handshake= .

One nit question, would it be better to hash twi= ce, as in:

=C2=A0 Hash(Hash(handshake messages) + = resumption_context)

I can't see a reason to, b= ut maybe I've missed something.

Comments welco= me. In the interest of not having too many outstanding
changes, I= 'll probably merge this tomorrow unless someone strongly
obje= cts or we find something really egregious (which is always possible
because there's a lot of text here).
=C2=A0=C2=A0
Best,
-Ekr











=C2=A0=C2=A0

=





=




--001a114089e2e342d80533499ac6-- From nobody Fri May 20 12:41: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 4BE6612D612 for ; Fri, 20 May 2016 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, 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 X-cDmaGAUwIP for ; Fri, 20 May 2016 12:41:20 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4012D1CD for ; Fri, 20 May 2016 12:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 99C4DF078; Fri, 20 May 2016 22:41: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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id ubVL_lcPD3O9; Fri, 20 May 2016 22:41:17 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DB7C428A; Fri, 20 May 2016 22:41:17 +0300 (EEST) Date: Fri, 20 May 2016 22:41:15 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160520194115.GA5467@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] Asking for certificate authentication when doing 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: Fri, 20 May 2016 19:41:22 -0000 On Wed, May 18, 2016 at 10:10:29AM -0400, Martin Thomson wrote: > I just posted this: > > https://datatracker.ietf.org/doc/draft-thomson-tls-0rtt-and-certs/ > > It's fairly self explanatory. The idea is to create a way to signal > that the client wants the server to re-authenticate itself, even if it > successful in using a pre-shared key. - How is the capability signaled? New flag bits in session ticket for these ciphersuites? - This mechanism has session ticket lifetime limited by the certificate lifetime, right? -Ilari From nobody Fri May 20 13:43: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 E44F212D620 for ; Fri, 20 May 2016 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 nq-pHQl5fcia for ; Fri, 20 May 2016 13:43:21 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A071C12D61E for ; Fri, 20 May 2016 13:43:21 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id vs11so27412551igb.1 for ; Fri, 20 May 2016 13:43:21 -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=5imVi6aDQ0VzRHUFfnxhnRuUPLDjtH0W1N6rvVezids=; b=oo9We7QIpz6tAsHRwSrEnLqqY5IN82tcuB8Wn0L2G559FcTEEgJcB6+1NX3R9aP4qe E43xdnRlRIf5fCLeqB9TWd4lxH/2J2mfiKhP8eDvuBkrh/jrhHW1cVc18Flvp83WgAiG gYVt0oedPNj6l4hlOZyLaXjuCmFwcZUJYCroZadP7+9z1U+7goAGyfA+lHnWwzRr6S5P 5W8qUFZpua4fHNU8OHtESfOUQ+Y7JWnxVevmUrpMcTPbeVEC7iH45honTzU3NBUO3Kxf w5C8+a5fefYRFQ+sYWjWtisSszxjCl3r78g5Mq3XAGCOux9kePN5QfUIxbvN4Xd+M515 Bl/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5imVi6aDQ0VzRHUFfnxhnRuUPLDjtH0W1N6rvVezids=; b=B8p87DiPHzseSB7LGTTp5dSKuCTkhei3tBnt0xTULSI57UDtYSLGtTknenmJyMipSu OY7ZRLGbbLICxsVS71xkd1hyrQsj8KjpsYXTy4hoTJg+iJTAihyaIDP9jAdUI6ZypL95 TwrrmCifHCXkPV2Q6C6PlU21exSMuLfuaqv+7Et9O3oiMhztrR8aQDVh8gBHk9N3/bvF iLsYirX2pxMETowxCulOeCa/R+FVn++I8pHxTZStP636zTIZ5g8BXA2H3MzMzbvW5fkn f6VQKl4tngenaZr1ZjV98YGYIAUn2UPLl/Fdsa15ttwPrGArihC4XQRbVF4MG47Gf45L 7VDw== X-Gm-Message-State: AOPr4FUdYvLBHuY7d2kLk4WfLmQhcUO1bEJFFIeyDAT5GezuCXDzZDfpuJZSPG1uC3pSh4FePIl/LhuFu8SKBQ== MIME-Version: 1.0 X-Received: by 10.50.122.68 with SMTP id lq4mr4803660igb.77.1463777000926; Fri, 20 May 2016 13:43:20 -0700 (PDT) Received: by 10.36.43.23 with HTTP; Fri, 20 May 2016 13:43:20 -0700 (PDT) In-Reply-To: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 20 May 2016 16:43:20 -0400 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Asking for certificate authentication when doing 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: Fri, 20 May 2016 20:43:23 -0000 On 20 May 2016 at 15:41, Ilari Liusvaara wrote: > - How is the capability signaled? New flag bits in session ticket > for these ciphersuites? Yes, I realized it yesterday that I had neglected to define the bit that this needs. Of course a client could decide to do this unilaterally. > - This mechanism has session ticket lifetime limited by the certificate > lifetime, right? There is a session ticket, which has a lifetime. The certificate has to be constant, so if that expires, then you can't connect. So yes, both limits would seem to apply. From nobody Fri May 20 13:58: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 9564A12D635 for ; Fri, 20 May 2016 13:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, 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 4YoOrRY7H5_G for ; Fri, 20 May 2016 13:58: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 C338F12D154 for ; Fri, 20 May 2016 13:58:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9623BF846; Fri, 20 May 2016 23:58:26 +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 b7X5OYUAL4hX; Fri, 20 May 2016 23:58:26 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5573228A; Fri, 20 May 2016 23:58:26 +0300 (EEST) Date: Fri, 20 May 2016 23:58:23 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160520205823.GA5606@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160520194115.GA5467@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] Asking for certificate authentication when doing 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: Fri, 20 May 2016 20:58:29 -0000 On Fri, May 20, 2016 at 04:43:20PM -0400, Martin Thomson wrote: > On 20 May 2016 at 15:41, Ilari Liusvaara wrote: > > > - This mechanism has session ticket lifetime limited by the certificate > > lifetime, right? > > There is a session ticket, which has a lifetime. The certificate has > to be constant, so if that expires, then you can't connect. So yes, > both limits would seem to apply. Also, the effective lifetime of the cert can be good bit shorter than the nominal one (e.g. 90 day cert renewed at 60 days). And most software doesn't support overlapping certs... -Ilari From nobody Sat May 21 15:11: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 E9CC412D189 for ; Sat, 21 May 2016 15:11: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 lAjZWW_orIBw for ; Sat, 21 May 2016 15:11:54 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 663A112D13B for ; Sat, 21 May 2016 15:11:54 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id o16so22528215ywd.2 for ; Sat, 21 May 2016 15:11:54 -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=7gnZoHg4IzZsIrNnj+8/AbUGxQgtRi2Q0iVPaiHBqC4=; b=yPmPe6PhRL31HO/yIDhSPoiBVqIpBPp3ZvHxAOsnyUTlX1CfIc8q+2N8hVaCXdLc/w j5zFnlVY3ufHCtwCkBwXsxPN7fjc7FAf3BkQiOabxrKSHquxNpbC2/vm5DXju+e9DdeY CueeUWCspu2vYcm8daF4QpkM+m7XaWSqT1A1y2iPTFv5xtJ7kw2JDgpNtIa4KGNJ5GVU dWRT+MJAk3WnavKcHbKrlfGcjA4/zTue3xAVZE+LsYVY0ZCO/HmHKfFqFY7aDZpw2gRh h1natmWoUYSoxp28otlKawaPYgNL0FbrDMzet5cklydWNgH8QXfqkD4HU3QRq1egDOzF I05A== 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=7gnZoHg4IzZsIrNnj+8/AbUGxQgtRi2Q0iVPaiHBqC4=; b=jatR14bZ3ZRbdO5YR2Sc3/CIqF03+dNsb0964PXt3OIGOYBzVqRLOjN2ZKs29a9HRO I+LtZQJ83z6PBnaOUKsJpRqHBvYrwNlmIVbPt3uUxmRtIrp3UR5wFdkV0/rMp6Ghx0h0 a6LVCO+iO+PEeB7+m2Ae7AkgIT8uKRxiez9DNNVVE+mrTUKtXx/YCpZeWehnRVbkBxrT arB/HTPtIfiE1wacJpJicZRooXXW8tB1c1Pdm4WTnmkTgCF3uspsEkmy+gacmQmYCs8T OUOWwf/FMVm/Z++c36qZjlXTB72uKwSJDUfFiJK49wLZDDiE1sx+v7gojOe/MT2rpQ4J EGwQ== X-Gm-Message-State: AOPr4FXhQbwmCo40Q/w3mmfPu6BdJ4WtFibsv00XE3bSp0znVqROM4maaaOaVfoDbXU2r0mBJAJE21BBKCM4Rw== X-Received: by 10.37.208.16 with SMTP id h16mr5600041ybg.82.1463868713643; Sat, 21 May 2016 15:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sat, 21 May 2016 15:11:14 -0700 (PDT) From: Eric Rescorla Date: Sat, 21 May 2016 15:11:14 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0553eeace0870533617ecb Archived-At: Subject: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 22:11:56 -0000 --94eb2c0553eeace0870533617ecb Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/471 http://tlswg.github.io/tls13-spec/#alert-protocol says: "Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections." However, this is not consistent with a stateless implementation of session tickets. RFC5077 is a bit handwavy on this but implies that you shouldn't do this with tickets (see also [SBR04] for discussion of this). I propose we remove this requirement -Ekr [SBR04] Shacham, H., Boneh, D., and E. Rescorla, "Client-side caching for TLS", Transactions on Information and System Security (TISSEC) , Volume 7, Issue 4, November 2004. --94eb2c0553eeace0870533617ecb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Alert messages with a level o= f fatal result in the immediate termination of the connection. In this case= , other connections corresponding to the session may continue, but the sess= ion identifier MUST be invalidated, preventing the failed session from bein= g used to establish new connections."

Ho= wever, this is not consistent with a stateless implementation of session ti= ckets.
RFC5077 is a bit han= dwavy on this but implies that you shouldn't do this with tickets
<= font face=3D"arial, helvetica, sans-serif">(see also [SBR04] for discussion= of this). I propose we remove this requirement

<= br>
-Ekr


=C2=A0 =C2=A0[SBR04] =C2=A0 =C2=A0 Shacham, H., Boneh, D.,= and E. Rescorla, "Client-side
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 caching for TLS", Transactions on Informa= tion and System
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Security (TISSEC) , Volume 7, Issue 4, November 2004.


--94eb2c0553eeace0870533617ecb-- From nobody Sat May 21 15: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 CA8E512D0EB for ; Sat, 21 May 2016 15:17:20 -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 AFXCE5fni3Ut for ; Sat, 21 May 2016 15:17:19 -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 5E11612D0BF for ; Sat, 21 May 2016 15:17:19 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id x194so140312685ywd.0 for ; Sat, 21 May 2016 15:17:19 -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=LaEsBmC0TuoyROTCuldlM4+dGFy7ptVkLWr/VHYA7yo=; b=QSjAhZ4Hjcs78Vk+e/K4erB1fY4XRPLiD0WIm0ZsY5tTEBL3vp2+lpe8SMn071K0fx zs4mL4Aau0gmwA8B57lAZeH91X43fMv4ZPaNWbmyc4kHBmng0scz36Q/86S7mFvZ5/RP sJH9wkW7BhDS7awMIgNYRghwTkE+NFqL7Raug1r2/NpJmyH0eZRIIeJZUcDgRNFt/5Jq Lt6+oWjRhjp57KHZV3OxBeccv0UhT4d0rfqtCwxIQw7aCQmKD5C7ioud8cJ+18wSjSMr wT4tHasS0exWRqZi3GWVXenarvPQ6AAxZVLVWV1uXZOHESzn/QhjrGtq5UesOTBoLyO7 o2ug== 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=LaEsBmC0TuoyROTCuldlM4+dGFy7ptVkLWr/VHYA7yo=; b=PiZ1PsFnddFThjc6/7PM/WCbWKoVauOqTTO4QuVosOQt3j2Ef1sDcC0zh63VpSWqhB G4XT9ndEiaGJH2foRKThLoQHAEQDhF3AQgN8JZ2hUt1rH8niUJrIPOZ4cZ4SRt4t/K2v NMc/LofWYl0YpcL/p3HYT0oBPx/RzfTEqGpHfN1uRrxa6kWwyoo7YyJkAOdgXMGaWtYu nElB4s0de6YvXPTnCeOc+vF6qw5mXDncBZEMdNVvL9K0eDlGAZ24rpbILov6WXBsURNt q7RXcy7nlgTxCLey7EUTSFppaTGC0LJPtjV+CGcIKpBUuy96jkUlR6ucENINcCGQK9Ot lNqg== X-Gm-Message-State: AOPr4FUl8dGNOVLR66GvFMcCVga6VvCOjUFMPNqhyGjFEHCoio0jtFzDMqhde5Ml6Za8qmcSrsC/B3q/oUd+UQ== X-Received: by 10.129.51.140 with SMTP id z134mr5605581ywz.322.1463869038607; Sat, 21 May 2016 15:17:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sat, 21 May 2016 15:16:39 -0700 (PDT) From: Eric Rescorla Date: Sat, 21 May 2016 15:16:39 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140746e0b6da105336192fc Archived-At: Subject: [TLS] Issue 472: Remove redundant 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, 21 May 2016 22:17:21 -0000 --001a1140746e0b6da105336192fc Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/472 http://tlswg.github.io/tls13-spec/#error-alerts says: Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted. For example, if a party decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a "certificate_expired" alert. It would probably be simpler to require that alerts either be warning or fatal and that the only warning alerts are the "Closure Alerts" specified in http://tlswg.github.io/tls13-spec/#closure-alerts (or in some update document) rather than expect people to handle some warning version of the Error Alerts. Thoughts? -Ekr --001a1140746e0b6da105336192fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


<= div>=C2=A0 Therefore, warning alerts are not very useful when
=C2=A0 the sending party wants to continue the connection, and thus are so= metimes
=C2=A0 omitted. For example, if a party decides to accept= an expired certificate
=C2=A0 (perhaps after confirming this wit= h the user) and wants to continue the
=C2=A0 connection, it would= not generally send a "certificate_expired" alert.

=
It would probably be simpler to require that alerts either be wa= rning or fatal and that
the only warning alerts are the "Clo= sure Alerts" specified in
rather than expect people= to handle some warning version of the Error Alerts.

Thoughts?
-Ekr



--001a1140746e0b6da105336192fc-- From nobody Sat May 21 18:26: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 46F7212D1A7 for ; Sat, 21 May 2016 18:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcJ1SkdY7_F4 for ; Sat, 21 May 2016 18:26:06 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 9789B12B05C for ; Sat, 21 May 2016 18:26:06 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id j18so28083910qge.2 for ; Sat, 21 May 2016 18:26:06 -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=XBVHIbsIIagSZITLduxvw453+Jnb7cicvepbiYFOvJI=; b=rSz0+sdCZ+RnPN77uadGNewjI1Hk7A3K0FNd1uRomEa6Wn+M6wPbsaev/c7uuvMIP1 bBGmdLqKjwlsxLB2Br+s8jHS2bm7ZSsjdUEna7sMyAP94Ts8QK/eky82NSJpWSeqYnIB 5s88XZUH9pfl/nl0sCD5+iOPj26o+cmzGY9bdpw9jArvMqF8vhGB8Cl7t0gKNc1yhIwX m8f6R+MxrpyNDDH36SR2WZl3QhmMPLPxPUPtrMPNlLv8mPUNhHZnteN9ewwjF5JK8hW3 zl34hYJ4ky/1585X1kWclorjcAjhF/4XxmD36IfAE8mKzjnWBAgLqScUcCK0hUjgc3x/ ZTcg== 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=XBVHIbsIIagSZITLduxvw453+Jnb7cicvepbiYFOvJI=; b=FJMixtaI6VtLcdTn8w+Zj4VDC8VALfpqnh/zKylu2Jm4eXETtfqb/N8MWsqVDAwfoI M3Qx228+G7krbWq1d+Sfib1o62uok0/+ENTxd71om92joQiEjqWbFwZHmC3SqCiQBo6M 0nfenFo6HMjIqh232Fz92s3wKP87ZDBCnoTDfw3hsPYi5Htd6sW78E14v/dVaEdakmbc eqiXK8PQpFlzS/Rr+tL5PGB9CcPEm2rbzuTRLZbNJycgCgKSdTPgCI3i0DIeBy8Vj6WL jru9EWBoL65MLDt94KWVAebE7xRjVAw+FLoQnGM1cAxCxF78n9j02EdOTLoFrNLX3oF1 oGhA== X-Gm-Message-State: AOPr4FV1Pf4OE9eJizMT2Ohr1wfMlQJ4vQ4ePhHU02uUlCWYZUBlt/Rq2LlpnpFP+enz8w== X-Received: by 10.140.216.16 with SMTP id m16mr10322287qhb.37.1463880365753; Sat, 21 May 2016 18:26:05 -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 s184sm11258526qhc.28.2016.05.21.18.26.04 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 21 May 2016 18:26:04 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 21 May 2016 21:26:03 -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: <201605212126.03515.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Issue 472: Remove redundant 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, 22 May 2016 01:26:08 -0000 On Saturday, May 21, 2016 06:16:39 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/472 > > http://tlswg.github.io/tls13-spec/#error-alerts says: > > Therefore, warning alerts are not very useful when > the sending party wants to continue the connection, and thus are sometimes > omitted. For example, if a party decides to accept an expired certificate > (perhaps after confirming this with the user) and wants to continue the > connection, it would not generally send a "certificate_expired" alert. > > It would probably be simpler to require that alerts either be warning or > fatal and that > the only warning alerts are the "Closure Alerts" specified in > http://tlswg.github.io/tls13-spec/#closure-alerts (or in some update > document) > rather than expect people to handle some warning version of the Error > Alerts. > > Thoughts? Does any implementation actually do anything with the warning version of alerts in question? If not, then this sounds like a reasonable simplification. Dave From nobody Sun May 22 02:25: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 F282112D09A for ; Sun, 22 May 2016 02:25: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 by2NJtOR1dwY for ; Sun, 22 May 2016 02:25:21 -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 34C9612B01C for ; Sun, 22 May 2016 02:25:21 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n129so36876908wmn.1 for ; Sun, 22 May 2016 02:25:21 -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=vt5ol9gl8YGfqhOTqUI/G1ExMP9Ii79ZSGKcubYKg+o=; b=E5o5iuaFK9KfSjWKJuh3DgJKT79whx+413u7Jo5lxO8MZ/U8givF/6RSz+kFDlDYLd Nx1NMBbFWyaib0kPKctEUBxD/JOVxvbi+0WqdAl1F7FhLzwM6+SszztBaBRyNbWoi+Gx dvtG0YLamryD9GSWY9xMkdQPJzCfHjdKyZZ2F4EpClXLHjsH6anp5uIv6XNfNBIShClh gs2blcZbS4za1z+MrL+POdOymeeKKbCX92Ec7pyQt6xBgaMznXlQPO8xHjIkNukcVCed bpQeVpLLNeuAX82y2aJ3e1T1uVUhz65I1pqv8Uelk1MpxkZUvQtsmFTok5OC85XMGjOV 481g== 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=vt5ol9gl8YGfqhOTqUI/G1ExMP9Ii79ZSGKcubYKg+o=; b=i/MLfF6JZ8bsCH2QWUE+GDFDf0fAJjv/9zzLQrC8AMDS0GupHInH6nGVBf7rwkMDF7 MXoeUXK2MSxErYmzoVW+FTnD5ORr0Dh6V6ZpQ4tCUQEnuS9qB+0kZP8iy8t3/8+uj6iR 6HlFxE/xHqbrhaVVUGdwT6de7J+xZYDGeEUb7+CGMakWCUDT3tQr7ZdqGEq5RK+tTRce NidiBNNbkscZCMuI2+CFMhdFunwqCjTmuAXhIRaPeoXDqDkPBNICCrjVy7Vj5z6JvD+9 l8fMdnunPIwzSscFWnyBSBlaU6STpl//vSxs1xboiT77ZLEXsj3WP2C3IgTAOuRYFlHY daeQ== X-Gm-Message-State: AOPr4FUblqeVwGYtMGYVWzc02LbmCt5Kvm0JzKqEYC9MLSCTm6NvF0hFPDRvn9RDY1fmXQ== X-Received: by 10.28.113.86 with SMTP id m83mr9919866wmc.67.1463909119599; Sun, 22 May 2016 02:25:19 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-2-90.red.bezeqint.net. [79.179.2.90]) by smtp.gmail.com with ESMTPSA id kc2sm28960739wjb.5.2016.05.22.02.25.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 May 2016 02:25:18 -0700 (PDT) To: Eric Rescorla , "tls@ietf.org" References: From: Yaron Sheffer Message-ID: <57417AFC.7030702@gmail.com> Date: Sun, 22 May 2016 12:25:16 +0300 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=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 09:25:23 -0000 This still makes the *stateful* implementation much more deterministic and those implementations are common enough. So how about: Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. This requirement does not apply when the server's implementation of session resumption is stateless. Thanks, Yaron On 22/05/16 01:11, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/471 > > > http://tlswg.github.io/tls13-spec/#alert-protocol says: > > "Alert messages with a level of fatal result in the immediate > termination of the connection. In this case, other connections > corresponding to the session may continue, but the session identifier > MUST be invalidated, preventing the failed session from being used to > establish new connections." > > However, this is not consistent with a stateless implementation of > session tickets. > RFC5077 is a bit handwavy on this but implies that you shouldn't do this > with tickets > (see also [SBR04] for discussion of this). I propose we remove this > requirement > > > -Ekr > > > [SBR04] Shacham, H., Boneh, D., and E. Rescorla, "Client-side > caching for TLS", Transactions on Information and System > Security (TISSEC) , Volume 7, Issue 4, November 2004. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun May 22 07:22: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 BF58112B00C for ; Sun, 22 May 2016 07:22:19 -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 eIwvgrcjWLWu for ; Sun, 22 May 2016 07:22:18 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C2F8E12B004 for ; Sun, 22 May 2016 07:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A6BA7C602 for ; Sun, 22 May 2016 17:22:15 +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 gNVONxeWPX3W for ; Sun, 22 May 2016 17:22:15 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 765EB21C for ; Sun, 22 May 2016 17:22:15 +0300 (EEST) Date: Sun, 22 May 2016 17:22:12 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160522142212.GA17666@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] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 14:22:20 -0000 Looking at PR #468: - It isn't at all obvious how to use it for stateless rejection. - It is even less obvious how to recover (not causing non-retryable fault) from bad cookie (e.g. expired) remembered from previous connection. There are some tricks for both, but with latter, the 255-byte cookie space can become quite cramped... I think it would be easier if either: - Cookies could not be remembered across connections. - HRR and EE cookies had separate slots those go to in CH. (Of course, neither of those solves the "failed 0-RTT" case...) Also, some clients do burst connects, where multiple TLS connections are connected in parallel. Through quite frequently these would be pure-PSK, keyed off one master GDHE-CERT connection. -Ilari From nobody Sun May 22 07: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 A0BF912D0AE for ; Sun, 22 May 2016 07:49:54 -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 9UVrLweZQuiY for ; Sun, 22 May 2016 07:49:53 -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 14E1912B069 for ; Sun, 22 May 2016 07:49:53 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id c127so33151429ywb.1 for ; Sun, 22 May 2016 07: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:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E3Mms8prBpCRjV4k8uFKJhFhDKEjElsyJ87UUuzkGM0=; b=D727Iy/18aVQsc16LOgmw0mYUXX3BKzB8ENU2PwXgS7sw5QF7hjUlprkhiSoSDcZ+A Bc4i7WQZkatuDQdFabGc1SSM2cujsSG2A5PdNewXAfFvU4yGHHmIWVz/uXMEyYkt3Sl5 M6a1gs4MjDY9pS0nzS+oZi7pUnBM/Su/gOoKAevN3RoS9pmAxtg5RhYn3RYmHMQfhL0c Xd8y0xMBIQo2yTRJ7zFd4fd7NymYNRIq8pxtT5QW1gXWPuW9StdXv0nBANPrXwxwVnDH nWWyctAiJBZdt9IsObibnzbWfOLNLP+qqTdSN6w8LymPhMyvW4bfe1cnXAUXbSWULFSI TbMg== 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=E3Mms8prBpCRjV4k8uFKJhFhDKEjElsyJ87UUuzkGM0=; b=KieGEfi97d7hgmk9ayaE6ZOBG/86W+/aPFxiEks9+ZIbcd2lkV4uXQlHE92ef2yhjg lf0zLdgmv/QoKErTvnxCsqwjD4K2L3a8zMQxdWnyRG3scvmDY9oVYUGDLj3I/MfnFYR6 oGHr2LKAz8wgS5w9nQMuoWQN0vxcdw7d1cfs90c9/y0QbbeSUIkc4SnwqBq/r1Ca9COn fS+uYTqyjK1XgbKWZVqKnqWNYNfT3jOuPQ+L/w4KkWJN61w2ChYRcv+dINt7sGnswV85 JhiFUVOdHcCRYnxjrQOnOn8roIvjoML2RslHrw6wXE2Tb2Qe7k+t+09wicIR/9pPzf/m Stjg== X-Gm-Message-State: AOPr4FXbVLhhpac6x9SbwKTgUVHDT6ohvdB7iG0+K+rZCWspZGeDf/FaWh0rMqyMsG6pnKr1mH0bEMfZFLVXlQ== X-Received: by 10.129.163.146 with SMTP id a140mr7289060ywh.254.1463928592298; Sun, 22 May 2016 07:49:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 07:49:12 -0700 (PDT) In-Reply-To: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 22 May 2016 07:49:12 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c1287eeb8a0af05336f6f06 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 14:49:54 -0000 --94eb2c1287eeb8a0af05336f6f06 Content-Type: text/plain; charset=UTF-8 On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara wrote: > Looking at PR #468: > - It isn't at all obvious how to use it for stateless rejection. > - It is even less obvious how to recover (not causing non-retryable > fault) from bad cookie (e.g. expired) remembered from previous > connection. > > There are some tricks for both, but with latter, the 255-byte > cookie space can become quite cramped... > I'll make the space biggeer. > > I think it would be easier if either: > - Cookies could not be remembered across connections. > Yes, MT and I discussed this last night and came to the same conclusion. I will make it so. -Rk > - HRR and EE cookies had separate slots those go to in CH. > > (Of course, neither of those solves the "failed 0-RTT" case...) > > > Also, some clients do burst connects, where multiple TLS > connections are connected in parallel. Through quite frequently > these would be pure-PSK, keyed off one master GDHE-CERT > connection. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1287eeb8a0af05336f6f06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, May 22, 2016 at 7:22 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
Looking at PR = #468:
- It isn't at all obvious how to use it for stateless rejection.
- It is even less obvious how to recover (not causing non-retryable
=C2=A0 fault) from bad cookie (e.g. expired) remembered from previous
=C2=A0 connection.

There are some tricks for both, but with latter, the 255-byte
cookie space can become quite cramped...

I'll make the space biggeer.




I think it would be easier if either:
- Cookies could not be remembered across connections.
=
Yes, MT and I discussed this last night and came to the same= conclusion.=C2=A0
I will make it so.

-R= k
=C2=A0
- HRR and EE cookies had separate slots those go to in CH.

(Of course, neither of those solves the "failed 0-RTT" case...)

Also, some clients do burst connects, where multiple TLS
connections are connected in parallel. Through quite frequently
these would be pure-PSK, keyed off one master GDHE-CERT
connection.



-Ilari

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

--94eb2c1287eeb8a0af05336f6f06-- From nobody Sun May 22 08:59: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 BB92612D130 for ; Sun, 22 May 2016 08:59:28 -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 1UnpG7KSk87Z for ; Sun, 22 May 2016 08:59:26 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B435D12B038 for ; Sun, 22 May 2016 08:59:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 295127925; Sun, 22 May 2016 18:59:25 +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 yrkQ7uGtPSVW; Sun, 22 May 2016 18:59:24 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id BE99027B; Sun, 22 May 2016 18:59:24 +0300 (EEST) Date: Sun, 22 May 2016 18:59:21 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@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] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 15:59:29 -0000 On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara > wrote: > > > Looking at PR #468: > > - It isn't at all obvious how to use it for stateless rejection. > > - It is even less obvious how to recover (not causing non-retryable > > fault) from bad cookie (e.g. expired) remembered from previous > > connection. > > > > There are some tricks for both, but with latter, the 255-byte > > cookie space can become quite cramped... > > > > I'll make the space biggeer. Not having to deal with cross-connection cookies makes things easier, but... Actually, looking at it, I didn't find how EDI context is determined. And EDI context needs to be fit into cookies because it isn't retransmitted on 2nd CH. If it is intended for client to be able to preturb 0-RTT, it can be much smaller. 32 bytes is plenty for random parameter, and then ClientRandom preturbs 0-RTT as well... Also while looking at 0-RTT: It occured to me how to determine the ciphersuite used for 0-RTT. Then it occured to me that the symmetric parts are determined by the provisioned context and asymmetric parts don't matter. But I think this is quite non-obvious. And clock errors being small outside of gross corrections? Clock first-order errors can be pretty large with unsynchronized clocks (I have personally seen FO errors on order of 1s per day on some bit bad piece of kit), and those would absolutely show up as errors in ticket age. And if you have synchronized clock, the zeroth-order errors (wrong time) will be small too (can be <10ms). And have fun with leap seconds. :-) Is the ticket allowed to outlive certificate orginally used in provisioning it (possibly indirectly, with ticket being provisoned from connection using ticket)? Also, the extension negotiation matching stuff with 0-RTT talking about padding? Padding just plain can't be negotiated. And "negotiated in ServerHello"? None of the extensions that can presently be negotiated there are any of any interest with 0-RTT. To me the text looks really confused. -Ilari From nobody Sun May 22 11:30: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 A4C3212D504 for ; Sun, 22 May 2016 11:30: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 tsDK-y7vC02U for ; Sun, 22 May 2016 11:30:51 -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 DF74A12D1EC for ; Sun, 22 May 2016 11:30:50 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id c127so35876834ywb.1 for ; Sun, 22 May 2016 11:30:50 -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=Hp7vqeVu3zFOzFjc8HVHvOtFAlyDrRnFlvbZtkoKFYc=; b=asKMC0mzFmjqHP/oGzAZ5SJf5wNF0FoWMp16KO6nDNo4TmYLhtMKrbAl3JCc/ZT3U2 wje5t2l0wpDFehSxBZw6IupbaSgWaAsj9HIUaupIvksmPx2LnuKdnnmlHRlc/d38Rp5Y OtYfjNH4f+mNWuehC4IoOidGJBTarxrn+W3INSj75A5ralg+Gmq07K/x3e5/EgAyBHVj CXunL6S36KHQYA1I0Dd9LaFhDzhpJR/n2qx5w+KO7Fb5EpVxhLbF6jBskEvVZMtTQpCL MuVDsI09htLecEcxt2S16mLPfq8i8Z5HwyL5OKVpSSLqSUrOkx4gQ5a5WqbeAX2Lz3MQ wgFA== 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=Hp7vqeVu3zFOzFjc8HVHvOtFAlyDrRnFlvbZtkoKFYc=; b=Q5/vJDXydwRxp90Z5t5g13okZuTW3D0iJAowemXvbHBYsoPrBpo/rRQxvAq+ZQPSYE 6JGWm9uTzqF1H5uJ+JQh5zVwHUkzezNUKMqdNKsBswicz+rH2fKJli8okuS5N4OddlnH zLtYOoArDNE3eYEb4mhNqGbd4BsJKugL6A6lC8Lp6e3CiecV7gbDtJdxQ+YlcdSKtENc d/9+p2f1a+RZpKm+rNUnuT+Ewb6afFANScmcq5cOD13Dprk6pB5o7MhvgiFEAGKd0Co1 i7IYgkEx3HqQnKKp3dGSGgYAG3VmvLsqN5AcAxOiOd83pT65kMEoqdJjHBBBhhB7AkRz Ugbw== X-Gm-Message-State: AOPr4FXMHA8abT+/6iI+qW67RDLUie7HLLuPP5brDszD4tGMyCb+5GhN5lFa+v1hSUNxK3dEPA5o3Nf5fGDPHQ== X-Received: by 10.13.237.1 with SMTP id w1mr7256956ywe.62.1463941850119; Sun, 22 May 2016 11:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 11:30:10 -0700 (PDT) In-Reply-To: <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 22 May 2016 11:30:10 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0864a8f2f6920533728588 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 18:30:52 -0000 --94eb2c0864a8f2f6920533728588 Content-Type: text/plain; charset=UTF-8 On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > Looking at PR #468: > > > - It isn't at all obvious how to use it for stateless rejection. > > > - It is even less obvious how to recover (not causing non-retryable > > > fault) from bad cookie (e.g. expired) remembered from previous > > > connection. > > > > > > There are some tricks for both, but with latter, the 255-byte > > > cookie space can become quite cramped... > > > > > > > I'll make the space biggeer. > > Not having to deal with cross-connection cookies makes things > easier, but... > > Actually, looking at it, I didn't find how EDI context is > determined. And EDI context needs to be fit into cookies because > it isn't retransmitted on 2nd CH. > I don't understand what you're saying here. Here is my claim: 1. The second ClientHello doesn't come with EDI. 2. The Cookie (if used for this) needs to contain the entire hash state, which means it includes the ClientHello w/ EDI transitively. 3. Therefore you can recover the hash state no matter how much the client changes the ClientHello (though we forbid a lot of changes) If I'm wrong here, would definitely like to know. Can you explain? > Also while looking at 0-RTT: > > It occured to me how to determine the ciphersuite used for 0-RTT. > Then it occured to me that the symmetric parts are determined by the > provisioned context and asymmetric parts don't matter. But I think > this is quite non-obvious. > "All of the parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) MUST be those which were negotiated in the connection which established the PSK. " Would be happy to have clarifications. And clock errors being small outside of gross corrections? Clock > first-order errors can be pretty large with unsynchronized clocks > (I have personally seen FO errors on order of 1s per day on some > bit bad piece of kit), and those would absolutely show up as errors > in ticket age. And if you have synchronized clock, the zeroth-order > errors (wrong time) will be small too (can be <10ms). And have fun > with leap seconds. :-) Yes. Those people basically won't be able to use 0-RTT. > > > Is the ticket allowed to outlive certificate orginally used in > provisioning it (possibly indirectly, with ticket being provisoned > from connection using ticket)? > This has never been something TLS has taken a position on. Also, the extension negotiation matching stuff with 0-RTT talking > about padding? Padding just plain can't be negotiated. And "negotiated > in ServerHello"? None of the extensions that can presently be > negotiated there are any of any interest with 0-RTT. To me the text > looks really confused. > I'll take a look at it, but PRs welcome. Right now I have an open issue marker, -Ekr > > > -Ilari > --94eb2c0864a8f2f6920533728588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On S= un, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote:
> On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > Looking at PR #468:
> > - It isn't at all obvious how to use it for stateless rejecti= on.
> > - It is even less obvious how to recover (not causing non-retryab= le
> >=C2=A0 =C2=A0fault) from bad cookie (e.g. expired) remembered from= previous
> >=C2=A0 =C2=A0connection.
> >
> > There are some tricks for both, but with latter, the 255-byte
> > cookie space can become quite cramped...
> >
>
> I'll make the space biggeer.

Not having to deal with cross-connection cookies makes things
easier, but...

Actually, looking at it, I didn't find how EDI context is
determined. And EDI context needs to be fit into cookies because
it isn't retransmitted on 2nd CH.

I= don't understand what you're saying here. Here is my claim:

1. The second ClientHello doesn't come with EDI.=
2. The Cookie (if used for this) needs to contain the entire has= h
=C2=A0 =C2=A0 state, which means it includes the ClientHello w/= EDI transitively.
3. Therefore you can recover the hash state no= matter how much
=C2=A0 =C2=A0 the client changes the ClientHello= (though we forbid a lot of
=C2=A0 =C2=A0 changes)

=
If I'm wrong here, would definitely like to know. Can you ex= plain?

=C2=A0
Also while looking at 0-RTT:

It occured to me how to determine the ciphersuite used for 0-RTT.
Then it occured to me that the symmetric parts are determined by the
provisioned context and asymmetric parts don't matter. But I think
this is quite non-obvious.

"All of= the parameters for the 0-RTT data (symmetric cipher suite,
ALPN,= etc.) MUST be those which were negotiated in the connection
whic= h established the PSK.=C2=A0"

Would be happy = to have clarifications.


And clock errors being small outside of gross corrections? Clock
first-order errors can be pretty large with unsynchronized clocks
(I have personally seen FO errors on order of 1s per day on some
bit bad piece of kit), and those would absolutely show up as errors
in ticket age. And if you have synchronized clock, the zeroth-order
errors (wrong time) will be small too (can be <10ms). And have fun
with leap seconds. :-)

Yes. Those people ba= sically won't be able to use 0-RTT.
=C2=A0
=C2=A0

Is the ticket allowed to outlive certificate orginally used in
provisioning it (possibly indirectly, with ticket being provisoned
from connection using ticket)?

This has= never been something TLS has taken a position on.



Also, the extension negotiation matching stuff with 0-RTT talking
about padding? Padding just plain can't be negotiated. And "negoti= ated
in ServerHello"? None of the extensions that can presently be
negotiated there are any of any interest with 0-RTT. To me the text
looks really confused.

I'll take a = look at it, but PRs welcome. Right now I have an open issue marker,

-Ekr




-Ilari

--94eb2c0864a8f2f6920533728588-- From nobody Sun May 22 12:33: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 1A88112D577 for ; Sun, 22 May 2016 12:33:10 -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 fqE5kuK8gSW9 for ; Sun, 22 May 2016 12:33:08 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B8DD012D575 for ; Sun, 22 May 2016 12:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6010FD4AC; Sun, 22 May 2016 22:33: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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 5AfwsSY8dy3W; Sun, 22 May 2016 22:33:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D6FAF28F; Sun, 22 May 2016 22:33:05 +0300 (EEST) Date: Sun, 22 May 2016 22:33:02 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@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] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 19:33:10 -0000 On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara > wrote: > > > Actually, looking at it, I didn't find how EDI context is > > determined. And EDI context needs to be fit into cookies because > > it isn't retransmitted on 2nd CH. > > > > I don't understand what you're saying here. Here is my claim: > > 1. The second ClientHello doesn't come with EDI. > 2. The Cookie (if used for this) needs to contain the entire hash > state, which means it includes the ClientHello w/ EDI transitively. > 3. Therefore you can recover the hash state no matter how much > the client changes the ClientHello (though we forbid a lot of > changes) > > If I'm wrong here, would definitely like to know. Can you explain? That would require hash implementation supporting freezing/thawing (I have seen only one, and that used MD5), which is even more exotic than forking checkpointable hash implementations. Also, SHA-384 states are so big (the state at arbitrary point is 208 bytes!) that putting one into cookie leaves space VERY cramped (if all necressary things fit at all). > > Also while looking at 0-RTT: > > > > It occured to me how to determine the ciphersuite used for 0-RTT. > > Then it occured to me that the symmetric parts are determined by the > > provisioned context and asymmetric parts don't matter. But I think > > this is quite non-obvious. > > > > "All of the parameters for the 0-RTT data (symmetric cipher suite, > ALPN, etc.) MUST be those which were negotiated in the connection > which established the PSK. " > > Would be happy to have clarifications. I would phrase the thing as what various values are, not what they must be (there is no way negotiate those, which is good). > And clock errors being small outside of gross corrections? Clock > > first-order errors can be pretty large with unsynchronized clocks > > (I have personally seen FO errors on order of 1s per day on some > > bit bad piece of kit), and those would absolutely show up as errors > > in ticket age. And if you have synchronized clock, the zeroth-order > > errors (wrong time) will be small too (can be <10ms). And have fun > > with leap seconds. :-) > > > Yes. Those people basically won't be able to use 0-RTT. Even if ticket timestamp mismatch error has fallback in spec, will it actually fallback properly with real-world implementations? > > Is the ticket allowed to outlive certificate orginally used in > > provisioning it (possibly indirectly, with ticket being provisoned > > from connection using ticket)? > > > > This has never been something TLS has taken a position on. Ah, it only came up in conjunction with GDHE-PSK-CERT modes, where tickets can't outlast parent certificate (because it can't change). > Also, the extension negotiation matching stuff with 0-RTT talking > > about padding? Padding just plain can't be negotiated. And "negotiated > > in ServerHello"? None of the extensions that can presently be > > negotiated there are any of any interest with 0-RTT. To me the text > > looks really confused. > > I'll take a look at it, but PRs welcome. Right now I have an open issue > marker, Here is what I think should match (going through all currently known values and excetions): - Version - Ciphersuite Protection+PRF, key exchange in allowed values. - What to do with server_name??? - Status_request presence (but not contents)??? - Status_request_v2 presence (but not contents)??? - Signed_certificate_timestamp presence (but not contents)??? - ALP can not be negotiated by any means. - 0-RTT Protection+PRF+ALP can not be negotiated. (I think status_request and status_request_v2 should mirror whatever signed_certificate_timestamp does). Also, that server_name is just its own kind of mess, where what is the proper thing isn't at all obvious. And here is the list of extensions that are allowed to be negotiated with 0-RTT (parenthesis denotes extensions where things depend on exact handling discussed above). - (server_name) - max_framgment_length - (status_request) - supported_groups - use_srtp - heartbeat - (status_request_v2) - (signed_certificate_timestamp) - token_binding [I-D stage] - cached_info? - key_share - pre_shared_key - early_data (required for obvious reasons) (Note: application_layer_protocol_negotiation is not on this list, very much intentionally, since negotiation of ALP is not possible in presence of 0-RTT. Don't even try). -Ilari From nobody Sun May 22 12:45:08 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 5EA0012D1AF; Sun, 22 May 2016 12:45:04 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160522194504.723.15316.idtracker@ietfa.amsl.com> Date: Sun, 22 May 2016 12:45:04 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-13.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: Sun, 22 May 2016 19:45:04 -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-13.txt Pages : 119 Date : 2016-05-22 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol 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-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 22 12:46: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 94CE912D119 for ; Sun, 22 May 2016 12:46:02 -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 4OxmzQQQBOmm for ; Sun, 22 May 2016 12:46:01 -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 2C1A012D0F9 for ; Sun, 22 May 2016 12:46:01 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id h19so646366ywc.0 for ; Sun, 22 May 2016 12:46:01 -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=7LPUvYtwktK761n6eDo01AvEooTj+r+1bTZCdRUXeMU=; b=u741re9SXFeCnTQgmEsyyAmAjJFoKqI9fOUWUCcZthHBP+zKj8Tz3hIQNrHkrlkySf 9qSWNyvN/X68+21QKZB1nUqxx6FK35Aqzs6r0nIxDWH/GgiGx7IVNipnRyZxXfBlJuqN OsBzErDtXV0fXfdLjtAUy/2/Byj/5uzLJclNhCJgD1Z4eKUK97kxdOVQR8fr5cgb3L0t kyVFwaCoYpVHc318QFy/tPlAoY8xflw79foIs6L/Dxxb8BA2vW4e7IQEDRHqo8ClJkoZ mjZcL/yf8/+/SA6xzcbdO5TFGiHy439QrlOx65WSq5AaYxiGM5OmnsDuSige9Nc4G9JL 9Ysw== 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=7LPUvYtwktK761n6eDo01AvEooTj+r+1bTZCdRUXeMU=; b=hq30WDYa0WSvV2540KgDHVgWccGV1ZCxf8sKymkvDasOOmc8JM2aasHyo6CFJKtsvv Ki9l+/WLzIWaVaHkKI2xPURGQX1WLuQ51EaBPllhyAri68bIDyYtz+bLEdzBTZyZU26Q Rb+wMMMIM77g6N6dFUWVjKKJTlfyRYcEITR0NN3RN69SdjdsLUWOaP2b7vJVMPdsaRSm myt7WzBU81HqLmWL3pkTYKaMIe8ODfDfWyDJGT3HXTfUxqnQZfiA+QZd/a5qBLVilZFr e30VbB9qlyTO7dhvmWVQitSQHOGd/P9dMCBvAd7oe2EXzVr3Fbuao8vGv6v0WYtoQDQ2 p8tw== X-Gm-Message-State: ALyK8tLkUAhQvvTvMcuTzfLe4w8HBPdZ/CQ4YEMc5Pd6V8vnWm6LgWb+2pUrcjLjYGL5B23AYvJj49MJQTwf8w== X-Received: by 10.129.160.149 with SMTP id x143mr18933ywg.180.1463946360302; Sun, 22 May 2016 12:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 12:45:20 -0700 (PDT) From: Eric Rescorla Date: Sun, 22 May 2016 12:45:20 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07ee04c6da7505337392f9 Archived-At: Subject: [TLS] TLS 1.3 draft 13. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 19:46:02 -0000 --94eb2c07ee04c6da7505337392f9 Content-Type: text/plain; charset=UTF-8 Folks, I just uploaded draft-13. Changelog appended at the bottom of this message. The following nontrivial issues are outstanding: - How to encrypt post-handshake messages (post-handshake client auth, NewSessionTicket, etc.). I'm having a discussion now with the cryptographers about this. - Allowing multiple session tickets in NewSessionTicket (https://github.com/tlswg/tls13-spec/pull/466). I think this is OK but please take a look. - The rules for how closely extensions need to match in 0-RTT. I am starting to think that Ilari is right that the current "check everything for match" is too strict, so expect a new PR for this in the next few days. I want to resolve these this week and then publish -14 soon after. -Ekr Changes: - Allow server to send SupportedGroups. - Remove 0-RTT client authentication - Remove (EC)DHE 0-RTT. - Flesh out 0-RTT PSK mode and shrink EarlyDataIndiation - Turn PSK-resumption response into an index to save room - Move CertificateStatus to an extension - Extra fields in NewSessionTicket. - Restructure key schedule and add a resumption_context value. - Require DH public keys and secrets to be zero-padded to the size of the group. - Remove the redundant length fields in KeyShareEntry. - Define a cookie field for HRR. --94eb2c07ee04c6da7505337392f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I just uploaded draft= -13. Changelog appended at the bottom of this
message.
=
The following nontrivial issues are outstanding:
<= br>
- How to encrypt post-handshake messages (post-handshake clie= nt auth,
=C2=A0 NewSessionTicket, etc.). I'm having a discuss= ion now with the
=C2=A0 cryptographers about this.
=C2= =A0=C2=A0
- Allowing multiple session tickets in NewSessionTicket=
=C2=A0 (https://github.com/tlswg/tls13-spec/pull/466). I think this is OK
=C2=A0 but please take a look.

- The rules f= or how closely extensions need to match in 0-RTT. I am
=C2=A0 sta= rting to think that Ilari is right that the current "check
= =C2=A0 everything for match" is too strict, so expect a new PR for thi= s
=C2=A0 in the next few days.

I want to= resolve these this week and then publish -14 soon after.

-Ekr

Changes:
- Allow server to = send SupportedGroups.

- Remove 0-RTT client authen= tication

- Remove (EC)DHE 0-RTT.

- Flesh out 0-RTT PSK mode and shrink EarlyDataIndiation
=
- Turn PSK-resumption response into an index to save room

- Move CertificateStatus to an extension
<= br>
- Extra fields in NewSessionTicket.

= - Restructure key schedule and add a resumption_context value.
- Require DH public keys and secrets to be zero-padded to the = size
=C2=A0 of the group.

- Remove the r= edundant length fields in KeyShareEntry.

- Define = a cookie field for HRR.



<= div>




<= div>


--94eb2c07ee04c6da7505337392f9-- From nobody Sun May 22 12:51: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 3EFFC12D0F9 for ; Sun, 22 May 2016 12:51: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 PqDnYiXxvPZM for ; Sun, 22 May 2016 12:51:19 -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 E1D7712B051 for ; Sun, 22 May 2016 12:51:18 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id c127so36834580ywb.1 for ; Sun, 22 May 2016 12:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sOB+Mijjftgr4VelFn8Nw7V1YZJE2UHSr+8+fkPZXr4=; b=MpYZIYlC5Zsf4CMkSlaAOH6KlJ1D53A+lRYfNknH2CDl5vV/HLTB1Wl+84NfJh2LqN UGSNBrtaejydInDj3N5qUpbLlirCPwLtkgUL5aY44mIo1NnrTJbAZ2BizNvnNMgfYss+ jq9ovHtcQ9KrE72SQ3hW21j3FjVojUprngr96gNZFaHIpvQr8o+lhOJz+urnFkv3JFsg moL77+UFblHQsrezpY/YBlqY7eUC9tg7iehbFr3hFu5oZS8BMgz9NBlikgjGiFc8O53p XVVPF/4uXyqWWe7lr1S7kZ65iKNrVV4IYzYcF9xfhg1xUhEr7joTZVFoB5Vp7BagvVC4 eqyA== 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=sOB+Mijjftgr4VelFn8Nw7V1YZJE2UHSr+8+fkPZXr4=; b=PGPp4R/mMhAEyFTNDZHdtkQmiUomx2Rwf156oGVV9o5eAB4s8nW6u2RVPGCHFva9Za EodpW3MTbfRHXAagEnzzbDrehw1wROMkz5iKpQGJnj/hPgY5Vx1c5tOKYE1JfXRMwY2F 968iiqK0WUis4ng96ilLJiATXot/tiFlIwLsCWCgaG2i951UdQweI3/xttxqYFD+FktR kuvkVsd8daFb7AhpPW523UlLa9xlOBuwHXqBzE6FF/jOqaaahXzBRMW1awbtZrS3j+9R 36KcdbUyf/m/2VFZlQYnOiW3G4ezt83ayjYMA+kxjJzxlHfb5VteX7GvaCKkr/1YqtFP vOLQ== X-Gm-Message-State: AOPr4FVm9VxmHgYFwNB794EZKTqmw48/a8ClgcbsUHI+RmseA2YcnC8KALphQ4FIGiEGBA3PCfMp+X3BsE66pA== X-Received: by 10.13.233.1 with SMTP id s1mr7521887ywe.286.1463946678194; Sun, 22 May 2016 12:51:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 12:50:38 -0700 (PDT) In-Reply-To: <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 22 May 2016 12:50:38 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07cfb4b9862b053373a5ad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 19:51:21 -0000 --94eb2c07cfb4b9862b053373a5ad Content-Type: text/plain; charset=UTF-8 On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > Actually, looking at it, I didn't find how EDI context is > > > determined. And EDI context needs to be fit into cookies because > > > it isn't retransmitted on 2nd CH. > > > > > > > I don't understand what you're saying here. Here is my claim: > > > > 1. The second ClientHello doesn't come with EDI. > > 2. The Cookie (if used for this) needs to contain the entire hash > > state, which means it includes the ClientHello w/ EDI transitively. > > 3. Therefore you can recover the hash state no matter how much > > the client changes the ClientHello (though we forbid a lot of > > changes) > > > > If I'm wrong here, would definitely like to know. Can you explain? > > That would require hash implementation supporting freezing/thawing > (I have seen only one, and that used MD5), which is even more exotic > than forking checkpointable hash implementations. > This is a bit of an irritation, I agree. However, it's only required for stateless implementations, so not your average TLS stack. If you have a better suggestion, I'd love to have it, thought! Also, SHA-384 states are so big (the state at arbitrary point is 208 > bytes!) that putting one into cookie leaves space VERY cramped (if > all necressary things fit at all). > Good point. I just made the editor's copy have 2^16-1 thought it didn't make it into draft-13. > > Also while looking at 0-RTT: > > > > > > It occured to me how to determine the ciphersuite used for 0-RTT. > > > Then it occured to me that the symmetric parts are determined by the > > > provisioned context and asymmetric parts don't matter. But I think > > > this is quite non-obvious. > > > > > > > "All of the parameters for the 0-RTT data (symmetric cipher suite, > > ALPN, etc.) MUST be those which were negotiated in the connection > > which established the PSK. " > > > > Would be happy to have clarifications. > > I would phrase the thing as what various values are, not what they > must be (there is no way negotiate those, which is good). > > > And clock errors being small outside of gross corrections? Clock > > > first-order errors can be pretty large with unsynchronized clocks > > > (I have personally seen FO errors on order of 1s per day on some > > > bit bad piece of kit), and those would absolutely show up as errors > > > in ticket age. And if you have synchronized clock, the zeroth-order > > > errors (wrong time) will be small too (can be <10ms). And have fun > > > with leap seconds. :-) > > > > > > Yes. Those people basically won't be able to use 0-RTT. > > Even if ticket timestamp mismatch error has fallback in spec, will it > actually fallback properly with real-world implementations? > I hope so. We plan to test it. > > Also, the extension negotiation matching stuff with 0-RTT talking > > > about padding? Padding just plain can't be negotiated. And "negotiated > > > in ServerHello"? None of the extensions that can presently be > > > negotiated there are any of any interest with 0-RTT. To me the text > > > looks really confused. > > > > I'll take a look at it, but PRs welcome. Right now I have an open issue > > marker, > > Here is what I think should match (going through all currently known > values and excetions): > Thanks for this. Ill try to work up a PR from the below. Best, -Ekr > > - Version > - Ciphersuite Protection+PRF, key exchange in allowed values. > - What to do with server_name??? > - Status_request presence (but not contents)??? > - Status_request_v2 presence (but not contents)??? > - Signed_certificate_timestamp presence (but not contents)??? > - ALP can not be negotiated by any means. > - 0-RTT Protection+PRF+ALP can not be negotiated. > > (I think status_request and status_request_v2 should mirror whatever > signed_certificate_timestamp does). > > Also, that server_name is just its own kind of mess, where what is > the proper thing isn't at all obvious. > > > And here is the list of extensions that are allowed to be negotiated > with 0-RTT (parenthesis denotes extensions where things depend on exact > handling discussed above). > > - (server_name) > - max_framgment_length > - (status_request) > - supported_groups > - use_srtp > - heartbeat > - (status_request_v2) > - (signed_certificate_timestamp) > - token_binding [I-D stage] > - cached_info? > - key_share > - pre_shared_key > - early_data (required for obvious reasons) > > > (Note: application_layer_protocol_negotiation is not on this list, > very much intentionally, since negotiation of ALP is not possible > in presence of 0-RTT. Don't even try). > > > > -Ilari > --94eb2c07cfb4b9862b053373a5ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > Actually, looking at it, I didn't fin= d how EDI context is
> > determined. And EDI context needs to be fit into cookies because<= br> > > it isn't retransmitted on 2nd CH.
> >
>
> I don't understand what you're saying here. Here is my claim:<= br> >
> 1. The second ClientHello doesn't come with EDI.
> 2. The Cookie (if used for this) needs to contain the entire hash
>=C2=A0 =C2=A0 =C2=A0state, which means it includes the ClientHello w/ E= DI transitively.
> 3. Therefore you can recover the hash state no matter how much
>=C2=A0 =C2=A0 =C2=A0the client changes the ClientHello (though we forbi= d a lot of
>=C2=A0 =C2=A0 =C2=A0changes)
>
> If I'm wrong here, would definitely like to know. Can you explain?=

That would require hash implementation supporting freezing/thawing (I have seen only one, and that used MD5), which is even more exotic
than forking checkpointable hash implementations.
=C2= =A0
This is a bit of an irritation, I agree. However, it's on= ly required for
stateless implementations, so not your average TL= S stack. If you
have a better suggestion, I'd love to have it= , thought!


> > Also while looking at 0-RTT:
> >
> > It occured to me how to determine the ciphersuite used for 0-RTT.=
> > Then it occured to me that the symmetric parts are determined by = the
> > provisioned context and asymmetric parts don't matter. But I = think
> > this is quite non-obvious.
> >
>
> "All of the parameters for the 0-RTT data (symmetric cipher suite= ,
> ALPN, etc.) MUST be those which were negotiated in the connection
> which established the PSK. "
>
> Would be happy to have clarifications.

I would phrase the thing as what various values are, not what they must be (there is no way negotiate those, which is good).

> And clock errors being small outside of gross corrections? Clock
> > first-order errors can be pretty large with unsynchronized clocks=
> > (I have personally seen FO errors on order of 1s per day on some<= br> > > bit bad piece of kit), and those would absolutely show up as erro= rs
> > in ticket age. And if you have synchronized clock, the zeroth-ord= er
> > errors (wrong time) will be small too (can be <10ms). And have= fun
> > with leap seconds. :-)
>
>
> Yes. Those people basically won't be able to use 0-RTT.

Even if ticket timestamp mismatch error has fallback in spec, will i= t
actually fallback properly with real-world implementations?

I hope so. We plan to test it.

=C2=A0
> Also, th= e extension negotiation matching stuff with 0-RTT talking
> > about padding? Padding just plain can't be negotiated. And &q= uot;negotiated
> > in ServerHello"? None of the extensions that can presently b= e
> > negotiated there are any of any interest with 0-RTT. To me the te= xt
> > looks really confused.
>
> I'll take a look at it, but PRs welcome. Right now I have an open = issue
> marker,

Here is what I think should match (going through all currently known=
values and excetions):

Thanks for this.= Ill try to work up a PR from the below.

Best,
-Ekr
=C2=A0

- Version
- Ciphersuite Protection+PRF, key exchange in allowed values.
- What to do with server_name???
- Status_request presence (but not contents)???
- Status_request_v2 presence (but not contents)???
- Signed_certificate_timestamp presence (but not contents)???
- ALP can not be negotiated by any means.
- 0-RTT Protection+PRF+ALP can not be negotiated.

(I think status_request and status_request_v2 should mirror whatever
signed_certificate_timestamp does).

Also, that server_name is just its own kind of mess, where what is
the proper thing isn't at all obvious.


And here is the list of extensions that are allowed to be negotiated
with 0-RTT (parenthesis denotes extensions where things depend on exact
handling discussed above).

- (server_name)
- max_framgment_length
- (status_request)
- supported_groups
- use_srtp
- heartbeat
- (status_request_v2)
- (signed_certificate_timestamp)
- token_binding [I-D stage]
- cached_info?
- key_share
- pre_shared_key
- early_data (required for obvious reasons)


(Note: application_layer_protocol_negotiation is not on this list,
very much intentionally, since negotiation of ALP is not possible
in presence of 0-RTT. Don't even try).



-Ilari

--94eb2c07cfb4b9862b053373a5ad-- From nobody Sun May 22 13:48: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 D032212D5A6 for ; Sun, 22 May 2016 13:48:29 -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 ELwNeKMlwsX0 for ; Sun, 22 May 2016 13:48: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 E9CC912D5A2 for ; Sun, 22 May 2016 13:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5A808E054; Sun, 22 May 2016 23:48:26 +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 7erhbaROgHSM; Sun, 22 May 2016 23:48:26 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 0CB1F28C; Sun, 22 May 2016 23:48:26 +0300 (EEST) Date: Sun, 22 May 2016 23:48:23 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160522204823.GC17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> <20160522193302.GB17811@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] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 20:48:30 -0000 On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara > wrote: > > > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara < > > ilariliusvaara@welho.com> > > > wrote: > > > > > > > Actually, looking at it, I didn't find how EDI context is > > > > determined. And EDI context needs to be fit into cookies because > > > > it isn't retransmitted on 2nd CH. > > > > > > > > > > I don't understand what you're saying here. Here is my claim: > > > > > > 1. The second ClientHello doesn't come with EDI. > > > 2. The Cookie (if used for this) needs to contain the entire hash > > > state, which means it includes the ClientHello w/ EDI transitively. > > > 3. Therefore you can recover the hash state no matter how much > > > the client changes the ClientHello (though we forbid a lot of > > > changes) > > > > > > If I'm wrong here, would definitely like to know. Can you explain? > > > > That would require hash implementation supporting freezing/thawing > > (I have seen only one, and that used MD5), which is even more exotic > > than forking checkpointable hash implementations. > > > > This is a bit of an irritation, I agree. However, it's only required for > stateless implementations, so not your average TLS stack. If you > have a better suggestion, I'd love to have it, thought! Well, if you didn't have to deal with possibly overly large contexts, you could just reconstruct the 1st ClientHello and HelloRetryRequest. (Reconstruction is even easier without having to worry about cross- handshake cookies). -Ilari From nobody Sun May 22 14:31: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 52BBF12B013 for ; Sun, 22 May 2016 14:31:39 -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 ytKtqaiUJr3l for ; Sun, 22 May 2016 14:31:36 -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 EB28312D5AF for ; Sun, 22 May 2016 14:31:35 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id c127so38011949ywb.1 for ; Sun, 22 May 2016 14:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wnNQm+Sdf7sI0618o1z97VfEtNY/OIAVUKzu+EYk+hg=; b=AD5R7D7i4aZQi31sKgF0oO3XXdeIfopgutK+yYGpFh1SDL6IaUhlcvBeZa8CCQskgi t52+i3jzFD6bmgNSxQQZjs1jPGZn5Upjjl4sleSfEsdBQjNOS3gtN27K20Y+YHE4YoCd uzD2Iih8iZLqCrv4/A5ofrPhvJc/e25r+H2muaVxTMMPi9IFbgpcWfOO/e8j/KfbEiYF Lh4qrijhFKPlD84m097uUpdOg9zCuGpsDutKYyYhcbz2de0V6hCHufS+XGgo0j2v5YXP 2ZYakVl9CVAJQCdABkMPbopW9by7Hr8/PoCDhOtaXCsfk4C7IgRQknoDsBPFFDvJ6oQy yr7w== 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=wnNQm+Sdf7sI0618o1z97VfEtNY/OIAVUKzu+EYk+hg=; b=S0Rx9UBpViPq9MrCMmkLCDFG1AWT3yT98x97shgXwhtJtac5CL4rr8EkaQTMZwJ18t PyB34B4IsZpMGBP7VD43jEQJJCeZnpT+j87din9+bj9KFpv1VkILshObMtpardQCez9W y2zSnfvVQH7Baf9lUQOZRoApqT6/50L646e0gp04Xdt8HrB0siH3sao4ZEjDhwjQs6Ps rhd2q+s6OOZtwkFlqK01dwGojR+uiyHTwosJR5Nn77CCBDgq3YlHccGp7Z3Vhh9VgW7e 9aF527mQc3qUJGlTu2ScZend/+hhwlZbtpjwE3o49vvDs2cLpThwHwWooMJ+JWyzMYnf mhvQ== X-Gm-Message-State: AOPr4FUvo8y7PhNCKA3w54HL97efjd+EvOVa0fgw/N3PyEpE82oIIIlHCj/dHGpojFYEyaajcovwlvRphtA25A== X-Received: by 10.13.233.1 with SMTP id s1mr7702147ywe.286.1463952695179; Sun, 22 May 2016 14:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 14:30:55 -0700 (PDT) In-Reply-To: <20160522204823.GC17811@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi> <20160522204823.GC17811@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 22 May 2016 14:30:55 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07cfb45d6fdc0533750cfc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 May 2016 21:31:39 -0000 --94eb2c07cfb45d6fdc0533750cfc Content-Type: text/plain; charset=UTF-8 On Sun, May 22, 2016 at 1:48 PM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara < > > > ilariliusvaara@welho.com> > > > > wrote: > > > > > > > > > Actually, looking at it, I didn't find how EDI context is > > > > > determined. And EDI context needs to be fit into cookies because > > > > > it isn't retransmitted on 2nd CH. > > > > > > > > > > > > > I don't understand what you're saying here. Here is my claim: > > > > > > > > 1. The second ClientHello doesn't come with EDI. > > > > 2. The Cookie (if used for this) needs to contain the entire hash > > > > state, which means it includes the ClientHello w/ EDI > transitively. > > > > 3. Therefore you can recover the hash state no matter how much > > > > the client changes the ClientHello (though we forbid a lot of > > > > changes) > > > > > > > > If I'm wrong here, would definitely like to know. Can you explain? > > > > > > That would require hash implementation supporting freezing/thawing > > > (I have seen only one, and that used MD5), which is even more exotic > > > than forking checkpointable hash implementations. > > > > > > > This is a bit of an irritation, I agree. However, it's only required for > > stateless implementations, so not your average TLS stack. If you > > have a better suggestion, I'd love to have it, thought! > > Well, if you didn't have to deal with possibly overly large contexts, > you could just reconstruct the 1st ClientHello and HelloRetryRequest. > > (Reconstruction is even easier without having to worry about cross- > handshake cookies). > They're gone! -Ekr > > > -Ilari > --94eb2c07cfb45d6fdc0533750cfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 22, 2016 at 1:48 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.= com>
> > > wrote:
> > >
> > > > Actually, looking at it, I didn't find how EDI cont= ext is
> > > > determined. And EDI context needs to be fit into cookie= s because
> > > > it isn't retransmitted on 2nd CH.
> > > >
> > >
> > > I don't understand what you're saying here. Here is = my claim:
> > >
> > > 1. The second ClientHello doesn't come with EDI.
> > > 2. The Cookie (if used for this) needs to contain the entire= hash
> > >=C2=A0 =C2=A0 =C2=A0state, which means it includes the Client= Hello w/ EDI transitively.
> > > 3. Therefore you can recover the hash state no matter how mu= ch
> > >=C2=A0 =C2=A0 =C2=A0the client changes the ClientHello (thoug= h we forbid a lot of
> > >=C2=A0 =C2=A0 =C2=A0changes)
> > >
> > > If I'm wrong here, would definitely like to know. Can yo= u explain?
> >
> > That would require hash implementation supporting freezing/thawin= g
> > (I have seen only one, and that used MD5), which is even more exo= tic
> > than forking checkpointable hash implementations.
> >
>
> This is a bit of an irritation, I agree. However, it's only requir= ed for
> stateless implementations, so not your average TLS stack. If you
> have a better suggestion, I'd love to have it, thought!

Well, if you didn't have to deal with possibly overly large cont= exts,
you could just reconstruct the 1st ClientHello and HelloRetryRequest.

(Reconstruction is even easier without having to worry about cross-
handshake cookies).

They're gone!

-Ekr
=C2=A0


-Ilari

--94eb2c07cfb45d6fdc0533750cfc-- From nobody Mon May 23 09:25: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 5CAFA12D810 for ; Mon, 23 May 2016 09:25: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 ivwc9gCxNrR0 for ; Mon, 23 May 2016 09:25:32 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id D23C712D9B4 for ; Mon, 23 May 2016 09:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id ED87B8009; Mon, 23 May 2016 19:25: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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id MhAMuqJsJ3fI; Mon, 23 May 2016 19:25:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BA090287; Mon, 23 May 2016 19:25:29 +0300 (EEST) Date: Mon, 23 May 2016 19:25:26 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160523162526.GA22373@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160522193302.GB17811@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] =?utf-8?q?PR_=C2=A4468=3A_Cookie_for_hrr?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:25:34 -0000 On Sun, May 22, 2016 at 10:33:02PM +0300, Ilari Liusvaara wrote: > Here is what I think should match (going through all currently known > values and excetions): > > - Version > - Ciphersuite Protection+PRF, key exchange in allowed values. > - What to do with server_name??? > - Status_request presence (but not contents)??? > - Status_request_v2 presence (but not contents)??? > - Signed_certificate_timestamp presence (but not contents)??? > - ALP can not be negotiated by any means. > - 0-RTT Protection+PRF+ALP can not be negotiated. > > (I think status_request and status_request_v2 should mirror whatever > signed_certificate_timestamp does). Thinking about it some more, including status_request/status_request_v2/ signed_certificate_timestamp is only useful if one wants to tie the ticket lifetime to parent certificate lifetime. Also, list of things saved for 0-RTT-capable context would be useful. I presume: - The context name - The PSK key - The PSK context - Timestamp - Expiry time (not needed for 0-RTT) - On server side: RTT estimate - Allowed key exchanges - Negotiated protection - Negotiated PRF - Negotiated ALP (negotiated via any means, or absence thereof) - (Implementation-defined peer identity, not needed for 0-RTT) - (Implementation-defined self identity, not needed for 0-RTT) - What to do with server_name??? (On server side, one can save the rest encrypted into context name). Also, how is the context in EDI defined? I couldn't find clear answer, and I preseume it is a replay detector for 0-RTT (Client- Random already is a preturbator, and could also be used for replay detection). But such thing could be much shorter than maximum of 255 bytes... -Ilari From nobody Mon May 23 09:34:17 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 EB21312DA05; Mon, 23 May 2016 09:34:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523163413.20947.52104.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:34:13 -0700 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-falsestart@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [TLS] Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.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, 23 May 2016 16:34:14 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) False Start' (draft-ietf-tls-falsestart-02.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ 1. Summary "False Start†was an attempt to reduce the latency impact of HTTPS based on the simple premise that the client send application data earlier in the handshake; to be precise clients send application data before they have received and verified the server's "Finished†message. Initial measurements showed a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the implications at the end of s2. Note that this “experiment†was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some additional details: - Chrome 20 disable it except for sites that enabled NPN. - Firefox has (or at some point had) an NPN requirement to enable False Start. - Safari as an additional example without the NPN requirement: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslTransport.c - While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official release. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Stephen Farrell is the responsible Area Director. 2. Review and Consensus There wasn’t a whole lot of discussion, primarily because "False Start†the implementation issues were worked out by the browsers and the WG didn’t adopt this draft until long after (Nov-2014). The draft was adopted because it documents existing practices and provides security considerations [0]; the comments in the WG adoption thread were incorporated in the -01 WG version. The WG’s deliberations resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3). One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade protections defined in [1] are in adequate. To solve address this issue, the “False Start†draft requires whitelists as well as large groups/curves. [0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0 [1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ RFC Editor Note Please change the intended status in the header to "Informational" I don't believe any other text changes are needed. (The IESG and authors figured that informational was better during IESG eval.) From nobody Tue May 24 08:20: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 35B9312D8BE for ; Tue, 24 May 2016 08:20:27 -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 c0R5i22Wj9I7 for ; Tue, 24 May 2016 08:20:20 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0097.outbound.protection.outlook.com [23.103.201.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F325012D8B4 for ; Tue, 24 May 2016 08:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4rPpe76OhIcJpAvcht6ShoIzeJwn1NqiXCOmkgwCG+o=; b=IlWnXJkeSYdQ0GQk4AmOakGq95C1OxL1dPEkVOsjkC5Q2uNnO8S/pp+LW2piJ33q7uxllhfA4zpj5jPjITiIK3M4al+mtHILfUQ9uy4BT4lCCMcKRdgoueNH2mW6kFchLtcjmOaGYjaJpWqKHxZhQPWOSywN2Cbd00hN/IM/+2Y= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 15:20:18 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 24 May 2016 15:20:18 +0000 From: "Dang, Quynh (Fed)" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: Comments on nonce construction and cipher text size restriction. Thread-Index: AQHRtc/HWUjUunA/c0agQBPElmd3kA== Date: Tue, 24 May 2016 15:20:17 +0000 Message-ID: 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: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.109.185] x-ms-office365-filtering-correlation-id: 53a68397-2c9e-4b4b-93c8-08d383e6ea3e x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:AQzxylsnMVIM+9LBrefMe2WkkAECgfBrlOOnlOcSmXJMDloVbGieQ3+fTFteSDnmPVmZvzSlAjxHV2sP9+oTaTFF42Y6pKl1tijilNQicwt37EU5XQSjUufkeIqPsm7tqn68NfF2eYhEbfmFf6v/lw==; 24:K2DR3tH8VPx0PGybWGfeaceUqVl4rDFoeQj4Pd2E1G0LlABOMkbTLQz4k+3Wd3TBRHYXeBBxSjXlhJgfx/SaqrEOz/s/FsyFJHY+zDVBMiY=; 7:EhF3fhWH8I6/8RsIzoGozQPM0DmVc/LJ6N5CERx/kppN0HcQr4TflG5YukBy+g7SYx5SU2sYlGY7eB/9VYI3IZwcVwMuBuiXekS9M+RV6pTI9na8obedUB3DB+ieRsLpj5azD0ShPY7cSetXVbouAPJ4lIDZoUfLohcuOVPoqyEg4oBuCtDk+CQAaSQQLVnC x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(83506001)(102836003)(6116002)(10400500002)(2900100001)(3280700002)(5001770100001)(3660700001)(3846002)(5002640100001)(5004730100002)(586003)(8676002)(107886002)(122556002)(189998001)(54356999)(229853001)(2906002)(4001350100001)(5008740100001)(92566002)(1220700001)(8936002)(11100500001)(81166006)(36756003)(106116001)(99286002)(2501003)(77096005)(86362001)(16236675004)(87936001)(50986999)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D369E95C267A5qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 15:20:17.8651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 15:20:27 -0000 --_000_D369E95C267A5qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, 1. For this text: "plus the length of the output of the signing algorithm.= " in the last paragraph of Section 4.8.1, did you mean "plus the output of= the signing algorithm." ? 2. "The length (in bytes) of the following TLSCiphertext.fragment. The leng= th MUST NOT exceed 2^14 + 256. An endpoint that receives a record that exce= eds this length MUST generate a fatal "record_overflow" alert. " . There co= uld be a cipher that generates ciphertext longer than plaintext in some cas= es plus the tag. If the tag was 256 bits, then this requirement would disal= low that cipher unnecessarily when a record size is 2^14. 3. "The padded sequence number is XORed with the static client_write_iv or = server_write_iv, depending on the role." I think the ivs are not needed. 4. The current way nonce is specified would disallow ciphers that use any o= ther ways of generating the nonce such as random nonces. Regards, Quynh. --_000_D369E95C267A5qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Eric, 

<= font color=3D"#222222">1. For this text:  "plus the length of the output of the signing algorithm. " in the last paragraph of Section 4.8.1, did yo= u mean "plus the output of the signing algorithm.” ?=

2. "The le= ngth (in bytes) of the following TLSCiphertext.fragment. = The length MUST NOT exceed 2^14 + 256. An endpoint that receives "record_overflow" alert. " . There could be a cipher that generates ciphert= ext longer than plaintext in some cases plus the tag. If the tag was 256 bi= ts, then this requirement would disallow that cipher unnecessarily when a r= ecord size is 2^14. 

3. "The pa= dded sequence number is XORed with the static client_write_iv or server_write_iv, depending on the role.” I think the ivs are= not needed. 


<=
font face=3D"Times">4. The current way non=
ce is specified would disallow ciphers that use any other ways of generatin=
g the nonce such as random nonces.
<=
br>
<=
font face=3D"Times">


<=
font face=3D"Times">Regards,=



<=
font face=3D"Times">Quynh. <=
/pre>

<=
font face=3D"Times">


<=
font face=3D"Times">
--_000_D369E95C267A5qdangnistgov_-- From nobody Tue May 24 09:13: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 A8FDA12D7A8 for ; Tue, 24 May 2016 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1mBHr3M_V3D for ; Tue, 24 May 2016 09:13:48 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4D512D14C for ; Tue, 24 May 2016 09:13:48 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id fh2so13500296igd.1 for ; Tue, 24 May 2016 09:13:48 -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:content-transfer-encoding; bh=3AeesWy2FSulBQ4IwTSlclaq5AmthoRt+0yhiwF+TyY=; b=cH/gHZt6dEUta4VYhmJrXcBBy31sRXSWGM0S9cEKOcEbRCTEi0/E0Quu37ininGX9h omkG6BK5qyElVQJHfs1ZwUHYF0r77QkQ5JWtPaAcje0bGtjgouyyRaYgOK+/v4GThFjV ZSKrXpCsq58LsspBx/y7j4esfRcWFWJd8+4MllPGUD47kuIS4vEXbxIadxnIWPA2ivBz BMtBNLJuiq+AK/VvOUJZbVRQbJZ1+5IJXLSPw1BTeGpX+aHBzyT2i/5OXqecToz4qitl AVY5UaydxxSxbXzZJ4Opl6feDZgMS22KhRoIGpD2+0m0NPlwHZGIikD/TnBuslVlFVeo bwWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=3AeesWy2FSulBQ4IwTSlclaq5AmthoRt+0yhiwF+TyY=; b=OF2Z/8LhMKGfBMQVNveWvglfLOZeKnPRyi6D3Gktk3RqHEz0RGQ0ZR/2h8UhzySPbG NgffGOb2IbJh0QAW5I/bYX60ikF61dbX5tEX38uzh3JnGukOaocQi4pV7mhDb7lz34Lv lg5A0tz5CqZKej2ENQ+mbb2qC2Ez+k2O8hQj8OTCCvb5IcimwJAJoppV/BkxpbxRjMQW h9ql6wSg3zWaFx3Os8cWDYlMTr4amxl+YErJavL2mnSNDVeYWOGMhaTRdm2262Xh3n+o DWGkLUoVuUVpwA1GP96VZXkz1VD+/1/DB03XmNpETNMVg7vvYDs9uLKr7HHXsgleZDw4 THEw== X-Gm-Message-State: AOPr4FVUh7JaZFIdGBKyTf4x6O2ibRwxgt47NwGxd4w6YCn4r4HhmItutXlvZ763TCwWcHUVtIbvGTqLUtkbMg== MIME-Version: 1.0 X-Received: by 10.50.122.68 with SMTP id lq4mr18961864igb.77.1464106425941; Tue, 24 May 2016 09:13:45 -0700 (PDT) Received: by 10.36.43.23 with HTTP; Tue, 24 May 2016 09:13:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 09:13:45 -0700 Message-ID: From: Martin Thomson To: "Dang, Quynh (Fed)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 16:13:50 -0000 On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote: > 1. For this text: "plus the length of the output of the signing algorith= m. > " in the last paragraph of Section 4.8.1, did you mean "plus the output o= f > the signing algorithm.=E2=80=9D ? The text is correct. It is talking about the length of the structure, not its contents. > 2. "The length (in bytes) of the following TLSCiphertext.fragment. The > length MUST NOT exceed 2^14 + 256. An endpoint that receives a record tha= t > exceeds this length MUST generate a fatal "record_overflow" alert. " . Th= ere > could be a cipher that generates ciphertext longer than plaintext in some > cases plus the tag. If the tag was 256 bits, then this requirement would > disallow that cipher unnecessarily when a record size is 2^14. The value 256 is octets, not bits. If you are aware of a need for an authentication tag longer than 256 octets, now would be a great time to tell all of us. > 3. "The padded sequence number is XORed with the static client_write_iv o= r > server_write_iv, depending on the role.=E2=80=9D I think the ivs are not = needed. We discussed this at quite some length. I originally took your position, but the IVs add an extra layer of safety at very little cost. From nobody Tue May 24 09:58: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 087A312D8F6 for ; Tue, 24 May 2016 09:58:55 -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 NP_SwZrmv8gB for ; Tue, 24 May 2016 09:58: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 47C6D12D147 for ; Tue, 24 May 2016 09:58:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C876D86AA; Tue, 24 May 2016 19:58:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id qXDDLEVg6i4H; Tue, 24 May 2016 19:58:48 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7BBCA2310; Tue, 24 May 2016 19:58:48 +0300 (EEST) Date: Tue, 24 May 2016 19:58:45 +0300 From: Ilari Liusvaara To: "Dang, Quynh (Fed)" Message-ID: <20160524165845.GB23887@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] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 16:58:55 -0000 On Tue, May 24, 2016 at 03:20:17PM +0000, Dang, Quynh (Fed) wrote: > Hi Eric, > > 1. For this text: "plus the length of the output of the signing > algorithm. " in the last paragraph of Section 4.8.1, did you mean > "plus the output of the signing algorithm." ? The paragraph seems to talk about the length, so plus length of seems correct. > 2. "The length (in bytes) of the following TLSCiphertext.fragment. > 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. " . There could be a cipher that generates ciphertext longer > than plaintext in some cases plus the tag. If the tag was 256 bits, > then this requirement would disallow that cipher unnecessarily when > a record size is 2^14. It is not in bits, it is in bytes. So to blow the limit, you would need cipher that expands the plaintext by 256 bytes (remember the typebyte counts as plaintext input here). And what algorithm would have >2040 bits of expansion? Variable-tau MRAEs could have larger expansions, but practical parameters limit expansion much below that value. > 3. "The padded sequence number is XORed with the static client_write_iv > or server_write_iv, depending on the role." I think the ivs are not > needed. Oh, they are needed (as in, security will be degraded if IVs are removed). > 4. The current way nonce is specified would disallow ciphers that > use any other ways of generating the nonce such as random nonces. None of the present algorithms is able to handle a random nonce, you would need much longer nonces. And also, it is much easier to just count than try to randomly generate "nonces" (and as far as it is known, more secure, due to random "nonces" having tendency to repeat). And TLS breaks in truly catastrophic way if GCM nonce ever repeats (and wasn't there just such problem in multiple TLS implmenentations)? -Ilari From nobody Tue May 24 10:44: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 A102B12D941 for ; Tue, 24 May 2016 10:44: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=allcosts-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 wRLblo_NhzzO for ; Tue, 24 May 2016 10:44:17 -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 0214712D955 for ; Tue, 24 May 2016 10:44:16 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id c127so23356188ywb.1 for ; Tue, 24 May 2016 10:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/5B7TKwO6FaplEKori2Zv06hQpjZqM3scUPV6+fYXfs=; b=oy7+y/8nNUDeS0nsg4yvUYmpCI9//DlUPNf0aTldjW24pEplBGmeOo70EmzYVuqn7C jtV5hcUShwXYYVNeZNMQXzqOhwgXNW+2EnVzVmr72yKFHsR+nUsIDCpJWqBUjTsLDS2H wZ6zqQj+lCpFHK2fq7TroAzjDIr9Oy4JZPOHz3QsL2HIcSqc+2vj1eilOMeouEf90OqA OJUbtl2eIdk8KMfZac8D4wEe2pFjTXhS6wXjgSyORO3h+1SNO6ib1oaB4haGgbHiU3rU 80gd1CN3Q9J8wLEacKjDSSTCbZ5kMM/sW6ijwpZLYlYzdA9XJNpbOix++k86ALL7mPH/ jZnQ== 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=/5B7TKwO6FaplEKori2Zv06hQpjZqM3scUPV6+fYXfs=; b=D5zkxCqxssbB6STwlqkyIYJD6Tn8Td/NkS8dZzKO4dzi4NfopXYHqcGAyo1toexrcU 4LZkBK488tORLUs+yHz02ovDZH1EId4VgqMi1ATJMXfmrnqEhcv3LDGUhOvHfL8/TekW 1Oh6jiR430sIL9PZXZYNmNFLj4rDJm28jENCdU+3LmusbT6GXb49pYPpSllEG698kGTk TAaE/owYwUzAEXqAMVmblq/7wJ14C2e2H+O+3OJZF7++j04+vrMQ3RdHtGsk4qtBLbj0 sTaVHWIqmybYI4xvX+7ITupBjaLQfGUbgWm5G1xevX+TDv3ZoLzy8GpLyva7bcS+xQCL JaOw== X-Gm-Message-State: ALyK8tKc18Jn2wR51BtCoMNmWShq0cz+bnA+Ije8InMbWzmwCgmhpZbHHy+nv1TsohS7+v3v8FYuxxNu7y2giQ== MIME-Version: 1.0 X-Received: by 10.37.71.3 with SMTP id u3mr3360443yba.36.1464111856003; Tue, 24 May 2016 10:44:16 -0700 (PDT) Received: by 10.129.75.151 with HTTP; Tue, 24 May 2016 10:44:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 10:44:15 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1142326c16f48b05339a1b34 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 17:44:19 -0000 --001a1142326c16f48b05339a1b34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2016 at 9:13 AM, Martin Thomson wrote: > > 3. "The padded sequence number is XORed with the static client_write_iv > or > > server_write_iv, depending on the role.=E2=80=9D I think the ivs are no= t needed. > > We discussed this at quite some length. I originally took your > position, but the IVs add an extra layer of safety at very little > cost. > Is this more safe? wouldn't this disclose the key in the event that the HKDF and the underlying hash turned out to have some cryptanalytical flaw that meant it wasn't back-tracking resistant? I think otherwise TLS can survive such a flaw because the output of the PRF is not directly discernible on the wire. --=20 Colm --001a1142326c16f48b05339a1b34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 9:1= 3 AM, Martin Thomson <martin.thomson@gmail.com> wrote= :
> 3. "The padded sequence number is XORed with the static cli= ent_write_iv or
> server_write_iv, depending on the role.=E2=80=9D I think the ivs are n= ot needed.

We discussed this at quite some length.=C2=A0 I originally took your=
position, but the IVs add an extra layer of safety at very little
cost.

Is this more safe? wouldn't t= his disclose the key in the event that the HKDF and the underlying hash tur= ned out to have some cryptanalytical flaw that meant it wasn't back-tra= cking resistant? I think otherwise TLS can survive such a flaw because the = output of the PRF is not directly discernible on the wire.=C2=A0
<= div>
--
Colm
--001a1142326c16f48b05339a1b34-- From nobody Tue May 24 10:46: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 0905F12D120 for ; Tue, 24 May 2016 10:46:55 -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 QcB3fTyRIHAH for ; Tue, 24 May 2016 10:46:50 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0119.outbound.protection.outlook.com [23.103.200.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD89F12D613 for ; Tue, 24 May 2016 10:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EtG5XjcZvF2knYNL69e+EIJSqb0AF8MNR8SaBcx+iQ8=; b=r3h80ZLKrzZ/EZqyczKudxmlLpJJ2Rv/8qQ1DxRXr/7RbBkpMWvXDhIQVNNw6fRkqCSCB7Ohqz6qDVdPewoEsQbL9OOo+UU/7W4foCcWDQ2yKxIkzCv0oGXMYkcjab4Rb9cayhlFfQ8s2vM+Fdqb3SzfET9X5nq0TQVhfFaAFlk= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 17:46:49 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 24 May 2016 17:46:49 +0000 From: "Dang, Quynh (Fed)" To: Martin Thomson , "Dang, Quynh (Fed)" Thread-Topic: [TLS] Comments on nonce construction and cipher text size restriction. Thread-Index: AQHRtc/HWUjUunA/c0agQBPElmd3kJ/IQt6A///W7AA= Date: Tue, 24 May 2016 17:46:48 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.109.185] x-ms-office365-filtering-correlation-id: 539cdba0-cf1b-45a8-4ecd-08d383fb61f3 x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:ssWkqAlI1tnyCi91vjNw3OVR8rhkRUwqyWNs2EuRKqBdKKX9iK6+Vl6AIcOFaqebhTq2s/k8QVM1Cq4Z2VMehl1QeiDOaK4Qf+8FqhTfj4ZCQERdX0cNYH/lquj+8oHeMZVzRC1zy53YbqiTWJHiCg==; 24:7u+Y7ipZpRzTJozpdRZlGu3WkyNsuEXT9dNt5mdGgSVm9oyjhMdAxhhAmG6D/v/UhyM7jv6TxSALSmQOHS9zWRXLXd0RzjEW/UN26DIjExY=; 7:9rehaKM3U49PygR/STHCKanIbd0fRH7HQ4jfDm1nKxYtJ0vW0Uuf59PgIwB5idVTJQHbUzP15lL9wiGpm0XpnK+dOD/L5oP2bgos7EvPiBFFS4ufA2lOpLis6FsMEwFOsX00ylGnTfAWBQwBik3Tjv5EKrzHh1DZ4Bw1D2DHdbqzqVdA/PbmuIpnD5WQBpwt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(83506001)(1220700001)(19580395003)(4001350100001)(19580405001)(87936001)(77096005)(3660700001)(5008740100001)(10400500002)(586003)(66066001)(122556002)(5001770100001)(54356999)(3846002)(8936002)(92566002)(2950100001)(8676002)(102836003)(3280700002)(2900100001)(6116002)(2906002)(50986999)(5004730100002)(5002640100001)(76176999)(189998001)(4326007)(99286002)(86362001)(4001450100002)(11100500001)(106116001)(81166006)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8FD08589E5BF7C4CB995F7F6C2A894E8@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 17:46:48.9143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 17:46:55 -0000 On 5/24/16, 12:13 PM, "Martin Thomson" wrote: >On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote: >> 1. For this text: "plus the length of the output of the signing >>algorithm. >> " in the last paragraph of Section 4.8.1, did you mean "plus the output >>of >> the signing algorithm.=B2 ? > >The text is correct. It is talking about the length of the structure, >not its contents. > >> 2. "The length (in bytes) of the following TLSCiphertext.fragment. 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. " . >>There >> could be a cipher that generates ciphertext longer than plaintext in >>some >> cases plus the tag. If the tag was 256 bits, then this requirement would >> disallow that cipher unnecessarily when a record size is 2^14. > >The value 256 is octets, not bits. If you are aware of a need for an >authentication tag longer than 256 octets, now would be a great time >to tell all of us. My misreading of the text. Thanks. > > >> 3. "The padded sequence number is XORed with the static client_write_iv >>or >> server_write_iv, depending on the role.=B2 I think the ivs are not neede= d. > >We discussed this at quite some length. I originally took your >position, but the IVs add an extra layer of safety at very little >cost. I don=B9t see any extra layer here. > From nobody Tue May 24 10:56: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 378BC12D94D for ; Tue, 24 May 2016 10:56:08 -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 3QR0YRxBivoE for ; Tue, 24 May 2016 10:56:06 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0122.outbound.protection.outlook.com [23.103.201.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5632312D928 for ; Tue, 24 May 2016 10:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oB0nBPJjb0UgS2IBNp12b2w+VwE0GoRU6QFHGfkTTYs=; b=1F1kPEFZ0Vk7lLdBETyfDO9vZ4J2HkynEXOkmjncF0mXRZ8H2q/nAqGwnJLrXB5VsVtB6xQaceF+zIs3eDXCZy2+sNWoeKjpsPpEXWpDRA/P4aCg6l3NZcJoD0EwQwJtmgXQyQPYLoFHAlw3SBo1mvY2MbscROioBGCUboQpXEc= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 17:56:04 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 24 May 2016 17:56:04 +0000 From: "Dang, Quynh (Fed)" To: Ilari Liusvaara , "Dang, Quynh (Fed)" Thread-Topic: [TLS] Comments on nonce construction and cipher text size restriction. Thread-Index: AQHRtc/HWUjUunA/c0agQBPElmd3kJ/IT3GA///M8wA= Date: Tue, 24 May 2016 17:56:04 +0000 Message-ID: References: <20160524165845.GB23887@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160524165845.GB23887@LK-Perkele-V2.elisa-laajakaista.fi> 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: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.109.185] x-ms-office365-filtering-correlation-id: 82cc94f9-9511-4d02-4f54-08d383fcacde x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:H6jpv2DVYF2S9gYPNxHWkxbOWSPV230xyIodvGcPDhFDJYvx93DQu2GSYiz8qCLj8OH1HCyPB9ArSpP0/SPvf8o8my+b6tRHnYqL0z0q/RGFNnFX9rtA8jh3iTmTDWzBX8ZIJ0nmVjETA9qv43SbnA==; 24:GrEWMKpSM1r+9V9KdPS8EGT3Wtmj8f1E4d8sdz1GV/o+sQjIOf00NfimX1DpeRsve+YIq58PHCGrOZaHv8kAxo12TmjgcNMp99Eb6cVIwd8=; 7:YtFXzpeFR6lRg5FzKEcqLbpdA0tbr0brue4Y0+N9K2F2qfRqlZUjOeExRXf5I0nuQUmfS4LKLhVMmFbZy7lhT+Ah74+ThrA9dlzCbl0DuurWFa5SunO281R2cPE2unT829XhNoUQeOoQhOA+9r9iZymHw2NXY+qa6P91d/t0cwHBmzgRWjORSMy/BVFEHlcs x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(83506001)(102836003)(6116002)(10400500002)(3280700002)(2900100001)(5001770100001)(3660700001)(3846002)(8676002)(4001450100002)(5004730100002)(5002640100001)(586003)(189998001)(122556002)(54356999)(2950100001)(2906002)(4326007)(4001350100001)(5008740100001)(92566002)(19580405001)(19580395003)(8936002)(81166006)(1220700001)(11100500001)(36756003)(106116001)(99286002)(77096005)(76176999)(86362001)(87936001)(50986999)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <066B623C8F65AE49A5B9F5DBAB80FB2C@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 17:56:04.1650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 17:56:08 -0000 On 5/24/16, 12:58 PM, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" wrote: >On Tue, May 24, 2016 at 03:20:17PM +0000, Dang, Quynh (Fed) wrote: >> Hi Eric, >>=20 >> 1. For this text: "plus the length of the output of the signing >> algorithm. " in the last paragraph of Section 4.8.1, did you mean >> "plus the output of the signing algorithm." ? > >The paragraph seems to talk about the length, so plus length of seems >correct. > >> 2. "The length (in bytes) of the following TLSCiphertext.fragment. >> 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. " . There could be a cipher that generates ciphertext longer >> than plaintext in some cases plus the tag. If the tag was 256 bits, >> then this requirement would disallow that cipher unnecessarily when >> a record size is 2^14. > >It is not in bits, it is in bytes. So to blow the limit, you would need >cipher that expands the plaintext by 256 bytes (remember the typebyte >counts as plaintext input here). > >And what algorithm would have >2040 bits of expansion? > >Variable-tau MRAEs could have larger expansions, but practical >parameters limit expansion much below that value. > >> 3. "The padded sequence number is XORed with the static client_write_iv >> or server_write_iv, depending on the role." I think the ivs are not >> needed. > >Oh, they are needed (as in, security will be degraded if IVs are >removed). I don=B9t think so.=20 >=20 >> 4. The current way nonce is specified would disallow ciphers that >> use any other ways of generating the nonce such as random nonces. > >None of the present algorithms is able to handle a random nonce, >you would need much longer nonces. True.=20 > >And also, it is much easier to just count than try to randomly >generate "nonces" (and as far as it is known, more secure, >due to random "nonces" having tendency to repeat). I did not recommend using short random nonces. If the current construction of nonces is for GCM, than that would be fine and recommended. But, currently, it is written as for all ciphers. If the construction of nonce is not fixed, then an encryption mode just needs to specify its own way of generating nonces.=20 > >And TLS breaks in truly catastrophic way if GCM nonce ever >repeats (and wasn't there just such problem in multiple TLS See comment above.=20 >implmenentations)? > > >-Ilari Quynh.=20 > From nobody Tue May 24 11:03: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 E122612D956 for ; Tue, 24 May 2016 11:03:23 -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 BGTjGqoxT40M for ; Tue, 24 May 2016 11:03:22 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id F04E712D8B7 for ; Tue, 24 May 2016 11:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 7FABA4BAB; Tue, 24 May 2016 21:03:20 +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 Jx0m5Uzsdh_c; Tue, 24 May 2016 21:03:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3DA6B28C; Tue, 24 May 2016 21:03:20 +0300 (EEST) Date: Tue, 24 May 2016 21:03:17 +0300 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Message-ID: <20160524180317.GA24055@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] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:03:24 -0000 On Tue, May 24, 2016 at 10:44:15AM -0700, Colm MacCárthaigh wrote: > On Tue, May 24, 2016 at 9:13 AM, Martin Thomson > wrote: > > > > 3. "The padded sequence number is XORed with the static client_write_iv > > or > > > server_write_iv, depending on the role.†I think the ivs are not needed. > > > > We discussed this at quite some length. I originally took your > > position, but the IVs add an extra layer of safety at very little > > cost. > > > > Is this more safe? wouldn't this disclose the key in the event that the > HKDF and the underlying hash turned out to have some cryptanalytical flaw > that meant it wasn't back-tracking resistant? I think otherwise TLS can > survive such a flaw because the output of the PRF is not directly > discernible on the wire. It seems like failing backtracking resistance would need really major breakage in PRF-hash. And the whole TLS will fall apart pretty badly WAY before that point with broken PRF. -Ilari From nobody Tue May 24 11:44: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 71DDE12D7E8 for ; Tue, 24 May 2016 11:44:39 -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 J_O6d3dJw_i6 for ; Tue, 24 May 2016 11:44:37 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CD212D874 for ; Tue, 24 May 2016 11:43:00 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id e93so11551525qgf.2 for ; Tue, 24 May 2016 11:43: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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=01Qk9fLeIw3jixyoRKe3uS/s2kEXlHSGHEpGtPWzfsM=; b=TNe1p8PHNbi+4g7ciuf72P4n653KK3NoLq7ycOVu1LeWtG87xhpAGVq0PtIyFmsC+a wJjjaWmEQOwpEPT8lRZIeTXKD/hJ/hWystvR3VKdoAFHQphKNLfrwn2PaaQe6VXnbSOE S4Rr1W0qkQ5M1b1LgbpC2Kc9jeEaXbtNhFma0BTcx4x1G0fRV2XtQoMeA446VpRAzz0+ 3nllnRt3o8nJYh4VnHzVepxFdquRv7UEfe2EIKbDxNy6iluUMOi1e6rPAKRuSdyhsivv UUXrNw05TQVnGHyDn9dTv7khtNeRYLGEtWc9NOTVYbLBnFpGHACbtX8IXSXYuqi84txt RjOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=01Qk9fLeIw3jixyoRKe3uS/s2kEXlHSGHEpGtPWzfsM=; b=dBDSRDXR2uvociQ/EIoDuxK4q/+2hTSkUaZYZRJnRw3icd17lpFT7tuN8XcHeJf917 SPBb9Xbk5PEKs5xUJu37wMnrvyQS6hNaG6qeELjxInKTqpKFtgi9qf+swXuXE3uMfpIi M9YHVDBWIT2Nbk0lsCwgVbJMz33SCX86jC7kXMpVpnzV23Hkz5e6+9f1CgemzYtMRNGM xMOTK4FgSsmHig/BXautwGvFkj6zQ/exEISmETNCplgZDc4Q6aRWYx6uhhYwtDdaQPtU uyDUEaiXypHT+PeUhe8KosU/OAuNAUZvLle4z7NWTN/dmH411NdondvBJnh+z0Ia45Tw uRMg== X-Gm-Message-State: ALyK8tLbm0KQFnG4BtrwCO+mcGU42kRUaAnOmeQG0izcwOV/EFDQ4MHsDmEAxyeGGdc8Uoh67gZYwquRX3d/BA== MIME-Version: 1.0 X-Received: by 10.140.163.212 with SMTP id j203mr4962335qhj.40.1464115379950; Tue, 24 May 2016 11:42:59 -0700 (PDT) Received: by 10.140.104.70 with HTTP; Tue, 24 May 2016 11:42:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 11:42:59 -0700 Message-ID: From: Martin Thomson To: "Dang, Quynh (Fed)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:44:39 -0000 On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote: >>We discussed this at quite some length. I originally took your >>position, but the IVs add an extra layer of safety at very little >>cost. > > I don=C2=B9t see any extra layer here. The argument here is that there are only 2^128 keys and some protocols have predictable plaintext. A predictable nonce would allow an attacker to do some pre-calculation with a large number of keys to get a chance of a collision (and a break). It's a long bow, but not entirely implausible. From nobody Tue May 24 12:00: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 0E48D12DA4E for ; Tue, 24 May 2016 12:00:40 -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 YknrHH615MUM for ; Tue, 24 May 2016 12:00:38 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0132.outbound.protection.outlook.com [23.103.200.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552D912DA1B for ; Tue, 24 May 2016 12:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YRtx9Gw/sjDRmZ3s2+krWgDVJhPD3Ntup51q3MdYtV0=; b=GaKL3hX7MjsRqS7RyYwFs6NAWtA60hlF2udEmMg7iHvmWOHIVDnar1tt0CdTfmlJSD/uJYrPc8dBtY5SO2cXpB+7alKURSJ0bssLmta24SbAqL2sO20eKixaGZ+nLAy5kpvHA1TIDyLgJvQZz7LU648FkbVQ8pVjbnmwnLLqyjM= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 19:00:27 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 24 May 2016 19:00:27 +0000 From: "Dang, Quynh (Fed)" To: Martin Thomson , "Dang, Quynh (Fed)" Thread-Topic: [TLS] Comments on nonce construction and cipher text size restriction. Thread-Index: AQHRtc/HWUjUunA/c0agQBPElmd3kJ/IQt6A///W7ACAAFLGgP//wdGA Date: Tue, 24 May 2016 19:00:27 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.109.185] x-ms-office365-filtering-correlation-id: 2c8a0ec4-ca72-4dad-0123-08d38405ab90 x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:TvcOfL9EpkbOGpPkA8aGZeZ8gDI3enPwYe7ZlRjNr8fkwarhNWNq3Q+cZVTix0kaW1qByq9HZgH0rycLDsl5H/SUDZknTWCvR994OWxLc9l11gb16tpdEH+b5PklHqWT/pxpUWIFyscRLHBPm5CdAw==; 24:B9aDPJ1mkzN0VLEAOx4IjB+Ss00l+bkHD+MTYeRjOvrDck/0zAQNFqxVZ/5DiWaXcIQHSXmYsQSBpMXGQ3RUJUPUgfInfTLbgFfK71QS9u8=; 7:WA+CGISqm+jZzIk4dkw9xEDnUSSoRfSqVJpq6nCoTgJZEBksE3c72VQqTkUNvcAws5HG9D8geyl7L4+kD3JPONn+FA1cihDytyMJyBXEhdZJR5blNsjw+V27KryfmtzH61Xhd/NyZ8eOnopkm/BtQknSxW+u3FgyOu5RY27fVbLBn72qT92biWr1RrMT0zlJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(86362001)(87936001)(106116001)(36756003)(76176999)(77096005)(99286002)(66066001)(50986999)(586003)(5002640100001)(5004730100002)(2950100001)(122556002)(189998001)(4001450100002)(54356999)(8676002)(2900100001)(3280700002)(10400500002)(83506001)(6116002)(102836003)(3660700001)(3846002)(5001770100001)(5008740100001)(92566002)(4001350100001)(8936002)(19580395003)(11100500001)(81166006)(1220700001)(19580405001)(2906002)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: <09AF87433E218748A0F08A4DC50190DA@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 19:00:27.2571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:00:40 -0000 DQoNCk9uIDUvMjQvMTYsIDI6NDIgUE0sICJNYXJ0aW4gVGhvbXNvbiIgPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5PbiAyNCBNYXkgMjAxNiBhdCAxMDo0NiwgRGFuZywgUXV5 bmggKEZlZCkgPHF1eW5oLmRhbmdAbmlzdC5nb3Y+IHdyb3RlOg0KPj4+V2UgZGlzY3Vzc2VkIHRo aXMgYXQgcXVpdGUgc29tZSBsZW5ndGguICBJIG9yaWdpbmFsbHkgdG9vayB5b3VyDQo+Pj5wb3Np dGlvbiwgYnV0IHRoZSBJVnMgYWRkIGFuIGV4dHJhIGxheWVyIG9mIHNhZmV0eSBhdCB2ZXJ5IGxp dHRsZQ0KPj4+Y29zdC4NCj4+DQo+PiBJIGRvbqn2dCBzZWUgYW55IGV4dHJhIGxheWVyIGhlcmUu DQo+DQo+DQo+VGhlIGFyZ3VtZW50IGhlcmUgaXMgdGhhdCB0aGVyZSBhcmUgb25seSAyXjEyOCBr ZXlzIGFuZCBzb21lIHByb3RvY29scw0KPmhhdmUgcHJlZGljdGFibGUgcGxhaW50ZXh0LiAgQSBw cmVkaWN0YWJsZSBub25jZSB3b3VsZCBhbGxvdyBhbg0KPmF0dGFja2VyIHRvIGRvIHNvbWUgcHJl LWNhbGN1bGF0aW9uIHdpdGggYSBsYXJnZSBudW1iZXIgb2Yga2V5cyB0byBnZXQNCj5hIGNoYW5j ZSBvZiBhIGNvbGxpc2lvbiAoYW5kIGEgYnJlYWspLiAgSXQncyBhIGxvbmcgYm93LCBidXQgbm90 DQo+ZW50aXJlbHkgaW1wbGF1c2libGUuDQoNCkNpcGhlcnMgdXNlIG5vbmNlcyBhcmUgZGVzaWdu ZWQvcHJvdmVkIHRvIGJlIHNlY3VyZSB3aGVuIG5vbmNlcyBhcmUNCnByZWRpY3RhYmxlOiBub25j ZXMgYXJlIG5vdCByYW5kb20gdmFsdWVzLg0KDQo+DQoNCg== From nobody Tue May 24 12:05: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 8545B12D989 for ; Tue, 24 May 2016 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] 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 9goA8sUHLm1Z for ; Tue, 24 May 2016 12:05:10 -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 A6B8612D9BB for ; Tue, 24 May 2016 12:05:09 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id o16so25581444ywd.2 for ; Tue, 24 May 2016 12:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vM99zL+ACcfUdnaxSaLsDF2cHmiyAREvNNnT+IhE0eA=; b=XANAu7qG2L//zVnVb2U5w6HajMxQ+c5KJic7xTe5nZg8adR5gUqEf1uFP2wwUkmseC iyRRIg39wzp9hFe6WJzoNhVfK8VQ8WEsfcX5KEDJUNMCfNPI4tTzxliftCiDpkJ4S1tN XyZodkw+hHA/rHpOUnWh4lwsJeBquOAcvdBgMW4+YK1PoodWdV4dsuBdZM68VMXTAvu1 u343+AXVXvNTveLyTLL1T9qae0FbMEXQVk/uRAtyFCHP3H0X7nh0YHgKAIse7vm1f1nu AnqXktq/Go8w2iyqIgyW0Z47PXdr18HLWtt9QyyE1Lpy/++TCJIUGO5eqBdz0mgi4Edj PuyQ== 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=vM99zL+ACcfUdnaxSaLsDF2cHmiyAREvNNnT+IhE0eA=; b=b86gJ/eTzb4+Hnx0dVZcm+EJh9iNcPEx2OvydaOjQxaLtl3d9EiCWiULiqh5N9w1Tj Y/gDZo5UjRimZPreIDgoispT1ncMMU4tiwcANhp7jXXG6uX93oPls273ah7/hZ1r6OoX v12Mqt+ki6N8f5INPmkNpmmQeVpcs5oU4cYzcYEgphf/3pB7LzNNCz8Vs/XboOF4Pgvu rx+aQKmQK/eUnu4+Kl/MB0UuRq1riGKOHgBuBXy73HQOE5mTnZ2GLkc7vIpWEaYiBKHw quJwNk5Cil/e+3GhkxRH0z4A1Tf2Vrx5RipKXKmI9qYSpEh0M8VvWvluimWsV1i+K1NL 53UQ== X-Gm-Message-State: ALyK8tKlzx3I/M56VoMf+oCxURK/i5HnGK8llxkDdPNoIMdMH6rTJUuQJP8idackqljjuvnkoPyB5gSQb4+/ow== X-Received: by 10.129.160.149 with SMTP id x143mr3656170ywg.180.1464116708939; Tue, 24 May 2016 12:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Tue, 24 May 2016 12:04:29 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 24 May 2016 12:04:29 -0700 Message-ID: To: "Dang, Quynh (Fed)" Content-Type: multipart/alternative; boundary=94eb2c07ee0458e53705339b3cb2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:05:17 -0000 --94eb2c07ee0458e53705339b3cb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) wrote: > > > On 5/24/16, 2:42 PM, "Martin Thomson" wrote: > > >On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote: > >>>We discussed this at quite some length. I originally took your > >>>position, but the IVs add an extra layer of safety at very little > >>>cost. > >> > >> I don=C2=B9t see any extra layer here. > > > > > >The argument here is that there are only 2^128 keys and some protocols > >have predictable plaintext. A predictable nonce would allow an > >attacker to do some pre-calculation with a large number of keys to get > >a chance of a collision (and a break). It's a long bow, but not > >entirely implausible. > > Ciphers use nonces are designed/proved to be secure when nonces are > predictable: nonces are not random values. > I think you may be misunderstanding. There is a time/space tradeoff here when the nonces are predictable that does not exist when they are random. This is not a vulnerability in the cipher and applies even if the keystream generator at the core of the cipher is PRF_k(nonce). -Ekr > > > > --94eb2c07ee0458e53705339b3cb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) &= lt;quynh.dang@nist= .gov> wrote:


On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
>>>We discussed this at quite some length.=C2=A0 I originally took= your
>>>position, but the IVs add an extra layer of safety at very litt= le
>>>cost.
>>
>> I don=C2=B9t see any extra layer here.
>
>
>The argument here is that there are only 2^128 keys and some protocols<= br> >have predictable plaintext.=C2=A0 A predictable nonce would allow an >attacker to do some pre-calculation with a large number of keys to get<= br> >a chance of a collision (and a break).=C2=A0 It's a long bow, but n= ot
>entirely implausible.

Ciphers use nonces are designed/proved to be secure when nonces= are
predictable: nonces are not random values.

<= div>I think you may be misunderstanding. There is a time/space tradeoff her= e when the
nonces are predictable that does not exist when they a= re random. This is not a
vulnerability in the cipher and applies = even if the keystream generator at the core
of the cipher is PRF_= k(nonce).

-Ekr


>


--94eb2c07ee0458e53705339b3cb2-- From nobody Tue May 24 13:16: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 D38A312D5B8 for ; Tue, 24 May 2016 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Oo_JzUMnpxhj for ; Tue, 24 May 2016 13:15:48 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9972112D782 for ; Tue, 24 May 2016 13:13:48 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f8so19378418ioe.3 for ; Tue, 24 May 2016 13:13:48 -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=7c9+zAuM9zDxsrdyOBBpwhpB2LfUJtHpzKn6qhyce6M=; b=sbeIeEvKq4Iskx5RaaHLVJZiubNgyG7bE428v8VqLnGyFaEXYSfbXKvtBEHM+s7mUN c24NE7WmgSye1q4MUBuWF85x3oTVk7ecS03KxeIhb5jh634KKaKlwdXBM/OlV4wC6bLY 4rFb8PVBtqFV0F8xaraUKLitAaAzXLvLb+XxNZwLyBJv5reNeDg1mz675a+nE5yHt3tS IVBZGqHYNNZO4CbONU0mtlczYLWmY8msn9gk6YSdMfcClnOZ7MfKNuVhbISmsGUU6sm7 ax7lmihGwT9rrbWOmJvw49lFCAJE0iyelQOX0YI2IifufI7MmJ2rzWZgZbBqnYzRBDmy FPCA== 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=7c9+zAuM9zDxsrdyOBBpwhpB2LfUJtHpzKn6qhyce6M=; b=jqdB7REkZW5kZiKfAtqJzlR/6vnJUy4/+5cGa/MR17I6VparNt8ACgCsqym/tvA0pS fSu0k8Zqy2/DxfjZhNOcsf59qkW7NmFsrWRkIA0sHrsfz4T7uLIz88LJwypTtYSQvsTc I9edLVFAVlVecjJxh4aIZAHtVZe3IUk0wxPNR/3VHFnnuUEucsn+VkoTYe66eLVYQTQQ DN20UFlLg9KReZvQlIsMqw253dkf2QiKAnIVOK3o/jPPWap18wuewayUTuREqhRwIe5S JAG693rc6yxDsSObFDZNo8nf52gJVviEiTWQ3s6U+haxiqQKVuqQ8XBl8ikucn0vb7O5 MTWw== X-Gm-Message-State: ALyK8tIZw5KaBu5vmQkmQQrqwQESkVvHLYIvS8fhk8J5lY0Di9NCZvxhWqRniAPBgHPEOvEoSRCSVhF17lsDVQ== MIME-Version: 1.0 X-Received: by 10.107.26.148 with SMTP id a142mr627894ioa.119.1464120827905; Tue, 24 May 2016 13:13:47 -0700 (PDT) Received: by 10.64.228.131 with HTTP; Tue, 24 May 2016 13:13:47 -0700 (PDT) Received: by 10.64.228.131 with HTTP; Tue, 24 May 2016 13:13:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 16:13:47 -0400 Message-ID: From: Quynh Dang To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113fe964db0cb905339c31e7 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:15:56 -0000 --001a113fe964db0cb905339c31e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are you worried about 2^96 precomputation and the risk of 1/2^32 of cracking your key? Quynh. On May 24, 2016 3:05 PM, "Eric Rescorla" wrote: > > > On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) > wrote: > >> >> >> On 5/24/16, 2:42 PM, "Martin Thomson" wrote: >> >> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote: >> >>>We discussed this at quite some length. I originally took your >> >>>position, but the IVs add an extra layer of safety at very little >> >>>cost. >> >> >> >> I don=C2=B9t see any extra layer here. >> > >> > >> >The argument here is that there are only 2^128 keys and some protocols >> >have predictable plaintext. A predictable nonce would allow an >> >attacker to do some pre-calculation with a large number of keys to get >> >a chance of a collision (and a break). It's a long bow, but not >> >entirely implausible. >> >> Ciphers use nonces are designed/proved to be secure when nonces are >> predictable: nonces are not random values. >> > > I think you may be misunderstanding. There is a time/space tradeoff here > when the > nonces are predictable that does not exist when they are random. This is > not a > vulnerability in the cipher and applies even if the keystream generator a= t > the core > of the cipher is PRF_k(nonce). > > -Ekr > > >> > >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113fe964db0cb905339c31e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Are you worried about 2^96 precomputation and the risk of 1/= 2^32 of cracking your key?

Quynh.

On May 24, 2016 3:05 PM, "Eric Rescorla&quo= t; <ekr@rtfm.com> wrote:


On Tue, May 24, 2016 at= 12:00 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:<= br>


On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thomson@gmail.com> wro= te:

>On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
>>>We discussed this at quite some length.=C2=A0 I originally took= your
>>>position, but the IVs add an extra layer of safety at very litt= le
>>>cost.
>>
>> I don=C2=B9t see any extra layer here.
>
>
>The argument here is that there are only 2^128 keys and some protocols<= br> >have predictable plaintext.=C2=A0 A predictable nonce would allow an >attacker to do some pre-calculation with a large number of keys to get<= br> >a chance of a collision (and a break).=C2=A0 It's a long bow, but n= ot
>entirely implausible.

Ciphers use nonces are designed/proved to be secure when nonces= are
predictable: nonces are not random values.

<= div>I think you may be misunderstanding. There is a time/space tradeoff her= e when the
nonces are predictable that does not exist when they a= re random. This is not a
vulnerability in the cipher and applies = even if the keystream generator at the core
of the cipher is PRF_= k(nonce).

-Ekr


>



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

--001a113fe964db0cb905339c31e7-- From nobody Tue May 24 13:23: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 B57D112D1CD for ; Tue, 24 May 2016 13:23:06 -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 IG4rYHA_WziB for ; Tue, 24 May 2016 13:23:04 -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 B576C12D109 for ; Tue, 24 May 2016 13:23:04 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h19so27809934ywc.0 for ; Tue, 24 May 2016 13:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BR1usJgZnxsACswNYxtBUp1zvgPQeB6tHoWqL33QokI=; b=sAcOKB8ay4CJA64WRju2ngE4IXT1ytDg2EateqSMXxwVW89AyeMWCZBObqwAjHYzkg xp2kDq7AZ+2uHbUW9/gD9xh+KAFYi2+of+LsGju0X6dVNd9aJ/Gb8VTnz0a43mn2Z066 OIgxNzBOrj8aobRaZ0r2glHGh380apgQeXGOdkhyyAyxvI9VCR8vnzs7SFRdE/EoTQd9 +m4U1lSKJOf50a+iL6mopg+UhWkEkikTFeugday/fjU7MC/5UWjkxUl6F+9huyN2Q/FG hIS0QMpjs9tlOyz133CLcvintzHTRkbXfPIKFBYjr4sK0n0YRC8d/THF2f4Ry/GpbXoj STdA== 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=BR1usJgZnxsACswNYxtBUp1zvgPQeB6tHoWqL33QokI=; b=C8KEbvFF9AmcLAu6F7Fk3GVX1bUqEId0kAP9uy5X7X2vdJBazwUt6Y78ajJvvK38m3 OP6588dsTUtOU5J4r3Yb64MfhLOAmqa/XTXWb4Yl43f/093ci3sJb7ukVXF8u//R3Ywk +ejuKtS2hyhDkQIWc1tF2uVKGh1tDgm+cCuw6HVT3dadJIBDrY1TnwtmTHVCOOluDZhs 1+pHFp/oZ8dQPWyGMLW+EPf6Q2mU+eSvZIjMnsc9WMbz0ZIh5+tAsF3w869RI7beK178 l6SgaSkCN1hRyPr+Hrj/qZLWI+Gf9/iBGVNfd4/xFDGi6LclIZ/dvbhimAVx/eL9WDmE sAnQ== X-Gm-Message-State: ALyK8tIB0mgUkZjhMG2trTfzw8J0kV+24htM8AGcojpZuabiSpc2i9iXDXJLHLRyLhvVawk8fszttai1I1iAdw== X-Received: by 10.129.164.145 with SMTP id b139mr24704ywh.171.1464121383950; Tue, 24 May 2016 13:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Tue, 24 May 2016 13:22:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 24 May 2016 13:22:24 -0700 Message-ID: To: Quynh Dang Content-Type: multipart/alternative; boundary=94eb2c128ec2ffd11305339c5234 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:23:07 -0000 --94eb2c128ec2ffd11305339c5234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, a smaller computation (say 2^{64}) and then collecting 2^{40} connections all of which encipher the same plaintext (e.g., "GET /...") -Ekr On Tue, May 24, 2016 at 1:13 PM, Quynh Dang wrote: > Are you worried about 2^96 precomputation and the risk of 1/2^32 of > cracking your key? > > Quynh. > On May 24, 2016 3:05 PM, "Eric Rescorla" wrote: > >> >> >> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) >> wrote: >> >>> >>> >>> On 5/24/16, 2:42 PM, "Martin Thomson" wrote: >>> >>> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote= : >>> >>>We discussed this at quite some length. I originally took your >>> >>>position, but the IVs add an extra layer of safety at very little >>> >>>cost. >>> >> >>> >> I don=C2=B9t see any extra layer here. >>> > >>> > >>> >The argument here is that there are only 2^128 keys and some protocols >>> >have predictable plaintext. A predictable nonce would allow an >>> >attacker to do some pre-calculation with a large number of keys to get >>> >a chance of a collision (and a break). It's a long bow, but not >>> >entirely implausible. >>> >>> Ciphers use nonces are designed/proved to be secure when nonces are >>> predictable: nonces are not random values. >>> >> >> I think you may be misunderstanding. There is a time/space tradeoff here >> when the >> nonces are predictable that does not exist when they are random. This is >> not a >> vulnerability in the cipher and applies even if the keystream generator >> at the core >> of the cipher is PRF_k(nonce). >> >> -Ekr >> >> >>> > >>> >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> --94eb2c128ec2ffd11305339c5234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, a smaller computation (say = 2^{64}) and then collecting 2^{40} connections all of which encipher the sa= me plaintext (e.g., "GET /...")
<= br>
-Ekr

On Tue, M= ay 24, 2016 at 1:13 PM, Quynh Dang <quynh97@gmail.com> wrote= :

Are you worried about 2^= 96 precomputation and the risk of 1/2^32 of cracking your key?

Quynh.

On May 24, = 2016 3:05 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:


On Tue, M= ay 24, 2016 at 12:00 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov><= /span> wrote:


On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thomson@gmail.com> wro= te:

>On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
>>>We discussed this at quite some length.=C2=A0 I originally took= your
>>>position, but the IVs add an extra layer of safety at very litt= le
>>>cost.
>>
>> I don=C2=B9t see any extra layer here.
>
>
>The argument here is that there are only 2^128 keys and some protocols<= br> >have predictable plaintext.=C2=A0 A predictable nonce would allow an >attacker to do some pre-calculation with a large number of keys to get<= br> >a chance of a collision (and a break).=C2=A0 It's a long bow, but n= ot
>entirely implausible.

Ciphers use nonces are designed/proved to be secure when nonces= are
predictable: nonces are not random values.

<= div>I think you may be misunderstanding. There is a time/space tradeoff her= e when the
nonces are predictable that does not exist when they a= re random. This is not a
vulnerability in the cipher and applies = even if the keystream generator at the core
of the cipher is PRF_= k(nonce).

-Ekr


>



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


--94eb2c128ec2ffd11305339c5234-- From nobody Tue May 24 14:00: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 6064A12D0A6 for ; Tue, 24 May 2016 14:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 9hEacWSjDZO3 for ; Tue, 24 May 2016 14:00:23 -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 77B3412B051 for ; Tue, 24 May 2016 14:00:23 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n63so21056992qkf.0 for ; Tue, 24 May 2016 14:00: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:date:message-id:subject:from:to :cc; bh=6+ZsB5rVvhpPNYl58fySyZOoVhnuK87Mn5XnS8gTing=; b=VKM8GU2VFcrva/itaEGpKWmTuHibIGfbnvLnCtsnxttKcXa8fDCltZr9rh0BkoiNB5 7l/WfVaLZ7yXgoZHpXed/qCG58K3PUF5cMh+3UaoC6UyQN2qRrCDFPePYfFlVWi8Ob26 NTLuS0qsEuBTc+QIAH8SMnOr4cV71kF9nx1g5ZcnrV9vw6j1zKzX+jAF8neCNpx6K2gL 5u2VrgGNyteLsg/zQHRZQYBvW7O655YHnLdVU6GfPGHWn37ls0JrpHd9LuUMKwmLd2ZH rpSJOAZvmrYg1Q3WiWR5xxO7iOdEWiW7XZzTeN2HQXbIuX6KgWEWfAzZRRRvXK6OXCx4 RnWA== 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=6+ZsB5rVvhpPNYl58fySyZOoVhnuK87Mn5XnS8gTing=; b=hcwI/J5yi1p4gCcfuVwz5HQxmeyyxl3ploqUrYVTn0UM7YIF6YlCXWKB234yTJyPoh z4fvnOkT3FFGN76WNSy9TywH87um/EZ122Z3SuNTVwIzCE3ohKbnv5kEvvwjqCQQNCIJ qs2uHsRfD6Fc1bnlij7GB0LjIHfl4R5S4+EtxY2BxG/baFrLMU2LOKKDAjqeQaiuy77X PWT/Welf3L9idOov3l+iTsn002nvq7VS3zjTRchq+tbHfP4pMGHBiL9f+HHxpKRWN1+t 2HpSWiuRHHy+V6DEmgdHu8Igwt9wg6bk+6+gYtvea8Q+hVRIjN18AfU/KRGLsOddkyy1 Vsjg== X-Gm-Message-State: ALyK8tKYDH5IG5XcxKOZ0QS8sDGgwFxdXkq5J5dXX3BP+9dSGcSxShcpFA17mm593PHMvrsWAdpdJwZ558pikw== MIME-Version: 1.0 X-Received: by 10.237.55.73 with SMTP id i67mr232121qtb.94.1464123622547; Tue, 24 May 2016 14:00:22 -0700 (PDT) Received: by 10.140.104.70 with HTTP; Tue, 24 May 2016 14:00:22 -0700 (PDT) In-Reply-To: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 24 May 2016 14:00:22 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Asking for certificate authentication when doing 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: Tue, 24 May 2016 21:00:25 -0000 On 20 May 2016 at 12:41, Ilari Liusvaara wrote: > On Wed, May 18, 2016 at 10:10:29AM -0400, Martin Thomson wrote: >> I just posted this: >> >> https://datatracker.ietf.org/doc/draft-thomson-tls-0rtt-and-certs/ >> >> It's fairly self explanatory. The idea is to create a way to signal >> that the client wants the server to re-authenticate itself, even if it >> successful in using a pre-shared key. > > - How is the capability signaled? New flag bits in session ticket > for these ciphersuites? I just uploaded -01 that corrects this oversight. I have raised https://github.com/martinthomson/tls-0rtt-and-certs/issues/1 which tracks whether certificates might change. From nobody Tue May 24 14:19: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 04A0B12D557 for ; Tue, 24 May 2016 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 L8JhTkQ_f6C0 for ; Tue, 24 May 2016 14:19:02 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1678112D505 for ; Tue, 24 May 2016 14:19:02 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id ww4so60241852igb.1 for ; Tue, 24 May 2016 14:19:02 -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=7D7Sh+s+N5GmOmzlY613Mf1egWvcG8LEA4wyu9xgARI=; b=MLsN/AlCHGLJVMUmYxI1G9zgbQz96u8vmxM5PGmKzwID76h91njhO+SZ8aAqlUlirg g0lC8zkhkGjDA0AzfBrod8GK7Ropve5JYbJfksBPUrD+j+giroE73wRKvLhiPAaQWpDr lZk3D8RrqLKZyLUcFDvDCuQmwLeAzFaZYDCOQ0vTraAGQ/Fky6q3yKpgQkk1D+G8yPzp ii0I3Jm2/eOLE3thIQcNtIxPT08eC8bORkUOl+brbp/nrMI/52QQdRbA7ARSB4ZaASm2 XyQGzkx+y9KUfFbSJ2eeB83BB+ifpkdR5NbGA0TH3c44+zYWeLXeqN1RSJ4CFtjQpv6Y +YLg== 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=7D7Sh+s+N5GmOmzlY613Mf1egWvcG8LEA4wyu9xgARI=; b=ZsPkdvudDdL7lVPSwBeSY83X8FrtTn2w8nv/XT7W5zuK95tSW4Hz81rIy+ENCHn8Cp K2Y1Z3X2Z0DRM83DpuVcvEy/Esk/cuWnadHUeg6MVK0hbTbAfIHanbClrHp8VGygtzl8 3l1zskSM1YCD1t7Pv9iKpHMGQxzhZ2NjmNikUMGjBbNl6oyWGgCtFfX1BuksLA75pNST nwqLBecmsU4HKIkRZyX6KPvYdc1JUfr9sKcOWw624YqTzrsRkRoV7gE1ibKE9b+CJiFn pbDPgWeGlx5RzMK0Jxon8dnBaLwmcxZ2gz7UyAVj+7RHG0KSQujRwAWiCWneF4/BMqfk 8UFg== X-Gm-Message-State: AOPr4FW3Vh6IZggugn7HC9RgOtMCIMCzWae619e45Ekh4q2/p8/5OAe6D6LQSUEq+FAXsM8dvHrHl1pf8Dnu+g== MIME-Version: 1.0 X-Received: by 10.50.153.166 with SMTP id vh6mr19367127igb.90.1464124741395; Tue, 24 May 2016 14:19:01 -0700 (PDT) Received: by 10.64.228.131 with HTTP; Tue, 24 May 2016 14:19:01 -0700 (PDT) Received: by 10.64.228.131 with HTTP; Tue, 24 May 2016 14:19:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 17:19:01 -0400 Message-ID: From: Quynh Dang To: Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8f2355651e2f8405339d1b46 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:19:04 -0000 --e89a8f2355651e2f8405339d1b46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If that is what you are worried about, then that would make sense. Quynh. On May 24, 2016 4:23 PM, "Eric Rescorla" wrote: > No, a smaller computation (say 2^{64}) and then collecting 2^{40} > connections all of which encipher the same plaintext (e.g., "GET /...") > > -Ekr > > > On Tue, May 24, 2016 at 1:13 PM, Quynh Dang wrote: > >> Are you worried about 2^96 precomputation and the risk of 1/2^32 of >> cracking your key? >> >> Quynh. >> On May 24, 2016 3:05 PM, "Eric Rescorla" wrote: >> >>> >>> >>> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) >> > wrote: >>> >>>> >>>> >>>> On 5/24/16, 2:42 PM, "Martin Thomson" wrote= : >>>> >>>> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) >>>> wrote: >>>> >>>We discussed this at quite some length. I originally took your >>>> >>>position, but the IVs add an extra layer of safety at very little >>>> >>>cost. >>>> >> >>>> >> I don=C2=B9t see any extra layer here. >>>> > >>>> > >>>> >The argument here is that there are only 2^128 keys and some protocol= s >>>> >have predictable plaintext. A predictable nonce would allow an >>>> >attacker to do some pre-calculation with a large number of keys to ge= t >>>> >a chance of a collision (and a break). It's a long bow, but not >>>> >entirely implausible. >>>> >>>> Ciphers use nonces are designed/proved to be secure when nonces are >>>> predictable: nonces are not random values. >>>> >>> >>> I think you may be misunderstanding. There is a time/space tradeoff her= e >>> when the >>> nonces are predictable that does not exist when they are random. This i= s >>> not a >>> vulnerability in the cipher and applies even if the keystream generator >>> at the core >>> of the cipher is PRF_k(nonce). >>> >>> -Ekr >>> >>> >>>> > >>>> >>>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> > --e89a8f2355651e2f8405339d1b46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If that is what you are worried about, then that would make = sense.

Quynh.

On May 24, 2016 4:23 PM, "Eric Rescorla&quo= t; <ekr@rtfm.com> wrote:
No, a smaller computation (say 2^{64}) and then collecting= 2^{40} connections all of which encipher the same plaintext (e.g., "G= ET /...")

-Ekr


On Tue, May 24, 2016 at 1:13 PM, Quy= nh Dang <quynh97@gmail.com> wrote:

Are you worried about 2^96 precomputation and the= risk of 1/2^32 of cracking your key?

Quynh.

On May 24, 2016 3:05 PM,= "Eric Rescorla" <ekr@rtfm.com> wrote:


On Tue, May 24, 2016 at 12:00 PM, D= ang, Quynh (Fed) <quynh.dang@nist.gov> wrote:


On 5/24/16, 2:42 PM, "Martin Thomson" <martin.thomson@gmail.com> wro= te:

>On 24 May 2016 at 10:46, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:
>>>We discussed this at quite some length.=C2=A0 I originally took= your
>>>position, but the IVs add an extra layer of safety at very litt= le
>>>cost.
>>
>> I don=C2=B9t see any extra layer here.
>
>
>The argument here is that there are only 2^128 keys and some protocols<= br> >have predictable plaintext.=C2=A0 A predictable nonce would allow an >attacker to do some pre-calculation with a large number of keys to get<= br> >a chance of a collision (and a break).=C2=A0 It's a long bow, but n= ot
>entirely implausible.

Ciphers use nonces are designed/proved to be secure when nonces= are
predictable: nonces are not random values.

<= div>I think you may be misunderstanding. There is a time/space tradeoff her= e when the
nonces are predictable that does not exist when they a= re random. This is not a
vulnerability in the cipher and applies = even if the keystream generator at the core
of the cipher is PRF_= k(nonce).

-Ekr


>



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--e89a8f2355651e2f8405339d1b46-- From nobody Tue May 24 16:23: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 E6CFC12B04A for ; Tue, 24 May 2016 16:23:12 -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 ia6lskbH2rWA for ; Tue, 24 May 2016 16:23:11 -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 9AE1A12D5C5 for ; Tue, 24 May 2016 16:23:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CBBB143342C; Tue, 24 May 2016 23:23:04 +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 AA238433404; Tue, 24 May 2016 23:23:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1464132184; bh=/SQJgj5q4V5dlm5BWG70bYztQ4+wdD+4HCkBoVBBG8A=; l=2404; h=To:References:From:Date:In-Reply-To:From; b=FmyzFYzOGMBwCBSDc/AfXhB86E8lRVlUN52moqfnPL2cxbW7dS104eFPZgghjE+vJ GF0FYUqlraVa5Qlz0ooukrQSZQLnzm6mQbQE4tLY82X9beId/lQL2R9Oi6rpwuk9Zb jPSc1XjQqzS3EgMkPThU6zGFtn8lPS28IcSrgUyg= 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 1B4E71FC99; Tue, 24 May 2016 23:23:04 +0000 (GMT) To: Yaron Sheffer , Eric Rescorla , "tls@ietf.org" References: <57417AFC.7030702@gmail.com> From: Benjamin Kaduk Message-ID: <5744E257.2020609@akamai.com> Date: Tue, 24 May 2016 18:23:03 -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: <57417AFC.7030702@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 23:23:13 -0000 Version -13 includes neither the word "stateful" nor "stateless", so if Yaron's proposal is taken, it would be better to explicitly refer to session tickets or ID-based resumption (with appropriate citations). That said, I'm not sure I see the need for a normative requirement on the server; we could note that the previous version required session invalidation and clients should not expect to be able to reuse sessions in this state, and leave it at that. (Or do that and drop to a MAY be invalidated.) -Ben On 05/22/2016 04:25 AM, Yaron Sheffer wrote: > This still makes the *stateful* implementation much more deterministic > and those implementations are common enough. So how about: > > Alert messages with a level of fatal result in the immediate > termination of the connection. In this case, other connections > corresponding to the session may continue, but the session identifier > MUST be invalidated, preventing the failed session from being used to > establish new connections. This requirement does not apply when the > server's implementation of session resumption is stateless. > > Thanks, > Yaron > > On 22/05/16 01:11, Eric Rescorla wrote: >> https://github.com/tlswg/tls13-spec/issues/471 >> >> >> http://tlswg.github.io/tls13-spec/#alert-protocol says: >> >> "Alert messages with a level of fatal result in the immediate >> termination of the connection. In this case, other connections >> corresponding to the session may continue, but the session identifier >> MUST be invalidated, preventing the failed session from being used to >> establish new connections." >> >> However, this is not consistent with a stateless implementation of >> session tickets. >> RFC5077 is a bit handwavy on this but implies that you shouldn't do this >> with tickets >> (see also [SBR04] for discussion of this). I propose we remove this >> requirement >> >> >> -Ekr >> >> >> [SBR04] Shacham, H., Boneh, D., and E. Rescorla, "Client-side >> caching for TLS", Transactions on Information and System >> Security (TISSEC) , Volume 7, Issue 4, November 2004. >> >> >> >> >> _______________________________________________ >> 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 Tue May 24 19:06: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 0E13312D188 for ; Tue, 24 May 2016 19:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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=eC1nspO3; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CHVoNy8P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLOdOqsh6Wiy for ; Tue, 24 May 2016 19:06:55 -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 7ABD112D0F2 for ; Tue, 24 May 2016 19:06:55 -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 u4P25nqP024049; Tue, 24 May 2016 19:06:54 -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 : content-transfer-encoding : mime-version; s=facebook; bh=vrZk3JhSdkrywUzdvW1Kfrqr/m3lvsVb6S7lNyjWFzs=; b=eC1nspO3L/Y2TnnsYa7y+ycWfda+5uU9ciQmB2yixGMGT783LuL0kjV/oMONbgpaUaih CFnIB84wHmipMyVvuYkMkQtxAvGFCD8xVkir6rOO21DaFvpfj/Gqhw7OonUTyTVNrAsI HgFj+vi4XSFzbc26NA2p3CrdmSLrYq8DgQc= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 234ywg8t5p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 May 2016 19:06:54 -0700 Received: from na01-bn1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 24 May 2016 22:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qt7XMJ5s28bfysXheLzM9+f5ECcFmOEnEjqyLGID+74=; b=CHVoNy8P9BXioF1iObB8Uzbqd+0X6XxY5oPGmXrZlpKMZ8CNSal3Mp+zmSveJuFov7e/OVXMvOsJTHoTPezBv6Zl1aJzlSjRuJXmiVDNb7kBN/ni3iDj+dXZ9bPcK9ONoqD+HiSdxCBTeW37nPPKSg9JUOpu/n/H0mERyJZL6+c= Received: from BLUPR15MB0275.namprd15.prod.outlook.com (10.162.232.26) by BLUPR15MB0273.namprd15.prod.outlook.com (10.162.232.24) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 25 May 2016 02:06:51 +0000 Received: from BLUPR15MB0275.namprd15.prod.outlook.com ([10.162.232.26]) by BLUPR15MB0275.namprd15.prod.outlook.com ([10.162.232.26]) with mapi id 15.01.0497.022; Wed, 25 May 2016 02:06:51 +0000 From: Kyle Nekritz To: Martin Thomson , Ilari Liusvaara Thread-Topic: [TLS] Asking for certificate authentication when doing 0-RTT Thread-Index: AQHRsQ8Scc6AdnpECkGEG7MzEe33vJ/CPQaAgAZfbgCAAEbxMA== Date: Wed, 25 May 2016 02:06:51 +0000 Message-ID: References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1:c37b] x-ms-office365-filtering-correlation-id: c8da4dd4-f7e5-43c9-f8af-08d384413cbe x-microsoft-exchange-diagnostics: 1; BLUPR15MB0273; 5:s9JLYh1fSZnrpRKLPXJyjMuCJ/zLnA+8PYeaCUed63G3/wD2lap5kfkKbuK2kUHdulwBzi2Y4wSlgsuC77o6Aq2u5yDq0t2zXa/7Z8huc+w5olIoBMkMah9JseKSaHs6gOuAEyGqBlMoRtvkyG65oA==; 24:B5IXoslnufa0BGCMt22SnIAT6RYqY6GCtsHj4ZZ7+N7uRctXQTcnc3TIKxxvNr2mOtDiG9AIV/KrdgZj4Rx83YP+xytaDhyR7Wrekrem2O4=; 7:0ZU7vp4MVyGbwkn5F5VepOJr8pCc0jqvj8wgllgi82yHfUp1GjT5piZCUmaPSwuvRGr2m/YD1SynYLTwNAQyVpisO1qUpB8ZIbIUFtfVHlZiUOXMmQAQN3lOcC9KGdRtNiQiZFb79H426hsH+AK0fCPvflBFOYKyyYvi9Mp60iIF3WwRpEnMqj+2iGwF6/hJ; 20:Mx8QPADJakzqYGwyCe8q6vHGY6kYjI07Xzifw/O0DK8F0QwIKlG4BusEJM0Jd90P3ZynVUUbWxUHmlYW901khb+TEQwGq2TBG1GbSujFjXKgPtC0ro3+/U1sazAdypy1346CycVkcBmqlWNb3FrLcPPxGgpfeR+0DT8SAAx1seE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR15MB0273; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR15MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR15MB0273; x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(77096005)(1220700001)(189998001)(5003600100002)(586003)(19580405001)(6116002)(19580395003)(99286002)(50986999)(102836003)(76576001)(106116001)(8936002)(81166006)(74316001)(122556002)(92566002)(8676002)(76176999)(5001770100001)(5002640100001)(2906002)(5008740100001)(575784001)(86362001)(3280700002)(11100500001)(2950100001)(5004730100002)(33656002)(54356999)(3660700001)(9686002)(87936001)(2900100001)(10400500002)(15975445007)(4326007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR15MB0273; H:BLUPR15MB0275.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 02:06:51.3135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR15MB0273 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-05-25_01:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Asking for certificate authentication when doing 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: Wed, 25 May 2016 02:06:57 -0000 What is the rationale for restricting a change in certificate? If the serve= r has a new certificate that the client would accept with a full handshake,= what threat is added by also accepting that certificate with a PSK handsha= ke? Requiring the certificate to remain the same will make rollout of a new cer= tificate more challenging (even with longer-lived certificates), particular= ly on distributed servers where the update is not immediate fleet-wide. It = will also add noise to metrics when rolling out a new certificate when idea= lly you want everything relatively constant (to be confident the new certif= icate is working properly). Kyle -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, May 24, 2016 5:00 PM To: Ilari Liusvaara Cc: tls@ietf.org Subject: Re: [TLS] Asking for certificate authentication when doing 0-RTT On 20 May 2016 at 12:41, Ilari Liusvaara wrote: > On Wed, May 18, 2016 at 10:10:29AM -0400, Martin Thomson wrote: >> I just posted this: >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf >> .org_doc_draft-2Dthomson-2Dtls-2D0rtt-2Dand-2Dcerts_&d=3DCwICAg&c=3D5VD0= R >> TtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7jPw&m=3DcJNWhprXjoJ1zN66VdIpTtq= s >> s54Z2N5U0l61Yj7RL_I&s=3Dhd6AtOpOp_1ULpSo_TRrpuxmTwQKZrjr6oz0Tm0hASs&e=3D >> >> It's fairly self explanatory. The idea is to create a way to signal=20 >> that the client wants the server to re-authenticate itself, even if=20 >> it successful in using a pre-shared key. > > - How is the capability signaled? New flag bits in session ticket > for these ciphersuites? I just uploaded -01 that corrects this oversight. I have raised https://github.com/martinthomson/tls-0rtt-and-certs/issues/1 which tracks whether certificates might change. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7= jPw&m=3DcJNWhprXjoJ1zN66VdIpTtqss54Z2N5U0l61Yj7RL_I&s=3D2divOhlUGndixU6HSAF= fmzyMt_Ufkc58GwbPbrg19GM&e=3D=20 From nobody Tue May 24 21:18: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 1D3DC12D606 for ; Tue, 24 May 2016 21:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukB2mvFs6CiA for ; Tue, 24 May 2016 21:18:29 -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 C558A12D602 for ; Tue, 24 May 2016 21:18:28 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n63so26639200qkf.0 for ; Tue, 24 May 2016 21:18:28 -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=3YG9F7cv0VPisvltetg/96DZtVuCNP58d4IPz2NDYFo=; b=BuwYMC45We0xR/S7yqWyYvE+5+0o6e6Nx1RmTyWpgmDMinkdvuLybCve/nCvwKV9zk 8ik8NHrwXXKJNv/cH+IJoX//STb6Cals33UR5SdvZZzlSWrJ2XEqhzR4YT0QswVJQqLm 0jpHsAuW4ZbEtbTYrLbkis6O+Cp0QpP0ZA7kJkAcydzPvNpHz41vBrr8a6VekHn2vF6Z 6sXJDkUQD/7jJM5KImGvKjUCX4vhUre6dD/cyFIOTpQuYnqPK4QagTdFfyusI0H6y6vS EP62IW66canbzSlrCyYJOgElrKi3n4yG0mLHvYtS1pJ+MuSzBHOQmXnzjIYSXMmke9y6 S6+w== 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=3YG9F7cv0VPisvltetg/96DZtVuCNP58d4IPz2NDYFo=; b=KomMXRq4i+xuKU7NUt519MJXejzIh7roMBVB6wkEo79JIADHVCljUEuEoC0hintaXz 5wRX+l6D867W1YoGlslu4rjaxylxjKgNGYhRrIDyFSW8kMowCs3rVrqs9HQudsy+iGgR C9zu9m2d0kjOHFtwXo3QBUFlIMkMmY7hSXNqmMBz721vHTRZ8/3r/7Sbw5puK4XxR8AA T7O6bNwv/uw6zBM/051UYEvH9y3iYT2I2o6S8Bi8f+C3rFVGC26x9aSAQCMT8kKR3RSn clu45olKJu52GERhw5X5FFOhHd/Upds0V7QNe+xjfVnE1jDe9o5wMmKy66F4sFA89Fw5 BdWg== X-Gm-Message-State: ALyK8tIgKPUkz1GANe5GPTlk2UYTzuAzQqb/G9AD5i/0sZcFU5kj1lHZPVSwXx4XuattaTLCjnJgq4DRk+70yg== MIME-Version: 1.0 X-Received: by 10.55.138.194 with SMTP id m185mr1699464qkd.48.1464149907899; Tue, 24 May 2016 21:18:27 -0700 (PDT) Received: by 10.140.104.70 with HTTP; Tue, 24 May 2016 21:18:27 -0700 (PDT) In-Reply-To: References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 24 May 2016 21:18:27 -0700 Message-ID: From: Martin Thomson To: Kyle Nekritz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Asking for certificate authentication when doing 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: Wed, 25 May 2016 04:18:30 -0000 On 24 May 2016 at 19:06, Kyle Nekritz wrote: > What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake? This was a request from David Benjamin. But then all the things you mention are why I think that it might have been a bad idea. I think that the idea was to avoid unnecessary changes. Changes that might regress the security decisions made originally. It was the most conservative choice without thinking about the problem too much. However, if we model this as new connection + 0-RTT stuff, then I think that we are good. Probably. If anyone disagrees it would be good to hear that. From nobody Wed May 25 08:47: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 8CC6112D7CF for ; Wed, 25 May 2016 08:47:24 -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 kh4gy9RgXeT9 for ; Wed, 25 May 2016 08:47:22 -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 D650612D7A2 for ; Wed, 25 May 2016 08:47:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0B8B3433443; Wed, 25 May 2016 15:47:18 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E8902433404; Wed, 25 May 2016 15:47:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1464191237; bh=Z1HIQpO82kK3+NJBDvjJLWOR425W6bBM9H2RiNbOsLI=; l=1898; h=To:References:Cc:From:Date:In-Reply-To:From; b=tf2UQkWlg1wISoWOlHiRiS5AmnLdhcSw9yFHpz42R6yvwLFd+nMzyQLizuTqZGQg/ sR12RzBABfBOrLCJLv0OxrB6i/DVJoufwXCUsFqkPLWQDqNRZRTlnAkiKxp1pmMjs4 G9etLlYbQ5g73ZYunZTmpa18dem7AYEHIsCscSwE= 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 AC3001FC9F; Wed, 25 May 2016 15:47:17 +0000 (GMT) To: Martin Thomson , Kyle Nekritz References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <5745C905.4090506@akamai.com> Date: Wed, 25 May 2016 10:47:17 -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=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Asking for certificate authentication when doing 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: Wed, 25 May 2016 15:47:24 -0000 On 05/24/2016 11:18 PM, Martin Thomson wrote: > On 24 May 2016 at 19:06, Kyle Nekritz wrote: >> What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake? > This was a request from David Benjamin. But then all the things you > mention are why I think that it might have been a bad idea. I think > that the idea was to avoid unnecessary changes. Changes that might > regress the security decisions made originally. It was the most > conservative choice without thinking about the problem too much. > > However, if we model this as new connection + 0-RTT stuff, then I > think that we are good. Probably. If anyone disagrees it would be > good to hear that. > It seems like it's kind of messy either way -- if the cert changes, the client has to check the chain of course, but it also ought to confirm that it's still talking to "the same party" [0] that it was before, so it is not sending data to someplace it didn't expect. A scenario where an attacker can break the 0-RTT crypto and swap in an attacker-controlled certificate is admittedly a bit far-fetched (other things would probably be broken, too), but what about a mis-configured shared host that can accept the 0-RTT for the original site but then mistakenly presents a cert for a different site that is hosted there [and sends the data off to the wrong backend]? If we prevent the cert from changing, then yes there's the added complexity for deploying cert updates. It's not even clear that doing a 0-RTT reject when the server wants to change cert would fix everything, though it might help some. -Ben [0] Somehow I don't think there's a good way to express the "same party" check that works everywhere. From nobody Wed May 25 14:55: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 7D4A512D1B1 for ; Wed, 25 May 2016 14:55:07 -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 SgJv_1oPzF0t for ; Wed, 25 May 2016 14:55:05 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9858612D16D for ; Wed, 25 May 2016 14:55:05 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id l10so36763679igk.0 for ; Wed, 25 May 2016 14:55:05 -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=Yuco0b5+EkZZS/iYmkCFSuXFPHE4Vu7wR81VXDNJT34=; b=pdM6JBXWGFuZiSePzAInSXFfDFcXo2NuqhUIHfqekEyoDUirWukAUx5OxRFpaSmhpX d/zJpHJVK7tq77en21QQR9PxyukxJwzy84k2r8ftVni21zkkrcdFvhnxY2uur+yVsxGZ Ms4ZoDFkGUgWj9gBst9HMZ+LHvMfLa5zB0i6aXm+SQqdduccVfWFWFDN7si28J1MvZoH hYahADi/Lf0haWguh+UJxvwB0dNxZHDGnIzgXrD/SMhGjlPbL89AKySfy/U9UbWNr11u AS8kaKIDbEJlNuuSBIN4FNJXq5rOMhTzSPh9Li4nWKBDblU/VzctYB5np4x955iOwNTh VyoA== 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=Yuco0b5+EkZZS/iYmkCFSuXFPHE4Vu7wR81VXDNJT34=; b=FbOq+ISwaeBPGEt6yuHcMWFaEDRBIynwtD95rRrAlCDaBBGko+OYhWybA6OQNLRbkl IXXTMcijUPE3Zx9iK4Bm3WJ7HbGpoo6lqOhR59ADrRhEndDvo0spqqFfK6Avy5IuCdBP VNJu277RQVsLb8WzbyMnPZUpjB2Pwnir00EtpGNkZqtOiKpbU4ygO8MAGqxFVR97vAoe SX2B0ZakXJ/SjzZy19NwvNXY1/lONMrTRtzqg3Cue06M3HSOP+WnNbj3qN+iB0wLV/8D n6XSS7eRiwc8hp3k/6XmsZ+X/n8xAd2L8Sp4h9/wJBwq9YK1H+8Ui9NhLoYogIoRUEjZ Y+Rg== X-Gm-Message-State: ALyK8tJpDOA0s4xONFZQWkwv1oRPdOJjiv73QoqGjOIlkk4WJZ1hxLdEs9KzozQGDv0lw6e9DBdguyrd5Qr/dQ== MIME-Version: 1.0 X-Received: by 10.200.54.108 with SMTP id n41mr6163680qtb.18.1464213304900; Wed, 25 May 2016 14:55:04 -0700 (PDT) Received: by 10.140.104.70 with HTTP; Wed, 25 May 2016 14:55:04 -0700 (PDT) Received: by 10.140.104.70 with HTTP; Wed, 25 May 2016 14:55:04 -0700 (PDT) In-Reply-To: References: <20160520194115.GA5467@LK-Perkele-V2.elisa-laajakaista.fi> <5745C905.4090506@akamai.com> Date: Wed, 25 May 2016 14:55:04 -0700 Message-ID: From: Martin Thomson To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a113f35f2ea01800533b1b95d Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Asking for certificate authentication when doing 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: Wed, 25 May 2016 21:55:07 -0000 --001a113f35f2ea01800533b1b95d Content-Type: text/plain; charset=UTF-8 I think that there are four levels of continuity that make sense here : 1. None. Anthony can change. 2. Server name. I.e. SNI stays constant. 3. Public key (and SNI) stays constant. 4. The certificate stays the same. The use case of short-lived certs is served by 2. 3 might also work. I think that 4 is too restrictive, as we have established. 1 just doesn't seem plausible, since the psk_identity will be cached against a name in almost every case I can imagine. On 26 May 2016 01:47, "Benjamin Kaduk" wrote: On 05/24/2016 11:18 PM, Martin Thomson wrote: > On 24 May 2016 at 19:06, Kyle Nekritz wrote: >> What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake? > This was a request from David Benjamin. But then all the things you > mention are why I think that it might have been a bad idea. I think > that the idea was to avoid unnecessary changes. Changes that might > regress the security decisions made originally. It was the most > conservative choice without thinking about the problem too much. > > However, if we model this as new connection + 0-RTT stuff, then I > think that we are good. Probably. If anyone disagrees it would be > good to hear that. > It seems like it's kind of messy either way -- if the cert changes, the client has to check the chain of course, but it also ought to confirm that it's still talking to "the same party" [0] that it was before, so it is not sending data to someplace it didn't expect. A scenario where an attacker can break the 0-RTT crypto and swap in an attacker-controlled certificate is admittedly a bit far-fetched (other things would probably be broken, too), but what about a mis-configured shared host that can accept the 0-RTT for the original site but then mistakenly presents a cert for a different site that is hosted there [and sends the data off to the wrong backend]? If we prevent the cert from changing, then yes there's the added complexity for deploying cert updates. It's not even clear that doing a 0-RTT reject when the server wants to change cert would fix everything, though it might help some. -Ben [0] Somehow I don't think there's a good way to express the "same party" check that works everywhere. --001a113f35f2ea01800533b1b95d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think that there are four levels of continuity that make s= ense here :

1. None. Anthony can change.
2. Server name. I.e. SNI stays constant.
3. Public key (and SNI) stays constant.
4. The certificate stays the same.

The use case of short-lived certs is served by 2. 3 might al= so work. I think that 4 is too restrictive, as we have established. 1 just = doesn't seem plausible, since the psk_identity will be cached against a= name in almost every case I can imagine.

On 26 May 2016 01:47, "Benjamin Kaduk"= <bkaduk@akamai.com> wrote:<= br type=3D"attribution">
On 05/24/2016 11:18 PM, Martin Thomson wrote:
> On 24 May 2016 at 19:06, Kyle Nekritz <knekritz@fb.com> wrote:
>> What is the rationale for restricting a change in certificate? If = the server has a new certificate that the client would accept with a full h= andshake, what threat is added by also accepting that certificate with a PS= K handshake?
> This was a request from David Benjamin.=C2=A0 But then all the things = you
> mention are why I think that it might have been a bad idea.=C2=A0 I th= ink
> that the idea was to avoid unnecessary changes.=C2=A0 Changes that mig= ht
> regress the security decisions made originally.=C2=A0 It was the most<= br> > conservative choice without thinking about the problem too much.
>
> However, if we model this as new connection + 0-RTT stuff, then I
> think that we are good.=C2=A0 Probably.=C2=A0 If anyone disagrees it w= ould be
> good to hear that.
>


It seems like it's kind of messy either way -- if the cert change= s, the
client has to check the chain of course, but it also ought to confirm
that it's still talking to "the same party" [0] that it was b= efore, so
it is not sending data to someplace it didn't expect.=C2=A0 A scenario = where
an attacker can break the 0-RTT crypto and swap in an
attacker-controlled certificate is admittedly a bit far-fetched (other
things would probably be broken, too), but what about a mis-configured
shared host that can accept the 0-RTT for the original site but then
mistakenly presents a cert for a different site that is hosted there
[and sends the data off to the wrong backend]?

If we prevent the cert from changing, then yes there's the added
complexity for deploying cert updates.

It's not even clear that doing a 0-RTT reject when the server wants to<= br> change cert would fix everything, though it might help some.

-Ben


[0] Somehow I don't think there's a good way to express the "s= ame party"
check that works everywhere.
--001a113f35f2ea01800533b1b95d-- From nobody Fri May 27 07:55: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 BC6F312D615 for ; Fri, 27 May 2016 07:55: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 c96vfup2EZqp for ; Fri, 27 May 2016 07:55:13 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A1412D593 for ; Fri, 27 May 2016 07:55:12 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id z87so140240772wmh.0 for ; Fri, 27 May 2016 07:55:12 -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=Li6hSk0lc67apidz8YLQJ3YIoxgBTAiwym73AUS0az0=; b=DAsggG3meqzKt5pqNZ5g3mo1upUxGOmzwg5KcUAXwJH5Dt0W0V3JHfuFOSFltB7UfY irvHZ/wl/j9pcBz+EcSn6imRvUc6s+9eKhatkfpvj9gByF5aKz5kj+B1ZJOSRbsSW5KV Vbe9rjMOEa14z80H43pnmLNIVObA+MKbP2/II= 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=Li6hSk0lc67apidz8YLQJ3YIoxgBTAiwym73AUS0az0=; b=KqJzWYrGS6HXAFgxg3kwyySwc//Z+l+Vg2s0JzCdK+RYPjl+6kVIw1FDYX14z04Hmx dfk970MSsUYfePc+2pWtRybs13OYTdntWa2Qu/S8iUMJyG+QJ+gOW7OE/1qLIhcY78fG UdSBDw89ctFnz2BfVAaFGNO+LkSAK/iNqQlSClvJzQCvDTdwjHTWaflHCT6y9NcbpVvw ZjmwoX87tu80DQULVEBqgAEa5OMC5U/efqCz1FDnD4g0IIhPJxdObc1yd+ADwJJ3OAwQ GRVbxq2oCGdNS2SfZKUXCCONoIG5btjp/ndFAJEUCiWwCzt0Euoak5/izVwOyzTKTex9 ysVw== X-Gm-Message-State: ALyK8tKvhlmY60bdBwbKEksrSt12BKFjqc5uLYiNFYC9IVLMGZ6gjc8BHcQLDpW0EZwQAg== X-Received: by 10.194.184.169 with SMTP id ev9mr15039323wjc.27.1464360911313; Fri, 27 May 2016 07:55:11 -0700 (PDT) Received: from [10.172.6.236] ([91.143.127.68]) by smtp.gmail.com with ESMTPSA id hm7sm19725314wjb.41.2016.05.27.07.55.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 May 2016 07:55:10 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2FD6F0C8-D38D-4182-AB3B-CC5FE41BB177@sn3rd.com> Date: Fri, 27 May 2016 16:55:07 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] adopted: draft-shore-tls-dnssec-chain-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: Fri, 27 May 2016 14:55:15 -0000 It appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-shore-tls-dnssec-chain-extension based on this thread: https://mailarchive.ietf.org/arch/msg/tls/ymEtvciDKGgI2JrGP6wlV7XWy7I =20= We're hoping that we can maintain focus and get this extension published = quickly. Authors, If draft-ietf-tls-dnssec-chain-extension works as a draft name let us = know and one of us can pre-approve the draft so we can start moving this = draft through the process. Thanks!=20 J&S= From nobody Fri May 27 07:55: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 E2EEA12D659 for ; Fri, 27 May 2016 07:55:18 -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 6wFreEA-Kuku for ; Fri, 27 May 2016 07:55:17 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349BA12D5B5 for ; Fri, 27 May 2016 07:55:17 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a136so76749884wme.0 for ; Fri, 27 May 2016 07:55:17 -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=2gV32v/oZ/OOPeqvVB0exGzTqXQaJQbGSu+O8G2Cdkw=; b=j0hOhfEh+cLVrg9+x4rvDCBlCr060GRgjwArvzCVnFfNHWeRb/spYsdddLum6MhJMJ K0eQPMWZJ7DSto9Z12CFVoJAaidnur5L9P//3O/8pFfS4uLSeI9zex9uj16G/e5bMEgZ G7dY8BqQkJuANCBKNKDiMJq8Lxe32zIeyGVVw= 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=2gV32v/oZ/OOPeqvVB0exGzTqXQaJQbGSu+O8G2Cdkw=; b=KCFoDnJNJzZxFb1sI+7KOPs5azRC9BO+rDwMy7JWOpcMQcBm/yZxoQWUre6n9d7n4E xe2yRkBtGI+cNYDEi9xnH71Zzmv2mV0diYHBQLtu4HHPn+h0DIUIwjx/RRRy1dkqgVcw 9l8R+KKRjT/JAuy7oC3LCb8FRpxIeSPFE7HYibR5r1OS+TqaXMjzpcx9KlU1uY5DI8wZ D1NRF9Nx1KFRWA38FV+VRf5pN35MwpkMbxgplsvcgpbgUK/xHax1WZY+kQh2cwmznD7g Zb3sLtrwWext4R6TthLQw2sLhJpjOjc8ujcJcLxxMTBpAtlDeSdub3LdyIDiu9T8Xn+E W7BA== X-Gm-Message-State: ALyK8tLIviDq6551sCs37ppLkcz4TUgPMAj+//XWYeGT2Hg8dPABLMayU8ShnmP5yUv1eg== X-Received: by 10.194.18.18 with SMTP id s18mr16470606wjd.100.1464360915789; Fri, 27 May 2016 07:55:15 -0700 (PDT) Received: from [10.172.6.236] ([91.143.127.68]) by smtp.gmail.com with ESMTPSA id hm7sm19725314wjb.41.2016.05.27.07.55.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 May 2016 07:55:15 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <07BF37A2-CD5E-4C54-B829-0316D556EF9F@sn3rd.com> Date: Fri, 27 May 2016 16:55:08 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] adopted: draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 14:55:19 -0000 I appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-mattsson-tls-ecdhe-psk-aead based on this thread: https://mailarchive.ietf.org/arch/msg/tls/JuC5Fba5PSsPenRvLGIUdYuFYeI Note that this draft will be published using new the IANA registrations = rules we=E2=80=99ve discussed so it=E2=80=99ll probably get pinned = waiting for the TLS1.3 draft to be published. Also, we should probably = just go ahead and get the early IANA code point assignment done, but = we=E2=80=99ll do that in another thread. Authors, If draft-mattsson-tls-ecdhe-psk-aead works as a draft name let us know = and one of us can pre-approve the draft so we can start moving this = draft through the process. Thanks!=20 J&S= From nobody Fri May 27 08:59: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 879F112D67F for ; Fri, 27 May 2016 08:59: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=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 Tmnu5nOlhK00 for ; Fri, 27 May 2016 08:59:13 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111FF12D6AD for ; Fri, 27 May 2016 08:59:13 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id ct2so22383869igb.0 for ; Fri, 27 May 2016 08:59:13 -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:content-transfer-encoding; bh=J1+NdwSZol7KPbgsNEWLCH7uzTY7nwYjWntSZIXsb3w=; b=UJYxbq7ghc7rKaeizP8dB8MEZ6uWrLCtV8j5yL5kG86MCnpm9hVv+6CsC0+7D3qlUb QdnWpKeCklUQNBaV2965QbuWNLLYa+CU1cUm0lc4oK8PZCutKIeT+4rQqu3HF06ufzrc 1R82+7paFQhqEKfG2xe3mMbP1Y5t6/SJYvIQDhUyu45ipB1MeT0FtWxXLczqKLiQIX3X XV13OZ3yvwoKtAfGc1eYTW9m4wS1/Asu3pLFB4OpHDKao27DF7nYhn/TwIJAKinkDhu3 oedc4Tb/4A0PGWSnfGpNBbTUAVK3+3FAU4sfUXhCtgvbQ2vYALWmkU1vTlzBjkLiIw91 qY/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=J1+NdwSZol7KPbgsNEWLCH7uzTY7nwYjWntSZIXsb3w=; b=ki5xlsFos24+qyUbWml+Zml+ryb9vOA/I97eLTX81TJ89O0Va6uj6q4iL9YpxFd1v6 k2BoUdobFOSuAGguhS8l28etjn/5DT2TqEcUVoq/aECAFj6US8x+h+xVi8WnJ/2rJqKF yxkEzB1vVMWp6s1aEITv91tyqaPCPCuumhar/E8XX3HeBLS8lpleRaAcgJsK41HuAubc MIUrE2wuuXeuYkKqxlT0br5HmA3NfcF1LifGAL2GXFc3jPpJiPzdcHnjODAFFuiW7Znw C/jU+KaKzk11D1ypvYhRFZ9rEMgxQfBFrmtm6hsZswC6YpMYSSnWOFEBfXDkWwsSsTMr F87A== X-Gm-Message-State: ALyK8tIDVZlIcyB20ebXzlLtG4MuAi7/GFxn1ayvh4sG69kjdBjonSJE45bw1iFzdewOf29GnpQIRe46elWPfw== MIME-Version: 1.0 X-Received: by 10.50.63.5 with SMTP id c5mr8625109igs.56.1464364752356; Fri, 27 May 2016 08:59:12 -0700 (PDT) Received: by 10.36.202.196 with HTTP; Fri, 27 May 2016 08:59:12 -0700 (PDT) In-Reply-To: <07BF37A2-CD5E-4C54-B829-0316D556EF9F@sn3rd.com> References: <07BF37A2-CD5E-4C54-B829-0316D556EF9F@sn3rd.com> Date: Fri, 27 May 2016 17:59:12 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] adopted: draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:59:15 -0000 On Fri, May 27, 2016 at 4:55 PM, Sean Turner wrote: > I appears that we=E2=80=99ve got enough consensus/interest to adopt draft= -mattsson-tls-ecdhe-psk-aead based on this thread: > https://mailarchive.ietf.org/arch/msg/tls/JuC5Fba5PSsPenRvLGIUdYuFYeI [...] > Authors, > > If draft-mattsson-tls-ecdhe-psk-aead works as a draft name let us know an= d one of > us can pre-approve the draft so we can start moving this draft through th= e process. I assume you intended to write "draft-ietf-tls-ecdhe-psk-aead" here? --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Fri May 27 09:19: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 24D4D12D6F8 for ; Fri, 27 May 2016 09:19:17 -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 gIo3rZPhVZ_f for ; Fri, 27 May 2016 09:19:15 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D31912D6F6 for ; Fri, 27 May 2016 09:19:15 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id e93so52932228qgf.2 for ; Fri, 27 May 2016 09:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OGPO4Plg2FJFjsvZU8NxY6q7Cf8F+WQqq1U8VMl5KwA=; b=CsK/i1uNteRyHEX/JxAz/0gRZZEY8bzJM+7OfaqU9cpSg2sEYpy4OluyA20m2Gl9tO xnEV/QG74c8HPiC6OdZGagF0MpUFHc7yPNeeGbLxpX8baforLEwGmubcqNmCaER1A262 gNIm2Ea9DaNmpPe0JuFf2pOrKnu+mmYGPsFE0= 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=OGPO4Plg2FJFjsvZU8NxY6q7Cf8F+WQqq1U8VMl5KwA=; b=b63oKxmy67TsEBwVd5eohmUAZTN+X+bUOPeihD1qNPkPcEoiUjv8A3SqCOaOlAkDOn I+8L0wF2n6iT8IbXwJxoCpBhGMEcJc+yc1ob0+Bl0zu9I0RcV6G/kgcMXm6WRpYFIy+D BRyGdL4dQzGLQIX97MPrRX0Fep2jU5sRR+fJNgXzFA+Guk8wJ92FuEx1/3GDQQX0Nnf9 yjVk1YvjK7FMs078JMoYNWFbv6nZSFx7HDlUaUAwXa7R+WTyCFn/Yb70oZ4oBEVDCwAU FEMfdP84IpBUh+b3MQAADC43/8fj0bzKUnSC0QoYbzJNtGg1UYMvpFvsCHH+eNjtx0Up BmPw== X-Gm-Message-State: ALyK8tLIUJuofya9pEyICSlMdjrsOT7jz1F4weXfSoJCy9PRVWYzVwJUvn8jQPm6eKKfuw== X-Received: by 10.140.38.165 with SMTP id t34mr14031401qgt.47.1464365954653; Fri, 27 May 2016 09:19:14 -0700 (PDT) Received: from [5.5.33.121] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id t77sm2084927qgt.20.2016.05.27.09.19.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 May 2016 09:19:13 -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: Fri, 27 May 2016 18:19:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BCFB7D0-3B9D-4FD3-A75E-D13DCCAA5043@sn3rd.com> References: <07BF37A2-CD5E-4C54-B829-0316D556EF9F@sn3rd.com> To: =?utf-8?Q?Henrik_Grubbstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] adopted: draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 16:19:17 -0000 On May 27, 2016, at 17:59, Henrik Grubbstr=C3=B6m = wrote: >=20 > On Fri, May 27, 2016 at 4:55 PM, Sean Turner wrote: >> I appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-mattsson-tls-ecdhe-psk-aead based on this thread: >> https://mailarchive.ietf.org/arch/msg/tls/JuC5Fba5PSsPenRvLGIUdYuFYeI > [...] >> Authors, >>=20 >> If draft-mattsson-tls-ecdhe-psk-aead works as a draft name let us = know and one of >> us can pre-approve the draft so we can start moving this draft = through the process. >=20 > I assume you intended to write "draft-ietf-tls-ecdhe-psk-aead" here? drat - yes I=E2=80=99ve pre-approved "draft-ietf-tls-ecdhe-psk-aead". spt= From nobody Fri May 27 10:19:36 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 110F012D521; Fri, 27 May 2016 10:19:35 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 10:19:35 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.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, 27 May 2016 17:19:35 -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 : 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/ From nobody Fri May 27 13:18: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 8FEAC12D127 for ; Fri, 27 May 2016 13:18:00 -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 hmlfpwzTHyTM for ; Fri, 27 May 2016 13:17:59 -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 BA53C12D0AB for ; Fri, 27 May 2016 13:17:58 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a136so6515966wme.0 for ; Fri, 27 May 2016 13:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=bfrxBJA6VNs78fODl81AN2CBnND8+v1lvHYZvEMJlwg=; b=hEukkx9wtIF1gBLdNHrMGlKHsy91fYOIY9Ge2wkHmLgZw5s0usvu8+gai3cvjRoSgK PAR/Hs8Oo1CARt/TI9jIR5XReSbfImmuyvDpDf/QkyYNYNbh1+HJ+irv8citd5PfHYQt aw8OVpcsmOaFHpM03bJEkR8aeoWJtzCjn4/ZOloHsPpZjl6H6f8a5Wgn349O93A5gn/F l3T/f++u+J+mlpCfsLflG3O4klGyjPm/GIX6xbPoPCJSTubAhtdihYrHq8lPteTm9bZe ViZyqPAHadt/u3M7MajMg5jSTFvBs87apV+P4OeH1fRq9hXj5pugATGcmVEYNRp1CoK4 zqYg== 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:date:message-id:subject:from :to; bh=bfrxBJA6VNs78fODl81AN2CBnND8+v1lvHYZvEMJlwg=; b=bea4RNvUGaPoCofnTMq6PLBZuyjjxSX7R2MphIyopexlxmmL2lGxW11IvgRmTjIH0l HPHrhk+2USf/c9o6YeJowHPnVa6LJd8s/wtfGJSBgBo+w3H1QA2w40J/qH7GoXfcMRu+ QkBKhQlIRarkDcOU7u2JGpJP4GtWbi7RmJtY4g9QAMjubugIqApvpFCRK2MiwRw5c9mt wr1dNG6CK38WS/7T8mEMTNz480ylyN+qNfma/llzMskTEkuj9LLQLokHi5tC+lwgwEAe qeAxc4QMa7NabBEMof7wC/EsbvEY3E8DMWi/rctxhoMj7KL2uueT2k/PnXQIS19CXTo9 Q8zA== X-Gm-Message-State: ALyK8tJaYs07MP/iMV9DEWdVvCIM4/habZiWPFnXOJHY2vAt+nrNOllHRkumvK7rl1r7ei8PloGsjAWCs5rf6A== MIME-Version: 1.0 X-Received: by 10.28.103.2 with SMTP id b2mr424515wmc.28.1464380277092; Fri, 27 May 2016 13:17:57 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.236.1 with HTTP; Fri, 27 May 2016 13:17:57 -0700 (PDT) Date: Fri, 27 May 2016 16:17:57 -0400 X-Google-Sender-Auth: zYOgcwSBEP82HcOWBAWEebJwWYk Message-ID: From: Daniel Migault To: tls Content-Type: multipart/alternative; boundary=001a114af9083b7cae0533d89a11 Archived-At: Subject: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 20:18:00 -0000 --001a114af9083b7cae0533d89a11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have a few comments while reading 4.8.1 Digital Signature of draft-tls-tls13.Hope it helps. BR, Daniel Comment a) "In previous versions of TLS, the ServerKeyExchange format meant that attackers can obtain a signature of a message with a chosen, 32-byte prefix= . " My understanding is that the ServeKeyExchange format defines the bits exchanged between the TLS Client and the TLS Server. I think the attack vector is more coming from how the signatures are computed. I would rather propose something like: "In previous version of TLS, the signature of the ECDH or EDH public key is performed by concatenating the client random, the server random to the public keys. The concatenation is hash and then signed. As the client random is chosen by the TLS CLient, such design allows an attacker to obtain a signature of a message with a chosen 32-byte prefix." Comment b) "Because TLS 1.3 servers are likely to also implement prior versions, the contents of the element always start with 64 bytes of octet 32 in order to clear that chosen-prefix. I think some additional steps need to be explicitly specified. I am not completely sure of what is being signed. a) padding + context + H(client.random + server + random + ECDHE/DHE Params) OR b) padding + context + client.random + server + random + ECDHE/DHE Params OR c) padding + context + ECDHE/DHE Params OR d) something else I assume that is a) in which case, the reason for choosing this format is to constraint changes between TLS versions at the signing module. In addition, if the correct scheme is a) maybe some additional text or reference could explain why the padding and context solves this problem. By prepending a fixed padding and some context, to the output of the hash function, the TLS Client does not control the input that is signed as cryptographic hash function are expected to be non-invertible. Comment c) "A single 0 byte is appended to the context to act as a separator." When describing how the input to be signed is built, it may be clearer to emphasize that string ends with 0, whihc leads to a "00" separator. I would propose to add something like: "As the string ends with a "0" byte, the binary representation will results in two zero bytes." Comment d) It would help the reader to add that =E2=80=9CExample=E2=80=9D is represent= ed in hexa by 4578616d706c650 with the end of string character. --001a114af9083b7cae0533d89a11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a few comments while re= ading 4.8.1 Digital Signature of draft-tls-tls13.Hope it helps.

BR,
Daniel

Comment a)
"In previous versions o= f TLS, the ServerKeyExchange format meant that attackers can obtain a signa= ture of a message with a chosen, 32-byte prefix. "
My understanding is that the ServeKeyExchange form= at defines the bits exchanged between the TLS Client and the TLS Server. I = think the attack vector is more coming from how the signatures are computed= . I would rather propose something like:

"In previou= s version of TLS, the signature of the ECDH or EDH public key is performed = by concatenating the client random, the server random to the public keys. T= he concatenation is hash and then signed. As the client random is chosen by= the TLS CLient, such design allows an attacker to obtain a signature of a = message with a chosen 32-byte prefix."

Comment b)
"Because TLS 1.3 servers = are likely to also implement prior versions, the contents of the element al= ways start with 64 bytes of octet 32 in order to clear that chosen-prefix.<= /span>

I think some additional steps need to be explicitl= y specified. I am not completely sure of what is being signed.=C2=A0
= =C2=A0=C2=A0=C2=A0 a) padding + context + H(client.random + server + random= + ECDHE/DHE Params)
OR
=C2=A0=C2=A0=C2=A0 b) = padding + context + client.random + server + random + ECDHE/DHE Params
O= R
=C2=A0=C2=A0=C2=A0 c) padding + context + ECDHE/DHE Params
OR
=C2=A0=C2=A0 d) something else

I assu= me that is a) in which case, the reason for choosing this format is to cons= traint changes between TLS versions at the signing module. In addition, if = the correct scheme is a) maybe some additional text or reference could expl= ain why the padding and context solves this problem. By prepending a fixed = padding and some context, to the output of the hash function, the TLS Clien= t does not control the input that is signed as cryptographic hash function = are expected to be non-invertible.


Commen= t c)

"A single 0 byte = is appended to the context to act as a separator."

When describing how the input to be signed is built, it may be cleare= r to emphasize that string ends with 0, whihc leads to a "00" sep= arator. I would propose to add something like: "As the string ends wit= h a "0" byte, the binary representation will results in two zero = bytes."


Comment d)

=C2=A0
It would help= the reader to add that =E2=80=9CExample=E2=80=9D is represented in hexa by= 4578616d706c650 with the end of string character.




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

--001a114af9083b7cae0533d89a11-- From nobody Fri May 27 14:59: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 67CC912D1B0 for ; Fri, 27 May 2016 14:59:01 -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 KpImrTJO9obJ for ; Fri, 27 May 2016 14:58:59 -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 4148912D11F for ; Fri, 27 May 2016 14:58:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id o16so118126286ywd.2 for ; Fri, 27 May 2016 14:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sabG1mYojMCv2PCTns3iRFmLEYG7iAX5rCH1W3jHAe4=; b=JLdGknD543uWcDbE3pT069VEQsfTArXI5Bl84xX1ITGkv4ycMY4JAjNXYl5D24kRyN YXMQkznPwUFF9NBuzF6AMY1DgoCKTXXNDYpRXzmk6RNjeQkt4fR9WOS+0K6QHEpYlCrb 26kzCER8SH8yTsEEZfJ3hwBnDRUQ2xdTmX0aoZ+7OVx95bR5qRswe1FgbgG6O/CahLwy qlvZZJF9ZAizWw1BbuS34Ai3V9MnY7k2D7d+bdl858XCkKBTn98qsKJIaIY/c05a7861 Xnr9Q5PGy6Ft9+DGtnQIOhcsAztPoZ8wT8t27U7eb4PNVh0ZARBqnhQr2U05drn0Io5D I8Fw== 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=sabG1mYojMCv2PCTns3iRFmLEYG7iAX5rCH1W3jHAe4=; b=h6FJdlGZP3zLaoSTL4RFEUTCRSr58wSKkq1S7nKCm1pCZ0b6AFBN2pApMdeGSRl5E/ UJa/gbza5idFjIMOzMFEv8SM77dDpTAcFCE9jLKi4RnLNpcW95neC5jhBflhXwYFiREG K17V7KNzTT8jWt116KT+irtagVffi3ac6tE17Z4bLa1Tozh6XmzoTk5ytMhtktJCcEWN mtnm/Gqrx61RlV5mCeChtz6w/lh+fcsNcLhDBUhstsyBbnESUpwEZOYo8JrvI6eI2uQQ DbMgfhKHgpYdjLIthKjem9JWDgaB6yJJvPWf8H8xiCVcOjhuhMzzo8DDpQ69y9JkyW80 o4Pw== X-Gm-Message-State: ALyK8tJ1lqpuxmMsd9TCa91TENlfV93rG8+RUkaxT/6BHUHyrYJMOsw5epLeZwr20p4uDA5ufMFvaFc+KZFzhQ== X-Received: by 10.13.233.1 with SMTP id s1mr9830035ywe.286.1464386338492; Fri, 27 May 2016 14:58:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 27 May 2016 14:58:19 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 27 May 2016 14:58:19 -0700 Message-ID: To: Daniel Migault Content-Type: multipart/alternative; boundary=94eb2c07cfb48549ba0533da03db Archived-At: Cc: tls Subject: Re: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 21:59:01 -0000 --94eb2c07cfb48549ba0533da03db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2016 at 1:17 PM, Daniel Migault wrote: > Hi, > > I have a few comments while reading 4.8.1 Digital Signature of > draft-tls-tls13.Hope it helps. > > BR, > Daniel > > Comment a) > "In previous versions of TLS, the ServerKeyExchange format meant that > attackers can obtain a signature of a message with a chosen, 32-byte pref= ix. > " > > My understanding is that the ServeKeyExchange format defines the bits > exchanged between the TLS Client and the TLS Server. I think the attack > vector is more coming from how the signatures are computed. I would rathe= r > propose something like: > > "In previous version of TLS, the signature of the ECDH or EDH public key > is performed by concatenating the client random, the server random to the > public keys. The concatenation is hash and then signed. As the client > random is chosen by the TLS CLient, such design allows an attacker to > obtain a signature of a message with a chosen 32-byte prefix." > Hmm... I'm not sure this makes it much clearer. How about "The computation of the signature in the ServerKeyExchange...." Comment b) > > "Because TLS 1.3 servers are likely to also implement prior versions, the > contents of the element always start with 64 bytes of octet 32 in order t= o > clear that chosen-prefix. > > I think some additional steps need to be explicitly specified. I am not > completely sure of what is being signed. > a) padding + context + H(client.random + server + random + ECDHE/DHE > Params) > OR > b) padding + context + client.random + server + random + ECDHE/DHE > Params > OR > c) padding + context + ECDHE/DHE Params > OR > d) something else > > I assume that is a) in which case, the reason for choosing this format is > to constraint changes between TLS versions at the signing module. In > addition, if the correct scheme is a) maybe some additional text or > reference could explain why the padding and context solves this problem. = By > prepending a fixed padding and some context, to the output of the hash > function, the TLS Client does not control the input that is signed as > cryptographic hash function are expected to be non-invertible. > None of these. The specific structs are indicated with digitally-signed, but generally the thing being signed is the concatenation of the handshake hashes and the hash of the resumption ctx. > Comment c) > > "A single 0 byte is appended to the context to act as a separator." > > When describing how the input to be signed is built, it may be clearer to > emphasize that string ends with 0, whihc leads to a "00" separator. I wou= ld > propose to add something like: "As the string ends with a "0" byte, the > binary representation will results in two zero bytes." > It's just one zero. TLS strings don't have trailing zeros. The 00 is 0x00. It would help the reader to add that =E2=80=9CExample=E2=80=9D is represent= ed in hexa by 4578616d706c650 > with the end of string character. > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c07cfb48549ba0533da03db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <<= a href=3D"mailto:daniel.migault@ericsson.com" target=3D"_blank">daniel.miga= ult@ericsson.com> wrote:
Hi,

I have a few comments while read= ing 4.8.1 Digital Signature of draft-tls-tls13.Hope it helps.

BR,
Daniel

Comment a)
=
"In previous versions of = TLS, the ServerKeyExchange format meant that attackers can obtain a signatu= re of a message with a chosen, 32-byte prefix. "

<= /span>
My understanding is that the ServeKeyExchange format defines th= e bits exchanged between the TLS Client and the TLS Server. I think the att= ack vector is more coming from how the signatures are computed. I would rat= her propose something like:

"In previous version of = TLS, the signature of the ECDH or EDH public key is performed by concatenat= ing the client random, the server random to the public keys. The concatenat= ion is hash and then signed. As the client random is chosen by the TLS CLie= nt, such design allows an attacker to obtain a signature of a message with = a chosen 32-byte prefix."

<= div>Hmm... I'm not sure this makes it much clearer. How about "The= computation of the signature in the ServerKeyExchange...."
=
C= omment b)

"Because TLS = 1.3 servers are likely to also implement prior versions, the contents of th= e element always start with 64 bytes of octet 32 in order to clear that cho= sen-prefix.

I think some additional steps need to = be explicitly specified. I am not completely sure of what is being signed.= =C2=A0
=C2=A0=C2=A0=C2=A0 a) padding + context + H(client.random + serv= er + random + ECDHE/DHE Params)
OR
=C2=A0=C2= =A0=C2=A0 b) padding + context + client.random + server + random + ECDHE/DH= E Params
OR
=C2=A0=C2=A0=C2=A0 c) padding + context + ECDHE/DHE Param= s
OR
=C2=A0=C2=A0 d) something else

I assume that is a) in which case, the reason for choosing this form= at is to constraint changes between TLS versions at the signing module. In = addition, if the correct scheme is a) maybe some additional text or referen= ce could explain why the padding and context solves this problem. By prepen= ding a fixed padding and some context, to the output of the hash function, = the TLS Client does not control the input that is signed as cryptographic h= ash function are expected to be non-invertible.

None of these. The specific structs are indicated wit= h digitally-signed, but generally the thing being signed is the concatenati= on of the handshake hashes and the hash of the resumption ctx.
=C2=A0
Comment c)

"A single 0 byte is appended to the context to act as a separator."=

When describing how the input to be signed is bui= lt, it may be clearer to emphasize that string ends with 0, whihc leads to = a "00" separator. I would propose to add something like: "As= the string ends with a "0" byte, the binary representation will = results in two zero bytes."

It's just one zero. TLS strings don't have trailing zeros. Th= e 00 is 0x00.


It would= help the reader to add that =E2=80=9CExample=E2=80=9D is represented in he= xa by 4578616d706c650 with the end of string character.


=


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


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


--94eb2c07cfb48549ba0533da03db-- From nobody Mon May 30 06:14: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 CEDB312D194 for ; Mon, 30 May 2016 06:14:11 -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 zZoAzT9poSeg for ; Mon, 30 May 2016 06:14:08 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF7A12D50E for ; Mon, 30 May 2016 06:14:07 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a136so86341331wme.0 for ; Mon, 30 May 2016 06:14: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:date:message-id:subject :from:to:cc; bh=MTw8cOpRrAcwAMyrwQhNwlUonjxU36nXLsWW4k/P7Ww=; b=Pd5qpeCenQHXOHA+QlrnOyrRq0Y6sGimg3qLDNHB8p9eaCJv1EjvtI5jtzKp+njUr6 5kQzoWdylzSJUKkntzkFAYvqtuRDyzeev+mWG88/UAhSXNSZ25/mnfmT9HOqZXfrlEpk p0qqA7bCiwL95Sw67bl+kUgkUQUxNDIxAZAN4xWH2XnjvaDcckVE4C6jh5+7nqOWveZZ 9JCfl7O0TEiuSVv67xuFOCohWMqWmcH43+ru6QoeXJFFWPNBK8JH26gU7rrXKzk8RDhn y6rYvc2Fl8nahC0ueb6b+Rjledb2OTwZrYwi8WohsUFxItbZxNkj5cEwfMJV3+2liibh teYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MTw8cOpRrAcwAMyrwQhNwlUonjxU36nXLsWW4k/P7Ww=; b=T4TPdhFKcrtci+2oyNikkoUSqK1+dZtjA9ePVAlq7ACo7CiFrkwwlr277iRKVdOYzN M9PhCf3t+PlX52+wsWFhEL7Res68XJfIs377L7aIgo6G6Pbjl5d6gCvwzsYAGcnB8S3T BLBkBfgb2jTYOPyedjEIYNZZAl8k0vzHOWlzZKq4Fr5lIc9XGndgKdMub1O6SKrllMMc aD2BY4AVC0VZ4TPXJJL7VTKtQNgMWflguAimiAUHV06AT5FkTddLnv49rPVqmYzDt9O/ lHbjyYV/JwutE7si5wbcdoi4M/YLSIJz1ZxS31/GpDblAGcdG/9UnX0NxqU9/wZQmX62 zTeQ== X-Gm-Message-State: ALyK8tLE8++EChR57mEIFRyg338QKTYywB9KKg1VgR3hZy1eJ2sHcjOUrIpW5d55rJkHG0qqXhtjjdv9ydj0Iw== MIME-Version: 1.0 X-Received: by 10.194.3.51 with SMTP id 19mr28185993wjz.57.1464614046114; Mon, 30 May 2016 06:14:06 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.86.42 with HTTP; Mon, 30 May 2016 06:14:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 May 2016 09:14:06 -0400 X-Google-Sender-Auth: boEATh-6laczbVWZB3Iw-odUed4 Message-ID: From: Daniel Migault To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b3a81fcf3edaa05340f07ab Archived-At: Cc: tls Subject: Re: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 May 2016 13:14:12 -0000 --047d7b3a81fcf3edaa05340f07ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks a lot for your responses, they addressed my concerns. BR, Daniel On Fri, May 27, 2016 at 5:58 PM, Eric Rescorla wrote: > > > On Fri, May 27, 2016 at 1:17 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> I have a few comments while reading 4.8.1 Digital Signature of >> draft-tls-tls13.Hope it helps. >> >> BR, >> Daniel >> >> Comment a) >> "In previous versions of TLS, the ServerKeyExchange format meant that >> attackers can obtain a signature of a message with a chosen, 32-byte pre= fix. >> " >> >> My understanding is that the ServeKeyExchange format defines the bits >> exchanged between the TLS Client and the TLS Server. I think the attack >> vector is more coming from how the signatures are computed. I would rath= er >> propose something like: >> >> "In previous version of TLS, the signature of the ECDH or EDH public key >> is performed by concatenating the client random, the server random to th= e >> public keys. The concatenation is hash and then signed. As the client >> random is chosen by the TLS CLient, such design allows an attacker to >> obtain a signature of a message with a chosen 32-byte prefix." >> > > Hmm... I'm not sure this makes it much clearer. How about "The computatio= n > of the signature in the ServerKeyExchange...." > > Comment b) >> >> "Because TLS 1.3 servers are likely to also implement prior versions, th= e >> contents of the element always start with 64 bytes of octet 32 in order = to >> clear that chosen-prefix. >> >> I think some additional steps need to be explicitly specified. I am not >> completely sure of what is being signed. >> a) padding + context + H(client.random + server + random + ECDHE/DHE >> Params) >> OR >> b) padding + context + client.random + server + random + ECDHE/DHE >> Params >> OR >> c) padding + context + ECDHE/DHE Params >> OR >> d) something else >> >> I assume that is a) in which case, the reason for choosing this format i= s >> to constraint changes between TLS versions at the signing module. In >> addition, if the correct scheme is a) maybe some additional text or >> reference could explain why the padding and context solves this problem.= By >> prepending a fixed padding and some context, to the output of the hash >> function, the TLS Client does not control the input that is signed as >> cryptographic hash function are expected to be non-invertible. >> > > None of these. The specific structs are indicated with digitally-signed, > but generally the thing being signed is the concatenation of the handshak= e > hashes and the hash of the resumption ctx. > > > >> Comment c) >> >> "A single 0 byte is appended to the context to act as a separator." >> >> When describing how the input to be signed is built, it may be clearer t= o >> emphasize that string ends with 0, whihc leads to a "00" separator. I wo= uld >> propose to add something like: "As the string ends with a "0" byte, the >> binary representation will results in two zero bytes." >> > > It's just one zero. TLS strings don't have trailing zeros. The 00 is 0x00= . > > > It would help the reader to add that =E2=80=9CExample=E2=80=9D is represe= nted in hexa by 4578616d706c650 >> with the end of string character. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --047d7b3a81fcf3edaa05340f07ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot for your responses, they addressed = my concerns.
BR,
Daniel

On Fri, May 27, 2016 at 5:58 PM, Eric Re= scorla <ekr@rtfm.com> wrote:


On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

I have a few com= ments while reading 4.8.1 Digital Signature of draft-tls-tls13.Hope it help= s.

BR,
Daniel

Comm= ent a)
"In previ= ous versions of TLS, the ServerKeyExchange format meant that attackers can = obtain a signature of a message with a chosen, 32-byte prefix. "=

My understanding is that the ServeKeyExchange f= ormat defines the bits exchanged between the TLS Client and the TLS Server.= I think the attack vector is more coming from how the signatures are compu= ted. I would rather propose something like:

"In prev= ious version of TLS, the signature of the ECDH or EDH public key is perform= ed by concatenating the client random, the server random to the public keys= . The concatenation is hash and then signed. As the client random is chosen= by the TLS CLient, such design allows an attacker to obtain a signature of= a message with a chosen 32-byte prefix."
=

Hmm... I'm not sure this makes it much clear= er. How about "The computation of the signature in the ServerKeyExchan= ge...."

Comment b)

"Because TLS 1.3 servers are likely to also impl= ement prior versions, the contents of the element always start with 64 byte= s of octet 32 in order to clear that chosen-prefix.

I think some additional steps need to be explicitly specified. I am not c= ompletely sure of what is being signed.=C2=A0
=C2=A0=C2=A0=C2=A0 a) pad= ding + context + H(client.random + server + random + ECDHE/DHE Params)
=
OR
=C2=A0=C2=A0=C2=A0 b) padding + context + clien= t.random + server + random + ECDHE/DHE Params
OR
=C2=A0=C2=A0=C2=A0 c= ) padding + context + ECDHE/DHE Params
OR
=C2= =A0=C2=A0 d) something else

I assume that is a) in which = case, the reason for choosing this format is to constraint changes between = TLS versions at the signing module. In addition, if the correct scheme is a= ) maybe some additional text or reference could explain why the padding and= context solves this problem. By prepending a fixed padding and some contex= t, to the output of the hash function, the TLS Client does not control the = input that is signed as cryptographic hash function are expected to be non-= invertible.

None of= these. The specific structs are indicated with digitally-signed, but gener= ally the thing being signed is the concatenation of the handshake hashes an= d the hash of the resumption ctx.

=C2=A0
Comment c)

"A single= 0 byte is appended to the context to act as a separator."

When describing how the input to be signed is built, it may b= e clearer to emphasize that string ends with 0, whihc leads to a "00&q= uot; separator. I would propose to add something like: "As the string = ends with a "0" byte, the binary representation will results in t= wo zero bytes."

It's just one zero. TLS strings don't have trailing zeros. The 00 = is 0x00.


=
It would help the reader to add that =E2=80=9CExample=E2=80=9D is repre= sented in hexa by 4578616d706c650 with the end of string character. =




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


_______________________________________________
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


--047d7b3a81fcf3edaa05340f07ab--