Re: [quicwg/base-drafts] Add retry integrity tag (#3120)

David Schinazi <notifications@github.com> Tue, 22 October 2019 02:00 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85782120ADD for <quic-issues@ietfa.amsl.com>; Mon, 21 Oct 2019 19:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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=github.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 UupqaB6cnFfW for <quic-issues@ietfa.amsl.com>; Mon, 21 Oct 2019 19:00:12 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1266120AD8 for <quic-issues@ietf.org>; Mon, 21 Oct 2019 19:00:11 -0700 (PDT)
Date: Mon, 21 Oct 2019 19:00:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571709611; bh=vpCB8fqm2LQBas6KdE9k99ldfYaOVaZI/z0UbXBmFm0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=h5+ZmtzuL7LvPAg+1v7VrHhgUizA7mTXBZQ6/GFecjAgkIvq3sn0ik/h54sGBxUWJ kb1Hpo8Rp0iR0QRv+78UI8aUPHkE7bbmcAOTTiriiPJXkRIgzcxKyuDy4W+bHMUkwa K/bOgMT579zo5wE0392dE31e+40TnaKXSUihB5mY=
From: David Schinazi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3ELMXSNOS2Z6LXB2V3XORTXEVBNHHB4UZE54@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3120/c544777830@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3120@github.com>
References: <quicwg/base-drafts/pull/3120@github.com>
Subject: Re: [quicwg/base-drafts] Add retry integrity tag (#3120)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dae62ab5628_55dc3f8f132cd968663cd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/nAJInFlTaxzA7Pk_QO2ysu0vs4c>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 02:00:14 -0000

@martinthomson 
> I'm ambivalent with the implicit ODCID thing. I like implicit things generally because you can't succeed if you don't have the right information, but this seems like it might still fail if the client doesn't check the tag. We could completely avoid that being an issue if we enciphered the token, but that might change the optimization options enough that it isn't worthwhile.

The ODCID being implicit has the same checking properties as an explicit ODCID - the client could ignore that field entirely before.

That said I do like the idea of making it harder to not check, by encrypting the token. @nibanks if we were to encrypt the token with a zero-key, would that still be suitable? I think the overhead is very small as long as we don't use HKDF / SHA-2 here.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#issuecomment-544777830