On Sun, Apr 26, 2020 at 02:10:02PM -0700, internet-dra...@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-00.txt
> Pages : 17
> Date : 2020-04-26
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-ctls-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00
First impressions:
- I think this protocol should use different label in key derivations
from the "tls13" label used by TLS 1.3. I do not see any fundamential
reason why transcripts could not collide with TLS 1.3 ones.
- It seems not be possible for server to support multiple profiles at
once. This could be useful for things like updating clients to use
better algorithms.
- It probably makes sense to support the case where client profile has
incomplete list of certificates. E.g., some IoT client only knows its
own and server certificates, whereas the server knows all
certificates.
- If one wanted dual TLS 1.3/cTLS server, one would presumably have to
define TCP mapping.
Simplest one that might work: Connection starts with fixed byte
(which should not be 20-126 to be able to tell the thing apart from
both TLS 1.x and HTTP), followed by sequence of records, where each
record is prefixed with varint length. Application data records
transport application data.
However, cTLS is not quite "TLS 2.0", as that would presumably move
some important extensions into top-level messages. Especially stuff
like supported_groups, key_share and pre_shared_key.
- There is one special case where epoch is not clear: alert mesages in
response to server handshake. These can be unprotected despite being
in position where protected record is possible.
It is possible to tell apart unprotected alerts from everything else
by size. Unprotected alerts are 2 bytes (if the useless severity field
is stripped out), and no protected record can be that small.
- Just blindly switching all integers to varints does not work, as there
are integer fields that can legimately have integer values >=2^22.
TLS 1.3 spec itself has two of those: PskIdentity.obfuscated_ticket_age
and NewSessionTicket.ticket_age_add. And with those two, it is not
even possible to just take modulo 2^22, as the time unit is
milliseconds, so that would limit the ticket age to just ~70 minutes.
Some extensions have more integer fields that can be >=2^22, but none
that I can find where limiting to 2^22-1 would be a significant issue.
- Strict ascending extension sort probably does not work, as extension
41 is magic due to having to be last in client hello. If there is
strict extension sort, most straightforward fix would be to make the
order 0,1,2,3,4,..,39,40,42,43,,..,65534,65535,41.
- Some ways to eke a few more bytes out of profiling:
* If group is specified, move key share out of extensions.
* If group is specified to something with fixed length, omit the
group length.
* If using uncompressed P-x keys, strip the 04 prefix (does not work
with X25519 nor X448, as there is no prefix).
* If using compressed P-521 keys, stuff the sign bit into unused bit
of the x coordinate field (does not work with P-256 nor P-384 as
there are no unused bits in x coordinate field, nor with X25519 nor
X448 as there is no sign bit).
* If signature algorith is specified, omit the signature algorithm.
* If EncryptedExtensions is empty, omit it (can tell if it is there
from type sequence).
* Re-encode ECDSA signatures to raw form (can also be done without
profiling; does not work with Ed25519 nor Ed448 as the signatures
are already in raw form).
* If signature algorithm has fixed signature length, omit it in
signatures (e.g., Ed25519 and raw form ECDSA/P-256 are always
64 bytes; can also be done without profiling).
- The example in A.1 looks suspect:
* Why is client_shares.length encoded as 2 bytes? it is vector
length <128, so should be 1 byte?
* Why is KeyShareEntry.group encoded as 2 bytes? It is enumeration
value <128, so should be 1 byte? (Both in Client Hello and Server
Hello).
* Why is length of KeyShareEntry.key_exchange encoded as 2 bytes?
It is vector length <128, so should be 1 byte? (Both in Client
Hello and Server Hello).
* Why does the signature start with 4047? The signature should be
71 bytes, so should be 47? (Both in server and client flights).
- And example in A.2 has this:
* Server hello has 18 bytes = RANDOM(16) + 2 ... Those 2 are
presumably overhead?
* Client Flight: 1 byte = Overhead(3) ... Should presumably be
1 byte of overhead.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
