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

["Mark Brown" <[e-mail]>]

Eric,

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

You're right.  

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

You're right again.  I could drop the port number; then it scales about as
well as using client certs.  I think the "scales well?" comparison here
should be made against client cert use cases.  

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


This seems like a misunderstanding.  I'm proposing two web servers over two
TLS instances using two PKCs in this illustration.  On the web server using
the "evidence" TLS instance you don't need to check for EvidenceResponse any
more than the web server on a normal TLS instance double checks that
encryption was performed.  TLS Evidence is on or it's not.

Is your concern the semantics?  In the brokerage scenario, the second
EvidenceResponse either is or it isn't.  What does the brokerage care if the
TLS client never countersigns the issued receipt?  The TLS layer's TLS
Evidence implementation will ensure that no further application data is
allowed back up to the app server in this case.  If the TLS client drops off
and hangs up, there's no problem.  If the TLS client skips its
countersignature and yet still wants to turn around and send more app data
then the TLS Evidence implementation will block this.

> there's still the relative inefficiency
> of your signature mechanism, which is conservatively a factor of 2-4
> slower than app-level signatures.

Yes, you're right.  Twice-signed is slower than single-signed, especially
when you figure in network latency as proposed.  Using order-of-magnitude
computations, twice-signed is probably about as costly as a TLS handshake.
Both estimates really hinge on network latency which is a bit of a wildcard.

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

I expect that most TLS Extensions will require some modification to the TLS
instance, modifying both client and server.  My goal is to eliminate impact
on the TLS-app API except for opt-ins to TLS Evidence, and then, to minimize
impact.  I've made progress, thanks to input on this list.  I think we're
currently at "no impact" unless opt-in occurs.  Where opt-in occurs, I
believe that the server impact occurs only at TLS server installation /
configure time.  Client has to configure per-cert as its opt-in action,
assuming a TLS Evidence instance already exists.  I think that overall this
is shaping up to be pretty close to current TLS practice, but I'm interested
in your opinion.

> 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

I think that if we can work out the sorts of concerns you raise here, we
will save applications from having to make these exact mistakes (and worse)
over and over again.  Your suggestions and others are valuable and based on
a lot of experience that most of the rest of us don't have.  Let's move this
entire discussion forward for everyone by making the compromises that stick
and documenting them in a spec.

--mark


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