[TLS] 4492bis table 1
Is table 1 correct? +---+-++ | Symmetric | ECC | DH/DSA/RSA | +---+-++ | 80| 163 |1024| |112| 233 |2048| |128| 283 |3072| |192| 409 |7680| |256| 571 | 15360| +---+-++ Aren't we dropping 571? Can we use values that match up. Or, drop the table. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] 4492 ECDH_anon
I have never understood why 4492 doesn't claim forward secrecy for ECDH_anon suites. Can someone explain why this doesn't have an 'E'? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
I'd like to see the bits of the cipher suite associated entirely with ephemeral data tied together roughly by security margin, to avoid combinations that don't make sense (e.g., straw men of RSA384 + AES256 or AES256 + CRC32). This means: the type/size of the (EC)DHE group and the symmetric cipher (and possibly the MAC, if it's anything other than "GCM"). So, you'd potentially have something like ECDHE256-AES256-GCM DHE2048-AES256-GCM DHE1536-AES128-GCM etc. The signature algorithm (ECDSA, RSA, etc.) would be entirely separate. This isn't like the old days when the RSA key was used to exchange the keys: in the FS world, RSA is never used for key agreement, so RSA/ECDSA is used only to authenticate the server and is therefore orthogonal to the cipher suite negotiated above... and it's also implicit from the set of certificates the server has available. This unfortunately means we can't really tie the signature security margin to the cipher suite (going back to the RSA384 straw man), but since it's a pre-existing credential nothing can be done by the client other than to hang up if it's spooked by that. To fix this, we'd really need to go down the road of specifying the key size in the cipher suite, e.g. RSA2048 or ECDSA25519, which I'm not sure anyone wants. Does anyone want that? I ask because there are a ton of servers with 1024-bit RSA keys negotiating AES256-GCM, which tells an attacker exactly what to focus on. (In theory: a tire iron is still probably faster than factoring RSA1024.) The nice thing about the above approach is that IMO it actually makes things simpler for an implementer: the cipher suite list becomes a lot smaller but still covers most of the options, avoiding the complexity of full a la carte, while the signature algorithm is implicit for the server. So, we're not at libsodium level of simplicity, but closer. The one thing I'm having trouble pinning down is PSK. I fear it's not a separate dimension, because it replaces both signature and KEX. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492bis table 1
The current recommendations in NIST SP 800-57 Part 1, Table 2 suggest that 256-bit symmetric strength is matched by ECC strength of 512+ bits. All of the ECC sizes given in Table 2 are slightly different than given below, and most are given as ranges, not single values. http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_gener al.pdf (see page 64) -Peter On 7/22/15, 1:36 AM, "TLS on behalf of Martin Thomson" wrote: >Is table 1 correct? > > +---+-++ > | Symmetric | ECC | DH/DSA/RSA | > +---+-++ > | 80| 163 |1024| > |112| 233 |2048| > |128| 283 |3072| > |192| 409 |7680| > |256| 571 | 15360| > +---+-++ > >Aren't we dropping 571? Can we use values that match up. > >Or, drop the table. > >___ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
On 22 July 2015 at 01:50, Kyle Rose wrote: > I'd like to see the bits of the cipher suite associated entirely with > ephemeral data tied together roughly by security margin I've seen this argument several times, but there are reasons why you might want a non-homogenous strength profile. The argument for consistency is appealing, but given that the design of TLS is historically[1] vulnerable to the weakest *supported* algorithm as opposed to the weakest *used* algorithm, I am not concerned about ensuring consistency. [1] ... and likely in future, despite our best efforts > The one thing I'm having trouble pinning down is PSK. I fear it's not > a separate dimension, because it replaces both signature and KEX. Yes, this is a problem. I like to think of PSK as KEX with null auth. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On Jul 22, 2015, at 10:44 AM, Martin Thomson wrote: > I have never understood why 4492 doesn't claim forward secrecy for > ECDH_anon suites. Can someone explain why this doesn't have an 'E’? I wasn’t there for the original 4492, but I think it’s because the old anonymous ciphersuites were called DH_anon (no E). They both provide forward secrecy. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 02:20, Yoav Nir wrote: > They both provide forward secrecy. The draft specifically excludes ECDH_anon from the following statement, implying otherwise: The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. It might be a good idea to revise that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
PR at https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml ? > On Jul 22, 2015, at 11:23 AM, Martin Thomson wrote: > > On 22 July 2015 at 02:20, Yoav Nir wrote: >> They both provide forward secrecy. > > The draft specifically excludes ECDH_anon from the following > statement, implying otherwise: > > The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward > secrecy. > > It might be a good idea to revise that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
>> I have never understood why 4492 doesn't claim forward secrecy for >> ECDH_anon suites. Can someone explain why this doesn't have an 'E’? > > I wasn’t there for the original 4492, but I think it’s because the old > anonymous ciphersuites were called DH_anon (no E). > > They both provide forward secrecy. This is very confusing … ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote: > On 22 July 2015 at 01:50, Kyle Rose wrote: > > I'd like to see the bits of the cipher suite associated entirely with > > ephemeral data tied together roughly by security margin > > I've seen this argument several times, but there are reasons why you > might want a non-homogenous strength profile. > > The argument for consistency is appealing, but given that the design > of TLS is historically[1] vulnerable to the weakest *supported* > algorithm as opposed to the weakest *used* algorithm, I am not > concerned about ensuring consistency. Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems like comparing apples, orangles, pears and kumquants. Even if the nominal strengths are the same, the scaling of strengths is going to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs. symmetric). > > The one thing I'm having trouble pinning down is PSK. I fear it's not > > a separate dimension, because it replaces both signature and KEX. > > Yes, this is a problem. I like to think of PSK as KEX with null auth. I think TLS has currently four non-obsolete key exchanges: - GDHE_CERT - GDHE_PSK - GDHE_anon - PSK (I couple things here because I think that decoupling those would lead to unacceptable interop problems). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492bis table 1
> Is table 1 correct?
>
> +---+-++
> | Symmetric | ECC | DH/DSA/RSA |
> +---+-++
> | 80| 163 |1024|
> |112| 233 |2048|
> |128| 283 |3072|
> |192| 409 |7680|
> |256| 571 | 15360|
> +---+-++
>
> Aren't we dropping 571? Can we use values that match up.
>
> Or, drop the table.
>
>From all research I know the ECC numbers are larger than they should
be.
Breaking ECC (good curve etc.) with size ~2^n takes 2^{n/2} point
additions. Breaking a cipher with m bits takes about 2^m cipher
evaluations; usually some parts can be omitted. The difference for
cryptographic sizes between one EC operation and a symmetric operation
is somewhere around 2^3 to 2^5 depending on size.
When attacking multiple symmetric keys at once security reduces faster
than for ECC keys (k keys give factor k speedup for symmetric while
giving a factor sqrt(k) speedup for ECC).
In summary symmetric m corresponds to ECC with somewhat _less than_ 2m.
The numbers listed in that table match up with NIST's Koblitz
curves; the sizes were chosen because for those Koblitz curves of
nearly prime order exist -- this is a rare property for Koblitz
curves -- and not because that bit size is needed for other
reasons.
There are several proposals for matching key sizes, see
http://www.keylength.com/
for an overview.
I would go with
+---+---++
| Symmetric | ECC | DH/DSA/RSA |
+---+---++
| 80| >=158 |1024|
|112| >=221 |2048|
|128| >=252 |3072|
|192| >=379 |7680|
|256| >=506 | 15360|
+---+++
where the number in the ECC column refers to the bitlength of
the prime order of the subgroup. This does not take into
account that symmetric and DH are more weakened by multi-target
attacks.
I wouldn't haggle over a bit or two, but the previous table was
certainly not reflective of ECC strength given all we know.
All the best
Tanja
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
Ilari Liusvaara writes: >Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems >like comparing apples, orangles, pears and kumquants. > >Even if the nominal strengths are the same, the scaling of strengths is going >to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs. >symmetric). +1. It's just more numerology: (In case you're wondering why you shouldn't go straight to 2048 bits, this is another piece of cryptographic numerology that arises from the confusing idea of algorithm pairings, that every conventional encryption algorithm or key size has to be somehow matched up to a public-key algorithm key size. Since conventional encryption algorithms generally have the property that every single bit added to the key doubles the work factor needed to break it by brute force while public-key algorithms don't, this means that attempts to pair conventional-encryption with public-key sizes leads to insanely large public keys as the conventional-encryption key sizes get larger. Using any known technology it's unlikely that humans can ever get beyond about 2^^100 operations, which means that common key sizes of 112 bits (triple DES), 128 bits (AES), 192 bits (AES again), and 256 bits (yet more AES, because you can never have too many key sizes) are all equally unbreakable, and yet the desire for algorithm pairing means that we're supposed to go to public-key sizes of 2048, 3072, 7680, and 15,360 bits respectively for all of these equally-unbreakable conventional key sizes ["Recommendations for Key Management --- Part 1: General", Elaine Barker, William Barker, William Burr, William Polk and Miles Smid, NIST Special Publication 800-57, 9 July 2012]. This is a good example of the strange places that cryptographic numerology can lead you if you believe in it too fervently). So really the table of key sizes should be: ConventionalRSA/DH --- -- 100 bits1536 bits 112 (ie. > 100) 1536 bits 128 (ie. > 100) 1536 bits 192 (ie. > 100) 1536 bits 256 (ie. > 100) 1536 bits Anything > 100 1536 bits Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
>>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems >>like comparing apples, orangles, pears and kumquants. >> >>Even if the nominal strengths are the same, the scaling of strengths is going >>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs. >>symmetric). > > +1. It's just more numerology: In that case, we should dispense with any larger key sizes and recommend exactly one per algorithm, and vary only on algorithm. Adopting this would simplify things even further by reducing the cipher set list by an order of magnitude. Sadly, I'm guessing there are numerological requirements in various standards and regulations that make it necessary to keep both AES-128 and AES-256 around, for example. There are also a ton of existing 2048-bit RSA keys that aren't going anywhere for a while. I'm also skeptical of statements like "Using any known technology it's unlikely that humans can ever get beyond about 2^^100 operations", because that's true exactly up until it isn't. An open question is whether the innovation that undoes this will also subsume much larger keys. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 02:29, Yoav Nir wrote: > PR at > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml > ? https://github.com/tlswg/rfc4492bis/pull/6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-shore-tks-dnssec-chains-extension
I do like the dnssec-chain-extension. I think the server should stick to one chain, from the root to itself, so it does not have to deal with variable chain blobs per client. That will allow server code to stick to something like hourly regenerating the blob for use with all clients. I do strongly prefer the binary blob to be in raw dns format. That will make parsing easier with existing code, and over time we will not run into issues where dns libraries support newer algorithms but this specific dnssec parsing code isn't updated. The DNS answer packet format can contain many DNS records in the Additional Section, without requiring any new DNS data format (and note edns-query-chain also does not specify a new format). I would be fine with stating the order of the additional records should be top down, to make validation easier, although probably the TLSA record and RRSIG itself should appear in the DNS Answer Section. As for ekr's question on why not stuff this inside X.509, that would not be compatible with tls raw pulic keys that only contain a SBKI, and drag back into the protocol more ASN.1 parsing and containers. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Remove signature algorithm from the cipher suite
How about removing the RSA/ECDSA from the cipher suite, and making the SigAlgs extension mandatory for connections requiring authentication? That halves the number of cipher suites and eliminates an unnecessary redundancy, while keeping the rest of the cipher suite negotiation logic intact. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Meetecho recordings of TLS WG session
Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TLS WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS In case of problems with the playout, just drop an e-mail to ietf-supp...@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Meetecho recordings of TLS 2nd WG session
Dear all, the full recording (synchronized video, audio, slides and jabber room) of the TLS 2nd WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS_II In case of problems with the playout, just drop an e-mail to ietf-supp...@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Remove signature algorithm from the cipher suite
On Wednesday, July 22, 2015 10:30:24 am Kyle Rose wrote: > How about removing the RSA/ECDSA from the cipher suite, and making the > SigAlgs extension mandatory for connections requiring authentication? > That halves the number of cipher suites and eliminates an unnecessary > redundancy, while keeping the rest of the cipher suite negotiation > logic intact. This is already a part of the current a la carte proposal that's been under discussion. recent summary of changes: https://www.ietf.org/mail-archive/web/tls/current/msg17156.html 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 Both the supported groups and signature algorithms extensions are mandatory in this proposal, and they are the sole methods to select key exchange and certificates, with the ECDHE_ECDSA prefix being essentially frozen for certificate authenticated cipher suites. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On Wednesday, July 22, 2015 07:36:50 am Martin Thomson wrote: > On 22 July 2015 at 02:29, Yoav Nir wrote: > > PR at > > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml > > ? > > https://github.com/tlswg/rfc4492bis/pull/6 Could the cipher suite names be officially changed to add the 'E' to them? It'd make things simpler to be consistent. e.g. TLS_ECDH_anon_WITH_AES_128_CBC_SHA => TLS_ECDHE_anon_WITH_AES_128_CBC_SHA Anon is ephemeral by nature, but putting the 'E' in there matches existing notation better. TLS 1.3 will be deprecating all ECDH in favor of ECDHE, so it would be nice to not have to always stick in side notes that ECDH_anon==ECDHE_anon. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 19:07, Dave Garrett wrote: > Could the cipher suite names be officially changed to add the 'E' to them? > It'd make things simpler to be consistent. I'd be OK with that. I didn't do it in the PR, but would be happy to make a new one. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
I’d like to hear from the chairs if it’s OK to rename stuff in the IANA registry. That has some implications for implementations that use these names. Not to mention that the same issue applies to DH(E)_anon > On Jul 22, 2015, at 7:09 PM, Martin Thomson wrote: > > On 22 July 2015 at 19:07, Dave Garrett wrote: >> Could the cipher suite names be officially changed to add the 'E' to them? >> It'd make things simpler to be consistent. > > I'd be OK with that. I didn't do it in the PR, but would be happy to > make a new one. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote: > I think the server should stick to one chain, from the root to itself, > so it does not have to deal with variable chain blobs per client. > That will allow server code to stick to something like hourly > regenerating the blob for use with all clients. >From the root to its own TLSA RRset, however, this can be complicated in the presence of CNAMEs: www.example.com. IN CNAME cdn.example.net. cdn.example.net. IN A 192.0.2.1 _443._tcp.cdn.example.net. IN CNAME _dane.example.net. _dane.example.net. IN TLSA 2 0 1 In this example, three leaf RRsets need to be verified back to the root (with notable overlaps in the chains): www.example.com. IN CNAME _443._tcp.cdn.example.net. IN CNAME _dane.example.net. IN TLSA How should these be organized? It seems to me that the immediate answer that gets the client going in the right direction is the first CNAME, which enables to construct the TLSA base domain, and then to follow the second CNAME to the ultimate TLSA RRset. Should everything other than the first CNAME be in additional records? Should all the above (with their RRSIGs) be in the answer section, with the union of the supporting DNSKEY/RRSIG/DS records as additional? I tried to ask a related question during the meeting, but bandwidth to explain the context was limited: Should proofs of non-delegation be included, to keep gTLDs and ccTLDs honest for some future CT for DNS? Specifically, suppose you see: _443._tcp.www.example.com. IN TLSA with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 records that demonstrate that "example.com" (and www.example.com) are not delegated? (Such records might then be subject to "gossip" or related "transparency" counter-measures). > I do strongly prefer the binary blob to be in raw dns format. That > will make parsing easier with existing code, and over time we will > not run into issues where dns libraries support newer algorithms > but this specific dnssec parsing code isn't updated. I'm not sure what "algorithms" you have in mind? We should perhaps allow (even encourage) "compression" to reduce the payload size, this would require the client to "uncompress" (canonicalize) all the RRs before checking the RRsigs. Once canonicalized, DNSSEC signature checks don't care how the canonical forms of each RRset were constructed, and the wire form (which is not canonical) is not more compatible with new signature algorithms than any other representation. > As for ekr's question on why not stuff this inside X.509, that would not > be compatible with tls raw pulic keys that only contain a SBKI, and drag > back into the protocol more ASN.1 parsing and containers. This really can't go in the certificate, because then certificates would have to be updated as often as RRSIGS are regenerated. That seems exceedingly unlikely to be deployable. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On 22 July 2015 at 19:12, Yoav Nir wrote: > I’d like to hear from the chairs if it’s OK to rename stuff in the IANA > registry. > > That has some implications for implementations that use these names. > > Not to mention that the same issue applies to DH(E)_anon I believe that renaming entries in the IANA registry is possible. I don't think that it affects implementations, though it might cause some minor usability issues if people attempt to configure them using the IANA names. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On Wednesday, July 22, 2015 01:20:52 pm Martin Thomson wrote: > I believe that renaming entries in the IANA registry is possible. Negotiated FFDHE is renaming an extension identifier in the IANA registry, so this is not an entirely new issue. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
> I'd be OK with that. I didn't do it in the PR, but would be happy to make a > new one. Please do. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Relative vs absolute ServerConfiguration.expiration_date
One of the topics of discussion at the WG discussion was whether ServerConfiguration.expiration_date should be an absolute or relative value. Subodh (CC) dug into our production data and found that nearly half of the TLS errors we see in production (end user to edge/origin) are due to date mismatch. This often occurs when people intentionally reset the clock on their phone, or for other various reasons. Due to the high rate of date mismatch errors we see, my preference would be that ServerConfiguration.expiration_date be a relative value instead of an absolute one. This provides the client an opportunity to correctly use a monotonic (or other similar) clock to minimizing exposure, without losing the value of the ServerConfiguration. Using an absolute value means that ServerConfiguration, for clients with invalid clocks, would essentially never be cacheable. These clients wouldn’t benefit from ServerConfiguration. Thoughts or feedback? -Blake ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote: > One of the topics of discussion at the WG discussion was whether > ServerConfiguration.expiration_date should be an absolute or relative > value. Subodh (CC) dug into our production data and found that nearly half > of the TLS errors we see in production (end user to edge/origin) are due to > date mismatch. This often occurs when people intentionally reset the clock > on their phone, or for other various reasons. > > Due to the high rate of date mismatch errors we see, my preference would > be that ServerConfiguration.expiration_date be a relative value instead of > an absolute one. This provides the client an opportunity to correctly use a > monotonic (or other similar) clock to minimizing exposure, without losing > the value of the ServerConfiguration. Using an absolute value means that > ServerConfiguration, for clients with invalid clocks, would essentially > never be cacheable. These clients wouldn’t benefit from ServerConfiguration. > > Thoughts or feedback? Can you provide a sense of the range of clock skew you are seeing? I'm trying to figure out how many of these clients are going to start choking with OCSP must-staple, short-lived certs, etc. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] A la carte concerns from IETF 93
Consensus was my current WIP proposal is not viable, for some of the following main reasons: 1) cost/benefit analysis doesn't seem to be worth it 2) backwards compatibility handling 3) some argue harder to implement; others argue easier To start, I'll note that I have not submitted a PR yet. This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs were merged (namely the updated cipher suite section). I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these topics, so a better summary is needed. On to the concerns: 1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I perceive it, currently: benefit: + reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to offer some old) + single point of negotiation for (EC)DHE + single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a la carte) + deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop hazard due to Java being crap + ECC is always an option, regardless of suite offer/selection + FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment + missing combinations are no longer an interop failure cost: - change has risks of mistake at various points (implementation, deployment, admin, client config, etc.) - support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered - risk of confusion due to change in behavior (point #2 above) depends: +/- point #4, depending on implementation (the number of points in this list is not indicative of weight; the first cost could outweigh all benefits, depending on perspective) Additionally mentioned cost: - cannot specify exact combinations; some might not be desirable However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one. All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash. Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then this is a risk that comes up. The main difference in my calculus vs. others is that: a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas without this proposal we go ECC or bust (until something post-quantum is a viable option here). b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints actually offering suites that claim support, as it's just a given now. c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's currently possible to negotiate CBC because the GCM suites offered by the server are combinations not supported by the client, even though GCM is supported. (this does happen in the real world and is too often overlooked in this discussion) 2) Backwards compatibility is pretty straightforward. Here's what Firefox currently offers, minus RC4 & 3DES: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and the general consensus minimum would pick just the top one and pick certs based on the extension. Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility of FFDHE on new. If you want to keep around FFDHE without this proposal, you ne
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny mailto:bmath...@fb.com>> wrote: One of the topics of discussion at the WG discussion was whether ServerConfiguration.expiration_date should be an absolute or relative value. Subodh (CC) dug into our production data and found that nearly half of the TLS errors we see in production (end user to edge/origin) are due to date mismatch. This often occurs when people intentionally reset the clock on their phone, or for other various reasons. Due to the high rate of date mismatch errors we see, my preference would be that ServerConfiguration.expiration_date be a relative value instead of an absolute one. This provides the client an opportunity to correctly use a monotonic (or other similar) clock to minimizing exposure, without losing the value of the ServerConfiguration. Using an absolute value means that ServerConfiguration, for clients with invalid clocks, would essentially never be cacheable. These clients wouldn’t benefit from ServerConfiguration. Thoughts or feedback? Can you provide a sense of the range of clock skew you are seeing? I'm trying to figure out how many of these clients are going to start choking with OCSP must-staple, short-lived certs, etc. Well, our public cert is set to expire in ~1 year. The errors I’m seeing are “certificate has expired” and “certificate not yet valid”. I don’t have client timestamp vs server timestamp, but the clock in these cases is off by a year-ish? -Blake ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
I guess what I'm trying to get at is the following: Are there a lot of people whose clocks are accurate enough that they will be able to connect to the server and check the certificate/OCSP but not accurate enough to process ServerConfiguration if it is in absolute time. On Wed, Jul 22, 2015 at 10:54 PM, Blake Matheny wrote: >On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote: > >> One of the topics of discussion at the WG discussion was whether >> ServerConfiguration.expiration_date should be an absolute or relative >> value. Subodh (CC) dug into our production data and found that nearly half >> of the TLS errors we see in production (end user to edge/origin) are due to >> date mismatch. This often occurs when people intentionally reset the clock >> on their phone, or for other various reasons. >> >> Due to the high rate of date mismatch errors we see, my preference would >> be that ServerConfiguration.expiration_date be a relative value instead of >> an absolute one. This provides the client an opportunity to correctly use a >> monotonic (or other similar) clock to minimizing exposure, without losing >> the value of the ServerConfiguration. Using an absolute value means that >> ServerConfiguration, for clients with invalid clocks, would essentially >> never be cacheable. These clients wouldn’t benefit from ServerConfiguration. >> >> Thoughts or feedback? > > > Can you provide a sense of the range of clock skew you are seeing? I'm > trying to > figure out how many of these clients are going to start choking with OCSP > must-staple, short-lived certs, etc. > > > Well, our public cert is set to expire in ~1 year. The errors I’m seeing > are “certificate has expired” and “certificate not yet valid”. I don’t have > client timestamp vs server timestamp, but the clock in these cases is off > by a year-ish? > > -Blake > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
Ahh. I can't tell, the data I have is only clients with very very broken clocks who failed validation as a result. My assumption would be that there is a much larger number of clients that fit what you described (cert/OCSP check passes, but ServerConfiguration would not be). Since I don’t have the data, I can’t say that for sure, but anecdotal evidence would indicate that this is the case. -Blake On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: >I guess what I'm trying to get at is the following: >Are there a lot of people whose clocks are accurate enough that they will be >able to connect to the server and check the certificate/OCSP but not accurate >enough to process ServerConfiguration if it is in absolute time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Wed, 22 Jul 2015, Viktor Dukhovni wrote: I think the server should stick to one chain, from the root to itself, so it does not have to deal with variable chain blobs per client. That will allow server code to stick to something like hourly regenerating the blob for use with all clients. From the root to its own TLSA RRset, however, this can be complicated in the presence of CNAMEs: Should everything other than the first CNAME be in additional records? I think so. Should all the above (with their RRSIGs) be in the answer section, with the union of the supporting DNSKEY/RRSIG/DS records as additional? No, only the TLSA record and its RRSIG should be in there, so it is identical to a real DNS response packet. I tried to ask a related question during the meeting, but bandwidth to explain the context was limited: Should proofs of non-delegation be included, to keep gTLDs and ccTLDs honest for some future CT for DNS? Specifically, suppose you see: _443._tcp.www.example.com. IN TLSA with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 records that demonstrate that "example.com" (and www.example.com) are not delegated? (Such records might then be subject to "gossip" or related "transparency" counter-measures). That's an interesting question. I'd be tempted not to do this work in the TLS extension but keep that to a ct-dnssec document. I do strongly prefer the binary blob to be in raw dns format. That will make parsing easier with existing code, and over time we will not run into issues where dns libraries support newer algorithms but this specific dnssec parsing code isn't updated. I'm not sure what "algorithms" you have in mind? The successor to ECDSA or something like Curve*. I meant new DNSKEY algorithms used to generate RRSIG records. I would like to see DNS code maintained by DNS people used by browser people but I am young and naive. We should perhaps allow (even encourage) "compression" to reduce the payload size, Is that a problem in TLS? I thought the CA chains were already massively bigger? Or is this something specific to the client/server hello message? As for ekr's question on why not stuff this inside X.509, that would not be compatible with tls raw pulic keys that only contain a SBKI, and drag back into the protocol more ASN.1 parsing and containers. This really can't go in the certificate, because then certificates would have to be updated as often as RRSIGS are regenerated. That seems exceedingly unlikely to be deployable. I agree, but Adam Langley did make that work so perhaps we are wrong? Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Wed, Jul 22, 2015 at 05:23:39PM -0400, Paul Wouters wrote: > >Should everything other than the first CNAME be in additional > >records? > > I think so. > > > Should all the above (with their RRSIGs) be in the answer > >section, with the union of the supporting DNSKEY/RRSIG/DS records > >as additional? > > No, only the TLSA record and its RRSIG should be in there, so it is > identical to a real DNS response packet. But, the presence of a CNAME chain (either from host to TLSA base domain, or from TLSA base domain to ultimate TLSA RRset) the start of the chain is in the answer per your first comment? > >I tried to ask a related question during the meeting, but bandwidth > >to explain the context was limited: Should proofs of non-delegation > >be included, to keep gTLDs and ccTLDs honest for some future CT for > >DNS? Specifically, suppose you see: > > > > _443._tcp.www.example.com. IN TLSA > > > >with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3 > >records that demonstrate that "example.com" (and www.example.com) > >are not delegated? (Such records might then be subject to "gossip" > >or related "transparency" counter-measures). > > That's an interesting question. I'd be tempted not to do this work in > the TLS extension but keep that to a ct-dnssec document. But it would affect which RRsets servers should put in the extension. I guess the extension structure remains the same, so no need to pin this down yet? > >>I do strongly prefer the binary blob to be in raw dns format. That > >>will make parsing easier with existing code, and over time we will > >>not run into issues where dns libraries support newer algorithms > >>but this specific dnssec parsing code isn't updated. > > > >I'm not sure what "algorithms" you have in mind? > > The successor to ECDSA or something like Curve*. I meant new DNSKEY > algorithms used to generate RRSIG records. I would like to see DNS > code maintained by DNS people used by browser people but I am young and > naive. Oh, I see, indeed I DO NOT want to see applications shipping with their own rarely updated DNSSEC libraries. They should at least use an actively maintained library that is sepeparate from the application, and provides a "standard" API for doing the validation. Even better would be a new type of query to the local resolver that includes all the records as part of the query, and the local resolver validates the results (for clients that can reach a resolver on 127.0.0.1, but which in turn can't get DNSSEC data). (That is a protocol is even better than an API). > > We should perhaps > >allow (even encourage) "compression" to reduce the payload size, > > Is that a problem in TLS? I thought the CA chains were already massively > bigger? Or is this something specific to the client/server hello > message? Sure, CA chains are largish, but no reason to make DNS chains needlessly large, or for servers to perform uncompression just to forward DNS packets to clients. > >This really can't go in the certificate, because then certificates > >would have to be updated as often as RRSIGS are regenerated. That > >seems exceedingly unlikely to be deployable. > > I agree, but Adam Langley did make that work so perhaps we are wrong? Google might be more at liberty to mint certificates as they please and to coordinate this with any DNS RRSIG refreshes, I don't see the world at large being at liberty to do this. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
One place we may run into a lot of those clients are on machines like the Raspberry Pi and Beaglebone machines. These boards do not include clock chips, so the machines must get the current time via NTP every time they power on. If there is a problem with NTP, or if the shell script to set the clock is not run, then the date will probably be 20 or 30 years back in the last millenium. Cheers - Bill On 7/22/15 at 2:14 PM, bmath...@fb.com (Blake Matheny) wrote: Ahh. I can't tell, the data I have is only clients with very very broken clocks who failed validation as a result. My assumption would be that there is a much larger number of clients that fit what you described (cert/OCSP check passes, but ServerConfiguration would not be). Since I don’t have the data, I can’t say that for sure, but anecdotal evidence would indicate that this is the case. -Blake On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: I guess what I'm trying to get at is the following: Are there a lot of people whose clocks are accurate enough that they will be able to connect to the server and check the certificate/OCSP but not accurate enough to process ServerConfiguration if it is in absolute time. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --- Bill Frantz| Ham radio contesting is a| Periwinkle (408)356-8506 | contact sport. | 16345 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] new error alerts?
Hubert Kairo found quite a few more spots in need of explicit error
designations, which have been amended into PR #201.
https://github.com/tlswg/tls13-spec/pull/201
I just noticed one error in the current draft text that was wrong and added a
fix for that as well. The Server Hello section said that lack of acceptable
group would result in an "insufficient_security" error, which is incorrect.
That error is clearly defined to be for lack of acceptable cipher suite. The
Negotiated Groups section says lack of acceptable group is a
“handshake_failure” error. I changed the text to state the error for suites, as
the other is already noted elsewhere. (this change is now in PR #201) This
brings up a problem, however: there is no distinct error for lack of group
support. The “handshake_failure” is a bit of a catchall, so there's no way for
a client to really know what's wrong if this happens. This is also why I don't
want to change the definition of the "insufficient_security" error. Clients
rely on these being relatively precise in order to show error messages that are
hopefully meaningful enough to get them fixed. As such, I'd like to propose
adding a new error just for this and renaming the old one to focus precisely on
its long defined meaning. While we're at it, a failure of client authentication
doesn't have its own error alert code either.
enum {
handshake_failure(40),
unsupported_cipher_suites(71), /* formerly insufficient_security */
unsupported_dh_groups(72), /* new */
client_authentication_failure(73), /* new */
(255)
} AlertDescription;
Pretty straightforward. Are there any other errors that can't be clearly
identified by the returned code? Debugging shouldn't be guesswork. ;)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
Kyle Rose writes: >In that case, we should dispense with any larger key sizes and recommend >exactly one per algorithm, and vary only on algorithm. Adopting this would >simplify things even further by reducing the cipher set list by an order of >magnitude. Yup. >Sadly, I'm guessing there are numerological requirements in various standards >and regulations that make it necessary to keep both AES-128 and AES-256 >around, for example. There are also a ton of existing 2048-bit RSA keys that >aren't going anywhere for a while. You could just say "anything over 1536 bits, 1536 or 2048 recommended", which would deal with both. >I'm also skeptical of statements like "Using any known technology it's >unlikely that humans can ever get beyond about 2^^100 operations", because >that's true exactly up until it isn't. Right, but if you're going to use that argument then AES is breakable until it isn't, you can't find SHA-256 collisions until you can, quantum crypto can be broken by whoever you're afraid of, and so on. One thing we've become pretty good at doing is taking current progress on breaking crypto and mapping out what'll happen in the future, to the point where there have been zero sudden breaks of properly-designed algorithms (DES, AES, IDEA, SHA, RSA, DH, and so on), ever. In every case we've been able to see, from a long way off, what's in store. And to see what's in store for PKCs, you can't use the computers used by mathematicians/numerologists, which all have infinite amounts of zero-cycle-time memory, but the ones that actually exist in the real world. For a 1024-bit RSA key that's around 40 terabytes of memory for the final step, and a 1280-bit key would require roughly a petabyte of RAM, all in a single machine or a single-machine equivalent (a standard distributed cluster won't work because of interconnect latency problems). So you'd need to dedicate the entire Tianhe-2 to breaking a single 1280-bit key (I don't know how its memory architecture will affect performance, I just chose the world's most powerful supercomputer because that happens to be barely enough to attack a 1280-bit key, so I'm not sure how many years of time you'd need). Or you could just backdoor the server, which is what'll actually happen to anyone who wants to get in. Heck, just the interest on the power bill for the Tianhe-2 (if you assume the computer itself comes for free) would be enough to bribe most of the maintenance staff to plug in a trojan USB key for a minute or two while they're cleaning. And if you really are concerned about China secretly building a second Tianhe-2 and using it to attack your mail server, just change your key once a year and you're OK. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz wrote: > One place we may run into a lot of those clients are on machines like the > Raspberry Pi and Beaglebone machines. These boards do not include clock > chips, so the machines must get the current time via NTP every time they > power on. If there is a problem with NTP, or if the shell script to set the > clock is not run, then the date will probably be 20 or 30 years back in the > last millenium. > That's definitely a problem, but not a specific problem for ServerConfiguration since those implementations will also have problems with certificates (and ironically, will accept ServerConfiguration just fine) -Ekr Cheers - Bill > > On 7/22/15 at 2:14 PM, bmath...@fb.com (Blake Matheny) wrote: > > Ahh. I can't tell, the data I have is only clients with very very broken >> clocks who failed validation as a result. My assumption would be that there >> is a much larger number of clients that fit what you described (cert/OCSP >> check passes, but ServerConfiguration would not be). Since I don’t have the >> data, I can’t say that for sure, but anecdotal evidence would indicate that >> this is the case. >> >> -Blake >> >> >> >> >> On 7/22/15, 10:58 PM, "Eric Rescorla" wrote: >> >> I guess what I'm trying to get at is the following: >>> Are there a lot of people whose clocks are accurate enough that they >>> will be able to connect to the >>> >> server and check the certificate/OCSP but not accurate enough to process >> ServerConfiguration if it is in absolute time. >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> --- > Bill Frantz| Ham radio contesting is a| Periwinkle > (408)356-8506 | contact sport. | 16345 Englewood Ave > www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
