From nobody Wed May 5 13:27:05 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC2A3A1FD2 for ; Wed, 5 May 2021 13:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDMez6hfm9ei for ; Wed, 5 May 2021 13:27:01 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71A3A1FD0 for ; Wed, 5 May 2021 13:27:01 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id b3so1737315plg.11 for ; Wed, 05 May 2021 13:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l8bH4V+ZsFt3yIqJnSKbLxOzqMcxteuq2hL/RP2erFI=; b=kcjXzm9bE4OJYC9ZXrBCDCIsEAQexir5GYAjHsuRFDEbz2QqWFPmfmKi5fmJcMe7Cn hnXhJ1V7AUx3AfDvClEsc6aFjoIuR3XLLAjuU0bVsM/xlRX3nlfsWoTdP04IYwVNcWlF /wsfyGqeqVKWdkDdIIxoEM61PpFZPwMq5JTMr5wF86kC2Iu0G+2mA2ITTAZpBzUKicLT v4rUkQQvxBCRfx6krVRM3LpR+wOYJ/j4PTKQPgE+7Rw57HM7P/+/aThohVMAZboqISQC xEQ3MihMksFbaoS06X6Z+n8QTHXPwEbXXmVwFwdU0a5yMnRxo9ll97GvzCMrd2oF8xrB rE3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l8bH4V+ZsFt3yIqJnSKbLxOzqMcxteuq2hL/RP2erFI=; b=iRx1xCBm36HkaVjn9+ybgv4SJjECXfoan0MPYcM0/J50/Ao2l3fcoC2646YhZbBWbm KmTzYnJcK8PvYKFD07gaC6KbRGFg1TPVXNjU7/syNEi1LEFKj2nNm8SIjKBGPCPsB7Fy 0XGaQLO91cUDgtE5ZrfWc2mKPXgVgbRQQZfRlHhD5Bd2Jm0dFkAJmsE+ckC1so17jBZf kIPZyUD6EQVAHUT8L1Od5APYUiSBIpautahqpanbxPN7KfYrERJj0c7JXfBVueP/uK0X Ymv7dNF+2wnE2VllZkErBOQaTXQdZVsb3A1PjB6HmsjSPbBf0gQNq6NYKXRziOpVj9MH sTew== X-Gm-Message-State: AOAM530UHK7k+kWtjuy53uCKlwt9HhqZgpO4mTSAE6MOmt1WaCJpohmN Ak/cLFe9SHYyvp7uZem+qYahHrPflXfz09JHui4= X-Google-Smtp-Source: ABdhPJyXYiCaStjowoOcvzF4vVB7Ka7y60xsLe8CwJDsyiyI9lU0YHcF8crYNrpbKRHCWTJmtlutMFeCibS6tWB2SBI= X-Received: by 2002:a17:90a:7bc4:: with SMTP id d4mr13263260pjl.100.1620246419587; Wed, 05 May 2021 13:26:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 5 May 2021 13:26:48 -0700 Message-ID: Subject: Re: Update on Version Aliasing, ECHO for QUIC To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000049c5dc05c19b040d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 20:27:04 -0000 --00000000000049c5dc05c19b040d Content-Type: text/plain; charset="UTF-8" Thanks for writing these drafts Martin, I'm interested in seeing these progress and would like to implement them. I took a closer look at draft-duke-quic-protected-initial and filed a couple issues (#17 and #18 ), but overall it seems sound*. * I am not a crypto expert, more of an enthusiast... David On Wed, May 5, 2021 at 8:00 AM Martin Duke wrote: > You may recall that at IETF 109 I presented my version aliasing draft. > (The server sends a transport parameter with a random version number and > salt that the client can use next time, which greases the version and [I > claim] secures Initial Packets). It was well received, but I haven't gotten > much in the way of reviews (especially a much-needed security review) since. > > There's a new version of this draft > https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/ > that has only minor changes. > > However, I wrote a new companion draft that mangles the ECHO design to > encrypt initial packets beginning with the first connection. This would be > a new version of QUIC, leveraging some of the lessons from last month's v2 > exercise: > https://datatracker.ietf.org/doc/draft-duke-quic-protected-initial/ > > I wrestled with the crypto piece for a long while, and it could really use > a look from an expert. > > Thanks, > Martin > --00000000000049c5dc05c19b040d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing these drafts Martin, I'm interested= in seeing these progress and would like to implement them.

<= div>I took a closer look at=C2=A0draft-duke-quic-protected-initial and file= d a couple issues (#17 and #18), but overall it seems sound*.

* I am not a crypto expert, more of an enthusiast...

David

On Wed, May 5, 2021 at 8:00 AM Martin Duke = <martin.h.duke@gmail.com&= gt; wrote:
You may recall that at IETF 109 I presented my version ali= asing draft. (The server sends a transport parameter with a random version = number and salt that the client can use next time, which greases the versio= n and [I claim] secures Initial Packets). It was well received, but I haven= 't gotten much in the way of reviews (especially a much-needed security= review) since.

There's a new version of this = draft
that has only minor changes.

However, I wrote a new companion draft that mang= les the ECHO design to encrypt initial packets beginning with the first con= nection. This would be a new version of QUIC, leveraging some of the lesson= s from last month's v2 exercise:

I wrestled with the crypto piece for a lo= ng while, and it could really use a look from an expert.

Thanks,
Martin
--00000000000049c5dc05c19b040d--