Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

[SeongHan Shin <[e-mail]>]

Dear all,

>> Additionally, developments such as Elligator and AugPAKE hold promise
>> for protocols that have both security proofs *and* no IPR encumbrance.
>
>https://datatracker.ietf.org/ipr/2037/<https://datatracker.ietf.org/ipr/2037/>

As in the above IPR Disclosures, AugPAKE can be used royal-free for any
conforming implementations.
The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
U.S. respectively.

Best regards,
Shin


On Fri, Dec 6, 2013 at 3:40 AM, Dan Harkins <[e-mail]> wrote:

>
>
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
> > On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <[e-mail]> wrote:
> >>
> >> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
> >>> Dan Harkins <[e-mail]>:
> >>>
> >>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
> >>>> results.
> >>>
> >>>
> >>> While it is true that Joe noted that, I think the point of the present
> >>> discussion is that the protocol wasn't actually reviewed by the CFRG
> >>> with
> >>> satisfactory results.
> >>
> >>   No, that's not really true.  There is a difference between "your
> >> protocol has
> >> not been proven secure" and "your protocol has a security flaw". And
> >> while
> >> the former has been pointed out on this list and the CFRG list, the
> >> later
> >> has not.
> >
> > Yes, it has.  Bodo pointed out a security flaw.
>
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.
>
> >>   You have pointed out an issue with using an in-band server-provided
> >> domain parameter set and I'm going to address that in a subsequent
> >> version.
> >> That's not really a flaw in the key exchange, it's how the key exchange
> >> has
> >> been inserted into TLS and it can be addressed by some text rewrite. I
> >> am genuinely thankful for your comment and I will address it in a
> >> subsequent version.
> >>
> >>   The present discussion on the list boils down to these subjects:
> >>
> >>   1) there's no security proof and that is unacceptable (Rene, Watson)
> >>   2) there's nothing special about this protocol so why don't you (being
> >>       me) spend your time working on something else that we (Rene,
> >>       Watson) think is better.
> >>   3) the TLS-pwd benefits and your use cases are not compelling to
> >>       me (Trevor).
> >>
> >> The response to #1 is that security proofs have never been required
> >> and we have standards-track protocols today that are susceptible to
> >> offline dictionary attack (every PSK cipher suite). So it's an appeal to
> >> a
> >> process that does not exist.
> >
> > At Watson points out, times have changed and the bar is higher now.
>
>   You are appealing to a process that does not exist.
>
> >> The response to #2 is that lack of implementation of these other
> >> protocols has been hampered by patents
> >
> > See the discussion around SRP that occurred when you first presented
> > this.  Any patent FUD which *might* have existed, once, has expired:
> >
> > http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
> > http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves. Now I know elliptic curve support is not a
> compelling use case for you but, again, so what?
>
> > Additionally, developments such as Elligator and AugPAKE hold promise
> > for protocols that have both security proofs *and* no IPR encumbrance.
>
> https://datatracker.ietf.org/ipr/2037/
>
> >> The response to #3 is: so? There is rarely uniformity in viewpoints
> >> as everyone's experience is different. Now there's a choice and if
> >> the benefits of one are not compelling then be happy you can
> >> choose the other.
> >
> > The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
> > has nothing to do with this draft's cryptographic differences.  It has
> > to do with architectural issues with the approach, which your draft
> > does not improve on.
>
>   You are free to not use this protocol as well if you do not find it
> compelling.
>
>   Dan.
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : [phone]
Fax : [phone]
E-mail : [e-mail]
------------------------------------------------------------------