On Wed 2015-09-16 13:48:27 -0400, Martin Thomson <[email protected]>
wrote:
> On 16 September 2015 at 08:30, Ilari Liusvaara <[email protected]>
> wrote:
>> As then the application needs to ensure that the authentication
>> occurs between TLS handshake and actually starting up the protocol.
>
> I'm not sure that is necessarily a problem. If the claim is that the
> authentication attests to everything prior to its appearance, then you
> have no problem. I think that claim is reasonable, but I'm happy to
> discuss it.
I think this claim sounds confusing, for (at least) two reasons:
(a) it interacts oddly with the possibility of > 1 CertificateVerify
message -- does it imply that all messages in a TLS session
(past and present) are attested to by every client certificate ever
sent in the session?
(b) it has unclear semantics around session resumption. If i resume a
session and send a ClientCert+CertificateVerify, am i retroactively
attesting to all the communications from the previous session(s)?
What does that even mean to the server which has already processed
the traffic from previous sessions?
Can we communicate these semantics to application developers who might
have an "accelerating" TLS session cache available, or who might share a
session cache between systems? Can we help clients make sense of the
implications of retroactive attestation when confronted with a
certificateRequest?
--dkg
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
