[TLS] Enforcing Protocol Invariants
On Thursday, November 8, 2018, Eric Rescorla wrote: > It's also worth noting that in practice, many sites are served on > multiple CDNs which do not share keying material. > > Encrypting common knowledge is cargo cult fetishism for cryptography. The files could be sent unencrypted, and protected using subresource integrity. If you are sharing the same data to multiple second parties to serve to a single third party, the value of encryption is less than zero. This could create a long drawn out argument which may prove that it is impossible to change anything about TLS as it has reached a point where too many people are doing too many things to it, that is outside any original or rational design. In any case, Eric, you inadvertently contradict yourself. The whole point of WebPKI is to certify trust, and has been an issue over the years. But CDNs act as a intermediary between the creator of the content and the end user. CDNs do not have as strict requirements as do CAs in terms of auditing, and have their own issues outside the scope of this conversation. Like I said, this could go on forever, I’m just making one point, you people have made a protocol does very little of what one should expect it should do, and the internet has evolved to be some sort of non functioning system, the best example of which would be that everyone has forgotten what URI standards are supposed to be about. In any case, TLS 1.3 won’t reach widespread adoption for another few years, and any subsequent protocol (independent of Google’s worldwide lab experiment) won’t be finalized for five years, and depending on how radical it is, won’t achieve mass adoption for four to fifteen years. By which point layer 2 protocols might allow for IPv6 jumbo packets to be used. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
I think I have implied that ClientHello is unneccesary to an extent, it can be replaced by a DNS TXT record. I think I implied that self-signed certificates are acceptable given the precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence of DNS spoofing attacks against a CA?). I think my suggestion has the implication that protocol negotiation is unnecessary, although it can be kept. I think my suggestion would have automatic backwards compatibility. A TLS 1.2-only client (likely to be found in regulated sectors that requires middlebox inspection and decryption) would attempt to connect using port 443, while my proposed protocol would attempt to look up using DNS first to obtain DNS records relevant. By using separate ports for each new protocol, it maintains a greater level of cross-compatibility and allows for future development. These compounded extensions make the protocol less secure by making it harder to implement, particularly given the recent spate of attacks against unintuitively implemented state machines for key negotiation. The entire protocol should be removed and replaced by something far simpler.. Is this sufficiently specific? I hope in the future, the IETF TLS working group will reach out to middlebox designers to understand what they are exactly doing to TLS so that these things won’t be unexpected. I must also say that CBC isn’t bad, as long as the padding is considered to be part of the message to be authenticated. On Thursday, November 8, 2018, Salz, Rich wrote: > *>*Hmm. TLS has gotten too complex. > > > > What makes you say that? Please be specific about what you think should > be taken out. > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] How should inability to access key revocation lists impact the TLS handshake?
How should inability to access key revocation lists impact the TLS handshake, if previous public keys and/or certificate hashes are not cached? I cannot see this in the standard. Considering that all one has to do is DDOS a certificate authority nowadays... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Ryan Carboni <rya...@gmail.com> writes: > > >I've never quite understood what TLS was supposed to be protecting > against, > >and whether or not it has done so successfully, or has the potential to > do so > >successfully. > > It's the Inside-Out Thread Model (also shared by a number of other security > protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/… and our > threat model is whatever that happens to defend against". DNSSEC is a > classic > example of this, the DNSSEC requirements doc was published *a decade* after > DNSSEC itself. Mind you, other protocols are still waiting for their > requirements doc to be published. PKIX specifically actively declined to > consider use cases because heck, this is a standards committee dammit, we > can't be expected to take into account what people want to do with it. > > Mind you, in the absence of any success criteria, no-one can say you've > failed... > > Peter. It is worth reading this paper apparently from 2010 on reusing ephemeral keys: https://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf Regardless, I can hope the Snowden disclosures will force people into action. But please. Continue to make the internet secure. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
I've never quite understood what TLS was supposed to be protecting against, and whether or not it has done so successfully, or has the potential to do so successfully. Well, I don't think anyone here even knows how to protect a mailing list from multi-billion dollar threat actors so...??? Let me quote RFC 3526: "The strengths of the groups defined here are always estimates and there are as many methods to estimate them as there are cryptographers." But whatever. You people aren't even willing to do what the Germans did... twice. Personally I think TLS should be scrapped, replaced with a protocol without negotiation, replace PKI with trusted notaries ( https://en.wikipedia.org/wiki/Convergence_(SSL) ), etc. But, no one has been able to program anything correctly, not even certificate authorities: https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com I'm not paying you people anyway. At least the protocol is theoretically secure. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
