Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

[Nick Sullivan <[e-mail]>]

The other option is to restructure this document so that the frame 0
communication is handled in the TLS layer using this proposal (or something
like it):
https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00

Moving the authentication and certificate exchange to a lower layer should
answer many of the questions raised in this thread.

Nick

On Sun, Jul 24, 2016 at 4:23 AM Ilari Liusvaara <[e-mail]>
wrote:

> On Sun, Jul 24, 2016 at 12:56:31PM +0200, Martin Thomson wrote:
> > On 24 July 2016 at 12:34, Ilari Liusvaara <[e-mail]>
> wrote:
> > > I think one needs to also sign and MAC over any implicit parameters
> > > that are shared over multiple authentications. E.g. Supported end-
> > > certificate signature algorithms.
> >
> > My understanding of SIGMA is that the MAC needs to cover the identity
> > and other properties, but the signature only has to cover the key
> > shares (or shared key).  Thankfully we don't need to worry about that
> > distinction because of the way that TLS 1.3 and EMS cause everything
> > to depend on everything else: keys depend on identity and negotiation
> > parameters as much as the MAC does.
>
> I thought the easiest way is to multi-tap hashes (in the same style
> TLS 1.3 does), which impiles that the both cover the same things
> (modulo MAC also covering the signature)...
>
> And if MAC needs to cover the "implicit" properties, it means you
> need to be able to include those into computations.
>
> > Either way, I am increasingly of the opinion that we should ask for
> > this facility from the TLS working group.  There are subtleties to
> > this that are easy to get wrong and good analysis is crucial.
>
> I think before that, one should plan the interface to HTTP/2 and
> some rough ideas for what information is passed.
>
> E.g.
> - Are the requests transferred as header blocks or binary blobs
>   (I presume responses are binary blobs)?
> - At least which parameters are present for each request?
> - What of above parameters are shared over multiple requests?
> - How many flights are allowable (I presume 1 request + 1 response,
>   but this should be explicit)?
> - If typed auxillary data (e.g. OCSP staple or SCT staple) can be
>   passed back or not?
>
> This is to know what to request, so one avoids nasty surprises
> of having hard time figuring out how to pluck the result into
> HTTP/2.
>
>
> And I think certificate use control should be separate mechanism,
> operating over proven certificates in client->server direction.
>
>
> -Ilari
>
>