On Mon, Nov 02, 2020 at 10:14:48AM -0800, [email protected] 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
