Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FCC126D05 for ; Mon, 16 Apr 2018 12:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stGs_uPdO9wC for ; Mon, 16 Apr 2018 12:22:53 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389BB120725 for ; Mon, 16 Apr 2018 12:22:49 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m22-v6so18682282otf.8 for ; Mon, 16 Apr 2018 12:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/EEZX0+T3tpEfNTskYJBrhdHp4vkru2YyPd8B2Tsl0=; b=lpa/ZAvIS9o60ATEulA0yvRcigBzIYUfxnph95HbI5A3RTFL4x/m+mRFc8F0uaAuwm u5+GWODYaHdaeJ/Dy3o5NV1chzoRbb/VK6zGNADovfuXHxeF7xjs9xMvR7LZpinQ8vDt btF0DFYIB2AgnY1aVSIp/OL8FjoWjDfc+J10luNAKmO5FtZtP0Mo7PZk3rj3/PB4E9Or Ltj8eLffdR5fGwRW2pRubqHudZwvcRDiUT3tYD2rzlYmo7NRZaUAgPAk+bnkQcg7oSiR Sr+Pg8kbLrkXmvRvYfaG5z5QMhBh886gObIUz6ZXfIMBJUD+QouydQKo0dfh4kB+7E24 fcXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y/EEZX0+T3tpEfNTskYJBrhdHp4vkru2YyPd8B2Tsl0=; b=Xo9M3EA9vdUrQy+lCex9jAm98/QfzEHQEn02/QVnFsDLCfnW3xA5rrWWMI0QIcBany cQGfDEwOTNjN5tKBHo1s0yh4++mQHpKB9TkKl4AoQYc1UgleikAYtlpZtDdkhXJXZggt /xkRKUEIba0BfGqGMfvMBFc3PNaN7NEys3Jt5h0iiDRoJ13NaLIJrJp+aRJLXLcmE2/j cwAe8ps7RHtTd/Z0FazQe2+AshlR+AVJDmSZTnXYxFuVbp+Gi6iSW6gO18zppJuPH59J Q/tuJAX5+RbHFf/5z9BR2qOGL9g8NpcIDcdswCzi8sS65hCXMlqWuNhXxkE4y+bc3+bF 4VCQ== X-Gm-Message-State: ALQs6tC5AO7YvwvqcbIzUydiPF8MuVjfQCZZfOzsflpYQ3Yug0/Jw3sj uDGWBlA+xvtIY+CrHRb1TMKP1aNMFsXN1DbfxqCPKQ== X-Google-Smtp-Source: AIpwx48ptavRnCjIJm2FSH1wRHzxa07DPj81QZ5GdTe9HveGkD3ptE7N6sN+Plba/AKKjCL+oBikrjJE8RyKPU8XeDI= X-Received: by 2002:a9d:22e8:: with SMTP id y95-v6mr11910732ota.84.1523906568383; Mon, 16 Apr 2018 12:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 12:22:47 -0700 (PDT) In-Reply-To: References: <152345795593.1972.17855870949078823595.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC1DBF718C@UK-MAL-MBOX-01.dyson.global.corp> <140080C241BAA1419B58F093108F9EDC1DBFD7C7@UK-MAL-MBOX-02.dyson.global.corp> From: Richard Barnes Date: Mon, 16 Apr 2018 15:22:47 -0400 Message-ID: To: Jonathan Hoyland Cc: Tony Putman , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000ae103e0569fc2551" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:22:56 -0000 --000000000000ae103e0569fc2551 Content-Type: text/plain; charset="UTF-8" Oh, sure. In a similar vein, an attacker can also probe for which identities are known to the server. https://github.com/bifurcation/tls-pake/commit/0e72bd5244e89970fe61e5434ca7df3d769d057c On Mon, Apr 16, 2018 at 3:06 PM, Jonathan Hoyland < jonathan.hoyland@gmail.com> wrote: > You are, but it's not mentioned in the security section. > As it's a security consideration that you don't get in vanilla TLS I feel > that it should be mentioned. > > Regards, > > Jonathan > > > On Mon, 16 Apr 2018 at 20:01 Richard Barnes wrote: > >> That's correct, however if I have a guess of the password can I not just >>> try and connect using that password? >>> If my guess is correct then the connection will succeed, whereas if my >>> guess is incorrect then the connection will fail. >>> >> >> Sure, but aren't you going to have that with any password-authenticated >> protocol? >> >> --Richard >> >> >> >>> I'm assuming here that the salt is public, because salts in general do >>> not have confidentiality guarantees (otherwise they stretch the metaphor >>> and become pepper). >>> (I also assume that the client identity can be derived from observing a >>> previous session, and that the server identity can be identified through >>> probing.) >>> >>> Regards, >>> >>> Jonathan >>> >>> >>> >>> On Mon, 16 Apr 2018 at 19:43 Richard Barnes wrote: >>> >>>> Hey Jonathan, >>>> >>>> Thanks for the comments. I've implemented them in my working copy of >>>> the draft, and in my implementation in mint. I have also changed it over >>>> to use SPAKE2+; I agree with Tony that this is necessary to guard against >>>> server compromise. >>>> >>>> https://github.com/bifurcation/tls-pake/commit/ >>>> a9f097c3bfe43cf50001e1a340c7e2e693850d4b >>>> https://github.com/bifurcation/mint/pull/193 >>>> >>>> With regard to security properties: I don't think it's correct that an >>>> active attacker can do online password guessing. Everything that is >>>> revealed on the wire is blinded with fresh, per-connection entropy, and >>>> thus doesn't reveal anything about the password. >>>> >>>> --Richard >>>> >>>> >>>> On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < >>>> jonathan.hoyland@gmail.com> wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> A few nits. >>>>> >>>>> * In the introduction you have the sentence >>>>> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet >>>>> >>>>> seen significant security analysis. >>>>> >>>>> Iiuc this draft has no connection to MLS, and this is a typo. >>>>> >>>>> * In the setup you define >>>>> >>>>> > o A DH group "G" of order "p*h", with "p" a large prime >>>>> >>>>> and >>>>> >>>>> > o A password "p" >>>>> >>>>> >>>>> The variable "p" has two different meanings, which is a bit confusing, >>>>> especially later on. >>>>> >>>>> * The document doesn't explicitly state that X and Y need to be >>>>> non-zero. >>>>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if >>>>> the warning was carried through. >>>>> >>>>> * In terms of security properties, iiuc an active adversary can do >>>>> online password guessing attacks, but a passive adversary cannot derive the >>>>> password from observing the messages. If that is the case perhaps a warning >>>>> about rate-limiting connection attempts is appropriate. >>>>> >>>>> Regards, >>>>> >>>>> Jonathan >>>>> >>>>> On Mon, 16 Apr 2018 at 10:50 Tony Putman >>>>> wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> I don't think that you can protect against server compromise with >>>>>> SPAKE2. The server can store w*N as you suggest, but it also has to store >>>>>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and >>>>>> w*N from a compromised server can then impersonate a client. >>>>>> >>>>>> The rest of your comments I agree with (though they are not all >>>>>> addressed in the updated draft). >>>>>> >>>>>> Tony >>>>>> >>>>>> > From: Richard Barnes [mailto:rlb@ipv.sx] >>>>>> > Sent: 13 April 2018 19:50 >>>>>> > >>>>>> > Hey Tony, >>>>>> > >>>>>> > Thanks for the comments. Hopefully we can adapt this document to >>>>>> tick more boxes for you :) >>>>>> > Since I had noticed some other errors in the document (e.g., >>>>>> figures not rendering properly), >>>>>> > I went ahead and submitted a new version that takes these comments >>>>>> into account. >>>>>> > >>>>>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01 >>>>>> > >>>>>> > Some responses inline below. >>>>>> >>>>>> Dyson Technology Limited, company number 01959090, Tetbury Hill, >>>>>> Malmesbury, SN16 0RP, UK. >>>>>> This message is intended solely for the addressee and may contain >>>>>> confidential information. If you have received this message in error, >>>>>> please immediately and permanently delete it, and do not use, copy or >>>>>> disclose the information contained in this message or in any attachment. >>>>>> Dyson may monitor email traffic data and content for security & >>>>>> training. >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>> >>>> --000000000000ae103e0569fc2551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, sure.=C2=A0 In a similar vein, an attacker can al= so probe for which identities are known to the server.

On Mon, Apr 16, 2018 a= t 3:06 PM, Jonathan Hoyland <jonathan.hoyland@gmail.com> wrote:
You are, bu= t it's not mentioned in the security section.
As it's a security consideration that you don't get in v= anilla TLS I feel that it should be mentioned.

= Regards,

Jonathan


On Mon, 16 Apr 2018 at 20:01 Rich= ard Barnes <rlb@ipv.sx> wrote:
That's correct, howe= ver if I have a guess of the password can I not just try and connect using = that password?
If my guess is correct then the connection will su= cceed, whereas if my guess is incorrect then the connection will fail.=C2= =A0

Sure, but are= n't you going to have that with any password-authenticated protocol?

--Richard
=

=C2=A0
I'm assuming here that the salt is public, because salts in gener= al do not have confidentiality guarantees (otherwise they stretch the metap= hor and become pepper).=C2=A0
(I also assume that the client iden= tity can be derived from observing a previous session, and that the server = identity can be identified through probing.)

Regar= ds,

Jonathan



On Mon, 16 Apr 2018 at 19:43 Richard Barnes <= ;rlb@ipv.sx> wrote:
Hey Jonathan,

Thanks for the comments.= =C2=A0 I've implemented them in my working copy of the draft, and in my= implementation in mint.=C2=A0 I have also changed it over to use SPAKE2+; = I agree with Tony that this is necessary to guard against server compromise= .


With regard to security pr= operties: I don't think it's correct that an active attacker can do= online password guessing.=C2=A0 Everything that is revealed on the wire is= blinded with fresh, per-connection entropy, and thus doesn't reveal an= ything about the password.=C2=A0

=
--Richard


On Mon, Apr 16, 2018 at 7:52 AM, Jonathan= Hoyland <jonathan.hoyland@gmail.com> wrote:
Hi Richard,

A few nits.

=
* In the introduction you have the sentence<= /div>
>=C2=A0DISCLAIMER: This is a work-in-progress draft of MLS = and has not yet
   seen significant security analysis.=
Iiuc this draft has no connection to = MLS, and this is a typo.
* In the setup you define=C2=A0
> o A DH group "G" of order "p*h", with "= p" a large prime
and 
> o  A password &=
quot;p"

The variable "p" has two dif= ferent meanings, which is a bit confusing, especially later on.
* The document doesn't explicitly state that X and Y need to be= non-zero.=C2=A0
The requirement is in "I-D.irtf-cfrg-= spake2", but it would be nice if the warning was carried through.
<= br>
* In terms of security properties, = iiuc an active adversary can do online password guessing attacks, but a pas= sive adversary cannot derive the password from observing the messages. If t= hat is the case perhaps a warning about rate-limiting connection attempts i= s appropriate.=C2=A0

Regards,

Jonathan

On Mon, 16 Apr = 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> wrote:
Hi Richard,
I don't think that you can protect against server compromise with SPAKE= 2. The server can store w*N as you suggest, but it also has to store w*M be= cause it must calculate y*(T-w*M). An attacker that learns w*M and w*N from= a compromised server can then impersonate a client.

The rest of your comments I agree with (though they are not all addressed i= n the updated draft).

Tony

> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.=C2=A0 Hopefully we can adapt this document to= tick more boxes for you :)=C2=A0
> Since I had noticed some other errors in the document (e.g., figures n= ot rendering properly),
> I went ahead and submitted a new version that takes these comments int= o account.
>
> https://tools.ietf.org/html/draft-ba= rnes-tls-pake-01
>
> Some responses inline below.

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--000000000000ae103e0569fc2551--