Re: Read-out on offline connection ID discussion

Christian Huitema <huitema@huitema.net> Thu, 25 January 2018 09:11 UTC

Return-Path: <huitema@huitema.net>
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 3E9CA12E870 for <quic@ietfa.amsl.com>; Thu, 25 Jan 2018 01:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 r1jAl-MFP71q for <quic@ietfa.amsl.com>; Thu, 25 Jan 2018 01:11:56 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D76F012D868 for <quic@ietf.org>; Thu, 25 Jan 2018 01:11:55 -0800 (PST)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx12.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eedZQ-0007ks-6u for quic@ietf.org; Thu, 25 Jan 2018 10:11:48 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1eedZJ-0006zT-RK for quic@ietf.org; Thu, 25 Jan 2018 04:11:41 -0500
Received: (qmail 10835 invoked from network); 25 Jan 2018 09:11:32 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 25 Jan 2018 09:11:31 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-A2E6BD0C-FE2F-4E37-A930-BEA7099B0A75"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15C202)
In-Reply-To: <CAN1APdcuyGk=2TAv+7WoRAsh3vVPxu56xXtdj0SgNaTL=ihvPA@mail.gmail.com>
Date: Wed, 24 Jan 2018 23:11:28 -1000
Cc: Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <3B18A5DF-E9D6-4866-9B1F-25068647203F@huitema.net>
References: <CABcZeBO8UcdsPPp7D-3gZW8tuDqNhP-z+O1+WH=68KjbfYMr5A@mail.gmail.com> <CAN1APdewkGQULckLb6F4rEzcPtiFJPBVBQbkcNeupK3d+r6Sow@mail.gmail.com> <CABcZeBO2iRrFXNgLD1AsxmwRJ+Pz6USadWGeU5vb12Pu9eOyog@mail.gmail.com> <CAN1APdcuyGk=2TAv+7WoRAsh3vVPxu56xXtdj0SgNaTL=ihvPA@mail.gmail.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Subject: Re: Read-out on offline connection ID discussion
X-Originating-IP: 168.144.250.177
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5l0ULHbsj3cpPgbIvyKFHkMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuarhUvg7Jby3KCeBAtlpgFB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RbsXxkdg7AzXKJWQK1/EQZPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATvFVVOfJAYdBTniKgyyo60ONoJfh+XjGSeeT90H/uIEv dgPkYMgX1clsm44k8mBD4xk5vj6n8gof57frkeDipGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWi2LEHF33nMCnEPdDBPtPg/fFcHV2tQAVqGdj/zM7G/G3L31QGIB1LDs8uX49JL/W5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vLH6Kl1mSafSQYm3cb-X8dlsmIM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 09:11:58 -0000

> On Jan 24, 2018, at 10:45 PM, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> wrote:
> 
>> On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote:
>> I don’t understand this requirement for the CID to be 16 bytes in order to be encrypted.
>> If you have a unique key you can encrypt 0, truncate and xor with the CID.
>> If you don’t have a unique key, you can encrypt a unique counter value and do the same, or derive a unique key.
>> 
>> I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.?
> 
> I’m merely stating that if you want to encrypt with AES and you do not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic.
> 
AES GCM is a stream cipher. It is OK in AEAD mode, but using that without authentication opens the way to all the known attacks against stream ciphers. If we don't have room for authentication, then ECB mode seems much preferable.

--Christian Huitema