Subject: [TLS] draft-tschofenig-tls-cwt comments

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 05:37:55 -0400

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

---

From: John Mattsson <[email-masked]>
Date: Wed, 20 Mar 2019 14:34:12 +0000

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 <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Wednesday, 20 March 2019 at 10:38
To: "[email-masked]" <[email-masked]>
Subject: [TLS] draft-tschofenig-tls-cwt comments

    

    

    Cheers,
    Martin
    
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls