Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara <[e-mail]>]

On Fri, Sep 23, 2016 at 12:42:09AM +0000, Nick Sullivan wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/654
> 
> Hello,
> 
> I'd like to propose a small to the Certificate message format to allow for
> future extensibility of the protocol.
> 
> This change adds a set of extensions to the Certificate message. With this
> change, the Certificate message can now hold all extension messages that
> are certificate-specific (rather than connection-specific). This change
> also resolves the anomaly of OCSP messages appearing before certificates in
> the handshake.
> 
> Reasoning:
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
> and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
> per-connection metadata. By putting these responses in the
> EncryptedExtensions, you limit these extensions to being shown once per
> connection. This restricts future protocol extensions from using multiple
> Certificate messages to support multiple certificates on the same
> connection. An example of this is the post-handshake authentication
> proposal (
> https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
> which currently requires a modified post-handshake Certificate message.
> This proposed change would simplify the post-handshake auth proposal
> significantly and generally make more sense as more certificate-specific
> extensions are created.

Also, this would presumably solve the user_mapping problem without
introducing a new handshake message. Basically, there is extension
user_mapping, that wants to send some certificate-associated auxillary
data from client to server. Currnently, there is no place to put such
data.

And yeah, with post-handshake auth, it looks like one would want a lot
more flexibility than currently exists.


BTW: I would rather dump the current post-handshake auth for such
extension proposal. The current post-handshake authentication is just
plain annoying to implement in contexts where the client has no
intention of ever supporting it.

And the current post-handshake auth mechanism seems to be insufficient
for real-world uses too...

I recently got an idea of implementing freezing session state into
octet stream and being able to thaw such. I quickly discovered I
can't implement that without either having freezable hashes (which I
don't have available) or just saying screw it with post-handshake auth
and never responding to the requests, even to reject them.



-Ilari