Re: [Cryptography] TLS2
On 2/10/13 00:43 AM, James A. Donald wrote: On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. This is an inherent problem, not with ASN.1, but with any data representation that can represent arbitrary data. Right. I see the encoding choice as both integral to any proposal, and a very strong design decision. I would fail any proposal that used some form of external library like ASN.1, XML, JSON, YAML, pb, Thrift, etc, that was clearly not suited for purpose of security. I would give a thumbs-up to any proposal that created its own tight custom definition. The decoder should only be able to decode the data structure it expects, that its caller knows how to interpret, and intends to interpret. Anything else should fail immediately. Thus our decoder should have been compiled from, a data description, rather than being a general purpose decoder. This is why I like not using a decoder. My requirement is that I read exactly what I expect, check it for both syntax semantics, and move on. There should be no intervening lazy compilation steps to stop the coder seeing the entire picture. Another problem with decoders is that you need a language. So that makes two languages - the primary one and the layout. Oops. Have you noticed how these languages start off simple and get more and more complicated, as they try and do what the primary could already do? The end result is no savings in coding, split sanity semantics checking, added complexity and less security. For every element you need to read, you need a line of code either way you do it, so it may as well be in the primary language, and then you get the security and the full checking capability, for free. Thus sender and receiver should have to agree on the data structure for any communication to take place, which almost automatically gives us a highly compressed format. Conversely, any highly compressed format will tend to require and assume a known data structure. The problem is that we do not want, and should not have, the capacity to send a program an arbitrary data structure, for no one can write a program that can respond appropriately to an arbitrary data structure. Right. To solve this, we would generally know what is to come, and we would signal that the exact expected thing is coming. Following-data-identification is the one problem I've not seen an elegant solution to. Tagging is something that lends itself to some form of hierarchical or centralised solution. I use a centralised file with numbers and classes, but there are many possibilities. If I was to do it, for TLS2, I'd have a single table containing the mapping of all things. It would be like (off the top of my head): 1 compactInt 2 byteArray 3 bigInt 4 booleans 20 secret key packet 21 hash 22 private key packet 23 public key packet 24 hmac 40 Hello 41 Hiya 42 Go4It 43 DataPacket 44 Teardown I don't like it, but I've never come across a better solution. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-10-02 13:18, Tony Arcieri wrote: LANGSEC calls this: full recognition before processing http://www.cs.dartmouth.edu/~sergey/langsec/occupy/ http://www.cs.dartmouth.edu/%7Esergey/langsec/occupy/ I disagree slightly with langsec. At compile time you want an extremely powerful language for describing data, that can describe any possible data structure. At run time, you want the least possible power, such that your recognizer can only recognize the specified and expected data structure. Thus BER and DER are bad for the reasons given by Langsec, indeed they illustrate the evils that langsec condemns, but these criticisms do not normally apply to PER, since for PER, the dangerously great power exists only at compile time, and you would have to work pretty hard to retain any substantial part of that dangerously great power at run time. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 1/10/13 23:13 PM, Peter Fairbrother wrote: ... Sounds like you want CurveCP? http://curvecp.org/ Yes, EXACTLY that. Proposals like CurveCP. I have said this first part before: Dan Boneh was talking at this years RSA cryptographers track about putting some sort of quantum-computer-resistant PK into browsers - maybe something like that should go into TLS2 as well? I would see that as optional. If a designer thinks it can be done, go for it. Let's see what the marketplace We need to get the browser makers - Apple, Google, Microsoft, Mozilla - and the webservers - Apache, Microsoft, nginx - together and get them to agree we must all implement this before writing the RFC. Believe me, that way is a disaster. The first thing that happens is someone says, let's get together and we'll fix this. Guys, we can do this! The second thing that happens is they form a committee. Then the companies insist that only their agenda be respected. End of (good) story, start of rort. Also, the banks and the CA's should have an input. But not a say. I'm sorry, this is totally embarrased by history. The CAs have *all* the say, the vendors are told what to say by the CAs. The banks have *none* of the say. We can see this from the history of CABForum, which started out as I suggested above. (The users were totally excluded from CABForum. Then about 2 years back, after they had laid out the foundation and screwed the users totally, they invented some sort of faux figurehead user representation. I never followed it after they announced their intent to do a facade.) More rules: IP-free, open source code, Patent free or free licences provided, yes. no libraries (*all* functions internal to each suite) Fewest dependencies. a compiler which gives repeatable binary hashes so you can verify binary against source. Note to Microsoft - open source does not always mean free. But in this case it must be free. Maximum of four crypto suites. 3 too many! Each suite has fixed algorithms, protocols, key and group sizes etc. I agree with that. You'll find a lot of people don't agree with the key size being fixed, and people like NIST love yanking the chain by insisting on upping the numbers to some schedule. But that resistance is somewhat of an RSA hangover; if the one cryptosuite is based on EC then there is more chance of it being fixed to one size. Give them girls' names, not silly and incomplete crypto names - This connection is protected by Alice. :) Ability to add new suites as secure browser upgrade from browser supplier. ?New suites must be signed by working group?. Signed new suites must then be available immediately on all platforms, both browser and webserver. And that opens pandora's box. It requires a WG. I have a vanity need. Trouble begins... Separate authentication and sessionkeysetup keys mandatory. I like it, but DJB raises a good point: if EC is fast enough, there may be scope to eliminate some of the phases. Maybe use existing X.509? but always for authentication only, never sessionkeysetup. I see this as difficult. A lot of the problems in the last lot happened because the institutions imposed x.509 over everything. I see the same problem with the anti-solution which is passwords. How the past is rectified and future auth needs are handled will be part of what makes a winning solution the winner. No client authentication. None. Zero. That won't get very far. We need client auth for just about everything. The business about privacy is totally dead; sophisticated websites are slopping up the id info regardless of the auth. Privacy isn't a good reason to drop client-side auth. (Which isn't to say privacy isn't a requirement.) That's too hard for an individual to manage - remembering passwords or whatever, yes, global authentication, no. That does not belong in TLS. I specifically include this because the banks want it, now, in order to shift liability to their customers. Well, they want a complete solution. Not the crapola they have to deal with now, where they have to figure out where CIA stops and where their problems start. And as to passwords being near end-of-life? Rubbish. Keep the password database secure, give the user a username and only three password attempts, and all your GPUs and ASIC farms are worth nothing. So, it seems that there is no consensus on the nature of client auth. Therefore I'd suggest we throw the whole question open: How much auth and which auth will be a key telling point. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 1/10/13 02:01 AM, Tony Arcieri wrote: On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. Sounds like you want CurveCP? http://curvecp.org/ Yes, EXACTLY that. Proposals like CurveCP. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 01/10/13 08:54, ianG wrote: On 1/10/13 02:01 AM, Tony Arcieri wrote: On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. Sounds like you want CurveCP? http://curvecp.org/ Yes, EXACTLY that. Proposals like CurveCP. I have said this first part before: Dan Boneh was talking at this years RSA cryptographers track about putting some sort of quantum-computer-resistant PK into browsers - maybe something like that should go into TLS2 as well? We need to get the browser makers - Apple, Google, Microsoft, Mozilla - and the webservers - Apache, Microsoft, nginx - together and get them to agree we must all implement this before writing the RFC. Also, the banks and the CA's should have an input. But not a say. More rules: IP-free, open source code, no libraries (*all* functions internal to each suite) a compiler which gives repeatable binary hashes so you can verify binary against source. Note to Microsoft - open source does not always mean free. But in this case it must be free. Maximum of four crypto suites. Each suite has fixed algorithms, protocols, key and group sizes etc. Give them girls' names, not silly and incomplete crypto names - This connection is protected by Alice. Ability to add new suites as secure browser upgrade from browser supplier. ?New suites must be signed by working group?. Signed new suites must then be available immediately on all platforms, both browser and webserver. Separate authentication and sessionkeysetup keys mandatory. Maybe use existing X.509? but always for authentication only, never sessionkeysetup. No client authentication. None. Zero. That's too hard for an individual to manage - remembering passwords or whatever, yes, global authentication, no. That does not belong in TLS. I specifically include this because the banks want it, now, in order to shift liability to their customers. And as to passwords being near end-of-life? Rubbish. Keep the password database secure, give the user a username and only three password attempts, and all your GPUs and ASIC farms are worth nothing. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
At 02:27 PM 9/30/2013, James A. Donald wrote: On 2013-09-30 18:02, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it. Unfortunately, you have to be able to comprehend all of the failure modes and attacks on ASN.1. The object descriptions themselves are a bit bloaty, with their main weakness being that either you have to get permission to attach your data into the official tree, or else do a vendor-specific branch, but they're not all that broken. It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. This is an inherent problem, not with ASN.1, but with any data representation that can represent arbitrary data. The decoder should only be able to decode the data structure it expects, that its caller knows how to interpret, and intends to interpret. Anything else should fail immediately. Thus our decoder should have been compiled from, a data description, rather than being a general purpose decoder. Thus sender and receiver should have to agree on the data structure for any communication to take place, which almost automatically gives us a highly compressed format. Conversely, any highly compressed format will tend to require and assume a known data structure. The problem is that we do not want, and should not have, the capacity to send a program an arbitrary data structure, for no one can write a program that can respond appropriately to an arbitrary data structure. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. BER and DER can express an arbitrary data structure - and thus can crash the program receiving the data, probably causing it to execute transmitted data as code. The same, however, is true of every overly general line format. Incoming data should be parsed as the expected and bounded size data structure, thus we need something that can generate parsing code from a description of the data at compile time. We need compile time descriptions of the data, not run time descriptions, because the program that uses the incoming data will unavoidably rely on compile time description of the data. PER, however cannot receive unexpected data structures. Thus all data should be transmitted as PER, or by a format with the properties of PER. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote: On 30/09/13 11:02 AM, Adam Back wrote: no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits [...] support soft-hosting [...] Add TOFO for self-signed keys. Personally, I'd do it over UDP (and swing for an IP allocation). I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. The other approach is to bump up security - ie start with HTTP, then switch to TLS, however that is generally a bad direction as it invites attacks on the unauthenticated destination redirected to. I know there is also another direction to indicate via certification that a domain should be TLS only, but as a friend of mine was saying 10 years ago, its past time to deprecate HTTP in favor of TLS. Both client and server must have a PP key pair. Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. However whether its password based or challenge response based, I think we ought to address the phish problem for which actually EKE was after all designed for (in 1992 (EKE) and 1993 (password augmented EKE)). Maybe as its been 20 years we might actually do it. (Seems to be the general rule of thumb for must-use crypto inventions that it takes 20 years until the security software industry even tries). Of course patents ony slow it down. And coincidentally the original AKE patent expired last month. (And I somehow doubt Lucent, the holder, got any licensing revenue worth speaking about between 1993 and now). By pinning the EKE or AKE to the domain, I mean that there should be no MITM that can repurpose a challenge based on phish at telecon.com to telecom.com, because the browser enforces that EKE/AKE challenge reponse includes the domain connected to is combined in a non-malleable way into the response. (EKE/AKE are anyway immune to offline grinding of the exchanged messags.) Clearly you want to tie that also back to the domains TLS auth key, otherwise you just invite DNS exploits which are trivial across ARP poisoning, DNS cache-poisoning, TCP/UDP session hijack etc depending on the network scenario. And the browser vendors need in the case of passwords/AKE to include a secure UI that can not be indistinguishably pasted over by carefully aligned javascript popups. (The other defense with securid and their clones can help prop up AKE/passwords.) Both, used every time to start the session, both sides authenticating each other at the key level. Any question of certificates is kicked out to a higher application layer with key-based identities established. While certs are a complexity it would be nice to avoid, I think that reference to something external and bloated can be a problem, as then like now you pollute an otherwise clean standard (nice simple BNF definition) with something monstrous like ASN.1 and X.500 naming via X.509. Maybe you could profile something like openPGP though (it has its own crappy legacy they're onto v5 key formats by now, and some of the earlier vs have their own problems, eg fingerprint ambiguity arising from ambiguous encoding and other issues, including too many variants, extra mandatory/optional extensions.) Of course the issue with rejecting formats below a certain level is the WoT is shrunk, and anyway the WoT is also not that widely used outside of operational security/crypto industry circes. That second argument may push more towards SSH format keys which are by comparison extremely simple, and are recently talking about introducing simple certification as I recall. Adam ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. And support soft-hosting by sending the server domain in the client-hello. Add TOFO for self-signed keys. Maybe base on PGP so you get web of trust, thogh it started to get moderately complicated to even handle PGP certificates. Adam On Sun, Sep 29, 2013 at 10:51:26AM +0300, ianG wrote: On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical set of requirements. Then make it so. There are a dozen people here who could do it. Why not do the requirements, then ask for competing proposals? Choose 1. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 29 Sep 2013, at 08:51, ianG i...@iang.org wrote: On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical set of requirements. Then make it so. There are a dozen people here who could do it. Why not do the requirements, then ask for competing proposals? Choose 1. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. Sounds like a suggestion to make on the tls wg list. It might get some support, though I'd guess not everyone would want to do that S S iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 30/09/13 11:02 AM, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. And support soft-hosting by sending the server domain in the client-hello. Add TOFO for self-signed keys. Maybe base on PGP so you get web of trust, thogh it started to get moderately complicated to even handle PGP certificates. Exactly. By setting the *high-level* requirements, we can show how real software engineering is done. In small teams. Personally, I'd do it over UDP (and swing for an IP allocation). So it incorporates the modes of TLS and UDP, both. Network packets orderable but not ordered, responses have to identify their requests. One cipher/mode == one AE. One curve, if the users are polite they might get another in v2.1. Both client and server must have a PP key pair. Both, used every time to start the session, both sides authenticating each other at the key level. Any question of certificates is kicked out to a higher application layer with key-based identities established. Adam On Sun, Sep 29, 2013 at 10:51:26AM +0300, ianG wrote: On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical set of requirements. Then make it so. There are a dozen people here who could do it. Why not do the requirements, then ask for competing proposals? Choose 1. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] TLS2
On 30 September 2013 10:47, Adam Back a...@cypherspace.org wrote: I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On Mon, 30 Sep 2013 11:47:37 +0200 Adam Back a...@cypherspace.org wrote: I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. It's called SNI and it is widely deployed. All browsers and all relevant web servers support it. However, it has one drawback: It doesn't work with SSLv3, which means it breaks every time browsers do a fallback on SSLv3. And they do quite often, because they retry SSLv3 connects if TLS connections fail. Which is also a security problem and allows downgrade attacks, but mainly it means with weak internet connections you often get downgraded connections. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-09-30 18:02, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it. base on PGP so you get web of trust, PGP web of trust does not scale. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
Hi, What I personally think would be necessary for TLS2: * At least one quantum-computing resistant algorithm which must be useable either as replacement for DH+RSA+EC, or preferrably as additional strength(double encryption) for the transition period. * Zero-Knowledge password authentication (something like TLS-SRP), but automatically re-encrypted in a normal server-authenticated TLS session (so that it's still encrypted with the server if you used a weak password). * Having client certificates be transmitted in the encrypted channel, not in plaintext Best regards, Philipp ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On Mon, Sep 30, 2013 at 2:27 PM, James A. Donald jam...@echeque.com wrote: Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it. What about tools that want to comprehend it using something other than C code? The theoretical argument against something like this is the resulting C code is a weird machine, i.e. ASN.1 cannot be understood by a pushdown automaton or described by a context-free grammar. See: http://www.cs.dartmouth.edu/~sergey/langsec/papers/langsec-tr.pdf -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. Sounds like you want CurveCP? http://curvecp.org/ -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] TLS2
On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical set of requirements. Then make it so. There are a dozen people here who could do it. Why not do the requirements, then ask for competing proposals? Choose 1. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
