Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01

[Stephen Checkoway <[e-mail]>]

On Feb 23, 2014, at 8:31 PM, Watson Ladd <[e-mail]> wrote:

> On Sun, Feb 23, 2014 at 5:20 PM, Stephen Checkoway <[e-mail]> wrote:
>> Hi Watson,
>> 
>> On Feb 23, 2014, at 7:41 PM, Watson Ladd <[e-mail]> wrote:
>> 
>>> Easy solution: limit the options so that there is one acceptable
>>> choice,
>> 
>> As much as this appeals to me, this route seems unlikely to be adopted since what's acceptable to you or me is probably not acceptable to everyone.
>> 
>>> with a means to negotiate a future one when that one
>>> acceptable choice falls.
>> 
>> It seems likely that this will because the default method and I'm not sure how this is simpler than offering options initially.
> 
> Does anyone have a problem with P256 or Curve25519 with some fallback
> option TBD?

I don't have a problem with either but, again, that doesn't say anything about everyone else.

>>> I'm proposing that we secure the key we are sending SNI data to with
>>> some certificate
>> 
>> I'm not sure I'm following you here. As I understand it, the whole issue is that with SNI the server doesn't know which cert to use until after it sees the SNI. Are you proposing that there is some master cert which secures the key used for SNI data and then a separate cert for the given server name?
> 
> In the SNI case the server has a great number of certificates to pick
> from, and doesn't know which one to use. My suggestion is that they
> use on initially, and if informed they messed up, use that one.

So say the server picks the wrong one. This reveals a different server name to the client. This would seem to be an issue if the various names the server is willing to use are private for some reason. With the wrong one chosen, the client has three options: (1) send the SNI in the clear to the server; (2) use the unauthenticated server parameters to establish a key and send the SNI encrypted under that key; or (3) say "nope, pick a different cert and try again."

(1) is essentially what we have today but with more overhead;
(2) is essentially the proposed mechanism except that it has more overhead and exposes the server name of the incorrectly chosen cert; and
(3) could take a significant number of round trips to get the right cert and also enables a client to enumerate all supported server names.

None of these seem better so I've probably misunderstood what you're actually proposing.

-- 
Stephen Checkoway