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

[Martin Thomson]

On 8 August 2016 at 16:14, Ilari Liusvaara  wrote:
> In 2, I would imagine the context is probably usually a sequence
> number of some kind.

The draft defines some rules for construction of identifiers that
prevent collisions and the like.

>> 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...

Of course.  See
https://github.com/grittygrease/tls13-post-handshake-auth/issues/18
(feel free to contribute)

> 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.

Sure.  The usual async API guarantees apply here; I don't know that
this needs special treatment in the spec though.  If you disagree, I'm
sure that my coauthors would be happy to take suggestions for
improvements.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Mon, Aug 08, 2016 at 11:19:39AM +1000, Martin Thomson wrote:
> On 7 August 2016 at 03:26, Ilari Liusvaara  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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 7 August 2016 at 03:26, Ilari Liusvaara  wrote:
> Also, how would this be used in applications that need higher-level
> coordination above TLS layer (like HTTP/2)?

The companion h2 draft hasn't been updated, but this will need support
from the application layer to use.  The intent is to take the
structure of draft-bishop-httpbis-http2-additional-certs and remove
the stream 0 components and replace them with this draft.

> 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)

> 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.

> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Sat, Aug 06, 2016 at 01:38:40AM +, Nick Sullivan wrote:
> 
> 
> We discussed on this list a proposal to allow secondary certificate
> authentication in HTTP/2 (https://tools.ietf.org/html/draft-bishop-httpbis-
> http2-additional-certs). In that discussion, some questions were raised
> around whether or not certificate authentication should be handled in the
> HTTP/2 layer or at the TLS layer. This draft is our attempt to create a
> more complete mechanism for post-handshake authentication in TLS 1.3 that
> supports standard use cases like in-browser client certificate
> authentication as well as new use cases like secondary certificate
> authentication in HTTP/2.

Also, how would this be used in applications that need higher-level
coordination above TLS layer (like HTTP/2)?

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).

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.

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.

> This draft takes the post-handshake client authentication mechanism from
> TLS 1.3 (Section 4.4.2.) and generalizes it to allow four types of
> post-handshake authentication:
> * solicited client authentication
> * spontaneous client authentication
> * solicited server authentication
> * spontaneous server authentication
> Support for these modes is negotiated in a new TLS extension.

The crypto used looks bit odd. AFAIU, if one wants to chain hashes,
one should expand the chaining value to multiple of input block and
continue from there.

One could even use the normal TLS authentication block with
extended_handshake_hash as base context (with certificate request
included if present). extended_handshake_hash can either be
the same handshake_hash used for calculating EMS/RMS but padded
to multiple of blocksize, or special HKDF-extracted value that
is one hash input in size.

For SHA-256 "one hash input" is 64 bytes, for SHA-384, it is 128 bytes
[1]

I.e. the signature TBS (without context) is:

hash(extended_handshake_hash + certificate_request* + certificate) +
resumption_context

And the MAC input is:

hash(extended_handshake_hash + certificate_request* + certificate
+ certificate_verify) + resumption_context

Where extended_handshake_hash can be:

hash(ClientHello...ClientFinished), padded to input block.

or

HKDF-Expand-Label result with HashValue=hash(ClientHello...ClientFinished)
and length being hash input block.


> As written, this draft is complementary to the current TLS 1.3 draft,
> however, it makes use of modified versions of the Certificate and
> CertificateRequest structures instead of those from TLS 1.3. If the working
> group agrees that a separate draft is a reasonable approach for
> post-handshake authentication, it may make sense to merge the structure
> changes from this draft into the TLS 1.3 specification and remove
> post-handshake authentication from TLS 1.3. Doing so would likely make both
> TLS 1.3 and this draft smaller, simpler to analyze, and easier to implement.

Yeah, the post-handshake parts are annoying to implement even if one
does not support actual post-handshake auth (due to the requirement to
send Finished) if one wants to do anything else except just plain not
respond to server requests (or even worse, just terminate the
connection).

 
> This draft comes with the caveat that the new post-handshake flows still
> need formal a security proof.

Just keep in mind that even if it is secure at TLS level, does not mean
it is secure at application level!



[1] SHA3-256 would have 136, SHA3-384 would have 104. BLAKE2b would
have 128.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

We discussed on this list a proposal to allow secondary certificate
authentication in HTTP/2 (https://tools.ietf.org/html/draft-bishop-httpbis-
http2-additional-certs). In that discussion, some questions were raised
around whether or not certificate authentication should be handled in the
HTTP/2 layer or at the TLS layer. This draft is our attempt to create a
more complete mechanism for post-handshake authentication in TLS 1.3 that
supports standard use cases like in-browser client certificate
authentication as well as new use cases like secondary certificate
authentication in HTTP/2.

This draft takes the post-handshake client authentication mechanism from
TLS 1.3 (Section 4.4.2.) and generalizes it to allow four types of
post-handshake authentication:
* solicited client authentication
* spontaneous client authentication
* solicited server authentication
* spontaneous server authentication
Support for these modes is negotiated in a new TLS extension.

As written, this draft is complementary to the current TLS 1.3 draft,
however, it makes use of modified versions of the Certificate and
CertificateRequest structures instead of those from TLS 1.3. If the working
group agrees that a separate draft is a reasonable approach for
post-handshake authentication, it may make sense to merge the structure
changes from this draft into the TLS 1.3 specification and remove
post-handshake authentication from TLS 1.3. Doing so would likely make both
TLS 1.3 and this draft smaller, simpler to analyze, and easier to implement.

This draft comes with the caveat that the new post-handshake flows still
need formal a security proof.

Nick Sullivan
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls