Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson wrote: > On 21 July 2015 at 08:17, Ilari Liusvaara > wrote: > >> > *deadlock*. > >> > >> > >> Is this the case where the server is accepting 0-RTT or rejecting it? > > > > Apparently, only for accepting case. > > > > (If the server rejects, it can reply immediately, avoiding this > > deadlock). > > I don't think that this is a concern. You only have to say that the > server should not wait for the 0-RTT data before continuing with the > handshake. At some level, you can safely consider 0-RTT data as being > streamable/equivalent to application data. > This is what I have been assuming. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote:
> struct {
>select (Role) {
> case client:
>opaque identifier<0..2^16-1>;
>CipherSuite cipher_suite;// NEW
>Extension extensions<0..2^16-1>; // NEW
>
> case server:
>struct {};
>}
> } KnownConfigurationExtension
>
> The server would just need one configuration for each public key and
> woudldn't need to have any client-specific state. It also has the
> benefit that it makes PSK work with 0-RTT.
>
> Thoughts? Improvements?
A simple suggested improvement: name the fields clearly to indicate what they
are.
e.g.
opaque server_configuration_identifier<0..2^16-1>;
CipherSuite early_data_cipher_suite;
Extension cached_server_extensions<0..2^16-1>;
Use this same ID field name in ServerConfiguration.
Also, why is this ID allowed to be so big? It's extreme overkill now that it's
down to one config per pub key, with nothing client specific. It doesn't need a
string with a 16-bit length; it barely needs a single 16-bit integer.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 08:17, Ilari Liusvaara wrote: >> > *deadlock*. >> >> >> Is this the case where the server is accepting 0-RTT or rejecting it? > > Apparently, only for accepting case. > > (If the server rejects, it can reply immediately, avoiding this > deadlock). I don't think that this is a concern. You only have to say that the server should not wait for the 0-RTT data before continuing with the handshake. At some level, you can safely consider 0-RTT data as being streamable/equivalent to application data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 05:09:31PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > > > Also, with regard to ending 0RTT, even without encrypted content > > types. Either I am misunderstanding something, or: > > > > - Client: Send ClientHello. > > - Server: Read ClientHello. > > - Client: Send 0-RTT & client cert. > > - Server: Read 0-RTT & client cert. > > - Client: Wait for server reply. > > - Server: Wait for handshake message to end 0-RTT. > > *deadlock*. > > > Is this the case where the server is accepting 0-RTT or rejecting it? Apparently, only for accepting case. (If the server rejects, it can reply immediately, avoiding this deadlock). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: > > On 21 July 2015 at 06:08, Ilari Liusvaara > wrote: > > > Well, if it is about supported ciphers, there could be multiple, and > > > the proposal has slot for only one. > > > > The proposal is for what the client selects and uses for its first > flight. > > Oh darn, mislooked what message it was. > > > Also, with regard to ending 0RTT, even without encrypted content > types. Either I am misunderstanding something, or: > > - Client: Send ClientHello. > - Server: Read ClientHello. > - Client: Send 0-RTT & client cert. > - Server: Read 0-RTT & client cert. > - Client: Wait for server reply. > - Server: Wait for handshake message to end 0-RTT. > *deadlock*. Is this the case where the server is accepting 0-RTT or rejecting it? -Ekr > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: > On 21 July 2015 at 06:08, Ilari Liusvaara wrote: > > Well, if it is about supported ciphers, there could be multiple, and > > the proposal has slot for only one. > > The proposal is for what the client selects and uses for its first flight. Oh darn, mislooked what message it was. Also, with regard to ending 0RTT, even without encrypted content types. Either I am misunderstanding something, or: - Client: Send ClientHello. - Server: Read ClientHello. - Client: Send 0-RTT & client cert. - Server: Read 0-RTT & client cert. - Client: Wait for server reply. - Server: Wait for handshake message to end 0-RTT. *deadlock*. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 06:08, Ilari Liusvaara wrote: > Well, if it is about supported ciphers, there could be multiple, and > the proposal has slot for only one. The proposal is for what the client selects and uses for its first flight. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > > For 0-RTT/Early handshake data you want cipher that the server > > supports and accepts. If it is about this, there could be multiple > > allowed ciphers. > > > > In principle this is true. However, there are two complications, ISTM: > > 1. The client has no way of knowing which ciphers the server would support > other than the one it negotiated with the client previously (assuming > in-band) Well, if it is about supported ciphers, there could be multiple, and the proposal has slot for only one. > 2. I'm trying to avoid questions about the security of the negotiation for > the 0-RTT data, and we already have negotiated parameters. Can you give some examples of such questions? > I haven't done any analysis of what happens if the server doesn't check > that it would negotiate the parameters that the client provides. That might > be fine, but I'm trying to be conservative. I think it would either work fine (client picks something server supports/ accepts) or it would not work at all (client picks some unknown cipher). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > > > > > Yes, that's an issue. Not entirely sure what to do about other than > > > > have the server provide its negotiation preferences out of band > > > > in that case. > > > > > > I think that we could handle that at the point we define an > > > out-of-band configuration priming mechanism. I don't think we need a > > > full negotiation model for the server. A simple option would list the > > > server's preference order for suites and so forth in its configuration > > > advertisement; the client would then pick from that. > > > > > Yeah, or it could just have the semantics "this is my most preferred > > configuration and if you send me anything compatible with it, I will > > pick it" > > What cipher this is about? The cipher used for protecting 0RTT/Early > handshake data? The cipher used for protecting main connection? > The former. For main connection, the server can pick from ciphersuites advertized > by client (assuming client gives ciphers that are acceptable and > are usable with configurations, i.e. GDHE_CERT-type things). > Agreed. > For 0-RTT/Early handshake data you want cipher that the server > supports and accepts. If it is about this, there could be multiple > allowed ciphers. > In principle this is true. However, there are two complications, ISTM: 1. The client has no way of knowing which ciphers the server would support other than the one it negotiated with the client previously (assuming in-band) 2. I'm trying to avoid questions about the security of the negotiation for the 0-RTT data, and we already have negotiated parameters. I haven't done any analysis of what happens if the server doesn't check that it would negotiate the parameters that the client provides. That might be fine, but I'm trying to be conservative. Thanks, -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson > wrote: > > > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > > > Yes, that's an issue. Not entirely sure what to do about other than > > > have the server provide its negotiation preferences out of band > > > in that case. > > > > I think that we could handle that at the point we define an > > out-of-band configuration priming mechanism. I don't think we need a > > full negotiation model for the server. A simple option would list the > > server's preference order for suites and so forth in its configuration > > advertisement; the client would then pick from that. > > > Yeah, or it could just have the semantics "this is my most preferred > configuration and if you send me anything compatible with it, I will > pick it" What cipher this is about? The cipher used for protecting 0RTT/Early handshake data? The cipher used for protecting main connection? For main connection, the server can pick from ciphersuites advertized by client (assuming client gives ciphers that are acceptable and are usable with configurations, i.e. GDHE_CERT-type things). For 0-RTT/Early handshake data you want cipher that the server supports and accepts. If it is about this, there could be multiple allowed ciphers. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
Yeah, or it could just have the semantics "this is my most preferred configuration and if you send me anything compatible with it, I will pick it" -Ekr On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson wrote: > On 21 July 2015 at 04:12, Eric Rescorla wrote: > > > > Yes, that's an issue. Not entirely sure what to do about other than > > have the server provide its negotiation preferences out of band > > in that case. > > I think that we could handle that at the point we define an > out-of-band configuration priming mechanism. I don't think we need a > full negotiation model for the server. A simple option would list the > server's preference order for suites and so forth in its configuration > advertisement; the client would then pick from that. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 04:12, Eric Rescorla wrote: > > Yes, that's an issue. Not entirely sure what to do about other than > have the server provide its negotiation preferences out of band > in that case. I think that we could handle that at the point we define an out-of-band configuration priming mechanism. I don't think we need a full negotiation model for the server. A simple option would list the server's preference order for suites and so forth in its configuration advertisement; the client would then pick from that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson wrote: > On 21 July 2015 at 04:04, Eric Rescorla wrote: > > - The client indicates configuration ID and cryptographic configuration, > > including the cipher suites and cryptographic extensions. This > > MUST replicate the server's selection from a previous handshake > > > That's not going to work if there was no previous session. For > instance, if the configuration was learned out of band. Yes, that's an issue. Not entirely sure what to do about other than have the server provide its negotiation preferences out of band in that case. It also implies that the selection can come from ANY previous session, where I > think that it only makes sense to identify the session where the > configuration was learned. > I agree with this point. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On 21 July 2015 at 04:04, Eric Rescorla wrote: > - The client indicates configuration ID and cryptographic configuration, > including the cipher suites and cryptographic extensions. This > MUST replicate the server's selection from a previous handshake That's not going to work if there was no previous session. For instance, if the configuration was learned out of band. It also implies that the selection can come from ANY previous session, where I think that it only makes sense to identify the session where the configuration was learned. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Negotiating with known_configuration
The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This has the advantage of keeping things
short but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). After some thought,
I think this is a bad plan.
Here's what I propose (and what's in my slides for today):
- The client indicates configuration ID and cryptographic configuration,
including the cipher suites and cryptographic extensions. This
MUST replicate the server's selection from a previous handshake
- The server verifies the client's ClientHello and
(a) Checks that configuration ID is valid
(b) Verifies that client's parameters are what it would negotiate
Accordingly, this would change the extension to something like:
struct {
select (Role) {
case client:
opaque identifier<0..2^16-1>;
CipherSuite cipher_suite;// NEW
Extension extensions<0..2^16-1>; // NEW
case server:
struct {};
}
} KnownConfigurationExtension
The server would just need one configuration for each public key and
woudldn't need to have any client-specific state. It also has the
benefit that it makes PSK work with 0-RTT.
Thoughts? Improvements?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
