Re: [TLS] I-D Action: draft-ietf-tls-ctls-01.txt
Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 02 November 2020 21:46 UTC
Return-Path: <ilariliusvaara@welho.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 4E8623A0EC7 for <tls@ietfa.amsl.com>; Mon, 2 Nov 2020 13:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9L3gFTrh3mfC for <tls@ietfa.amsl.com>; Mon, 2 Nov 2020 13:46:55 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4513C3A08B8 for <tls@ietf.org>; Mon, 2 Nov 2020 13:46:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 2BC1B2259D for <tls@ietf.org>; Mon, 2 Nov 2020 23:46:53 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Qc4Cfd-k1PSG for <tls@ietf.org>; Mon, 2 Nov 2020 23:46:52 +0200 (EET)
Received: from LK-Perkele-VII (78-27-99-170.bb.dnainternet.fi [78.27.99.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A0680292 for <tls@ietf.org>; Mon, 2 Nov 2020 23:46:51 +0200 (EET)
Date: Mon, 02 Nov 2020 23:46:50 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20201102214650.GA3148245@LK-Perkele-VII>
References: <160434088886.13331.8358635973543939345@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <160434088886.13331.8358635973543939345@ietfa.amsl.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mlepPSwm5c9loTOA6SE7gNTZ7Ak>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ctls-01.txt
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: Mon, 02 Nov 2020 21:46:57 -0000
On Mon, Nov 02, 2020 at 10:14:48AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Compact TLS 1.3 > Authors : Eric Rescorla > Richard Barnes > Hannes Tschofenig > Filename : draft-ietf-tls-ctls-01.txt > Pages : 19 > Date : 2020-11-02 Some comments: - Section 3.1. Varints: Using varint encoding is problematic for PskIdentity.obfuscated_ticket_age and NewSessionTicket.ticket_age_add, since these are actually cryptographic values, and cryptography and variable-length do not mix. RFC8446 defines these to be uint32_t, so they would get caught by the varint rule. - Section 3.2. Record Layer: How are alerts represented? Some TLS alerts are in plaintext. Especially: * Server puking on something in client hello. * Client puking on something in server hello. And some TLS libraries have more cases: * Failing to decrypt first encrypted server record. * Client puking on anything in EE..serverFinished. - Section 3.2. Record Layer: Could be useful to divide transports into three classes (these classes are isomorphic to socket types in Linux): * DGRAM: Packet-oriented, unreliable (e.g., UDP) + Length: OPTIONAL + Sequence numbers: REQUIRED * STREAM: Byte-oriented, reliable (e.g., TCP) + Length: REQUIRED + Sequence numbers: OPTIONAL * SEQPACKET: Packet-oriented, reliable (apperntly SCTP can do this) + Length: OPTIONAL + Sequence numbers: OPTIONAL - Section 5. Template-Based Specialization: I fear that having specialization work without modifying transcripts leads to prohibitive complexity. Especially considering that cTLS seems to be aimed at (semi-)constrained environments. Being able to directly work with on-wire specialized represenations would be much simpler code-wise. And I would guess that to make that safe, one would only need to inject the profile hash into handshake (as sythetic message, in style of how first ClientHello is bound on restart in TLS 1.3). This would require being able to canonically serialie profiles, which would have implications as detailed below. - Section 5.1. Specifying a Specialization: If this is ever serialized, entiere use of JSON needs to be dumped. The reason for this is that it is not dictionaries (objects) are the problem in canonicalizing JSON, it is numbers that are the problem. There exists CBOR, which is essentially binary encoding of mildly extended version of JSON. The main differences: * There is octet string type. * Dictionaries can also be keyed by integers and octet strings (and one can mix-and-match the types in the same dictionary). * Integer range is limited to -18446744073709551616 to 18446744073709551615 (superset of interoperable JSON). * Canonicalization is easy. - Section 5.1. Specifying a Specialization: suppressSequenceNumber seems to only make sense if DGRAM transports are supported. And in that case, one needs mechanism to retransmit lost handshake messages. And considering apperant itended scope, the DTLS 1.3 mechanism looks to be way too complex. - Section 5.1. Specifying a Specialization: dhGroup could also save some more bytes (3?) by having key_share encode the raw share, and then reconstruct one-element list from that. - Section 5.1. Specifying a Specialization: signatureAlgorithm could save 2 bytes by having it also automatcally encode the signature algorithm value in server CertificateVerify message. - Section 5.1. Specifying a Specialization: Some more ideas for specializations: * Server signature size (saves 1 byte) * ECDSA signature compression (saves ~7 bytes). (note that uncompressed ECDS signatures do not have constant size, but compressed ones do). - Section 5.1.1. Requirements on the TLS Implementation: Ascending order will not work with extension 41, as it is magic and needs to be last. 0 to 40, 42 to 65535 and 41 would work. - Section 6. Examples: Why is that '"named_groups": 29' there? - Section 6. Examples: Why is the ALPN extension encoded as "030016832"? That doesn't even seem to be of integral number of octets. I get that the value should be "03026832". - Section 7. Security Considerations On transcript expansion, suppressSequenceNumber looks to make any sense only if DGRAM transports are also supported, and it is not obvious to me that uncompressing to TLS 1.3 is possible in such cases. It is also not obvious to me that explicit transcript expansion can be implemented with acceptable complexity, especially considering the apparent intended scope. -Ilari
- [TLS] I-D Action: draft-ietf-tls-ctls-01.txt internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-ctls-01.txt Ilari Liusvaara