Return-Path: 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 A861D12017F for ; Fri, 17 May 2019 05:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.01 X-Spam-Level: X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 kA1w-sVX577O for ; Fri, 17 May 2019 05:42:53 -0700 (PDT) Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BE012004F for ; Fri, 17 May 2019 05:42:53 -0700 (PDT) Date: Fri, 17 May 2019 05:42:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558096972; bh=lepGIItIp38QbA8hIVLYav979Cmp2OwbsTlNft3awuA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qzMEWoxpwwL4rDxxkfkjC/XJvXFOl1Tjo6xFdVBWJ0jbpkcXP1txcLKNCWM6gP6Jl +i7qq8H5f8ymLmbXU5AflK7VFK+fPt7uzQmlwjq4Pnfp0463DAR5g+9fMyUk3N3Q2j IgNYL+0xb/JeDQ+cdTe28u8N1CmOr370X8ap3lbU= From: ekr Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (#2581) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5cdeac4c7d59f_73ea3fc7082cd96811251fd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: ekr X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 12:42:56 -0000 ----==_mimepart_5cdeac4c7d59f_73ea3fc7082cd96811251fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @DavidSchinazi this doesn't seem like a very persuasive analogy, given that HTTP/2 has a long list of rules about disabling ciphers that were present in TLS 1.2: https://tools.ietf.org/rfcmarkup?doc=7540#section-9.2.2 The reason that it doesn't have that in TLS 1.3 is because (1) TLS 1.3 post-dates HTTP/2 and (2) the suites were chosen according to the same principles Second, as a practical matter, most browsers do not support CCM_8, and I suspect that will continue to be true for most stacks, partly because performance is not awesome (as it requires computing CBC). If, as @RyanAtGoogle implies, we want to have a cipher with a shorter authentication tag (I'm undecided on this topic myself at present) for general use then we should consult CFRG for one, rather than just use the one that happened to be the one that IoT devices supported. -- 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/issues/2581#issuecomment-493439412 ----==_mimepart_5cdeac4c7d59f_73ea3fc7082cd96811251fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@DavidSchinazi this doesn't seem like a very persuasive analogy, given that HTTP/2 has a long list of rules about disabling ciphers that were present in TLS 1.2:

https://tools.ietf.org/rfcmarkup?doc=7540#section-9.2.2

The reason that it doesn't have that in TLS 1.3 is because (1) TLS 1.3 post-dates HTTP/2 and (2) the suites were chosen according to the same principles

Second, as a practical matter, most browsers do not support CCM_8, and I suspect that will continue to be true for most stacks, partly because performance is not awesome (as it requires computing CBC). If, as @RyanAtGoogle implies, we want to have a cipher with a shorter authentication tag (I'm undecided on this topic myself at present) for general use then we should consult CFRG for one, rather than just use the one that happened to be the one that IoT devices supported.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5cdeac4c7d59f_73ea3fc7082cd96811251fd--