Re: [TLS] TLS and KCI vulnerable handshakes

>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek > > Some comments on this, it looks like it requires a "cert with static (EC)DH > key" in order to work, which would mean an X9.42 cert. Since no (public) CA > that I know of can handle or issue such certs, this p

Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

> Sam just ran the analysis. The TLS 1.3 proofs they have work without > Certificate in the transcript, which is equivalent to a zero-bit > truncated hash. I assume the client hello extension still has the certificate digest, yes? This means that the analysis probably relied on agreement of the c

Re: [TLS] TLS 1.3 - Support for compression to be removed

Julien, It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, but it is unlikely. You ask a pointed question about AUTHINFO, so just as a fun game, let’s analyze its security: AUTHINFO USER test 381 Enter password AUTHINFO P

Re: [TLS] Review of PR #209

As dkg points out, dynamically authenticating clients later in the connection brings up API issues of how to notify the application about the scope of this new authentication event. I think it is inevitable that implementation will store the client credential in the session, and that the new (a

Re: [TLS] PR for anti-downgrade mechanism

A few more words on this proposal. - The goal is to protect TLS 1.3 clients and servers from attacks on TLS 1.* ciphersuites. E.g. if a new attack on the MD5 | SHA1 concatenation in TLS 1.0 is announced, connections between TLS 1.3 clients and servers would still be protected. Similarl

Re: [TLS] PR for anti-downgrade mechanism

> For reference, the version field in the TLS premaster secret is not checked > by many servers, IIRC some of them have large market shares. That’s good to know. It would be tempting to recommend that TLS 1.3 servers disable RSA (encryption) ciphersuites for all protocol versions, but I guess

Re: [TLS] PR for anti-downgrade mechanism

> 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a > client that supports TLS 1.3? Why doesn't the already-standardized downgrade > SCSV mechanism work for those cases? The attack we’re protecting against is the following: - a TLS 1.3 client sends a client hello and the

Re: [TLS] PR for anti-downgrade mechanism

Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2 implementations to signal each other about their preferred connection parameters. To make most use of the bytes provided, one could use the sentinel value to indicate support for an extension, which then carries a signed s

Re: [TLS] Design Alternatives for Kerberos + DH

> 2) Embed the Ticket + Authenticator in a PSK I don’t fully understand the constraints of the Kerberos+DH use-case, but using DHE-PSK seems like the best idea. The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and uses a session ticket mechanism that is not so far from the

Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

Nice analysis! I think that the composition of different mechanisms in the protocol is likely to be where many subtle issues lie, and analyses like this one support that concern. Several other composition examples were already discussed on this list (for previous drafts). For example, when comp

Re: [TLS] Deprecating tls-unique for TLS 1.3

Despite the proposed extended master secret fix in RFC7627, I now think that tls-unique needs to be deprecated for all versions of TLS, and that we should design and recommend a new channel binding that can be used uniformly by SASL/TokenBinding/FIDO etc. I have read Simon’s draft and it is a pl

Re: [TLS] Fresh results

The use of the same RSA key for decryption and signature has always been problematic from a cryptographic point of view. As far as I am aware, all current security theorems for TLS assume that the same RSA certificate (public key) is not used in both RSA and DHE ciphersuites. In theory this sh

Re: [TLS] Fresh results

> Suppose keyUsage is respected. Who will knowingly shoot themselves > in the foot and restrict their RSA certificate to just DHE or just > RSA key transport? This looks like an impractical counter-measure. I guess we have to trade-off between different levels of “shooting oneself in the foot”.

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Our state machine design in miTLS was quite deliberate, and based on our interpretation of the TLS 1.2 spec. It is possible that we got this interpretation wrong, but maybe the protocol authors can clarify the intended behavior. However, I think that looking at the Handshake protocol message se

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

As mentioned before, validating Curve25519 public values is necessary in TLS 1.2 without session hash. Otherwise, as we pointed out in [1], the triple handshake attack returns. [1] http://www.internetsociety.org/doc/verified-contributive-channel-bindings-compound-authentication

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

> I'm aware of that (and related) work, but this is about finding > multicollisions in MD5 || SHA1. To be clear, there is no published collision on MD5 || SHA1 right now. In our paper, we only say that *if SHA-1 collisions were to appear* with complexity 2^x, then MD5||SHA1 collisions would cos

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

> I'm also wondering whether it might be misleading to lump the > (in)significance of the currently known collisions for HMAC-SHA1 > and HMAC-MD5 together with the (in)significance for > (general, low-frequent) digital signatures and together with > PKCS#10 & Certificate-issuance design flaw that

Re: [TLS] Proposal: don't change keys between handshake and application layer

I do not have a very strong opinion on whether the same traffic keys can or should be used for the handshake and application. As Hugo says, it complicates the cryptographic analysis but we do know now how to do the analysis for such key usage, thanks to years of work on TLS <= 1.2. I am told tha

Re: [TLS] Proposal: Simplified Key Schedule

> Note that this is (almost) exactly the original KDF scheme of OPTLS as I > presented in Dallas Indeed, Ekr’s proposed scheme looks much like you original diagram. > Anyway, from here you can see that the last HKDF in your scheme (with 0 salt) > is not needed. You can derive the RMS, EMS keys d

Re: [TLS] 0.5 RTT

There are some fears about 0.5-RTT data that do not necessarily apply to post-client authentication, at which point at least both parties have sent their Finished messages. When the server is sending 0.5-RTT data, this is effectively false-start; the client hasn’t confirmed its choice of ciphe

Re: [TLS] 0.5 RTT

> ​That's right, we do not consider downgrades or client authentication but > Martin's suggestion explicitly only applies to the case​ where the server > does not require client authentication so the analysis holds in that case. As > for downgrades, this will be discovered by the server when rec

Re: [TLS] 0.5 RTT

> Won't a downgrade be detected by the client when it fails to decrypt > the server's data? The main downgrade concern, I think, is for the 0.5-RTT data’s confidentiality; i.e. it may have been sent encrypted under a broken cipher. You’re right that the client will not accept this data because t

Re: [TLS] 0.5 RTT

may contain a cookie. > > Let me be clear, I prefer a conservative design to a more liberal one so if > we can do without 0.5 data then much better. > > Hugo > > > > > On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan > mailto:karthik.bharga...@gmail.com>

Re: [TLS] Remove DH-based 0-RTT

> > The server signature is essentially over raw handshake messages, up > to and including ServerCertificate. The first message that would > depend on actual value of SS is ServerFinished, which comes after > that point… Yes Ilari, you’re right. In my TRON talk, I described an attack on PSK+Sign

Re: [TLS] Working Group Last Call for ECH

> Hopefully, some of the people who did the analyses will > chime in on the WGLC though, it'd be good if they had the > time to do that. I am not sure this specific case was covered in our analysis, but I will confer with our co-authors. Best, Karthik > > Cheers, > S. > >> thanks, >> Rob >>

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

I can speak a little to how the reuse of keys will affect existing TLS 1.3 proofs and analyses. First it is worth noting that most TLS 1.3 proofs do not consider hash function agility, and say nothing about deploying TLS 1.3 in parallel to TLS 1.2 (with some exceptions like [1], [2]) So, the go

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

> As with Universal PSKs (UPSKs), each input key is a triplet of > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs To be clear, you’re suggesting that

Re: [TLS] Limiting replay time frame of 0-RTT data

Hi Kyle, In my talk at TRON, I was also concerned by potential attacks from allowing unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should implement replay protection using a cache, but requiring clients to provide a timestamp in the client random is a great idea. Perhaps this

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

> The problem with this is that the standard hash API is { Init, [ Update, > Update, ... ], Final }, so this only works if you've got access to a custom > API that allows you to fork the state so one branch goes to Final and the > other continues with Update. It's good if you've got it, but a lot

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

> So presumably instead of hashing the bare nonces for the keyex sig you'd hash > the entire hello message that contains them? Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want to clone the hash state, then maybe the log up to ServerCertificate. I agree that the benefi

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

Let me try to understand the concerns here. > Resumption and Forward Secrecy PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? This is already better than TLS 1.2 where we had no way to do forward-secret resumption. In that case, the concern is mainly for 0-RTT, which I agre

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

From: TLS [mailto:tls-boun...@ietf.org <mailto:tls-boun...@ietf.org>] On > Behalf Of Karthikeyan Bhargavan > Sent: Monday, March 28, 2016 1:31 PM > To: Colm MacCárthaigh mailto:c...@allcosts.net>> > Cc: tls@ietf.org <mailto:tls@ietf.org> > Subject: Re: [TLS] Resumpti

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

> ​We (Chrome) definitely want this (sending cookies in 0-RTT requests), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify). ​ I see. So, it is quite likely that the most common usage of TLS 1.3 would send sensitive data in 0-RTT. It is unfortunate that the forward secrec

Re: [TLS] Key separation and privacy

These are good questions. More generally, when do we care about distinguishing handshake data from application data? I just posted another email about using plaintext end_of_early_data alerts to avoid trial decryption, and similar questions come into play there. Best, Karthik > On 29 Mar 201

Re: [TLS] Consensus call for keys used in handshake and data messages

I prefer (2) > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> >> or >> >> 2. Restore a public content type and different keys > > G

Re: [TLS] judging consensus on keys used in handshake and data messages

If we are left with 1 or 3, the miTLS team would prefer 1. On the cryptographic side, Hugo has a recent (draft) paper that seems to provide some more justification for (1), at least for client authentication. I know this is a bit off-topic, but the miTLS team would also like to get rid of 0-RTT

Re: [TLS] [Cfrg] 3DES diediedie

> Looking at it from the other side, your typical IoT device will be sending, > for example, a 12-byte message every 15 minutes, meaning it'll take, if my > calculations are right, just under two million years to collect the 785GB of > data required to perform the attack. I agree that it would be

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

Recall that the original renegotiation attack relied on a client that has no intention to renegotiate but was still fooled into renegotiating the attackers’s connection to the server. To prevent this attack, it is essential that the client includes an empty R-I in its client hello. This negative

Re: [TLS] Current TLS 1.3 state?

We’re hoping that the TLS:DIV workshop later this month will serve to gather some opinions from the academic community on the current spec. https://www.mitls.org/tls:div/ At IEEE S&P (Oakland), there will be at least two papers on analyses of draft 18: - A ProVer

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

Visibility goes both ways. The discussion so far has been primarily about making end-to-end data visible to middleboxes. It would less concerning to do it the other way round, where middleboxes are made visible to the endpoints, and proxying/visbility decisions are made at the endpoints. Indeed,

Re: [TLS] Working Group Last Call for ECH

Is there value in citing the security analysis for ECH as an informative reference? https://dl.acm.org/doi/abs/10.1145/3548606.3559360 A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security