Re: [Cfrg] Fwd: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt

[Hugo Krawczyk <[e-mail]>]

Thanks for the correction Clinton.

Let me take this opportunity to remind everyone that as clearly noted  in
the draft, draft-krawczyk-cfrg-opaque is intended as a high level
presentation of the protocol and not as a basis for a secure, interoperable
implementation. A detailed spec ready for implementation will be published
soon as a working group document (based on Stanislaw's email early today).

Hugo

On Mon, Jul 6, 2020 at 6:30 PM clinton bowen <[e-mail]>
wrote:

> Hello,
>
> A small note regarding
> https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-06.txt,
> could we revise the following formula in section 4 from:
>
>    KEYS = HKDF-Expand(key=RwdU, info=(nonce | "EnvU"), Length=LS+LH+LH)
>
> to:
>
>    KEYS = HKDF-Expand(key=RwdU, info=(Nonce | "EnvU"), Length=LS+LH+LH)
>
> -Clinton
>
>
> On Fri, Jun 19, 2020 at 9:26 PM Hugo Krawczyk <[e-mail]> wrote:
>
>> A new version of draft-krawczyk-cfrg-opaque is available.
>> It has an important change in the way secret information under the
>> envelope EnvU is protected.
>>
>> There is no form of optional encryption or use of counter mode anymore.
>> Instead it defines a very specific mechanism:
>> Secret information included in EnvU is xor-ed with a pseudo random
>> pad derived from RwdU, and HMAC is computed on the concatenation of this
>> value
>> and any non-secret information included in EnvU. This simple mechanism
>> satisfies the encryption requirement of OPAQUE and obviates any need to
>> specify
>> other RKR-secure schemes. In particular, it eliminates the "temptation"
>> to use
>> non-RKR modes such as GCM. Performance considerations are insignificant
>> here as
>> EnvU requires encryption of very short plaintexts. Applications that
>> require
>> sending additional information (e.g., non-OPAQUE user secrets stored at
>> the
>> server) will use ExportKey (previously called KdKey) with any encryption
>> scheme of their choice. No RKR requirement in this case.
>> See Section 4 for the details.
>>
>> This version also corrects a typo in the specification of SIGMA (the
>> identities
>> in messages K2 and K3 got mixed up in the version 05 of the draft).
>>
>> Very important: This draft is still intended as a high level description
>> of the
>> protocol and its components. A detailed specification is underway and
>> will be
>> posted shortly as draft-irtf-cfrg-opaque. OPAQUE implementers should
>> follow
>> the specifications in that document.
>>
>> Hugo
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Sat, Jun 20, 2020 at 12:20 AM
>> Subject: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt
>> To: Hugo Krawczyk <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-krawczyk-cfrg-opaque-06.txt
>> has been successfully submitted by Hugo Krawczyk and posted to the
>> IETF repository.
>>
>> Name:           draft-krawczyk-cfrg-opaque
>> Revision:       06
>> Title:          The OPAQUE Asymmetric PAKE Protocol
>> Document date:  2020-06-19
>> Group:          Individual Submission
>> Pages:          26
>> URL:
>> https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-06.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/
>> Htmlized:       https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-06
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-krawczyk-cfrg-opaque-06
>>
>> Abstract:
>>    This draft describes the OPAQUE protocol, a secure asymmetric
>>    password authenticated key exchange (aPAKE) that supports mutual
>>    authentication in a client-server setting without reliance on PKI and
>>    with security against pre-computation attacks upon server compromise.
>>    Prior aPAKE protocols did not use salt and if they did, the salt was
>>    transmitted in the clear from server to user allowing for the
>>    building of targeted pre-computed dictionaries.  OPAQUE security has
>>    been proven by Jarecki et al.  (Eurocrypt 2018) in a strong and
>>    universally composable formal model of aPAKE security.  In addition,
>>    the protocol provides forward secrecy and the ability to hide the
>>    password from the server even during password registration.
>>
>>    Strong security, versatility through modularity, good performance,
>>    and an array of additional features make OPAQUE a natural candidate
>>    for practical use and for adoption as a standard.  To this end, this
>>    draft presents several instantiations of OPAQUE and ways of
>>    integrating OPAQUE with TLS.
>>
>>    This draft presents a high-level description of OPAQUE, highlighting
>>    its components and modular design.  It also provides the basis for a
>>    specification for standardization but a detailed specification ready
>>    for implementation is beyond the scope of this document.
>>
>>    Implementers of OPAQUE should ONLY follow the precise specification
>>    in the upcoming draft-irtf-cfrg-opaque.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
> --
> -Clinton M. Bowen
>