Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/15 22:17, Aaron Zauner wrote: > I'd be happy to receive feedback on the document and am looking > forward for people to try out AES-OCB in TLS (an upcoming OpenSSL > version will ship with default-support I am told). We already have AES-OCB in libcrypto in OpenSSL master (forthcoming version 1.1.0). However we don't yet have any OCB TLS ciphersuite support and I'm not aware of anyone currently working on it. That's not to say it couldn't be included if someone were to provide a patch. Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVw0gQAAoJENnE0m0OYESRDjIH/1BrzOANeT6lTC+rklcY4UFN 2DOeohxojCeYkB7e9XzvnFUqbpVrd8O+5SLMaCHzAz5510XdbunTegjjb5DZNkkL BI52Y3edP0ftTEa2o9tKBJ7ngkg+3cizGR8iVh3+m5Px6chluase8e8Zp6g9Agys nNvhRxAaycyPXA7z3GrzHzUSSNvA2v2Y9vN69qt+NUyicBxnMYZ7bztW3GEvA+l+ do/Oy0Uv0f3SLxierbnZ18QUaCr4+feWdeq7/B0TvXg5B7QV1Z0XPbVEPGSEv//K NnJrputtgGB2jfBzM75zI/z6AElyjM4nV1RWTx01qMfUh45xXX9mqrTRld044tk= =1V// -END PGP SIGNATURE- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
I looks like we’ve come to WG consensus that the sect571r1 curve should be removed from the TLS 1.3 & 4492bis drafts. spt On Jul 20, 2015, at 09:08, Hubert Kario wrote: > On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote: >> On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: >>> What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way >>> it has no unexplained constants...). Has it been removed already, or does >>> the question also refer K-571 too? >> Already dropped. That's obviously not irreversible, but it's unambiguously >> in the virtually unused camp. The initial goal was to drop all largely >> unused curves. >> >> This question is just about sect571r1, which is far closer to secp384r1 & >> secp521r1 in terms of usage, though still notably less. If you want to >> argue for going with sect571k1 and not sect571r1, I don't think the WG is >> on-board with that. Even if we continued to allow it, I doubt much would >> add support for it to be worthwhile. > > This is likely just an artefact of use of OpenSSL curve order, if K-571 was > first, the servers would likely select it over B-571 more often > >> The scan I linked to found one; literally a single server on the entire >> Internet, > > _not_ a single server in the Internet, a single server among Alexa top 1 > million websites - the scan is checking only a set of popular _websites_, not > even all popular services that use TLS, let alone the whole Internet > >> that actually supports sect571k1 for ECDHE. The stats also show >> 1575 "support" it, so I'm not sure what's going on there specifically. (if >> someone can explain this bit of those stats, please do) > > The "Supported PFS" section describes what the server selects if the client > advertises default OpenSSL order of all defined curves. The "Prefer" lines, > means that the ciphersuite selected by server by default uses this key > exchange. > > IOW, if server supports FFDHE 2048 and ECDHE P-256 and prefers ECDHE, then > the > server will be counted in three lines: > DH,2048bits > ECDH,P-256,256bits > Prefer ECDH,P-256,256bits > > The "Supported ECC curves" section describes what curves the server will use > for ECDHE key exchange if its preferred one is not advertised by client (in > most cases that means what happens if the client doesn't advertise P-256 > curve). Then that curve is removed and the process repeated until the server > picks a ciphersuite that doesn't use ECDHE or aborts connection. > > feel free to ask more questions about the scans if something is still unclear > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech > Republic___ > 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
[TLS] WGLC for draft-ietf-tls-cached-info-19
Hi Folks, This is the Working Group last call for draft-ietf-tls-cached-info-19. This document has undergone modification since last WGLC so another WGLC is appropriate. This document is a dependency for the DICE working group TLS/DTLS profile. Please send your comments to the TLS list by September 2, 2015. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00
On 5 August 2015 at 11:13, Wan-Teh Chang wrote:
> Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.
>
>struct {
>opaque nonce[12];
>} ChaChaNonce;
>
> 1. The 64-bit record sequence number is padded to the left with
> zeroes to 96 bits (12 octets).
> 2. The padded sequence number is XORed with either the
> client_write_IV (when the client is sending) or the
> server_write_IV (when the server is sending)
> 3. Store the XOR result in ChaChaNonce.nonce.
This looks fine. Note that the general construction in TLS 1.3 should
be, more formally:
assert(N_MAX > 64bits)
nonce = {client|server|_{read|write}_IV[0..N_MAX] XOR lpad0(seq_num)
Of course, ChaChaX sets N_MAX to 96 bits, so what you described was correct.
--Martin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
I've read this draft before, but this is considerably different to what I read, and I haven't been following the discussion, so consider this as a review with fresh eyes. First the high points. I think that this is useful, the right scope, and reasonably well formulated. I have a couple of minor points Figure 2 is in error: it shows CertificateRequest instead of Certificate. I'd like to see the document explicitly note that msg_type and length from the handshake message are not covered by the hash. The description of what is covered is a little too terse (and badly formatted). I'm not sure that I like the lack of both negotiation and signaling for the hashes that are used here. Though I think the chances of a collision being found, or that a collision would lead to an attack, are slim, I would rather see this use the PRF hash so we have at least that much flexibility. If the current design is retained, I would like to see a little discussion of this in the document. A little analysis of the properties we expect the hash to provide would also be good. I think that truncated hashes might be advantageous from the server side. Given that the server only uses hashes to identify which of the offered (available, known?) cached information is in use, is there any reason you can't save additional space by arbitrarily truncating the hash? In many cases I would imagine that the client would be offering only one option and even if there were a small number of options presented, a single byte would suffice to disambiguate. I'm trying to think why you might want the full-length hash on the client side, but I believe that the only problem there is that there might be a collision between the certificates that a server might offer if you truncate too aggressively. The connection still relies on the server presenting proof of knowledge of a key that the client extracts from a certificate bound to the server identity, so I believe that it would be equally secure if you removed all mention of certificates from the protocol. And that makes me nervous, because I'm fairly sure that Karthik will tell me that I'm wrong very shortly; since we've put in a lot of work to cover key fields in the handshake hash, and I'm concerned that this could be exploited somehow. The more I think about this, the more I think that we need a little more analysis on this point (i.e., what properties the hash function needs to provide and why). If it has already happened, mention of that in the security considerations is needed. (I think that truncation on the server side is safe if the client uses a strong hash function to identify the certificate, but I'm frequently wrong about these things.) On 6 August 2015 at 10:24, Joseph Salowey wrote: > Hi Folks, > > This is the Working Group last call for draft-ietf-tls-cached-info-19. This > document has undergone modification since last WGLC so another WGLC is > appropriate. This document is a dependency for the DICE working group > TLS/DTLS profile. Please send your comments to the TLS list by September 2, > 2015. > > Thanks, > > J&S > > ___ > 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
[TLS] Comments on the TLS 1.3 draft
I recently reviewed the most recent TLS 1.3 draft, and I must say that I am impressed; the protocol appears to be a significant improvement. In particular, you simplify the protocol significantly, and as we all know, complexity is the enemy of security. You also drop many of the weak options, such as RC4 and the export ciphers; that sounds like an excellent idea. That said, I do see a few things that puzzle me: - When dealing with ECDSA signatures, the default hash algorithm is SHA1, and any other hash function needs to be specified explicitly. Might I ask why that is? No one has demonstrated a SHA1 collision yet; however people are creeping closer. If you ask me (which you didn't, but I'll give my opinion anyways), the default should be (at least) SHA-256; you should allow SHA-1 as a downgrade option only if someone makes a strong case that they can implement ECDSA and the rest of TLS 1.3, but implementing SHA-256 is just too hard. Otherwise, it should be discarded just like the other known weak cryptographical primitives (such as RC4). - You also allow the provision of someone using MD5 as the hash algorithm. Take the above comments about how SHA-1 is not a good idea, and multiply it by a factor of about 10. I see no justification for allowing someone to use a known broken hash algorithm. - Given the general theme of simplification, I was a bit puzzled by something; you appear to provide two different solutions to "how do I quickly reestablish a TLS tunnel"; you have both 0-RTT and session resumption. While both appear to have minor advantages over the other, I don't immediately see any real justification for including the complexity of both. Now, it might be that I'm catching a draft in the middle, and that you fully intend to combine them. Alternatively, there might be strong reasons to have both (and it just doesn't occur to me). In either of those two cases, "never mind" However, despite these minor nits, I would end with saying that the working group has done good work on this draft; I look forward to the end product. Thanks! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comments on the TLS 1.3 draft
On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) wrote: > I recently reviewed the most recent TLS 1.3 draft, and I must say that I > am impressed; the protocol appears to be a significant improvement. In > particular, you simplify the protocol significantly, and as we all know, > complexity is the enemy of security. You also drop many of the weak > options, such as RC4 and the export ciphers; that sounds like an excellent > idea. > > > > That said, I do see a few things that puzzle me: > > > > - When dealing with ECDSA signatures, the default hash algorithm > is SHA1, and any other hash function needs to be specified explicitly. > Might I ask why that is? No one has demonstrated a SHA1 collision yet; > however people are creeping closer. If you ask me (which you didn’t, but > I’ll give my opinion anyways), the default should be (at least) SHA-256; > you should allow SHA-1 as a downgrade option only if someone makes a strong > case that they can implement ECDSA and the rest of TLS 1.3, but > implementing SHA-256 is just too hard. Otherwise, it should be discarded > just like the other known weak cryptographical primitives (such as RC4). > > - You also allow the provision of someone using MD5 as the hash > algorithm. Take the above comments about how SHA-1 is not a good idea, and > multiply it by a factor of about 10. I see no justification for allowing > someone to use a known broken hash algorithm. > This is just a transient state. We have patches in progress to remove both of these. - Given the general theme of simplification, I was a bit puzzled > by something; you appear to provide two different solutions to “how do I > quickly reestablish a TLS tunnel”; you have both 0-RTT and session > resumption. While both appear to have minor advantages over the other, I > don’t immediately see any real justification for including the complexity > of both. Now, it might be that I’m catching a draft in the middle, and > that you fully intend to combine them. Alternatively, there might be > strong reasons to have both (and it just doesn’t occur to me). In either of > those two cases, “never mind” > Each of these has some benefit, though I agree that it would be nice to combine them. The big issue is: - For security reasons it's much easier to work with 0-RTT DH exchanges. - For performance reasons it's nice to have resumption. -Ekr > > > However, despite these minor nits, I would end with saying that the > working group has done good work on this draft; I look forward to the end > product. > > > > Thanks! > > ___ > 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
[TLS] Adding a new signature scheme
This is about adding a new signature primitive (such as the (eventual) CFRG scheme). There are basically two issues: 1) Do we allocate new ciphersuite codepoints or not? So far each certificate algorithm in ciphersuite has corresponded to only one signature algorithm. Implications of new codepoints: - More ciphersuites (about 11). - Needs TLS 1.2+ anyway, because the ciphers are presumably AEAD mode and those need TLS 1.2+. - Keep existing semantics. Implication of reusing ECDSA codepoints. - No new ciphersuites - Needs TLS 1.2+ - Redefines existing semantics a bit. 2) What does the SignatureAndHashAlgorithm.hash mean exactly? The TLS 1.2 RFC isn't specific enough. I see two choices: a) The field sets hash (prehash) to perform before passing the hash to be signed (the description of "none" and description of Certificate Verify message hints at this interpretation). b) The field parameterizes the signature scheme in some scheme- specific way (but what would "none" mean in context of this, the scheme having no hash parameters?). All the existing schemes are compatible with interpratation a). But for proposals for CFRG scheme: All proposed schemes have a hash parameter (the only one or one of two) that is incompatible with interpretation a): 1) Only one hash that does not prehash the message. 2) Two hash functions, one prehash (can be identity) and one internal hash. Prehash can be chosen per-signature. 3) Two hash functions, one prehash (can be identity) and one internal hash. Prehash is not indicated, so one has to be careful changing it. So if interpretation a) is the correct one, one presumably has to fix the internal hash in signature scheme codepoint (E.g. to SHA-512 for signature scheme #4). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
