Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - brokerage illustration

[Eric Rescorla <[e-mail]>]

"Mark Brown" <[e-mail]> writes:
> Let me retrace Eric's line of thought first, using his broker illustration:
>
> 1) 100's of fetches to accomplish a trade:  In HTTP the TCP/IP session gets
> torn down after every fetch.

Uh, not in any modern HTTP stack, no. I refer you to RFC 2616 S 8.1.


> This TLS client configuration line identifies one DNS name and port number
> for which the client will always ClientHello using TLS Evidence.

It does what??? I need to hard-configure some list of names and ports?
That scales how?


> To one of Eric's concerns, in this illustration there really is no change
> required for either the TLS client or the TLS server APIs (i.e. how the
> application interacts programmatically with the TLS layer).

No. The server *still* needs to check that he's actually getting
evidence. I.e., that the client is coming in through the right
virtual server (unless you're proposing that I rearchitect
all my server apps to split every kind of transaction into
two different servers), and there's still the relative inefficiency
of your signature mechanism, which is conservatively a factor of 2-4
slower than app-level signatures.

So, you've had to modify both client and server, you quite
possibly had to substantially rearchitect the server, and the
client has to have some semi-manual configuration settings to
determine when it offers evidence. None of this seems
particularly convenient. 

To uplevel a moment, I'm not arguing that you can't make some proposal
along the lines you indicate sort of work. What I am arguing is that
it isn't substantially simpler than the application-level signature
alternatives, that it offers inferior semantics, and that it doesn't
fit well with the TLS architecture. None of this discussion has
changed my views on that point.

-Ekr


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls