Re: [TLS] Key Hierarchy TLS 1.3 RFC8446(bis)

See full thread here https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA/ See also how this helped analysis here (search for reference [73] https://inria.hal.science/hal-01528752v3/file/RR-9040.pdf On Sat, Dec 16, 2023 at 1:16 PM Muhammad Usama Sardar <

Re: [TLS] TLS Opaque

Thanks Bob for pointing to the "real" ongoing specification of OPAQUE in https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03 and its careful specification of OPAQUE-3DH, including test vectors (and sorry Scott for the typos in the other draft). draft-irtf-cfrg-opaque is still work in process and

Re: [TLS] Static DH timing attack

Dan, What you suggest, namely, DH for both static and ephemeral keys is what OPTLS was about and this approach is now specified in https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01. I was never too happy with the name semi-static for such protocol, and people may think that if static

Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

re > forgery. But then people naturally wanted to use hashes (as a “utility > function” in Phillip’s terms) for a MAC. But hashes with message extension > suffer from MAC forgery. Along came HMAC to the rescue, saving the day, and > the rest is history. (To exaggerate

Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

Hi Quynh, see a couple of remarks below, On Mon, May 11, 2020 at 8:10 AM Dang, Quynh H. (Fed) wrote: > Hi Rich, Sean and all, > > 1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type > shared secret. However, the first HKDF-Extract in the key schedule takes a > PSK instead

Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

There is no flaw if you use HMAC and HKDF as intended. See details below. The bottom line advise is: If you are using related (not random) salt values in HKDF, you are probably using it with domain separation functionality. In HKDF, domain separation is enforced via the info field not the salt.

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

A clarification on the text suggest below by Russ. The way I see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of authentication but as a way of regaining forward secrecy in case the (EC)DHE mechanism is ever broken (e.g., by cryptanalysis or

Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

What Illari describes is in accordance to TLS 1.3, which uses HKDF-Expand correctly (as defined in RFC 5869 and the related extract-then-expand scheme from https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf, Fig 1 in pg 18). That is, it uses the "secret" as a key to HMAC

[TLS] Security of OPAQUE in TLS

In the TLS meeting on Tuesday, Kenny asked about the analysis of OPAQUE in the context of TLS. One important property of OPAQUE is that its design and analysis is modular. It applies to the composition of *any* OPRF with *any* (KCI-secure) key exchange. This is why we can integrate OPAQUE with

Re: [TLS] Elliptic Curve J-PAKE

Hi Hannes, J-PAKE is a symmetric PAKE. Both parties store the same password. It is not suitable for most client-server scenarios where using J-PAKE would mean that an attacker that breaks into the server simply steals all plaintext passwords. OPAQUE is an asymmetric (or augmented) PAKE where user

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

+1 for this work. If you are one of those that think, as I did 20 years ago, that password authentication is dying and practical replacements are just around the corner, do not support this document. Otherwise, please do. Asymmetric or augmented PAKE (aPAKE) protocols provide secure password

Re: [TLS] Adding an additional step to exporters

Martin, Which of these two derivation schemes are you proposing? Are you assuming that all uses of the exporter_secret are known at the end of the handshake? If not, you still need to keep an exporter_secret beyond the handshake. Master Secret | | +-> Derive-Secret(.,

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

Typo correction below. On Jan 1, 2017 12:43 PM, "Hugo Krawczyk" <h...@ee.technion.ac.il> wrote: There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One has to be careful not to give a false sense of security by the illusion that not detecting DH

Re: [TLS] Confirming consensus: TLS1.3->TLS*

If it wasn't because we don't need more noise in this discussion I would have suggested SSL 5.0 which seems to be the logical conclusion from the reasoning people are using. Clearly, everyone thinks that the battle of replacing "SSL" with "TLS" in the popular and technical references to the

Re: [TLS] Finished stuffing/PSK Binders

On Fri, Oct 7, 2016 at 1:08 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: >> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < >>

Re: [TLS] Finished stuffing

On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote: > > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > > > > >

Re: [TLS] Finished stuffing

On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <h...@ee.technion.ac.il> > wrote: > >> I don't understand the proposal. >> Are you proposing to eliminate resumption_context (RC) f

Re: [TLS] Finished stuffing

I don't understand the proposal. Are you proposing to eliminate resumption_context (RC) from All its current uses and replace it with the hello_finished extension? Or is this to affect only certain uses of RC? Which ones? One important property of RC is that it serves as a binding with the

Re: [TLS] Resumption Contexts and 0-RTT Finished

Without taking a position on the implementation issues, I am in favor of Option A with a dedicated context value (and an explicit name "PSK Context") as this makes clear the function of this value. Relying in Finished makes it more fragile and open to be dropped in the future when its binding role

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

On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote: > I do not have an objection to option 1 if re-phrased as > Option 1 - use the same key for protecting both *post*-handshake and > applications messages.. > > I believe this is what was intended

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

I am abstaining on the choice of alternative 1 and 2 since I do not understand enough the engineering considerations and ramifications of the different choices. Also, I have not put any thought into the privacy issues related to hiding content type and I certainly did not do any formal analysis of

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <h...@ee.technion.ac.il> > wrote: > >> >> >> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <s...@sn3rd.com> wrote: >

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: > All, > > To make sure we’ve got a clear way forward coming out of our BA sessions, > we need to make sure there’s consensus on a couple of outstanding issues. > So... > > There also seems to be (rougher) consensus not to

Re: [TLS] 0.5 RTT

On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd <watsonbl...@gmail.com> wrote: > On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk <h...@ee.technion.ac.il> > wrote: > > As I said in another email, without client authentication (which is the > > scenario in the Karthik q

Re: [TLS] 0.5 RTT

As I said in another email, without client authentication (which is the scenario in the Karthik quote), data sent by the server should be considered secure only against passive adversaries. Any additional assumption on confidentiality (i.e., restricting the power of an active attacker) must

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

On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett wrote: > On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: > > I propose that we remove DH-based 0-RTT from TLS 1.3. > > > > As ekr's previous mail noted, the security properties of PSK-based > > 0-RTT and

Re: [TLS] 0.5 RTT

On Tue, Feb 23, 2016 at 5:08 PM, Martin Thomson wrote: > On 23 February 2016 at 14:01, Karthikeyan Bhargavan > wrote: > > The main downgrade concern, I think, is for the 0.5-RTT data’s > confidentiality; i.e. it may have been sent encrypted

Re: [TLS] 0.5 RTT

On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > 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

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

On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet wrote: > As pointed out by Karthik, we are not strongly advocating this > simplification, but we do not think it would weaken the security of TLS. > Details below. > I am glad you are not strongly advocating this. I

Re: [TLS] Proposal: Simplified Key Schedule

Couple of comments below. On Fri, Feb 19, 2016 at 9:14 AM, Eric Rescorla wrote: > > > On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < > karthik.bharga...@gmail.com> wrote: > >> >> Note that this is (almost) exactly the original KDF scheme of OPTLS as I >> presented in

Re: [TLS] Proposal: Simplified Key Schedule

I agree that once you remove the requirement to derive a key from g^xy (=ES) for protecting a static DH key then the KDF scheme can be simplified as shown (or even further - see below). Note that this is (almost) exactly the original KDF scheme of OPTLS as I presented in Dallas

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

I want to point out that the benefits of using the application key output by the handshake protocol also for handshake traffic protection are not clear cut. I cannot comment at the level of implementation simplification that motivates this change but I can comment on the cryptographic implications

Re: [TLS] Explicit use of client and server random values

On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg <m...@shiftleft.org> wrote: > Whoops, big-R to reply all... > > On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote: > > > On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <m...@shiftleft.org&g

Re: [TLS] Explicit use of client and server random values

I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash. That is, handshake_hash = Hash( client random|| server random

Re: [TLS] bikeshed: Forward Security or Secrecy?

The more common term is "forward secrecy" - indeed, the normal definition [1] refers specifically to the secrecy of session keys or ephemeral key material after being deleted. Other elements of security such as authentication and integrity are irrelevant so "secrecy" seems to be the more

Re: [TLS] Should we use proof-of-possession rather than signatures?

d be slightly faster than > sigs, but I don't have an implementation of that lying around. There is > also a different calculation if the client has precomputed a table from the > server's static key, but nobody does that and I'd guess the results are > similar anyway. > > Proof of

Re: [TLS] Key Hierarchy

On Sun, Sep 20, 2015 at 9:56 PM, Brian Smith wrote: > On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/248 >> >> Aside from some analytic advantages >> > > What are the analytic advantages? > ​The