Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On 15/10/15 00:04, Watson Ladd wrote: > On Wed, Oct 14, 2015 at 6:43 PM, Matt Caswell wrote: >> >> >> On 14/10/15 21:42, Martin Thomson wrote: >>> On 14 October 2015 at 13:29, David Benjamin wrote: If you really absolutely must support interleave and can't avoid it, I think it being allowed everywhere except between CCS and Finished is probably the closest you can get to coherent semantics. "Coherent" here is, of course, all relative since renego is involved. >>> >>> I think that it needs to be more than that. I would say: >>> >>> 1. You should not interleave data with handshake messages from the same >>> flight. >>> 2. You should not report any change to handshake status until the >>> renegotiation is complete. That means no callbacks/events about new >>> peer certificates, or anything of that nature until you have received >>> and validated the Finished. You would have to exercise caution here >>> for the callbacks that are necessary during the process, like the >>> "please choose a certificate and private key to use" callback on >>> either side. >>> >>> If you can somehow manage to do all of that, then you might be able >>> get away with not halting progress entirely. Because - as far as the >>> application is concerned - application data is sent as though it were >>> before the renegotiation. In essence, you are keeping the application >>> ignorant of any changes until the whole process is over. >>> >>> I've heard it recommended that you add other stipulations, such as >> >> That would be very challenging to implement. Almost certainly not >> possible for the stable released versions. I would hesitate to do so for >> the new development version too without explicit published advice in the >> form of an RFC/errata...it would add significant complexity. >> >> It seems my options in reality are: >> >> 1) Allow interleaved data everywhere except between CCS and Finished, as >> per the (hopelessly unclear) RFC. This would leave us conformant, would >> solve our interoperability problems, but is a "highly dangerous idea" >> according to your advice. >> >> or >> >> 2) Leave things as they are now where we abort on interleaved >> application data. This would leave us unconformant and with an >> interoperability problem which is causing real issues for users (who >> will point the finger at us for failing to fix it). > > It takes two sides here to have an interop problem. What > implementations are doing this? The specific report I have is for Oracle JRE 1.7.0_71 and 1.7.0_75 but my assumption is that this affects all Oracle JRE versions. The problem ticket in question describes a scenario where a PostgreSQL server (which uses OpenSSL) is talking to a PostgreSQL JDBC client. Due to that fact that these connections are long running, PostgreSQL server has a config parameter "ssl_renegotiation_limit" which triggers a renegotiation after a certain amount of data has been transferred over the connection. Matt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On 15/10/15 00:06, Martin Thomson wrote: > On 14 October 2015 at 15:43, Matt Caswell wrote: >> "highly dangerous idea" > > Wrong Martin. Oops. Sorry. > I agree that there is a need for caution, but in > reality, it's not like you can use renegotiation to hand-off to > someone else entirely. The person you are talking to hasn't changed. > What is dangerous is making assertions about *new* things that the > renegotiation introduces. > OpenSSL will not itself use anything from the new handshake until the CCS/Finished has been processed. I couldn't make the same guarantee about applications using OpenSSL APIs/callbacks (although no doubt applications could do all manner of dangerous things if they chose to). So that leaves me unclear whether you are advising me to "fix" the "bug" because its not that dangerous really, or whether the risk of applications using info they shouldn't is too great so we should maintain the status quo and leave things as they are (i.e. broken in certain scenarios). Matt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
Is the particular interop problem that you want to address caused by a necessity to really process application data and handshake data with arbitrary interleave, or is it rather a problem of getting back into half-duplex operation, i.e. a client being able to continue receiving application data up to a ServerHello when it has sent out ClientHello, or a server being able to continue receiving application data up to a ClientHello (or warning level no-renegotiation alert) after the server has sent a ClientHelloRequest? -Martin Matt Caswell wrote: > >>> 1) Allow interleaved data everywhere except between CCS and Finished, as >>> per the (hopelessly unclear) RFC. This would leave us conformant, would >>> solve our interoperability problems, but is a "highly dangerous idea" >>> according to your advice. >>> >>> or >>> >>> 2) Leave things as they are now where we abort on interleaved >>> application data. This would leave us unconformant and with an >>> interoperability problem which is causing real issues for users (who >>> will point the finger at us for failing to fix it). >> >> It takes two sides here to have an interop problem. What >> implementations are doing this? > > The specific report I have is for Oracle JRE 1.7.0_71 and 1.7.0_75 but > my assumption is that this affects all Oracle JRE versions. > > The problem ticket in question describes a scenario where a PostgreSQL > server (which uses OpenSSL) is talking to a PostgreSQL JDBC client. Due > to that fact that these connections are long running, PostgreSQL server > has a config parameter "ssl_renegotiation_limit" which triggers a > renegotiation after a certain amount of data has been transferred over > the connection. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New curves work and TLS
As you might know, CFRG has been working on new curves (the document has been sent to IRSG) and is working on signatures (main issues seem to be selecting prehash for prehashed version of 448-bit signatures and KDF for 448-bit signatures). I have been thinking how to integrate this work into TLS. Diffie-Hellman: --- There is already a WG draft about this. The one remaining technical issue seems to be wheither to share the curves with signatures or dedicate those for DH. I propose dedicating the codepoints (like draft currently does). The complexity of implementing signatures is significantly above complexity of implementing ECDH. This is magnified by the differences between the signature primitive (one is based on SHA-512, the other on some still-TBD KDF). It is not like there is imminent shortage of curve codepoint space, as we have >64,000 codepoints free. There's also editorial issue of tracking the renaming of the DHFs in CFRG-CURVES (Curve25519->X25519 and similarly for Curve448). Signatures: --- The base algorithm for signatures work is EdDSA. It looks like Ed25519 is standardized as-is (at least compatible enough for existing verifiers to be used). Then there is version that first does SHA-512. For 448-bit versions, the KDF and prehash to be done first (for version that does prehashing) is TBD. So, there are four primitives: Ed25519, Ed25519ph, Ed448 and Ed448ph. And keys MUST NOT be mixed between those. I propose the following: - EdDSA uses one SignatureAlgorithm value (5?[1]). - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and another for Ed448/Ed448ph - If there is ever EdDSA instantiation with Edwards448 curve (the same one Ed448 uses) with another KDF, it gets a new curve distinct from Ed448/Ed448ph. - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or value matching the prehash (but the prehash is always done once[2]). [TBD: resolve this] - To be useful, one needs PKIX SPKI representation for the keys. There is a draft about that, to be progressed via other channels (Security area presumably, as PKIX WG is no more). [1] TLS 1.3 introduces one new value for RSA-PSS (which is IIRC marked as 4 in the spec). [2] Technically Ed25519 and Ed448 do have prehash function PH, it just is the identity function. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On 15/10/15 14:00, Martin Rex wrote: > Is the particular interop problem that you want to address > caused by a necessity to really process application data and > handshake data with arbitrary interleave, > > or is it rather a problem of getting back into half-duplex operation, > i.e. a client being able to continue receiving application data > up to a ServerHello when it has sent out ClientHello, or a server being > able to continue receiving application data up to a ClientHello > (or warning level no-renegotiation alert) after the server has sent > a ClientHelloRequest? The former. The existing code should cope with the half-duplex issue. In the reported problem we (OpenSSL) are running as a server and we have received application data from the Client *after* we have sent our ServerHelloDone. Matt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New curves work and TLS
On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett
wrote:
> On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> > Ed448ph. And keys MUST NOT be mixed between those.
> >
> > I propose the following:
> > - EdDSA uses one SignatureAlgorithm value (5?[1]).
> > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and
> > another for Ed448/Ed448ph
> > - If there is ever EdDSA instantiation with Edwards448 curve (the same
> > one Ed448 uses) with another KDF, it gets a new curve distinct from
> > Ed448/Ed448ph.
> > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or
> > value matching the prehash (but the prehash is always done once[2]).
> > [TBD: resolve this]
>
> I've been thinking about the issue of how to handle
> SignatureAndHashAlgorithm values better. I think this time, I'd like to
> propose going the opposite way we'd normally want to move: let's consider
> enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of
> having independent values. We're moving to signature algorithms that don't
> have arbitrary hashes, so the current system isn't really ideal anymore.
>
> Current draft:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1
> (text)
> https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88 (full
> registry)
>
> enum {
> none(0),
> md5_RESERVED(1),
> sha1(2),
> sha224_RESERVED(3),
> sha256(4), sha384(5), sha512(6),
> (255)
> } HashAlgorithm;
>
> enum {
> anonymous_RESERVED(0),
> rsa(1),
> dsa(2),
> ecdsa(3),
> rsapss(4),
> (255)
> } SignatureAlgorithm;
>
> struct {
> HashAlgorithm hash;
> SignatureAlgorithm signature;
> } SignatureAndHashAlgorithm;
>
>
> Proposed replacement backwards-compatible registry:
>
> struct {
> anonymous_RESERVED(0x),
> rsa_nohash(0x0001),
> dsa_nohash(0x0002),
> ecdsa_nohash(0x0003),
> rsapss_nohash(0x0004),
> md5_RESERVED (0x0100..0x01FF),
> rsa_sha1(0x0201),
> dsa_sha1(0x0202),
> ecdsa_sha1(0x0203),
> rsapss_sha1(0x0204),
> sha224_RESERVED (0x0300..0x03FF),
> rsa_sha256(0x0401),
> dsa_sha256(0x0402),
> ecdsa_sha256(0x0403),
> rsapss_sha256(0x0404),
> rsa_sha384(0x0501),
> dsa_sha384(0x0502),
> ecdsa_sha384(0x0503),
> rsapss_sha384(0x0504),
> rsa_sha512(0x0601),
> dsa_sha512(0x0602),
> ecdsa_sha512(0x0603),
> rsapss_sha512(0x0604),
> (0x)
> } SignatureAndHashAlgorithm;
>
>
> New values could be assigned specific combinations as needed. This would
> also let hashes & signatures be deprecated independently easily, e.g. allow
> rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from
> the start).
I am not in favor of this change. Because we can already indicate
combinations, this
doesn't seem to add significant new value. If we need to indicate
"signature algorithm
without a hash" then a "none" hash is the simplest solution.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] OPTLS paper posted
The OPTLS paper (preprint) explaining the rationale of the protocol and its analysis is posted here: http://eprint.iacr.org/2015/978. The OPTLS design provides the basis for the handshake modes specified in the current TLS 1.3 draft including 0-RTT, 1-RTT variants, and PSK modes (client authentication is not covered). OPTLS dispenses with elements that are not essential to achieve the basic cryptographic security of the protocol. By following such a "minimalistic" approach, the OPTLS design provides the flexibility of building different protocol variants that provide varied performance trade-offs and security features. Some of these variants give rise to the current TLS 1.3 modes while others may be useful in the future. In the latter class it is worth noting the ability to obtain a protocol that completely eliminates online signatures while keeping most of TLS 1.3 unchanged. The analysis part of the paper covers the basics of key exchange security. More comprehensive analyses including validation of TLS 1.3 specifications and implementations is expected to be covered by future work. We would like to take this opportunity to thank the TLS Working Group for insightful discussions and invaluable feedback that led to this work. Hoeteck and Hugo ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt
On Mon 2015-10-12 09:18:17 -0400, Yaron Sheffer wrote: > I'm not familiar enough with TACK at the moment. I can write something > up, or if you'd like to contribute text, that'll be awesome. i'm not up-to-speed yet either, and am unlikely to be able to get to this soon, sorry! > IMO persisting the master key to disk is less of a problem than > distributing it across cluster members, and this is something that > needs to happen or session resumption will fail regularly. Regular > rotation of the master key means that persisting it to disk is not > such a risk. You are right that a session resumption master key needs > not be backed up, whereas the pinning secret may need to be backed up > securely for disaster recovery. hm, i'm not convinced of this tradeoff in general -- in today's "cloud-y" age, backing up to disk rather than keeping in RAM might trigger writes to data storage that's owned by yet another entity. This means you have the potential for traffic decryption not only to those who can access your CPU and RAM, but those who run your storage backend. Even worse, if the pinning secret is derived from the session resumption master secret as recommended in section 4.2, then the temptation will be to store the session resumption master secret to disk, which puts the forward secrecy of resumed sessions at risk. If admins don't persist the resumption master secret, but persist only the derived secret, then there are two modes of operation: one running from the derived secret, and one running from the backup secret, which sounds messy. Perhaps some implementation guidance is warranted here? > Yes, I was thinking of privacy in the face of passive attackers who > listen in to the TLS handshake. Not when the server itself is out to get > you. I suspect that there is little you can do to protect your privacy > when the server itself is malicious, but I'm sure you are more > knowledgeable about these issues. TLS servers themselves should not be able to track a TLS client in the event that the client decides to not be tracked. For example, a client could refuse to initiate session resumption, and could offer a standardized, common TLS Client Hello. Maybe privacy from a pinned-ticket server can be achieved by a client by simply never sending the ticket pinning extension, or by never sending it on subsequent connections? this would come at the cost of losing the ability to detect when a server's identity gets swapped out, of course. It's not a particularly satisfying tradeoff. > You are right. "Certificate pinning" is the more common term, but is it > less precise. fwiw, "certificate pinning" is also used in https://tools.ietf.org/html/rfc6125#page-11 to describe what browsers often call a "security exception" -- a non-validating certificate that the user explicitly decides to allow for a given site. this kind of additional grant is the *opposite* of the additional restriction you're describing. better to stick to "public key pinning", which has no such connotations. > The longer you keep a keypair, the more likely it is to be compromised. > So you may not want to keep a keypair in "cold storage" for a year, and > then use it as a production cert for another year. > > Depending on your setup, the risk may be much larger on the production > server than on some offline storage, and then your proposed process > makes perfect sense. yes, i intended the proposal to be for an admin who has access to offline storage (though even an encrypted thumb drive locked in a drawer would do). > One difference is that in HPKP, the data stored in (b) is > security-critical, in that its compromise is just as bad as compromise > of the site's regular secret key (you can use it to MITM all > connections to the server). In my proposal the pinning secret is truly > a "second factor". Its compromise is an issue only if you can *also* > generate a fake certificate. I'm not sure about this distinction. No certificate has been issued for the HPKP backup key until just before it is deployed. So the attacker has to get a certificate issued for that secret key anyway, right? > Another major difference is that my proposal avoids the manual > management steps of HPKP (at least until we have ACME widely > deployed). The pinning secret can be generated automatically when the > server is started and rolled over periodically, with no human in the > loop. Since you'd still need to persist the secret to disk in some reliable way that handles rotation, backup, etc. safely if you don't want to risk bricking the site, I think you're saying that hypothetical software stack X has a better chance at successful implementation and deployment than hypothetical software stack Y. ;) Thanks for proposing this, Yaron. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
