Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Mohit Sethi M <mohit.m.sethi@ericsson.com> Wed, 07 October 2020 17:47 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CFC3A0CB3 for <tls@ietfa.amsl.com>; Wed, 7 Oct 2020 10:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.514
X-Spam-Level:
X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 W0B-5tYBhLws for <tls@ietfa.amsl.com>; Wed, 7 Oct 2020 10:47:20 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20059.outbound.protection.outlook.com [40.107.2.59]) (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 667FD3A0C9A for <tls@ietf.org>; Wed, 7 Oct 2020 10:47:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mhclr3345Rg/1DOxjm0bFwVPolajPuYVFu7qGwTdZ6GnmBJKthw9fZ8xq1O/osOnwKBR+NjxZQROfri6ijG7a+CKjLeYgRkUX300zjDVN0NBZyswS04GqjOTzUCvg2/VOmUKz+lHIU8VAukvlvUlB1g48nCN89YKv20WkU9YtlQs94CbPz/A2CAhzVIUdtSyhKI+15RL8KxXnbOeSnMtdrvqClx+fzY60t7zhWPKvoY0AtXMKU0jFVeo2FQ2w7QsvgGJ0D7vvb7YSI47IOcTv6+VUFLEJW2tZOyLlkMaUpW1uip/9Qsb1UcbXUaUo59EV8S3d9bQQyFIeF0TWzWaIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fcHi8ji/flSBWad9uvfgE0X1sqsyBko58/xfO1TY8L4=; b=I/PrWNM1lN6FgitJQB8Abn/Bek1H9vwNtARl94FvvCM0Lf//cOvMMeL+ZnRQ08c7lFZg4aLWxlpuXYs2Al6XicZIoSEpeteD3jZuRAK7js5nDHxa9wuknbIVXYba4ZsBHdnfg699FRYeIcGuV1/lipA8h+Od6wJ+sv5yXlUKA67WzFzzHZbwwVVI6/Oiwgrqx1zCm2j11f9b5jDqbOJihGvy/nt1SLkobkmPqU+Ndbh6JY2aqE80/zGyzHL7kh6hWjXQ8FJPVGZqvWC0/A7kLUUT89E9hXYx8tAaMcjYB3MhLBg5tzc9Sc+SBmsLvRAIQV8QaCJAYXm73g+lZ7TDig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fcHi8ji/flSBWad9uvfgE0X1sqsyBko58/xfO1TY8L4=; b=s1CCO2l9rDRUNBo4vrEHkPs3H8tdJEppEz40dx+LsfUCIWFlWNtrs2ssRrHq4X/kJUvEQAy36PXHoMkh6Y4gZRvT7ehAh6XiORLFiO12eGjbC/mvSfFzGcFwN66ESWRWGYmOAU8Snn55X3GSWPsfMXeV4m3KwIctFR2Ud6CT7Ag=
Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0702MB3547.eurprd07.prod.outlook.com (2603:10a6:7:85::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.13; Wed, 7 Oct 2020 17:47:12 +0000
Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca%6]) with mapi id 15.20.3455.023; Wed, 7 Oct 2020 17:47:12 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Watson Ladd <watsonbladd@gmail.com>, Christian Huitema <huitema@huitema.net>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] PR#28: Converting cTLS to QUIC-style varints
Thread-Index: AQHWnNHiaVI1NS22a0OA6GEJUmjn9A==
Date: Wed, 7 Oct 2020 17:47:12 +0000
Message-ID: <0fbf5f36-9480-ceb6-dc20-5e27e41061a8@ericsson.com>
References: <CABcZeBPNFhGoLhgqeR9ObwyU68BYq=hXG1PhXcqNsNDNFGGyaw@mail.gmail.com> <CAOYVs2rEDtgJFVpiQkcaaYG2LAyW1hB5Cou4kUoG2_dkxMFTww@mail.gmail.com> <CABcZeBP3BUDEeiV2T-kxYTmC841XE_BrXhPHSoRqfdH0hHd-6w@mail.gmail.com> <BBA456AB-EC42-47DD-A3E3-5FC0E9E7A534@akamai.com> <53DD7D0D-D325-4246-86F2-C409875134FB@ll.mit.edu> <8e8ca76e-37ce-ce10-ae42-ea26d87c35fc@pobox.com> <9CED80DA-FAE7-4C7F-9687-3B61B63587E9@akamai.com> <a49d4b8c-cf49-51df-0c6b-332a4459f318@pobox.com> <b8f4597c-37de-0092-6179-c6bf275c20f9@huitema.net> <CACsn0c=V035wmmhwTzJoREHwmGJmVujcdm0LQKQqLCCBRzv4oQ@mail.gmail.com>
In-Reply-To: <CACsn0c=V035wmmhwTzJoREHwmGJmVujcdm0LQKQqLCCBRzv4oQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:14bb:140:34a4:43da:bde5:a265:cf55]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ef4be92f-702b-4c8d-f398-08d86ae9057c
x-ms-traffictypediagnostic: HE1PR0702MB3547:
x-microsoft-antispam-prvs: <HE1PR0702MB35476645B3DB4C1E241F2A48D00A0@HE1PR0702MB3547.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JB61VTOMNjo1E94sMOv9rfMNBtPeM3MLhLv5bLRhZilMuOtRMwE59eoFNe1JwSQn5iIL9K+PdUn0uM7FCIbDXRf5NGGORyl2AJg1AcPXyMqwzjTvhPZ2R3VOBkjWLmCUFgQtcvofmDsLbtAwoFIdy8YEmoZ7Ra1ZRgaXRkyAaxxI8x4f9IZglLwQJyh78rs0pSeeTUul7dVeq4aVm+oeib/asNsRnqPamWuajV6XKyZ1CtQCNiTKMnkkn9C6GLvwfouG6i207xUQuvxDL6wYNBK6s8JzKYRmu8nlp5Cmf9HxzWEDGjvjh2JJbYQWu/4iJeJq78dKgYij40iUCYMdR8ew+G1LI/4WuBBV6lPq7B4Kxw7+IROKM5P77IJZdhbcS4HcSSC4rHHSApHUDghMM3aX1K207wstc5iB65JBEmPZPDEdHAXpErQrQ/p0dh9cUCqwK8uK9CsK36/y6n+dGQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(396003)(39860400002)(346002)(6486002)(4326008)(83080400001)(186003)(86362001)(6512007)(36756003)(8936002)(8676002)(6506007)(53546011)(71200400001)(5660300002)(2616005)(478600001)(110136005)(966005)(316002)(31686004)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(83380400001)(31696002)(2906002)(43740500002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ubHcvUOfB21MoO/ys+0bbYOAwD2q87/Srj5EHXGbHUFn6vKcyu1nOHMMfhYedRASaYmRtEiLsAt75iDo6qPtpFwRzZZIUzpQMz8J1SZcVEWt1s2nYfaF9jSwIJF0jqZQmPSQIC+kQwvHGYoEyDrTtIm4SamPp88cJ02y87WSeGWHFdDuiNbsuDbV62zdoT7I5aBABslohO0bPl1zmCsnYJqKe6cN5nBthAHHh3hH56yBWOhOq+6YoBNoRUSH8ufKHNW3nq9Uiesro++G3axRt95XtW6XkjpHIyIRVAvn2fsdz6ySrWr91gG/I/Xh3vjeI5OXPGhgYdqw0NmQvmAEG1Uycpq3tJnAOab4h+FVg9ieW/3h2wiiOlp2PCbFFIiVZUXmWTOxVrL6Gd5EeU2eSyWXBNqi7UmJJ3AxahvscoD7u2SgdxgM5fehAfaEB942S/zwqT4vUqxzB5IvBl3iFJyFcpvafPNcQxkR5yxcOdNsuDo5U4u1zpw7DX1S7pBYcIAlBXHmYyKSI66TMDYk5oSyAlHkj/pVqne+ifrZ2kRY8XabhdyYAR+vFf71chcDnmn/lMF5xicgc1fnMpjysuXioYmcPxKWVrUdtTsfDJCtPvh4HYAv/qLfSSMXSAlNf1EHerO1kk7qlXHa83CYRZBVFLMSh6v1yiEi929HhZXT5Yg2ZXsAjYCE5iDcafZ1h1yamm5jqYULIceXcHlewg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E88EEB7BC479C0449872A2BBB79E9AB7@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef4be92f-702b-4c8d-f398-08d86ae9057c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2020 17:47:12.3315 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /ekH3nKQxY5QyFzwe70O8O4PifTssmTVf1DJ+0p9uYgTQr4Jah2hFxbhOFfeRtYcszrZ8dXun/98WORcCn2Q1Nx/ROqqS1axRJAWkDr/QtA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3547
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B_sALeopWJ9swA90YN9Ai6tQljU>
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2020 17:47:23 -0000

A strong +1 on the security issues of decode -> extract -> re-encode -> 
verify signature flow. The lack of canonical encoding can also mean that 
the resulting bytes can be different in different encoder/decoder 
implementations.

It would have been nice to have canonical JSON. Some implementations 
support it with flags such as "JSON_PRESERVE_ORDER" 
(https://jansson.readthedocs.io/en/2.8/apiref.html). Some specs try to 
specify things like keys should be in alphabetical order but fail to 
realize the complication with nested structures.

CBOR has thankfully specified canonical representation (called as 
deterministic encoding in 7049bis). Some CBOR libraries have added 
support: https://github.com/agronholm/cbor2/issues/6.

--Mohit

On 10/7/20 7:30 AM, Watson Ladd wrote:
> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema <huitema@huitema.net> wrote:
>> On 10/6/2020 10:00 AM, Michael D'Errico wrote:
>>
>>> It matters in X.509 certificates because the basic
>>> encoding rules (BER) allow you to specify the same
>>> thing in different ways.  With DER, there is only
>>> one way to encode every element, so everybody will
>>> come up with the same string of bytes and hashes of
>>> those strings will be the same, signatures will
>>> verify, etc.
>>
>> Well, we have learned a few things since 1994. The DER rules are defined
>> to allow a "re-encoding" workflow:
>>
>> * Sender side: prepare the message, encode with DER, sign the result
>>
>> * Receiver side: receive the message, parser with generic ASN.1 decoder,
>> process the message using the "parsed" representation, re-encode with
>> DER, check the signature.
>>
>> Experience showed that this workflow is very problematic, because the
>> parse/reencode process may introduce subtle changes and the signature
>> will fail.  One may argue that these changes are due to implementation
>> bugs, but fact it that this is a rich environment for growing bugs.
>> Based on experience, the receiver side is better done as:
>>
>> * Receiver side: receive the message, save it, parse and process, and
>> when it is time to verify the signature go back to the original message
>> and check the signature.
> Examining signed data ahead of verification, particularly to determine
> what should have signed it, is fraught with issues. In particular
> parser errors that would only be exploitable by trusted parties become
> exploitable by anyone. Furthermore, you should know the expected
> signer ahead of time. That this isn't possible in X509 due to
> inordinate flexibility is one of many pitfalls for implementors. This
> sort of issue periodically leads to authentication bypasses and other
> such fun.
A strong +1 to this.
>
> Sincerely,
> Watson Ladd
>
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls