Re: [TLS] draft-sullivan-tls-post-handshake-auth-00

[Ilari Liusvaara <[e-mail]>]

On Mon, Aug 08, 2016 at 11:19:39AM +1000, Martin Thomson wrote:
> On 7 August 2016 at 03:26, Ilari Liusvaara <[e-mail]> wrote:
> 
> > Can applications specify and receive the context values used? E.g.
> > to act as handles to refer to the resulting authority objects
> > (HTTP/2 absolutely needs to be able to refer to client authority).
> 
> The API might take one of two forms:
> 1. an application requests that authentication happen and get the
> identifier that TLS uses in return
> 2. an application requests authentication and specifies the identifier
> (the TLS stack will have to verify that this is unique and conforms to
> the restrictions)

In 2, I would imagine the context is probably usually a sequence
number of some kind.
 
> > Also, are all errors (including things like getting extensions
> > wrong or CA wrong) fatal to the whole connection, or how is error
> > reporting handled? One can't use alerts for non-fatal reports.
> 
> Good question.  Errors in encoding or otherwise problems following the
> rules in the spec should result in a connection-level fatal error.
> But if the certificate isn't trusted, handling that will be up to the
> application.

And that should presumably be communicated somehow...

> > Also, are applications expected to be able to specify exactly
> > where in stream to put an authentication (response)? Especially
> > so they can immediately follow with appdata coordinating the
> > usage.
> 
> Not sure where you are going here.

Being able for application to to wait for certificate/cv/finised
message to be sent, so it can do something special in application
layer immediately after that.



-Ilari