RE: Packet number encryption
Praveen Balasubramanian <pravb@microsoft.com> Fri, 09 February 2018 19:58 UTC
Return-Path: <pravb@microsoft.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 01DC8126DFF for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 11:58:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 OzxJTCgzDbem for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 11:58:40 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735CB1242F7 for <quic@ietf.org>; Fri, 9 Feb 2018 11:58:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ubdA7XxVOGDrbDGSbqpNFHQQFV/02BX+baznfRZqGjw=; b=LDgFwjaVj2BzZ4HELwbTCjg1FGmiJCeDF6/sTV4PA4xBc4dGPFFAYcK77d86cVUSlCWvtnczSxAskd6ua3IB/DdzkByzknWY4lym1HJJO/2i+HyQ9UGmpFxlh24zTGm+UesIqFrvb774g4/rsYkmy082UXIIksxsyxMdUbiKzI4=
Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 19:58:38 +0000
Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 19:58:38 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: David Benjamin <davidben@chromium.org>
CC: Eric Rescorla <ekr@rtfm.com>, "quic@ietf.org" <quic@ietf.org>, huitema <huitema@huitema.net>
Subject: RE: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnCAACeJgIAAApzg
Date: Fri, 09 Feb 2018 19:58:38 +0000
Message-ID: <CY4PR21MB0133A4FC7160DA1FABAA291BB6F20@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <CAGD1bZauKbucs_5n7RQbK8H2HiyfiqpGVEcKreGA6umhMBSFgg@mail.gmail.com> <CABcZeBPNrc-9vANSH02r++p53s6gN4pVB8DMd80nUxOhKTp3dA@mail.gmail.com> <CAKcm_gMvHSBhpUvsQCCkV2_o+d_wchF3R3L6H8mp6nKNaaRmSw@mail.gmail.com> <CY4PR21MB0133CCAA6807469BA983D00BB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <CABkgnnW4xr_YzpsvCxaJJgcQdBTuX=Yv735_sdd4VoMfji8mbA@mail.gmail.com> <CY4PR21MB0133C759D4A08A4988B641B2B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <bdf88936-8edc-d56e-ee59-c9d597058edd@huitema.net> <CY4PR21MB01337C8A700E58B49D90B712B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <CAOYVs2pi8-NVuS+crNMfjsP-n5upK3=5tPeQ8OSGpOvL6RTrjA@mail.gmail.com> <CY4PR21MB0133A1117B2733BBCF049C5FB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30@MWHPR08MB2432.namprd08.prod.outlook.com> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <MWHPR21MB0144C68102972A668611E1FCB6F20@MWHPR21MB0144.namprd21.prod.outlook.com> <CY4PR21MB01332141C3563ABBA240C566B6F20@CY4PR21MB0133.namprd21.prod.outlook.com> <CABcZeBNeTT79nd+d7h-KFPpFYxpr5wt1KgwPY=M0_UQpCkKq1w@mail.gmail.com> <CY4PR21MB01337A5E81D8A8A1D7518D97B6F20@CY4PR21MB0133.namprd21.prod.outlook.com> <CAF8qwaBm6DRpS6eUthSMithsbUq-NMNhBND7RaDUFfzP0tAxnQ@mail.gmail.com>
In-Reply-To: <CAF8qwaBm6DRpS6eUthSMithsbUq-NMNhBND7RaDUFfzP0tAxnQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:6::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:t1+5Xux6x6DMqDvYt4a9ld6kMt33X8zJcFt18kXwwzPksyFDruhilhOvRGCqjr9So/NJ2R1f2bQsxtQ2GqVyvKJHWFa/25lS7tx0tF9nKBvPwgZQObzf5CPejhkFFGLduJDWfJOF765Zu6f2sjDWIqV7meWX2Jg/a+p47q3Xh/sLVW6qJ4QvoWGRtMk/3h9hbp/n1yYGA9TlHAjWJt/QdJWFbBHiyP21JUATksOJV/xf/PYm4mi6Ucn0KSsClQs7
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1514f5cf-906f-4f36-7098-08d56ff782b8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0504;
x-ms-traffictypediagnostic: CY4PR21MB0504:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <CY4PR21MB050400ACEDDFE963289A227FB6F20@CY4PR21MB0504.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0504;
x-forefront-prvs: 057859F9C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(39380400002)(199004)(189003)(377424004)(97736004)(25786009)(3280700002)(3480700004)(2906002)(6346003)(102836004)(68736007)(19609705001)(186003)(4326008)(53546011)(6506007)(59450400001)(76176011)(8936002)(10090500001)(99286004)(8990500004)(7696005)(3660700001)(105586002)(5250100002)(5660300001)(86362001)(81156014)(81166006)(7116003)(14454004)(7736002)(74316002)(6246003)(93886005)(9686003)(54896002)(236005)(6306002)(53936002)(8676002)(86612001)(54906003)(6916009)(6116002)(790700001)(2950100002)(2900100001)(55016002)(6436002)(561944003)(316002)(10290500003)(229853002)(22452003)(478600001)(33656002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-message-info: flsOv15o1ryNI86M2xRVsO+Tl7xVUdhu7DwLmfSq/lYTs0XhTO2SUsKAI7KDM7yBbbeZJim2GBKY7goPCJf/2w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133A4FC7160DA1FABAA291BB6F20CY4PR21MB0133namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1514f5cf-906f-4f36-7098-08d56ff782b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 19:58:38.2742 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HLBUeRJeJ08glEAAvcnbvr6hQRo>
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: Fri, 09 Feb 2018 19:58:44 -0000
With VLE its minimal overhead per packet so you are not encrypting 4 bytes more all the time even with 64 bit or 128 bit packet number . So its decidedly better. Also fewer calls into TLS, but I suppose one could do some refactoring of TLS API. Many CPUs yes but this is a general purpose transport and could run on CPUs that don’t. Didn’t ask for nonce to be variable length. Fixed length for connection lifetime. Datacenters connections could use 64-bit nonce to avoid frequent key rollover. Effectively the plain text nonce is a sequence number since it increases monotonically with small jumps as needed to avoid ossification. So no worse off than gQUIC or current draft. No more complex than using the packet number. Just the starting number is randomized. Also please notice that this proposal does not preclude using encrypted packet number as the nonce as proposed previously. Changing how the nonce works makes 0 impact on the transport logic. An implementation can choose to implement any form of non-repeating nonce without revving the RFC. This is the biggest advantage of separation of concerns IMHO. From: David Benjamin [mailto:davidben@chromium.org] Sent: Friday, February 9, 2018 11:39 AM To: Praveen Balasubramanian <pravb@microsoft.com> Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net> Subject: Re: Packet number encryption Your primary worry here was the extra block cipher operation, right? By moving the packet number into the plaintext, this proposal increases the length, which will cost that same one extra block cipher operation, no? It is one block operation under the same key, rather than a different key so I suppose there are minuscule cache footprint wins (one symmetric key is 16 or 32 bytes). But the cost is per-packet (!) bandwidth and complexity. I do not see how this could be worth it. Note that, for AES, many CPUs have dedicated instructions for it already. > Clear separation of concerns results if we don’t overload the packet number as the nonce. Connection migration and multi-path are optional features and we pay no extra compute cost for most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn’t need it and can grow to larger size as needed for bulk transfers to prevent frequent key rollovers (say in datacenter scenarios). You're not going to find AEADs that don't require a nonce. Encryption must not produce the same ciphertext twice for the same plaintext, so you need some input to diversify them. That input is the nonce. Nonces also are not variable-length, so you don't get to arbitrarily grow them. (AES-GCM per spec is variable length, but that's a spec bug. If you size it above 96 bits, it's as if you randomized it and your nonce space crashes per birthday.) It is also harmful to separate the two concerns. When you are building a transport, derive the nonce from a sequence number. TLS 1.2 AES-GCM separated them, which was a mistake. It's less efficient (the world wasted quite a lot of bandwidth due to this), and more error-prone. There was nothing stopping implementations from sending the same nonce or generating nonces randomly (the AEADs we use don't have large enough nonces for that), and indeed some did just that. If you use some sort of sequence number, you can lean on existing work both to filter out the obvious implementation mistakes and to avoid sending unnecessary data. On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>> wrote: Let me try to summarize the proposal again: 1. Packet number is in the encrypted portion of the header and is no longer used as the nonce. It is encoded as a variable length number. Always starts at 0. * No ossification of PN * No linkability using PN * Allows for growth beyond 64 bits if needed in future 1. The nonce is in the clear in plaintext header. It is generated per path as a secure random number. Call this the “starting value”. Both sides MUST initialize the “starting value” nonce per path. Within a path it grows monotonically (to avoid repeats just like PN today) and can include short random jumps periodically so that middleboxes cannot assume anything about the field. Since nonce has nothing to do with PN the jumps don’t add any complexity to transport logic. Jumps are for greasing and preventing ossification. When the nonce rolls over and reaches close to the “starting value”, key rollover must happen. At high data rates the nonce field can be 64-bits to prevent frequent key rollover. For crypto that doesn’t need nonces, the field can be omitted. * No ossification because there is no pre-determined sequence to the nonce. * In gQUIC and the RFC as defined the nonce is a simple sequence that increments by one, so this is no worse off in terms of security. It is non-repeating. * No linkability because different paths start at a completely different random number. If repeating is a concern then different paths use different keys. Carries forward to not just connection migration but mutli-path. * Supports key rollover just like gQUIC and currently defined draft RFC. * Allows for omitting the nonce when we use crypto that doesn’t need it. * Allows for larger nonces for high data rates. * It doesn’t preclude any other type of non-repeating nonces without having to modify the RFC! So implementations that want to use cryptographic nonces can still do so. The downsides: 1. Even with variable length encoding the extra PN field is more space used per packet when a nonce is required. I think we can do with 2 bytes in version 1. 2. It’s not perfect unlinkabiltiy but I have yet to see any solution that can provide this. A simple time based analysis using machine learning will allow flow correlation especially for connection migration. The IP addresses in the clear allow for a high degree of correlation. There is also the application sending pattern and other signals that could be used. From: Eric Rescorla [mailto:ekr@rtfm.com<mailto:ekr@rtfm.com>] Sent: Friday, February 9, 2018 5:52 AM To: Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>> Cc: huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; quic@ietf.org<mailto:quic@ietf.org> Subject: Re: Packet number encryption On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>> wrote: Actually taking a step back what if we don’t we overloaded packet number as the nonce? Can we: 1. Put packet number as a separate variable length field in the encrypted portion of the header. This allows for growth beyond 64 bits in future and completely avoids ossification. For short lived flows variable length encoding leads to minimal space overhead. 2. Put a separate plaintext nonce which starts out as a secure random number and monotonically increases as short random jumps (every packet or every few packets) and could then rollover. This will prevent linkability and scales to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithms that do not need a nonce saving more space. I'm not sure how to do #2 safely and efficiently. The primary concern is that short random jumps don't actually prevent linkability because the high order bits don't change and long random jumps are effectively randomly sampling out of the nonce space, and you start to run into birthday problems. Additionally, the cheapest PRNGs are basically ciphers in counter mode, so at best you're going to get a small amount of overhead reduction by getting multiple jump computations out of a single block, though if you use 96-bit jumps, you only get 25% savings... -Ekr Some MSB of the nonce could be used for signaling reorder to the network if needed. I don’t have the historical context for overloading of PN as the nonce so pardon me if un-overloading option was discussed and ruled out before. From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>] On Behalf Of Praveen Balasubramanian Sent: Thursday, February 8, 2018 5:51 PM To: huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; quic@ietf.org<mailto:quic@ietf.org> Subject: RE: Packet number encryption >> and using separate packet sequences for each path This alone prevents linkability right? >> The packet number on each path will start at 1 (or maybe 0 ;-). Is supporting multiple paths at the same time a goal? If yes, then yes all paths will need to have separate tracking and ACK state and congestion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migration scenario then all you need is a (random) jump to a offset in packet number space for the new path so that the few packets in the old path can continue for a little bit. This works with just one ACK space so no implementation complexity. >> 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. In addition if the value in the clear was obfuscated with an XOR transform it will help prevent ossification. The obfuscation is not meant to guard against later analysis that reveals the packet numbers - why do we care about that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume ordering etc. All said if I am alone in being concerned about the perf hit then I’d say go on with option 1. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Thursday, February 8, 2018 3:54 PM To: quic@ietf.org<mailto:quic@ietf.org> Subject: Re: Packet number encryption On 2/8/2018 1:13 PM, Mike Bishop wrote: #2 won’t work. The packet number is an input to the AEAD nonce, so you have to get to the packet number before you can decrypt the payload. It can’t be based on anything internal to the encrypted packet. In Martin’s proposal, it’s using a combination of the encrypted payload (which requires nothing to access) and some stored state on each endpoint, which requires only the Connection ID to look up. You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet numbers and start drawing inferences about what the XOR value is. If overhead is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize the cost of doing the encryption step. (At the cost of keeping the table of precomputed values, of course.) I still think Jana’s pushing in the right direction here: Let’s agree on goals, and then see if we can craft a design that meets those goals. I hear you saying that low overhead is a goal, which I think we can all agree on. I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like there’s less agreement on that. You also raise an interesting point that some clients will care less about linkability because they will never intentionally migrate. I think Victor said it best, "Obfuscation is just encryption done poorly." Either we encrypt, or we don't. But there is no such thing as an obfuscation middle-ground. Obfuscation would just be a speed bump, easily broken. It won't provide privacy, and it won't prevent linkability. As far as I am concerned, there are only two designs that prevent linkability: 1) Martin's PR, in which the packet number is encrypted using sensible crypto; 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. The second option requires more computation when explicitly setting up a new path. The connection ID would be used as part of the "salt" when deriving connection contexts. The packet number on each path will start at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK to be per/path, or alternatively adding a PATH-ACK frame that indicates the path for which packets are acked. The pros and cons of the two options are easy to get: 1) Option 2 does not require the cost of encrypting every packet, thus per packet processing will be maybe 1% faster than option 1. 2) Option 2 requires computing encryption contexts for each path, which is more complex than option 1, but the cost will be amortized over the duration of the path. 3) Option 2 requires more complex data structures and ACK management, thus increasing the chances that something goes wrong. 4) Option 2 does nothing against packet number ossification. The packet number effectively becomes part of the invariants. In short, the only advantage of option 2 is to avoid a single symmetric encryption operation per packet, while making the code significantly more complex, and at the cost of not protecting against PN ossification. The way I see that, there is hardly any debate. -- Christian Huitema
- Packet number encryption Martin Thomson
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eggert, Lars
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Duke
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Dmitri Tikhonov
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Piotr Galecki
- Re: Re: Packet number encryption alexandre.ferrieux
- Re: Packet number encryption Patrick McManus
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Roberto Peon
- RE: Packet number encryption Piotr Galecki
- RE: Packet number encryption Roni Even (A)
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Lubashev, Igor
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Willy Tarreau
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Reducing ossification through protocol design (wa… Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Roberto Peon
- Re: Reducing ossification through protocol design… Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- RE: Packet number encryption Roni Even (A)
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- Re: Reducing ossification through protocol design… Salz, Rich
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Reducing ossification through protocol design… Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Marten Seemann
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Gorry Fairhurst
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- RE: Explicit measurability in the QUIC wire image… Roni Even (A)
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Stephen Farrell
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Martin Thomson
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Martin Thomson
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption David Benjamin
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Deval, Manasi
- RE: Packet number encryption Deval, Manasi
- Re: Packet number encryption Victor Vasiliev
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Ian Swett
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: hardware offload (was: Packet number encrypti… Christian Huitema
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Eggert, Lars
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen