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

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

> 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] 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

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.

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 (Oakland), there will be at least two papers on analyses of draft 18: - A

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

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] 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

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

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 <c...@allcosts.net <mailto:c...@allcosts.net>> > Cc: tls@ietf.org <mailto:tls@ietf.org> > S

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

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

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

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

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

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

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

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] 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] 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

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

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

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

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

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

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

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] 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

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

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 probably