[TLS] ietf 93 slides
I've uploaded the chair’s slides and the other presentations I’ve received to date: https://datatracker.ietf.org/meeting/agenda/ spt ___ 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
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
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: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
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 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
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 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
[TLS] Fwd: I-D Action: draft-stjohns-kdf-with-assignment-00.txt
On 7/21/2015 9:21 AM, Michael StJohns wrote: FYI - This is my long delayed KDF document. I think its late enough that it isn't a useful submission for TLS1.3, but I would appreciate any feedback on it. It may eventually be useful for the next group of protocol revisions. Thanks - Mike From: internet-dra...@ietf.org To: Subject: I-D Action: draft-stjohns-kdf-with-assignment-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Key Derivation Functions with Assignment Author : Michael C StJohns Filename: draft-stjohns-kdf-with-assignment-00.txt Pages : 20 Date: 2015-07-21 Abstract: This document describes a key derivation function (KDF) wrap-around or a meta-KDF that's designed to mix in key assignment parameters to the key stream generation phase. This allows a security module to rely upon and enforce the key assignment parameters during the assigment of key material from the generated key stream to the cryptographic objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-stjohns-kdf-with-assignment/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-stjohns-kdf-with-assignment-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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 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] (selection criteria for crypto primitives) Re: sect571r1
Rene Struik schrieb am 16.07.2015 um 03:42: > Dear colleagues: > > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, > one should perhaps have some diversity of gene pool criteria within the set > of recommend curves and not only include > special primes. Should some problem with a particular subclass show up over > time, one then at least has other classes > available. > > On a general note, I do not understand what is wrong with having a dictionary > of curves that is well-specified, but > whose members are not all widely used. To my knowledge, having a dictionary > does not force everyone to use every term in > this (mandatory vs. optional to implement vs. mandatory to use, etc.). > > If one follows the line of reasoning of some people on the mailing list > earlier today, doesn't this also call into > question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this > certainly calls into question why one would > have a whole set of new DLP groups (which certainly cannot be widely used > yet, since the ink to write the parameters > down is still wet). What about RSA-1024, etc.? > I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware manufacturers, certification bodies) prefer curves over random primes. And as Rene has pointed out, allowing both would also give more agility w.r.t potential future attacks on certain sub-classes. Why can't the draft just specify the curves that are MTI but allow (at least some) alternative options, instead of putting all our eggs in one basket? Johannes ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Tue, Jul 21, 2015 at 04:39:17PM +0200, Johannes Merkle wrote: > > I absolutely back up this position. Currently, the TLS 1.3 draft only permits > curves over special primes. It has become > quite clear in the discussions in CFRG and at the NIST ECC workshop that some > parties (major hardware manufacturers, > certification bodies) prefer curves over random primes. And as Rene has > pointed out, allowing both would also give more > agility w.r.t potential future attacks on certain sub-classes. I thought that Brainpool curves weren't removed (even if those aren't explicitly in), which are random prime curves. Also, the security of binary curves seems quite questionable. And I would expect that if more curves croak, either relatively few curves croak (in style of MOV or SASS), or almost everything croaks. -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 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 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] (selection criteria for crypto primitives) Re: sect571r1
On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > I thought that Brainpool curves weren't removed (even if those aren't > explicitly in), which are random prime curves. > > Also, the security of binary curves seems quite questionable. Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited either. If there's no strong objection, I'd like to add them to the list, if just to document the current NamedGroup registry. I could add a recommendation to stick to standards track, for those worrying about them. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 Dave ___ 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] (selection criteria for crypto primitives) Re: sect571r1
On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote: > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > > I thought that Brainpool curves weren't removed (even if those aren't > > explicitly in), which are random prime curves. > > > > Also, the security of binary curves seems quite questionable. > > Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited > either. > > If there's no strong objection, I'd like to add them to the list, if > just to document the current NamedGroup registry. I could add a > recommendation to stick to standards track, for those worrying about them. Related: There's the following draft: draft-iab-crypto-alg-agility (currently in IETF LC) which contains the following: 3.4 National Cipher Suites "The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required." While the thing is about cipher suites, it also goes for curves. Also, Brainpool is much slower than the special prime stuff, so I think the defaults should be high-performance where it is not known to hurt security. This could also be applied to some actual ciphersuite stuff, namely ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote: > On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote: > > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > > > I thought that Brainpool curves weren't removed (even if those aren't > > > explicitly in), which are random prime curves. > > > > > > Also, the security of binary curves seems quite questionable. > > > > Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited > either. > > > > If there's no strong objection, I'd like to add them to the list, if > > just to document the current NamedGroup registry. I could add a > > recommendation to stick to standards track, for those worrying about > them. > > Related: There's the following draft: draft-iab-crypto-alg-agility > (currently in IETF LC) which contains the following: > > 3.4 National Cipher Suites > > "The default server or > responder configuration SHOULD disable such algorithms; in this way, > explicit action by the system administrator is needed to enable them > where they are actually required." > > While the thing is about cipher suites, it also goes for curves. > > Also, Brainpool is much slower than the special prime stuff, > so I think the defaults should be high-performance where it is > not known to hurt security. > > > This could also be applied to some actual ciphersuite stuff, namely > ARIA and CAMELLIA (there doesn't seem to be any usable SEED ciphers). I would be comfortable with taking a hard look at these. -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 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] A la carte handshake negotiation
I've updated the a la carte proposal again with some improvements to readability. I've also added in the ECDHE PSK cipher suites in the current draft, as they are required for this. current WIP text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites diff from PR #201: https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
