My current feeling is that this is worth doing. The use of CWT have been
discussed in several IoT groups lately and will be discussed at Sec-Dispatch in
Prague (2.5 Concise IDs)
In a general TLS context, it could be discussed if the draft should support JWT
as well.
My feeling is that the TLS WG should in most cases focus on TLS 1.3 only.
Supporting TLS 1.2 as well complicates things and takes up valuable time that
could be spent on other things. Implementations willing to update significant
amount of code should update to TLS 1.3.
The inclusion of CWT with PSK should probably be done as an update to
PreSharedKeyExtension (similar to the construction of ID_PSK in
draft-selander-ace-cose-ecdhe-13) instead of as a new certificate type. I don't
know how to encode a CWT in the PreSharedKeyExtension in a good way. May
actually require a new PreSharedKeyCWTExtension.
Cheers,
John
-----Original Message-----
From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson
<m...@lowentropy.net>
Date: Wednesday, 20 March 2019 at 10:38
To: "TLS@ietf.org" <tls@ietf.org>
Subject: [TLS] draft-tschofenig-tls-cwt comments
I've no real opinion on whether this draft is worth doing, because that
depends on making an assessment about CWT and I keep bouncing off the C part.
I guess that the point of the draft is to start that part of the discussion,
which is a fine thing.
There are a few more mundane, mechanical issues I noted when reading the
draft.
This appears to be aimed at both TLS 1.2 and TLS 1.3. That should be made
clearer. Supporting TLS 1.2 complicates the design.
The mapping from CWT to TLS signature scheme (or signature algorithms in
1.2) needs to be clearer. Also, the interactions with the TLS 1.3
signature_algorithms_cert extension need some treatment. For some of what I
think is being proposed, that requires the definition of new methods of
producing CertificateVerify messages.
The symmetric key stuff needs considerably more meat on it. How does the
sender know what encryption schemes are used? Why use an encrypted key and not
just a key identifier (or PSK for that matter)?
Section 4 is interesting. It's good to see a treatment of this issue here.
However, this is missing the piece where the server checks to see if it is
willing to offer the identity it has been given via server_name.
The use of a URI as an identity is new. It narrows the conception of
server identity in a way that could be useful. However, it needs far more
thorough a treatment than this text gives. Take a look at RFC 6125 if you want
to get an appreciation for what thorough means in this context.
Cheers,
Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
