[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
From: "Stanislav V. Smyshlyaev" <smyshsv () gmail ! com>
Date: 2024-03-25 11:55:31
Message-ID: CAMr0u6khy2oo6GpxYYWq803NPYvKHLk4=9Lf7Z5ddNVu8KbiZw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Dear CFRG,
The authors have updated the draft.
Please feel free to express whether the changes address your concerns.
Regards,
Stanislav (for chairs)
On Tue, Mar 5, 2024 at 9:37 AM Kevin Lewi <klewi@cs.stanford.edu> wrote:
> Hi Steve!
>
> Just wanted to check in and see if you had a chance to review my response
> to your feedback above. Let me know if there is anything else that you
> would like to see addressed explicitly, or if we are good to go.
>
> Kevin
>
> On Sun, Feb 11, 2024 at 8:59 PM Kevin Lewi <klewi@cs.stanford.edu> wrote:
>
>> (Replying to:
>> https://mailarchive.ietf.org/arch/msg/cfrg/Fxxdbe6sBae9yqTtZfwrGvtAKRQ/)
>>
>> Hi Steve,
>>
>> Appreciate the review and the feedback! Here are my thoughts:
>>
>> 1) "There should be a section mentioning that OPAQUE is doubly augmented
>> and why that's better than augmented."
>>
>> I gave this some thought and I think I understand the distinction between
>> an sdPAKE vs. aPAKE. But I am not entirely sure if we should get into this
>> level of detail in the draft, mainly because I am struggling to figure out
>> how to phrase this in a way that is generally understandable to most
>> readers without causing confusion. However, if you do feel like this would
>> be necessary to include in the draft text, can you perhaps write up a
>> suggested paragraph under a new subsection of the "Security Considerations"
>> section which covers this detail? Then we can discuss and iterate on the
>> wording. You can also open a PR on
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pulls and we can continue
>> the discussion via comments over there.
>>
>> 2) Section 10.3. "Related Protocols" should probably be removed.
>>
>> I agree, good suggestion! I went ahead and put up a PR for this change.
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443
>>
>> 3) The mentions of "offline registration" should be changed to "online
>> registration".
>>
>> Good point, this is confusing. Seems like we have a PR up (
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439) to address
>> this, by changing "offline registration" to simply read as "registration"
>> (no "online"). Let me know if that also sounds acceptable.
>>
>> 4) Now the good parts of OPAQUE that weren't mentioned. Stateless HSM
>> implementation.
>>
>> I agree with this as well, but similar to point #1, do you think that
>> this is something that we actually need to include explicitly in the draft
>> text? And if so, do you have a suggested change or wording that would be
>> suitable for adding to one of the sections?
>>
>> Let me know if I missed anything.
>>
>> Thanks,
>> Kevin
>>
>>
>> On Thu, Feb 1, 2024 at 12:39 AM <steve@tobtu.com> wrote:
>>
>>> I've been meaning to do a full review and just checked the status. So
>>> this might be a little rushed. Anyway...
>>>
>>> ----
>>>
>>> "Asymmetric PAKE" is not a thing. aPAKE means "augmented PAKE" and some
>>> time ago people saw "aPAKE" and thought it meant asymmetric because of it's
>>> asymmetrical relation between the client and server. The first PAKE was a
>>> balanced PAKE and it was then augmented so that a server doesn't hold a
>>> password equivalent. There are currently four types of PAKEs: balanced,
>>> augmented, doubly augmented, and identity. Abbreviated bPAKE, aPAKE, dPAKE,
>>> iPAKE and if the non-balanced PAKE has an OPRF then it is "strong" and is
>>> prefixed with an "s". Note that bPAKE ⊂ aPAKE ⊂ dPAKE ⊂ iPAKE. For info on
>>> iPAKEs see https://eprint.iacr.org/2020/529.
>>>
>>> Doubly augmented PAKEs' best use case is WiFi: compromising a device
>>> doesn't lead to being able to act as an AP. The first description of a
>>> dPAKE: "SPAKE2 can even be doubly augmented, where Alice does the same
>>> thing, but I'm not sure if there's any application to that." -Mike Hamburg (
>>> https://moderncrypto.org/mail-archive/curves/2015/000424.html). I
>>> actually couldn't think of a reason either until around the time the WiFi
>>> Alliance picked a known to be broken bPAKE.
>>>
>>> Which brings us to OPAQUE is not an aPAKE, it's a sdPAKE. One way to
>>> think of OPAQUE, as a sdPAKE, is that it's a cert delivery protocol. Once
>>> the client has the cert they just store and use it. There should be a
>>> section mentioning that OPAQUE is doubly augmented and why that's better
>>> than augmented
>>
>>
[Attachment #5 (text/html)]
<div dir="ltr">Dear CFRG,<div><br></div><div>The authors have updated the draft. \
</div><div>Please feel free to express whether the changes address your \
concerns.</div><div><br></div><div>Regards,</div><div>Stanislav (for \
chairs)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Tue, Mar 5, 2024 at 9:37 AM Kevin Lewi <<a \
href="mailto:klewi@cs.stanford.edu">klewi@cs.stanford.edu</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
Steve!<br><br>Just wanted to check in and see if you had a chance to review my \
response to your feedback above. Let me know if there is anything else that you would \
like to see addressed explicitly, or if we are good to go.<br><br>Kevin</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 11, 2024 at \
8:59 PM Kevin Lewi <<a href="mailto:klewi@cs.stanford.edu" \
target="_blank">klewi@cs.stanford.edu</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">(Replying to: <a \
href="https://mailarchive.ietf.org/arch/msg/cfrg/Fxxdbe6sBae9yqTtZfwrGvtAKRQ/" \
target="_blank">https://mailarchive.ietf.org/arch/msg/cfrg/Fxxdbe6sBae9yqTtZfwrGvtAKRQ/</a>)<br><div><br></div><div>Hi \
Steve,<br><br>Appreciate the review and the feedback! Here are my thoughts:<br><br>1) \
"There should be a section mentioning that OPAQUE is doubly augmented and why \
that's better than augmented."<br><br>I gave this some thought and I think I \
understand the distinction between an sdPAKE vs. aPAKE. But I am not entirely sure if \
we should get into this level of detail in the draft, mainly because I am struggling \
to figure out how to phrase this in a way that is generally understandable to most \
readers without causing confusion. However, if you do feel like this would be \
necessary to include in the draft text, can you perhaps write up a suggested \
paragraph under a new subsection of the "Security Considerations" section \
which covers this detail? Then we can discuss and iterate on the wording. You can \
also open a PR on <a href="https://github.com/cfrg/draft-irtf-cfrg-opaque/pulls" \
target="_blank">https://github.com/cfrg/draft-irtf-cfrg-opaque/pulls</a> and we can \
continue the discussion via comments over there.<br><br>2) Section 10.3. \
"Related Protocols" should probably be removed.<br><br>I agree, good \
suggestion! I went ahead and put up a PR for this change. <a \
href="https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443" \
target="_blank">https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443</a><br><br>3) \
The mentions of "offline registration" should be changed to "online \
registration".<br><br>Good point, this is confusing. Seems like we have a PR up \
(<a href="https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439" \
target="_blank">https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439</a>) to \
address this, by changing "offline registration" to simply read as \
"registration" (no "online"). Let me know if that also sounds \
acceptable.<br><br>4) Now the good parts of OPAQUE that weren't mentioned. \
Stateless HSM implementation.<br><br>I agree with this as well, but similar to point \
#1, do you think that this is something that we actually need to include explicitly \
in the draft text? And if so, do you have a suggested change or wording that would be \
suitable for adding to one of the sections?<br><br>Let me know if I missed \
anything.<br><br>Thanks,<br>Kevin<br><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 1, 2024 at \
12:39 AM <<a href="mailto:steve@tobtu.com" \
target="_blank">steve@tobtu.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I've been meaning to do a full review and just \
checked the status. So this might be a little rushed. Anyway...<br> <br>
----<br>
<br>
"Asymmetric PAKE" is not a thing. aPAKE means "augmented PAKE" \
and some time ago people saw "aPAKE" and thought it meant asymmetric \
because of it's asymmetrical relation between the client and server. The first \
PAKE was a balanced PAKE and it was then augmented so that a server doesn't hold \
a password equivalent. There are currently four types of PAKEs: balanced, augmented, \
doubly augmented, and identity. Abbreviated bPAKE, aPAKE, dPAKE, iPAKE and if the \
non-balanced PAKE has an OPRF then it is "strong" and is prefixed with an \
"s". Note that bPAKE ⊂ aPAKE ⊂ dPAKE ⊂ iPAKE. For info on iPAKEs see \
<a href="https://eprint.iacr.org/2020/529" rel="noreferrer" \
target="_blank">https://eprint.iacr.org/2020/529</a>.<br> <br>
Doubly augmented PAKEs' best use case is WiFi: compromising a device doesn't \
lead to being able to act as an AP. The first description of a dPAKE: "SPAKE2 \
can even be doubly augmented, where Alice does the same thing, but I'm not sure \
if there's any application to that." -Mike Hamburg (<a \
href="https://moderncrypto.org/mail-archive/curves/2015/000424.html" rel="noreferrer" \
target="_blank">https://moderncrypto.org/mail-archive/curves/2015/000424.html</a>). I \
actually couldn't think of a reason either until around the time the WiFi \
Alliance picked a known to be broken bPAKE.<br> <br>
Which brings us to OPAQUE is not an aPAKE, it's a sdPAKE. One way to think of \
OPAQUE, as a sdPAKE, is that it's a cert delivery protocol. Once the client has \
the cert they just store and use it. There should be a section mentioning that OPAQUE \
is doubly augmented and why that's better than augmented</blockquote></div> \
</blockquote></div> </blockquote></div>
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic