IETF Logo Mail Archive

RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 05 April 2018 17:59 UTC

Return-Path: <ilubashe@akamai.com>
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 0B297129C5D for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:59: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, 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=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 p3jRmIRZYMcr for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:59:16 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 966BE126BF6 for <quic@ietf.org>; Thu, 5 Apr 2018 10:59:16 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w35HriKg007188; Thu, 5 Apr 2018 18:59:07 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=D5rIDnC6KZ/V2keppBC5sY6uESTMq+81x8wCAGIFD6Q=; b=pNY2EGimy18aAau9wlW7x9ssa178zxLeEEKN6P/n4ST2jQD9VXBrMQ/xdctYIU7G1+fJ HZRMKHtC6CwmGlFjZddZDJwtZFe6km2muF82ESTp8celuUIYNtWmstBlhCLW6FmBQ9hW CkKcnUYWkdJsTfI/zOawoxjeiuNR9kCuNOUp60+SzrSe9Ti4bIattFFfSUlRYPey2gar 09wqXwxs41E6k1NFRidz2pTHdmNEBMhjKmesF0i+iO1PnZLS4X0fKyQBt6YRk5Iqguxq CBlXOdDOgYRzvIvdrCgere4r0y8czZQbC/AMWgXQh+BJGa2JtZWDgwgViIAQs5VMT1L4 HA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2h4vfv3v83-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 18:59:07 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35HqaxP008847; Thu, 5 Apr 2018 13:59:06 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2h25nvugc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 13:59:06 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Apr 2018 13:59:05 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Thu, 5 Apr 2018 13:59:05 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Mike Bishop <mbishop@evequefou.be>, Christian Huitema <huitema@huitema.net>, Kazuho Oku <kazuhooku@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOeCspMmk/31UumuO1CInS8X6PylyoAgAACsQCAABOkAIAAAk8AgAABDID//8BxoA==
Date: Thu, 05 Apr 2018 17:59:04 +0000
Message-ID: <a02101a18f16419f81233058a1a6de15@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net> <CANatvzy8zTFKs-c-rR0jMSHdh2HJMvZrRmcR5A+b6qNpNPzkrw@mail.gmail.com> <SN1PR08MB1854010FD61AC17D19E497FDDABB0@SN1PR08MB1854.namprd08.prod.outlook.com> <CAN1APddJ7b+7Ydtw7i5c3XBHiC3mz9FmJEM-kZ0=Y8DvmpQ0eg@mail.gmail.com>
In-Reply-To: <CAN1APddJ7b+7Ydtw7i5c3XBHiC3mz9FmJEM-kZ0=Y8DvmpQ0eg@mail.gmail.com>
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: [172.19.35.87]
Content-Type: multipart/alternative; boundary="_000_a02101a18f16419f81233058a1a6de15usma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=942 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050184
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=879 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050184
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QdvohiN_PSnNcztqhO96CBGyQAw>
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, 05 Apr 2018 17:59:19 -0000

  *   I'd prefer making handshake packets indistinguishable from short header packets. In essence, you move the flags of the long header inside the AEAD-protected area. An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails.
This change would wreck stateless load balancers that rely on being able to distinguish CI packets (and route them based on IPs) from other packets (and route them based on CID).

- Igor

From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be>; Christian Huitema <huitema@huitema.net>; Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

Hi


On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be<mailto:mbishop@evequefou.be>) wrote:

 An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails.

I can see hiding things may be a good thing, but having to trial decrypt all unknown packets as potentially creating a huge load, unless you combine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average to reject random packet content.

It won’t solve all DDoS, but it will help. Forcing trial decryption fo the full packet makes me a bit anxious.



Mikkel

v2.23.0 | Report a Bug | By Email