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

[Eric Rescorla <[e-mail]>]

"Mark Brown" <[e-mail]> writes:
>> > 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.

Preconfiguring all the servers you're willing to sign with scales
as well as installing a single client cert?



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

But they're not two TLS servers now, they're one. So, you're proposing
a massive rearchitecture of people's servers--and think about this
scales next time you want to add such a feature! Easier to just add
message signing, which doesn't require any such rearchitecture.


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

You're assuming that each transaction is only covered by one set
of signatures. But there's no such requirement in TLS. You can
send every byte as a separate SSL record--and it's quite common
for an HTTPS response to span multiple records. 


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

I don't agree with this assessment, for reasons I think I've indicated
as nauseum.


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

But to a first order, these mistakes are a result of your attempt 
to put signatures at a layer with inappropriate semantics. There
are a lot fewer mistakes to be made if the signatures are done at
the right layer. And I'm not at all convinced that any amount of
hacking on this general architecture will produce an acceptable
result.


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

You're assuming the exact point I'm contesting, which is that this
should be done at all.

-Ekr


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