On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla wrote:
>
>
> On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett
> wrote:
>
>> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
>> > I think perhaps you have misunderstood the forward secrecy properties
>> of the
>> > current draft. Unlike
I am ok with whatever the WG decides, particularly when the reasons are
non-cryptographic but rather based on implementation considerations.
Still, for the record, I'd like to correct the statement "
KnownConfiguration is only useful with 0-RTT.
".
KnownConfiguration could be used with 1-RTT
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 advantages are: a cleaner separation of keys de
On Sun, Oct 11, 2015 at 9:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> wrote:
> > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> >> > *From:* internet-dra...@ietf.org
> >> >
> >> > Name: draft-vanrein-tls-kdh
> >> > Revision: 00
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
authentica
; 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 possessio
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 appropriat
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
On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg wrote:
>
>
> On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote:
>
>
>
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk
> wrote:
>
>> I have mentioned this in private conversations but let me say this here:
>
On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg wrote:
> Whoops, big-R to reply all...
>
> On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk wrote:
>
>
> On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg wrote:
>
>>
>>
>> On Dec 17, 2015, at 12:11 PM, Eric Rescorla
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
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
https://www.ietf.or
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 Dallas
>>
>>
>> In
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 strongly advocate not using the
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 sen
Karthik, I think that what you are pointing to are cases where the client
*is* authenticated via its PSK.
There is an important distinction between PSKs that have been authenticated
by the client (in a previous exchange) and those that are not.
Any PSK-based handshake that uses a (previously) clie
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 under a broken cipher.
>
> Hmm, that's a good point. S
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 DH-based 0-RTT are almost ident
tacker can learn its
identity from a TLS handshake, it also needs to understand that 0.5 data is
open to any active attacker. Any expectations of 0.5 data being directed to
a specific client need to be eliminated.
Hugo
On Tue, Feb 23, 2016 at 5:52 PM, Martin Thomson
wrote:
> On 23 Febru
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 conside
On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk
> wrote:
> > 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
&g
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 i
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
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 <
muhammad_usama.sar...@tu-
+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
auth
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
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
diff
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 (w
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
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. R
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
gnature
> 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 exagg
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 support 0-RTT via DHE
On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk
> wrote:
>
>>
>>
>> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote:
>>
>>> All,
>>>
>>> To make sure we’ve got a cl
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
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 by that option anyway. Let me clarify.
I understand the question as relating *only* to post-handshake messages a
On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson
wrote:
> Not taking any position on the question, which I think is a fine thing
> to ask, but...
>
> I'd just like to point out that the example is flawed in the sense
> that the system permits both users to share state. When Alice logs
> out, that
Here are some (second) thoughts on the derivation of resumption_context.
The purpose of this value is to bind the resumed session to the data in the
original connection, namely, to "ClientHello...Client Finished" (and, in
particular, to the server's identity).
The right way to do this binding i
On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk
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 by that option anyway. Let me
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
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
origin
On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote:
>
>
> On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
> wrote:
>
>> I don't understand the proposal.
>> Are you proposing to eliminate resumption_context (RC) from All its
>> current uses and replac
On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara
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 wrote:
> >
> > >
> > >
> > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
>
On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara
wrote:
> On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> > On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Sep 07, 2016 a
If the problem is the use of forward secrecy then there is a simple
solution, don't use it.
That is, you can, as a server, have a fixed key_share for which the secret
exponent becomes the private key exactly as in the RSA case. It does
require some careful analysis, though.
But maybe I misundersto
t 4:41 PM, Hugo Krawczyk
> wrote:
>
>> If the problem is the use of forward secrecy then there is a simple
>> solution, don't use it.
>> That is, you can, as a server, have a fixed key_share for which the
>> secret exponent becomes the private key exactly as in t
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 <
>> ilariliusva...@welho.com>
>> > wrote:
>> >
>> > > On
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
standar
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
repeti
Typo correction below.
On Jan 1, 2017 12:43 PM, "Hugo Krawczyk" 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 not repeat DH values). One has
On Thu, Feb 9, 2017 at 4:15 PM, Eric Rescorla wrote:
> I've just posted a pull request which slightly adjusts the structure of
> key derivation.
> PR#875 adds another Derive-Secret stage to the left side of the key ladder
> between each pair of HKDF-Extracts. There are two reasons for this:
>
> -
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(., "expor
52 matches
Mail list logo
